Re: RE: CALL FOR TESTING

Re: RE: CALL FOR TESTING

[Matthew Wilcox]

On Fri, Sep 20, 2002 at 08:28:32AM -0400, Bernd Pfrommer wrote:
> kernel: 2.4.20-pre7, with patch acpi20020918, configured with ACPI
> platform: intel server SRMK2S with AMIBIOS and dual 1GHz PIII/256k 
> cache, 1GB memory, adaptec 7899 SCSI
> 
> DOES NOT BOOT

The question Andy forgot to ask is:

Does it work with ACPI enabled in the stock 2.4.20-pre7 kernel?
	[ If NO, there is no problem with including today's code.
	  Didn't work before, still doesn't work => not a regression. ]

I agree your machine should be fixed, but the real purpose of this test
is to determine whether there are any impediments to including this code
in 2.4.20.

-- 
Revolutions do not require corporate support.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: RE: CALL FOR TESTING

[Bernd Pfrommer]

[-- Attachment #1: Type: text/plain, Size: 6917 bytes --]

With the bare 2.4.20-pre7 kernel, the interrupt assignment appears to 
work, and the machine boots up without passing acpi=off. However, the 
acpi driver doesn't load (and it didn't load in 2.4.18, 2.4.19 either)

Sep 20 05:23:58 option kernel: PCI: PCI BIOS revision 2.10 entry at 
0xfda65, last bus=1
Sep 20 05:23:58 option kernel: PCI: Using configuration type 1
Sep 20 05:23:58 option kernel: PCI: Probing PCI hardware
Sep 20 05:23:58 option kernel: PCI: Discovered primary peer bus 01 [IRQ]
Sep 20 05:23:58 option kernel: PCI->APIC IRQ transform: (B0,I4,P0) -> 23
Sep 20 05:23:58 option kernel: PCI->APIC IRQ transform: (B0,I7,P0) -> 17
Sep 20 05:23:58 option kernel: PCI->APIC IRQ transform: (B0,I8,P0) -> 16
Sep 20 05:23:58 option kernel: PCI->APIC IRQ transform: (B0,I15,P0) -> 10
Sep 20 05:23:58 option kernel: PCI->APIC IRQ transform: (B1,I4,P0) -> 24
Sep 20 05:23:58 option kernel: PCI->APIC IRQ transform: (B1,I4,P1) -> 25
Sep 20 05:23:58 option kernel: Linux NET4.0 for Linux 2.4
Sep 20 05:23:58 option kernel: Based upon Swansea University Computer 
Society NET3.039
Sep 20 05:23:58 option kernel: Initializing RT netlink socket
Sep 20 05:23:58 option kernel: Starting kswapd
Sep 20 05:23:58 option kernel: allocated 32 pages and 32 bhs reserved 
for the highmem bounces
Sep 20 05:23:58 option kernel: Journalled Block Device driver loaded
Sep 20 05:23:58 option kernel: Installing knfsd (copyright (C) 1996 
okir-pn4DOG8n3UYbFoVRYvo4fw@public.gmane.org).
Sep 20 05:23:58 option netfs: Mounting other filesystems:  succeeded
Sep 20 05:23:58 option kernel:  tbxface-0099 [01] Acpi_load_tables      
: ACPI Tables successfully loaded
Sep 20 05:23:58 option kernel:  tbxface-0106: *** Error: 
Acpi_load_tables: Could not load namespace: AE_NOT_FOUND
Sep 20 05:23:58 option kernel:  tbxface-0115: *** Error: 
Acpi_load_tables: Could not load tables: AE_NOT_FOUND
Sep 20 05:23:58 option kernel: ACPI: System description table load failed
Sep 20 05:23:58 option kernel:  utalloc-0504 [03] Ut_dump_allocations   
: Outstanding allocations:
Sep 20 05:23:58 option kernel: f7e77d08 Len 0038   utalloc-150 Parse_obj 
Opcode 0010
Sep 20 05:23:58 option kernel: f7e77d88 Len 0038   utalloc-150 Parse_obj 
Opcode 5B82
Sep 20 05:23:58 option kernel: f7eaf288 Len 0038   utalloc-150 Parse_obj 
Opcode 5B82
Sep 20 05:23:58 option kernel: f7eb01e8 Len 0038   utalloc-150 Parse_obj 
Opcode 5B82
Sep 20 05:23:58 option kernel: c1c1ce48 Len 0009  tbconvrt-520
Sep 20 05:23:58 option kernel:  utalloc-0598 [03] Ut_dump_allocations   
: Total number of unfreed allocations = 5(5)

