Re: mac_scsi boot crash, was Re: [PATCH] m68k link error and NCR5380_exit()
On Wed, Mar 09, 2005 at 02:16:45AM +1100, Finn Thain wrote: > That seems to have helped. It still crashes with the same bus error, but > the preceding issue/disconnect/abort cycle is gone now. Log is below. > Hopefully I'll get a chance to look at the bus error soon. I notice it got through all the device identify stuff. It dies as soon as it actually tries to tranfer a real block of data (the partition map) and do something useful with it. Could you see if disabling PDMA helps? There's a way to do it with the command line, but that is messy. If you don't mind recompiling, just set the FLAG_NO_PSEUDO_DMA flag like it always does for the IIfx case. The performance will be terrible, but it might help narrow down the problem. Brad Boyer [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: mac_scsi boot crash, was Re: [PATCH] m68k link error and NCR5380_exit()
On Mon, 7 Mar 2005, Kenn Humborg wrote: > On Mon, Mar 07, 2005 at 09:53:22AM -0800, Brad Boyer wrote: > > ... > > Looks to me like the interrupt came in after the driver already > > decided to give up for some reason. I had a big problem with that > > while I was trying to fix the driver to use DMA on the IIfx. I never > > did get it to give me the interrupt for dma completion before the scsi > > mid layer timed out. > > It broke in 2.6.9 for us Linux/VAX guys. > > Try the NCR5380_set_timer() change from this patch: > >http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg01499.html That seems to have helped. It still crashes with the same bus error, but the preceding issue/disconnect/abort cycle is gone now. Log is below. Hopefully I'll get a chance to look at the bus error soon. BTW, I found your patch is available here intact, http://article.gmane.org/gmane.linux.scsi/14617/raw Thanks for your help. -f Linux version 2.6.10-m68k ([EMAIL PROTECTED]) (gcc version 3.4.3) #20 Wed Mar 9 01:42:11 EST 2005 Detected Macintosh model: 27 Penguin bootinfo data: Video: addr 0x60b0 row 0x280 depth 8 dimensions 640 x 480 Videological 0xf030 phys. 0x60b0, SCC at 0x50f04000 Boottime: 0xe7c4e54a GMTBias: 0x0 Machine ID: 27 CPUid: 0x1 memory size: 0x8 VIA1 at 50f0 is a 6522 or clone VIA2 at 50f26000 is an RBV Apple Macintosh LC III On node 0 totalpages: 2048 DMA zone: 2048 pages, LIFO batch:1 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: ro root=/dev/sdb4 init=/boot.sh debug debug=ser console=tty0 Killing onboard sonic... Done. PID hash table entries: 64 (order: 6, 1024 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory: 5788k/8192k available (1736k kernel code, 528k data, 116k init) Calibrating delay loop... 6.11 BogoMIPS (lpj=30592) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) NET: Registered protocol family 16 NuBus: Scanning NuBus slots. SCSI subsystem initialized audit: initializing netlink socket (disabled) audit(0.860:0): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API macfb: framebuffer at 0x60b0, mapped to 0xd000, size 300k macfb: mode is 640x480x8, linelength=640 macfb: scrolling: redraw fbcon_startup: No VBL detected, using timer based cursor. mac_delete_irq: tried to remove invalid irq Console: switching to colour frame buffer device 80x30 fb0: Macintosh Sonora built-in frame buffer device io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx Macintosh SCSI: resetting the SCSI bus...<6> done scsi0: generic 5380 at port 50F1 irq<6> 19<6> options CAN_QUEUE=16 CMD_PER_LUN=2 release=2<6> scsi0: generic options AUTOSENSE PSEUDO DMA USLEEP, USLEEP_POLL=20 USLEEP_SLEEP=2 generic release=7 scsi0 : elevator: using anticipatory as default io scheduler blk_queue_max_hw_segments: set to minimum 1 Vendor: QUANTUM Model: CTS80SRev: 4.2 Type: Direct-Access ANSI SCSI revision: 02 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 Vendor: CONNERModel: CP30540 SUN0535 Rev: B0CD Type: Direct-Access ANSI SCSI revision: 02 blk_queue_max_hw_segments: set to minimum 1 SCSI device sda: 166200 512-byte hdwr sectors (85 MB) SCSI device sda: drive cache: write through SCSI device sda: 166200 512-byte hdwr sectors (85 MB) SCSI device sda: drive cache: write through sda:Data read fault at 0x667a26b9 in Super Data (pc=0x114cec) BAD KERNEL BUSERR Oops: Modules linked in: PC: [<00114cec>] macscsi_intr+0x1a/0x74 SR: 2700 SP: 00239e74 a2: 001b34cc d0: 00232100d1: 0100d2: 00232100d3: d4: 0001d5: 0013a0: 667a2669a1: 50f26000 Process swapper (pid: 0, stackpage=001b44cc) Stack from 00239e74: 0100 00232100 0001 0013 667a2669 50f26000 001b34cc 00232100 2711 4cecb008 0eec0755 120049c1 667a26b9 667a26b9 2100 10280050 00114cf4 00114cf2 00114cf0 667a26ff 00500064 000ff487 0001 3c18 8008 667a26b9 001f3208 00114ce8 00232200 0013 0013 0013 001f32d0 00239f74 7d30 0013 00114cd2 00239f74 0023a008 0008 1c13 2000 Call Trace: [<8eb8>] via2_irq+0x6e/0x96
Re: [PATCH] m68k link error and NCR5380_exit()
On Mon, Mar 07, 2005 at 09:53:22AM -0800, Brad Boyer wrote: > On Tue, Mar 08, 2005 at 12:45:28AM +1100, Finn Thain wrote: > > My main reservation about embarking on this is that I don't think mac_scsi > > ever actually worked under 2.6 (or 2.5?) kernels. I'm not competent enough > > to submit a good, untested patch for a broken driver. Maybe the best thing > > is to make it work before worrying about style. At least then I can test > > my work. > > I certainly never got it to work, but I only tried on my IIfx which > doesn't have exactly the same version of the chip anyway. > > > To that end, I've included a boot log below. Maybe someone familiar with > > the NCR5380 driver can make some sense of the failure? > > Looks to me like the interrupt came in after the driver already > decided to give up for some reason. I had a big problem with that > while I was trying to fix the driver to use DMA on the IIfx. I > never did get it to give me the interrupt for dma completion > before the scsi mid layer timed out. It broke in 2.6.9 for us Linux/VAX guys. Try the NCR5380_set_timer() change from this patch: http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg01499.html Later, Kenn - 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] m68k link error and NCR5380_exit()
On Tue, Mar 08, 2005 at 12:45:28AM +1100, Finn Thain wrote: > Having qla1280.c as a guide will help, thanks. My next question is, what > does a NuBus architecture do in place of pci_(un)register_driver? Eventually, you should use macio_(un)register_driver. However, I don't have the support quite finished for mac68k. If I get some time to work on it, I have most of the code written. It's close enough that it should work on nubus-pmac, and I passed some preliminary versions of the code off to them. > My main reservation about embarking on this is that I don't think mac_scsi > ever actually worked under 2.6 (or 2.5?) kernels. I'm not competent enough > to submit a good, untested patch for a broken driver. Maybe the best thing > is to make it work before worrying about style. At least then I can test > my work. I certainly never got it to work, but I only tried on my IIfx which doesn't have exactly the same version of the chip anyway. > To that end, I've included a boot log below. Maybe someone familiar with > the NCR5380 driver can make some sense of the failure? Looks to me like the interrupt came in after the driver already decided to give up for some reason. I had a big problem with that while I was trying to fix the driver to use DMA on the IIfx. I never did get it to give me the interrupt for dma completion before the scsi mid layer timed out. Brad Boyer [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] m68k link error and NCR5380_exit()
On Mon, 7 Mar 2005, Christoph Hellwig wrote: > > .detect = macscsi_detect, > > - .release= macscsi_release, > > + .release= __exit_p(macscsi_release), > > Please get rid of your ->detect/->release useage instead. Allocate the > host struct directly with scsi_host_alloc and add it when setup using > scsi_add_host/scsi_scan_host in your init routine and call > scsi_remove_host/ scsi_host_put in the module exit routine. Fair enough, I just noticed that scsi_module.c is deprecated. My patch is flogging a dead horse. I guess that those who require the legacy NCR5380 drivers (being mac_scsi.c, dtc.c, t128.c, pas16.c and g_NCR5380.c) can use CONFIG_HOTPLUG to avoid the problem. > see qla1280.c for an example that does this for the 2.6 case and to ease > your porting also has the 2.4 code ifdefed so you have the direct > comparism. Having qla1280.c as a guide will help, thanks. My next question is, what does a NuBus architecture do in place of pci_(un)register_driver? My main reservation about embarking on this is that I don't think mac_scsi ever actually worked under 2.6 (or 2.5?) kernels. I'm not competent enough to submit a good, untested patch for a broken driver. Maybe the best thing is to make it work before worrying about style. At least then I can test my work. To that end, I've included a boot log below. Maybe someone familiar with the NCR5380 driver can make some sense of the failure? -f Linux version 2.6.10-m68k ([EMAIL PROTECTED]) (gcc version 3.4.3) #6 Fri Mar 11 09:10:02 EST 2005 Detected Macintosh model: 27 Penguin bootinfo data: Video: addr 0x60b0 row 0x280 depth 8 dimensions 640 x 480 Videological 0xf030 phys. 0x60b0, SCC at 0x50f04000 Boottime: 0xe7bb738f GMTBias: 0x0 Machine ID: 27 CPUid: 0x1 memory size: 0x8 VIA1 at 50f0 is a 6522 or clone VIA2 at 50f26000 is an RBV Apple Macintosh LC III On node 0 totalpages: 2048 DMA zone: 2048 pages, LIFO batch:1 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: ro root=/dev/sdb4 init=/boot.sh debug debug=ser console=tty0 Killing onboard sonic... Done. PID hash table entries: 64 (order: 6, 1024 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory: 5452k/8192k available (2028k kernel code, 568k data, 120k init) Calibrating delay loop... 6.11 BogoMIPS (lpj=30592) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) NET: Registered protocol family 16 NuBus: Scanning NuBus slots. SCSI subsystem initialized audit: initializing netlink socket (disabled) audit(0.860:0): initialized macfb: framebuffer at 0x60b0, mapped to 0xd000, size 300k macfb: mode is 640x480x8, linelength=640 macfb: scrolling: redraw fbcon_startup: No VBL detected, using timer based cursor. mac_delete_irq: tried to remove invalid irq Console: switching to colour frame buffer device 80x30 fb0: Macintosh Sonora built-in frame buffer device io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx Macintosh SCSI: resetting the SCSI bus...<6> done scsi0: generic 5380 at port 50F1 irq<6> 19<6> options CAN_QUEUE=16 CMD_PER_LUN=2 release=2<6> scsi0: generic options AUTOSENSE PSEUDO DMA USLEEP, USLEEP_POLL=20 USLEEP_SLEEP=2 generic release=7 scsi0 : elevator: using anticipatory as default io scheduler blk_queue_max_hw_segments: set to minimum 1 Vendor: QUANTUM Model: CTS80SRev: 4.2 Type: Direct-Access ANSI SCSI revision: 02 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 blk_queue_max_hw_segments: set to minimum 1 Vendor: CONNERModel: CP30540 SUN0535 Rev: B0CD Type: Direct-Access ANSI SCSI revision: 02 blk_queue_max_hw_segments: set to minimum 1 SCSI device sda: 166200 512-byte hdwr sectors (85 MB) scsi0 : aborting command scsi0 : destination target 0, lun 0 command = Mode Sense 00 08 00 20 00 NCR5380 core release=7. Base Addr: 0x0io_port: 50f1 IRQ: 19. scsi0 : destination target 0, lun 0 command = 26 (0x1a)00 08 00 20 00 scsi0: issue_queue scsi0: disconnected_queue scsi0 : aborting command scsi0 : destination target 0, lun 0 command = Mode Sense 00 08 00 20 00 NCR5380 core release=7. Base Addr: 0x0io_port: 50f1 IRQ: 19. scsi0 : destination target 0, lun 0 command = 26 (0x1a)00 08 00 20 00 scsi0: issue_queue scsi0: disconnected_queue NCR5380 core release=7. Base Addr: 0x00
Re: [PATCH] m68k link error and NCR5380_exit()
> .detect = macscsi_detect, > - .release= macscsi_release, > + .release= __exit_p(macscsi_release), Please get rid of your ->detect/->release useage instead. Allocate the host struct directly with scsi_host_alloc and add it when setup using scsi_add_host/scsi_scan_host in your init routine and call scsi_remove_host/ scsi_host_put in the module exit routine. see qla1280.c for an example that does this for the 2.6 case and to ease your porting also has the 2.4 code ifdefed so you have the direct comparism. - 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
