CALL FOR TESTING

CALL FOR TESTING

[Grover, Andrew]

I wanted to make a special request for testing of the 2.4 patch (or should I
say, MEGA-patch).

Marcelo has asked for widespread testing of it, in anticipation of likely
2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
soon, but am posting this here first to hopefully weed out any really bad
bugs that may have crept in.

The main issues of importance are:

- DOES IT BOOT?
- DOES IT ASSIGN INTERRUPTS PROPERLY?

Failure to do so either indicates a bug that we need to fix (fast) or a
system that should go on the blacklist. dmesg now includes the DSDT
signature to aid blacklisting.

Issues like whether the battery reports stats properly are of secondary
importance.

Thanks in advance.

Regards -- Andy

-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org



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

Re: CALL FOR TESTING

[ahaning-mn4gwa5WIIQysxA8WJXlww]

My system is as follows:

ASUS CUBX-E (440BX) on 300W ATX PSU
Intel Celeron 600E running at ~600MHz
320MB of PC100 memory running at 66MHz (due to bus speed of CPU)
Creative SBLive! 5.1 using digital out
Hauppauge WinTV (bt878)
ATI Radeon VE using the VGA out
Kingston KNE111TX NIC
generic PS/2 keyboard and MS IntelliMouse USB
13GB 7200RPM ATA66 WDC on Promise ATA100 port

> - DOES IT BOOT?
Yup...

ahaning@desktop:~$ uname -a
Linux desktop 2.4.20-pre7 #1 SMP Sat Sep 21 12:15:41 /etc/localtime 2002 
i686 unknown

No, it's not an SMP board, I just forgot to deselect that when preparing 
the kernel config.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Sound, X, TV, usb mouse, DRI, etc all seem to work fine, so I'll assume 
that the IRQs are okay. How can I tell if they are not? Maybe by 
comparing against a stable kernel?

I've also tried putting the machine into some of the ACPI sleep modes 
with less-than-impressive results (though, I guess, nothing that I 
shouldn't expect):

Sleep Mode.....Result
----------.....------
0..............Nothing. Machine continued to work at full power.
1..............Machine seemed "locked" at full power until power was
                depressed momentarily. The machine then continued to
                work.
2..............Nothing. Machine continued to work at full power. This is
                not listed as a supported mode, though.
3..............Nothing. Machine continued to work at full power.
4..............Nothing. Machine continued to work at full power.
5..............Machine shut off abruptly and fsck ran at next boot.

To do these tests, I did:

echo "#" > /proc/acpi/sleep

where # is 0-5. Perhaps this was wrong. I've had little luck finding 
tools to control ACPI on linux whereas I've found several (pmutils and 
apm) for APM.

I should mention that Windows2000 is able to suspend this machine (the 
only difference being the hard drive.. other than that, all cards and 
cords are in the same place) very well. HDD turns off, video goes to 
"off", optical USB mouse goes off, and all fans (CPU, case, PSU) turn 
off. I can wake it up by pressing the power button momentarily. It can 
also do "hibernation" quite well. I've had limited luck with the swsusp 
option. I cannot do a "swsusp" from X, as X comes back garbled, so it's 
usefulness is limited. So, I'm sure that this should work on linux, and 
that there are no strange hardware issues.

Thanks

ahaning-mn4gwa5WIIQysxA8WJXlww@public.gmane.org



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

Re: CALL FOR TESTING

[Shay Elkin]

On Wed, 18 Sep 2002 23:27:01 +0000, Grover, Andrew wrote:

IBM ThinkPad 1161-93G, with a modified DSDT.

> - DOES IT BOOT?

Yes. 

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes,  but I find the following messages in my dmesg (00:10.0 is IDE,
01:00.0 is VGA):

 pci_irq-0293 [04] acpi_pci_irq_derive   : Unable to derive IRQ for device 00:10.0
PCI: No IRQ known for interrupt pin A of device 00:10.0 - using IRQ 15
 pci_irq-0293 [04] acpi_pci_irq_derive   : Unable to derive IRQ for device 01:00.0
PCI: No IRQ known for interrupt pin A of device 01:00.0 - using IRQ 10
 pci_irq-0293 [03] acpi_pci_irq_derive   : Unable to derive IRQ for device 00:10.0
PCI: No IRQ known for interrupt pin A of device 00:10.0 - using IRQ 15

On the bright side, the CPU doesn't to stuck in C mode it can't get out
of, and this is the first release to recieve button events. Guess it's
time I'll look into ospmd's code.

	Shay.




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

Re: CALL FOR TESTING

[Stephen Early]

Tested 2.4.19 with this patch on three machines: a Supermicro SMP board, 
a HP Pavilion N5472 laptop, and an Asus P2B board.

All three boot, assign interrupts properly (which is an improvement over 
stock 2.4.19 on the Supermicro board) and all features like buttons, 
battery info on the laptop, etc. work correctly (an improvement over the 
ACPI code in 2.4.19).

ACPI: RSDP (v000 AMI                        ) @ 0x000fb2d0
ACPI: RSDT (v001 SUPERM SUPERTBL 00000.00009) @ 0x17ff0000
ACPI: FADT (v001 SUPERM SUPERTBL 00000.00009) @ 0x17ff1000
ACPI: MADT (v001 SUPERM SUPERTBL 00000.00009) @ 0x17ff2000
ACPI: DSDT (v001 SUPERM SUPERMTB 00000.00001) @ 0x00000000

ACPI: RSDP (v000 HP-MCD                     ) @ 0x000f61b0
ACPI: RSDT (v001 HP-MCD   RSDT   01540.00000) @ 0x0f6fa497
ACPI: FADT (v001 HP-MCD GF DSDT  01540.00000) @ 0x0f6fef8c
ACPI: DSDT (v001 HP-MCD GF DSDT  01540.00000) @ 0x00000000

ACPI: RSDP (v000 ASUS                       ) @ 0x000f7f30
ACPI: RSDT (v001 ASUS   P2B      22616.11825) @ 0x07ffd000
ACPI: FADT (v001 ASUS   P2B      22616.11825) @ 0x07ffd080
ACPI: BOOT (v001 ASUS   P2B      22616.11825) @ 0x07ffd040
ACPI: DSDT (v001   ASUS P2B      00000.04096) @ 0x00000000

Stephen Early



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

Re: CALL FOR TESTING

[Al]

[-- Attachment #1.1: Type: text/plain, Size: 797 bytes --]

Cosi' scrisse "Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:

> I wanted to make a special request for testing of the 2.4 patch (or
> should I say, MEGA-patch).

Here we are.

> The main issues of importance are:
> 
> - DOES IT BOOT?
> - DOES IT ASSIGN INTERRUPTS PROPERLY?

It works for me. Mainboard is an ABIT KR7A, everything seems to run ok.

mater:~# uname -a
Linux mater 2.4.20-pre7-acpi #1 gio set 19 08:53:33 CEST 2002 i686 unknown

Attached: lspci; dmesg (relevant part).


Regards,


        Luca Amigoni


-- 

If you wrap the Internet around every person on the planet and spin the
planet, software flows in the network. [...] The resistance of the net-
work is directly proportional to the field strength of the intellectual
property system. (Eben Moglen)

[-- Attachment #1.2: lspci --]
[-- Type: text/plain, Size: 7556 bytes --]

00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=<none>
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: d2000000-d4ffffff
	Prefetchable memory behind bridge: d0000000-d1ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 04)
	Subsystem: Creative Labs CT4620 SBLive!
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 12
	Region 0: I/O ports at d000 [size=32]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.1 Input device controller: Creative Labs SB Live! (rev 01)
	Subsystem: Creative Labs Gameport Joystick
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 0: I/O ports at d400 [size=8]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at d800 [size=256]
	Region 1: Memory at d6001000 (32-bit, non-prefetchable) [size=256]

00:0f.0 SCSI storage controller: Adaptec 7892A (rev 02)
	Subsystem: Adaptec: Unknown device 62a0
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (10000ns min, 6250ns max), cache line size 08
	Interrupt: pin A routed to IRQ 11
	BIST result: 00
	Region 0: I/O ports at dc00 [disabled] [size=256]
	Region 1: Memory at d6000000 (64-bit, non-prefetchable) [size=4K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
	Subsystem: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Subsystem: VIA Technologies, Inc. Bus Master IDE
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Interrupt: pin A routed to IRQ 10
	Region 4: I/O ports at e000 [size=16]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1b) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, cache line size 08
	Interrupt: pin D routed to IRQ 12
	Region 4: I/O ports at e400 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1b) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, cache line size 08
	Interrupt: pin D routed to IRQ 12
	Region 4: I/O ports at e800 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.4 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1b) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, cache line size 08
	Interrupt: pin D routed to IRQ 12
	Region 4: I/O ports at ec00 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc. Millennium G450 Dual Head LX
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 8000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at d0000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at d2000000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at d3000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=<none>


[-- Attachment #1.3: dmesg --]
[-- Type: text/plain, Size: 4711 bytes --]

Linux version 2.4.20-pre7-acpi (root@mater) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 gio set 19 08:53:33 CEST 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
 BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 VIA694                     ) @ 0x000f6e00
ACPI: RSDT (v001 VIA694 AWRDACPI 16944.11825) @ 0x1fff3000
ACPI: FADT (v001 VIA694 AWRDACPI 16944.11825) @ 0x1fff3040
ACPI: DSDT (v001 VIA694 AWRDACPI 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: MADT not present
Kernel command line: BOOT_IMAGE=acpi ro root=805 video=matrox:vesa:0x1B8
Found and enabled local APIC!
Initializing CPU#0
Detected 1467.319 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2929.45 BogoMIPS
Memory: 515516k/524224k available (1604k kernel code, 8324k reserved, 510k data, 276k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU: AMD Athlon(tm) XP 1700+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1467.3383 MHz.
..... host bus clock speed is 266.7888 MHz.
cpu: 0, clocks: 2667888, slice: 1333944
CPU0<T0:2667888,T1:1333936,D:8,S:1333944,C:2667888>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20020918
PCI: PCI BIOS revision 2.10 entry at 0xfb4d0, last bus=1
PCI: Using configuration type 1
 tbxface-0099 [03] Acpi_load_tables      : ACPI Tables successfully loaded
Parsing Methods:................................................................................................
Table [DSDT] - 383 Objects with 31 Devices 96 Methods 22 Regions
ACPI Namespace successfully loaded at root c036ea1c
evxfevnt-0074 [04] Acpi_enable           : Transition to ACPI mode successful
Executing all Device _STA and_INI methods:...............................
31 Devices found containing: 31 _STA, 2 _INI methods
Completing Region/Field/Buffer/Package initialization:.....................................................
Initialized 18/22 Regions 6/8 Fields 16/17 Buffers 13/13 Packages (383 nodes)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:12.00 not present in PCI namespace
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports C1 C2, 2 throttling states)
ACPI: Thermal Zone [THRM] (51 C)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: CALL FOR TESTING

[Federico Di Gregorio]

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

Il gio, 2002-09-19 alle 08:27, Grover, Andrew ha scritto:
> I wanted to make a special request for testing of the 2.4 patch (or should I
> say, MEGA-patch).
> 
> Marcelo has asked for widespread testing of it, in anticipation of likely
> 2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
> soon, but am posting this here first to hopefully weed out any really bad
> bugs that may have crept in.
> 
> The main issues of importance are:
> 
> - DOES IT BOOT?

yep. here are the first lines, to identify my laptop model:

ACPI: RSDP (v000 ASUS                       ) @ 0x000f71d0
ACPI: RSDT (v001 ASUS   S1300A   12336.12337) @ 0x0f7e9000
ACPI: FADT (v001 ASUS   S1300A   12336.12337) @ 0x0f7e9080
ACPI: BOOT (v001 ASUS   S1300A   12336.12337) @ 0x0f7e9040
ACPI: DSDT (v001   ASUS S1300A   00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist

> - DOES IT ASSIGN INTERRUPTS PROPERLY?
> 
> Failure to do so either indicates a bug that we need to fix (fast) or a
> system that should go on the blacklist. dmesg now includes the DSDT
> signature to aid blacklisting.

everything seems to work fine. how can i say if an interrupt has been
wrongly assigned? anyway the only problem has always been there but i
don't know if it is about irq:

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:1f.03 not
present in PCI namespace
pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:1f.06 not
present in PCI namespace
ACPI: Power Resource [PFAN] (off)

and later:

acpi_processor-2115 [07] acpi_processor_get_inf: Invalid PBLK length [5]

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org
INIT.D Developer                                           fog-NGVKUo/i/6DYtjvyW6yDsg@public.gmane.org
  Spesso crescere ed andare a vivere da soli è l'unico modo di restare
   bambini.                                             -- Alice Fontana

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: CALL FOR TESTING

[Matthew Wilcox]

On Thu, Sep 19, 2002 at 11:47:53AM +0200, Federico Di Gregorio wrote:
> everything seems to work fine. how can i say if an interrupt has been
> wrongly assigned? anyway the only problem has always been there but i
> don't know if it is about irq:

So the problem exists in both the vanilla Marcelo kernel and in the
ACPI-patched kernel?  That doesn't seem like a reason to exclude the
ACPI patch from going in.

> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
> pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:1f.03 not
> present in PCI namespace
> pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:1f.06 not
> present in PCI namespace

Interesting ... could you send the output from /sbin/lspci -s 00: I
suspect a bug in your machine's _PRT -- it's describing routing for a
device which doesn't exist.  Maybe we should silently ignore that.

> ACPI: Power Resource [PFAN] (off)
> 
> and later:
> 
> acpi_processor-2115 [07] acpi_processor_get_inf: Invalid PBLK length [5]

Interesting.  The code does:

        else if (object.processor.pblk_length < 6)
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid PBLK length [%d]\n",
                        object.processor.pblk_length));
        else {
                pr->throttling.address = object.processor.pblk_address;
                pr->throttling.duty_offset = acpi_fadt.duty_offset;
                pr->throttling.duty_width = acpi_fadt.duty_width;
                pr->power.states[ACPI_STATE_C2].address =
                        object.processor.pblk_address + 4;
                pr->power.states[ACPI_STATE_C3].address =
                        object.processor.pblk_address + 5;
        }

