Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Pekka Enberg
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: BUG_ON(!PageSlab(page)); that's seriously screwed up. Do you have CONFIG_DEBUG_SLAB enabled? If not, please enable it and retest. This is scary. Looking at disassembly of the OOPS: Disassembly of section .text: .text:

Re: improve sg_luns output for iscsi

2007-03-19 Thread Olaf Hering
On Tue, Mar 06, Douglas Gilbert wrote: In summary sg_luns is probably not what you want! Yes, it can be done in bash. cd /sys/block/sde/device ; i=`pwd -P` ; printf '%x%012x\n' ${i##*:} - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL

Re: [PATCH] bind bsg to request_queue instead of gendisk

2007-03-19 Thread FUJITA Tomonori
From: Jens Axboe [EMAIL PROTECTED] Subject: Re: [PATCH] bind bsg to request_queue instead of gendisk Date: Wed, 14 Feb 2007 22:25:00 +0100 On Wed, Feb 14 2007, FUJITA Tomonori wrote: It seems that it would be better to bind bsg devices to request_queue instead of gendisk. This enables any

Re: [PATCH] bsg: iovec support

2007-03-19 Thread FUJITA Tomonori
From: Pete Wyckoff [EMAIL PROTECTED] Subject: [PATCH] bsg: iovec support Date: Thu, 1 Mar 2007 17:29:08 -0500 Support vectored IO as in SGv3. The iovec structure uses explicit sizes to avoid the need for compat conversion. Signed-off-by: Pete Wyckoff [EMAIL PROTECTED] --- My application

Re: SCSI Generic version 4 interface, release 1.2

2007-03-19 Thread FUJITA Tomonori
From: Douglas Gilbert [EMAIL PROTECTED] Subject: SCSI Generic version 4 interface, release 1.2 Date: Wed, 14 Mar 2007 12:18:16 -0400 - the write() usage in the sg driver's asynchronous interface has caused problems when mistakenly applied to a block device node rather than a sg device

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Pekka Enberg
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote: EIP is at kmem_cache_free+0x29/0x5a eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180 esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14 ds: 007b es: 007b ss: 0068 But somehow eax and edx have the same value 0xc180

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Pekka Enberg
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote: You can see that mempool_free is passing a NULL pointer to kmem_cache_free() which doesn't handle it properly. The NULL pointer comes from bio_free() where -bi_io_vec is NULL because nr_iovecs passed to bio_alloc_bioset() was zero. The question

drivers/message/fusion/mptscsih.c: inconsequent NULL checking

2007-03-19 Thread Adrian Bunk
The Coverity checker spotted the following inconsequent NULL checking in drivers/message/fusion/mptscsih.c: -- snip -- ... int mptscsih_qcmd(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_cmnd *)) { ... if (vdev (vdev-vtarget-tflags MPT_TARGET_FLAGS_Q_YES)

drivers/message/fusion/mptsas.c: inconsequent NULL checking

2007-03-19 Thread Adrian Bunk
The Coverity checker spotted the following inconsequent NULL checking in drivers/message/fusion/mptsas.c: -- snip -- ... static void mptsas_delete_expander_phys(MPT_ADAPTER *ioc) { ... if (port_info-phy_info (!(port_info-phy_info[0].identify.device_info

Re: [PATCH] bsg: iovec support

2007-03-19 Thread Douglas Gilbert
FUJITA Tomonori wrote: From: Pete Wyckoff [EMAIL PROTECTED] Subject: [PATCH] bsg: iovec support Date: Thu, 1 Mar 2007 17:29:08 -0500 Support vectored IO as in SGv3. The iovec structure uses explicit sizes to avoid the need for compat conversion. Signed-off-by: Pete Wyckoff [EMAIL

Re: [PATCH] bsg: iovec support

2007-03-19 Thread FUJITA Tomonori
From: Douglas Gilbert [EMAIL PROTECTED] Subject: Re: [PATCH] bsg: iovec support Date: Mon, 19 Mar 2007 08:56:39 -0400 FUJITA Tomonori wrote: From: Pete Wyckoff [EMAIL PROTECTED] Subject: [PATCH] bsg: iovec support Date: Thu, 1 Mar 2007 17:29:08 -0500 Support vectored IO as in SGv3.

Re: [PATCH] bsg: iovec support

2007-03-19 Thread Douglas Gilbert
FUJITA Tomonori wrote: From: Douglas Gilbert [EMAIL PROTECTED] Subject: Re: [PATCH] bsg: iovec support Date: Mon, 19 Mar 2007 08:56:39 -0400 FUJITA Tomonori wrote: From: Pete Wyckoff [EMAIL PROTECTED] Subject: [PATCH] bsg: iovec support Date: Thu, 1 Mar 2007 17:29:08 -0500 Support

Re: [PATCH] bsg: iovec support

2007-03-19 Thread FUJITA Tomonori
From: Douglas Gilbert [EMAIL PROTECTED] Subject: Re: [PATCH] bsg: iovec support Date: Mon, 19 Mar 2007 10:04:45 -0400 Pete is also suggesting (shown above) a revised sg_io_vec structure that uses a uint64_t for the pointer to simplify 32, 64 bit thunking. All I said is that it would be

[PATCH 1/2] fusion : shost max_id not set in VMWare guest os

2007-03-19 Thread Eric Moore
[PATCH 1/2] fusion : shost max_id not set in VMWare guest os In vmware guest os with emulated LSI 53c1030, the port facts config page is not having MaxDevices initialized to 16 devices. Instead its set to zero. Thereforewhen driver loads, no devices are scanned for from scsi_scan_host. Prior to

[PATCH 2/2] fusion : VMWare guest OS remounted as read only fix

2007-03-19 Thread Eric Moore
This address the issue of VMWare guest OS being remounted as read-only becuase the underlying device was held busy too long, , and at the same time address Engenio MPP driver concerns over infinite retries. This patch removes the code that snoops the SAM STATUS on busy, which would be

Re: [PATCH 1/2] fusion : shost max_id not set in VMWare guest os

2007-03-19 Thread Christoph Hellwig
On Mon, Mar 19, 2007 at 10:30:43AM -0600, Eric Moore wrote: [PATCH 1/2] fusion : shost max_id not set in VMWare guest os In vmware guest os with emulated LSI 53c1030, the port facts config page is not having MaxDevices initialized to 16 devices. Instead its set to zero. Thereforewhen driver

[PATCH v2] bsg: iovec support with explicit u64

2007-03-19 Thread Pete Wyckoff
[EMAIL PROTECTED] wrote on Mon, 19 Mar 2007 14:07 -0400: Here is the patch to use sg_iovec, with its userspace void * and size_t, and the CONFIG_COMPAT code to fixup 32-bit userspace. I'm not fond of having __u64 for non-iovec buffer representations, and void * for iovec buffer

Re: [PATCH] bind bsg to request_queue instead of gendisk

2007-03-19 Thread FUJITA Tomonori
From: FUJITA Tomonori [EMAIL PROTECTED] Subject: Re: [PATCH] bind bsg to request_queue instead of gendisk Date: Mon, 19 Mar 2007 19:25:34 +0900 From: Jens Axboe [EMAIL PROTECTED] Subject: Re: [PATCH] bind bsg to request_queue instead of gendisk Date: Wed, 14 Feb 2007 22:25:00 +0100 On Wed,

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Mike Christie
Andreas Steinmetz wrote: As posted to lkml and linux-scsi on 2007-03-15 without reply, see http://marc.info/?l=linux-kernelm=117395128412313w=2 for original post: It is not so nice when one can write backup tapes but the tapes cannot be read. I don't know if memory management or the st

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread James Bottomley
On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: I can't even say if the tapes are written correctly as I can't read them (one does not reboot production machines back to 2.4.x just to try to read a backup tape - I don't have 2.6.x older than 2.6.20 on these machines). Could you

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread James Bottomley
On Mon, 2007-03-19 at 17:47 -0400, Gene Heskett wrote: James, could this also be the cause of a tar based backup going crazy and thinking all data is new under any 2.6.21-rc* kernel I've tested so far with amanda, which in my case uses tar? I've tried the fedora patched tar-1.15-1, and one

RE: [PATCH] scsi: megaraid_sas - throttle io if cmds are in riskof being timed-out

2007-03-19 Thread Patro, Sumant
Thank you James. I will submit new patch that will throttle (if required) from eh_timed_out call back. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 3:23 PM To: Patro, Sumant Cc: [EMAIL PROTECTED];

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Andreas Steinmetz
Mike Christie wrote: James Bottomley wrote: On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: I can't even say if the tapes are written correctly as I can't read them (one does not reboot production machines back to 2.4.x just to try to read a backup tape - I don't have 2.6.x older than

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Andreas Steinmetz
Mike Christie wrote: Mike Christie wrote: James Bottomley wrote: On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: I can't even say if the tapes are written correctly as I can't read them (one does not reboot production machines back to 2.4.x just to try to read a backup tape - I don't

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Gene Heskett
On Monday 19 March 2007, James Bottomley wrote: On Mon, 2007-03-19 at 17:47 -0400, Gene Heskett wrote: James, could this also be the cause of a tar based backup going crazy and thinking all data is new under any 2.6.21-rc* kernel I've tested so far with amanda, which in my case uses tar? I've

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Andrew Morton
On Tue, 20 Mar 2007 00:25:02 +0100 Andreas Steinmetz [EMAIL PROTECTED] wrote: Mike Christie wrote: Mike Christie wrote: James Bottomley wrote: On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: I can't even say if the tapes are written correctly as I can't read them (one does not

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Andreas Steinmetz
Andrew Morton wrote: On Tue, 20 Mar 2007 00:25:02 +0100 Andreas Steinmetz [EMAIL PROTECTED] wrote: Mike Christie wrote: Mike Christie wrote: James Bottomley wrote: On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: I can't even say if the tapes are written correctly as I can't read

RE: MPT Fusion LSI22320 , Domain validation loops .

2007-03-19 Thread Moore, Eric
On Saturday, March 17, 2007 2:33 PM, James W. Laferriere wrote: Hello All , I am have been having this problem since I purchased the controller and after changing out the disks I thought were the problem . I am still getting the continous : mptscsih: ioc1: attempting task