* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
@ 2004-04-14 19:32 Andy Walker
2004-04-14 20:52 ` Joel Soete
0 siblings, 1 reply; 17+ messages in thread
From: Andy Walker @ 2004-04-14 19:32 UTC (permalink / raw)
To: parisc-linux
Joel Soete wrote:
> That said, I am not able to link jejb with what I observe but here is
> the story.
> The system boot but hang very quickly as soon as io rate increase as per
> a find of a file name :( (reproducible on request)
> I then get mesg
>
> arq->state 2
> Badness in as_requeue_request at drivers/block/as-iosched.c:1479
> Kernel addresses on the stack:
> [snip]
> [<10124528>] printk+0x144/0x1c0
> [<101036bc>] dump_stack+0x18/0x24
> [<102276a0>] as_requeue_request+0x5c/0x17c
> [<1021e630>] elv_requeue_request+0x30/0x3c
> [<1023baf4>] scsi_request_fn+0x220/0x2bc
> [<1021e630>] elv_requeue_request+0x30/0x3c
> [<102212b8>] blk_insert_request+0xd8/0xf0
> [<1023a978>] scsi_queue_insert+0x6c/0xa0
> [<1023b7bc>] scsi_prep_fn+0xc4/0x1dc
> [<102368f8>] scsi_dispatch_cmd+0x118/0x22c
> [<1021e820>] elv_remove_request+0x34/0x44
> [<1023ba80>] scsi_request_fn+0x1ac/0x2bc
> [<102273f0>] as_next_request+0x44/0x54
> [<10228218>] as_work_handler+0x44/0x48
> [<101344e4>] worker_thread+0x1e4/0x280
> [<101200cc>] schedule+0x3f8/0x718
> [<101385f4>] kthread+0xdc/0xe4
> [<10108c5c>] ret_from_kernel_thread+0x1c/0x24
>
> [snip]
>
> it seems to be infinite loop :(
>
> Any idea?
>
> Thanks in advance,
> Joel
I'm experiencing a very similar problem with 2.6.5-pa7 on a C180. I'm in
unfortunate position that my ext3 root filesystem needs INFO recovery,
but as soon as the recovery kicks in I get:
arq->state 2
Badness in as_requeue_request at drivers/block/as-iosched.c:1479
Kernel addresses on the stack:
[snip]
[<10125d0c>] printk+0x188/0x1c8
[<10105638>] dump_stack+0x18/0x24
[<101fb740>] as_requeue_request+0x64/0x10c
[<101f24b0>] elv_requeue_request+0x2c/0x38
[<101f51b4>] blk_insert_request+0xf4/0xfc
[<10211c2c>] scsi_queue_insert+0x68/0x9c
[<102376f4>] hp_sdc_tasklet+0x80/0x160
[<1020dd2c>] scsi_softirq+0xfc/0x11c
[<10129990>] do_softirq+0xf4/0xf8
[<10129e68>] ksoftirqd+0x84/0xf0
[<101398a0>] kthread+0xe8/0xf0
[<1010ac5c>] ret_from_kernel_thread+0x1c/0x24
Can't point to the last kernel version that worked, because this is
actually the first kernel I've built for the C180, having just
finished bootstrapping Gentoo. But I'll be happy to provide what
info I can - seems this problem is real if both a C110 and a C180
are suffering from it, and they're very similar pieces of hardware.
cheers
-Andy
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( 2004-04-14 19:32 [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( Andy Walker @ 2004-04-14 20:52 ` Joel Soete 2004-04-15 7:05 ` Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-14 20:52 UTC (permalink / raw) To: Andy Walker; +Cc: parisc-linux Andy, Many Thanks you save my mind: I was becoming crazy ;) That said, thanks to viewcvs, cvs and some tbz I recover from my systems, I reach to rebuild on my b2k at the office: 2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a tar of one of those tree) survive :) 2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :) but 2.6.4-rc4-pa6 died with same messages. and too bad after such crash not more possible to reboot even with 2.6.4-rc1-pa3 which panic: [snip] EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 520k freed Stack Dump: 10380418: 10380418 00048308 00000040 ffe01800 10380408: ffe01801 1046f010 10380080 003803b8 [snip] 10380038: 00000000 00000000 00000000 00000000 10380028: 00000000 00000000 00000000 00000000 Kernel addresses on the stack: [<10125aec>] call_console_drivers+0xd0/0x17c [<10106020>] parisc_terminate+0x60/0xb8 [<10111cd0>] pdc_console_restart+0x4c/0x68 [<101061bc>] handle_interruption+0x144/0x5b0 [<1010b088>] intr_check_sig+0x0/0xc [<1025e5bc>] ncr_reset_scsi_bus+0x158/0x2b8 High Priority Machine Check (HPMC): Code=1 regs=10380080 (Addr=00000000) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111100100001110 Not tainted r00-03 00000000 103a5010 1025e4b8 0000000f r04-07 17edeba0 17ec0000 00000002 103a5010 r08-11 00000000 17ec4110 b6da8c80 1046e060 r12-15 100fe244 00000000 10394010 1046e010 r16-19 f00010f4 f00000ac f00000a4 f3f8c80e r20-23 00000001 0000000f 0000000e 1046d010 r24-27 17ec0000 00000000 0000c800 1037d010 r28-31 f3f8c800 00005dc0 17ec4380 1025e57c sr0-3 00000000 00000003 00000000 00000003 sr4-7 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: 1025e5b8 1025e5bc IIR: d6c30a3f ISR: 00000000 IOR: f3f8c80c CPU: 0 CR30: 17ec4000 CR31: 103dc000 ORIG_R28: 00000000 IAOQ[0]: ncr_reset_scsi_bus+0x154/0x2b8 IAOQ[1]: ncr_reset_scsi_bus+0x158/0x2b8 RP(r2): ncr_reset_scsi_bus+0x54/0x2b8 (already retry 2 time even after a cycle power off/on? and now with 2.6.3-pa2 up again pfff) I can still restric research between 2.6.4-rc3-pa3 (which I missed in my investigation?) and 2.6.4-rc4-pa6? hth, Joel Andy Walker wrote: > Joel Soete wrote: > > >>That said, I am not able to link jejb with what I observe but here is >>the story. >>The system boot but hang very quickly as soon as io rate increase as per >>a find of a file name :( (reproducible on request) >>I then get mesg >> >>arq->state 2 >>Badness in as_requeue_request at drivers/block/as-iosched.c:1479 >>Kernel addresses on the stack: >>[snip] >> [<10124528>] printk+0x144/0x1c0 >> [<101036bc>] dump_stack+0x18/0x24 >> [<102276a0>] as_requeue_request+0x5c/0x17c >> [<1021e630>] elv_requeue_request+0x30/0x3c >> [<1023baf4>] scsi_request_fn+0x220/0x2bc >> [<1021e630>] elv_requeue_request+0x30/0x3c >> [<102212b8>] blk_insert_request+0xd8/0xf0 >> [<1023a978>] scsi_queue_insert+0x6c/0xa0 >> [<1023b7bc>] scsi_prep_fn+0xc4/0x1dc >> [<102368f8>] scsi_dispatch_cmd+0x118/0x22c >> [<1021e820>] elv_remove_request+0x34/0x44 >> [<1023ba80>] scsi_request_fn+0x1ac/0x2bc >> [<102273f0>] as_next_request+0x44/0x54 >> [<10228218>] as_work_handler+0x44/0x48 >> [<101344e4>] worker_thread+0x1e4/0x280 >> [<101200cc>] schedule+0x3f8/0x718 >> [<101385f4>] kthread+0xdc/0xe4 >> [<10108c5c>] ret_from_kernel_thread+0x1c/0x24 >> >>[snip] >> >>it seems to be infinite loop :( >> >>Any idea? >> >>Thanks in advance, >> Joel > > > I'm experiencing a very similar problem with 2.6.5-pa7 on a C180. I'm in > unfortunate position that my ext3 root filesystem needs INFO recovery, > but as soon as the recovery kicks in I get: > > arq->state 2 > Badness in as_requeue_request at drivers/block/as-iosched.c:1479 > Kernel addresses on the stack: > [snip] > [<10125d0c>] printk+0x188/0x1c8 > [<10105638>] dump_stack+0x18/0x24 > [<101fb740>] as_requeue_request+0x64/0x10c > [<101f24b0>] elv_requeue_request+0x2c/0x38 > [<101f51b4>] blk_insert_request+0xf4/0xfc > [<10211c2c>] scsi_queue_insert+0x68/0x9c > [<102376f4>] hp_sdc_tasklet+0x80/0x160 > [<1020dd2c>] scsi_softirq+0xfc/0x11c > [<10129990>] do_softirq+0xf4/0xf8 > [<10129e68>] ksoftirqd+0x84/0xf0 > [<101398a0>] kthread+0xe8/0xf0 > [<1010ac5c>] ret_from_kernel_thread+0x1c/0x24 > > Can't point to the last kernel version that worked, because this is > actually the first kernel I've built for the C180, having just > finished bootstrapping Gentoo. But I'll be happy to provide what > info I can - seems this problem is real if both a C110 and a C180 > are suffering from it, and they're very similar pieces of hardware. > > cheers > -Andy > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( 2004-04-14 20:52 ` Joel Soete @ 2004-04-15 7:05 ` Joel Soete 2004-04-16 11:19 ` Andy Walker 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-15 7:05 UTC (permalink / raw) To: Andy Walker; +Cc: parisc-linux >That said, thanks to viewcvs, cvs and some tbz I recover from my systems, I >reach to rebuild on my b2k at the office: >2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a > tar of one of those tree) survive :) >2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :) >but 2.6.4-rc4-pa6 died with same messages. Sorry a typo: read 2.6.4-rc3-pa6 in place of rc4 :( Joel ---------------------------------------------------------------------------------------- Tiscali ADSL: 35 €/mois, la meilleure offre du marché! http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( 2004-04-15 7:05 ` Joel Soete @ 2004-04-16 11:19 ` Andy Walker 2004-04-17 18:10 ` Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Andy Walker @ 2004-04-16 11:19 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux >>That said, thanks to viewcvs, cvs and some tbz I recover from my systems, > I >reach to rebuild on my b2k at the office: >>2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a >> tar of one of those tree) survive :) >>2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :) >>but 2.6.4-rc4-pa6 died with same messages. > > Sorry a typo: read 2.6.4-rc3-pa6 in place of rc4 :( > > Joel > > Joel, 2.6.6-rc1-pa0 shows the same behaviour, although it does seem to make it through the Gentoo boot process most times. Typically, 'ls <TAB><TAB>' in bash in a largeish directory will do the trick. The bash process ends up in disk-wait, the WARN_ON gets logged. I can switch consoles and log in but just about anything that goes to disk ends up in disk-wait too. I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable. Can't boot it until this evening because the machine's at home and AUTOBOOT is OFF. -Andy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( 2004-04-16 11:19 ` Andy Walker @ 2004-04-17 18:10 ` Joel Soete 2004-04-17 20:49 ` Andy Walker 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-17 18:10 UTC (permalink / raw) To: Andy Walker; +Cc: parisc-linux Hello Andy, Sorry for delay but I was a bit busy by a production server. Andy Walker wrote: >>>That said, thanks to viewcvs, cvs and some tbz I recover from my systems, >> >>I >reach to rebuild on my b2k at the office: >> >>>2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a >>>tar of one of those tree) survive :) >>>2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :) >>>but 2.6.4-rc4-pa6 died with same messages. >> >>Sorry a typo: read 2.6.4-rc3-pa6 in place of rc4 :( >> >>Joel >> >> > > > Joel, > > 2.6.6-rc1-pa0 shows the same behaviour, Thanks. but not a surprise regarding previous test. > although it does seem to make it > through the Gentoo boot process most times. I would not be surprise if it occures during some fsck. Do you also use ext3 on your Gentoo? btw Gentoo always install pkg by a local rebuild from src (that's a long time that I visit the site)? > Typically, 'ls <TAB><TAB>' in > bash in a largeish directory will do the trick. The bash process ends up > in disk-wait, the WARN_ON gets logged. I can switch consoles and log in > but just about anything that goes to disk ends up in disk-wait too. > I will try this also. > I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable. This seems to be the last one enough stable for me and my c110: I just updated my distro (that used a lot tar iirc) and all works fine with this kernel. > Can't boot it until this evening because the machine's at home and > AUTOBOOT is OFF. > No pb. Thanks for your feedback ;) Joel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( 2004-04-17 18:10 ` Joel Soete @ 2004-04-17 20:49 ` Andy Walker 2004-04-17 21:32 ` Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Andy Walker @ 2004-04-17 20:49 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux > Hello Andy, > > Sorry for delay but I was a bit busy by a production server. No problem. >> 2.6.6-rc1-pa0 shows the same behaviour, > > Thanks. > but not a surprise regarding previous test. > >> although it does seem to make it >> through the Gentoo boot process most times. > > I would not be surprise if it occures during some fsck. Do you also use > ext3 on your Gentoo? > btw Gentoo always install pkg by a local rebuild from src (that's a long > time that I visit the site)? That's the Gentoo way - so every package on my system is compiled -march=2.0 -mschedule=8000. The downside is that install and upgrade takes a long time on slow machines. The upside is that you get total control over package selection and compilation options. I've played with Debian before but I find apt a pain compared to Gentoo's portage. Also all this sid/woody/stable/unstable etc.... stuff confuses me. >> I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable. > > This seems to be the last one enough stable for me and my c110: I just > updated my distro (that used a lot tar iirc) and all works > fine with this kernel. 2.6.3-pa2 is rock solid. I've been running updates, kernel compilation - pretty heavy stuff, and no problems. I'm just about to 'emerge' X11 - that should keep it downloading, untarring and compiling for 24 hours. Any suggestions for things I might test to narrow our problem down. cheers, -Andy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( 2004-04-17 20:49 ` Andy Walker @ 2004-04-17 21:32 ` Joel Soete 2004-04-17 23:00 ` [parisc-linux] kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-17 21:32 UTC (permalink / raw) To: Andy Walker; +Cc: parisc-linux Andy Walker wrote: >>Hello Andy, >> >>Sorry for delay but I was a bit busy by a production server. > > > No problem. > > >>>2.6.6-rc1-pa0 shows the same behaviour, >> >>Thanks. >>but not a surprise regarding previous test. >> >> >>>although it does seem to make it >>>through the Gentoo boot process most times. >> >>I would not be surprise if it occures during some fsck. Do you also use >>ext3 on your Gentoo? >>btw Gentoo always install pkg by a local rebuild from src (that's a long >>time that I visit the site)? > > > That's the Gentoo way - so every package on my system is compiled > -march=2.0 -mschedule=8000. The downside is that install and upgrade > takes a long time on slow machines. Yes that why I do not investegate more: I don't have a lot of budget for my system which are generaly systems a bit outdated machine recover from trash still just enough for my investigation but a bit too slow to build all the tools I would like to maintained uptodate frequently. The very great stuff would have to have the choice: update from pre-compiled binaries or a local compile. The debian packaging system is very robust (some month ago, on a i386, I do an update from a old woody (r0 iirc) directly to unstable aka sid without any pb) but I do not yet find a clear doc explaining me how to personalize pkg from dpkg src (I would like for instance change the prefix in general /usr into /opt/app/app_rev a la hp)? > The upside is that you get total > control over package selection and compilation options. I've played > with Debian before but I find apt a pain compared to Gentoo's portage. > Also all this sid/woody/stable/unstable etc.... stuff confuses me. > That is the simple aspect: in short the current stable release was named (the 2.x was potato, the current one woody) the very last packages otc are put in unstable (aka sid) for large testing and debuging when pkg become enough stable it is pushed in testing the futur debian release (recently named sarge) there are also security update for stable release only because there are in general in unstable and testing before! For my part I only have ineterest in very last available packages (so sid or unstable) to test new features but some times (rarely in fact) the system is a bit 'unstable' :) (that's my choice). > >>>I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable. >> >>This seems to be the last one enough stable for me and my c110: I just >>updated my distro (that used a lot tar iirc) and all works >>fine with this kernel. > > > 2.6.3-pa2 is rock solid. I've been running updates, kernel compilation - > pretty heavy stuff, and no problems. > I'm just about to 'emerge' X11 - that should keep it downloading, > untarring and compiling for 24 hours. > Ok > Any suggestions for things I might test to narrow our problem down. > Not realy for the moment, as explain previously, the problem seems to apear between 2.6.4-rc1-pa3 and 2.6.4-rc3-pa6. I will try to figure out now if it comes from upstream or from or tree: I am on going to rebuild 2.6.4-rc3-pa1 and see how will it behave. Thanks a lot, Joel ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] 2004-04-17 21:32 ` Joel Soete @ 2004-04-17 23:00 ` Joel Soete 2004-04-18 14:39 ` [parisc-linux] " Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-17 23:00 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux, Andy Walker Hi all, To summarise I do following test with different kernel to locate this pb: launch severall find into local big tree (different release of kernel tree) in the same time of a tar of one of those tree. with kernel 2.6.3-pa2 no pb with 2.6.4-rc1-pa3 no pb (apparently) with 2.6.4-rc3-pa6 system crash (as well as with 2.6.4-rc3-pa1) with the last one (2.6.4-rc3-pa1) I also log: attempt to access beyond end of device sdb9: rw=0, want=2307486096, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=2842788104, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=1904280008, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=2298589592, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=26325376, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=1371126224, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=3277938880, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=122917000, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=1151862976, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=3236466824, limit=3075696 attempt to access beyond end of device sdb9: rw=0, want=3253102776, limit=3075696 during the first find alone? arq->state 2 Badness in as_requeue_request at drivers/block/as-iosched.c:1479 Kernel addresses on the stack: [<10125de8>] printk+0x188/0x1c8 [<10105938>] dump_stack+0x18/0x24 [<102294fc>] as_requeue_request+0x64/0x10c [<10220468>] elv_requeue_request+0x2c/0x38 [<1022313c>] blk_insert_request+0xfc/0x104 [<1024cbb0>] scsi_queue_insert+0x68/0x9c [<1024915c>] scsi_finish_command+0x9c/0xc0 [<10249068>] scsi_softirq+0xfc/0x11c [<10262fb4>] ncr53c8xx_intr+0x74/0xbc [<101299cc>] do_softirq+0xf4/0xf8 [<10220468>] elv_requeue_request+0x2c/0x38 [<10107270>] do_cpu_irq_mask+0xfc/0x10c [<10220468>] elv_requeue_request+0x2c/0x38 [<1010b068>] intr_return+0x0/0x14 [<1024cbb0>] scsi_queue_insert+0x68/0x9c [<1010b070>] intr_return+0x8/0x14 [<1016ba8c>] may_open+0x58/0x1c8 [<1015a850>] dentry_open+0x138/0x1c4 [<1016e784>] locate_fd+0x158/0x194 [<1010b068>] intr_return+0x0/0x14 kernel BUG at include/linux/blkdev.h:543! Kernel addresses on the stack: [<10125de8>] printk+0x188/0x1c8 [<10105938>] dump_stack+0x18/0x24 [<1024ddc8>] scsi_request_fn+0x2a0/0x2c4 [<10220468>] elv_requeue_request+0x2c/0x38 [<10223120>] blk_insert_request+0xe0/0x104 [<1024cbb0>] scsi_queue_insert+0x68/0x9c [<1024915c>] scsi_finish_command+0x9c/0xc0 [<10249068>] scsi_softirq+0xfc/0x11c [<10262fb4>] ncr53c8xx_intr+0x74/0xbc [<101299cc>] do_softirq+0xf4/0xf8 [<10220468>] elv_requeue_request+0x2c/0x38 [<10107270>] do_cpu_irq_mask+0xfc/0x10c [<10220468>] elv_requeue_request+0x2c/0x38 [<1010b068>] intr_return+0x0/0x14 [<1024cbb0>] scsi_queue_insert+0x68/0x9c [<1010b070>] intr_return+0x8/0x14 [<1016ba8c>] may_open+0x58/0x1c8 [<1015a850>] dentry_open+0x138/0x1c4 [<1016e784>] locate_fd+0x158/0x194 [<1010b068>] intr_return+0x0/0x14 [...] and so on severall time. I also drive the same test over a nfs (as it seems that lan and scsi ctrl on this c110 share the same U2 bridge?): no pb. May I so reasonably thought that pb is loacted into ncr53c720 scsi driver? Thanks in advance for additional help, Joel Joel Soete wrote: > > > Andy Walker wrote: > >>> Hello Andy, >>> >>> Sorry for delay but I was a bit busy by a production server. >> >> >> >> No problem. >> >> >>>> 2.6.6-rc1-pa0 shows the same behaviour, >>> >>> >>> Thanks. >>> but not a surprise regarding previous test. >>> >>> >>>> although it does seem to make it >>>> through the Gentoo boot process most times. >>> >>> >>> I would not be surprise if it occures during some fsck. Do you also use >>> ext3 on your Gentoo? >>> btw Gentoo always install pkg by a local rebuild from src (that's a long >>> time that I visit the site)? >> >> >> >> That's the Gentoo way - so every package on my system is compiled >> -march=2.0 -mschedule=8000. The downside is that install and upgrade >> takes a long time on slow machines. > > > Yes that why I do not investegate more: I don't have a lot of budget for > my system which are generaly systems a bit outdated machine recover from > trash still just enough for my investigation but a bit too slow to build > all the tools I would like to maintained uptodate frequently. The very > great stuff would have to have the choice: update from pre-compiled > binaries or a local compile. The debian packaging system is very robust > (some month ago, on a i386, I do an update from a old woody (r0 iirc) > directly to unstable aka sid without any pb) but I do not yet find a > clear doc explaining me how to personalize pkg from dpkg src (I would > like for instance change the prefix in general /usr into > /opt/app/app_rev a la hp)? > >> The upside is that you get total >> control over package selection and compilation options. I've played >> with Debian before but I find apt a pain compared to Gentoo's portage. >> Also all this sid/woody/stable/unstable etc.... stuff confuses me. >> > That is the simple aspect: in short > the current stable release was named (the 2.x was potato, the > current one woody) > the very last packages otc are put in unstable (aka sid) for large > testing and debuging > when pkg become enough stable it is pushed in testing the futur > debian release (recently named sarge) > > there are also security update for stable release only because there are > in general in unstable and testing before! > > For my part I only have ineterest in very last available packages (so > sid or unstable) to test new features but some times (rarely in fact) > the system is a bit 'unstable' :) (that's my choice). > >> >>>> I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable. >>> >>> >>> This seems to be the last one enough stable for me and my c110: I just >>> updated my distro (that used a lot tar iirc) and all works >>> fine with this kernel. >> >> >> >> 2.6.3-pa2 is rock solid. I've been running updates, kernel compilation - >> pretty heavy stuff, and no problems. >> I'm just about to 'emerge' X11 - that should keep it downloading, >> untarring and compiling for 24 hours. >> > Ok > >> Any suggestions for things I might test to narrow our problem down. >> > Not realy for the moment, as explain previously, the problem seems to > apear between 2.6.4-rc1-pa3 and 2.6.4-rc3-pa6. > I will try to figure out now if it comes from upstream or from or tree: > I am on going to rebuild 2.6.4-rc3-pa1 and see how will it behave. > > Thanks a lot, > Joel > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] 2004-04-17 23:00 ` [parisc-linux] kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] Joel Soete @ 2004-04-18 14:39 ` Joel Soete 2004-04-18 16:36 ` James Bottomley 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-18 14:39 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux, Andy Walker Hello, Sorry but I absolutly blind this week-end (no access to 192.25.206 ie debian.org, p-l.org and cvs.p-l.org :_( ), more over I had to confirm 'membership in the mailing list parisc-linux' which has been disabled, so I didn't received anymore followup :( Any way I progress: I revert the following patch against the last pa kernel I had here ie 2.6.5-pa5: =================================================================== RCS file: /var/lib/cvs/linux-2.6/drivers/parisc/ccio-dma.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- linux-2.6/drivers/parisc/ccio-dma.c 2004/03/09 21:49:04 1.12 +++ linux-2.6/drivers/parisc/ccio-dma.c 2004/03/10 19:24:48 1.13 @@ -38,9 +38,7 @@ #include <linux/spinlock.h> #include <linux/slab.h> #include <linux/string.h> -#define PCI_DEBUG #include <linux/pci.h> -#undef PCI_DEBUG #include <linux/reboot.h> #include <asm/byteorder.h> @@ -344,15 +342,16 @@ * of available pages for the requested size. */ static int -ccio_alloc_range(struct ioc *ioc, unsigned long pages_needed) +ccio_alloc_range(struct ioc *ioc, size_t size) { + unsigned int pages_needed = size >> IOVP_SHIFT; unsigned int res_idx; #ifdef CCIO_SEARCH_TIME unsigned long cr_start = mfctl(16); #endif - ASSERT(pages_needed); - ASSERT((pages_needed * IOVP_SIZE) <= DMA_CHUNK_SIZE); + BUG_ON(pages_needed == 0); + BUG_ON((pages_needed * IOVP_SIZE) > DMA_CHUNK_SIZE); DBG_RES("%s() size: %d pages_needed %d\n", __FUNCTION__, size, pages_needed); @@ -387,7 +386,7 @@ CCIO_FIND_FREE_MAPPING(ioc, res_idx, ~0UL, 64); #endif } else { - panic("%s: %s() Too many pages to map. pages_needed: %ld\n", + panic("%s: %s() Too many pages to map. pages_needed: %u\n", __FILE__, __FUNCTION__, pages_needed); } @@ -420,7 +419,7 @@ #define CCIO_FREE_MAPPINGS(ioc, res_idx, mask, size) \ u##size *res_ptr = (u##size *)&((ioc)->res_map[res_idx]); \ - ASSERT((*res_ptr & mask) == mask); \ + BUG_ON((*res_ptr & mask) != mask); \ *res_ptr &= ~(mask); /** @@ -438,9 +437,9 @@ unsigned long iovp = CCIO_IOVP(iova); unsigned int res_idx = PDIR_INDEX(iovp) >> 3; - ASSERT(pages_mapped); - ASSERT((pages_mapped * IOVP_SIZE) <= DMA_CHUNK_SIZE); - ASSERT(pages_mapped <= BITS_PER_LONG); + BUG_ON(pages_mapped == 0); + BUG_ON((pages_mapped * IOVP_SIZE) > DMA_CHUNK_SIZE); + BUG_ON(pages_mapped > BITS_PER_LONG); DBG_RES("%s(): res_idx: %d pages_mapped %d\n", __FUNCTION__, res_idx, pages_mapped); @@ -558,13 +557,14 @@ * index are bits 12:19 of the value returned by LCI. */ void CCIO_INLINE -ccio_io_pdir_entry(u64 *pdir_ptr, space_t sid, void * vba, unsigned long hints)+ccio_io_pdir_entry(u64 *pdir_ptr, space_t sid, unsigned long vba, + unsigned long hints) { register unsigned long pa = (volatile unsigned long) vba; register unsigned long ci; /* coherent index */ /* We currently only support kernel addresses */ - ASSERT(sid == KERNEL_SPACE); + BUG_ON(sid != KERNEL_SPACE); mtsp(sid,1); @@ -677,7 +677,7 @@ unsigned int idx = PDIR_INDEX(iovp); char *pdir_ptr = (char *) &(ioc->pdir_base[idx]); - ASSERT(idx < (ioc->pdir_size / sizeof(u64))); + BUG_ON(idx >= (ioc->pdir_size / sizeof(u64))); pdir_ptr[7] = 0; /* clear only VALID bit */ /* ** FIXME: PCX_W platforms don't need FDC/SYNC. (eg C360) @@ -747,7 +747,7 @@ BUG_ON(!dev); ioc = GET_IOC(dev); - ASSERT(size > 0); + BUG_ON(size <= 0); /* save offset bits */ offset = ((unsigned long) addr) & ~IOVP_MASK; @@ -761,7 +761,7 @@ ioc->msingle_pages += size >> IOVP_SHIFT; #endif - idx = ccio_alloc_range(ioc, (size >> IOVP_SHIFT)); + idx = ccio_alloc_range(ioc, size); iovp = (dma_addr_t)MKIOVP(idx); pdir_start = &(ioc->pdir_base[idx]); @@ -774,7 +774,7 @@ hint |= HINT_SAFE_DMA; while(size > 0) { - ccio_io_pdir_entry(pdir_start, KERNEL_SPACE, addr, hint); + ccio_io_pdir_entry(pdir_start, KERNEL_SPACE, (unsigned long)addr, hint); DBG_RUN(" pdir %p %08x%08x\n", pdir_start, @@ -886,162 +886,10 @@ */ #define PIDE_FLAG 0x80000000UL -/** - * ccio_fill_pdir - Insert coalesced scatter/gather chunks into the I/O Pdir. - * @ioc: The I/O Controller. - * @startsg: The scatter/gather list of coalesced chunks. - * @nents: The number of entries in the scatter/gather list. - * @hint: The DMA Hint. - * - * This function inserts the coalesced scatter/gather list chunks into the - * I/O Controller's I/O Pdir. - */ -static CCIO_INLINE int -ccio_fill_pdir(struct ioc *ioc, struct scatterlist *startsg, int nents, - unsigned long hint) -{ - struct scatterlist *dma_sg = startsg; /* pointer to current DMA */ - int n_mappings = 0; - unsigned long dma_offset = 0, dma_len = 0; - u64 *pdirp = NULL; - - while (nents-- > 0) { - unsigned long vaddr; - long size; - - DBG_RUN_SG(" %d : %08lx/%05x %08lx/%05x\n", nents, - (unsigned long)sg_dma_address(startsg), cnt, - sg_virt_addr(startsg), startsg->length - ); - - - /* - ** Look for the start of a new DMA stream - */ - - if (sg_dma_address(startsg) & PIDE_FLAG) { - u32 pide = sg_dma_address(startsg) & ~PIDE_FLAG; - - if (pdirp) { - BUG_ON(dma_len != sg_dma_len(dma_sg)); - dma_sg++; - } - dma_len = sg_dma_len(startsg); - dma_offset = (unsigned long) pide & ~IOVP_MASK; - n_mappings++; - sg_dma_address(dma_sg) = pide; - pdirp = &(ioc->pdir_base[pide >> IOVP_SHIFT]); - } - - BUG_ON(pdirp == NULL); - - sg_dma_len(startsg) = 0; - vaddr = sg_virt_addr(startsg); - sg_dma_len(dma_sg) += startsg->length; - size = startsg->length + dma_offset; - dma_offset = 0; - if (unlikely(size > IOVP_SIZE)) { - printk("VIRTUAL CHUNK has size 0x%lx\n", - size); - } #ifdef CCIO_MAP_STATS - ioc->msg_pages += startsg->length >> IOVP_SHIFT; +#define IOMMU_MAP_STATS #endif - do { - ccio_io_pdir_entry(pdirp, KERNEL_SPACE, - (void *)vaddr, hint); - vaddr += IOVP_SIZE; - size -= IOVP_SIZE; - pdirp++; - } while(unlikely(size > 0)); - startsg++; - } - return(n_mappings); -} - -/* -** First pass is to walk the SG list and determine where the breaks are -** in the DMA stream. Allocates PDIR entries but does not fill them. -** Returns the number of DMA chunks. -** -** Doing the fill separate from the coalescing/allocation keeps the -** code simpler. Future enhancement could make one pass through -** the sglist do both. -*/ - -static CCIO_INLINE int -ccio_coalesce_chunks(struct ioc *ioc, struct scatterlist *startsg, int nents) -{ - struct scatterlist *contig_sg; /* contig chunk head */ - unsigned long dma_offset, dma_len; /* start/len of DMA stream */ - int n_mappings = 0; - - while (nents > 0) { - - /* - ** Prepare for first/next DMA stream - */ - contig_sg = startsg; - dma_len = startsg->length; - dma_offset = sg_virt_addr(startsg) & ~IOVP_MASK; - - /* PARANOID: clear entries */ - sg_dma_address(startsg) = 0; - sg_dma_len(startsg) = 0; - - /* - ** This loop terminates one iteration "early" since - ** it's always looking one "ahead". - */ - while(--nents > 0) { - unsigned long prevstartsg_end, startsg_end; - - prevstartsg_end = sg_virt_addr(startsg) + - startsg->length; - - startsg++; - startsg_end = sg_virt_addr(startsg) + - startsg->length; - - /* PARANOID: clear entries */ - sg_dma_address(startsg) = 0; - sg_dma_len(startsg) = 0; - - /* - ** First make sure current dma stream won't - ** exceed DMA_CHUNK_SIZE if we coalesce the - ** next entry. - */ - if(unlikely(ROUNDUP(dma_len + dma_offset + startsg->length, - IOVP_SIZE) > DMA_CHUNK_SIZE)) - break; - - /* - ** Next see if we can append the next chunk (i.e. - ** it must end on one page and begin on another - */ - if (unlikely(((prevstartsg_end | sg_virt_addr(startsg)) & ~PAGE_MASK) != 0)) - break; - - dma_len += startsg->length; - } - - /* - ** End of DMA Stream - ** Terminate last VCONTIG block. - ** Allocate space for DMA stream. - */ - sg_dma_len(contig_sg) = dma_len; - dma_len = ROUNDUP(dma_len + dma_offset, IOVP_SIZE); - sg_dma_address(contig_sg) = - PIDE_FLAG - | (ccio_alloc_range(ioc, (dma_len >> IOVP_SHIFT)) << IOVP_SHIFT) - | dma_offset; - n_mappings++; - } - - return n_mappings; -} +#include "iommu-helpers.h" /** * ccio_map_sg - Map the scatter/gather list into the IOMMU. @@ -1094,7 +942,7 @@ ** w/o this association, we wouldn't have coherent DMA! ** Access to the virtual address is what forces a two pass algorithm. */ - coalesced = ccio_coalesce_chunks(ioc, sglist, nents); + coalesced = iommu_coalesce_chunks(ioc, sglist, nents, ccio_alloc_range); /* ** Program the I/O Pdir @@ -1104,7 +952,7 @@ ** o dma_len will contain the number of bytes to map ** o page/offset contain the virtual address. */ - filled = ccio_fill_pdir(ioc, sglist, nents, hint); + filled = iommu_fill_pdir(ioc, sglist, nents, hint, ccio_io_pdir_entry); spin_unlock_irqrestore(&ioc->res_lock, flags); @@ -1446,16 +1294,16 @@ */ iov_order = get_order(iova_space_size) >> (IOVP_SHIFT - PAGE_SHIFT); - ASSERT(iov_order <= (30 - IOVP_SHIFT)); /* iova_space_size <= 1GB */ - ASSERT(iov_order >= (20 - IOVP_SHIFT)); /* iova_space_size >= 1MB */ + BUG_ON(iov_order > (30 - IOVP_SHIFT)); /* iova_space_size <= 1GB */ + BUG_ON(iov_order < (20 - IOVP_SHIFT)); /* iova_space_size >= 1MB */ iova_space_size = 1 << (iov_order + IOVP_SHIFT); ioc->pdir_size = (iova_space_size / IOVP_SIZE) * sizeof(u64); - ASSERT(ioc->pdir_size < 4 * 1024 * 1024); /* max pdir size < 4MB */ + BUG_ON(ioc->pdir_size >= 4 * 1024 * 1024); /* max pdir size < 4MB */ /* Verify it's a power of two */ - ASSERT((1 << get_order(ioc->pdir_size)) == (ioc->pdir_size >> PAGE_SHIFT)); + BUG_ON((1 << get_order(ioc->pdir_size)) != (ioc->pdir_size >> PAGE_SHIFT)); DBG_INIT("%s() hpa 0x%p mem %luMB IOV %dMB (%d bits) PDIR size 0x%0x", __FUNCTION__, ioc->ioc_hpa, physmem>>20, iova_space_size>>20, @@ -1469,7 +1317,7 @@ } memset(ioc->pdir_base, 0, ioc->pdir_size); - ASSERT((((unsigned long)ioc->pdir_base) & PAGE_MASK) == (unsigned long)ioc->pdir_base); + BUG_ON((((unsigned long)ioc->pdir_base) & PAGE_MASK) != (unsigned long)ioc->pdir_base); DBG_INIT(" base %p", ioc->pdir_base); /* resource map size dictated by pdir_size */ @@ -1708,6 +1556,7 @@ proc_runway_root, ccio_resource_map, NULL); } parisc_vmerge_boundary = IOVP_SIZE; + parisc_vmerge_max_size = BITS_PER_LONG * IOVP_SIZE; ioc_count++; return 0; } ================================================================================================== And the test (find + tar) works again. I presume that wrong stuff come from the ccio_fill_pdir() or ccio_coalesce_chunks() merge with lba one? But I don't have yet more accurate idea on what went wrong here (difference between functions are important). (would it help to rebuild this same kernel tree with gcc-3.0 32bit would help? right now is was build with latest gcc-3.3.3.) Grant, James any idea? Thanks again for your understanding, Joel Joel Soete wrote: > Hi all, > > To summarise I do following test with different kernel to locate this pb: > launch severall find into local big tree (different release of kernel > tree) in the same time of a tar of one of those tree. > > with kernel 2.6.3-pa2 no pb > with 2.6.4-rc1-pa3 no pb (apparently) > with 2.6.4-rc3-pa6 system crash (as well as with 2.6.4-rc3-pa1) > > with the last one (2.6.4-rc3-pa1) I also log: > attempt to access beyond end of device > sdb9: rw=0, want=2307486096, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=2842788104, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=1904280008, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=2298589592, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=26325376, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=1371126224, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=3277938880, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=122917000, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=1151862976, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=3236466824, limit=3075696 > attempt to access beyond end of device > sdb9: rw=0, want=3253102776, limit=3075696 > > during the first find alone? > arq->state 2 > Badness in as_requeue_request at drivers/block/as-iosched.c:1479 > Kernel addresses on the stack: > [<10125de8>] printk+0x188/0x1c8 > [<10105938>] dump_stack+0x18/0x24 > [<102294fc>] as_requeue_request+0x64/0x10c > [<10220468>] elv_requeue_request+0x2c/0x38 > [<1022313c>] blk_insert_request+0xfc/0x104 > [<1024cbb0>] scsi_queue_insert+0x68/0x9c > [<1024915c>] scsi_finish_command+0x9c/0xc0 > [<10249068>] scsi_softirq+0xfc/0x11c > [<10262fb4>] ncr53c8xx_intr+0x74/0xbc > [<101299cc>] do_softirq+0xf4/0xf8 > [<10220468>] elv_requeue_request+0x2c/0x38 > [<10107270>] do_cpu_irq_mask+0xfc/0x10c > [<10220468>] elv_requeue_request+0x2c/0x38 > [<1010b068>] intr_return+0x0/0x14 > [<1024cbb0>] scsi_queue_insert+0x68/0x9c > [<1010b070>] intr_return+0x8/0x14 > [<1016ba8c>] may_open+0x58/0x1c8 > [<1015a850>] dentry_open+0x138/0x1c4 > [<1016e784>] locate_fd+0x158/0x194 > [<1010b068>] intr_return+0x0/0x14 > > kernel BUG at include/linux/blkdev.h:543! > Kernel addresses on the stack: > [<10125de8>] printk+0x188/0x1c8 > [<10105938>] dump_stack+0x18/0x24 > [<1024ddc8>] scsi_request_fn+0x2a0/0x2c4 > [<10220468>] elv_requeue_request+0x2c/0x38 > [<10223120>] blk_insert_request+0xe0/0x104 > [<1024cbb0>] scsi_queue_insert+0x68/0x9c > [<1024915c>] scsi_finish_command+0x9c/0xc0 > [<10249068>] scsi_softirq+0xfc/0x11c > [<10262fb4>] ncr53c8xx_intr+0x74/0xbc > [<101299cc>] do_softirq+0xf4/0xf8 > [<10220468>] elv_requeue_request+0x2c/0x38 > [<10107270>] do_cpu_irq_mask+0xfc/0x10c > [<10220468>] elv_requeue_request+0x2c/0x38 > [<1010b068>] intr_return+0x0/0x14 > [<1024cbb0>] scsi_queue_insert+0x68/0x9c > [<1010b070>] intr_return+0x8/0x14 > [<1016ba8c>] may_open+0x58/0x1c8 > [<1015a850>] dentry_open+0x138/0x1c4 > [<1016e784>] locate_fd+0x158/0x194 > [<1010b068>] intr_return+0x0/0x14 > [...] > and so on severall time. > > I also drive the same test over a nfs (as it seems that lan and scsi > ctrl on this c110 share the same U2 bridge?): > no pb. > > May I so reasonably thought that pb is loacted into ncr53c720 scsi driver? > > Thanks in advance for additional help, > Joel > > > > Joel Soete wrote: > >> >> >> Andy Walker wrote: >> >>>> Hello Andy, >>>> >>>> Sorry for delay but I was a bit busy by a production server. >>> >>> >>> >>> >>> No problem. >>> >>> >>>>> 2.6.6-rc1-pa0 shows the same behaviour, >>>> >>>> >>>> >>>> Thanks. >>>> but not a surprise regarding previous test. >>>> >>>> >>>>> although it does seem to make it >>>>> through the Gentoo boot process most times. >>>> >>>> >>>> >>>> I would not be surprise if it occures during some fsck. Do you also use >>>> ext3 on your Gentoo? >>>> btw Gentoo always install pkg by a local rebuild from src (that's a >>>> long >>>> time that I visit the site)? >>> >>> >>> >>> >>> That's the Gentoo way - so every package on my system is compiled >>> -march=2.0 -mschedule=8000. The downside is that install and upgrade >>> takes a long time on slow machines. >> >> >> >> Yes that why I do not investegate more: I don't have a lot of budget >> for my system which are generaly systems a bit outdated machine >> recover from trash still just enough for my investigation but a bit >> too slow to build all the tools I would like to maintained uptodate >> frequently. The very great stuff would have to have the choice: update >> from pre-compiled binaries or a local compile. The debian packaging >> system is very robust (some month ago, on a i386, I do an update from >> a old woody (r0 iirc) directly to unstable aka sid without any pb) but >> I do not yet find a clear doc explaining me how to personalize pkg >> from dpkg src (I would like for instance change the prefix in general >> /usr into /opt/app/app_rev a la hp)? >> >>> The upside is that you get total >>> control over package selection and compilation options. I've played >>> with Debian before but I find apt a pain compared to Gentoo's portage. >>> Also all this sid/woody/stable/unstable etc.... stuff confuses me. >>> >> That is the simple aspect: in short >> the current stable release was named (the 2.x was potato, the >> current one woody) >> the very last packages otc are put in unstable (aka sid) for large >> testing and debuging >> when pkg become enough stable it is pushed in testing the futur >> debian release (recently named sarge) >> >> there are also security update for stable release only because there >> are in general in unstable and testing before! >> >> For my part I only have ineterest in very last available packages (so >> sid or unstable) to test new features but some times (rarely in fact) >> the system is a bit 'unstable' :) (that's my choice). >> >>> >>>>> I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable. >>>> >>>> >>>> >>>> This seems to be the last one enough stable for me and my c110: I just >>>> updated my distro (that used a lot tar iirc) and all works >>>> fine with this kernel. >>> >>> >>> >>> >>> 2.6.3-pa2 is rock solid. I've been running updates, kernel compilation - >>> pretty heavy stuff, and no problems. >>> I'm just about to 'emerge' X11 - that should keep it downloading, >>> untarring and compiling for 24 hours. >>> >> Ok >> >>> Any suggestions for things I might test to narrow our problem down. >>> >> Not realy for the moment, as explain previously, the problem seems to >> apear between 2.6.4-rc1-pa3 and 2.6.4-rc3-pa6. >> I will try to figure out now if it comes from upstream or from or >> tree: I am on going to rebuild 2.6.4-rc3-pa1 and see how will it behave. >> >> Thanks a lot, >> Joel >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] 2004-04-18 14:39 ` [parisc-linux] " Joel Soete @ 2004-04-18 16:36 ` James Bottomley 2004-04-18 17:16 ` Joel Soete ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: James Bottomley @ 2004-04-18 16:36 UTC (permalink / raw) To: Joel Soete; +Cc: PARISC list, Andy Walker On Sun, 2004-04-18 at 09:39, Joel Soete wrote: > I presume that wrong stuff come from the ccio_fill_pdir() or ccio_coalesce_chunks() merge with lba one? > But I don't have yet more accurate idea on what went wrong here (difference between functions are important). > > (would it help to rebuild this same kernel tree with gcc-3.0 32bit would help? right now is was build with latest gcc-3.3.3.) > > Grant, James any idea? Well, actually, the problem can't be in the code you cite, otherwise my raven wouldn't work either and it's been fine. However, it's entirely possible that the effects of the patch are causing issues in the ncr driver. What it does is correctly coalesce segments in the iommu. Before this, the parisc iommus rarely did coalescing, so our SG lists were usually lots of page sized entities. Now the individual entries can be up to 256k long. I suspect, since your C110 has a 53c720 (using the ncr driver) and my C360 has a 53c875 (using sym_2) that the ncr driver can't cope with sg lists whose entries are so long. The problems are probably due to some sort of fixed length assumption on sg elements in the ncr driver. James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] 2004-04-18 16:36 ` James Bottomley @ 2004-04-18 17:16 ` Joel Soete 2004-04-19 16:53 ` Joel Soete 2004-04-21 10:08 ` [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] Joel Soete 2 siblings, 0 replies; 17+ messages in thread From: Joel Soete @ 2004-04-18 17:16 UTC (permalink / raw) To: James Bottomley; +Cc: PARISC list, Andy Walker James Bottomley wrote: > On Sun, 2004-04-18 at 09:39, Joel Soete wrote: > >>I presume that wrong stuff come from the ccio_fill_pdir() or ccio_coalesce_chunks() merge with lba one? >>But I don't have yet more accurate idea on what went wrong here (difference between functions are important). >> >>(would it help to rebuild this same kernel tree with gcc-3.0 32bit would help? right now is was build with latest gcc-3.3.3.) >> >>Grant, James any idea? > > > Well, actually, the problem can't be in the code you cite, otherwise my > raven wouldn't work either and it's been fine. > > However, it's entirely possible that the effects of the patch are > causing issues in the ncr driver. What it does is correctly coalesce > segments in the iommu. Before this, the parisc iommus rarely did > coalescing, so our SG lists were usually lots of page sized entities. > Now the individual entries can be up to 256k long. > > I suspect, since your C110 has a 53c720 (using the ncr driver) and my > C360 has a 53c875 (using sym_2) that the ncr driver can't cope with sg > lists whose entries are so long. > Yes that's also the main difference I noticed between c110 and c360. > The problems are probably due to some sort of fixed length assumption on > sg elements in the ncr driver. > Ok, I now better understand inter-action between ccio and ncr drivers and I check in more detail this code. Thanks a lot for all, Joel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] 2004-04-18 16:36 ` James Bottomley 2004-04-18 17:16 ` Joel Soete @ 2004-04-19 16:53 ` Joel Soete [not found] ` <408AD395.4060909@tiscali.be> 2004-04-21 10:08 ` [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] Joel Soete 2 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-19 16:53 UTC (permalink / raw) To: James Bottomley; +Cc: PARISC list, Andy Walker James , Thanks to your explanation, I become to have (step by step) a more detail idea on what I did and its borther effect. (still have to confirm by test :^) >coalescing, so our SG lists were usually lots of page sized entities. >Now the individual entries can be up to 256k long. Just to be sure we spoke about the same thing: 256k for you is it well the parisc_vmerge_max_size = IOVP_SIZE * BITS_PER_LONG? as IOVP == PAGE_SIZE == 4k and BITS_PER_LONG == 32 for a 32bits kernel, so parisc_vmerge_max_size= 128k and BITS_PER_LONG == 64 for 64bit kernel, so parisc_vmerge_max_size= 256k. Thanks in advance, Joel PS: btw in dma.h I found "#define DMA_CHUNK_SIZE (BITS_PER_LONG*PAGE_SIZE)"; couldn't it used in ccio-dma.c and sba-iommu.c in parisc_vmerge_max_size assignement? ---------------------------------------------------------------------------------------- Tiscali ADSL: 35 €/mois, la meilleure offre du marché! http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <408AD395.4060909@tiscali.be>]
* [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [not found] ` <408AD395.4060909@tiscali.be> @ 2004-04-24 22:19 ` Grant Grundler 2004-04-24 22:31 ` Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Grant Grundler @ 2004-04-24 22:19 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux On Sat, Apr 24, 2004 at 08:52:37PM +0000, Joel Soete wrote: > Hello Grant, > > Sorry in advance to disturbe you with this c110 pb but if I well understand > the physical connection (fine doc find on openpa.net :) and better > understand what james means, otc I past the full last week to study more > ccio-dma and ncr53c8xx but I don't reach to locate the part of code making > the link between those 2 part (i mean where ncr call ccio and visversa). > Could you help me a bit more. Yup. Using 2.6.5-pa8 source tree, ncr53c8xx.c calls DMA services from ncr_scatter(): ncr53c8xx.c:7594: u_long baddr = map_scsi_single_data(np, cmd); sym53c8xx_comm.h:699:static int __map_scsi_sg_data(struct device *dev, Scsi_Cmnd *cmd) ... sym53c8xx_comm.h:708: use_sg = dma_map_sg(dev, cmd->buffer, cmd->use_sg, dma_dir); asm/dma-mapping.h:91:static inline int asm/dma-mapping.h:92:dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, asm/dma-mapping.h:93: enum dma_data_direction direction) asm/dma-mapping.h:94:{ asm/dma-mapping.h:95: return hppa_dma_ops->map_sg(dev, sg, nents, direction); asm/dma-mapping.h:96:} Then search for hppa_dma_ops in arch/parisc/kernel/* and drivers/parisc/*.c to locate the various platform/chipset DMA support: grundler <553>fgrep -n hppa_dma_ops arch/parisc/kernel/*c drivers/parisc/* arch/parisc/kernel/drivers.c:30:struct hppa_dma_ops *hppa_dma_ops; arch/parisc/kernel/drivers.c:31:EXPORT_SYMBOL(hppa_dma_ops); arch/parisc/kernel/pci-dma.c:492:struct hppa_dma_ops pcxl_dma_ops = { arch/parisc/kernel/pci-dma.c:533:struct hppa_dma_ops pcx_dma_ops = { arch/parisc/kernel/setup.c:96: hppa_dma_ops = &pcx_dma_ops; arch/parisc/kernel/setup.c:101: hppa_dma_ops = &pcxl_dma_ops; drivers/parisc/ccio-dma.c:1009:static struct hppa_dma_ops ccio_ops = { drivers/parisc/ccio-dma.c:1545: hppa_dma_ops = &ccio_ops; drivers/parisc/ccio-rm-dma.c:183: hppa_dma_ops = &ccio_ops; drivers/parisc/sba_iommu.c:1177:static struct hppa_dma_ops sba_ops = { drivers/parisc/sba_iommu.c:1809: hppa_dma_ops = &sba_ops; Ideally, "make" would detect when support for only one chipset is needed and just do away with hppa_dma_ops completely (ie directly call into the chipset specific function). > Thanks in advance, > Joel > > PS: btw I noticed that ncr_attach() is still prefix by __init where > sym_attach() is now prefix by __devinit. I trust it is important but could > it be the simple reason of pb encounter? IIRC, the difference is for hotplug. __devinit section is preserved when CONFIG_HOTPLUG is enabled. See linux/Documentation/pci.txt for the real description. grant ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 2004-04-24 22:19 ` [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 Grant Grundler @ 2004-04-24 22:31 ` Joel Soete 0 siblings, 0 replies; 17+ messages in thread From: Joel Soete @ 2004-04-24 22:31 UTC (permalink / raw) To: Grant Grundler; +Cc: parisc-linux Grant Grundler wrote: > On Sat, Apr 24, 2004 at 08:52:37PM +0000, Joel Soete wrote: > >>Hello Grant, >> >>Sorry in advance to disturbe you with this c110 pb but if I well understand >>the physical connection (fine doc find on openpa.net :) and better >>understand what james means, otc I past the full last week to study more >>ccio-dma and ncr53c8xx but I don't reach to locate the part of code making >> the link between those 2 part (i mean where ncr call ccio and visversa). >> Could you help me a bit more. > > > Yup. Using 2.6.5-pa8 source tree, ncr53c8xx.c calls DMA services from > ncr_scatter(): > > ncr53c8xx.c:7594: u_long baddr = map_scsi_single_data(np, cmd); > > sym53c8xx_comm.h:699:static int __map_scsi_sg_data(struct device *dev, Scsi_Cmnd *cmd) > ... > sym53c8xx_comm.h:708: use_sg = dma_map_sg(dev, cmd->buffer, cmd->use_sg, dma_dir); > > > asm/dma-mapping.h:91:static inline int > asm/dma-mapping.h:92:dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, > asm/dma-mapping.h:93: enum dma_data_direction direction) > asm/dma-mapping.h:94:{ > asm/dma-mapping.h:95: return hppa_dma_ops->map_sg(dev, sg, nents, direction); > asm/dma-mapping.h:96:} > > Then search for hppa_dma_ops in arch/parisc/kernel/* and drivers/parisc/*.c > to locate the various platform/chipset DMA support: > > grundler <553>fgrep -n hppa_dma_ops arch/parisc/kernel/*c drivers/parisc/* > arch/parisc/kernel/drivers.c:30:struct hppa_dma_ops *hppa_dma_ops; > arch/parisc/kernel/drivers.c:31:EXPORT_SYMBOL(hppa_dma_ops); > arch/parisc/kernel/pci-dma.c:492:struct hppa_dma_ops pcxl_dma_ops = { > arch/parisc/kernel/pci-dma.c:533:struct hppa_dma_ops pcx_dma_ops = { > arch/parisc/kernel/setup.c:96: hppa_dma_ops = &pcx_dma_ops; > arch/parisc/kernel/setup.c:101: hppa_dma_ops = &pcxl_dma_ops; > drivers/parisc/ccio-dma.c:1009:static struct hppa_dma_ops ccio_ops = { > drivers/parisc/ccio-dma.c:1545: hppa_dma_ops = &ccio_ops; > drivers/parisc/ccio-rm-dma.c:183: hppa_dma_ops = &ccio_ops; > drivers/parisc/sba_iommu.c:1177:static struct hppa_dma_ops sba_ops = { > drivers/parisc/sba_iommu.c:1809: hppa_dma_ops = &sba_ops; > > Ideally, "make" would detect when support for only one chipset is > needed and just do away with hppa_dma_ops completely (ie directly > call into the chipset specific function). > > >>Thanks in advance, >> Joel >> >>PS: btw I noticed that ncr_attach() is still prefix by __init where >>sym_attach() is now prefix by __devinit. I trust it is important but could >>it be the simple reason of pb encounter? > > > IIRC, the difference is for hotplug. > __devinit section is preserved when CONFIG_HOTPLUG is enabled. > See linux/Documentation/pci.txt for the real description. > > grant > Great. Many thanks, Joel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] 2004-04-18 16:36 ` James Bottomley 2004-04-18 17:16 ` Joel Soete 2004-04-19 16:53 ` Joel Soete @ 2004-04-21 10:08 ` Joel Soete 2 siblings, 0 replies; 17+ messages in thread From: Joel Soete @ 2004-04-21 10:08 UTC (permalink / raw) To: James Bottomley; +Cc: PARISC list, Andy Walker [-- Attachment #1: Type: text/plain, Size: 4422 bytes --] > > > > On Sun, 2004-04-18 at 09:39, Joel Soete wrote: > > I presume that wrong stuff come from the ccio_fill_pdir() or ccio_coalesce_chunks() merge with lba one? > > But I don't have yet more accurate idea on what went wrong here (difference between functions are important). My abd: I effectively analyse the differences between those function and their nes release and there are few > > > > (would it help to rebuild this same kernel tree with gcc-3.0 32bit would help? right now is was build with latest gcc-3.3.3.) > > > Well, actually, the problem can't be in the code you cite, otherwise my > raven wouldn't work either and it's been fine. > So why reverting only this stuff make kernel works? The idea is in this hunck: @@ -1708,6 +1556,7 @@ proc_runway_root, ccio_resource_map, NULL); } parisc_vmerge_boundary = IOVP_SIZE; + parisc_vmerge_max_size = BITS_PER_LONG * IOVP_SIZE; ioc_count++; return 0; } Reverting this, let parisc_vmerge_max_size = 0 as initialized in gsc.c (it is confirm by adding some printk() in ll_rw_blk and bio code) this btw confirms your idea. Learning so ncr53c8xx code, I found small trivial patches: diff -NaurX dontdiff linux-2.6.6-rc1-pa0.orig/drivers/parisc/ccio-dma.c linux-2.6.6-rc1-pa0/drivers/parisc/ccio-dma.c --- linux-2.6.6-rc1-pa0.orig/drivers/parisc/ccio-dma.c 2004-03-16 16:40:23.000000000 +0100 +++ linux-2.6.6-rc1-pa0/drivers/parisc/ccio-dma.c 2004-04-21 10:32:11.000000000 +0200 @@ -441,7 +447,7 @@ BUG_ON((pages_mapped * IOVP_SIZE) > DMA_CHUNK_SIZE); BUG_ON(pages_mapped > BITS_PER_LONG); - DBG_RES("%s(): res_idx: %d pages_mapped %d\n", + DBG_RES("%s(): res_idx: %d pages_mapped %ld\n", __FUNCTION__, res_idx, pages_mapped); #ifdef CCIO_MAP_STATS @@ -766,7 +772,7 @@ pdir_start = &(ioc->pdir_base[idx]); - DBG_RUN("%s() 0x%p -> 0x%lx size: %0x%x\n", + DBG_RUN("%s() 0x%p -> 0x%lx size: 0x%x\n", __FUNCTION__, addr, (long)iovp | offset, size); /* If not cacheline aligned, force SAFE_DMA on the whole mess */ diff -NaurX dontdiff linux-2.6.6-rc1-pa0.orig/drivers/parisc/iommu-helpers.h linux-2.6.6-rc1-pa0/drivers/parisc/iommu-helpers.h --- linux-2.6.6-rc1-pa0.orig/drivers/parisc/iommu-helpers.h 2004-03-12 17:37:31.000000000 +0100 +++ linux-2.6.6-rc1-pa0/drivers/parisc/iommu-helpers.h 2004-04-21 10:46:33.000000000 +0200 @@ -22,14 +22,15 @@ /* Horrible hack. For efficiency's sake, dma_sg starts one * entry below the true start (it is immediately incremented * in the loop) */ - dma_sg--; + dma_sg--; while (nents-- > 0) { unsigned long vaddr; long size; DBG_RUN_SG(" %d : %08lx/%05x %08lx/%05x\n", nents, - (unsigned long)sg_dma_address(startsg), cnt, + (unsigned long)sg_dma_address(startsg), + sg_dma_len(startsg), sg_virt_addr(startsg), startsg->length ); diff -NaurX dontdiff linux-2.6.6-rc1-pa0.orig/drivers/scsi/ncr53c8xx.c linux-2.6.6-rc1-pa0/drivers/scsi/ncr53c8xx.c --- linux-2.6.6-rc1-pa0.orig/drivers/scsi/ncr53c8xx.c 2004-03-16 16:40:24.000000000 +0100 +++ linux-2.6.6-rc1-pa0/drivers/scsi/ncr53c8xx.c 2004-04-21 11:11:06.855459160 +0200 @@ -3710,11 +3710,11 @@ ** **========================================================== */ -static int ncr_queue_command (struct ncb *np, struct scsi_cmnd *cmd) +static int ncr_queue_command(struct ncb *np, struct scsi_cmnd *cmd) { /* struct scsi_device *device = cmd->device; */ - struct tcb *tp = &np->target[cmd->device->id]; - struct lcb *lp = tp->lp[cmd->device->lun]; + struct tcb *tp = &np->target[cmd->device->id]; + struct lcb *lp = tp->lp[cmd->device->lun]; struct ccb *cp; int segments; @@ -8604,8 +8604,8 @@ int unit, struct ncr_device *device) { struct host_data *host_data; - struct ncb *np = 0; - struct Scsi_Host *instance = 0; + struct ncb *np = NULL; + struct Scsi_Host *instance = NULL; u_long flags = 0; int i; ================================================================================ Is that possible that you ci (i don't have cvs write access). Thanks in advance, Joel PS: As usual because of wrapping pb of my interface, I also attached the diff file ;) ---------------------------------------------------------------------------------------- Tiscali ADSL: 35 €/mois, la meilleure offre du marché! http://reg.tiscali.be/default.asp?lg=fr [-- Attachment #2: 2.6.6-rc1-pa0.diff --] [-- Type: application/octet-stream, Size: 2751 bytes --] diff -NaurX dontdiff linux-2.6.6-rc1-pa0.orig/drivers/parisc/ccio-dma.c linux-2.6.6-rc1-pa0/drivers/parisc/ccio-dma.c --- linux-2.6.6-rc1-pa0.orig/drivers/parisc/ccio-dma.c 2004-03-16 16:40:23.000000000 +0100 +++ linux-2.6.6-rc1-pa0/drivers/parisc/ccio-dma.c 2004-04-21 10:32:11.000000000 +0200 @@ -441,7 +447,7 @@ BUG_ON((pages_mapped * IOVP_SIZE) > DMA_CHUNK_SIZE); BUG_ON(pages_mapped > BITS_PER_LONG); - DBG_RES("%s(): res_idx: %d pages_mapped %d\n", + DBG_RES("%s(): res_idx: %d pages_mapped %ld\n", __FUNCTION__, res_idx, pages_mapped); #ifdef CCIO_MAP_STATS @@ -766,7 +772,7 @@ pdir_start = &(ioc->pdir_base[idx]); - DBG_RUN("%s() 0x%p -> 0x%lx size: %0x%x\n", + DBG_RUN("%s() 0x%p -> 0x%lx size: 0x%x\n", __FUNCTION__, addr, (long)iovp | offset, size); /* If not cacheline aligned, force SAFE_DMA on the whole mess */ diff -NaurX dontdiff linux-2.6.6-rc1-pa0.orig/drivers/parisc/iommu-helpers.h linux-2.6.6-rc1-pa0/drivers/parisc/iommu-helpers.h --- linux-2.6.6-rc1-pa0.orig/drivers/parisc/iommu-helpers.h 2004-03-12 17:37:31.000000000 +0100 +++ linux-2.6.6-rc1-pa0/drivers/parisc/iommu-helpers.h 2004-04-21 10:46:33.000000000 +0200 @@ -22,14 +22,15 @@ /* Horrible hack. For efficiency's sake, dma_sg starts one * entry below the true start (it is immediately incremented * in the loop) */ - dma_sg--; + dma_sg--; while (nents-- > 0) { unsigned long vaddr; long size; DBG_RUN_SG(" %d : %08lx/%05x %08lx/%05x\n", nents, - (unsigned long)sg_dma_address(startsg), cnt, + (unsigned long)sg_dma_address(startsg), + sg_dma_len(startsg), sg_virt_addr(startsg), startsg->length ); diff -NaurX dontdiff linux-2.6.6-rc1-pa0.orig/drivers/scsi/ncr53c8xx.c linux-2.6.6-rc1-pa0/drivers/scsi/ncr53c8xx.c --- linux-2.6.6-rc1-pa0.orig/drivers/scsi/ncr53c8xx.c 2004-03-16 16:40:24.000000000 +0100 +++ linux-2.6.6-rc1-pa0/drivers/scsi/ncr53c8xx.c 2004-04-21 11:11:06.855459160 +0200 @@ -3710,11 +3710,11 @@ ** **========================================================== */ -static int ncr_queue_command (struct ncb *np, struct scsi_cmnd *cmd) +static int ncr_queue_command(struct ncb *np, struct scsi_cmnd *cmd) { /* struct scsi_device *device = cmd->device; */ - struct tcb *tp = &np->target[cmd->device->id]; - struct lcb *lp = tp->lp[cmd->device->lun]; + struct tcb *tp = &np->target[cmd->device->id]; + struct lcb *lp = tp->lp[cmd->device->lun]; struct ccb *cp; int segments; @@ -8604,8 +8604,8 @@ int unit, struct ncr_device *device) { struct host_data *host_data; - struct ncb *np = 0; - struct Scsi_Host *instance = 0; + struct ncb *np = NULL; + struct Scsi_Host *instance = NULL; u_long flags = 0; int i; ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 @ 2004-04-26 16:52 Joel Soete 2004-04-26 17:11 ` Grant Grundler 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2004-04-26 16:52 UTC (permalink / raw) To: Grant Grundler; +Cc: parisc-linux Hi all, I know it shouldn't be the source of the pb but btw I noticed: > ncr53c8xx.c:7594: u_long baddr = map_scsi_single_data(np, cmd); cmd is a "struct scsi_cmnd *" (the parameter of ncr_scatter) > sym53c8xx_comm.h:699:static int __map_scsi_sg_data(struct device *dev, Scsi_Cmnd *cmd) ... sym53c8xx_comm.h:708: use_sg = dma_map_sg(dev, cmd->buffer, cmd->use_sg, dma_dir); and here cmd is a "Scsi_Cmnd *" which is so of different type because of "typedef struct scsi_cmnd Scsi_Cmnd" What should it be done? Thanks in advance for your attention, Joel ---------------------------------------------------------------------------------------- Tiscali ADSL: 35 €/mois, la meilleure offre du marché! http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 2004-04-26 16:52 [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 Joel Soete @ 2004-04-26 17:11 ` Grant Grundler 0 siblings, 0 replies; 17+ messages in thread From: Grant Grundler @ 2004-04-26 17:11 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux On Mon, Apr 26, 2004 at 06:52:40PM +0200, Joel Soete wrote: > and here cmd is a "Scsi_Cmnd *" which is so of different type because of > "typedef struct scsi_cmnd Scsi_Cmnd" uhm...the typedef says Scsi_Cmnd *IS* struct scsi_cmnd. Therefor "Scsi_Cmnd *" is the same type as "struct scsi_cmnd *". > What should it be done? Get rid of Scsi_Cmnd typedef? I personally consider it bad style to use both forms in the same subsystem and don't really care which is used. But that's an issue for the subsystem maintainer to decide. :^) grant ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-04-26 17:11 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-14 19:32 [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( Andy Walker
2004-04-14 20:52 ` Joel Soete
2004-04-15 7:05 ` Joel Soete
2004-04-16 11:19 ` Andy Walker
2004-04-17 18:10 ` Joel Soete
2004-04-17 20:49 ` Andy Walker
2004-04-17 21:32 ` Joel Soete
2004-04-17 23:00 ` [parisc-linux] kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] Joel Soete
2004-04-18 14:39 ` [parisc-linux] " Joel Soete
2004-04-18 16:36 ` James Bottomley
2004-04-18 17:16 ` Joel Soete
2004-04-19 16:53 ` Joel Soete
[not found] ` <408AD395.4060909@tiscali.be>
2004-04-24 22:19 ` [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 Grant Grundler
2004-04-24 22:31 ` Joel Soete
2004-04-21 10:08 ` [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(] Joel Soete
-- strict thread matches above, loose matches on Subject: below --
2004-04-26 16:52 [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 Joel Soete
2004-04-26 17:11 ` Grant Grundler
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.