so you're one element short, and that element is what tells us the address
to call to enter C3.  Clearly this is a broken BIOS, but I wonder if we
couldn't hande this more cleanly ...

	else if (object.processor.pblk_length < 4)
		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid PBLK length [%d]\n",
			object.processor.pblk_length));
	else {
		pr->throttling.address = object.processor.pblk_address;
		pr->throttling.duty_offset = acpi_fadt.duty_offset;
		pr->throttling.duty_width = acpi_fadt.duty_width;
		if (object.processor.pblk_length >= 5)
			pr->power.states[ACPI_STATE_C2].address =
				object.processor.pblk_address + 4;
		if (object.processor.pblk_length >= 6)
			pr->power.states[ACPI_STATE_C3].address =
				object.processor.pblk_address + 5;
	}

Andy, what do you think?

-- 
Revolutions do not require corporate support.


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

Re: CALL FOR TESTING

[Federico Di Gregorio]

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

Il gio, 2002-09-19 alle 15:44, Matthew Wilcox ha scritto:
> On Thu, Sep 19, 2002 at 11:47:53AM +0200, Federico Di Gregorio wrote:
> > everything seems to work fine. how can i say if an interrupt has been
> > wrongly assigned? anyway the only problem has always been there but i
> > don't know if it is about irq:
> 
> So the problem exists in both the vanilla Marcelo kernel and in the
> ACPI-patched kernel?  That doesn't seem like a reason to exclude the
> ACPI patch from going in.

acpi kernel is much better than marcelo's. i get a lot of errors on it.

> > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
> > pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:1f.03 not
> > present in PCI namespace
> > pci_bind-0194 [05] acpi_pci_bind         : Device 00:00:1f.06 not
> > present in PCI namespace
> 
> Interesting ... could you send the output from /sbin/lspci -s 00: I
> suspect a bug in your machine's _PRT -- it's describing routing for a
> device which doesn't exist.  Maybe we should silently ignore that.
> 
> > ACPI: Power Resource [PFAN] (off)
> > 
> > and later:
> > 
> > acpi_processor-2115 [07] acpi_processor_get_inf: Invalid PBLK length [5]
[snip]
> so you're one element short, and that element is what tells us the address
> to call to enter C3.  Clearly this is a broken BIOS, but I wonder if we
> couldn't hande this more cleanly ...

thank you very much for explaining exactly what's happening here. i am
sending you my dsts and lspci info in a separate private mail to not
disturb the ML.

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org
INIT.D Developer                                           fog-NGVKUo/i/6DYtjvyW6yDsg@public.gmane.org
                           Don't dream it. Be it. -- Dr. Frank'n'further

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: CALL FOR TESTING

[Matthew Wilcox]

On Thu, Sep 19, 2002 at 03:51:44PM +0200, Federico Di Gregorio wrote:
> acpi kernel is much better than marcelo's. i get a lot of errors on it.

ok, so that's a +1 for the patch ;-)

> > Interesting ... could you send the output from /sbin/lspci -s 00: I
> > suspect a bug in your machine's _PRT -- it's describing routing for a
> > device which doesn't exist.  Maybe we should silently ignore that.

> 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
> 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
> 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02)

So the _PRT is describing routing for ISA devices which don't exist... but
I wonder if they _might_ exist?  Is it possible that if you plug
your laptop into a docking station those devices appear, for example?

Ah, checking the code:

        /* 
         * Locate PCI Device
         * -----------------
         * Locate matching device in PCI namespace.  If it doesn't exist
         * this typically means that the device isn't currently inserted
         * (e.g. docking station, port replicator, etc.).
         */

        if (!data->dev) {
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
                        "Device %02x:%02x:%02x.%02x not present in PCI namespace
\n",
                        data->id.segment, data->id.bus, 
                        data->id.device, data->id.function));

Can I suggest we turn that ACPI_DB_ERROR into ACPI_DB_WARN or even
ACPI_DB_INFO?  This really isn't an _error_.

-- 
Revolutions do not require corporate support.


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

Re: CALL FOR TESTING

[KOCHI, Takayoshi]

On Thu, 19 Sep 2002 15:14:16 +0100
Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:

> So the _PRT is describing routing for ISA devices which don't exist... but
> I wonder if they _might_ exist?  Is it possible that if you plug
> your laptop into a docking station those devices appear, for example?

The same situation also happens for hot-pluggable PCI slots case.
A server with more than 100 empty PCI slots will generate very
annoying massive warning messages on boot (as every slot descrive
8 ACPI Device's for each function).

> Ah, checking the code:
> 
>         /* 
>          * Locate PCI Device
>          * -----------------
>          * Locate matching device in PCI namespace.  If it doesn't exist
>          * this typically means that the device isn't currently inserted
>          * (e.g. docking station, port replicator, etc.).
>          */
> 
>         if (!data->dev) {
>                 ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
>                         "Device %02x:%02x:%02x.%02x not present in PCI namespace
> \n",
>                         data->id.segment, data->id.bus, 
>                         data->id.device, data->id.function));
> 
> Can I suggest we turn that ACPI_DB_ERROR into ACPI_DB_WARN or even
> ACPI_DB_INFO?  This really isn't an _error_.

Right,
I think we should ignore the case unless we are debugging ACPI <-> PCI
device matching.  So I'd vote ACPI_DB_INFO.

Thanks,
-- 
KOCHI, Takayoshi <t-kouchi-f7IHDacdhdx8UrSeD/g0lQ@public.gmane.org/t-kouchi>



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

Re: CALL FOR TESTING

[Dirk Meul]

Hello.

Am Don, 2002-09-19 um 08.27 schrieb Grover, Andrew:
> - DOES IT BOOT?

My ASUS P3B-F with Celeron-850 CPU boots.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes everything looks fine.

Regards,
-- 
Dirk Meul <dirk.meul-jy7zG81Tlw8@public.gmane.org>



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

Re: CALL FOR TESTING

[Knut Neumann]

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

On Thu, 2002-09-19 at 08:27, Grover, Andrew wrote:
> - DOES IT BOOT?

No. This is a Gigabyte 7IXE4 with an Athlon 1,3 GHz. It throws two
oopses (NULL pointer deref at 0..04) just after providing information
about thermal zone. I can write them down, type them in and send them if
necessary.

> Failure to do so either indicates a bug that we need to fix (fast) or a
> system that should go on the blacklist. dmesg now includes the DSDT
> signature to aid blacklisting.

I attach a dmesg-output when booting with acpi=off. I hope that helps.

-Knut

PS: Did you get the ospmd patches I sent to you?

-- 
Knut Neumann <knut.neumann-4bfl1RV3iZDOEhgYWvzSCYQuADTiUCJX@public.gmane.org>
Physikalische Grundpraktika - Heinrich-Heine Universitaet Duesseldorf
Raum 25.33.01.63  -   Universitaetsstrasse 1   -  D-40225 Duesseldorf
fon: +49-211-81-11314                           fax: +49-211-81-13105









[-- Attachment #2: dmesg.ok --]
[-- Type: text/plain, Size: 6011 bytes --]

This buffer is for notes you don't want to save, and for Lisp evaluation.
If you want to create a file, visit that file with C-x C-f,
then enter the text in that file's own buffer.

Linux version 2.4.20-pre7 (root@bacchus) (gcc version 2.95.4 20011002 (Debian prerelease)) #2 Thu Sep 19 13:17:54 CEST 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000000f00000 (usable)
 BIOS-e820: 0000000000f00000 - 0000000001000000 (reserved)
 BIOS-e820: 0000000001000000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
 BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=devel ro root=301 acpi=off
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 1312.973 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2614.88 BogoMIPS
Memory: 255708k/262080k available (1251k kernel code, 4960k reserved, 381k data, 260k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1312.9365 MHz.
..... host bus clock speed is 201.9900 MHz.
cpu: 0, clocks: 2019900, slice: 1009950
CPU0<T0:2019888,T1:1009936,D:2,S:1009950,C:2019900>
mtrr: v1.40 (20010327) Richard Gooch (rgooch-r1x6VkxMR+00zabcByZE4g@public.gmane.org)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20020918
ACPI: Disabled via command line (acpi=off)
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, 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: Using IRQ router AMD756 VIPER [1022/740b] at 00:07.3
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI IS
APNP enabled
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD7409: IDE controller on PCI bus 00 dev 39
AMD7409: chipset revision 7
AMD7409: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD400AB-00BVA0, ATA DISK drive
hdc: DVD-ROM BDV212B, ATAPI CD/DVD-ROM drive
hdd: RICOH CD-R/RW MP7083A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c0309c04, I/O limit 4095Mb (mask 0xffffffff)
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(33)
hdc: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdd: set_drive_speed_status: error=0x04
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Partition check:
 hda: hda1 hda2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
8139too Fast Ethernet driver 0.9.26
AMD756: dev 10ec:8139, router pirq : 1 get irq : 10
PCI: Found IRQ 10 for device 00:0c.0
PCI: Sharing IRQ 10 with 00:08.0
eth0: RealTek RTL8139 Fast Ethernet at 0xd080df00, 00:10:a7:0a:71:f0, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139C'
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected AMD Irongate chipset
agpgart: AGP aperture is 64M @ 0xe8000000
[drm] AGP 0.99 on AMD Irongate @ 0xe8000000 64MB
[drm] Initialized r128 2.2.0 20010917 on minor 0
[drm] AGP 0.99 on AMD Irongate @ 0xe8000000 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 1
es1371: version v0.30 time 13:15:13 Sep 19 2002
AMD756: dev 1274:5880, router pirq : 1 get irq : 10
PCI: Found IRQ 10 for device 00:08.0
PCI: Sharing IRQ 10 with 00:0c.0
es1371: found chip, vendor id 0x1274 device id 0x5880 revision 0x02
es1371: found es1371 rev 2 at io 0xdc00 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23)
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 260k freed

Re: CALL FOR TESTING

[Pavel Machek]

Hi!

> > - DOES IT BOOT?
> 
> No. This is a Gigabyte 7IXE4 with an Athlon 1,3 GHz. It throws two
> oopses (NULL pointer deref at 0..04) just after providing information
> about thermal zone. I can write them down, type them in and send them if
> necessary.

HP Omnibook oopses if CPU is too hot during boot. Can you try booting from
cold system?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



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

Re: CALL FOR TESTING

[kneumann-4bfl1RV3iZDOEhgYWvzSCYQuADTiUCJX]

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?

In fact this seems not to be irq-related in any way.

-Knut

On Wed, 18 Sep 2002, Pavel Machek wrote:

> Hi!
> 
> > > - DOES IT BOOT?
> > 
> > No. This is a Gigabyte 7IXE4 with an Athlon 1,3 GHz. It throws two
> > oopses (NULL pointer deref at 0..04) just after providing information
> > about thermal zone. I can write them down, type them in and send them if
> > necessary.
> 
> HP Omnibook oopses if CPU is too hot during boot. Can you try booting from
> cold system?
> 								Pavel
> -- 
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
> 
> 



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

Re: CALL FOR TESTING

[Pavel Machek]

Hi!

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

It depends on temperature thresholds. It seems that if it is over
active threshold it dies, or something like that.
									Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


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

Re: CALL FOR TESTING

[Ernst Herzberg]

Oopses if CPU is too hot? I've seen that on a gericom M6-T too. Previous 
versions of the acpi patches has no such bug.  Ok, i am no absolute shure, i 
have seen that starting with arround acpi-20020728 or acpi-20020815. It is 
not easy to reproduce, summertime is over ;-) 

<earny>

On Mittwoch, 18. September 2002 07:54, Pavel Machek wrote:
> Hi!
>
>
> HP Omnibook oopses if CPU is too hot during boot. Can you try booting from
> cold system?
> 								Pavel



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

Re: CALL FOR TESTING

[Ernst Herzberg]

On Donnerstag, 26. September 2002 02:37, Ernst Herzberg wrote:
> Oopses if CPU is too hot? I've seen that on a gericom M6-T too. Previous
> versions of the acpi patches has no such bug.  Ok, i am no absolute shure,
> i have seen that starting with arround acpi-20020728 or acpi-20020815. It
> is not easy to reproduce, summertime is over ;-)
>
> <earny>
>
> On Mittwoch, 18. September 2002 07:54, Pavel Machek wrote:
> > Hi!
> >
> >
> > HP Omnibook oopses if CPU is too hot during boot. Can you try booting
> > from cold system?
> > 								Pavel
>


Yupp, i can reproduce this. Heated up with burnP6 an a little 'partial cooling 
preventer' to aprox. 65 to 75°C (the temperature display jumps between this 
values in the thermalzone, fan is forced 'off', means running half speed). 
The laptop is doing his job without problems...  i type reboot:

[.... the kernel loads ....]
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols ICMP, UDP, TCP, IGMP
Unable to handle kernel NULL pinter dereference at virtual address 00000004
 printing eip
c011fe45
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c011fe45>]  Not tainted
EFLAGS: 00010082
eax: c159bea8  ebx: 00000206  ecx: 00000000  edx: 00000000
esi: c02cf168  edi: c0284473  ebp:  0008e000  esp:  c159dfa8
ds: 0018  es: 0018  ss: 0018
Process swapper (pid: 1, stackpage=c159d000)
Stack: c02cf0e0 000001f5 c01fd0b5 c02cf168 c02cfb54 00000000 c02eafba c02cf0e0
         c02eb1c9 ........
Call Trace:   [<c01fd0b5>] [>c010502f>] [>c0106ff0>]

Code 89 72 04 89 16 89 46 04 89 30 53 9d eb 14 53 9d 8b 44 24 08
 <0>Kernel panic: Attempted to kill init!

[... a couple seconds later again Oops 0002, Process swapper ....]
 <0> kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

-------------------------------

The laptop is running without problems at  temperature above 70°C. The oops 
only occur during boot. If i power off for a couple of minutes it will boot 
without problems. 

lidl:/proc/acpi/thermal_zone/THRM # cat trip_points
critical (S5):           90 C
passive:                 65 C: tc1=4 tc2=3 tsp=600 devices=0xc158c5e0
active[0]:               50 C: devices=0xc158c8e0

'active' is not the problem, boot with temp > 50°C but less about 65°C will 
not oops. Looks like that 'passive' is the boot preventer -)

lidl:~ # uname -a
Linux lidl 2.4.20-pre7 #5 Thu Sep 19 22:51:02 CEST 2002 i686 unknown
lidl:~ # cat /proc/acpi/info
version:                 20020918
states:                  S0 S1 S4 S5
lidl:~ #

