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

[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

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;
 

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

[Joel Soete]

Hello Ryan,

>I finally had some time to compile a kernel and boot some systems today
>so I tested the latest CVS head on my C200 and a J200 to see if I could
>duplicate the problem you are seeing.
>
>The J200 is basically a dual processor C100 so it hould be very close
>to the C110 (i.e. no PCI, EISA based, etc)  The device names are
>different so I am not sure if it is close enough but I still think it is
>a relevant data point.
>
No more clue sorry

[snip]

>Would you be interested in trying the lifimage I complied and
>successfully booted on both the J200 and the C110?

Just a stupid question: where can I grab this lifimage?

> If the lifimage
>boots on your system then we localize the problem down to possible tool
>chain or .config problem (I used the defconfig).

Right I forgot to test defconfig.

That said, to get you more detail on my pb:
 - in genral i can reach to boot the system with 2.6.5-paX
 - the pb occurs when I try high i/o rate on disk (ie  a find, a fsck ,
a tar or some time a simple cp of the kernel from a fs to another one)
 - the pb can also occurs at boot time if a fs is not clear (a fsck is
so requested) or if a raid partition has to be sync (ie once again high i/o
rate on disks).

Thanks for your attention,

   Joel


PS: This system boot and mainly works always fine with a 2.4 and 2.6.3-rc1-pa3
(this is mainly this last one I used as reference), so I exclude hw pb ;)
(execpted that the battery saving system time (and more) has to be replaced)