And for reference, here again the messages with 2.4.20-pre7, with the 
acpi patch:

Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 997.4513 MHz.
..... host bus clock speed is 132.9934 MHz.
cpu: 0, clocks: 1329934, slice: 443311
CPU0<T0:1329920,T1:886608,D:1,S:443311,C:1329934>
cpu: 1, clocks: 1329934, slice: 443311
CPU1<T0:1329920,T1:443296,D:2,S:443311,C:1329934>
checking TSC synchronization across CPUs: passed.
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
ACPI: Subsystem revision 20020918
PCI: PCI BIOS revision 2.10 entry at 0xfda65, last bus=1
PCI: Using configuration type 1
    ACPI-0273: *** Info: Table [DSDT] replaced by host OS
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [NRTH] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Root Bridge [PCI1] (00:00)
ACPI: PCI Interrupt Link [LN00] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN01] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN02] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN03] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN04] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN05] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN06] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN07] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN08] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN09] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN10] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN11] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN12] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN13] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN14] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN15] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNUS] (IRQs 10, disabled)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LN00] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN01] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN02] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN03] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN04] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN05] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN06] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN07] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN08] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN09] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN10] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN11] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN12] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN13] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN14] enabled at IRQ 0
ACPI: PCI Interrupt Link [LN15] enabled at IRQ 0
ACPI: PCI Interrupt Link [LNUS] enabled at IRQ 0
PCI: No IRQ known for interrupt pin A of device 00:0f.2 - using IRQ 10
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 
'acpi=off'

With the acpi patch it is really hard to figure out what's breaking the 
boot, because once there is a kernel panic, it is impossible to scroll 
back to the messages that indicate an ACPI problem. I had to configure 
the serial port, buy a null modem cable etc just to get to the messages 
printed here. A lot of users may not know about this trick, or may not 
want to go through the trouble of configuring serial console access.

Please let me know if I can be of any help.

Thanks,

Bernd


Matthew Wilcox wrote:

>On Fri, Sep 20, 2002 at 08:28:32AM -0400, Bernd Pfrommer wrote:
>
>>kernel: 2.4.20-pre7, with patch acpi20020918, configured with ACPI
>>platform: intel server SRMK2S with AMIBIOS and dual 1GHz PIII/256k 
>>cache, 1GB memory, adaptec 7899 SCSI
>>
>>DOES NOT BOOT
>>
>
>The question Andy forgot to ask is:
>
>Does it work with ACPI enabled in the stock 2.4.20-pre7 kernel?
>	[ If NO, there is no problem with including today's code.
>	  Didn't work before, still doesn't work => not a regression. ]
>
>I agree your machine should be fixed, but the real purpose of this test
>is to determine whether there are any impediments to including this code
>in 2.4.20.
>