<Earny>




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

Re: CALL FOR TESTING

[Pavel Machek]

Hi!
  > Yupp, i can reproduce this. Heated up with burnP6 an a little 'partial cooling 
> preventer' to aprox. 65 to 75°C (the temperature display jumps between this 
> values in the thermalzone, fan is forced 'off', means running half speed). 
> The laptop is doing his job without problems...  i type reboot:
> 
> [.... the kernel loads ....]
> md: ... autorun DONE.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols ICMP, UDP, TCP, IGMP
> Unable to handle kernel NULL pinter dereference at virtual address 00000004
>  printing eip
> c011fe45
> *pde = 00000000
> Oops: 0002
> CPU:    0
> EIP:    0010:[<c011fe45>]  Not tainted

Can you ksymoops it?

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



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

Re: CALL FOR TESTING

[Ernst Herzberg]

On Montag, 30. September 2002 04:00, Pavel Machek wrote:
> Hi!
> Can you ksymoops it?

OkOk ;-) Same procedure: I recompiled the kernel to have a clean System.map,
installed my 'cooling preventer', and started burnP6. If the temp reaches 
about 75 °C, i type 'reboot'.

(I have also checked for a longer time, that the laptop is running at this 
temp without any problems. If  i let the laptop cooling down, he will 
boot up without any problems.)

The results differs at each reboot, so i append 3 different oops'es.
The first 2 ones are during a normal boot, the second seems more often than 
the first one. Then i tried to boot into single user. In this case it is not easy to 
see the first oops on the screen: If i try to enter the root passwort, i get 
immediatly a bunch of oops'es, unable to read the first one. The third oops
is done in single user mode, not typing in the password and wait. The oops('es) 
appears after a couple of seconds.

Enjoy ;-)

(i was not able to use a serial console, i typed careful all oops'es from the 
display. Don't blame me, if you find a typo :-)

##########################################################################

Gericom M6-T 1200MHz 

earny@lidl:~> uname -a
Linux lidl 2.4.20-pre7 #6 Tue Oct 1 00:55:43 CEST 2002 i686 unknown
earny@lidl:~> cat /proc/acpi/info
version:                 20020918
states:                  S0 S1 S4 S5
earny@lidl:~> ksymoops -v /usr/src/linux/vmlinux < oops1
ksymoops 2.4.6 on i686 2.4.20-pre7.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20-pre7/ (default)
     -m /boot/System.map (default)

Oops: 0002
CPU: 0
EIP:  0010:[<c011fe45>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: c159cea8 ebx: 00000006 ecx: 00000000 edx: 00000000
esi: c1593478 edi: c01c11e8 ebp: 00000000 esp: dea5dd44
ds: 0018 es: 0018 ss: 0018
Process ldconfig (pid: 689, stackpage=dea5d000)
Stack: c1593460 00000246 c01bb1a1 c1593478 00001000 c031fd84 c031fd40 c01c1b64
       c031fd84 c01c11e8 000007d0 00000000 000001f6 c15c9c00 c031fd84 c031fd84
       00000000 ddf82140 00000001 00000008 0031fd84 c01c3803 00000000 c031fd84
Call Trace:    [<c01bb1a1>] [<c01c1b64>] [<c01c11e8>] [<c01c3803>] [<c01c6e75>]
  [<c01bc497>] [<c01bc4f7>] [<c01bc857>] [<c01bc8db>] [<c01ae6e4>] [<c011d2ec>]
  [<c01382c2>] [<c01288f5>] [<c0128934>] [<c0129a8e>] [<c01265f2>] [<c012676e>]
  [<c0115d04>] [<c0115ba4>] [<c010d5ee>] [<c010d616>] [<c010874c>]
Code: 89 72 04 89 16 89 46 04 89 30 53 9d eb 14 53 9d 8b 44 24 08


>>EIP; c011fe45 <add_timer+b5/dc>   <=====

>>eax; c159cea8 <_end+126fa88/224ecbe0>
>>esi; c1593478 <_end+1266058/224ecbe0>
>>edi; c01c11e8 <ide_dma_intr+0/ac>
>>esp; dea5dd44 <_end+1e730924/224ecbe0>

Trace; c01bb1a1 <ide_set_handler+59/64>
Trace; c01c1b64 <ide_dmaproc+188/36c>
Trace; c01c11e8 <ide_dma_intr+0/ac>
Trace; c01c3803 <via82cxxx_dmaproc+cf/dc>
Trace; c01c6e75 <do_rw_disk+2bd/528>
Trace; c01bc497 <start_request+147/220>
Trace; c01bc4f7 <start_request+1a7/220>
Trace; c01bc857 <ide_do_request+287/2d4>
Trace; c01bc8db <do_ide_request+f/14>
Trace; c01ae6e4 <generic_unplug_device+20/28>
Trace; c011d2ec <__run_task_queue+50/5c>
Trace; c01382c2 <block_sync_page+16/1c>
Trace; c01288f5 <__lock_page+8d/b8>
Trace; c0128934 <lock_page+14/18>
Trace; c0129a8e <filemap_nopage+136/1f8>
Trace; c01265f2 <do_no_page+52/17c>
Trace; c012676e <handle_mm_fault+52/b0>
Trace; c0115d04 <do_page_fault+160/480>
Trace; c0115ba4 <do_page_fault+0/480>
Trace; c010d5ee <old_mmap+ea/120>
Trace; c010d616 <old_mmap+112/120>
Trace; c010874c <error_code+34/3c>

Code;  c011fe45 <add_timer+b5/dc>
00000000 <_EIP>:
Code;  c011fe45 <add_timer+b5/dc>   <=====
   0:   89 72 04                  mov    %esi,0x4(%edx)   <=====
Code;  c011fe48 <add_timer+b8/dc>
   3:   89 16                     mov    %edx,(%esi)
Code;  c011fe4a <add_timer+ba/dc>
   5:   89 46 04                  mov    %eax,0x4(%esi)
Code;  c011fe4d <add_timer+bd/dc>
   8:   89 30                     mov    %esi,(%eax)
Code;  c011fe4f <add_timer+bf/dc>
   a:   53                        push   %ebx
Code;  c011fe50 <add_timer+c0/dc>
   b:   9d                        popf
Code;  c011fe51 <add_timer+c1/dc>
   c:   eb 14                     jmp    22 <_EIP+0x22> c011fe67 <add_timer+d7/dc>
Code;  c011fe53 <add_timer+c3/dc>
   e:   53                        push   %ebx
Code;  c011fe54 <add_timer+c4/dc>
   f:   9d                        popf
Code;  c011fe55 <add_timer+c5/dc>
  10:   8b 44 24 08               mov    0x8(%esp,1),%eax

earny@lidl:~>###############################################################
earny@lidl:~> ksymoops -v /usr/src/linux/vmlinux < oops2
ksymoops 2.4.6 on i686 2.4.20-pre7.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20-pre7/ (default)
     -m /boot/System.map (default)

Oops: 0002
CPU: 0
EIP:  0010:[<c011ff45>]  Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: c159cea8 ebx: dea56574 ecx: 00000000 edx: 00000000
esi: 00000206 edi: 00000000 ebp: dea56520 esp: deb2bd14
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 667, stackpage=deb2b000)
Stack: dea56520 00000000 00000000 c0239ca9 dea56574 0000175c c029c000 deb2bd78
       df3e3ebc c0239cd0 c029c000 dea56520 00000000 00000000 deb2bd78 c01640cd
       c029c000 dea56520 00000000 00000000 dea56574 fffffff5 deadbb9c dea56520
Call Trace:    [<c0239ca9>] [<c0239cd0>] [<c01640cd>] [<c023a177>] [<c023a613>]
  [<c023a3cc>] [<c0163eef>] [<c0163fae>] [<c0164b49>] [<c01391b7>] [<c01392f8>]
  [<c0148e79>] [<c0149132>] [<c0148f94>] [<c01494b4>] [<c010865b>]
Code: 89 5a 04 89 13 89 43 04 89 18 56 9d 89 f8 5b 5e 5f c3 90 53


>>EIP; c011ff45 <mod_timer+d9/ec>   <=====

>>eax; c159cea8 <_end+126fa88/224ecbe0>
>>ebx; dea56574 <_end+1e729154/224ecbe0>
>>ebp; dea56520 <_end+1e729100/224ecbe0>
>>esp; deb2bd14 <_end+1e7fe8f4/224ecbe0>

Trace; c0239ca9 <__rpc_sleep_on+19d/1a4>
Trace; c0239cd0 <rpc_sleep_on+20/44>
Trace; c01640cd <nfs_flushd+f1/fc>
Trace; c023a177 <__rpc_execute+9f/2a4>
Trace; c023a613 <rpc_new_task+17/15c>
Trace; c023a3cc <rpc_execute+50/64>
Trace; c0163eef <nfs_reqlist_init+6f/88>
Trace; c0163fae <nfs_reqlist_alloc+4a/58>
Trace; c0164b49 <nfs_read_super+825/908>
Trace; c01391b7 <get_sb_nodev+37/6c>
Trace; c01392f8 <do_kern_mount+80/104>
Trace; c0148e79 <do_add_mount+65/130>
Trace; c0149132 <do_mount+14e/168>
Trace; c0148f94 <copy_mount_options+50/a0>
Trace; c01494b4 <sys_mount+84/c4>
Trace; c010865b <system_call+33/38>

Code;  c011ff45 <mod_timer+d9/ec>
00000000 <_EIP>:
Code;  c011ff45 <mod_timer+d9/ec>   <=====
   0:   89 5a 04                  mov    %ebx,0x4(%edx)   <=====
Code;  c011ff48 <mod_timer+dc/ec>
   3:   89 13                     mov    %edx,(%ebx)
Code;  c011ff4a <mod_timer+de/ec>
   5:   89 43 04                  mov    %eax,0x4(%ebx)
Code;  c011ff4d <mod_timer+e1/ec>
   8:   89 18                     mov    %ebx,(%eax)
Code;  c011ff4f <mod_timer+e3/ec>
   a:   56                        push   %esi
Code;  c011ff50 <mod_timer+e4/ec>
   b:   9d                        popf
Code;  c011ff51 <mod_timer+e5/ec>
   c:   89 f8                     mov    %edi,%eax
Code;  c011ff53 <mod_timer+e7/ec>
   e:   5b                        pop    %ebx
Code;  c011ff54 <mod_timer+e8/ec>
   f:   5e                        pop    %esi
Code;  c011ff55 <mod_timer+e9/ec>
  10:   5f                        pop    %edi
Code;  c011ff56 <mod_timer+ea/ec>
  11:   c3                        ret
Code;  c011ff57 <mod_timer+eb/ec>
  12:   90                        nop
Code;  c011ff58 <del_timer+0/44>
  13:   53                        push   %ebx

 <0>Kernel panic: Aiee, killing interrupt handler!
earny@lidl:~>###############################################################
earny@lidl:~> ksymoops -v /usr/src/linux/vmlinux < oops3
ksymoops 2.4.6 on i686 2.4.20-pre7.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20-pre7/ (default)
     -m /boot/System.map (default)

Unable to handle kernel NULL pointer dereference at virtual address 00000004
c011fe45
*pde = 00000000
Oops: 0002
CPU: 0
EIP:  0010:[<c011fe45>]  Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: c159cea8 ebx: 00000206 ecx: 00000000 edx: 00000000
esi: c159bf2c edi: 00000000 ebp: c159bf40 esp: c159bf14
ds: 0018 es: 0018 ss: 0018
Process init (pid: 1, stackpage=c159b000)
Stack: c159bf2c 000017eb c0116886 c159bf2c 00000000 dff652a0 00000000 00000000
       000017eb c159a000 c01167d0 c159bf74 c01417b1 00000004 00000001 c15c1b38
       00000104 00000400 c159a000 000001f4 0000000b 00000000 00000000 df995000
Call Trace:    [<c0116886>] [<c01167d0>] [<c01417b1>] [<c0141b50>] [<c010865b>]
Code: 89 72 04 89 16 89 46 04 89 30 53 9d eb 14 53 9d 8b 44 24 08


>>EIP; c011fe45 <add_timer+b5/dc>   <=====

>>eax; c159cea8 <_end+126fa88/224ecbe0>
>>esi; c159bf2c <_end+126eb0c/224ecbe0>
>>ebp; c159bf40 <_end+126eb20/224ecbe0>
>>esp; c159bf14 <_end+126eaf4/224ecbe0>

Trace; c0116886 <schedule_timeout+6e/94>
Trace; c01167d0 <process_timeout+0/48>
Trace; c01417b1 <do_select+19d/1dc>
Trace; c0141b50 <sys_select+338/474>
Trace; c010865b <system_call+33/38>

Code;  c011fe45 <add_timer+b5/dc>
00000000 <_EIP>:
Code;  c011fe45 <add_timer+b5/dc>   <=====
   0:   89 72 04                  mov    %esi,0x4(%edx)   <=====
Code;  c011fe48 <add_timer+b8/dc>
   3:   89 16                     mov    %edx,(%esi)
Code;  c011fe4a <add_timer+ba/dc>
   5:   89 46 04                  mov    %eax,0x4(%esi)
Code;  c011fe4d <add_timer+bd/dc>
   8:   89 30                     mov    %esi,(%eax)
Code;  c011fe4f <add_timer+bf/dc>
   a:   53                        push   %ebx
Code;  c011fe50 <add_timer+c0/dc>
   b:   9d                        popf
Code;  c011fe51 <add_timer+c1/dc>
   c:   eb 14                     jmp    22 <_EIP+0x22> c011fe67 <add_timer+d7/dc>
Code;  c011fe53 <add_timer+c3/dc>
   e:   53                        push   %ebx
Code;  c011fe54 <add_timer+c4/dc>
   f:   9d                        popf
Code;  c011fe55 <add_timer+c5/dc>
  10:   8b 44 24 08               mov    0x8(%esp,1),%eax

 <0>Kernel panic: Attempted to kill init!
 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000004
c012056b
*pde = 00000000
Oops: 0002
CPU: 0
EIP:  0010:[<c012056b>]  Not tainted
EFLAGS: 00010012
eax: 00000000 ebx: c0302a1c ecx: c159cea8 edx: 00000004
esi: 00000000 edi: c0302960 ebp: 00000000 esp: c159bd48
ds: 0018 es: 0018 ss: 0018
Process init (pid: 1, stackpage=c159b000)
Stack: 00000000 c02f7540 00000000 c02f7560 00001700 00000000 00001700 00000004
       00000001 c159bd6c c159bd6c c011d232 c011d176 00000000 00000001 c02f7560
       fffffffe c011cf9a c02f7560 00000000 c02f5900 00000000 c159bdbc 00000046
Call Trace:    [<c011d232>] [<c011d176>] [<c011cf9a>] [<c0109b22>] [<c010bcf8>]
  [<c0240018>] [<c01aca51>] [<c0118eb5>] [<c011bbf0>] [<c0108c16>] [<c0115ef7>]
  [<c0115ba4>] [<e2821f41>] [<c012f3ff>] [<c010874c>] [<c011fe45>] [<c0116886>]
  [<c01167d0>] [<c01417b1>] [<c0141b50>] [<c010865b>]
Code: 89 46 04 89 30 8b 41 08 c7 01 00 00 00 00 c7 41 04 00 00 00


>>EIP; c012056b <timer_bh+10b/368>   <=====

>>ebx; c0302a1c <tv2+bc/220>
>>ecx; c159cea8 <_end+126fa88/224ecbe0>
>>edi; c0302960 <tv2+0/220>
>>esp; c159bd48 <_end+126e928/224ecbe0>

Trace; c011d232 <bh_action+1a/40>
Trace; c011d176 <tasklet_hi_action+4a/70>
Trace; c011cf9a <do_softirq+5a/a4>
Trace; c0109b22 <do_IRQ+96/a8>
Trace; c010bcf8 <call_do_IRQ+5/d>
Trace; c0240018 <modify_qos+b4/d4>
Trace; c01aca51 <panic_blink+15/84>
Trace; c0118eb5 <panic+d5/e8>
Trace; c011bbf0 <do_exit+48/240>
Trace; c0108c16 <die+56/58>
Trace; c0115ef7 <do_page_fault+353/480>
Trace; c0115ba4 <do_page_fault+0/480>
Trace; e2821f41 <[reiserfs]inode2sd+85/94>
Trace; c012f3ff <__alloc_pages+3f/15c>
Trace; c010874c <error_code+34/3c>
Trace; c011fe45 <add_timer+b5/dc>
Trace; c0116886 <schedule_timeout+6e/94>
Trace; c01167d0 <process_timeout+0/48>
Trace; c01417b1 <do_select+19d/1dc>
Trace; c0141b50 <sys_select+338/474>
Trace; c010865b <system_call+33/38>

Code;  c012056b <timer_bh+10b/368>
00000000 <_EIP>:
Code;  c012056b <timer_bh+10b/368>   <=====
   0:   89 46 04                  mov    %eax,0x4(%esi)   <=====
Code;  c012056e <timer_bh+10e/368>
   3:   89 30                     mov    %esi,(%eax)
Code;  c0120570 <timer_bh+110/368>
   5:   8b 41 08                  mov    0x8(%ecx),%eax
Code;  c0120573 <timer_bh+113/368>
   8:   c7 01 00 00 00 00         movl   $0x0,(%ecx)
Code;  c0120579 <timer_bh+119/368>
   e:   c7 41 04 00 00 00 00      movl   $0x0,0x4(%ecx)

 <0>Kernel Panic: Aiee, killing interrupt handler!
earny@lidl:~>#############################################################

PS:
If you need more oops'es, wait until i have a null modem cable and
the serial console up and running ;-))


