Re: BAD_SG_DMA panic in aha1542
On Mon, Apr 30 2007, Bob Tracy wrote: rct wrote: Apologies to all concerned for an unfortunate delay in resolving this. (...) I'll go retrieve a more conservatively-configured source tree (closer to what DSL-N uses) and start over... Success with the Debian 2.6.18-4-486 build, which is known to work almost as well on the test platform as the 2.6.12 kernel that DSL-N comes with. I used an older compiler than Debian used for their production build, so I binary-patched the aha1542.ko and sr_mod.ko files so insmod wouldn't complain about different vermagic strings. That's as close as it gets without redoing everything from scratch. I'll give Alan's and James' patches a go within the next 13 hours. (Alan: what *else* would you name a variable associated with a bounce buffer besides Zebedee? Thanks for the occasion to smile...) Try Alan's patch, it should fix it. As mentioned earlier in this thread, the real fix is to get rid of the cgc stuff and inject into the block layer from cdrom.c. But Alan's patch should work-around the issue for now. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BAD_SG_DMA panic in aha1542
Jens Axboe wrote: Try Alan's patch, it should fix it. As mentioned earlier in this thread, the real fix is to get rid of the cgc stuff and inject into the block layer from cdrom.c. But Alan's patch should work-around the issue for now. Trying that patch is the next thing on my plate. For now, here's the dmesg output James requested (aha1542 debug patch). Oddly enough, when the smoke cleared, the mount succeeded and I could access the cd :-). Initial state: SCSI cdrom drivers not loaded. Command: mount -t iso9660 /dev/scd0 /mnt/cdrom -r sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:4:0: Attached scsi CD-ROM sr0 sgpnt[0:1] page c3489af0/0x3489af0 length 32 BUG: warning at drivers/scsi/aha1542.c:78/BAD_SG_DMA() [c4819858] aha1542_queuecommand+0x4a4/0x4ce [aha1542] [c4833317] scsi_done+0x0/0x16 [scsi_mod] [c48339f2] scsi_dispatch_cmd+0x1b0/0x223 [scsi_mod] [c4837abc] scsi_request_fn+0x22e/0x2ac [scsi_mod] [c01a09d4] __generic_unplug_device+0x1d/0x1f [c01a0a3a] blk_execute_rq_nowait+0x64/0x6a [c01a0aae] blk_execute_rq+0x6e/0x8f [c01a02d0] blk_end_sync_rq+0x0/0x1d [c01354c9] mempool_alloc+0x1c/0x97 [c014d2fc] bio_phys_segments+0xe/0x14 [c019f456] blk_rq_bio_prep+0x28/0x7c [c483744f] scsi_execute+0xc6/0xd9 [scsi_mod] [c4942da2] sr_do_ioctl+0x80/0x1bd [sr_mod] [c483439d] scsi_set_medium_removal+0x43/0x67 [scsi_mod] [c494209b] sr_packet+0x1a/0x1f [sr_mod] [c49aad25] cdrom_open+0x337/0x8ae [cdrom] [c0275aaf] wait_for_completion+0x5b/0x84 [c0111cba] default_wake_function+0x0/0xc [c0120312] call_usermodehelper_keys+0xa6/0xb2 [c012031e] __call_usermodehelper+0x0/0x43 [c012049b] request_module+0xc2/0xd0 [c01a9b71] kobject_get+0xf/0x13 [c4942324] sr_block_open+0x74/0x81 [sr_mod] [c014ec4f] do_open+0x8a/0x313 [c4837b01] scsi_request_fn+0x273/0x2ac [scsi_mod] [c0275d9f] io_schedule+0xe/0x16 [c0276065] __wait_on_bit+0x50/0x58 [c014ad1a] sync_buffer+0x0/0x2e [c014ad1a] sync_buffer+0x0/0x2e [c02760cf] out_of_line_wait_on_bit+0x62/0x6a [c0122cf0] wake_bit_function+0x0/0x3c [c014ace5] __wait_on_buffer+0x1c/0x1f [c48852e1] __ext3_get_inode_loc+0x263/0x2b1 [ext3] [c015bbd6] d_splice_alias+0xa9/0xc3 [c488b470] ext3_lookup+0x98/0xb8 [ext3] [c0153018] do_lookup+0x4f/0x135 [c015b1cb] dput+0x1a/0x10b [c0154e0d] __link_path_walk+0xa5d/0xba8 [c014ef2d] blkdev_get+0x55/0x60 [c014f212] open_bdev_excl+0x32/0x6e [c014e1f8] get_sb_bdev+0x14/0x115 [c49934c1] isofs_get_sb+0x12/0x16 [isofs] [c4993987] isofs_fill_super+0x0/0x899 [isofs] [c014df0a] vfs_kern_mount+0x88/0xfd [c014dfb2] do_kern_mount+0x26/0x36 [c015eee2] do_mount+0x589/0x5fb [c015e21c] mntput_no_expire+0x11/0x59 [c015e21c] mntput_no_expire+0x11/0x59 [c0155007] link_path_walk+0xaf/0xb9 [c013c4fc] __handle_mm_fault+0x341/0x620 [c01552c4] do_path_lookup+0x195/0x1b5 [c013c342] __handle_mm_fault+0x187/0x620 [c0136236] get_page_from_freelist+0x6e/0x2bb [c0136ae6] __get_free_pages+0x25/0x3e [c015de80] copy_mount_options+0x27/0x10a [c015efbe] sys_mount+0x6a/0xa2 [c0102a47] syscall_call+0x7/0xb sgpnt[0:1] page c3489af0/0x3489af0 length 32 BUG: warning at drivers/scsi/aha1542.c:78/BAD_SG_DMA() [c4819858] aha1542_queuecommand+0x4a4/0x4ce [aha1542] [c4833317] scsi_done+0x0/0x16 [scsi_mod] [c48339f2] scsi_dispatch_cmd+0x1b0/0x223 [scsi_mod] [c4837abc] scsi_request_fn+0x22e/0x2ac [scsi_mod] [c01a1662] blk_run_queue+0x2a/0x4b [c483725a] scsi_queue_insert+0x75/0x7d [scsi_mod] [c01a1598] blk_done_softirq+0x4a/0x55 [c0118563] __do_softirq+0x35/0x75 [c01185c5] do_softirq+0x22/0x26 [c0105074] do_IRQ+0x48/0x50 [c0103a9a] common_interrupt+0x1a/0x20 [c48339f6] scsi_dispatch_cmd+0x1b4/0x223 [scsi_mod] [c4837abc] scsi_request_fn+0x22e/0x2ac [scsi_mod] [c01a09d4] __generic_unplug_device+0x1d/0x1f [c01a0a3a] blk_execute_rq_nowait+0x64/0x6a [c01a0aae] blk_execute_rq+0x6e/0x8f [c01a02d0] blk_end_sync_rq+0x0/0x1d [c01354c9] mempool_alloc+0x1c/0x97 [c014d2fc] bio_phys_segments+0xe/0x14 [c019f456] blk_rq_bio_prep+0x28/0x7c [c483744f] scsi_execute+0xc6/0xd9 [scsi_mod] [c4942da2] sr_do_ioctl+0x80/0x1bd [sr_mod] [c483439d] scsi_set_medium_removal+0x43/0x67 [scsi_mod] [c494209b] sr_packet+0x1a/0x1f [sr_mod] [c49aad25] cdrom_open+0x337/0x8ae [cdrom] [c0275aaf] wait_for_completion+0x5b/0x84 [c0111cba] default_wake_function+0x0/0xc [c0120312] call_usermodehelper_keys+0xa6/0xb2 [c012031e] __call_usermodehelper+0x0/0x43 [c012049b] request_module+0xc2/0xd0 [c01a9b71] kobject_get+0xf/0x13 [c4942324] sr_block_open+0x74/0x81 [sr_mod] [c014ec4f] do_open+0x8a/0x313 [c4837b01] scsi_request_fn+0x273/0x2ac [scsi_mod] [c0275d9f] io_schedule+0xe/0x16 [c0276065] __wait_on_bit+0x50/0x58 [c014ad1a] sync_buffer+0x0/0x2e [c014ad1a] sync_buffer+0x0/0x2e [c02760cf] out_of_line_wait_on_bit+0x62/0x6a [c0122cf0] wake_bit_function+0x0/0x3c [c014ace5] __wait_on_buffer+0x1c/0x1f [c48852e1] __ext3_get_inode_loc+0x263/0x2b1 [ext3] [c015bbd6] d_splice_alias+0xa9/0xc3 [c488b470]
Re: BAD_SG_DMA panic in aha1542
That's as close as it gets without redoing everything from scratch.
I'll give Alan's and James' patches a go within the next 13 hours.
(Alan: what *else* would you name a variable associated with a bounce
buffer besides Zebedee? Thanks for the occasion to smile...)
The one I sent has a memory leak but it won't matter for basic testing.
Or you can change the final bit to
scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);
if (zebedee != cgc-buffer) {
if (cgc-data_direction == DMA_FROM_DEVICE)
memcpy(cgc-buffer, zebedee, cgc-buflen);
kfree(zebedee); /* Time for bed */
}
Alan
--
`I can hear you.` ,said Florence. `It s not true. Noddy and I are just
good friends.`
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata /dev/scd0 problem: mount after burn fails without eject
Forwarding to linux-scsi and linux-ide mailing lists. Frank van Maarseveen wrote: Tested on 2.6.20.6 and 2.6.21.1 I decided to swich from the old IDE drivers to libata and now there seems to be a little but annoying problem: cannot mount an ISO image after burning it. May 1 14:32:55 kernel: attempt to access beyond end of device May 1 14:32:55 kernel: sr0: rw=0, want=68, limit=4 May 1 14:32:55 kernel: isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 an eject command seems to fix the state of the PATA DVD writer or driver. The problem occurs for burning a CD and for DVD too with identical error messages. relevant kernel boot messages: | ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14 | ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15 | scsi0 : ata_piix | ata1.00: ATA-7: ST3120814A, 3.AAJ, max UDMA/100 | ata1.00: 234441648 sectors, multi 8: LBA48 | ata1.00: configured for UDMA/100 | scsi1 : ata_piix | ata2.00: ATAPI, max UDMA/33 | ata2.01: ATAPI, max UDMA/33 | ata2.00: configured for UDMA/33 | ata2.01: configured for UDMA/33 | scsi 0:0:0:0: Direct-Access ATA ST3120814A 3.AA PQ: 0 ANSI: 5 | SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB) | sda: Write Protect is off | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA | SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB) | sda: Write Protect is off | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA | sda: sda1 sda2 sda4 | sd 0:0:0:0: Attached scsi disk sda | sd 0:0:0:0: Attached scsi generic sg0 type 0 | scsi 1:0:0:0: CD-ROMHP DVD Writer 640c CS30 PQ: 0 ANSI: 5 | sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray | Uniform CD-ROM driver Revision: 3.20 | sr 1:0:0:0: Attached scsi generic sg1 type 5 | scsi 1:0:1:0: CD-ROMSAMSUNG CD-ROM SC-148C B105 PQ: 0 ANSI: 5 | sr1: scsi3-mmc drive: 1x/48x cd/rw xa/form2 cdda tray | sr 1:0:1:0: Attached scsi generic sg2 type 5 stripped config (well, as far of I'm sure it shouldn't matter): | CONFIG_PM=y | CONFIG_PM_LEGACY=y | | CONFIG_ACPI=y | CONFIG_ACPI_PROCFS=y | CONFIG_ACPI_FAN=y | CONFIG_ACPI_PROCESSOR=y | CONFIG_ACPI_THERMAL=y | CONFIG_ACPI_BLACKLIST_YEAR=0 | CONFIG_ACPI_EC=y | CONFIG_ACPI_POWER=y | CONFIG_ACPI_SYSTEM=y | CONFIG_X86_PM_TIMER=y | | CONFIG_PCI=y | CONFIG_PCI_GOANY=y | CONFIG_PCI_BIOS=y | CONFIG_PCI_DIRECT=y | CONFIG_PCI_MMCONFIG=y | CONFIG_PCIEPORTBUS=y | CONFIG_PCIEAER=y | CONFIG_HT_IRQ=y | CONFIG_ISA_DMA_API=y | | CONFIG_PNP=y | | CONFIG_PNPACPI=y | | CONFIG_CDROM_PKTCDVD=y | CONFIG_CDROM_PKTCDVD_BUFFERS=8 | | CONFIG_IDE=y | | CONFIG_RAID_ATTRS=y | CONFIG_SCSI=y | CONFIG_SCSI_PROC_FS=y | | CONFIG_BLK_DEV_SD=y | CONFIG_BLK_DEV_SR=y | CONFIG_CHR_DEV_SG=y | | CONFIG_SCSI_MULTI_LUN=y | CONFIG_SCSI_CONSTANTS=y | CONFIG_SCSI_LOGGING=y | | CONFIG_SCSI_SPI_ATTRS=y | | CONFIG_ATA=y | CONFIG_SATA_AHCI=y | CONFIG_ATA_PIIX=y | CONFIG_SATA_INTEL_COMBINED=y | CONFIG_SATA_ACPI=y | CONFIG_PATA_SERVERWORKS=y lspci: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01) 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2) 02:0c.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) lspci -v -v -v for IDE 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: Dell Unknown device 0142 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 17 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 2: I/O ports at 0170 [size=8]
Re: libata /dev/scd0 problem: mount after burn fails without eject
On 01/05/07, Mark Lord [EMAIL PROTECTED] wrote: Forwarding to linux-scsi and linux-ide mailing lists. Frank van Maarseveen wrote: Tested on 2.6.20.6 and 2.6.21.1 I decided to swich from the old IDE drivers to libata and now there seems to be a little but annoying problem: cannot mount an ISO image after burning it. May 1 14:32:55 kernel: attempt to access beyond end of device May 1 14:32:55 kernel: sr0: rw=0, want=68, limit=4 May 1 14:32:55 kernel: isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 an eject command seems to fix the state of the PATA DVD writer or driver. The problem occurs for burning a CD and for DVD too with identical error messages. relevant kernel boot messages: | ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14 | ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15 | scsi0 : ata_piix | ata1.00: ATA-7: ST3120814A, 3.AAJ, max UDMA/100 | ata1.00: 234441648 sectors, multi 8: LBA48 | ata1.00: configured for UDMA/100 | scsi1 : ata_piix | ata2.00: ATAPI, max UDMA/33 | ata2.01: ATAPI, max UDMA/33 | ata2.00: configured for UDMA/33 | ata2.01: configured for UDMA/33 | scsi 0:0:0:0: Direct-Access ATA ST3120814A 3.AA PQ: 0 ANSI: 5 | SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB) | sda: Write Protect is off | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA | SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB) | sda: Write Protect is off | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA | sda: sda1 sda2 sda4 | sd 0:0:0:0: Attached scsi disk sda | sd 0:0:0:0: Attached scsi generic sg0 type 0 | scsi 1:0:0:0: CD-ROMHP DVD Writer 640c CS30 PQ: 0 ANSI: 5 | sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray | Uniform CD-ROM driver Revision: 3.20 | sr 1:0:0:0: Attached scsi generic sg1 type 5 | scsi 1:0:1:0: CD-ROMSAMSUNG CD-ROM SC-148C B105 PQ: 0 ANSI: 5 | sr1: scsi3-mmc drive: 1x/48x cd/rw xa/form2 cdda tray | sr 1:0:1:0: Attached scsi generic sg2 type 5 stripped config (well, as far of I'm sure it shouldn't matter): | CONFIG_PM=y | CONFIG_PM_LEGACY=y | | CONFIG_ACPI=y | CONFIG_ACPI_PROCFS=y | CONFIG_ACPI_FAN=y | CONFIG_ACPI_PROCESSOR=y | CONFIG_ACPI_THERMAL=y | CONFIG_ACPI_BLACKLIST_YEAR=0 | CONFIG_ACPI_EC=y | CONFIG_ACPI_POWER=y | CONFIG_ACPI_SYSTEM=y | CONFIG_X86_PM_TIMER=y | | CONFIG_PCI=y | CONFIG_PCI_GOANY=y | CONFIG_PCI_BIOS=y | CONFIG_PCI_DIRECT=y | CONFIG_PCI_MMCONFIG=y | CONFIG_PCIEPORTBUS=y | CONFIG_PCIEAER=y | CONFIG_HT_IRQ=y | CONFIG_ISA_DMA_API=y | | CONFIG_PNP=y | | CONFIG_PNPACPI=y | | CONFIG_CDROM_PKTCDVD=y | CONFIG_CDROM_PKTCDVD_BUFFERS=8 | | CONFIG_IDE=y | | CONFIG_RAID_ATTRS=y | CONFIG_SCSI=y | CONFIG_SCSI_PROC_FS=y | | CONFIG_BLK_DEV_SD=y | CONFIG_BLK_DEV_SR=y | CONFIG_CHR_DEV_SG=y | | CONFIG_SCSI_MULTI_LUN=y | CONFIG_SCSI_CONSTANTS=y | CONFIG_SCSI_LOGGING=y | | CONFIG_SCSI_SPI_ATTRS=y | | CONFIG_ATA=y | CONFIG_SATA_AHCI=y | CONFIG_ATA_PIIX=y | CONFIG_SATA_INTEL_COMBINED=y | CONFIG_SATA_ACPI=y | CONFIG_PATA_SERVERWORKS=y lspci: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01) 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2) 02:0c.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) lspci -v -v -v for IDE 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: Dell Unknown device 0142 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to
[PATCH] aacraid: superfluous adapter reset for IBM 8 series ServeRAID controllers
The kexec patch introduced a superfluous (and otherwise inert) reset of some adapters. The register can have a hardware default value that has zeros for the undefined interrupts. This patch refines the test of the interrupt enable register to focus on only the interrupts that affect the driver in order to detect if an incomplete shutdown of the Adapter had occurred (kdump). ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patches. Dynamic fast paced public patches create confusion. This attached patch is against current scsi-misc-2.6 *after* either the aacraid_kexec_5 or the aacraid_kexec_fix patches have propagated. The reason for supplying this patch in this manner is to recognize the lower priority of this patch, the dependence and to survive cleanly the sequencing and the overlap of patch application. James, say the word and I can provide an aacraid_kexec_6 with this rolled in, but my goal is NOT to delay aacraid_kexec_5 (or aacraid_kexec_fix as applied to aacraid_kexec_2 which currently is in scsi-misc-2.6 and 2.6.21-rc6-mm1+) from propagating otherwise. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] --- Sincerely -- Mark Salyzyn -Original Message- From: Darrick J. Wong [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 5:49 PM To: Salyzyn, Mark Cc: linux-scsi@vger.kernel.org; Alexis Bruemmer; Vivek Goyal; Judith Lebzelter Subject: Re: [PATCH] aacraid: Initialize rx/rkt function pointers before calling them Salyzyn, Mark wrote: As an option for a patch (later), what was the actual value of the Munit.OIMR register (on the x3550 and the x3650 please, just in case)? 0xF. --D aacraid_aurora.patch Description: aacraid_aurora.patch
Re: Kernel crash with AIC94xx (one step forward, hope it's lucky)
Constantin Teodorescu wrote: 03:02:15 kernel: [ cut here ] 03:02:15 kernel: kernel BUG at drivers/scsi/aic94xx/aic94xx_hwi.h:354! On the odd chance you still have this controller (and have the time to test out patches), would you mind applying this patch: http://sweaglesw.net/~djwong/docs/17-aic94xx-hwi-bugon_1.patch and reporting back to me what happens? --D - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] aacraid: superfluous adapter reset for IBM 8 series ServeRAID controllers
Salyzyn, Mark wrote: The kexec patch introduced a superfluous (and otherwise inert) reset of some adapters. The register can have a hardware default value that has zeros for the undefined interrupts. This patch refines the test of the interrupt enable register to focus on only the interrupts that affect the driver in order to detect if an incomplete shutdown of the Adapter had occurred (kdump). Tests out ok on the affected machines, so: Acked-by: Darrick J. Wong [EMAIL PROTECTED] --D - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/scsi/pci2000.h: Remove unused file
Remove the unused header drivers/scsi/pci2000.h Signed-off-by: Richard Knutsson [EMAIL PROTECTED] --- 'grep -nr pci2000' on the whole tree results only in a reference to pci2000.h Diffed against Linus' git-tree. diff --git a/drivers/scsi/pci2000.h b/drivers/scsi/pci2000.h deleted file mode 100644 index 0ebd8ce..000 --- a/drivers/scsi/pci2000.h +++ /dev/null @@ -1,197 +0,0 @@ -/ - * Perceptive Solutions, Inc. PCI-2000 device driver for Linux. - * - * pci2000.h - Linux Host Driver for PCI-2000 IntelliCache SCSI Adapters - * - * Copyright (c) 1997-1999 Perceptive Solutions, Inc. - * All Rights Reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that redistributions of source - * code retain the above copyright notice and this comment without - * modification. - * - * Technical updates and product information at: - * http://www.psidisk.com - * - * Please send questions, comments, bug reports to: - * [EMAIL PROTECTED] Technical Support - * - / -#ifndef _PCI2000_H -#define _PCI2000_H - -#include linux/types.h - -#ifndefPSI_EIDE_SCSIOP -#definePSI_EIDE_SCSIOP 1 - -#defineLINUXVERSION(v,p,s)(((v)16) + ((p)8) + (s)) - -// -/* definition of standard data types */ -// -#defineCHARchar -#defineUCHAR unsigned char -#defineSHORT short -#defineUSHORT unsigned short -#defineBOOLlong -#defineLONGlong -#defineULONG unsigned long -#defineVOIDvoid - -typedefCHAR*PCHAR; -typedefUCHAR *PUCHAR; -typedefSHORT *PSHORT; -typedefUSHORT *PUSHORT; -typedefBOOL*PBOOL; -typedefLONG*PLONG; -typedefULONG *PULONG; -typedefVOID*PVOID; - - -// -/* Misc. macros */ -// -#define ANY2SCSI(up, p)\ -((UCHAR *)up)[0] = (((ULONG)(p)) 8);\ -((UCHAR *)up)[1] = ((ULONG)(p)); - -#define SCSI2LONG(up) \ -( (((long)*(((UCHAR *)up))) 16) \ -+ (((long)(((UCHAR *)up)[1])) 8)\ -+ ((long)(((UCHAR *)up)[2])) ) - -#define XANY2SCSI(up, p) \ -((UCHAR *)up)[0] = ((long)(p)) 24; \ -((UCHAR *)up)[1] = ((long)(p)) 16; \ -((UCHAR *)up)[2] = ((long)(p)) 8; \ -((UCHAR *)up)[3] = ((long)(p)); - -#define XSCSI2LONG(up) \ -( (((long)(((UCHAR *)up)[0])) 24) \ -+ (((long)(((UCHAR *)up)[1])) 16) \ -+ (((long)(((UCHAR *)up)[2])) 8) \ -+ ((long)(((UCHAR *)up)[3])) ) - -// -/* SCSI CDB operation codes*/ -// -#define SCSIOP_TEST_UNIT_READY 0x00 -#define SCSIOP_REZERO_UNIT 0x01 -#define SCSIOP_REWIND 0x01 -#define SCSIOP_REQUEST_BLOCK_ADDR 0x02 -#define SCSIOP_REQUEST_SENSE 0x03 -#define SCSIOP_FORMAT_UNIT 0x04 -#define SCSIOP_READ_BLOCK_LIMITS 0x05 -#define SCSIOP_REASSIGN_BLOCKS 0x07 -#define SCSIOP_READ6 0x08 -#define SCSIOP_RECEIVE 0x08 -#define SCSIOP_WRITE6 0x0A -#define SCSIOP_PRINT 0x0A -#define SCSIOP_SEND0x0A -#define SCSIOP_SEEK6 0x0B -#define SCSIOP_TRACK_SELECT0x0B -#define SCSIOP_SLEW_PRINT 0x0B -#define SCSIOP_SEEK_BLOCK 0x0C -#define SCSIOP_PARTITION 0x0D -#define SCSIOP_READ_REVERSE0x0F -#define SCSIOP_WRITE_FILEMARKS 0x10 -#define SCSIOP_FLUSH_BUFFER0x10 -#define SCSIOP_SPACE 0x11 -#define SCSIOP_INQUIRY 0x12 -#define SCSIOP_VERIFY6 0x13 -#define SCSIOP_RECOVER_BUF_DATA0x14 -#define SCSIOP_MODE_SELECT 0x15 -#define SCSIOP_RESERVE_UNIT0x16 -#define SCSIOP_RELEASE_UNIT0x17 -#define SCSIOP_COPY0x18 -#define SCSIOP_ERASE 0x19 -#define SCSIOP_MODE_SENSE 0x1A -#define SCSIOP_START_STOP_UNIT 0x1B -#define SCSIOP_STOP_PRINT 0x1B -#define SCSIOP_LOAD_UNLOAD 0x1B -#define
Re: [PATCH] drivers/scsi/pci2000.h: Remove unused file
On Tue, 1 May 2007, Richard Knutsson wrote: Remove the unused header drivers/scsi/pci2000.h i have the same patch in my pending patch directory, dated march 10, so i know i submitted it, but i have no idea whatever happened to it. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] bidi support: bidirectional request
Jens Axboe wrote: On Mon, Apr 30 2007, Douglas Gilbert wrote: Jens Axboe wrote: On Mon, Apr 30 2007, Benny Halevy wrote: Jens Axboe wrote: On Sun, Apr 29 2007, James Bottomley wrote: I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS). bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them). So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req-special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests. I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload -special for 2nd bio list. So basically just add a struct request pointer, so you can do rq = rq-next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it. And it should definitely be a request type. I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along). It still has to be implemented natively at the block layer, just differently like described above. So instead of messing all over the block layer adding rq_uni() stuff, just add that struct request pointer to the request structure for the 2nd data phase. You can relatively easy then modify the block layer helpers to support mapping and setup of such requests. Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list). The SCSI part is up to James, that can be done as either inside a single scsi command, or as linked scsi commands as well. I don't care too much about that bit, just the block layer parts :-). And the proposed block layer design can be used both ways by the scsi layer. Linked SCSI commands have been obsolete since SPC-4 rev 6 (18 July 2006) after proposal 06-259r1 was accepted. That proposal starts: The reasons for linked commands have been overtaken by time and events. I haven't see anyone mourning their demise on the t10 reflector. This has nothing to do with linked commands as defined in the SCSI spec. Mapping two requests to one bidi SCSI command might make error handling more of a challenge. Then go the other way, a command for each. Not a big deal. Hi Jens, James, Thanks for your response! Please consider the attached proposal. It is a complete block-level bidi implementation that is, I hope, a middle ground which will keep everyone happy (including Christoph). It is both quite small and not invasive, yet has a full bidi API that is easy to use and maintain. The patches take into account Douglas concern as well as Jens's and James. 1. Flags and direction are kept the same as before. I have only shifted them around a bit so they can work with bidi semantics as well. It is more of a necessary cleanup of weak code. (Patches 1 2). Thanks for the offer of a use of a new REQ_TYPE_XXX, but, as you can see below, it is not needed and bidi can safely be handled by the REQ_TYPE_BLOCK_PC paths. 2. C language has, what are called, nameless struct and union. I have used it to enable the same bidi approach as before but in a way that is absolutely backward code compatible. So the huge patch#3 has Just disappeared. The BIDI API is then implemented, considering the first and second adjustments, in a much similar way as before.
Re: BAD_SG_DMA panic in aha1542
Alan Cox wrote:
The one I sent has a memory leak but it won't matter for basic testing.
Or you can change the final bit to
scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);
if (zebedee != cgc-buffer) {
if (cgc-data_direction == DMA_FROM_DEVICE)
memcpy(cgc-buffer, zebedee, cgc-buflen);
kfree(zebedee); /* Time for bed */
}
I changed it, because I'll be living with this for a while I'd bet...
Works fine. No more BAD_SG_DMA() calls. Thanks!
--
---
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/scsi/pci2000.h: Remove unused file
On Tue, 2007-05-01 at 14:16 -0400, Robert P. J. Day wrote: On Tue, 1 May 2007, Richard Knutsson wrote: Remove the unused header drivers/scsi/pci2000.h i have the same patch in my pending patch directory, dated march 10, so i know i submitted it, but i have no idea whatever happened to it. It's in -mm via this, pending merge with linus: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=38891cb6b0de3f5986e6a7688c5ae17c18b000a9 James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] bidi support: bidirectional request
On Tue, May 01 2007, Boaz Harrosh wrote: Please consider the attached proposal. It is a complete block-level bidi implementation that is, I hope, a middle ground which will keep everyone happy (including Christoph). It is both quite small and not invasive, yet has a full bidi API that is easy to use and maintain. This isn't much of an improvement imo, if any at all. Why didn't you do the -next_rq approach I suggested? Your patch still makes struct request considerably fatter (30% here, from 280 to 368 bytes on x86-64 from a quick look) for something that will have relatively few uses. And it still has its paws all over the block layer code. Please just implement the 2nd data phase as a linked request off the first one. I think that approach is both much cleaner from a design perspective, and also much leaner and has zero (well almost, it costs a pointer) impact on the regular read-write paths. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] bidi support: bidirectional request
From: Jens Axboe [EMAIL PROTECTED] Subject: Re: [PATCH 4/4] bidi support: bidirectional request Date: Tue, 1 May 2007 20:57:20 +0200 On Tue, May 01 2007, Boaz Harrosh wrote: Please consider the attached proposal. It is a complete block-level bidi implementation that is, I hope, a middle ground which will keep everyone happy (including Christoph). It is both quite small and not invasive, yet has a full bidi API that is easy to use and maintain. This isn't much of an improvement imo, if any at all. Why didn't you do the -next_rq approach I suggested? Your patch still makes struct request considerably fatter (30% here, from 280 to 368 bytes on x86-64 from a quick look) for something that will have relatively few uses. And it still has its paws all over the block layer code. Please just implement the 2nd data phase as a linked request off the first one. I think that approach is both much cleaner from a design perspective, and also much leaner and has zero (well almost, it costs a pointer) impact on the regular read-write paths. I will send a next_rq patch shortly. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/scsi/pci2000.h: Remove unused file
James Bottomley wrote: On Tue, 2007-05-01 at 14:16 -0400, Robert P. J. Day wrote: On Tue, 1 May 2007, Richard Knutsson wrote: Remove the unused header drivers/scsi/pci2000.h i have the same patch in my pending patch directory, dated march 10, so i know i submitted it, but i have no idea whatever happened to it. It's in -mm via this, pending merge with linus: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=38891cb6b0de3f5986e6a7688c5ae17c18b000a9 Ok, thanks. Richard Knutsson - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] bidi support: bidirectional request
From: Jens Axboe [EMAIL PROTECTED]
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Mon, 30 Apr 2007 13:11:57 +0200
On Sun, Apr 29 2007, James Bottomley wrote:
On Sun, 2007-04-29 at 18:48 +0300, Boaz Harrosh wrote:
FUJITA Tomonori wrote:
From: Boaz Harrosh [EMAIL PROTECTED]
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 645d24b..16a02ee 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -322,6 +322,7 @@ struct request {
void *end_io_data;
struct request_io_part uni;
+struct request_io_part bidi_read;
};
Would be more straightforward to have:
struct request_io_part in;
struct request_io_part out;
Yes I wish I could do that. For bidi supporting drivers this is the most
logical.
But for the 99.9% of uni-directional drivers, calling rq_uni(), and being
some what on
the hotish paths, this means we will need a pointer to a uni
request_io_part.
This is bad because:
1st- There is no defined stage in a request life where to definitely set
that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all.
Now this is a
very bad spot already, and I have a short term fix for it in the
SCSI-bidi patches
(not sent yet) but a more long term solution is needed. Once such
hacks are
cleaned up we can do what you say. This is exactly why I use the
access functions
rq_uni/rq_io/rq_in/rq_out and not open code access.
I'm still not really convinced about this approach. The primary job of
the block layer is to manage and merge READ and WRITE requests. It
serves a beautiful secondary function of queueing for arbitrary requests
it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or
indeed any non REQ_TYPE_FS).
bidirectional requests fall into the latter category (there's nothing
really we can do to merge them ... they're just transported by the block
layer). The only unusual feature is that they carry two bios. I think
the drivers that actually support bidirectional will be a rarity, so it
might even be advisable to add it to the queue capability (refuse
bidirectional requests at the top rather than perturbing all the drivers
to process them).
So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will
remove it from the standard path and put it on the special command type
path where we can process it specially. Additionally, if you take this
approach, you can probably simply chain the second bio through
req-special as an additional request in the stream. The only thing
that would then need modification would be the dequeue of the block
driver (it would have to dequeue both requests and prepare them) and
that needs to be done only for drivers handling bidirectional requests.
I agree, I'm really not crazy about shuffling the entire request setup
around just for something as exotic as bidirection commands. How about
just keeping it simple - have a second request linked off the first one
for the second data phase? So keep it completely seperate, not just
overload -special for 2nd bio list.
So basically just add a struct request pointer, so you can do rq =
rq-next_rq or something for the next data phase. I bet this would be a
LOT less invasive as well, and we can get by with a few helpers to
support it.
This patch tried this approach. It's just for seeing how it works.
I added bidi support to open-iscsi and bsg and tested this patch
lightly. I've attached only a patch for the block layer and scsl-ml.
You can get all the patches are:
http://www.kernel.org/pub/linux/kernel/people/tomo/bidi
If we go with this approach, we need just minor changes to the block
layer. The overloading rq-special approach needs more but it's
reasonable too.
I need to add the proper error handling code, which might be a bit
tricky, but I think that it will not be so complicated.
And it should definitely be a request type.
I'm not sure about this. I think that bidi can't be a request type to
trace bidi pc requests (we have bidi special requests like SMP). I use
REQ_BIDI though I've not implemented bidi trace code.
From 7d278323ff8aad86fb82c823538f7ddfb6ded11c Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Wed, 2 May 2007 03:55:56 +0900
Subject: [PATCH] add bidi support
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
block/ll_rw_blk.c|1 +
drivers/scsi/scsi_lib.c | 72 +++---
include/linux/blkdev.h |7
include/scsi/scsi_cmnd.h |9 ++
4 files changed, 78 insertions(+), 11 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index cf8752a..82842d6
Re: [PATCH] aacraid: fails to initialize after a kexec operation
On Mon, Apr 30, 2007 at 10:11:03AM -0400, Salyzyn, Mark wrote: Foreign arrays are arrays configured on another adapter then moved over to the current host adapter. I do not know why this may be the case in your situation, but it had the smell of behaving like a foreign array and thus my suggestion. We use commit=1 for all situations where the importation of an array is not considered an error and there is no BIOS to intervene prior to driver load. Typically we advise to set this flag in embedded systems, or in non-Intel based architectures. Normally on Intel based systems you get a query from the card's BIOS as you boot that queries the user (to answer yes) to accept the array configuration should it be detected as foreign. I see some problems with declaring aacraid.commit=1 for kdump, you are changing the storage system conditions and the fact you have a foreign array may have been the cause of the primary kernel's failure. You are rubbing out a factor in the system's failure? I would also hate to store a kernel dump over an array one does not know the status or origin of. Hi Mark, How does one find from BIOS if array is local or foreign? In this machine I have not done any migration. I have not even configured the array. I think I am using default factory settings. If I get into the controller BIOS and query arrays, it shows me one array of type Volume. So if an adapter is managing both local and foreign arrays, it would online local one upon reset but offline foreign one. So we can continue to save dump? By the way, when you say that foreign arrays are configured on another adapter and then moved to current host adapter. Once the movement is complete (I am assuming it will happen in first kernel) then what's the issue with saving dump on foreign array. I think if applications are actively using the disks behind foreign array, then it should not be unreliable to save dump on those disks? If there is a clean shutdown, and there are no outstanding commands from the OS (including the ioctl, so make sure the management software commands are shut down), I do not see a reason to reset the adapter. In case of normal kexec (not kdump) clean shutdown takes place. All filesystems are unmounted, processes stopped and from kernel we call device_shutdown() which should shutdown the device no pending interrupt. I am wondering why it does not happen in case of aacraid and we end up restarting adapter even in case of clean shutdown using kexec. I agree, the irqpoll is troublesome! Could something else in the kexec kernel be catching the interrupts and dropping them on the floor? Are there any other devices sharing that same interrupt line that may be holding the interrupt asserted? /proc/irq/*, /proc/interrupts? By routing, I did not make it clear, but there is more than just the PCI hardware in control of the path of an Interrupt from the controller hardware to the interrupt service routine ... this may not be a pure issue with PCI configuration being corrupted. I will look more into it. Thanks Vivek - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
