* [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
@ 2004-03-21 13:17 Joel Soete
2004-03-21 19:57 ` Grant Grundler
0 siblings, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-03-21 13:17 UTC (permalink / raw)
To: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-03-21 13:17 [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( Joel Soete
@ 2004-03-21 19:57 ` Grant Grundler
2004-03-22 7:07 ` Joel Soete
2004-03-23 4:51 ` Grant Grundler
0 siblings, 2 replies; 24+ messages in thread
From: Grant Grundler @ 2004-03-21 19:57 UTC (permalink / raw)
To: Joel Soete; +Cc: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-03-21 19:57 ` Grant Grundler
@ 2004-03-22 7:07 ` Joel Soete
2004-03-23 4:51 ` Grant Grundler
1 sibling, 0 replies; 24+ messages in thread
From: Joel Soete @ 2004-03-22 7:07 UTC (permalink / raw)
To: Grant Grundler; +Cc: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-03-21 19:57 ` Grant Grundler
2004-03-22 7:07 ` Joel Soete
@ 2004-03-23 4:51 ` Grant Grundler
2004-03-27 22:43 ` Joel Soete
2004-04-09 20:47 ` Joel Soete
1 sibling, 2 replies; 24+ messages in thread
From: Grant Grundler @ 2004-03-23 4:51 UTC (permalink / raw)
To: Grant Grundler; +Cc: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-03-23 4:51 ` Grant Grundler
@ 2004-03-27 22:43 ` Joel Soete
2004-04-09 20:47 ` Joel Soete
1 sibling, 0 replies; 24+ messages in thread
From: Joel Soete @ 2004-03-27 22:43 UTC (permalink / raw)
To: Grant Grundler; +Cc: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-03-23 4:51 ` Grant Grundler
2004-03-27 22:43 ` Joel Soete
@ 2004-04-09 20:47 ` Joel Soete
2004-04-09 21:15 ` Grant Grundler
1 sibling, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-04-09 20:47 UTC (permalink / raw)
To: James Bottomley; +Cc: Grant Grundler, PA-RISC Linux Port
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-09 20:47 ` Joel Soete
@ 2004-04-09 21:15 ` Grant Grundler
2004-04-10 8:32 ` Joel Soete
0 siblings, 1 reply; 24+ messages in thread
From: Grant Grundler @ 2004-04-09 21:15 UTC (permalink / raw)
To: Joel Soete; +Cc: James Bottomley, PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-09 21:15 ` Grant Grundler
@ 2004-04-10 8:32 ` Joel Soete
2004-04-10 18:14 ` Grant Grundler
0 siblings, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-04-10 8:32 UTC (permalink / raw)
To: Grant Grundler; +Cc: James Bottomley, PA-RISC Linux Port
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-10 8:32 ` Joel Soete
@ 2004-04-10 18:14 ` Grant Grundler
2004-04-10 21:19 ` Joel Soete
0 siblings, 1 reply; 24+ messages in thread
From: Grant Grundler @ 2004-04-10 18:14 UTC (permalink / raw)
To: Joel Soete; +Cc: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-10 18:14 ` Grant Grundler
@ 2004-04-10 21:19 ` Joel Soete
2004-04-14 0:22 ` Ryan Bradetich
0 siblings, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-04-10 21:19 UTC (permalink / raw)
To: Grant Grundler; +Cc: PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-10 21:19 ` Joel Soete
@ 2004-04-14 0:22 ` Ryan Bradetich
0 siblings, 0 replies; 24+ messages in thread
From: Ryan Bradetich @ 2004-04-14 0:22 UTC (permalink / raw)
To: Joel Soete; +Cc: Grant Grundler, PA-RISC Linux Port
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
@ 2004-04-14 6:45 Joel Soete
2004-04-14 12:01 ` Joel Soete
2004-04-14 14:36 ` Ryan Bradetich
0 siblings, 2 replies; 24+ messages in thread
From: Joel Soete @ 2004-04-14 6:45 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: Grant Grundler, PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 6:45 Joel Soete
@ 2004-04-14 12:01 ` Joel Soete
2004-04-14 14:36 ` Ryan Bradetich
1 sibling, 0 replies; 24+ messages in thread
From: Joel Soete @ 2004-04-14 12:01 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: Grant Grundler, PA-RISC Linux Port
>> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 6:45 Joel Soete
2004-04-14 12:01 ` Joel Soete
@ 2004-04-14 14:36 ` Ryan Bradetich
2004-04-14 14:49 ` James Bottomley
2004-04-14 16:08 ` Joel Soete
1 sibling, 2 replies; 24+ messages in thread
From: Ryan Bradetich @ 2004-04-14 14:36 UTC (permalink / raw)
To: Joel Soete; +Cc: Grant Grundler, PA-RISC Linux Port
> >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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 14:36 ` Ryan Bradetich
@ 2004-04-14 14:49 ` James Bottomley
2004-04-14 16:26 ` Joel Soete
2004-04-14 16:08 ` Joel Soete
1 sibling, 1 reply; 24+ messages in thread
From: James Bottomley @ 2004-04-14 14:49 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: Joel Soete, PA-RISC Linux Port, Grant Grundler
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 14:49 ` James Bottomley
@ 2004-04-14 16:26 ` Joel Soete
0 siblings, 0 replies; 24+ messages in thread
From: Joel Soete @ 2004-04-14 16:26 UTC (permalink / raw)
To: James Bottomley, Ryan Bradetich; +Cc: Grant Grundler, PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 14:36 ` Ryan Bradetich
2004-04-14 14:49 ` James Bottomley
@ 2004-04-14 16:08 ` Joel Soete
1 sibling, 0 replies; 24+ messages in thread
From: Joel Soete @ 2004-04-14 16:08 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: Grant Grundler, PA-RISC Linux Port
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
@ 2004-04-14 19:32 Andy Walker
2004-04-14 20:52 ` Joel Soete
0 siblings, 1 reply; 24+ messages in thread
From: Andy Walker @ 2004-04-14 19:32 UTC (permalink / raw)
To: parisc-linux
Joel Soete wrote:
> That said, I am not able to link jejb with what I observe but here is
> the story.
> The system boot but hang very quickly as soon as io rate increase as per
> a find of a file name :( (reproducible on request)
> I then get mesg
>
> arq->state 2
> Badness in as_requeue_request at drivers/block/as-iosched.c:1479
> Kernel addresses on the stack:
> [snip]
> [<10124528>] printk+0x144/0x1c0
> [<101036bc>] dump_stack+0x18/0x24
> [<102276a0>] as_requeue_request+0x5c/0x17c
> [<1021e630>] elv_requeue_request+0x30/0x3c
> [<1023baf4>] scsi_request_fn+0x220/0x2bc
> [<1021e630>] elv_requeue_request+0x30/0x3c
> [<102212b8>] blk_insert_request+0xd8/0xf0
> [<1023a978>] scsi_queue_insert+0x6c/0xa0
> [<1023b7bc>] scsi_prep_fn+0xc4/0x1dc
> [<102368f8>] scsi_dispatch_cmd+0x118/0x22c
> [<1021e820>] elv_remove_request+0x34/0x44
> [<1023ba80>] scsi_request_fn+0x1ac/0x2bc
> [<102273f0>] as_next_request+0x44/0x54
> [<10228218>] as_work_handler+0x44/0x48
> [<101344e4>] worker_thread+0x1e4/0x280
> [<101200cc>] schedule+0x3f8/0x718
> [<101385f4>] kthread+0xdc/0xe4
> [<10108c5c>] ret_from_kernel_thread+0x1c/0x24
>
> [snip]
>
> it seems to be infinite loop :(
>
> Any idea?
>
> Thanks in advance,
> Joel
I'm experiencing a very similar problem with 2.6.5-pa7 on a C180. I'm in
unfortunate position that my ext3 root filesystem needs INFO recovery,
but as soon as the recovery kicks in I get:
arq->state 2
Badness in as_requeue_request at drivers/block/as-iosched.c:1479
Kernel addresses on the stack:
[snip]
[<10125d0c>] printk+0x188/0x1c8
[<10105638>] dump_stack+0x18/0x24
[<101fb740>] as_requeue_request+0x64/0x10c
[<101f24b0>] elv_requeue_request+0x2c/0x38
[<101f51b4>] blk_insert_request+0xf4/0xfc
[<10211c2c>] scsi_queue_insert+0x68/0x9c
[<102376f4>] hp_sdc_tasklet+0x80/0x160
[<1020dd2c>] scsi_softirq+0xfc/0x11c
[<10129990>] do_softirq+0xf4/0xf8
[<10129e68>] ksoftirqd+0x84/0xf0
[<101398a0>] kthread+0xe8/0xf0
[<1010ac5c>] ret_from_kernel_thread+0x1c/0x24
Can't point to the last kernel version that worked, because this is
actually the first kernel I've built for the C180, having just
finished bootstrapping Gentoo. But I'll be happy to provide what
info I can - seems this problem is real if both a C110 and a C180
are suffering from it, and they're very similar pieces of hardware.
cheers
-Andy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 19:32 Andy Walker
@ 2004-04-14 20:52 ` Joel Soete
2004-04-15 7:05 ` Joel Soete
0 siblings, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-04-14 20:52 UTC (permalink / raw)
To: Andy Walker; +Cc: parisc-linux
Andy,
Many Thanks you save my mind: I was becoming crazy ;)
That said, thanks to viewcvs, cvs and some tbz I recover from my systems, I reach to rebuild on my b2k at the office:
2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a tar of one of those tree) survive :)
2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :)
but 2.6.4-rc4-pa6 died with same messages.
and too bad after such crash not more possible to reboot even with 2.6.4-rc1-pa3 which panic:
[snip]
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 520k freed
Stack Dump:
10380418: 10380418 00048308 00000040 ffe01800
10380408: ffe01801 1046f010 10380080 003803b8
[snip]
10380038: 00000000 00000000 00000000 00000000
10380028: 00000000 00000000 00000000 00000000
Kernel addresses on the stack:
[<10125aec>] call_console_drivers+0xd0/0x17c
[<10106020>] parisc_terminate+0x60/0xb8
[<10111cd0>] pdc_console_restart+0x4c/0x68
[<101061bc>] handle_interruption+0x144/0x5b0
[<1010b088>] intr_check_sig+0x0/0xc
[<1025e5bc>] ncr_reset_scsi_bus+0x158/0x2b8
High Priority Machine Check (HPMC): Code=1 regs=10380080 (Addr=00000000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001110 Not tainted
r00-03 00000000 103a5010 1025e4b8 0000000f
r04-07 17edeba0 17ec0000 00000002 103a5010
r08-11 00000000 17ec4110 b6da8c80 1046e060
r12-15 100fe244 00000000 10394010 1046e010
r16-19 f00010f4 f00000ac f00000a4 f3f8c80e
r20-23 00000001 0000000f 0000000e 1046d010
r24-27 17ec0000 00000000 0000c800 1037d010
r28-31 f3f8c800 00005dc0 17ec4380 1025e57c
sr0-3 00000000 00000003 00000000 00000003
sr4-7 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 1025e5b8 1025e5bc
IIR: d6c30a3f ISR: 00000000 IOR: f3f8c80c
CPU: 0 CR30: 17ec4000 CR31: 103dc000
ORIG_R28: 00000000
IAOQ[0]: ncr_reset_scsi_bus+0x154/0x2b8
IAOQ[1]: ncr_reset_scsi_bus+0x158/0x2b8
RP(r2): ncr_reset_scsi_bus+0x54/0x2b8
(already retry 2 time even after a cycle power off/on?
and now with 2.6.3-pa2 up again pfff)
I can still restric research between 2.6.4-rc3-pa3 (which I missed in my investigation?) and 2.6.4-rc4-pa6?
hth,
Joel
Andy Walker wrote:
> Joel Soete wrote:
>
>
>>That said, I am not able to link jejb with what I observe but here is
>>the story.
>>The system boot but hang very quickly as soon as io rate increase as per
>>a find of a file name :( (reproducible on request)
>>I then get mesg
>>
>>arq->state 2
>>Badness in as_requeue_request at drivers/block/as-iosched.c:1479
>>Kernel addresses on the stack:
>>[snip]
>> [<10124528>] printk+0x144/0x1c0
>> [<101036bc>] dump_stack+0x18/0x24
>> [<102276a0>] as_requeue_request+0x5c/0x17c
>> [<1021e630>] elv_requeue_request+0x30/0x3c
>> [<1023baf4>] scsi_request_fn+0x220/0x2bc
>> [<1021e630>] elv_requeue_request+0x30/0x3c
>> [<102212b8>] blk_insert_request+0xd8/0xf0
>> [<1023a978>] scsi_queue_insert+0x6c/0xa0
>> [<1023b7bc>] scsi_prep_fn+0xc4/0x1dc
>> [<102368f8>] scsi_dispatch_cmd+0x118/0x22c
>> [<1021e820>] elv_remove_request+0x34/0x44
>> [<1023ba80>] scsi_request_fn+0x1ac/0x2bc
>> [<102273f0>] as_next_request+0x44/0x54
>> [<10228218>] as_work_handler+0x44/0x48
>> [<101344e4>] worker_thread+0x1e4/0x280
>> [<101200cc>] schedule+0x3f8/0x718
>> [<101385f4>] kthread+0xdc/0xe4
>> [<10108c5c>] ret_from_kernel_thread+0x1c/0x24
>>
>>[snip]
>>
>>it seems to be infinite loop :(
>>
>>Any idea?
>>
>>Thanks in advance,
>> Joel
>
>
> I'm experiencing a very similar problem with 2.6.5-pa7 on a C180. I'm in
> unfortunate position that my ext3 root filesystem needs INFO recovery,
> but as soon as the recovery kicks in I get:
>
> arq->state 2
> Badness in as_requeue_request at drivers/block/as-iosched.c:1479
> Kernel addresses on the stack:
> [snip]
> [<10125d0c>] printk+0x188/0x1c8
> [<10105638>] dump_stack+0x18/0x24
> [<101fb740>] as_requeue_request+0x64/0x10c
> [<101f24b0>] elv_requeue_request+0x2c/0x38
> [<101f51b4>] blk_insert_request+0xf4/0xfc
> [<10211c2c>] scsi_queue_insert+0x68/0x9c
> [<102376f4>] hp_sdc_tasklet+0x80/0x160
> [<1020dd2c>] scsi_softirq+0xfc/0x11c
> [<10129990>] do_softirq+0xf4/0xf8
> [<10129e68>] ksoftirqd+0x84/0xf0
> [<101398a0>] kthread+0xe8/0xf0
> [<1010ac5c>] ret_from_kernel_thread+0x1c/0x24
>
> Can't point to the last kernel version that worked, because this is
> actually the first kernel I've built for the C180, having just
> finished bootstrapping Gentoo. But I'll be happy to provide what
> info I can - seems this problem is real if both a C110 and a C180
> are suffering from it, and they're very similar pieces of hardware.
>
> cheers
> -Andy
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-14 20:52 ` Joel Soete
@ 2004-04-15 7:05 ` Joel Soete
2004-04-16 11:19 ` Andy Walker
0 siblings, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-04-15 7:05 UTC (permalink / raw)
To: Andy Walker; +Cc: parisc-linux
>That said, thanks to viewcvs, cvs and some tbz I recover from my systems,
I >reach to rebuild on my b2k at the office:
>2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a
> tar of one of those tree) survive :)
>2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :)
>but 2.6.4-rc4-pa6 died with same messages.
Sorry a typo: read 2.6.4-rc3-pa6 in place of rc4 :(
Joel
----------------------------------------------------------------------------------------
Tiscali ADSL: 35 €/mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-15 7:05 ` Joel Soete
@ 2004-04-16 11:19 ` Andy Walker
2004-04-17 18:10 ` Joel Soete
0 siblings, 1 reply; 24+ messages in thread
From: Andy Walker @ 2004-04-16 11:19 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
>>That said, thanks to viewcvs, cvs and some tbz I recover from my systems,
> I >reach to rebuild on my b2k at the office:
>>2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a
>> tar of one of those tree) survive :)
>>2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :)
>>but 2.6.4-rc4-pa6 died with same messages.
>
> Sorry a typo: read 2.6.4-rc3-pa6 in place of rc4 :(
>
> Joel
>
>
Joel,
2.6.6-rc1-pa0 shows the same behaviour, although it does seem to make it
through the Gentoo boot process most times. Typically, 'ls <TAB><TAB>' in
bash in a largeish directory will do the trick. The bash process ends up
in disk-wait, the WARN_ON gets logged. I can switch consoles and log in
but just about anything that goes to disk ends up in disk-wait too.
I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable.
Can't boot it until this evening because the machine's at home and
AUTOBOOT is OFF.
-Andy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-16 11:19 ` Andy Walker
@ 2004-04-17 18:10 ` Joel Soete
2004-04-17 20:49 ` Andy Walker
0 siblings, 1 reply; 24+ messages in thread
From: Joel Soete @ 2004-04-17 18:10 UTC (permalink / raw)
To: Andy Walker; +Cc: parisc-linux
Hello Andy,
Sorry for delay but I was a bit busy by a production server.
Andy Walker wrote:
>>>That said, thanks to viewcvs, cvs and some tbz I recover from my systems,
>>
>>I >reach to rebuild on my b2k at the office:
>>
>>>2.6.3-pa2 (runing simultaneoulsy 2 find on different linux tree, a
>>>tar of one of those tree) survive :)
>>>2.6.4-rc1-pa3 same test: survive (so no pb with ccio-dma changes) :)
>>>but 2.6.4-rc4-pa6 died with same messages.
>>
>>Sorry a typo: read 2.6.4-rc3-pa6 in place of rc4 :(
>>
>>Joel
>>
>>
>
>
> Joel,
>
> 2.6.6-rc1-pa0 shows the same behaviour,
Thanks.
but not a surprise regarding previous test.
> although it does seem to make it
> through the Gentoo boot process most times.
I would not be surprise if it occures during some fsck. Do you also use ext3 on your Gentoo?
btw Gentoo always install pkg by a local rebuild from src (that's a long time that I visit the site)?
> Typically, 'ls <TAB><TAB>' in
> bash in a largeish directory will do the trick. The bash process ends up
> in disk-wait, the WARN_ON gets logged. I can switch consoles and log in
> but just about anything that goes to disk ends up in disk-wait too.
>
I will try this also.
> I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable.
This seems to be the last one enough stable for me and my c110: I just updated my distro (that used a lot tar iirc) and all works
fine with this kernel.
> Can't boot it until this evening because the machine's at home and
> AUTOBOOT is OFF.
>
No pb.
Thanks for your feedback ;)
Joel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-17 18:10 ` Joel Soete
@ 2004-04-17 20:49 ` Andy Walker
2004-04-17 21:32 ` Joel Soete
0 siblings, 1 reply; 24+ messages in thread
From: Andy Walker @ 2004-04-17 20:49 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
> Hello Andy,
>
> Sorry for delay but I was a bit busy by a production server.
No problem.
>> 2.6.6-rc1-pa0 shows the same behaviour,
>
> Thanks.
> but not a surprise regarding previous test.
>
>> although it does seem to make it
>> through the Gentoo boot process most times.
>
> I would not be surprise if it occures during some fsck. Do you also use
> ext3 on your Gentoo?
> btw Gentoo always install pkg by a local rebuild from src (that's a long
> time that I visit the site)?
That's the Gentoo way - so every package on my system is compiled
-march=2.0 -mschedule=8000. The downside is that install and upgrade
takes a long time on slow machines. The upside is that you get total
control over package selection and compilation options. I've played
with Debian before but I find apt a pain compared to Gentoo's portage.
Also all this sid/woody/stable/unstable etc.... stuff confuses me.
>> I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable.
>
> This seems to be the last one enough stable for me and my c110: I just
> updated my distro (that used a lot tar iirc) and all works
> fine with this kernel.
2.6.3-pa2 is rock solid. I've been running updates, kernel compilation -
pretty heavy stuff, and no problems.
I'm just about to 'emerge' X11 - that should keep it downloading,
untarring and compiling for 24 hours.
Any suggestions for things I might test to narrow our problem down.
cheers,
-Andy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :(
2004-04-17 20:49 ` Andy Walker
@ 2004-04-17 21:32 ` Joel Soete
0 siblings, 0 replies; 24+ messages in thread
From: Joel Soete @ 2004-04-17 21:32 UTC (permalink / raw)
To: Andy Walker; +Cc: parisc-linux
Andy Walker wrote:
>>Hello Andy,
>>
>>Sorry for delay but I was a bit busy by a production server.
>
>
> No problem.
>
>
>>>2.6.6-rc1-pa0 shows the same behaviour,
>>
>>Thanks.
>>but not a surprise regarding previous test.
>>
>>
>>>although it does seem to make it
>>>through the Gentoo boot process most times.
>>
>>I would not be surprise if it occures during some fsck. Do you also use
>>ext3 on your Gentoo?
>>btw Gentoo always install pkg by a local rebuild from src (that's a long
>>time that I visit the site)?
>
>
> That's the Gentoo way - so every package on my system is compiled
> -march=2.0 -mschedule=8000. The downside is that install and upgrade
> takes a long time on slow machines.
Yes that why I do not investegate more: I don't have a lot of budget for my system which are generaly systems a bit outdated
machine recover from trash still just enough for my investigation but a bit too slow to build all the tools I would like to
maintained uptodate frequently. The very great stuff would have to have the choice: update from pre-compiled binaries or a local
compile. The debian packaging system is very robust (some month ago, on a i386, I do an update from a old woody (r0 iirc) directly
to unstable aka sid without any pb) but I do not yet find a clear doc explaining me how to personalize pkg from dpkg src (I would
like for instance change the prefix in general /usr into /opt/app/app_rev a la hp)?
> The upside is that you get total
> control over package selection and compilation options. I've played
> with Debian before but I find apt a pain compared to Gentoo's portage.
> Also all this sid/woody/stable/unstable etc.... stuff confuses me.
>
That is the simple aspect: in short
the current stable release was named (the 2.x was potato, the current one woody)
the very last packages otc are put in unstable (aka sid) for large testing and debuging
when pkg become enough stable it is pushed in testing the futur debian release (recently named sarge)
there are also security update for stable release only because there are in general in unstable and testing before!
For my part I only have ineterest in very last available packages (so sid or unstable) to test new features but some times (rarely
in fact) the system is a bit 'unstable' :) (that's my choice).
>
>>>I've compiled 2.6.3-pa2 in the hope of getting the C180 up and stable.
>>
>>This seems to be the last one enough stable for me and my c110: I just
>>updated my distro (that used a lot tar iirc) and all works
>>fine with this kernel.
>
>
> 2.6.3-pa2 is rock solid. I've been running updates, kernel compilation -
> pretty heavy stuff, and no problems.
> I'm just about to 'emerge' X11 - that should keep it downloading,
> untarring and compiling for 24 hours.
>
Ok
> Any suggestions for things I might test to narrow our problem down.
>
Not realy for the moment, as explain previously, the problem seems to apear between 2.6.4-rc1-pa3 and 2.6.4-rc3-pa6.
I will try to figure out now if it comes from upstream or from or tree: I am on going to rebuild 2.6.4-rc3-pa1 and see how will it
behave.
Thanks a lot,
Joel
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2004-04-17 21:32 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-21 13:17 [parisc-linux] 2.6.5-rc2-pa2 boot panic on c110 :( Joel Soete
2004-03-21 19:57 ` Grant Grundler
2004-03-22 7:07 ` Joel Soete
2004-03-23 4:51 ` Grant Grundler
2004-03-27 22:43 ` Joel Soete
2004-04-09 20:47 ` Joel Soete
2004-04-09 21:15 ` Grant Grundler
2004-04-10 8:32 ` Joel Soete
2004-04-10 18:14 ` Grant Grundler
2004-04-10 21:19 ` Joel Soete
2004-04-14 0:22 ` Ryan Bradetich
-- strict thread matches above, loose matches on Subject: below --
2004-04-14 6:45 Joel Soete
2004-04-14 12:01 ` Joel Soete
2004-04-14 14:36 ` Ryan Bradetich
2004-04-14 14:49 ` James Bottomley
2004-04-14 16:26 ` Joel Soete
2004-04-14 16:08 ` Joel Soete
2004-04-14 19:32 Andy Walker
2004-04-14 20:52 ` Joel Soete
2004-04-15 7:05 ` Joel Soete
2004-04-16 11:19 ` Andy Walker
2004-04-17 18:10 ` Joel Soete
2004-04-17 20:49 ` Andy Walker
2004-04-17 21:32 ` Joel Soete
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.