-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at http://www.ServePath.com/indexfm.htm

Re: CALL FOR TESTING

[Ernst Herzberg]

On Montag, 30. September 2002 04:00, Pavel Machek wrote:
> Hi!
>
>   > Yupp, i can reproduce this. Heated up with burnP6 an a little 'partial
>   > cooling
> >
> > preventer' to aprox. 65 to 75°C (the temperature display jumps between
> > this values in the thermalzone, fan is forced 'off', means running half
> > speed). The laptop is doing his job without problems...  i type reboot:
> >
> > [.... the kernel loads ....]
> > md: ... autorun DONE.
> > NET4: Linux TCP/IP 1.0 for NET4.0
> > IP Protocols ICMP, UDP, TCP, IGMP
> > Unable to handle kernel NULL pinter dereference at virtual address
> > 00000004 printing eip
> > c011fe45
> > *pde = 00000000
> > Oops: 0002
> > CPU:    0
> > EIP:    0010:[<c011fe45>]  Not tainted
>
> Can you ksymoops it?

------

Fixed with acpi-20021002 (doublechecked)

Thx, great work :)

<Earny>



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

Re: Testing: NVidia closed driver fails.

[P. Christeas]

> I wanted to make a special request for testing of the 2.4 patch (or should
> I say, MEGA-patch).
>
>
> - DOES IT BOOT?
> - DOES IT ASSIGN INTERRUPTS PROPERLY?
>

I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon XP 
1.7+, VIA VT8637 KT266 chipset. The system boots and displays some ACPI info 
that looks fine.
However, the proprietary NVidia video driver (I have a Geforce 2 MX card and 
the newest 1.0.3123 proprietary driver) fails to start the X system. I 
strongly suspect (although I don't have enough debug info yet) that the acpi 
patch is the one that makes NVidia fail. The 2.4.19 worked until the acpi 
patch was applied to it.

The situation arising is quite strange. I want the current ACPI to be 
included in the next mainline kernel. However, all NVidia users will be 
disappointed if the stable 2.4.20 comes out before NVidia releases a suitable 
driver.

I suggest: merge the ACPI and tell NVidia to start testing. Put a warning 
label at both sides make sure a correct NVidia driver is out before 2.4.20 
reaches final release (there is plenty of time).


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

Re: Testing: NVidia closed driver fails.

[Ducrot Bruno]

On Thu, Sep 19, 2002 at 03:38:16PM +0300, P. Christeas wrote:
> > I wanted to make a special request for testing of the 2.4 patch (or should
> > I say, MEGA-patch).
> >
> >
> > - DOES IT BOOT?
> > - DOES IT ASSIGN INTERRUPTS PROPERLY?
> >
> 
> I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon XP 
> 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some ACPI info 
> that looks fine.
> However, the proprietary NVidia video driver (I have a Geforce 2 MX card and 
> the newest 1.0.3123 proprietary driver) fails to start the X system. I 
> strongly suspect (although I don't have enough debug info yet) that the acpi 
> patch is the one that makes NVidia fail. The 2.4.19 worked until the acpi 
> patch was applied to it.

I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device with and
without acpi?

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


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

Re: Testing: NVidia closed driver fails.

[Jochen Reinwand]

Just an idea:

I read somewhere that NVidia kernel drivers make problems with apm.
In the syslog appears the following when starting X:

kernel: apm: set display: Power management disabled

It's a few seconds after the modules are inserted, so perhaps SuSE does it 
somewhere in the startup scripts... Have not found it yet...


I have a KT133 (Asus A7V) and also a Geforce 2 MX.
With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20 seconds 
to start and then consumes as much CPU time as possible. It's an adventure to 
try to hit something with the mouse pointer.
Everything is funktioning perfectly without ACPI.
Perhaps an interrupt problem. ACPI shares an interrupt with a bttv card. The 
GeForce has it's own interrupt.

Jochen

Am Donnerstag, 19. September 2002 17:06 schrieb Ducrot Bruno:
> On Thu, Sep 19, 2002 at 03:38:16PM +0300, P. Christeas wrote:
> > > I wanted to make a special request for testing of the 2.4 patch (or
> > > should I say, MEGA-patch).
> > >
> > >
> > > - DOES IT BOOT?
> > > - DOES IT ASSIGN INTERRUPTS PROPERLY?
> >
> > I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon XP
> > 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some ACPI
> > info that looks fine.
> > However, the proprietary NVidia video driver (I have a Geforce 2 MX card
> > and the newest 1.0.3123 proprietary driver) fails to start the X system.
> > I strongly suspect (although I don't have enough debug info yet) that the
> > acpi patch is the one that makes NVidia fail. The 2.4.19 worked until the
> > acpi patch was applied to it.
>
> I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device
> with and without acpi?



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

Re: Testing: NVidia closed driver fails.

[P. Christeas]

>
> I read somewhere that NVidia kernel drivers make problems with apm.
> In the syslog appears the following when starting X:
>
> kernel: apm: set display: Power management disabled
That happens at both my Linux boxes (using ACPI). Consider it normal.

>
> It's a few seconds after the modules are inserted, so perhaps SuSE does it
> somewhere in the startup scripts... Have not found it yet...
>
>
> I have a KT133 (Asus A7V) and also a Geforce 2 MX.
Mine must be a Chaintech.

> With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> seconds to start and then consumes as much CPU time as possible. It's an
> adventure to try to hit something with the mouse pointer.
> Everything is funktioning perfectly without ACPI.
> Perhaps an interrupt problem. ACPI shares an interrupt with a bttv card.
> The GeForce has it's own interrupt.
Huh! You just mentioned a magic word: bttv. I do have a bt878 card, I have to 
look if that is the problem after all.

To A. Grover: if the trouble lies in the bttv driver, the kernel will be 
considered broken until both drivers co-exist..

>
> Jochen
>

> > > I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon
> > > XP 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some
> > > ACPI info that looks fine.
> > > However, the proprietary NVidia video driver (I have a Geforce 2 MX
> > > card and the newest 1.0.3123 proprietary driver) fails to start the X
> > > system. I strongly suspect (although I don't have enough debug info
> > > yet) that the acpi patch is the one that makes NVidia fail. The 2.4.19
> > > worked until the acpi patch was applied to it.
> >
> > Ducrot Bruno:
> > I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device
> > with and without acpi?
Please hold a bit as the system in question is my 'stable' one and I don't 
want to debug it too often. I will certainly do that, but it may take a 
couple of days.



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

Re: Testing: NVidia closed driver fails.

[Patrick Mochel]

> To A. Grover: if the trouble lies in the bttv driver, the kernel will be 
> considered broken until both drivers co-exist..

Actually, if it's a problem with an nVidia video card, or something that 
is using the proprietary nVidia driver, the driver is considered broken 
and it is nVidia's problem. 

Because their driver is closed-source, kernel developers should not spend 
the time to reverse engineer the driver or attempt to figure out what 
they're trying to do. There are better things to worry about. 

Now, if you see this happening with an open-source driver, then we can 
help..

	-pat



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

Re: Testing: NVidia closed driver fails.

[Jochen Reinwand]

It really looks like it is NVidia's fault. But I don't think that it is not of 
any interest for Linux, that there are problems with NVidia boards!
The GeForce cards are at the moment the most used graphic boards. Everyone who 
wants to have fast 3D support for Linux seems to prefer NVidia boards. A few 
minutes ago a played a deathmatch with Unreal Tournament 2003 Demo and was 
very happy that everything worked fine within Linux. I really don't want to 
miss it ;-)
Perhaps NVidia just has to disable something within acpi like they do with 
apm... or make there driver open source.......

Jochen

Patrick Mochel wrote:
> > To A. Grover: if the trouble lies in the bttv driver, the kernel will be
> > considered broken until both drivers co-exist..
>
> Actually, if it's a problem with an nVidia video card, or something that
> is using the proprietary nVidia driver, the driver is considered broken
> and it is nVidia's problem.
>
> Because their driver is closed-source, kernel developers should not spend
> the time to reverse engineer the driver or attempt to figure out what
> they're trying to do. There are better things to worry about.
>
> Now, if you see this happening with an open-source driver, then we can
> help..
>
> 	-pat



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

Re: Testing: NVidia closed driver fails.

[P. Christeas]

> > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > seconds to start and then consumes as much CPU time as possible. It's an
> > adventure to try to hit something with the mouse pointer.
> > Everything is funktioning perfectly without ACPI.
> > Perhaps an interrupt problem. ACPI shares an interrupt with a bttv card.
> > The GeForce has it's own interrupt.
>
> Huh! You just mentioned a magic word: bttv. I do have a bt878 card, I have
> to look if that is the problem after all.
>
> To A. Grover: if the trouble lies in the bttv driver, the kernel will be
> considered broken until both drivers co-exist..
>
> > Jochen
> >
> > > > I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon
> > > > XP 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some
> > > > ACPI info that looks fine.
> > > > However, the proprietary NVidia video driver (I have a Geforce 2 MX
> > > > card and the newest 1.0.3123 proprietary driver) fails to start the X
> > > > system. I strongly suspect (although I don't have enough debug info
> > > > yet) that the acpi patch is the one that makes NVidia fail. The
> > > > 2.4.19 worked until the acpi patch was applied to it.
> > >
> > > Ducrot Bruno:
> > > I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device
> > > with and without acpi?
>
> Please hold a bit as the system in question is my 'stable' one and I don't
> want to debug it too often. I will certainly do that, but it may take a
> couple of days.
>
>

I managed to do some initial tests to that machine. The raw conclusion is 
that the machine runs (including NVidia-X) when the pci=noacpi is set.

The fact that there is a way (pci=noacpi) to let the NVidia users upgrade to 
2.4.20+acpi means that there is no reason not to merge the ACPI patch anymore.

There is definitely some trouble when ACPI sets the irq's for PCI. As seen in 
the attached files, ACPI maps the nvidia to irq 11 (instead of 10 as in 
noacpi), where other cards are mapped to, also.
The bttv card does work,  even with ACPI. Thus, the problem lies in the 
NVidia driver. It's their call now to fix that. We shall notify them.

One more point is that the 'stable' configuration cannot sleep. Is that 
normal, since the "pci=notacpi" is set? When I
'echo [1|4] > /proc/acpi/sleep'
the speaker beeps, nothing gets logged and nothing happens.


Here's the tests:
I booted 2.4.20-pre7 + acpi 20020918, runlevel 3 (with ACPI irq)
-->"irq-noX.log", "pci-noX.log"
I ran a tv prog (to a remote display, still no X server on the system). The 
bttv was used and I could watch to tv.
-->"irq-noX.2.log"

I re-booted the same (with ACPI irq), runlevel 5. 
The kernel was alive, X was frozen. This is when the system is in trouble:
--> "irq.log",  "pci.log"

I re-booted w/o acpi (pci=noacpi), runlevel 5
System was up, with X running OK
--> "irq-noacpi.log", "pci-noacpi.log"
I started the bttv, watched tv
--> "irq-noacpi.2.log"

Please ask any more question you want.


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

Re: Testing: NVidia closed driver fails.

[Pavel Machek]

Hi!
> One more point is that the 'stable' configuration cannot sleep. Is that 
> normal, since the "pci=notacpi" is set? When I
> 'echo [1|4] > /proc/acpi/sleep'
> the speaker beeps, nothing gets logged and nothing happens.

can we remove /proc/acpi/sleep so users don't waste time trying to make 
s3/s4 work in 2.4.x?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



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

Re: Testing: NVidia closed driver fails.

[Charl P. Botha]

On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
> can we remove /proc/acpi/sleep so users don't waste time trying to make 
> s3/s4 work in 2.4.x?

If swsusp is setup, echoing 4 to /proc/acpi/sleep does of course work on
2.4.  In addition, 5 can be used to switch off and 1 can be used on some
machines as well, all with 2.4.x.  How about a syslogged message rather if
someone tries something with /proc/acpi/sleep that's not supported?

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


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

Re: Testing: NVidia closed driver fails.

[Pavel Machek]

Hi!

> On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
> > can we remove /proc/acpi/sleep so users don't waste time trying to make 
> > s3/s4 work in 2.4.x?
> 
> If swsusp is setup, echoing 4 to /proc/acpi/sleep does of course work on
> 2.4.  In addition, 5 can be used to switch off and 1 can be used on some
> machines as well, all with 2.4.x.  How about a syslogged message rather if
> someone tries something with /proc/acpi/sleep that's not supported?

Do you think you could produce patch to do just that? printk() on S4 if
not config_software_suspend and printk() on S3 under 2.4.X is the best way
to go. Unfortunately I do not have 2.4.X tree easily available...
								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



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

Re: Testing: NVidia closed driver fails.

[Charl P. Botha]

On Sun, Sep 22, 2002 at 04:31:48AM +0000, Pavel Machek wrote:
> > On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
> > > can we remove /proc/acpi/sleep so users don't waste time trying to make 
> > > s3/s4 work in 2.4.x?
> > 
> > If swsusp is setup, echoing 4 to /proc/acpi/sleep does of course work on
> > 2.4.  In addition, 5 can be used to switch off and 1 can be used on some
> > machines as well, all with 2.4.x.  How about a syslogged message rather if
> > someone tries something with /proc/acpi/sleep that's not supported?
> 
> Do you think you could produce patch to do just that? printk() on S4 if
> not config_software_suspend and printk() on S3 under 2.4.X is the best way
> to go. Unfortunately I do not have 2.4.X tree easily available...

I would like to, but I'm still running acpi 20020726, mostly due to swsusp
and such-like.  Seeing that hard working hackers have graced us with 2.4.18
+ 20020918 + swsusp 12, I am considering upgrading... as soon as I've done
this I could make a patch.  This might take a while, with RealLife(tm)
taking inordinate amounts of time at the moment.

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


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

Re: Testing: NVidia closed driver fails.

[Shay Elkin]

On Tue, 24 Sep 2002 23:33:34 +0200, Charl P. Botha wrote:

> On Sun, Sep 22, 2002 at 04:31:48AM +0000, Pavel Machek wrote:
>> > On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
>> > > can we remove /proc/acpi/sleep so users don't waste time trying to
>> > > make s3/s4 work in 2.4.x?
>> Do you think you could produce patch to do just that? printk() on S4 if
>> not config_software_suspend and printk() on S3 under 2.4.X is the best
>> way to go. Unfortunately I do not have 2.4.X tree easily available...
> I would like to, but I'm still running acpi 20020726, mostly due to swsusp
> and such-like.  Seeing that hard working hackers have graced us with
> 2.4.18 + 20020918 + swsusp 12, I am considering upgrading... as soon as
> I've done this I could make a patch.  This might take a while, with
> RealLife(tm) taking inordinate amounts of time at the moment.

Is something along the attached patch is okay, or should it be done in
acpi_suspend() instead? (I don't think acpi_suspend is called from anywhere
else but acpi_system_write_sleep()).

	Shay.




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

Re: Testing: NVidia closed driver fails.

[Shay Elkin]

On Wed, 25 Sep 2002 18:26:32 +0300, Shay Elkin wrote:

> Is something along the attached patch is okay, or should it be done in
> acpi_suspend() instead? (I don't think acpi_suspend is called from
> anywhere else but acpi_system_write_sleep()).

I forogot to include the patch. Here:

=== cut here ===

--- drivers/acpi/system.c.orig  2002-09-25 18:14:11.000000000 +0300
+++ drivers/acpi/system.c       2002-09-25 18:09:34.000000000 +0300
@@ -510,10 +511,22 @@
        if (!system->states[state])
                return_VALUE(-ENODEV);
 
-       status = acpi_suspend(state);
-       if (ACPI_FAILURE(status))
-               return_VALUE(-ENODEV);
-
+       switch (state) {
+       case ACPI_STATE_S4:
+#ifdef CONFIG_SOFTWARE_SUSPEND
+               software_suspend_pending();
+               break;
+#endif 
+       case ACPI_STATE_S3:
+               printk("unsupported sleep mode %d", state);
+               break;
+       default:
+               status = acpi_suspend(state);
+               if (ACPI_FAILURE(status))
+                       return_VALUE(-ENODEV);
+               break;
+       }
+
        return_VALUE(count);
 }
 
=== cut here ===

	Shay.




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

Re: Testing: NVidia closed driver fails.

[Maciek Gorniak]

On nie, 2002-09-22 at 02:53, Pavel Machek wrote:
> Hi!
> > One more point is that the 'stable' configuration cannot sleep. Is that 
> > normal, since the "pci=notacpi" is set? When I
> > 'echo [1|4] > /proc/acpi/sleep'
> > the speaker beeps, nothing gets logged and nothing happens.
> 
> can we remove /proc/acpi/sleep so users don't waste time trying to make 
> s3/s4 work in 2.4.x?

S1 works fine and uses /proc/acpi/sleep. Removing it would be a step
backward...

-- 
Maciek




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

Re: CALL FOR TESTING

[Cyril Bitterich]

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

Hi,

Having a sony Vaio PCG-SRX41P i can say 

> - DOES IT BOOT?

It does.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

It DOES

/proc# cat interrupts
           CPU0
  0:      51258          XT-PIC  timer
  1:        313          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          3          XT-PIC  rtc
  9:        448          XT-PIC  acpi, Ricoh Co Ltd RL5c475, Texas Instruments PCI1410 PC card Cardbus Controller, eth0, orinoco_cs
 11:         10          XT-PIC  sonypi
 12:         92          XT-PIC  PS/2 Mouse
 14:      44636          XT-PIC  ide0
NMI:          0
ERR:          0

For Identification:

ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 65152
zone(0): 4096 pages.
zone(1): 61056 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 SONY                       ) @ 0x000f6c70
ACPI: RSDT (v001 SONY   U2       08193.04119) @ 0x0fcf7f4a
ACPI: FADT (v002   SONY       U2 08193.04119) @ 0x0fcfbf54
ACPI: BOOT (v001   SONY       U2 08193.04119) @ 0x0fcfbfd8
ACPI: DSDT (v001   SONY       U2 08193.04119) @ 0x00000000
ACPI: BIOS passes blacklist
Sony Vaio laptop detected.