[-- Attachment #2: Type: text/html, Size: 8031 bytes --]

RE: RE: CALL FOR TESTING

[Grover, Andrew]

> From: Bernd Pfrommer [mailto:berndp-p32f3XyCuykqcZcGjlUOXw@public.gmane.org] 
> kernel: 2.4.20-pre7, with patch acpi20020918, configured with ACPI
> platform: intel server SRMK2S with AMIBIOS and dual 1GHz PIII/256k 
> cache, 1GB memory, adaptec 7899 SCSI
> 
> DOES NOT BOOT

> I have attached the unpatched dsdt. To get rid of acpi error 
> messages, I 
> removed offending "Name()" lines. Please let me know if this is the 
> appropriate fix. As I said, it doesn't boot with the original 
> dsdt either.

I have an SCB2 system, whose ASL looks pretty similar to yours -- even some
of the same ASL problems. It boots for me with an SMP but not UP kernel.

Which are you trying?

If UP, can you please try this ASL change?

Search for this:

    Method(GETI, 1) {
        If(And(Arg0, 0xf, )) {
            Return(Zero)
        }
        Else {
            Return(\MLIB.CNV2(And(Arg0, 0xf, )))
        }
    }

And swap the contents of the if/else.

The Name() lines emit a warning but are harmless.

If you're having troubles in SMP mode, then I guess that is not shared
between our two platforms...

Thanks -- Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: RE: CALL FOR TESTING

[Grover, Andrew]

> From: Matthew Wilcox [mailto:willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org] 
> On Fri, Sep 20, 2002 at 08:28:32AM -0400, Bernd Pfrommer wrote:
> > kernel: 2.4.20-pre7, with patch acpi20020918, configured with ACPI
> > platform: intel server SRMK2S with AMIBIOS and dual 1GHz PIII/256k 
> > cache, 1GB memory, adaptec 7899 SCSI
> > 
> > DOES NOT BOOT
> 
> The question Andy forgot to ask is:
> 
> Does it work with ACPI enabled in the stock 2.4.20-pre7 kernel?
> 	[ If NO, there is no problem with including today's code.
> 	  Didn't work before, still doesn't work => not a regression. ]

Oh yeah, good point...

> I agree your machine should be fixed, but the real purpose of 
> this test
> is to determine whether there are any impediments to 
> including this code
> in 2.4.20.

I've gotten mostly positive input on the patch, so I'm going to post a wider
call for testing to linux-kernel this afternoon.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: RE: CALL FOR TESTING

[Bernd Pfrommer]

[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]

Thanks for the prompt reply!

Grover, Andrew wrote:

>>From: Bernd Pfrommer [mailto:berndp-p32f3XyCuykqcZcGjlUOXw@public.gmane.org] 
>>kernel: 2.4.20-pre7, with patch acpi20020918, configured with ACPI
>>platform: intel server SRMK2S with AMIBIOS and dual 1GHz PIII/256k 
>>cache, 1GB memory, adaptec 7899 SCSI
>>
>>DOES NOT BOOT
>>
>
>>I have attached the unpatched dsdt. To get rid of acpi error 
>>messages, I 
>>removed offending "Name()" lines. Please let me know if this is the 
>>appropriate fix. As I said, it doesn't boot with the original 
>>dsdt either.
>>
>
>I have an SCB2 system, whose ASL looks pretty similar to yours -- even some
>of the same ASL problems. It boots for me with an SMP but not UP kernel.
>
>Which are you trying?
>
Since the machine has 2 CPUs, the kernel is configured for SMP.

>
>
>If UP, can you please try this ASL change?
>
>Search for this:
>
>    Method(GETI, 1) {
>        If(And(Arg0, 0xf, )) {
>            Return(Zero)
>        }
>        Else {
>            Return(\MLIB.CNV2(And(Arg0, 0xf, )))
>        }
>    }
>
>And swap the contents of the if/else.
>
>The Name() lines emit a warning but are harmless.
>
>If you're having troubles in SMP mode, then I guess that is not shared
>between our two platforms...
>
>Thanks -- Regards -- Andy
>
With regards to Matthew Wilcox's comments: I have tried with 2.4.20-pre7 
without the acpi patch, and the machine boots there, and interrupts are 
assigned correctly (having ACPI config switched on for the kernel). 
However, the ACPI driver load fails as I posted in an earlier message.

Although I'm not running in uniprocessor mode, I still tried your ASL 
fix above, and the IRQ assignment has changed (see below), although the 
system still wouldn't boot (neither does it when I use pci=noacpi).

Does the interrupt assignment look reasonable to you? Do you have any 
more ASL fixes to suggest?

Thanks,
Bernd


//
// ----------------------------- THIS IS THE INTERRUPT DISTRIBUTION WHEN 
BOOTING WITH ACPI=OFF ----------------------
// (system boots successfully)

ACPI: Subsystem revision 20020918
ACPI: Disabled via command line (acpi=off)
PCI: PCI BIOS revision 2.10 entry at 0xfda65, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ACPI tables contain no PCI IRQ routing entries
PCI: Probing PCI hardware (bus 00)
PCI: Discovered primary peer bus 01 [IRQ]
PCI->APIC IRQ transform: (B0,I4,P0) -> 23
PCI->APIC IRQ transform: (B0,I7,P0) -> 17
PCI->APIC IRQ transform: (B0,I8,P0) -> 16
PCI->APIC IRQ transform: (B0,I15,P0) -> 10
PCI->APIC IRQ transform: (B1,I4,P0) -> 24
PCI->APIC IRQ transform: (B1,I4,P1) -> 25

//
// ---------------------------- THIS IS WITH 2.4.20-pre7 + acpi patch + 
above DSDT fix 
-----------------------------------------------------------------
//(kernel panic)


Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
ACPI: Subsystem revision 20020918
PCI: PCI BIOS revision 2.10 entry at 0xfda65, last bus=1
PCI: Using configuration type 1
    ACPI-0273: *** Info: Table [DSDT] replaced by host OS
    ACPI-0217: *** Warning: Invalid type (Integer) for target of Scope 
operator
[DEB_], changing type to ANY
..
.. (LOTS OF THESE WARNINGS....)
..  
[BIOS], changing type to ANY
    ACPI-0490: *** Warning: Invalid type (Integer) for target of Scope 
operator
[CMOS], changing type to ANY
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [NRTH] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Root Bridge [PCI1] (00:00)
ACPI: PCI Interrupt Link [LN00] (IRQs 3 4 *5 7 9 11 12 14 15)
ACPI: PCI Interrupt Link [LN01] (IRQs 3 4 5 7 9 11 12 14 15, enabled at 
IRQ 10)
ACPI: PCI Interrupt Link [LN02] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN03] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN04] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN05] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN06] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN07] (IRQs 3 4 5 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [LN08] (IRQs *3 4 5 7 9 11 12 14 15)
ACPI: PCI Interrupt Link [LN09] (IRQs 3 4 5 7 *9 11 12 14 15)
ACPI: PCI Interrupt Link [LN10] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN11] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN12] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN13] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN14] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LN15] (IRQs 3 4 5 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNUS] (IRQs *10)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LN02] enabled at IRQ 11
ACPI: PCI Interrupt Link [LN03] enabled at IRQ 9
ACPI: PCI Interrupt Link [LN04] enabled at IRQ 5
ACPI: PCI Interrupt Link [LN05] enabled at IRQ 11
ACPI: PCI Interrupt Link [LN06] enabled at IRQ 9
ACPI: PCI Interrupt Link [LN10] enabled at IRQ 5
ACPI: PCI Interrupt Link [LN11] enabled at IRQ 11
ACPI: PCI Interrupt Link [LN12] enabled at IRQ 9
ACPI: PCI Interrupt Link [LN13] enabled at IRQ 5
ACPI: PCI Interrupt Link [LN14] enabled at IRQ 11
ACPI: PCI Interrupt Link [LN15] enabled at IRQ 9
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 
'acpi=off


Eventually kernel panic because SCSI disk driver load fails due to irq 
mismatch



[-- Attachment #2: Type: text/html, Size: 6792 bytes --]

Re: Re: CALL FOR TESTING

[joerg.beyer-htSm2yLGOjU]

kneumann-4bfl1RV3iZDOEhgYWvzSCYQuADTiUCJX@public.gmane.org schrieb am 26.09.02 00:13:55:
> Sorry for beeing a bit late,  I was out of town for a few days. I will try
> that tomorrow morning. Actually before I left I did what Andrew suggested
> and compiled acpi as modules. Machine boots fine then, but when modprobing
> the thermal module oopses. IIRC temperature was around 60 degrees
> celsius...that does not seem too hot for an athlon, does it?
> 
I see this temerature also from time to time for a Athlon mobile 1200. I dont know if that
is too hot.

    Joerg





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf