Re: [PATCH] target: fix return value check in sbp_register_configfs()

2012-09-22 Thread Nicholas A. Bellinger
On Fri, 2012-09-21 at 13:57 +0800, Wei Yongjun wrote: > From: Wei Yongjun > > In case of error, the function target_fabric_configfs_init() returns > ERR_PTR() not NULL pointer. The NULL test in the return value check > should be replaced with IS_ERR(). > > dpatch engine is used to auto generated

Re: [PATCH] qla2xxx: Fix endianness of task management response code

2012-09-22 Thread Nicholas A. Bellinger
On Wed, 2012-09-19 at 00:43 -0500, Saurav Kashyap wrote: > > >From: Roland Dreier > > > >The qla2xxx firmware actually expects the task management response > >code in a CTIO IOCB with SCSI status mode 1 to be in little-endian > >byte order, ie the response code should be the first byte in the > >

Re: [PATCH v7 0/6] ZPODD patches

2012-09-22 Thread Rafael J. Wysocki
On Saturday, September 22, 2012, Alan Stern wrote: > On Sat, 22 Sep 2012, Rafael J. Wysocki wrote: > > > > > I see. So the sr's runtime suspend may be useful even without the > > > > power-off > > > > feature, right? > > > > > > Exactly. Even though the drive itself may not be powered off, by

Re: [PATCH v7 0/6] ZPODD patches

2012-09-22 Thread Alan Stern
On Sat, 22 Sep 2012, Rafael J. Wysocki wrote: > > > I see. So the sr's runtime suspend may be useful even without the > > > power-off > > > feature, right? > > > > Exactly. Even though the drive itself may not be powered off, by > > putting it into runtime suspend we gain the ability to suspen

[scsi] mpt-fusion: No SES device support?

2012-09-22 Thread Lars Randers
I can't get the SES device on my MPT controller to show up in Linux as a sg device. The controller is a re-flashed IBM BR10i (LSISAS1068E), running the latest firmware and it is connected to the SES capable backplane via i2c on the SFF-8087 sidebands. Bios post as follows: SLOT ID LUN VENDOR

Re: [PATCH v7 0/6] ZPODD patches

2012-09-22 Thread Rafael J. Wysocki
On Saturday, September 22, 2012, Alan Stern wrote: > On Sat, 22 Sep 2012, Rafael J. Wysocki wrote: > > > > There are sd devices with removable media. > > > > OK. Does the SCSI layer distinguish them from devices without removable > > media? > > Yes, it does. struct scsi_device has a .removabl

Re: [PATCH v7 0/6] ZPODD patches

2012-09-22 Thread Alan Stern
On Sat, 22 Sep 2012, Rafael J. Wysocki wrote: > > There are sd devices with removable media. > > OK. Does the SCSI layer distinguish them from devices without removable > media? Yes, it does. struct scsi_device has a .removable member, and the Removable flag is part of the response data to th

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

2012-09-22 Thread Thomas Schwinge
Hi Borislav! On Mon, 17 Sep 2012 19:23:45 +0200, Borislav Petkov wrote: > On Thu, Sep 13, 2012 at 02:58:25PM +0200, Borislav Petkov wrote: > > Here's the script, let me know how it goes: > > Here's a more correct version. I'm not saying yours won't work based > on the rdmsr and setpci output on

Re: [PATCH v7 0/6] ZPODD patches

2012-09-22 Thread Rafael J. Wysocki
On Saturday, September 22, 2012, Oliver Neukum wrote: > On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote: > > > Now, James says he doesn't like the way ready_to_power_off is used. Sure > > enough, it is totally irrelevant to the majority of SCSI devices. It > > actually > > is total

Re: [PATCH v3] scsi_lib: rate-limit the error message from failing commands

2012-09-22 Thread James Bottomley
On Fri, 2012-09-21 at 15:15 -0400, Mike Snitzer wrote: > On Thu, Aug 30, 2012 at 7:25 PM, Jens Axboe wrote: > > On 2012-08-30 14:06, Yi Zou wrote: > >> [ > >> Jens/James, > >> > >> This is a rather old rate limt patch but never gets picked up in upstream, > >> so I > >> am resending it here as v3

Re: [PATCH v7 0/6] ZPODD patches

2012-09-22 Thread Oliver Neukum
On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote: > Now, James says he doesn't like the way ready_to_power_off is used. Sure > enough, it is totally irrelevant to the majority of SCSI devices. It actually > is totally irrelevant to everything in the SCSI subsystem except for the sr >