> Issues like whether the battery reports stats properly are of secondary
> importance.

Battery/AC OK.
Power Lid works.
sonypi still works
S3 seems not to work, but not much testing yet.

Cyril

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: CALL FOR TESTING

[Pavel Machek]

Hi!

> > Issues like whether the battery reports stats properly are of secondary
> > importance.
> 
> Battery/AC OK.
> Power Lid works.
> sonypi still works
> S3 seems not to work, but not much testing yet.

S3 will never ever work in 2.4.X. Andrew can you put a big printk somewhere?

								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



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

Re: CALL FOR TESTING

[Al]

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

Cosi' scrisse "Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:

> - DOES IT BOOT?
> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Me again. Tested on laptop now (Asus B1520D) and it works (boot and IRQ).
One thing from dmsg:

pci_bind-0194 [08] acpi_pci_bind : Device 00:00:13.00 not present in PCI
   namespace

Attached: lspci -v, dmesg (relevant part).


Regards,


        Luca Amigoni


-- 

If you wrap the Internet around every person on the planet and spin the
planet, software flows in the network. [...] The resistance of the net-
work is directly proportional to the field strength of the intellectual
property system. (Eben Moglen)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: CALL FOR TESTING

[Al]

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

Forgot attachments, sorry...


        Luca Amigoni


-- 

If you wrap the Internet around every person on the planet and spin the
planet, software flows in the network. [...] The resistance of the net-
work is directly proportional to the field strength of the intellectual
property system. (Eben Moglen)

[-- Attachment #2: lspci --]
[-- Type: application/octet-stream, Size: 3923 bytes --]

00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
	Flags: bus master, medium devsel, latency 0
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Capabilities: [a0] AGP version 2.0
	Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT8605 [PM133 AGP] (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: d7000000-d7dfffff
	Prefetchable memory behind bridge: d7f00000-dfffffff
	Capabilities: [80] Power Management version 2

00:0f.0 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 02)
	Subsystem: Asustek Computer, Inc.: Unknown device 1474
	Flags: bus master, stepping, slow devsel, latency 32, IRQ 11
	Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=0
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0001

00:0f.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 02)
	Subsystem: Asustek Computer, Inc.: Unknown device 1474
	Flags: bus master, stepping, slow devsel, latency 32, IRQ 11
	Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=06, subordinate=09, sec-latency=0
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0001

00:10.0 Modem: PCTel Inc HSP MicroModem 56 (rev 02) (prog-if 04 [Hayes/16750])
	Subsystem: PCTel Inc: Unknown device 0001
	Flags: stepping, medium devsel, IRQ 6
	I/O ports at d800 [size=64]
	Capabilities: [40] Power Management version 2

00:11.0 ISA bridge: VIA Technologies, Inc. VT8231 [PCI-to-ISA Bridge] (rev 10)
	Flags: bus master, stepping, medium devsel, latency 0
	Capabilities: [c0] Power Management version 2

00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Flags: bus master, stepping, medium devsel, latency 32
	I/O ports at d400 [size=16]
	Capabilities: [c0] Power Management version 2

00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1e) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at d000 [size=32]
	Capabilities: [80] Power Management version 2

00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1e) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at b800 [size=32]
	Capabilities: [80] Power Management version 2

00:11.4 Bridge: VIA Technologies, Inc. VT8235 Power Management (rev 10)
	Subsystem: Asustek Computer, Inc.: Unknown device 1479
	Flags: medium devsel
	Capabilities: [68] Power Management version 2

00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 40)
	Subsystem: Asustek Computer, Inc.: Unknown device 1473
	Flags: medium devsel, IRQ 9
	I/O ports at b400 [size=256]
	I/O ports at b000 [size=4]
	I/O ports at a800 [size=4]
	Capabilities: [c0] Power Management version 2

00:12.0 Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 31)
	Subsystem: Unknown device 0291:8212
	Flags: bus master, medium devsel, latency 32, IRQ 9
	I/O ports at a000 [size=256]
	Memory at d6800000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at d7ec0000 [disabled] [size=256K]
	Capabilities: [50] Power Management version 2

01:00.0 VGA compatible controller: S3 Inc.: Unknown device 8d01 (rev 02) (prog-if 00 [VGA])
	Subsystem: Asustek Computer, Inc.: Unknown device 1432
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at d7000000 (32-bit, non-prefetchable) [size=512K]
	Memory at d8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at d7ff0000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
	Capabilities: [80] AGP version 2.0


[-- Attachment #3: dmesg --]
[-- Type: application/octet-stream, Size: 5846 bytes --]

Linux version 2.4.20-pre7-acpi (root@nostromo) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 gio set 19 15:38:16 CEST 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000f7f9000 (usable)
 BIOS-e820: 000000000f7f9000 - 000000000f7ff000 (ACPI data)
 BIOS-e820: 000000000f7ff000 - 000000000f800000 (ACPI NVS)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
247MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 63481
zone(0): 4096 pages.
zone(1): 59385 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 ASUS                       ) @ 0x000f5b80
ACPI: RSDT (v001 ASUS   B1A      12336.12592) @ 0x0f7f9000
ACPI: FADT (v001 ASUS   B1A      12336.12592) @ 0x0f7f9080
ACPI: BOOT (v001 ASUS   B1A      12336.12592) @ 0x0f7f9040
ACPI: DSDT (v001   ASUS      B1A 08193.00257) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: MADT not present
Kernel command line: BOOT_IMAGE=acpi ro root=305
Local APIC disabled by BIOS -- reenabling.
Could not enable APIC!
Initializing CPU#0
Detected 896.468 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 1789.13 BogoMIPS
Memory: 248404k/253924k available (1427k kernel code, 5132k reserved, 436k data, 268k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU:             Common caps: 0383f9ff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20020918
PCI: PCI BIOS revision 2.10 entry at 0xf0c70, last bus=1
PCI: Using configuration type 1
 tbxface-0099 [03] Acpi_load_tables      : ACPI Tables successfully loaded
Parsing Methods:.......................................................................................................................................................................................................................................
Table [DSDT] - 585 Objects with 51 Devices 231 Methods 16 Regions
ACPI Namespace successfully loaded at root c0329e5c
evxfevnt-0074 [04] Acpi_enable           : Transition to ACPI mode successful
Executing all Device _STA and_INI methods:........[ACPI Debug] String: ------------------------- BATTERY on line
.[ACPI Debug] String: ------------------------- BATTERY off line
.[ACPI Debug] String: --------------------------------------- AC_STA
.........................................
51 Devices found containing: 51 _STA, 5 _INI methods
Completing Region/Field/Buffer/Package initialization:.................................................................
Initialized 9/16 Regions 0/0 Fields 19/19 Buffers 37/37 Packages (585 nodes)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S3 S4 S5)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 9 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *6 7 9 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 *9 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 *11 14 15)
[ACPI Debug] String: ------------------------- BATTERY on line
[ACPI Debug] String: ------------------------- BATTERY on line
[ACPI Debug] String: ------------------------- BATTERY off line
[ACPI Debug] String: ------------------------- BATTERY off line
[ACPI Debug] String: --------------------------------------- AC_STA
[ACPI Debug] String: --------------------------------------- AC_STA
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
pci_bind-0194 [08] acpi_pci_bind         : Device 00:00:13.00 not present in PCI namespace
ACPI: Power Resource [PFAN] (off)
PCI: Probing PCI hardware
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
PCI: BIOS reporting unknown device 00:78
PCI: Device 00:79 not found by BIOS
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
udf: registering filesystem
[ACPI Debug] String: ---------------------------- AC _CHAC
[ACPI Debug] String: ---------------------------- AC _FLPA
[ACPI Debug] String: ---------------------------- AC on line
ACPI: AC Adapter [AC] (on-line)
[ACPI Debug] String: ------------------------- BATTERY on line
[ACPI Debug] String: ------------------------- BATTERY DBIF -----
[ACPI Debug] String: ------------------------- BATTERY _BIF from EC
ACPI: Battery Slot [BAT] (battery present)
[ACPI Debug] String: ------------------------- BATTERY off line
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (CM) [PWBN]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: Processor [CPU] (supports C1 C2, 16 throttling states)
ACPI: Thermal Zone [THRM] (67 C)

