From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Anderson Subject: Re: [PATCH] scsi host cleanup 3/3 (driver changes) Date: Thu, 10 Oct 2002 09:46:33 -0700 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <20021010164633.GA1348@beaverton.ibm.com> References: <20021010090157.A990@zuul.cca.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20021010090157.A990@zuul.cca.cpqcorp.net> List-Id: linux-scsi@vger.kernel.org To: Stephen Cameron Cc: linux-scsi@vger.kernel.org Stephen, You where most likely hitting the sg might sleep problem. I posted a patch to this list and I believe that the workaround is in 2.5.41. Stephen Cameron [steve.cameron@hp.com] wrote: > Mike Anderson wrote: > > > If you read my previous post on this patch I indicated that few of the > > driver changes I was only able to compile test ( block/cciss_scsi.c, > > scsi/53c700.c, scsi/pcmcia/*, scsi/wd33c93.c). The changes to the > > drivers are to remove the old interfaces and possibly extra NULL inits > > of struct members. These changes will need to be ok'd by there > > respective maintainers. > > I tried out these patches with 2.5.40 and the cciss driver. > Looks ok to me. > > When I did "echo engage scsi > /proc/driver/cciss/cciss0" to > make the cciss driver register with the scsi subsystem, I got > what you see below. However, I also got the same thing when > trying 2.5.40 without the patches, so I don't think the patches > are the problem. > > When I tried 2.5.41 without the patches, the problem below was > gone. > > And, despite all this, it always appeared to work anyway. > My tape drive appeared, and I could always do i/o to it. > > -- steve > > dmesg output follows: > > cciss0: No device changes detected. > scsi0 : cciss0 > Vendor: COMPAQ Model: SDT-10000 Rev: 1.14 > Type: Sequential-Access ANSI SCSI revision: 02 > Debug: sleeping function called from illegal context at slab.c:1374 > ce275de0 c01195e6 c0320bc0 c0326282 0000055e c1287080 c013c15f c0326282 > 0000055e c1336324 c1330c00 00000000 ce275e4c 00000286 00000286 cfc32974 > cf37e000 00000000 cfffb080 d0800000 00001000 ce274000 00001000 c013a199 > Call Trace: > []__might_sleep+0x56/0x5d > []kmalloc+0x4f/0x330 > []get_vm_area+0x29/0x140 > []__vmalloc+0x3b/0x120 > []vmalloc+0x16/0x20 > []sg_init+0xbe/0x160 > []scsi_register_host+0x130/0x200 > []cciss_engage_scsi+0x136/0x150 > []cciss_proc_write+0x8a/0xb0 > []open_namei+0x37f/0x4e0 > []free_block+0x192/0x2c0 > []proc_file_write+0x31/0x40 > []vfs_write+0xb6/0x180 > []filp_close+0x10f/0x120 > []filp_close+0x10f/0x120 > []sys_write+0x2a/0x40 > []syscall_call+0x7/0xb .. snip .. -andmike -- Michael Anderson andmike@us.ibm.com