The linux/drivers/scsi/sr.c code will issue a MODE_SENSE[_10] command to
a device as the first command sent to the device.  If the device has
just come out of reset, it will likely respond with a UNIT_ATTENTION /
NOT_READY status, which causes the MODE_SENSE to fail.  In fact, the
device may have several UNIT_ATTENTION conditions queued up (power-up
reset, media change, etc.)

This results in the mode page 0x2a data not being properly read and
interpreted.  As an end-effect, things like packet-writing don't work
(because the writeable bit is not set).

The solution to this is to issue one or more TEST_UNIT_READY commands to
the device to clear any pending UNIT_ATTENTION conditions.  This is the
technique used by sd.c -- in fact, this code was lifted directly from
sd.c

At some point in the future, abstraction of this initial TEST_UNIT_READY
code between all high-level SCSI drivers may be apropriate.  For now,
this patch makes sr.c issue TEST_UNIT_READY to clear the UNIT_ATTENTION,
thus allowing the mode page 0x2a code to work properly.  Given the
approaching 2.6.0-final release, I urge that this patch be accepted.

into home.osdl.org:/home/torvalds/v2.5/linux

the SG_IO and SCSI_IOCTL_SEND_COMMAND ioctl's. That just
screws things up when the drive is mounted.

If somebody wants exclusive access, he should indicate that
at open time.

into home.osdl.org:/home/torvalds/v2.5/linux

I've been trying to remove these, but apparently new ones crop up. Lets
just call it io scheduler, none of the ones in the kernel are using the
classic elevator algorithm.

From René Scharfe <l.s.r@web.de>

As a result the size of vfat.o drops by 384 bytes in my build.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

use the PCI layer instead to provide those for us.

* remove PCI_CACHE_LINE_SIZE workaround, PCI core already does
  this for us.  (main change)
* propagate pci_set_dma_mask return value
* add 'ULL' suffix to pci_set_dma_mask arg
* propagate pci_enable_device return value
* call pci_set_mwi, check and propagate its return value
* call pci_clear_mwi and pci_disable_device on close, and probe error
* call iounmap when cleaning up

Modifies drivers atm/eni.c, ide/pci/cmd64x.c, and
ide/pci/ns87415.c.  Ack'd by DaveM.

This implements the needed 'release' callback in order to make
videodev/sysfs happy again.

This reenables the CAPTURE button events in the sonypi driver, which
were lost with the latest patch...

This adds support for software controlled hard drive LED activity.

This is really nice on such machines as Apple Powerbooks, where there is
no such LED in the first place and the sleep/suspend LED isn't used for
anything when the machine is running.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

Fix byte order of info parameter in ip6ip6_err().

into redhat.com:/spare/repo/net-drivers-2.5

* The PCI layer now handles incorrect cacheline size settings,
  as it should.  Remove our own workarounds.
* Move pci_set_mwi up much earlier in the probe process,
  and check its return value.
* Call pci_clear_mwi() in ->probe error handling
* Call pci_clear_mwi() in ->remove

into nuts.ninka.net:/disk1/davem/BK/tg3-2.5

into nuts.ninka.net:/disk1/davem/BK/sparc-2.5

From: "Bryan O'Sullivan" <bos@serpentine.com>

This patch adds documentation for the contents of the /proc/stat file.

If journal_start() fails it returns an ERR_PTR.  Best not pass that into
journal_stop().

Ancient bug, reported by Hiroshi Inoue <inoueh@uranus.dti.ne.jp>:

 1. login to tty2 (not tty1)
 2. start kon (Kanji cONsole emulator, console which support
    Japanese characters)
 3. exit kon
 4. logout

It oopses in the debugging function check_tty_count(), walking a list_head
which has been list_del()'d.   Call trace is:

#0  check_tty_count (tty=0x10d42000, routine=0xc817b00 ".paths") at include/asm/processor.h:583
#1  0x022c6c00 in do_tty_hangup (data=0x10d42000) at drivers/char/tty_io.c:426
#2  0x022c6f60 in tty_vhangup (tty=0xc817b00) at drivers/char/tty_io.c:536
#3  0x022c6fcc in disassociate_ctty (on_exit=1) at drivers/char/tty_io.c:574
#4  0x02127aee in do_exit (code=0) at kernel/exit.c:718
#5  0x02127caa in do_group_exit (exit_code=0) at kernel/exit.c:796
#6  0x02127cbc in sys_exit_group (error_code=0) at kernel/exit.c:807

The tty refcount is zero, so everything seems consistent and sensible.  The
fix just uses list_del_init() on that list_head.


Heaven knows what the locking for tty->count is though.  Some bizarre mixture
of BKL, tty_sem and nothing at all.