Re: CALL FOR TESTING - tosk3k-601

[Carlos Morgado]

On 2002.09.19 07:27:01 +0100 "Grover, Andrew" wrote:

on a toshiba satelite 3000-601

> The main issues of importance are:
> 
> - DOES IT BOOT?
yes

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

seems like it

still get device busy from events and S1-4 don't return properly

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds


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

Re: CALL FOR TESTING

[Francesco Mosca]

Il gio, 2002-09-19 alle 08:27, Grover, Andrew ha scritto:
<snip>
> 
> - DOES IT BOOT?

no, i've an asus notebook (am1354d), this is what i can see on screen
when it hangs: 
<snip>

PCI: Using configuration type 1
 tbxface-0099 [03] Acpi_load_tables     :ACPI Tables successfully loaded
Parsing Methods: .......................................................
........................................................................
........................................................................
..................
Table [DSDT] - 563 Objects with 46 Devices 237 Methods 13 Regions
ACPI Namespace successfully loaded at root c03ad9dc
 evxfevent-0074 [04] Acpi_enable         :Transition to ACPI mode
successfull
Executing all Device _STA and_INI methods:...<3>schedule_task():keventd
has not started
..........

<hangs here>


this similar to what i was experiencing with previous patches
> - DOES IT ASSIGN INTERRUPTS PROPERLY?

wonder how they will look like.. :)

> 
<snip>


i hope this helps,

Francesco



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

Re: CALL FOR TESTING

[Ernst Herzberg]

Moin.

On Donnerstag, 19. September 2002 08:27, Grover, Andrew wrote:
> I wanted to make a special request for testing of the 2.4 patch (or should
> I say, MEGA-patch).

Gericom Supersonic M6-T Intel 1.2GHz

> - DOES IT BOOT?

Linux version 2.4.20-pre7 (root@lidl) (gcc version 2.95.3 20010315 (SuSE)) #4 Thu Sep 19 19:02:33 CEST 2002
Yes.

ACPI: RSDP (v000 PTLTD                      ) @ 0x000f6d40
ACPI: RSDT (v001 PTLTD    RSDT   01540.00000) @ 0x1fefb426
ACPI: FADT (v001 SMDVIA VT5228C  01540.00000) @ 0x1fefef8c
ACPI: DSDT (v001  VIA   PTL_ACPI 01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: MADT not present

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes. Sound is not loaded yet, i will try that later.

ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
ACPI: PCI Interrupt Link [LNKB] (IRQs *10)
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5, disabled)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PPB_._PRT]
pci_bind-0194 [07] acpi_pci_bind         : Device 00:00:06.01 not present in PCI namespace (??)

( lidl:~ # lspci | grep "00:06"
00:06.0 Communication controller: Lucent Microelectronics LT WinModem )

lidl:~ # cat /proc/interrupts
           CPU0
  0:     210767          XT-PIC  timer
  1:       1245          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:       2125          XT-PIC  usb-uhci
  8:          2          XT-PIC  rtc
  9:          1          XT-PIC  acpi
 10:       2359          XT-PIC  eth0, O2 Micro, Inc. OZ6933 Cardbus Controller, O2 Micro, Inc. OZ6933 Cardbus Controller (#2)
 14:      12914          XT-PIC  ide0
 15:        191          XT-PIC  ide1
NMI:          0
LOC:     210735
ERR:          0
MIS:          0


>
> Issues like whether the battery reports stats properly are of secondary
> importance.

Working:

lidl:~ # cat /proc/acpi/battery/BAT0/*
alarm:                   unsupported
present:                 yes
design capacity:         54720 mWh
last full capacity:      47600 mWh
battery technology:      rechargeable
design voltage:          14400 mV
design capacity warning: 3808 mWh
design capacity low:     1428 mWh
capacity granularity 1:  238 mWh
capacity granularity 2:  238 mWh
model number:            PC-VP-WP22/OP-570-74001
serial number:
battery type:            Lion
OEM info:                NEC
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            30189 mW
remaining capacity:      33320 mWh
present voltage:         14860 mV


Reagards

<Earny>





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

Re: CALL FOR TESTING

[Jurgen Kramer]

Hi,

Is there a patch against 2.4.19 available? I currently running some
version of this kernel with lots of patches (0(I) scheduler, preempt,
cpufreq etc.). The last ACPI diff against 2.4.19 worked flawlessly and I
do not want to lose those features.

Thanks,

Jurgen 

On Thu, 2002-09-19 at 08:27, Grover, Andrew wrote:
    I wanted to make a special request for testing of the 2.4 patch (or should I
    say, MEGA-patch).
    
    Marcelo has asked for widespread testing of it, in anticipation of likely
    2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
    soon, but am posting this here first to hopefully weed out any really bad
    bugs that may have crept in.
    
    The main issues of importance are:
    
    - DOES IT BOOT?
    - DOES IT ASSIGN INTERRUPTS PROPERLY?
    
    Failure to do so either indicates a bug that we need to fix (fast) or a
    system that should go on the blacklist. dmesg now includes the DSDT
    signature to aid blacklisting.
    
    Issues like whether the battery reports stats properly are of secondary
    importance.
    
    Thanks in advance.
    
    Regards -- Andy
    
    -----------------------------
    Andrew Grover
    Intel Labs / Mobile Architecture
    andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
    
    
    
    -------------------------------------------------------
    This sf.net email is sponsored by:ThinkGeek
    Welcome to geek heaven.
    http://thinkgeek.com/sf
    _______________________________________________
    Acpi-devel mailing list
    Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel
    
    



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

Re: CALL FOR TESTING

[Ville Syrjälä]

Abit KT7-RAID motherboard.

> - DOES IT BOOT?

Yes.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Sort of. I have "PNP OS" disabled so my BIOS already assigns the IRQs. 

ACPI: PCI Interrupt Link [LNKA] (IRQs 1 *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15, enabled
at IRQ 9)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)

The code respects the BIOS choice for LNKC even though 9 isn't in the
_PRS. A bug in the _PRS really.


  0:     117624          XT-PIC  timer
  1:      10225          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:       7471          XT-PIC  MGA Vertical Sync, eth0
  7:          8          XT-PIC  parport0
  8:          1          XT-PIC  rtc
  9:       9769          XT-PIC  ide2, ide3
 10:         35          XT-PIC  acpi, sym53c8xx
 12:       3645          XT-PIC  PS/2 Mouse
 14:         14          XT-PIC  ide0
 15:          9          XT-PIC  ide1

The BIOS assings my G400 to IRQ 3 but the code sticks it in 5 for some
reason. The AGP slot should share the IRQ with the first PCI slot. I
don't have a card in there so I don't know how things would look then.

lspci -vt:
-[00]-+-00.0  VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
      +-01.0-[01]----00.0  Matrox Graphics, Inc. MGA G400 AGP
      +-07.0  VIA Technologies, Inc. VT82C686 [Apollo Super South]
      +-07.1  VIA Technologies, Inc. Bus Master IDE
      +-07.4  VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
      +-0b.0  Symbios Logic Inc. (formerly NCR) 53c875
      +-0d.0  3Com Corporation 3c905C-TX [Fast Etherlink]
      +-0f.0  Brooktree Corporation Bt849A Video capture
      \-13.0  Triones Technologies, Inc. HPT366

So the G400 should use the IRQ assignement for 00:01.0 which doesn't have
an IRQ but is mentioned in the _PRT:

 Package(0x04){
   0x0001FFFF,
   0x00,
   \_SB.PCI0.LNKA,
   0x00
 },

So it should use LNKA's IRQ assignment but it doesn't.

Other IRQ stuff seems fine.



Other stuff:
ACPI: Power Button (FF) [PWRF]
- Works.
ACPI: Sleep Button (CM) [SLPB]
- I don't have a button in my case for this so I don't know if it works.
ACPI: Processor [CPU0] (supports C1 C2, 2 throttling states)
- Everything seems to work.

I also get messages like:
pci_bind-0191 [05] acpi_pci_bind         : Device 00:00:07.02 not present
in PCI namespace

Those are for modem, audio and USB. Maybe these messages shouldn't be
printed since it's not a real problem?