hmm, I also read back my first report of a pb on this c110 and noticed that
everything appears for me when I tried 2.6.4-pa[12]. I so try to grab cvs
kernel tree dated of the Makefile 2.6.3-rc1-pa3 and a saved tbz of 2.6.4-pa2
to build a diff. The diff file is of about 14Mb :_(

Historically there was not a lot of big changes specific to parisc between
those releases: the main one being the jejb change in ccio-dma (and related).
I so try to revert it and it seems to works better (with 2 different config
file)
until system hang at boot again because it has to re-sync a md (the root)
device. It seems so that ccio-dma changes was not the cause but much better
a revelator of a hidden pb (In fact I never reach to work with 2.6 on this
c110 without replacing cio_mem_ratio = 4 by 2)







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

[Joel Soete]

>> If the lifimage
>>boots on your system then we localize the problem down to possible tool
>>chain  or .config problem (I used the defconfig).
>
>Right I forgot to test defconfig.

I remember now: I just used to use the defconfig of which I remove all HIL
support (no device available) for this c110 (no specific config file).

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

[Ryan Bradetich]

> >Would you be interested in trying the lifimage I complied and
> >successfully booted on both the J200 and the C110?
> 
> Just a stupid question: where can I grab this lifimage?

I can make this lifimage available ... I will you a url once I have this
setup.

> > If the lifimage
> >boots on your system then we localize the problem down to possible tool
> >chain or .config problem (I used the defconfig).
> 
> Right I forgot to test defconfig.
> 
> That said, to get you more detail on my pb:
>  - in genral i can reach to boot the system with 2.6.5-paX
>  - the pb occurs when I try high i/o rate on disk (ie  a find, a fsck ,
> a tar or some time a simple cp of the kernel from a fs to another one)
>  - the pb can also occurs at boot time if a fs is not clear (a fsck is
> so requested) or if a raid partition has to be sync (ie once again high i/o
> rate on disks).

Ah .. I was under the impression it was a boot problem.  I will perform
the find, fsck and tar tests tests ... I only have a small disk (~500MB)
in the system so i will probably need to setup some external disks.  I
will try the tests w/o using software raid first, then add in the
software raid as a an additional variable.  This may take me a couple of
days to get this accomplished (busy work schedule :().

Thanks!

- Ryan

> Thanks for your attention,
> 
>    Joel
> 
> 
> PS: This system boot and mainly works always fine with a 2.4 and 2.6.3-rc1-pa3
> (this is mainly this last one I used as reference), so I exclude hw pb ;)
> (execpted that the battery saving system time (and more) has to be replaced)
> 
> hmm, I also read back my first report of a pb on this c110 and noticed that
> everything appears for me when I tried 2.6.4-pa[12]. I so try to grab cvs
> kernel tree dated of the Makefile 2.6.3-rc1-pa3 and a saved tbz of 2.6.4-pa2
> to build a diff. The diff file is of about 14Mb :_(
> 
> Historically there was not a lot of big changes specific to parisc between
> those releases: the main one being the jejb change in ccio-dma (and related).
> I so try to revert it and it seems to works better (with 2 different config
> file)
> until system hang at boot again because it has to re-sync a md (the root)
> device. It seems so that ccio-dma changes was not the cause but much better
> a revelator of a hidden pb (In fact I never reach to work with 2.6 on this
> c110 without replacing cio_mem_ratio = 4 by 2)
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------------------
> Tiscali ADSL: 35 /mois, la meilleure offre du marché!
> http://reg.tiscali.be/default.asp?lg=fr
> 
> 
> 
> _______________________________________________
> 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 :(

[James Bottomley]

On Wed, 2004-04-14 at 09:36, Ryan Bradetich wrote:
> Ah .. I was under the impression it was a boot problem.  I will perform
> the find, fsck and tar tests tests ... I only have a small disk (~500MB)
> in the system so i will probably need to setup some external disks.  I
> will try the tests w/o using software raid first, then add in the
> software raid as a an additional variable.  This may take me a couple of
> days to get this accomplished (busy work schedule :().

It was (hence 'boot panic' in the title):

http://lists.parisc-linux.org/pipermail/parisc-linux/2004-March/022657.html

So, Joel, are you saying you no-longer see this boot panic problem?

James

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

[Joel Soete]

Hello James,

>> On Wed, 2004-04-14 at 09:36, Ryan Bradetich wrote:
>> Ah .. I was under the impression it was a boot problem.  I will perform
>> the find, fsck and tar tests tests ... I only have a small disk (~500MB)
>> in the system so i will probably need to setup 
>> ome external disks.  I
>> will try the tests w/o using software raid first, then add in the
>> software raid as a an additional variable.  This may take me a couple
of
>> days to get this accomplished (busy work schedule :().
>
>It was (hence 'boot panic' in the title):
>
>http://lists.parisc-linux.org/pipermail/parisc-linux/2004-March/022657.html

You have absolutly right, please apologies. My wory was to follow up a single
thread: bad idea to not modify the title :(

>So, Joel, are you saying you no-longer see this boot panic problem?

Yes not anymore this panic :)

(sometime, the system still panic but far later, after a fsck or a md sync
[sorry I don't remember with enough acuracy]).

Thanks,
   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 :(

[Joel Soete]

Hello Ryan,

>> > >Would you be interested in trying the lifimage I complied and
>> >successfully booted on both the J200 and the C110?
>> 
>> Just a stupid question: where can I grab this lifimage?
>
>I can make this lifimage available ... I will you a url once I have
> this setup.

Great.

>Ah .. I was under the impression it was a boot problem.  I will perform
>the find, fsck and tar tests tests ... I only have a small disk (~500MB)
>in the system so i will probably need to setup some external disks.  I
>will try the tests w/o using software raid first,

Well I didn't suspect raid support because at my office there a 2 running
raid system happy with 2.6.5 though

> then add in the
>software raid as a an additional variable.

But that is logical ;)

>  This may take me a couple of
>days to get this accomplished (busy work schedule :().

Don't worry, for me it's just for fun (but nothing must be more serious than
thaking fun :) )

Thanks a lot for all,
    Joel

----------------------------------------------------------------------------------------
Tiscali ADSL: 35 €/mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr

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

[Joel Soete]

Hi all,

I just co last cvs kernel 2.6.5-rc2-pa2 and rebuild it last b180 config file on my c110 but still boot panic with following dmesg:
Linux version 2.6.5-rc2-pa2 (root@hpalin) (gcc version 3.3.3 (Debian 20040306)) #1 Sun Mar 21 13:27:53 CET 2004
FP[0] enabled: Rev 1 Model 11
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 000058e0 00000481 00000000 00000002 77e47570 100000f1 00000004 0000008a 0000008a
vers  0000000d
CPUID vers 11 rev 13 (0x0000016d)
model 9000/777/C110
Total Memory: 128 Mb
On node 0 totalpages: 32768
   DMA zone: 32768 pages, LIFO batch:8
   Normal zone: 0 pages, LIFO batch:1
   HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/md2 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=3/vmlinux-2.6.5-rc2-pa2
PID hash table entries: 16 (order 4: 128 bytes)
Console: colour dummy device 160x64
Memory: 126200k available
Calibrating delay loop... 119.60 BogoMIPS
Security Scaffold v1.0.0 initialized
Capability LSM initialized
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port at 0xfff88000 [8] { 12, 0x7, 0x580, 0x0000b }
2. SkyHawk 100/120 FW-SCSI at 0xf3f8c000 [8/12] { 4, 0x0, 0x01f, 0x00089 }
3. Raven T' Core BA at 0xffd00000 [8/16] { 11, 0x0, 0x032, 0x00081 },  additional addresses: 0xffd0c000 0xffc00000
4. Raven T' Core Centronics at 0xffd02000 [8/16/0] { 10, 0x0, 0x032, 0x00074 },  additional addresses: 0xffd01000 0xffd03000
5. Raven T' Audio at 0xffd04000 [8/16/1] { 10, 0x0, 0x032, 0x0007b }
6. Raven T' Lasi Core RS-232 at 0xffd05000 [8/16/4] { 10, 0x0, 0x032, 0x0008c }
7. Raven T' Core SCSI at 0xffd06000 [8/16/5] { 10, 0x0, 0x032, 0x00082 }
8. Raven T' Core LAN (802.3) at 0xffd07000 [8/16/6] { 10, 0x0, 0x032, 0x0008a }
9. Raven T' Core PS/2 Port at 0xffd08000 [8/16/7] { 10, 0x0, 0x032, 0x00084 }
10. Raven T' Core PS/2 Port at 0xffd08100 [8/16/8] { 10, 0x0, 0x032, 0x00084 }
11. Raven T' Core PC Floppy at 0xffd0a000 [8/16/10] { 10, 0x0, 0x032, 0x00083 }
12. Raven T' Wax BA at 0xffe00000 [8/20] { 11, 0x0, 0x01e, 0x0008e },  additional addresses: 0xffe03000 0xffe06000
13. Raven T' Wax HIL at 0xffe01000 [8/20/1] { 10, 0x0, 0x01e, 0x00073 }
14. Raven T' Wax RS-232 at 0xffe02000 [8/20/2] { 10, 0x0, 0x01e, 0x0008c }
15. Raven T' Wax EISA BA at 0xfc000000 [8/20/5] { 11, 0x0, 0x01e, 0x00090 },  additional addresses: 0xffc88400 0xf4000000
16. U2-IOA BC GSC+ Port at 0xf3fbf000 [8/63] { 7, 0x1, 0x501, 0x0000c },  additional addresses: 0xf3f80000
17. U2-IOA BC Runway Port at 0xfff8a000 [10] { 12, 0x7, 0x580, 0x0000b }
18. Raven T' GSC Core Graphics at 0xf4000000 [10/16] { 10, 0x0, 0x032, 0x00085 },  additional addresses: 0xf0069000
19. U2-IOA BC GSC+ Port at 0xf3fff000 [10/63] { 7, 0x1, 0x501, 0x0000c }
20. Raven 120 T' at 0xfffa0000 [32] { 0, 0x0, 0x58e, 0x00004 }
21. Memory at 0xfffb1000 [49] { 1, 0x0, 0x049, 0x00009 }
CPU(s): 1 x PA7200 (PCX-T') at 120.000000 MHz
Lasi version 0 at 0xffd00000 found.
Wax at 0xffe00000 found.
Wax EISA Adapter found at 0xfc000000
EISA EEPROM: cannot register misc device.
Enumerating EISA bus
EISA: Probing bus 0 at parisc8:20:5
EISA: Mainboard HWPC0E1 detected.
EISA: Detected 0 cards.
SCSI subsystem initialized
STI GSC/PCI core graphics driver Version 0.9a
     id 2b4ded6d-40a00499, conforms to spec rev. 8.04
     graphics card name: HPA208LC1024
fb0: stifb 1024x768-8 frame buffer device, HPA208LC1024, id: 2b4ded6d, mmio: 0xf4100000
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Soft power switch enabled, polling @ 0xf0140000.
Console: switching to colour frame buffer device 128x48
lp: driver loaded but no devices found
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 13 ports, IRQ sharing enabled
ttyS0 at MMIO 0xffd05800 (irq = 90) is a 16550A
ttyS1 at MMIO 0xffe02800 (irq = 121) is a 16550A
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
lp0: using parport0 (interrupt-driven).
loop: loaded (max 8 devices)
PPP generic driver version 2.4.2

Stack Dump:
  10594718:  10594718 1035c010 00000000 39158180
  10594708:  1042dc80 1035b1c8 1035d7c4 10368270
  105946f8:  00000004 00002e92 00002e94 1014133c
  105946e8:  100fe640 17fdf080 fffffff4 100fe64c
  105946d8:  1035d7c4 1035d7c4 000000b5 00000000
  105946c8:  10594380 0000001a 00000000 10368270
  105946b8:  00000004 00002e89 00002e92 1010401c
  105946a8:  1035c010 00000000 39158180 1042dc80
  10594698:  1035b1c8 1035d7c4 000000b5 00000001
  10594688:  1035db0c 17fe9a50 000000d0 17ff8b2c
  10594678:  00000000 17ff8b2c 000000d0 00000001
  10594668:  00000001 000000d0 1042dc80 1035b1c8
  10594658:  3b9aca00 ffd06100 17f390c0 1036e578
  10594648:  17fdd600 17fe9a50 00000010 17ff8ab8
  10594638:  00000080 17ff8ab8 000000d0 101414c8
  10594628:  00000001 000000d0 100d7084 17ff8ab8
  10594618:  100d7040 100e4000 100d7f38 100d7f38
  10594608:  00000001 000000d0 000000d0 17ff8ab8
  105945f8:  00000040 17ff8ab8 000000d0 1014492c
  105945e8:  00000001 000000d0 1042dc80 1035b1c8
  105945d8:  3b9aca00 1035d010 1042d810 00000001
  105945c8:  1035db0c 17fe9a50 00000010 10031640
  105945b8:  105f2400 10444404 1036f010 10109088
  105945a8:  10445010 00000000 1035e810 10594408
  10594598:  17ff2b20 00000000 000000f3 0098963a
  10594588:  39158180 1042dc80 fffffff4 17ff8ab8
  10594578:  00000000 17ff8ab8 000000d0 10174e34
  10594568:  00000001 00000000 17ff2b20 10594408
  10594558:  00000000 00000000 00000000 00000000
  10594548:  0e601096 0000000e 100e46c0 10368270
  10594538:  00000004 17fedd00 10594388 103bdd20
  10594528:  103bdd1c 00000000 00000000 00000000
  10594518:  00000000 00000000 00000000 00000000
  10594508:  00000000 00000000 00000000 00000000
  105944f8:  41000000 00000000 40800000 00000000
  105944e8:  40000000 00000000 40000000 7fffffff
  105944d8:  41800000 00000000 40200000 00000000
  105944c8:  40200000 00000000 40300000 00000000
  105944b8:  41000000 00000000 40800000 7fffffff
  105944a8:  7fffffff 00000000 41000000 7fffffff
  10594498:  7fffffff 00000800 00000400 00000200
  10594488:  00000100 00000080 00000040 00000000
  10594478:  00000000 00000010 00000010 00000000
  10594468:  41800000 25b7ea20 45e69c6a 00000000
  10594458:  00000000 e0000000 43ebebeb ffffffff
  10594448:  7f7fffff 00000020 00000010 00000000
  10594438:  00000000 00000000 00000000 00000000
  10594428:  00000000 00000000 00000000 00000000
  10594418:  0000001f 00000000 0000001f 00000000
  10594408:  0000001f 00000000 000b0800 1010cb30
  105943f8:  10594380 3a699d00 17f390c0 10346010
  105943e8:  17fdd688 00000000 ffffffff 00000000
  105943d8:  17f3910c 00000000 00000000 00000000
  105943c8:  f00000a4 f00000ac f00010f4 1042d810
  105943b8:  1035d010 3b9aca00 1035b1c8 1042dc80
  105943a8:  ffffffff 00000000 000000f3 17fdd688
  10594398:  17fdd600 1036e578 17f390c0 ffd06100
  10594388:  103bdbe8 1042b010 0004ff0f 10368270
  10594378:  00000004 00002f25 00002f42 103bdbcc
  10594368:  10364178 00000400 1042e810 1036dab4
  10594358:  103641c4 1035c010 00000000 1036e5a0
  10594348:  1036e5a0 10348544 1036e5a0 10368270
  10594338:  00000004 00002f73 00002f94 101907c4
  10594328:  1036dab8 1036dab8 00000014 1036dab4

Kernel addresses on the stack:
  [<101242ac>] call_console_drivers+0xd4/0x17c
  [<10103d68>] parisc_terminate+0x60/0xb4
  [<1014133c>] buffered_rmqueue+0xfc/0x1bc
  [<1010401c>] handle_interruption+0x260/0x560
  [<101414c8>] __alloc_pages+0xcc/0x378
  [<1014492c>] cache_init_objs+0xb0/0xb8
  [<10109088>] intr_check_sig+0x0/0xc
  [<10174e34>] d_alloc+0x34/0x1f0
  [<103bdd20>] lasi700_probe+0x190/0x1cc
  [<103bdbcc>] lasi700_probe+0x3c/0x1cc
  [<101907c4>] sysfs_create_dir+0x3c/0x80
  [<1010cb30>] parisc_driver_probe+0x2c/0x60
  [<102197c8>] bus_match+0x4c/0x84
  [<10219934>] driver_attach+0x80/0xa8
  [<101e8498>] kobject_register+0x28/0x64
  [<10219c10>] bus_add_driver+0xac/0xbc
  [<101e83cc>] kobject_add+0x54/0xf8
  [<10219fc0>] driver_register+0x44/0x50
  [<103bdb6c>] NCR_700_init+0x18/0x3c
  [<103a9384>] do_initcalls+0x58/0xfc
  [<101001d0>] init+0x28/0xd0
  [<10108c5c>] ret_from_kernel_thread+0x1c/0x24


Kernel Fault: Code=26 regs=10594380 (Addr=00000000)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 1042b010 103bdbe8 ffd06100
r04-07  17f390c0 1036e578 17fdd600 17fdd688
r08-11  000000f3 00000000 ffffffff 1042dc80
r12-15  1035b1c8 3b9aca00 1035d010 1042d810
r16-19  f00010f4 f00000ac f00000a4 00000000
r20-23  00000000 00000000 17f3910c 00000000
r24-27  ffffffff 00000000 17fdd688 10346010
r28-31  17f390c0 3a699d00 10594380 1010cb30
sr0-3   00000000 00000000 00000000 00000000
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 103bdd1c 103bdd20
  IIR: 0e601096    ISR: 00000000  IOR: 00000000
  CPU:        0   CR30: 10594000 CR31: 103a0000
  ORIG_R28: 00000004
  IAOQ[0]: lasi700_probe+0x18c/0x1cc
  IAOQ[1]: lasi700_probe+0x190/0x1cc
  RP(r2): lasi700_probe+0x58/0x1cc

hth,
	Joel

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

[Grant Grundler]

On Sun, Mar 21, 2004 at 01:17:04PM +0000, Joel Soete wrote:
...
> PPP generic driver version 2.4.2
...
> Kernel addresses on the stack:

[ looks a bit scrambled ]

...
> Kernel Fault: Code=26 regs=10594380 (Addr=00000000)

null ptr deref.

...
>  IAOQ[0]: lasi700_probe+0x18c/0x1cc
>  IAOQ[1]: lasi700_probe+0x190/0x1cc
>  RP(r2): lasi700_probe+0x58/0x1cc

IOAQ[0] is the offending instruction.
Brute force debug method is to start adding
printk's to lasi700_probe. It shouldn't take
more than a few iterations to find the offending line.

grant

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

[Joel Soete]

Hello Grant,

>> ...
>>  IAOQ[0]: lasi700_probe+0x18c/0x1cc
>>  IAOQ[1]: lasi700_probe+0x190/0x1cc
>>  RP(r2): lasi700_probe+0x58/0x1cc
>
>IOAQ[0] is the offending instruction.
>Brute force debug method is to start adding
>printk's to lasi700_probe. It shouldn't take
>more than a few iterations to find the offending line.

Thanks, I will foreseen such work next week-end :)

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

[Grant Grundler]

On Sun, Mar 21, 2004 at 12:57:16PM -0700, Grant Grundler wrote:
> > Kernel Fault: Code=26 regs=10594380 (Addr=00000000)
> 
> null ptr deref.
> 
> ...
> >  IAOQ[0]: lasi700_probe+0x18c/0x1cc
> >  IAOQ[1]: lasi700_probe+0x190/0x1cc
> >  RP(r2): lasi700_probe+0x58/0x1cc
> 
> IOAQ[0] is the offending instruction.

James Bottomley observed a problem with hppa_dma_ops
not being set properly for his U2/Uturn box.
This is likely the same problem.
See ccio driver isn't claiming the chip when it should.

grant

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

[Joel Soete]

Hello Grant,

Back to all with this pb

Grant Grundler wrote:
> On Sun, Mar 21, 2004 at 12:57:16PM -0700, Grant Grundler wrote:
> 
>>>Kernel Fault: Code=26 regs=10594380 (Addr=00000000)
>>
>>null ptr deref.
>>
>>...
>>
>>> IAOQ[0]: lasi700_probe+0x18c/0x1cc
>>> IAOQ[1]: lasi700_probe+0x190/0x1cc
>>> RP(r2): lasi700_probe+0x58/0x1cc
>>
>>IOAQ[0] is the offending instruction.

First of all this is my fault: for this b2k I used to compile the 2.6 kernel with b180 config :(
But I didn't notice that there was recently changes in this file.
To solve this pb I so had to add 'U2/Uturn I/O MMU' and also Zalon to make it bootable again (and finaly 'Lasi ethernet' to just 
have network access :) ).

> 
> 
> James Bottomley observed a problem with hppa_dma_ops
> not being set properly for his U2/Uturn box.
> This is likely the same problem.
> See ccio driver isn't claiming the chip when it should.
> 
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]
[<10108c5c>] ret_from_kernel_thread+0x1c/0x24

I so added some printk as follow in  drivers/block/as-iosched.c
[snip]
static void as_requeue_request(request_queue_t *q, struct request *rq)
{
         struct as_data *ad = q->elevator.elevator_data;
         struct as_rq *arq = RQ_DATA(rq);

         if (arq) {
                 if (arq->state != AS_RQ_REMOVED) {
                         printk("arq->state %d\n", arq->state);
                         WARN_ON(1);
                 }

/* JSO */
                 printk("as_requeue_request will now set arq->state.\n");
/* JSO */
                 arq->state = AS_RQ_DISPATCHED;
/* JSO */
                 printk("as_requeue_request has just set arq->state.\n");
                 if (arq->io_context && arq->io_context->aic)
                         printk("as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).\n");
/* JSO */
                 if (arq->io_context && arq->io_context->aic)
                         atomic_inc(&arq->io_context->aic->nr_dispatched);
                 printk("finished if (arq).\n");
         } else
                 WARN_ON(blk_fs_request(rq)
                         && (!(rq->flags & (REQ_HARDBARRIER|REQ_SOFTBARRIER))) );

         printk("as_requeue_request will now list_add().\n");
         list_add(&rq->queuelist, ad->dispatch);
         printk("as_requeue_request has just list_add().\n");

         /* Stop anticipating - let this request get through */
         printk("as_requeue_request will now (as_antic_stop(%p)).\n", ad);
         as_antic_stop(ad);
         printk("as_requeue_request has just (as_antic_stop(%p)).\n", ad);
}
[snip]

And here is a sample of what I can grab from serial console when I trigger a find:
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b89a0)).
as_requeue_request has just (as_antic_stop(100b89a0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b89a0)).
as_requeue_request has just (as_antic_stop(100b89a0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b89a0)).
as_requeue_request has just (as_antic_stop(100b89a0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b89a0)).
as_requeue_request has just (as_antic_stop(100b89a0)).
arq->state 2
Badness in as_requeue_request at drivers/block/as-iosched.c:1479
Kernel addresses on the stack:
  [<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

as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b89a0)).
as_requeue_request has just (as_antic_stop(100b89a0)).

as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b8aa0)).
as_requeue_request has just (as_antic_stop(100b8aa0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b8aa0)).
as_requeue_request has just (as_antic_stop(100b8aa0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b8aa0)).
as_requeue_request has just (as_antic_stop(100b8aa0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b8aa0)).
as_requeue_request has just (as_antic_stop(100b8aa0)).
as_requeue_request will now set arq->state.
as_requeue_request has just set arq->state.
as_requeue_request will now atomic_inc(&arq->io_context->aic->nr_dispatched).
finished if (arq).
as_requeue_request will now list_add().
as_requeue_request has just list_add().
as_requeue_request will now (as_antic_stop(100b8aa0)).
as_requeue_request has just (as_antic_stop(100b8aa0)).
[snip]

it seems to be infinite loop :(

Any idea?

Thanks in advance,
     Joel

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

[Joel Soete]

Hi James,

I come back to you with your ccio-dma patch because I don't undertand this part:
[snip]
#ifdef CONFIG_PROC_FS
/*
  * CCIO_SEARCH_TIME can help measure how fast the bitmap search is.
  * impacts performance though - ditch it if you don't use it.
  */
#define CCIO_SEARCH_TIME
#undef CCIO_MAP_STATS
#else
#undef CCIO_SEARCH_TIME
#undef CCIO_MAP_STATS
#endif

CCIO_MAP_STATS is always undef?

Could it be the panic reason of my c110 (_apparently_ since this patch)?

Thanks in advance for your attention,
	Joel


Grant Grundler wrote:
> On Sun, Mar 21, 2004 at 12:57:16PM -0700, Grant Grundler wrote:
> 
>>>Kernel Fault: Code=26 regs=10594380 (Addr=00000000)
>>
>>null ptr deref.
>>
>>...
>>
>>> IAOQ[0]: lasi700_probe+0x18c/0x1cc
>>> IAOQ[1]: lasi700_probe+0x190/0x1cc
>>> RP(r2): lasi700_probe+0x58/0x1cc
>>
>>IOAQ[0] is the offending instruction.
> 
> 
> James Bottomley observed a problem with hppa_dma_ops
> not being set properly for his U2/Uturn box.
> This is likely the same problem.
> See ccio driver isn't claiming the chip when it should.
> 
> grant
> 

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

[Grant Grundler]

On Fri, Apr 09, 2004 at 08:47:27PM +0000, Joel Soete wrote:
> /*
>  * CCIO_SEARCH_TIME can help measure how fast the bitmap search is.
>  * impacts performance though - ditch it if you don't use it.
>  */
> #define CCIO_SEARCH_TIME
> #undef CCIO_MAP_STATS
> #else
> #undef CCIO_SEARCH_TIME
> #undef CCIO_MAP_STATS
> #endif
> 
> CCIO_MAP_STATS is always undef?

yes - it interfers with DMA mapping performance.

> Could it be the panic reason of my c110 (_apparently_ since this patch)?

Not likely.
The above disables code that is (should!) not affect basic functionality.
CCIO_MAP_STATS just collects data for /proc/bus/runway/... output.

grant

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

[Joel Soete]

Grant,

Thanks.

I will so just reversed mentioned patches, check if it is the real cause of my pb.
If yes (I don't see what else) re-apply patch hunk by hunk until it breaks again?

Any better idea?

Joel


Grant Grundler wrote:
> On Fri, Apr 09, 2004 at 08:47:27PM +0000, Joel Soete wrote:
> 
>>/*
>> * CCIO_SEARCH_TIME can help measure how fast the bitmap search is.
>> * impacts performance though - ditch it if you don't use it.
>> */
>>#define CCIO_SEARCH_TIME
>>#undef CCIO_MAP_STATS
>>#else
>>#undef CCIO_SEARCH_TIME
>>#undef CCIO_MAP_STATS
>>#endif
>>
>>CCIO_MAP_STATS is always undef?
> 
> 
> yes - it interfers with DMA mapping performance.
> 
> 
>>Could it be the panic reason of my c110 (_apparently_ since this patch)?
> 
> 
> Not likely.
> The above disables code that is (should!) not affect basic functionality.
> CCIO_MAP_STATS just collects data for /proc/bus/runway/... output.
> 
> grant
> 

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

[Grant Grundler]

On Sat, Apr 10, 2004 at 08:32:04AM +0000, Joel Soete wrote:
> I will so just reversed mentioned patches, check if it is the real
> cause of my pb.

ok

> If yes (I don't see what else) re-apply patch hunk by hunk until it breaks 
> again?

That won't work with the changes to ccio driver. It's all or nothing.

> Any better idea?

I don't understand why C360 (James' machine) works and C110 (your machine)
does not.  C110 doesn't have PCI and maybe different keyboard/LAN.
Find out what is different between the two machines and see if ccio
changes broke one of the drivers for the different HW.

You might need to add pdc_io_reset_devices() to ccio_ioc_init()
since we moved that out of the common code path. I don't see that
in CCIO driver and it's not clear to me if HIL or LAN need it on C110.

It *might* need pdc_io_reset() call instead (or in addition)
but I don't know.  Just another thing to be aware of.

grant

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

[Joel Soete]

Grant Grundler wrote:
> On Sat, Apr 10, 2004 at 08:32:04AM +0000, Joel Soete wrote:
> 
>>I will so just reversed mentioned patches, check if it is the real
>>cause of my pb.
> 
> 
> ok
> 

Well I reach to reverted it and the result is a booting and operational kernel.
oops, my bad: I also reverted my config. Very stupid of my part, I just have re-do test; sorry

> 
>>If yes (I don't see what else) re-apply patch hunk by hunk until it breaks 
>>again?
> 
> 
> That won't work with the changes to ccio driver. It's all or nothing.
> 
(I see, any way there was 2 steps for this patch and I don't have the opportunity to test the first step alone?)
> 
>>Any better idea?
> 
> 
> I don't understand why C360 (James' machine) works and C110 (your machine)
> does not.  C110 doesn't have PCI and maybe different keyboard/LAN.
> Find out what is different between the two machines and see if ccio
> changes broke one of the drivers for the different HW.
> 
C110's Devices						      |	C360's Devices

Raven 120 T' (Processor)  (PA7200 (PCX-T'))		      |	Raven W 360 (9000/780/????) (Processor)  (PA8500 (PCX-W))
SkyHawk 100/120 (Memory)				      |	Raven W 360 Memory (Memory)
SkyHawk 100/120 FW-SCSI (A DMA) (Zalon driver)		      |	Raven U/L2 Dino RS-232 (Foreign I/O Module) (Serial driver)
Raven T' Core Centronics (Foreign I/O Module) (Parallel drive |	Raven+ w Core Centronics (Foreign I/O Module) (Paral
Raven T' Audio (Foreign I/O Module) (Harmony driver)	      |	Raven+ w Core Audio (Foreign I/O Module) (Harmony d
Raven T' Lasi Core RS-232 (Foreign I/O Module) (Serial driver |	Raven+ w Core RS-232 (Foreign I/O Module) (Serial d
Raven T' Core SCSI (Foreign I/O Module) (NCR53c710 driver)    |	Raven+ w Core SCSI (Foreign I/O Module) (NCR53c710
Raven T' Core LAN (802.3) (Foreign I/O Module) (Lasi_82596 dr |	Raven+ w Core PC Keyboard (Foreign I/O Module) (PS/
Raven T' Core PC Keyboard (Foreign I/O Module) (PS/2 driver)  |	Raven+ w Core BA (Bus Adapter) (Lasi driver)
Raven T' Core PC Floppy (Foreign I/O Module)		      <
Raven T' Wax HIL (Foreign I/O Module) (HIL driver)	      <
Raven T' Wax RS-232 (Foreign I/O Module) (Serial driver)      <
Raven T' GSC Core Graphics (Foreign I/O Module)		      <
Raven T' Core BA (Bus Adapter) (Lasi driver)		      <
Raven T' Wax BA (Bus Adapter) (Wax driver)		      <
Raven T' Wax EISA BA (Bus Adapter)			      <
U2-IOA BC Runway Port (IOA) (x2)				U2-IOA BC Runway Port (IOA) (x2)
							      >	Dino PCI Bridge (Bus Bridge to Foreign Bus) (Dino driver)
							      >	Cujo PCI Bridge (Bus Bridge to Foreign Bus) (Dino driver)
							      >
							      >	53c875 (Symbios Logic Inc. (formerly NCR)) (SYM8xx driver)
							      >	DECchip 21142/43 (Digital Equipment Corporation) (Tulip drive
							      >	Visualize FX4 (Hewlett-Packard Company)

This is diff -y of devices list grab from web h/w db (may be c360 list could be confirmed by James with a dmesg file?)
It help me to point out 2 big diff: scsi Zalon driver and Lasi_82596 Lan nic (I removed HIL modules simply because no device 
available).

That said the system always became to hang when I start a large disk i/o with a find into a linux kernel for example and also by 
accident I also start a kernel without Lasi module (and iirc the same pb occured) but in any case I could make it leave without 
Zalon driver; or did I miss something else in my .config (so much diff between the 2 config I used).

(C110 need long hours to compile the kernel :( but that is all I have at home)

> You might need to add pdc_io_reset_devices() to ccio_ioc_init()
> since we moved that out of the common code path.

hmm I don't see such stuff in patches I grab of jejb changes?
Any way I see what you did in sba_hw_init() (I will so be able to reproduce it ;) )

> I don't see that
> in CCIO driver and it's not clear to me if HIL or LAN need it on C110.
> 
> It *might* need pdc_io_reset() call instead (or in addition)
> but I don't know.  Just another thing to be aware of.
> 
Thanks for all kind advise (it will just take me much more test and so many time before I could figure out the actual pb)

Joel

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

[Ryan Bradetich]

Hello Joel,

I finally had some time to compile a kernel and boot some systems today
so I tested the latest CVS head on my C200 and a J200 to see if I could
duplicate the problem you are seeing.

The J200 is basically a dual processor C100 so it should be very close
to the C110 (i.e. no PCI, EISA based, etc)  The device names are
different so I am not sure if it is close enough but I still think it is
a relevant data point.


Device list for the J200:

1. U2-IOA BC Runway Port at 0xfff88000 [8] { 12, 0x7, 0x580, 0x0000b }
2. SkyHawk 100/120 FW-SCSI at 0xf3f80000 [8/0] { 4, 0x0, 0x01f, 0x00089
}
3. SkyHawk 100/120 Core BA at 0xffd00000 [8/12] { 11, 0x0, 0x01f,
0x00081 },  additional addresses: 0xffd0c000 0xffc00000
4. SkyHawk 100/120 Core Centronics at 0xffd02000 [8/12/0] { 10, 0x0,
0x01f, 0x00074 },  additional addresses: 0xffd01000 0xffd03000
5. SkyHawk 100/120 Audio at 0xffd04000 [8/12/1] { 10, 0x0, 0x01f,
0x0007b }
6. SkyHawk 100/120 Core RS-232 at 0xffd05000 [8/12/4] { 10, 0x0, 0x01f,
0x0008c }
7. SkyHawk 100/120 Core SCSI at 0xffd06000 [8/12/5] { 10, 0x0, 0x01f,
0x00082 }
8. SkyHawk 100/120 Core LAN (802.3) at 0xffd07000 [8/12/6] { 10, 0x0,
0x01f, 0x0008a }
9. SkyHawk 100/120 Core PS/2 Port at 0xffd08000 [8/12/7] { 10, 0x0,
0x01f, 0x00084 }
10. SkyHawk 100/120 Core PS/2 Port at 0xffd08100 [8/12/8] { 10, 0x0,
0x01f, 0x00084 }
11. U2-IOA BC GSC+ Port at 0xf3fbf000 [8/63] { 7, 0x1, 0x501, 0x0000c }
12. U2-IOA BC Runway Port at 0xfff8a000 [10] { 12, 0x7, 0x580, 0x0000b }
13. HP HSC-PCI Cards at 0xf3fc0000 [10/0] { 4, 0x0, 0x004, 0x0009d }
14. Hyperdrive Optional Graphics at 0xf6000000 [10/16] { 10, 0x0, 0x005,
0x00077 }
15. SkyHawk Wax BA at 0xffe00000 [10/20] { 11, 0x0, 0x01f, 0x0008e }, 
additional addresses: 0xffe03000 0xffe06000
16. SkyHawk 100/120 Wax HIL at 0xffe01000 [10/20/1] { 10, 0x0, 0x01f,
0x00073 }
17. SkyHawk 100/120 Wax RS-232 at 0xffe02000 [10/20/2] { 10, 0x0, 0x004,
0x0008c }
18. SkyHawk 100/120 Wax EISA BA at 0xfc000000 [10/20/5] { 11, 0x0,
0x01f, 0x00090 },  additional addresses: 0xf0182000 0xf4000000
19. U2-IOA BC GSC+ Port at 0xf3fff000 [10/63] { 7, 0x1, 0x501, 0x0000c
},  additional addresses: 0xf3fc0000
20. SkyHawk 100 at 0xfffa0000 [32] { 0, 0x0, 0x585, 0x00004 }
21. Memory at 0xfffb1000 [49] { 1, 0x0, 0x049, 0x00009 }
CPU(s): 1 x PA7200 (PCX-T') at 100.000000 MHz


Would you be interested in trying the lifimage I complied and
successfully booted on both the J200 and the C110?  If the lifimage
boots on your system then we localize the problem down to possible tool
chain or .config problem (I used the defconfig).


Linux moby 2.6.5-pa6 #2 Tue Apr 13 12:01:32 MDT 2004 parisc GNU/Linux

cpu MHz         : 100.000000
model           : 9000/770/J200

Thoughts?

Thanks,

- Ryan

On Sat, 2004-04-10 at 15:19, Joel Soete wrote:
> Grant Grundler wrote:
> > On Sat, Apr 10, 2004 at 08:32:04AM +0000, Joel Soete wrote:
> > 
> >>I will so just reversed mentioned patches, check if it is the real
> >>cause of my pb.
> > 
> > 
> > ok
> > 
> 
> Well I reach to reverted it and the result is a booting and operational kernel.
> oops, my bad: I also reverted my config. Very stupid of my part, I just have re-do test; sorry
> 
> > 
> >>If yes (I don't see what else) re-apply patch hunk by hunk until it breaks 
> >>again?
> > 
> > 
> > That won't work with the changes to ccio driver. It's all or nothing.
> > 
> (I see, any way there was 2 steps for this patch and I don't have the opportunity to test the first step alone?)
> > 
> >>Any better idea?
> > 
> > 
> > I don't understand why C360 (James' machine) works and C110 (your machine)
> > does not.  C110 doesn't have PCI and maybe different keyboard/LAN.
> > Find out what is different between the two machines and see if ccio
> > changes broke one of the drivers for the different HW.
> > 
> C110's Devices						      |	C360's Devices
> 
> Raven 120 T' (Processor)  (PA7200 (PCX-T'))		      |	Raven W 360 (9000/780/????) (Processor)  (PA8500 (PCX-W))
> SkyHawk 100/120 (Memory)				      |	Raven W 360 Memory (Memory)
> SkyHawk 100/120 FW-SCSI (A DMA) (Zalon driver)		      |	Raven U/L2 Dino RS-232 (Foreign I/O Module) (Serial driver)
> Raven T' Core Centronics (Foreign I/O Module) (Parallel drive |	Raven+ w Core Centronics (Foreign I/O Module) (Paral
> Raven T' Audio (Foreign I/O Module) (Harmony driver)	      |	Raven+ w Core Audio (Foreign I/O Module) (Harmony d
> Raven T' Lasi Core RS-232 (Foreign I/O Module) (Serial driver |	Raven+ w Core RS-232 (Foreign I/O Module) (Serial d
> Raven T' Core SCSI (Foreign I/O Module) (NCR53c710 driver)    |	Raven+ w Core SCSI (Foreign I/O Module) (NCR53c710
> Raven T' Core LAN (802.3) (Foreign I/O Module) (Lasi_82596 dr |	Raven+ w Core PC Keyboard (Foreign I/O Module) (PS/
> Raven T' Core PC Keyboard (Foreign I/O Module) (PS/2 driver)  |	Raven+ w Core BA (Bus Adapter) (Lasi driver)
> Raven T' Core PC Floppy (Foreign I/O Module)		      <
> Raven T' Wax HIL (Foreign I/O Module) (HIL driver)	      <
> Raven T' Wax RS-232 (Foreign I/O Module) (Serial driver)      <
> Raven T' GSC Core Graphics (Foreign I/O Module)		      <
> Raven T' Core BA (Bus Adapter) (Lasi driver)		      <
> Raven T' Wax BA (Bus Adapter) (Wax driver)		      <
> Raven T' Wax EISA BA (Bus Adapter)			      <
> U2-IOA BC Runway Port (IOA) (x2)				U2-IOA BC Runway Port (IOA) (x2)
> 							      >	Dino PCI Bridge (Bus Bridge to Foreign Bus) (Dino driver)
> 							      >	Cujo PCI Bridge (Bus Bridge to Foreign Bus) (Dino driver)
> 							      >
> 							      >	53c875 (Symbios Logic Inc. (formerly NCR)) (SYM8xx driver)
> 							      >	DECchip 21142/43 (Digital Equipment Corporation) (Tulip drive
> 							      >	Visualize FX4 (Hewlett-Packard Company)
> 
> This is diff -y of devices list grab from web h/w db (may be c360 list could be confirmed by James with a dmesg file?)
> It help me to point out 2 big diff: scsi Zalon driver and Lasi_82596 Lan nic (I removed HIL modules simply because no device 
> available).
> 
> That said the system always became to hang when I start a large disk i/o with a find into a linux kernel for example and also by 
> accident I also start a kernel without Lasi module (and iirc the same pb occured) but in any case I could make it leave without 
> Zalon driver; or did I miss something else in my .config (so much diff between the 2 config I used).
> 
> (C110 need long hours to compile the kernel :( but that is all I have at home)
> 
> > You might need to add pdc_io_reset_devices() to ccio_ioc_init()
> > since we moved that out of the common code path.
> 
> hmm I don't see such stuff in patches I grab of jejb changes?
> Any way I see what you did in sba_hw_init() (I will so be able to reproduce it ;) )
> 
> > I don't see that
> > in CCIO driver and it's not clear to me if HIL or LAN need it on C110.
> > 
> > It *might* need pdc_io_reset() call instead (or in addition)
> > but I don't know.  Just another thing to be aware of.
> > 
> Thanks for all kind advise (it will just take me much more test and so many time before I could figure out the actual pb)
> 
> Joel
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>