This patch addresses a problem in both sd.c and sr.c.  When a read/write
command is initialized, the routines may reduce this_count (the number of
sectors to transfer) if it exceeds the maximum allowed value (i.e., 0xffff
for READ(10)).  However, the code does not similarly alter
scmd->request_bufflen and scmd->bufflen to match the change in the CDB
value.

scmd->request_bufflen is important for the usb-storage driver, which
requires that it be exactly equal to the number of bytes transferred.
scmd->bufflen is used in the rw_intr() routines, where it is passed to
scsi_io_completion() as the number of sectors transferred if no errors
occur.

Another small change in the patch concerns the code in sr.c that checks
whether the total of the scatter-gather area lengths matches
scmd->request_bufflen.  If they don't match, the patch bumps the kernel
log message level up to KERN_ERR, and it takes the more conservative
approach of adjusting scmd->request_bufflen only if the s-g length is
smaller than the request length.

On Sat, Aug 16, 2003 at 10:44:09AM +0200, Olaf Hering wrote:
>
> Why is ->proc_info() called when the function pointer is NULL?

Looks like the check for it's presence got lost in

	[PATCH] Correct removal of procfs host enteries [1/2]

Here's a trivial patch to get it back:

When umounting a ppa device, I see (2.6.0-test3):

Releasing ppa0
Iomega VPI0 (ppa) interface did not call scsi_unregister
Call Trace:
 [<f89aeca6>] exit_this_scsi_driver+0xb6/0xfa [ppa]
 [<c013c08d>] sys_delete_module+0x18d/0x1e0
 [<c0155276>] do_munmap+0x136/0x1b0
 [<c0155333>] sys_munmap+0x43/0x70
 [<c0109657>] syscall_call+0x7/0xb

so ppa needs to call scsi_unregister().
Is this all that's needed?

--
~Randy


patch_name:	scsi_ppa_unreg.patch
patch_version:	2003-08-15.09:46:30
author:		Randy.Dunlap <rddunlap@osdl.org>
description:	ppa driver needs to call scsi_unregister(host);
product:	Linux
product_versions: 260-815
maintainer:	campbell@torque.net
diffstat:	=
 drivers/scsi/ppa.c |    1 +
 1 files changed, 1 insertion(+)

Damm, I keep forgetting about firewire, sorry.

This should fix the ieee1394 code for the device.name removal, and for
the i2c structure changes that happened in 2.6.0-test3.

This patch has no code changes.  It is just a resync of all the version
numbers with the 6.10 driver and bumping up the driver version number.

From: David Jeffery <david_jeffery@adaptec.com>
(with minor reject fixes)

This patch removes several places where we were using kmalloc flag
tricks to always get memory <4GB instead of using the proper
dma_alloc_consistent() API.  It also no longer #errors on when compiled
for x86-64 kernels.

From: David Jeffery <david_jeffery@adaptec.com>
(with minor fixes for rejects)

This patch is a resync with the 6.10 driver for 2.4 and updates the 2.4
compatability code.  It adds a new wrapper function for differences
between the 2.4 and 2.6 scsi proc interface,  forces pci posting in 3
places, corrects using a meaningless constant of 0x80 to 0, and syncs
comments that had changed. 

From: 	David Jeffery <david_jeffery@adaptec.com>
(with fix ups for rejections on CONFIG_HIGHIO)

This patch has no code changes.  It is only the result of running
scripts/Lindent on drivers/scsi/ips.c in test3.  Rather than use this
patch, it may be advisable to just run 

sh scripts/Lindent drivers/scsi/ips.c 

The nasty 3-4 space indenting in ips.c has always made it a pain to
read.  The remaining patches in this patch set all assume ips.c has been
lindented. 

In sym_attach we call sym_hcb_attach. If it fails we call
sym_free_resources which will call sym_hcb_free. Unfortunately
sym_hcb_attach also calls sym_hcb_free on failure.

This results in a bunch of things being freed twice and it looks like
the sym2 memory allocator adds them to the freelist twice. Sometime later
on we allocate the memory twice, with weird consequences.

One problem we found when we hit a bad adapter, we need to use scsi_host_put.

This is the preliminary version with no error indications or
control over the types of failures.

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

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

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

From: Andries Brouwer <aebr@win.tue.nl>

I see an Oops in the SCSI code, caused by the fact that sdkp is NULL
in sd_shutdown. "How can that be?", you will ask - dev->driver_data was set
in sd_probe. But in my case sd_probe never finished. An insmod usb-storage
hangs forever, or at least for more than six hours, giving ample opportunity
to observe this race between sd_probe and sd_shutdown.
(Of course sd_probe hangs in sd_revalidate disk.)

Perhaps the obvious test is a good idea.
Locking seems meaningless - sd_probe will never finish.

  ia64: Fix prologue directives for sys_clone() and sys_clone2()

into tiger.hpl.hp.com:/data1/bk/lia64/to-linus-2.5

into kroah.com:/home/greg/linux/BK/i2c-2.6

into kroah.com:/home/greg/linux/BK/gregkh-2.6

This has been in the -mm tree for a while and has helped a lot in finding
lots of improper users of the driver core.  It also moves the driver core
code up quite a few levels on the "Rusty's guide to kernel APIs".

A trailing else in the #ifdef CONFIG_USB_NET1080 block that would
prevent it from properly filling the bulk URB.

The code that manges the synchronous control/bulk calls has
been a mess for ages.  This patch rewrites it using:

 - "struct completion" instead of a usb-internal clone therof,
 - prepare_to_wait()/finish_wait() instead of the tangled
   mess it now uses (or a new wait_event_timeout call, as in
   previous versions of this patch).

It's a net code shrink and simplification.

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

Again, from Randy Dunlap

Based on patch from Randy Dunlap.

Need cacheflush.h for change_page_attr()

- sort some of the ATI entries. (note, there are dupes in there
  that could be fixed up at some point).
- Rename PCI_DEVICE_ID_RADEON_IGP to ATI_RS100.
  RadeonIGP is the family, not the specific chip.