And my computer still reboots with ISA GUS PnP + SCSI CD-ROM + ACPI. I
tried changing ACPI_OS_NAME to "Microsoft Windows" or "Microsoft Windows
NT" since the DSDT does something different in \_SB.PCI0._INI with those
values but neither helped. So it looks like ACPI will still remain off
limits for me :(

-- 
Ville Syrjälä
syrjala-ORSVBvAovxo@public.gmane.org
http://www.sci.fi/~syrjala/


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

Re: CALL FOR TESTING

[Andy Dustman]

On Thu, 2002-09-19 at 02:27, Grover, Andrew wrote:

> - DOES IT BOOT?

Yes.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes.

However, neither the battery nor AC adapter nor thermal zones work, but
these are known problems with the DSDT (Compaq Presario 2700T). On the
plus side, the problems I have previously had with switching from X to a
VT and back to X are now gone: The system no longer locks up (keyboard
at least) when switching back to X. (I'm also using a recent DRI radeon
build, so that may also be a factor, though with my old 2.4.18+acpi and
the same build, it didn't work.)

+1

-- 
Andy Dustman         PGP: 0x930B8AB6
    @       .net     http://dustman.net/andy
"Cogito, ergo sum." -- Rene Descartes
"I yam what I yam and that's all what I yam." -- Popeye


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

Re: CALL FOR TESTING

[Frédéric Bothamy]

On Wed, Sep 18, 2002 at 11:27:01PM -0700, Grover, Andrew wrote:
> I wanted to make a special request for testing of the 2.4 patch (or should I
> say, MEGA-patch).
> 
> Marcelo has asked for widespread testing of it, in anticipation of likely
> 2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
> soon, but am posting this here first to hopefully weed out any really bad
> bugs that may have crept in.

Hardware : Compaq Presario 711EA laptop
 
> The main issues of importance are:
> 
> - DOES IT BOOT?

Yes

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes, although the kernel complains about a :

PCI: No IRQ known for interrupt pin A of device 01:00.0 - using IRQ 5

the device 01:00.0 being the video card and this IRQ 5 seems to be
used by the onboard audio as well. But everything is working well
(audio and video).

I can provide the dmesg log and/or the raw dsdt if you ever need it.


Thanks for your work.

Fred


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

Re: CALL FOR TESTING

[Arnaud Fevrier]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 234 bytes --]


Hi,

 thanks for your work.


I have a fujitsu-siemens celsius H. I tried the 20-pre7


Grover, Andrew writes:
 > 
 > - DOES IT BOOT?
Yes

 > - DOES IT ASSIGN INTERRUPTS PROPERLY?
I don't know, so I include the cat /proc/interrupt:


[-- Attachment #2: interrupts --]
[-- Type: application/octet-stream, Size: 604 bytes --]

           CPU0       
  0:       7421          XT-PIC  timer
  1:        278          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:          3          XT-PIC  3c589_cs
  5:         18          XT-PIC  Allegro, O2 Micro, Inc. OZ6933 Cardbus Controller, O2 Micro, Inc. OZ6933 Cardbus Controller (#2), O2 Micro, Inc. OZ6912 Cardbus Controller
  8:          3          XT-PIC  rtc
  9:         35          XT-PIC  acpi
 12:          5          XT-PIC  PS/2 Mouse
 14:       2546          XT-PIC  ide0
 15:          0          XT-PIC  ide1
NMI:          0 
LOC:       7380 
ERR:          0

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 374 bytes --]


 

 > 
 > Failure to do so either indicates a bug that we need to fix (fast) or a
 > system that should go on the blacklist. dmesg now includes the DSDT
 > signature to aid blacklisting.

when I remove the ac adapter, I get this error message:

   ecgpe-0131 [05] ec_gpe_handler        : Unable to send 'query command' to EC.


I include the dmesg and the /proc/acpi/dsdt


[-- Attachment #4: dmesg --]
[-- Type: application/octet-stream, Size: 11452 bytes --]

Linux version 2.4.20-pre7 (root@debian) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Fri Sep 20 15:43:09 CEST 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dd000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ff60000 (usable)
 BIOS-e820: 000000001ff60000 - 000000001ff73c00 (ACPI data)
 BIOS-e820: 000000001ff73c00 - 000000001ff80000 (ACPI NVS)
 BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 130912
zone(0): 4096 pages.
zone(1): 126816 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=Linux ro root=302
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 1129.598 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2254.43 BogoMIPS
Memory: 515020k/523648k available (1550k kernel code, 8240k reserved, 669k data, 120k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel(R) Pentium(R) III Mobile CPU      1133MHz stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1129.5782 MHz.
..... host bus clock speed is 132.8915 MHz.
cpu: 0, clocks: 1328915, slice: 664457
CPU0<T0:1328912,T1:664448,D:7,S:664457,C:1328915>
PCI: PCI BIOS revision 2.10 entry at 0xfd9a0, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Transparent bridge - Intel Corp. 82801BAM/CAM PCI Bridge
PCI: Using IRQ router PIIX [8086/248c] at 00:1f.0
PCI: Found IRQ 5 for device 00:1f.1
PCI: Sharing IRQ 5 with 00:1d.2
PCI: Sharing IRQ 5 with 02:03.0
PCI: Sharing IRQ 5 with 02:04.1
PCI: Sharing IRQ 5 with 02:05.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
 tbxface-0099 [01] Acpi_load_tables      : ACPI Tables successfully loaded
Parsing Methods:....................................................................................................................................................................................................................................................................
260 Control Methods found and parsed (820 nodes total)
ACPI Namespace successfully loaded at root c0364220
ACPI: Core Subsystem version [20011018]
evxfevnt-0081 [02] Acpi_enable           : Transition to ACPI mode successful
Executing device _INI methods:......................................[ACPI Debug] String: CMBatt - _STA.BAT1
.[ACPI Debug] String: CMBatt - _STA.BAT2
...evregion-0302 [21] Ev_address_space_dispa: Region handler: AE_ERROR [PCIConfig]
Ps_execute: method failed - \_SB_.PCI0.HUB_.CB3_._INI (dfdfab68)
  nsinit-0351 [04] Ns_init_one_device    : \   /_SB_PCI0HUB_CB3_._INI failed: AE_ERROR
.evregion-0302 [21] Ev_address_space_dispa: Region handler: AE_ERROR [PCIConfig]
Ps_execute: method failed - \_SB_.PCI0.HUB_.CB1_._INI (dfdf9208)
  nsinit-0351 [04] Ns_init_one_device    : \   /_SB_PCI0HUB_CB1_._INI failed: AE_ERROR
.evregion-0302 [21] Ev_address_space_dispa: Region handler: AE_ERROR [PCIConfig]
Ps_execute: method failed - \_SB_.PCI0.HUB_.CB2_._INI (dfdf9708)
  nsinit-0351 [04] Ns_init_one_device    : \   /_SB_PCI0HUB_CB2_._INI failed: AE_ERROR
...............
59 Devices found: 59 _STA, 3 _INI
Completing Region and Field initialization:...................
18/28 Regions, 1/1 Fields initialized (820 nodes total)
ACPI: Subsystem enabled
[ACPI Debug] String: CMBatt - _STA.BAT1
[ACPI Debug] String: CMBatt - _STA.BAT1
[ACPI Debug] String: CMBatt - _STA.BAT1
[ACPI Debug] String: CMBatt - _STA.BAT2
[ACPI Debug] String: CMBatt - _STA.BAT2
[ACPI Debug] String: CMBatt - _STA.BAT2
[ACPI Debug] String: THERM: _STA - Fan Status
[ACPI Debug] String: THERM: _STA - Fan Status
[ACPI Debug] String: THERM: _STA - Fan Status
[ACPI Debug] String: THERM: _STA - Fan Status
Power Resource: found
EC: found, GPE 28
ACPI: System firmware supports S0 S3 S4 S5
Processor[0]: C0 C1 C2 C3, 8 throttling states
[ACPI Debug] String: CMBatt - _STA.BAT1
ectransx-0199 [30] ec_read               : Unable to send 'read command' to EC.
evregion-0302 [27] Ev_address_space_dispa: Region handler: AE_TIME [Embedded_control]
ectransx-0258 [30] ec_write              : Unable to send 'write command' to EC.
evregion-0302 [27] Ev_address_space_dispa: Region handler: AE_TIME [Embedded_control]
Ps_execute: method failed - \_SB_.PCI0.LPC0.BAT1._STA (dfdfdce8)
[ACPI Debug] String: CMBatt - _STA.BAT2
[ACPI Debug] String: CMBatt - _STA.BAT2
ACPI: Battery socket found, battery absent
ACPI: AC Adapter found
ACPI: Power Button (FF) found
ACPI: Lid Switch (CM) found
[ACPI Debug] String: THERM: _TMP - Value:
[ACPI Debug] Integer: 0xD0E (3342)
[ACPI Debug] String: THERM: _TMP - Value:
[ACPI Debug] Integer: 0xD0E (3342)
[ACPI Debug] String: THERM: _SCP(Active)
[ACPI Debug] String: THERM: _CRT - Value:
[ACPI Debug] Integer: 0xEC4 (3780)
[ACPI Debug] String: THERM: _CRT - Value:
[ACPI Debug] Integer: 0xEC4 (3780)
[ACPI Debug] String: THERM: _PSV - Value:
[ACPI Debug] Integer: 0xDCA (3530)
[ACPI Debug] String: THERM: _PSV - Value:
[ACPI Debug] Integer: 0xDCA (3530)
[ACPI Debug] String: THERM: _AC0 - Value:
[ACPI Debug] Integer: 0xD66 (3430)
[ACPI Debug] String: THERM: _AC0 - Value:
[ACPI Debug] Integer: 0xD66 (3430)
[ACPI Debug] String: THERM: _TMP - Value:
[ACPI Debug] Integer: 0xD0E (3342)
[ACPI Debug] String: THERM: _TMP - Value:
[ACPI Debug] Integer: 0xD0E (3342)
ACPI: Thermal Zone found
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3M: IDE controller on PCI bus 00 dev f9
PCI: Enabling device 00:1f.1 (0005 -> 0007)
PCI: Found IRQ 5 for device 00:1f.1
PCI: Sharing IRQ 5 with 00:1d.2
PCI: Sharing IRQ 5 with 02:03.0
PCI: Sharing IRQ 5 with 02:04.1
PCI: Sharing IRQ 5 with 02:05.0
ICH3M: chipset revision 1
ICH3M: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:DMA, hdd:pio
hda: IC25N030ATDA04-0, ATA DISK drive
hdc: UJDA710, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c037c3c4, I/O limit 4095Mb (mask 0xffffffff)
[ACPI Debug] String: QUERY_09
[ACPI Debug] String: CMBatt - SMSL
ectransx-0206 [24] ec_read               : Unable to send 'read address' to EC.
evregion-0302 [21] Ev_address_space_dispa: Region handler: AE_TIME [Embedded_control]
 dswexec-0392 [12] Ds_exec_end_op        : [And]: Could not resolve operands, AE_TIME
Ps_execute: method failed - \_SB_.PCI0.LPC0.EC0_._Q09 (dfdfe9c8)
[ACPI Debug] String: QUERY_20
hda: 58605120 sectors (30006 MB) w/1806KiB Cache, CHS=3648/255/63, UDMA(100)
Partition check:
 hda: hda1 hda2 hda3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: Detected Intel i830M chipset
agpgart: AGP aperture is 256M @ 0xe0000000
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.99 on Unknown @ 0xe0000000 256MB
[drm] Initialized radeon 1.1.1 20010405 on minor 1
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
es1371: version v0.30 time 15:45:35 Sep 20 2002
maestro3: version 1.22 built at 15:45:38 Sep 20 2002
PCI: Enabling device 02:03.0 (0000 -> 0001)
PCI: Found IRQ 5 for device 02:03.0
PCI: Sharing IRQ 5 with 00:1d.2
PCI: Sharing IRQ 5 with 00:1f.1
PCI: Sharing IRQ 5 with 02:04.1
PCI: Sharing IRQ 5 with 02:05.0
maestro3: Configuring ESS Allegro found at IO 0x2000 IRQ 5
maestro3:  subvendor id: 0x0082110a
ac97_codec: AC97 Audio codec, id: 0x4583:0x8308 (ESS Allegro ES1988)
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
PCI: Found IRQ 5 for device 02:04.0
PCI: Sharing IRQ 5 with 00:1f.3
PCI: Sharing IRQ 5 with 01:00.0
PCI: Sharing IRQ 5 with 02:06.0
PCI: Enabling device 02:04.1 (0100 -> 0102)
PCI: Found IRQ 5 for device 02:04.1
PCI: Sharing IRQ 5 with 00:1d.2
PCI: Sharing IRQ 5 with 00:1f.1
PCI: Sharing IRQ 5 with 02:03.0
PCI: Sharing IRQ 5 with 02:05.0
PCI: Found IRQ 5 for device 02:05.0
PCI: Sharing IRQ 5 with 00:1d.2
PCI: Sharing IRQ 5 with 00:1f.1
PCI: Sharing IRQ 5 with 02:03.0
PCI: Sharing IRQ 5 with 02:04.1
Intel PCIC probe: not found.
Databook TCIC-2 PCMCIA probe: not found.
usb.c: registered new driver hub
Yenta IRQ list 0898, PCI irq5
Socket status: 30000006
Yenta IRQ list 0898, PCI irq5
Socket status: 30000410
Yenta IRQ list 0898, PCI irq5
Socket status: 30000411
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 120k freed
Adding Swap: 979924k swap-space (priority -1)
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:60:97:8B:15:CF
  8K FIFO split 5:3 Rx:Tx, auto xcvr
[ACPI Debug] String: CMBatt - _PSR
[ACPI Debug] String: CMBatt - _PSR
[ACPI Debug] String: QUERY_20
[ACPI Debug] String: CMBatt - PwrEvent
   ecgpe-0131 [05] ec_gpe_handler        : Unable to send 'query command' to EC.
   ecgpe-0131 [05] ec_gpe_handler        : Unable to send 'query command' to EC.
[ACPI Debug] String: QUERY_20
[ACPI Debug] String: CMBatt - _PSR
[ACPI Debug] String: CMBatt - _PSR
[ACPI Debug] String: CMBatt - _PSR
[ACPI Debug] String: CMBatt - _PSR

[-- Attachment #5: dsdt --]
[-- Type: application/octet-stream, Size: 33522 bytes --]

[-- Attachment #6: message body and .signature --]
[-- Type: text/plain, Size: 439 bytes --]




When i echo 3 > /proc/acpi/sleep the system goes to sleep, but when I
press the power button, the system fails to restart properly. The
screen switch on, the Leds show that the CPU restarts, but the system
is frozen until a fuill power off.



Hope that helps,

-- 

			    Arnaud Février
			    fevrier-94MxA55sdNz4HDTGivPSy1aPQRlvutdw@public.gmane.org
			    +33 () 491 177 926
                  
                 

Re: CALL FOR TESTING

[Thomas Winkler]

Hi,

> - DOES IT BOOT?

Yes.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes.

- no broken IRQ routing
- all entries in /proc/acpi can be read without problems and the reported 
values make pretty good sense

If you need more info just drop me a line.

Bye,
-- 
Thomas Winkler
e-mail: tom.winkler-Tswl7xcH0yE@public.gmane.org


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

Re: CALL FOR TESTING

[Sérgio Monteiro Basto]

On Thu, 2002-09-19 at 02:27, Grover, Andrew wrote:
> I wanted to make a special request for testing of the 2.4 patch (or should I
> say, MEGA-patch).
> 
> Marcelo has asked for widespread testing of it, in anticipation of likely
> 2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
> soon, but am posting this here first to hopefully weed out any really bad
> bugs that may have crept in.
> 
> The main issues of importance are:
> 
> - DOES IT BOOT?
yes
> - DOES IT ASSIGN INTERRUPTS PROPERLY?
> 
yes normally, and had correct the events, now events works without
kacpid patch.
> Failure to do so either indicates a bug that we need to fix (fast) or a
> system that should go on the blacklist. dmesg now includes the DSDT
> signature to aid blacklisting.
> 
> Issues like whether the battery reports stats properly are of secondary
> importance.
> 
> Thanks in advance.
> 
> Regards -- Andy
> 
> -----------------------------
> Andrew Grover
> Intel Labs / Mobile Architecture
> andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org




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

Re: CALL FOR TESTING

[Stephen White]

---- Original Message ----
> From Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Thursday, 19 Sep 2002, 07:27
>
> I wanted to make a special request for testing of the 2.4 patch (or should I
> say, MEGA-patch).
> 
> - DOES IT BOOT?

Yes.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Appears to.

> Issues like whether the battery reports stats properly are of secondary
> importance.

Battery status and info is fine.  Thermal management appears ok.  

-- 
Stephen White              \      Oxford University Computing Society
System Administrator        \          http://ox.compsoc.net/~swhite/
PGP Key ID: 0xC79E5B6A       \          <stephen-acpi-devel-4QvXXjU8Dv4@public.gmane.org>


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

Re: CALL FOR TESTING

[Maciek Gorniak]

On czw, 2002-09-19 at 08:27, Grover, Andrew wrote:
> I wanted to make a special request for testing of the 2.4 patch (or should I
> say, MEGA-patch).

HP Pavilion n5415
kernel 2.4.20pre7

> - DOES IT BOOT?

Yes! RSDT mapping finally works out of the box (for the first time)!

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

It seems so! USB, sound both work.
Additionally S1 state works and all /proc/acpi reports seem to be ok.
Good job!
Thanks

-- 
Maciek Gorniak




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

Re: CALL FOR TESTING

[Sebastian Zimmermann]

linux-2.4.20-pre7-acpi
Toshiba Tecra 9000

> - DOES IT BOOT?

yes

kernel: ACPI: have wakeup address 0xc0001000
kernel: On node 0 totalpages: 196320
kernel: zone(0): 4096 pages.
kernel: zone(1): 192224 pages.
kernel: zone(2): 0 pages.
kernel: ACPI: RSDP (v000 TOSHIB                     ) @ 0x000f0180
kernel: ACPI: RSDT (v001 TOSHIB 750      00151.02068) @ 0x2fee0000
kernel: ACPI: FADT (v002 TOSHIB 750      00151.02068) @ 0x2fee0054
kernel: ACPI: BOOT (v001 TOSHIB 750      00151.02068) @ 0x2fee002c
kernel: ACPI: DSDT (v001 TOSHIB 9000     08194.01552) @ 0x00000000
kernel: ACPI: BIOS passes blacklist
kernel: ACPI: MADT not present

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

          CPU0       
  0:     100838          XT-PIC  timer
  1:       2270          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          3          XT-PIC  rtc
  9:         91          XT-PIC  acpi
 11:       2974          XT-PIC  Texas Instruments PCI1410 PC card
Cardbus Controller, Toshiba America Info Systems ToPIC95 PCI to Cardbus
Bridge with ZV Support, Toshiba America Info Systems ToPIC95 PCI to
Cardbus Bridge with ZV Support (#2), Intel ICH3, usb-uhci, usb-uhci,
usb-uhci, orinoco_cs
 12:      51835          XT-PIC  PS/2 Mouse
 14:      13212          XT-PIC  ide0
 15:          4          XT-PIC  ide1
NMI:          0 
LOC:     100801 
ERR:          0
MIS:          0

> Toshiba Laptop ACPI Extras version 0.13

Work fine

Lid ok
Battery ok

does enter S1 sleep (power led turns yellow), however, it won't wakeup
(power led turns green, but system hangs).

S.


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

Re: CALL FOR TESTING

[Tundra Slosek]

Quoting Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:
> The main issues of importance are:
> 
> - DOES IT BOOT?

Yes. Sony GRX570.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

It seems to, however the built-in PS/2 touchpad (i.e. mouse) is the only one
that works.. external (USB) Logitech mouse shows up in the
/proc/bus/usb/devices but does not get to X. This is functional in 2.4.18
w/ ACPI 20020611. I do have Ted Serryn's memstick patch & the usbdnet patch
applied as well as ACPI 09/18. 



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

Re: CALL FOR TESTING

[tundras-SmH/eyArkOtWk0Htik3J/w]

Quoting Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:
> I wanted to make a special request for testing of the 2.4 patch (or should I
> say, MEGA-patch).
> 
> Marcelo has asked for widespread testing of it, in anticipation of likely
> 2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
> soon, but am posting this here first to hopefully weed out any really bad
> bugs that may have crept in.
> 
> The main issues of importance are:
> 
> - DOES IT BOOT?

Yes, the machine boots.

Machine: HP Pavilion 501n
OS: Kernel 2.4.20-pre7 w/ ACPI 20020918. No other patches.

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

No. My earlier report on this machine was with AE_STACK_UNDERFLOW. Now it
reports Error: Acpi_load_tables: Could not load namespace: AE_AML_INTERNAL

/proc/acpi doesn't exist.

> 
> Failure to do so either indicates a bug that we need to fix (fast) or a
> system that should go on the blacklist. dmesg now includes the DSDT
> signature to aid blacklisting.

Is this the DSDT sig information you need?

ACPI: RSDP (v000 PTLTD                      ) @ 0x000f6670
ACPI: RSDT (v001 PTLTD    RSDT   01540.00000) @ 0x07cf7082
ACPI: FADT (v001 INTEL  Whitney  01540.00000) @ 0x07cfbf0a
ACPI: MADT (v001 PTLTD           APIC   01540.00000) @ 0x07cfbf7e
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 01540.00000) @ 0x07cfbfd8
ACPI: DSDT (v001  INTEL  Whitney 01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist




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

Re: CALL FOR TESTING

[Mattia Dongili]

Hi,

Sony vaio GR7/k

ACPI: RSDP (v000 PTLTD                      ) @ 0x000f6cd0
ACPI: RSDT (v001 SONY   C0       08193.02057) @ 0x07efa88f
ACPI: FADT (v001   SONY       C0 08193.02057) @ 0x07efef64
ACPI: BOOT (v001   SONY       C0 08193.02057) @ 0x07efefd8
ACPI: DSDT (v001   SONY       C0 08193.02057) @ 0x00000000


> - DOES IT BOOT?

Yes

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

Yes

I still have a couple of errors during the boot process but they have been here since 20020404 (not really sure about this date).

PCI: Using configuration type 1
    ACPI-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
    ACPI-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
    ACPI-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
    ACPI-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
[...]
PCI: No IRQ known for interrupt pin A of device 00:1f.1 - using IRQ 255

from lspci:

00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)

and it seems it doesn't need an irq...

bye,
--
Mattia


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

Re: CALL FOR TESTING

[James H. Cloos Jr.]

Another success story.  I'm now booted with 2.4.20-pre8 w/ acpi on a
dell i8100 (with radeon 7500m video and A07 bios).  Interupt routing
is the same as marcello's tree (w/ apm rather than acpi).  The files
under /proc/acpi all seem good.

OTOH, the sum of design capacity in /proc/acpi/battery/*/info divided
by the mW ratings in /proc/acpi/processor/CPU0/performance is
significantly less than the duration apm claimed.

The two batteries have 57420 mWh and the pIIIm has power states:

   *P0:                  1000 MHz, 15800 mW, 500 uS
    P1:                  733 MHz, 12500 mW, 500 uS

making 7.27 or 9.19 hours on two full batteries.  Apmd claimed 11.50
hours on two full batteries.

(I'm inclined to consider apmd's promise optimistic, so the above is
probably accurate.  But the difference is IMO worth a mention.)

The exact kernel I'm running can be duplicated by:

bk clone \
  -r'marcelo-h0V4oybiq0/QsHzvN0qAKK/+n4cY9krw@public.gmane.org|ChangeSet|20020925091643|62826' \
   bk://linux.bkbits.net/linux-2.4 linux-2.4.20-pre8
bk clone \
   -r'agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org|ChangeSet|20020924011021|60855' \
   bk://linux-acpi.bkbits.net/linux-2.4-acpi
bk clone -l linux-2.4-acpi linux-2.4.20-pre8-acpi
cd linux-2.4.20-pre8-acpi
bk pull ../linux-2.4.20-pre8
bk edit Makefile
perl -pi 's/EXTRAVERSION = -pre8/EXTRAVERSION = -pre8-acpi/' Makefile
bk citool Makefile

(Ie, grab Marcello's tree up to the cset where EXTRAVERSION became
-pre8, grab the linux-2.4-acpi up to where it was when I last pulled,
make a working clone, pull from the clone of Marcello, and fixup
EXTRAVERSION to differentiate from a 2.4.20-pre8 install.)


One thing not mentioned in the call for testing is what daemon(s)
should be run on top of the driver?  I saw ospmd-20020509.tar.gz
on the sf site; is that the most current?

-JimC



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

still hangs on boot with asus am1354d

[Francesco Mosca]

mostly the same as previous reports with previous patches..
when it hangs: 
<snip>

PCI: Using configuration type 1
 tbxface-0099 [03] Acpi_load_tables     :ACPI Tables successfully acquired
Parsing Methods: .......................................................
........................................................................
........................................................................
..................
Table [DSDT] - 563 Objects with 46 Devices 237 Methods 13 Regions
ACPI Namespace successfully loaded at root c03b7b3c
 evxfevent-0074 [04] Acpi_enable         :Transition to ACPI mode
successfull
Executing all Device _STA and_INI methods:...<3>schedule_task():keventd
has not started
..........

<hangs here>


this similar to what i was experiencing with previous patches
> - DOES IT ASSIGN INTERRUPTS PROPERLY?

wonder how they will look like.. :)

> 
<snip>


i hope this helps,

Francesco



-------------------------------------------------------
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD

Re: CALL FOR TESTING

[Zdeněk OGAR Skalák]

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

Compaq Armada 110, patched DSDT (myself :-), kernel 2.4.19

> - DOES IT BOOT?

	yes !

> - DOES IT ASSIGN INTERRUPTS PROPERLY?

	Seems be Okay :-)

	Zdenek OGAR Skalak

-- 
Ing. Zdeněk OGAR Skalák
Monet+ a.s.
Zámecká 365
763 14 Zlín - Štípa, CZ
Tel: 067 / 711 04 11,  Fax: 067 / 791 45 57

[-- Attachment #2: interrupts --]
[-- Type: text/plain, Size: 518 bytes --]

           CPU0       
  0:      77185          XT-PIC  timer
  1:       1375          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  via82cxxx
 10:        137          XT-PIC  acpi
 11:        336          XT-PIC  Texas Instruments PCI1410 PC card Cardbus Controller, usb-uhci, eth0
 12:         23          XT-PIC  PS/2 Mouse
 14:      11732          XT-PIC  ide0
 15:          4          XT-PIC  ide1
NMI:          0 
ERR:          0

[-- Attachment #3: dmesg --]
[-- Type: text/plain, Size: 1339 bytes --]

Linux version 2.4.19 (root@nb-skalak) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #14 Wed Sep 25 15:22:39 CEST 2002
.....
ACPI: have wakeup address 0xc0001000
Advanced speculative caching feature not present
On node 0 totalpages: 63472
zone(0): 4096 pages.
zone(1): 59376 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 PTLTD                      ) @ 0x000f6e90
ACPI: RSDT (v001 PTLTD    RSDT   01540.00000) @ 0x0f7fbdc2
ACPI: FADT (v001 COMPAQ Borg     01540.00000) @ 0x0f7ffb64
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 01540.00000) @ 0x0f7ffbd8
ACPI: DSDT (v001 Compaq Wrangler 01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist
.....
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *9 11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 9 *11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs *9 11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 9 *11 12)
ACPI: Embedded Controller [EC0] (gpe 1)
ACPI: Power Resource [PLPC] (on)
pci_bind-0191 [06] acpi_pci_bind         : Device 00:00:07.06 not present in PCI namespace
PCI: Probing PCI hardware
 pci_irq-0293 [05] acpi_pci_irq_derive   : Unable to derive IRQ for device 01:00.0
PCI: No IRQ known for interrupt pin A of device 01:00.0 - using IRQ 9
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'

RE: Testing: NVidia closed driver fails.

[Grover, Andrew]

> From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > seconds to start and then consumes as much CPU time as 
> possible. It's an
> > adventure to try to hit something with the mouse pointer.
> > Everything is funktioning perfectly without ACPI.
> > Perhaps an interrupt problem. ACPI shares an interrupt with 
> a bttv card.
> > The GeForce has it's own interrupt.
> Huh! You just mentioned a magic word: bttv. I do have a bt878 
> card, I have to 
> look if that is the problem after all.
> 
> To A. Grover: if the trouble lies in the bttv driver, the 
> kernel will be 
> considered broken until both drivers co-exist..

When you cat /proc/interrupts, is there a huge and ever-increasing number of
interrupts listed for the shared irq?

(Wait, I thought video devices weren't interrupt driven? Or is that only
video out, not video-in, like bt878?)

My understanding was, when an interrupt is shared, the OS calls *all* the
interrupt service routines (ISRs) for devices on that interrupt - it is then
up to the ISR to determine whether its device interrupted and handle it, or
whether just to return.

You might start your investigations by looking at
drivers/acpi/events/evsci.c acpi_ev_sci_handler().

Regards -- Andy


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

Re: Testing: NVidia closed driver fails.

[Ducrot Bruno]

On Thu, Sep 19, 2002 at 03:26:52PM -0700, Grover, Andrew wrote:
> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> > > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > > seconds to start and then consumes as much CPU time as 
> > possible. It's an
> > > adventure to try to hit something with the mouse pointer.
> > > Everything is funktioning perfectly without ACPI.
> > > Perhaps an interrupt problem. ACPI shares an interrupt with 
> > a bttv card.
> > > The GeForce has it's own interrupt.
> > Huh! You just mentioned a magic word: bttv. I do have a bt878 
> > card, I have to 
> > look if that is the problem after all.
> > 
> > To A. Grover: if the trouble lies in the bttv driver, the 
> > kernel will be 
> > considered broken until both drivers co-exist..
> 
> When you cat /proc/interrupts, is there a huge and ever-increasing number of
> interrupts listed for the shared irq?
> 
> (Wait, I thought video devices weren't interrupt driven? Or is that only
> video out, not video-in, like bt878?)

Some of them are interrupt driven, like some Nvidia cards, certainly when
you configure the so-called Nvidia TwinView(TM) feature of such card.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


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

Re: Testing: NVidia closed driver fails.

[Jochen Reinwand]

Grover, Andrew wrote:
> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
> >
> > > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > > seconds to start and then consumes as much CPU time as
> >
> > possible. It's an
> >
> > > adventure to try to hit something with the mouse pointer.
> > > Everything is funktioning perfectly without ACPI.
> > > Perhaps an interrupt problem. ACPI shares an interrupt with
> >
> > a bttv card.
> >
> > > The GeForce has it's own interrupt.
> >
> > Huh! You just mentioned a magic word: bttv. I do have a bt878
> > card, I have to
> > look if that is the problem after all.
> >
> > To A. Grover: if the trouble lies in the bttv driver, the
> > kernel will be
> > considered broken until both drivers co-exist..
>
> When you cat /proc/interrupts, is there a huge and ever-increasing number
> of interrupts listed for the shared irq?

No, everything seems to be ok there with my system. For a long time the value 
for interrupt 9 (shared between acpi, usb, bttv) did not even increase.

To test it I removed the bttv card and disabled usb as far as possible (there 
are two controllers, only one could be disabled. But there are no devices 
connected to usb at all.)
Still the same problem: X gets very slow. Looks like it's making a pause every 
few seconds. Working remote via ssh on the system is possible without any 
problems.

> (Wait, I thought video devices weren't interrupt driven? Or is that only
> video out, not video-in, like bt878?)

Strange. Someone told me, that they use interrupts to talk to the graphics 
card. I didn't really believe that...
Now I tried: I just watched a little bit with the bttv and there was NO 
interrupt activity at all!

I found a note on the German Asus web site, that tv cards should have there 
own interrupt. Doesn't seem to be very important. Windows and Linux seem to 
have no problem with it.

Conclusion: The bttv driver is not responsible for the problem! The NVidia 
driver or acpi is the problem. Should someone inform NVidia about the 
problem?

Jochen


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

Re: Testing: NVidia closed driver fails.

[Arnaud Fevrier]

I have just recompiled the 20-pre7 kernel and X works fine with my
nvidia. I have the closed nvidia kernel module :-( and had to
recompile it for the new kernel. 

When I use apm to nap my system, sometimes the X-server got killed. I
did not really investigate, but I thinks it depends on the compilation
options of the kernel.

It's still bad that nvidia did not release an open source
implementation, but I can't change it.

I can provide more information, just ask me what info you want.

sincerely,

-- 

			    Arnaud Février
			    fevrier-94MxA55sdNz4HDTGivPSy1aPQRlvutdw@public.gmane.org
			    +33 () 491 177 926
                  
                 


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

Re: Testing: NVidia closed driver fails.

[Arnaud Fevrier]

Hi,

 I have a fujitsu-Siemens CelsiusH which comes with a nvidia card. The
 nvidia driver (1.0-2960) shares it interupts with the allegro sound
 card.

I compiled the kernel 20-pre7 acpi 2002 09 18, and it boots fine. 

I cannot run the make xconfig, and I had to set the SMP. It did not
compile for a uniprocessor.

A lot of acpi features work fine, but I cannot sleep or hibernate the
laptop.

Sincerly,

-- 

			    Arnaud Février
			    fevrier-94MxA55sdNz4HDTGivPSy1aPQRlvutdw@public.gmane.org
			    +33 () 491 177 926
                  
                 


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