Re: qla2xxx BUG: workqueue leaked lock or atomic

On 10:26, Andrew Vasquez wrote: > You are loading some stale firmware that's left over on the card -- > I'm not even sure what 4.00.70 is, as the latest release firmware is > 4.00.27. That's the firmware which came with the card. Anyway, I just upgraded the firmware, but the bug remains. The backt

RE: LSI Logic 40919o fibre channel: scsi works ip not

Mario, There appears to be a bug in the driver. Go to mpt_lan_post_receive_buckets(), in mptlan.c. Find: mf = mpt_get_msg_frame(LanCtx, mpt_dev); Later find: pRecvReq = (LANReceivePostRequest_t *) mf; Below that, should be: i = le16_to_cpu(mf-

Re: qla2xxx BUG: workqueue leaked lock or atomic

On 11:11, Andre Noll wrote: > On 10:26, Andrew Vasquez wrote: > > You are loading some stale firmware that's left over on the card -- > > I'm not even sure what 4.00.70 is, as the latest release firmware is > > 4.00.27. > > That's the firmware which came with the card. Anyway, I just upgraded > th

Re: qla2xxx BUG: workqueue leaked lock or atomic

On Tue, 27 Feb 2007, Andre Noll wrote: > On 10:26, Andrew Vasquez wrote: > > You are loading some stale firmware that's left over on the card -- > > I'm not even sure what 4.00.70 is, as the latest release firmware is > > 4.00.27. > > That's the firmware which came with the card. Anyway, I just u

Re: [Patch 2/2] cciss: supercedes add shutdown support (replaces reboot notifier)

> On Fri, 23 Feb 2007 14:42:39 -0600 "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> > wrote: > This patch supercedes yesterdays cciss-shutdown patch. The primary difference > is > removing __devexit from cciss_remove_one. Instead of create another function > I'd > rather use the code that was intend

Re: end to end error recovery musings

> "Eric" == Moore, Eric <[EMAIL PROTECTED]> writes: Eric> Martin K. Petersen on Data Intergrity Feature, which is also Eric> called EEDP(End to End Data Protection), which he presented some Eric> ideas/suggestions of adding an API in linux for this. T10 DIF is interesting for a few things:

Re: end to end error recovery musings

> These features make the most sense in terms of WRITE. Disks already > have plenty of CRC on the data so if a READ fails on a regular drive > we already know about it. Don't bet on it. If you want to do this seriously you need an end to end (media to host ram) checksum. We do see bizarre and qui

Re: end to end error recovery musings

On Feb 27, 2007 19:02 +, Alan wrote: > > It would be great if the app tag was more than 16 bits. Ted mentioned > > that ideally he'd like to store the inode number in the app tag. But > > as it stands there isn't room. > > The lowest few bits are the most important with ext2/ext3 because yo

Re: end to end error recovery musings

Martin K. Petersen wrote: "Eric" == Moore, Eric <[EMAIL PROTECTED]> writes: Eric> Martin K. Petersen on Data Intergrity Feature, which is also Eric> called EEDP(End to End Data Protection), which he presented some Eric> ideas/suggestions of adding an API in linux for this. T10 DIF is interes

Re: end to end error recovery musings

> "Alan" == Alan <[EMAIL PROTECTED]> writes: >> These features make the most sense in terms of WRITE. Disks >> already have plenty of CRC on the data so if a READ fails on a >> regular drive we already know about it. Alan> Don't bet on it. This is why I mentioned that I want to expose the

Re: end to end error recovery musings

> Not sure you're up-to-date on the T10 data integrity feature. > Essentially it's an extension of the 520 byte sectors common in disk I saw the basics but not the detail. Thanks for the explanation it was most helpful and promises to fix a few things for some controllers.. but here's a minor bit

Re: end to end error recovery musings

> "Alan" == Alan <[EMAIL PROTECTED]> writes: >> Not sure you're up-to-date on the T10 data integrity feature. >> Essentially it's an extension of the 520 byte sectors common in >> disk [...] Alan> but here's a minor bit of passing bad news - quite a few older Alan> ATA controllers can't iss

[PATCH 0/4] SCSI: Printing cleanups

This patch series is the first batch of cleanups in an attempt to make the SCSI printing more consistent and suitable for human consumption. Previously a typical error looked like this: sd 0:0:0:0: SCSI error: return code = 0x0802 sda: Current: sense key: Aborted Command Addi

[PATCH 1/4] SCSI: constants.c cleanup, verbose result printing

Clean up constants.c and make result printing more user friendly: - Refactor the command and sense functions so that the actual formatting can be called from the various helper functions with the correct prefix. - Replace scsi_print_hostbyte() and scsi_print_driverbyte() with scsi_pri

[PATCH 2/4] SCSI: Make error printing more verbose

This patch enhances SCSI error printing by: - Making use of scsi_print_result() in the completion functions. - Having scmd_printk() output the disk name (when applicable). Signed-off-by: Martin K. Petersen <[EMAIL PROTECTED]> --- drivers/scsi/scsi.c| 47 -

[PATCH 3/4] SCSI: Make sd printing use a common prefix

Make SCSI disk printing more consistent: - Define sd_printk(), sd_print_sense_hdr() and sd_print_result() - Move relevant header bits into sd.h - Remove all the legacy disk_name passing and use scsi_disk pointers where possible - Switch printk() lines to the new sd_ functions so that ou

[PATCH 4/4] SCSI: Convert sd logging to new printk helpers

Convert the sd.c SCSI logging calls to scmd_printk()/sd_printk() instead of plain printk(). Signed-off-by: Martin K. Petersen <[EMAIL PROTECTED]> --- sd.c | 50 +- 1 files changed, 29 insertions(+), 21 deletions(-) Index: scsi-misc-2.6/drive

Re: [PATCH 0/4] SCSI: Printing cleanups

Martin K. Petersen wrote: > This patch series is the first batch of cleanups in an attempt to make > the SCSI printing more consistent and suitable for human consumption. > > Previously a typical error looked like this: > > sd 0:0:0:0: SCSI error: return code = 0x0802 > sda: Current: