Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Andy Walker]

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

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Joel Soete]

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
> 

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Joel Soete]

>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

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Andy Walker]

>>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

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Joel Soete]

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

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Andy Walker]

> 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

Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(

[Joel Soete]

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

[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]

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
> 

[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]

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
>>
> 

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 :(]

[James Bottomley]

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

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 :(]

[Joel Soete]

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

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 :(]

[Joel Soete]

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

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 :(]

[Joel Soete]

[-- 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;
 

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Grant Grundler]

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

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Joel Soete]

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

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Joel Soete]

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

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Grant Grundler]

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