eisa_set_level_irq(acpi_fadt.sci_int)

DISCUSSION Len Brown 4 participants 12 messages Oct 15, 2003 – Oct 27, 2003 9 messages not in the archive ACPI

Share & tools

Len Brown

author

2003-10-15 21:48 UTC #0 lore raw

What does eisa_set_level_irq() do for us?

As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)

thanks,
-Len

drivers/acpi/bus.c:

#ifdef CONFIG_X86
        /* Ensure the SCI is set to level-triggered, active-low */
        if (acpi_ioapic)
                mp_config_ioapic_for_sci(acpi_fadt.sci_int);
        else
                eisa_set_level_irq(acpi_fadt.sci_int);

#endif

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Ducrot Bruno

2003-10-17 15:41 UTC #2 lore raw

In reply to a message not in the archive

Quoted 6 lines · Len Brown

What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)

This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.

Signature · 11 lines

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com

Len Brown

author

2003-10-17 17:28 UTC #4 lore raw

In reply to a message not in the archive

Quoted 10 lines · Ducrot Bruno

Quoted 6 lines · Len Brown
What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)
This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.

Do ACPI interrupt work on this latop? What happens on that system if you delete the call to eisa_set_level_irq()?

If we blindly program the PIC to be level senstive when the hardware is designed to be edge triggered, then we'll probably get no ACPI events on those systems, as the pulse may not be asserted long enough to provoke an interrupt.

We used to blindly program the APIC assuming the SCI was ACPI compliant, but we got burnt when we discovered that a significant set of system do _not_ have a level-triggered active-low SCI. Most of those specified their deviation with an SCI-over-ride in the MADT, but some did not:
http://bugzilla.kernel.org/show_bug.cgi?id=774

The APIC solution was to
1. don't hard-code level-triggered active-low
2. do whatever the SCI over-ride says
3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS programmed it.

thanks,
-Len

ps. this routine is mis-named, it it not EISA specific. Further, it is mis-located in a PCI-specific file but is not PCI specific. It should be in an X86 specific interrupt file and be named pic_something. I'm thinking I'll clone it into our x86 acpi code and add a warning when we find that it actually _changes_ the polarity.

-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com

Len Brown

author

2003-10-22 04:25 UTC #6 lore raw

In reply to a message not in the archive

Ducrot,
I've found at least 1 system where hardcoding the PIC SCI to Level-Triggered fails, while leaving it as Edge Triggered succeeds.

The Intel SE7505VB2 "Vero Beach" when booted with "noapic" leaves IRQ9 as edge triggered.

When we force it to level triggered, we get no ACPI events. If we leave it as edge triggered, we do get ACPI events.

The other systems in my office leave the PIC SCI in Level Triggered mode, so Linux need do nothing to the trigger.

Today's patch prints a warning when the mode changes:

printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
"setting to Level Triggerd\n", irq);

But I'm thinking that by default we should _not_ change the trigger. Instead we should do so only upon, say acpi=sci_level_trigger or some such. If there is a popular model that leaves SCI as edge and requires level to work, then we can use DMI to set this param for it.

thanks,
-Len

Quoted 32 lines · Len Brown

Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · Len Brown
What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)
This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.
Do ACPI interrupt work on this latop? What happens on that system if you delete the call to eisa_set_level_irq()?
If we blindly program the PIC to be level senstive when the hardware is designed to be edge triggered, then we'll probably get no ACPI events on those systems, as the pulse may not be asserted long enough to provoke an interrupt.
We used to blindly program the APIC assuming the SCI was ACPI compliant, but we got burnt when we discovered that a significant set of system do _not_ have a level-triggered active-low SCI. Most of those specified their deviation with an SCI-over-ride in the MADT, but some did not:
http://bugzilla.kernel.org/show_bug.cgi?id=774
The APIC solution was to
1. don't hard-code level-triggered active-low
2. do whatever the SCI over-ride says
3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS programmed it.

Quoted 12 lines

thanks,
-Len
ps. this routine is mis-named, it it not EISA specific. Further, it is mis-located in a PCI-specific file but is not PCI specific. It should be in an X86 specific interrupt file and be named pic_something. I'm thinking I'll clone it into our x86 acpi code and add a warning when we find that it actually _changes_ the polarity.

-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Sérgio Monteiro Basto

2003-10-24 02:54 UTC #8 lore raw

In reply to a message not in the archive

Hi
Seems that patch has been applied into kernel-2.4.23-pre8 and hangs my laptop when lid button is pressed.
Here is dmesg file.
where you can see ACPI: IRQ 10 was Edge Triggered, setting to Level Triggerd
Notes:
With pre7 all works fine.
I have APIC disable.
Other buttons like sleep, power have the normal beaver
if I can help testing something else tell me.

thanks

Quoted 67 lines · Len Brown

Ducrot,
I've found at least 1 system where hardcoding the PIC SCI to Level-Triggered fails, while leaving it as Edge Triggered succeeds.
The Intel SE7505VB2 "Vero Beach" when booted with "noapic" leaves IRQ9 as edge triggered.
When we force it to level triggered, we get no ACPI events. If we leave it as edge triggered, we do get ACPI events.
The other systems in my office leave the PIC SCI in Level Triggered mode, so Linux need do nothing to the trigger.
Today's patch prints a warning when the mode changes:
printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
"setting to Level Triggerd\n", irq);
But I'm thinking that by default we should _not_ change the trigger. Instead we should do so only upon, say acpi=sci_level_trigger or some such. If there is a popular model that leaves SCI as edge and requires level to work, then we can use DMI to set this param for it.
thanks,
-Len
Quoted 40 lines · Len Brown
Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · Len Brown
What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)
This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.
Do ACPI interrupt work on this latop? What happens on that system if you delete the call to eisa_set_level_irq()?
If we blindly program the PIC to be level senstive when the hardware is designed to be edge triggered, then we'll probably get no ACPI events on those systems, as the pulse may not be asserted long enough to provoke an interrupt.
We used to blindly program the APIC assuming the SCI was ACPI compliant, but we got burnt when we discovered that a significant set of system do _not_ have a level-triggered active-low SCI. Most of those specified their deviation with an SCI-over-ride in the MADT, but some did not:
http://bugzilla.kernel.org/show_bug.cgi?id=774
The APIC solution was to
1. don't hard-code level-triggered active-low
2. do whatever the SCI over-ride says
3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS programmed it.
thanks,
-Len
ps. this routine is mis-named, it it not EISA specific. Further, it is mis-located in a PCI-specific file but is not PCI specific. It should be in an X86 specific interrupt file and be named pic_something. I'm thinking I'll clone it into our x86 acpi code and add a warning when we find that it actually _changes_ the polarity.

Signature · 4 lines

SérgioMB
email: [email protected]

Who gives me one shell, give me everything.

Linux version 2.4.23-pre8 (root-4/PLUo9XfK/yXfm4dIG/yWZHpeb/A1Y/@public.gmane.org) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)) #2 Fri Oct 24 02:58:53 WEST 2003 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000c0000 - 00000000000cc000 (reserved)
BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000def0000 (usable)
BIOS-e820: 000000000def0000 - 000000000deff000 (ACPI data)
BIOS-e820: 000000000deff000 - 000000000df00000 (ACPI NVS)
BIOS-e820: 000000000df00000 - 000000000e000000 (usable)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
224MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 57344
zone(0): 4096 pages.
zone(1): 53248 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 PTLTD ) @ 0x000f6dd0
ACPI: RSDT (v001 PTLTD RSDT 0x06040000 LTP 0x00000000) @ 0x0defb63b
ACPI: FADT (v001 COMPAQ EAGLES 0x06040000 PTL_ 0x000f4240) @ 0x0defeeb6
ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x0defef2a
ACPI: DSDT (v001 COMAPQ EAGLES 0x06040000 MSFT 0x0100000d) @ 0x00000000
ACPI: Vendor "COMAPQ" System " EAGLES" Revision 0x6040000 has a known ACPI BIOS problem.
ACPI: Reason: SCI issues (C2 disabled). This is a recoverable error
Kernel command line: ro root=/dev/hda5
Initializing CPU#0
Detected 996.560 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1985.74 BogoMIPS
Memory: 224164k/229376k available (1411k kernel code, 4756k reserved, 565k data, 84k 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: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.

CPU:     After generic, caps: 0383f9ff c1cbf9ff 00000000 00000000
CPU:             Common caps: 0383f9ff c1cbf9ff 00000000 00000000
CPU: AMD mobile AMD Athlon(tm) 4 Processor 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
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20031002
PCI: PCI BIOS revision 2.10 entry at 0xfd7ae, last bus=1
PCI: Using configuration type 1
tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:............................................................................................................. Table [DSDT](id F005) - 433 Objects with 44 Devices 109 Methods 15 Regions
Parsing all Control Methods:
Table [SSDT](id F003) - 3 Objects with 0 Devices 0 Methods 0 Regions
ACPI Namespace successfully loaded at root c031545c
ACPI: IRQ 10 was Edge Triggered, setting to Level Triggerd
evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful
evgpeblk-0740 [06] ev_create_gpe_block : GPE 00 to 15 [_GPE] 2 regs at 0000000000008020 on int 10
Completing Region/Field/Buffer/Package initialization:........................................................... Initialized 15/15 Regions 1/1 Fields 20/20 Buffers 23/23 Packages (444 nodes)
Executing all Device _STA and_INI methods:.....[ACPI Debug] String: ---------------------------- AC _STA
..[ACPI Debug] String: --------- VIA SOFTWARE SMI PMIO 2Fh ------------
......................................
45 Devices found containing: 45 _STA, 2 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S3 S4 S5)
[ACPI Debug] String: ---------------------------- AC _STA
[ACPI Debug] String: ---------------------------- AC _STA
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Disabling VIA memory write queue (PCI ID 0305, rev 80): [55] 3c & 1f -> 1c
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *4)
ACPI: PCI Interrupt Link [LNKB] (IRQs *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
ACPI: PCI Interrupt Link [LNKD] (IRQs *9)
ACPI: Embedded Controller [EC] (gpe 6)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 4
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Applying VIA southbridge workaround.
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
Journalled Block Device driver loaded
[ACPI Debug] String: ---------------------------- AC _PSR
[ACPI Debug] String: ---------------------------- AC _FLPA
[ACPI Debug] String: ---------------------------- AC on line
ACPI: AC Adapter [AC] (on-line)
[ACPI Debug] String: --------- VIA SOFTWARE SMI PMIO 2Fh ------------
[ACPI Debug] String: ---------------- NABT < 6
[ACPI Debug] String: ---------------- Li Battery
[ACPI Debug] String: --------------------- DC >= 3000
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Lid Switch [LID]
acpi_processor-0897 [28] acpi_processor_get_per: Unsupported address space [127] (control_register)
ACPI: Processor [CPU0] (supports C1 C2, 16 throttling states)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
Real Time Clock Driver v1.10e
Floppy drive(s): fd0 is 1.44M
[ACPI Debug] String: ---------------------------- AC _STA
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPP generic driver version 2.4.2
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 177M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 64M @ 0xec000000
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 42) IDE UDMA100 controller on pci00:07.1

    ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio

hda: FUJITSU MHN2200AT, ATA DISK drive
blk: queue c032d220, I/O limit 4095Mb (mask 0xffffffff)
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: attached ide-disk driver.
hda: 39070080 sectors (20004 MB) w/2048KiB Cache, CHS=2432/255/63, UDMA(100)
hdc: attached ide-cdrom driver.
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
host/usb-uhci.c: $Revision: 1.275 $ time 02:59:04 Oct 24 2003 host/usb-uhci.c: High bandwidth mode enabled
host/usb-uhci.c: USB UHCI at I/O 0x1800, IRQ 9
host/usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
usb.c: kmalloc IF cdfeab00, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB UHCI Root Hub
SerialNumber: 1800
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: Port indicators are not supported
hub.c: power on to power good time: 2ms
hub.c: hub controller current requirement: 0mA
hub.c: port removable status: RR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface cdfeab00
usb.c: kusbd: /sbin/hotplug add 1
usb.c: kusbd policy returned 0xfffffffe
host/usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
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.
hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s
hub.c: port 1 connection change
hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s
hub.c: port 2, portstatus 101, change 3, 12 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 101, change 3, 12 Mb/s
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 84k freed
hub.c: port 2, portstatus 101, change 2, 12 Mb/s
hub.c: port 2, portstatus 101, change 2, 12 Mb/s
hub.c: port 2, portstatus 101, change 2, 12 Mb/s
hub.c: port 2, portstatus 101, change 2, 12 Mb/s
hub.c: port 2, portstatus 103, change 0, 12 Mb/s
hub.c: new USB device 00:07.2-2, assigned address 2
usb.c: kmalloc IF cdfe85c0, numif 2
usb.c: skipping descriptor 0x24
usb.c: skipping descriptor 0x24
usb.c: skipping descriptor 0x24
usb.c: skipped 3 class/vendor specific endpoint descriptors
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3
usb.c: USB device number 2 default language ID 0x409
Manufacturer: Thomson Consumer Electronics
Product: Thomson TCM305 Cable Modem
SerialNumber: 001095D5AD3F
usb.c: unhandled interfaces on device
usb.c: USB device 2 (vend/prod 0x69b/0x704) is not claimed by any active driver.

  Length              = 18
  DescriptorType      = 01
  USB version         = 1.10
  Vendor:Product      = 069b:0704
  MaxPacketSize0      = 32
  NumConfigurations   = 1
  Device version      = 28.00
  Device Class:SubClass:Protocol = 02:00:00
    Communications class
Configuration:
  bLength             =    9
  bDescriptorType     =   02
  wTotalLength        = 0050
  bNumInterfaces      =   02
  bConfigurationValue =   01
  iConfiguration      =   04
  bmAttributes        =   c0

MaxPower = 2mA

Interface: 0
Alternate Setting: 0

    bLength             =    9
    bDescriptorType     =   04
    bInterfaceNumber    =   00
    bAlternateSetting   =   00
    bNumEndpoints       =   01

bInterface Class:SubClass:Protocol = 02:06:00
iInterface = 05
Endpoint:
bLength = 7
bDescriptorType = 05
bEndpointAddress = 85 (in)
bmAttributes = 03 (Interrupt)
wMaxPacketSize = 0008
bInterval = 40

Interface: 1
Alternate Setting: 0

    bLength             =    9
    bDescriptorType     =   04
    bInterfaceNumber    =   01
    bAlternateSetting   =   00
    bNumEndpoints       =   00
    bInterface Class:SubClass:Protocol =   0a:00:00
    iInterface          =   06
  Alternate Setting:  1
    bLength             =    9
    bDescriptorType     =   04
    bInterfaceNumber    =   01
    bAlternateSetting   =   01
    bNumEndpoints       =   02

bInterface Class:SubClass:Protocol = 0a:00:00
iInterface = 07
Endpoint:
bLength = 7
bDescriptorType = 05
bEndpointAddress = 81 (in)
bmAttributes = 02 (Bulk)
wMaxPacketSize = 0040
bInterval = 00
Endpoint:
bLength = 7
bDescriptorType = 05
bEndpointAddress = 02 (out)
bmAttributes = 02 (Bulk)
wMaxPacketSize = 0040
bInterval = 00
usb.c: kusbd: /sbin/hotplug add 2
usb.c: kusbd: /sbin/hotplug add 2
hub.c: port 1, portstatus 300, change 2, 1.5 Mb/s
hub.c: port 1 enable change, status 300
hub.c: port 2, portstatus 103, change 0, 12 Mb/s
Adding Swap: 489940k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,5), internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
hdc: DMA disabled
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport_pc: Via 686A parallel port: io=0x378
8139too Fast Ethernet driver 0.9.26
eth0: RealTek RTL8139 at 0xce83f000, 00:08:02:04:da:f5, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
CDCEther.c: CDCEther.c: 0.98.6 7 Jan 2002 Brad Hards and another
usb.c: registered new driver CDCEther
CDCEther.c: Ethernet information found at device configuration. Trying to use it anyway. CDCEther.c: Found Header descriptor, CDC version 110.
CDCEther.c: Imperfect filtering support - need sw hashing
CDCEther.c: Can't use SetEthernetMulticastFilters request
CDCEther.c: detected BULK OUT packets of size 64
CDCEther.c: interrupt address: 5
CDCEther.c: interrupt interval: 64
usb.c: ignoring set_interface for dev 2, iface 0, alt 0
CDCEther.c: eth1: Thomson Consumer Electronics Thomson TCM305 Cable Modem 001095D5AD3F CDCEther.c: eth1: 00:10:95:D5:AD:3F
usb.c: CDCEther driver claimed interface cdfe85d8
usb.c: CDCEther driver claimed interface cdfe85c0
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport_pc: Via 686A parallel port: io=0x378
lp0: using parport0 (polling).
lp0: console ready
mtrr: no more MTRRs available
CDCEther.c: CDCEther_open failed intr_urb -22
CDCEther.c: eth1: set multicast filters
CDCEther.c: eth1: set multicast filters
CDCEther.c: eth1: set multicast filters
CDCEther.c: eth1: too many MC filters for hardware, using allmulti

Len Brown

author

2003-10-24 03:13 UTC #10 lore raw

In reply to a message not in the archive

Actually that change in -pre8 was a no-op -- we still force the PIC SCI from Edge to Level, just that now we print a message when we do so.

I expect the regression related to your lid switch is cased by something else. But since you have a box with an Edge Triggered SCI, I'd be interested if you are able to receive ACPI interrupts if we leave the SCI in Edge Triggered mode:

===== arch/i386/kernel/acpi.c 1.14 vs edited =====

arch/i386/kernel/acpi.c Thu Oct 23 23:09:05 2003 renamed from arch/i386/kernel/acpi.c Mon Oct 20 18:08:05 2003 +2 -0

@@ -492,6 +492,8 @@
        if (!(val & mask)) {
                printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
                        "setting to Level Triggerd\n", irq);
+               printk(KERN_WARNING PREFIX "NOT!\n");
+               return;
                outb(val | mask, port);
        }
 }

If you get a chance to try it, please send the /proc/interrupts from before & after.

thanks,
-Len

Quoted 12 lines · Sérgio Monteiro Basto

Hi
Seems that patch has been applied into kernel-2.4.23-pre8 and hangs my laptop when lid button is pressed.
Here is dmesg file.
where you can see ACPI: IRQ 10 was Edge Triggered, setting to Level Triggerd
Notes:
With pre7 all works fine.
I have APIC disable.
Other buttons like sleep, power have the normal beaver
if I can help testing something else tell me.

Quoted 70 lines

thanks
Quoted 67 lines · Len Brown
Ducrot,
I've found at least 1 system where hardcoding the PIC SCI to Level-Triggered fails, while leaving it as Edge Triggered succeeds.
The Intel SE7505VB2 "Vero Beach" when booted with "noapic" leaves IRQ9 as edge triggered.
When we force it to level triggered, we get no ACPI events. If we leave it as edge triggered, we do get ACPI events.
The other systems in my office leave the PIC SCI in Level Triggered mode, so Linux need do nothing to the trigger.
Today's patch prints a warning when the mode changes:
printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
"setting to Level Triggerd\n", irq);
But I'm thinking that by default we should _not_ change the trigger. Instead we should do so only upon, say acpi=sci_level_trigger or some such. If there is a popular model that leaves SCI as edge and requires level to work, then we can use DMI to set this param for it.
thanks,
-Len
Quoted 40 lines · Len Brown
Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · Len Brown
What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)
This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.
Do ACPI interrupt work on this latop? What happens on that system if you delete the call to eisa_set_level_irq()?
If we blindly program the PIC to be level senstive when the hardware is designed to be edge triggered, then we'll probably get no ACPI events on those systems, as the pulse may not be asserted long enough to provoke an interrupt.
We used to blindly program the APIC assuming the SCI was ACPI compliant, but we got burnt when we discovered that a significant set of system do _not_ have a level-triggered active-low SCI. Most of those specified their deviation with an SCI-over-ride in the MADT, but some did not:
http://bugzilla.kernel.org/show_bug.cgi?id=774
The APIC solution was to
1. don't hard-code level-triggered active-low
2. do whatever the SCI over-ride says
3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS programmed it.
thanks,
-Len
ps. this routine is mis-named, it it not EISA specific. Further, it is mis-located in a PCI-specific file but is not PCI specific. It should be in an X86 specific interrupt file and be named pic_something. I'm thinking I'll clone it into our x86 acpi code and add a warning when we find that it actually _changes_ the polarity.

-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/

Sérgio Monteiro Basto

2003-10-24 04:19 UTC #12 lore raw

In reply to a message not in the archive

Hi
make bzImage with your patch and make install appears your NOT! in dmesg
Resolves the hangs but ... now I don't have any events :)

I don't know if it helps but this story isn't new.
BTW in September of 2002, someone discover that if we apply this eisa_set_level_irq, our laptop begin generate ACPI events, before that we have one patch that has been applied until ACPI core system 20020907 or something like that.
if you want to know more about this story in presarios 7xx laptops see this page
http://www.pps.jussieu.fr/~jch/software/presario/
Power management and Core system chapters.
I don't said nothing before because, I don't have any acknowledgments about this interrupt things.

thanks

now with 23-pre8
cat /proc/interrupts
CPU0

  0:      24319          XT-PIC  timer
  1:        717          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:        161          XT-PIC  usb-uhci
 10:          0          XT-PIC  acpi
 12:       2612          XT-PIC  PS/2 Mouse
 14:      10581          XT-PIC  ide0
 15:       2406          XT-PIC  ide1
NMI:          0
ERR:          0

Quoted 112 lines · Len Brown

Actually that change in -pre8 was a no-op -- we still force the PIC SCI from Edge to Level, just that now we print a message when we do so.
I expect the regression related to your lid switch is cased by something else. But since you have a box with an Edge Triggered SCI, I'd be interested if you are able to receive ACPI interrupts if we leave the SCI in Edge Triggered mode:
===== arch/i386/kernel/acpi.c 1.14 vs edited =====
arch/i386/kernel/acpi.c Thu Oct 23 23:09:05 2003 renamed from arch/i386/kernel/acpi.c Mon Oct 20 18:08:05 2003 +2 -0
@@ -492,6 +492,8 @@
        if (!(val & mask)) {
                printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
                        "setting to Level Triggerd\n", irq);
+               printk(KERN_WARNING PREFIX "NOT!\n");
+               return;
                outb(val | mask, port);
        }
 }
If you get a chance to try it, please send the /proc/interrupts from before & after.
thanks,
-Len
Quoted 82 lines · Sérgio Monteiro Basto
Hi
Seems that patch has been applied into kernel-2.4.23-pre8 and hangs my laptop when lid button is pressed.
Here is dmesg file.
where you can see ACPI: IRQ 10 was Edge Triggered, setting to Level Triggerd
Notes:
With pre7 all works fine.
I have APIC disable.
Other buttons like sleep, power have the normal beaver
if I can help testing something else tell me.
thanks
Quoted 67 lines · Len Brown
Ducrot,
I've found at least 1 system where hardcoding the PIC SCI to Level-Triggered fails, while leaving it as Edge Triggered succeeds.
The Intel SE7505VB2 "Vero Beach" when booted with "noapic" leaves IRQ9 as edge triggered.
When we force it to level triggered, we get no ACPI events. If we leave it as edge triggered, we do get ACPI events.
The other systems in my office leave the PIC SCI in Level Triggered mode, so Linux need do nothing to the trigger.
Today's patch prints a warning when the mode changes:
printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
"setting to Level Triggerd\n", irq);
But I'm thinking that by default we should _not_ change the trigger. Instead we should do so only upon, say acpi=sci_level_trigger or some such. If there is a popular model that leaves SCI as edge and requires level to work, then we can use DMI to set this param for it.
thanks,
-Len
Quoted 40 lines · Len Brown
Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · Len Brown
What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)
This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.
Do ACPI interrupt work on this latop? What happens on that system if you delete the call to eisa_set_level_irq()?
If we blindly program the PIC to be level senstive when the hardware is designed to be edge triggered, then we'll probably get no ACPI events on those systems, as the pulse may not be asserted long enough to provoke an interrupt.
We used to blindly program the APIC assuming the SCI was ACPI compliant, but we got burnt when we discovered that a significant set of system do _not_ have a level-triggered active-low SCI. Most of those specified their deviation with an SCI-over-ride in the MADT, but some did not:
http://bugzilla.kernel.org/show_bug.cgi?id=774
The APIC solution was to
1. don't hard-code level-triggered active-low
2. do whatever the SCI over-ride says
3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS programmed it.
thanks,
-Len
ps. this routine is mis-named, it it not EISA specific. Further, it is mis-located in a PCI-specific file but is not PCI specific. It should be in an X86 specific interrupt file and be named pic_something. I'm thinking I'll clone it into our x86 acpi code and add a warning when we find that it actually _changes_ the polarity.

Signature · 12 lines

SérgioMB
email: [email protected]

Who gives me one shell, give me everything.



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/

Len Brown

author

2003-10-24 06:07 UTC #14 lore raw

In reply to a message not in the archive

Are you running with the kacpid patch to poll for acpi events as mentioned in the link below, or vanilla -pre7 and -pre8?

Does /proc/interrupts for vanilla -pre8 show any acpi interrupts after acpi events?

Does /proc/interrupts for vanilla -pre7 show any acpi interrupts after acpi events?

Please apply this patch to your -pre7 tree and tell me if you see any changes in behaviour:

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.4.22/20031020180809-eisa_set_level_irq.patch

again showing /proc/interrupts after acpi events.

My expectation is that it should make no difference, except for printing the extra line about changing the trigger mode.

If the kacpid patch is necessary for you to get any acpi events, then the real bug here is how to get the VT82C686 to deliver acpi events without resorting to polling.

thanks,
-Len

Quoted 35 lines · Sérgio Monteiro Basto

Hi
make bzImage with your patch and make install appears your NOT! in dmesg
Resolves the hangs but ... now I don't have any events :)
I don't know if it helps but this story isn't new.
BTW in September of 2002, someone discover that if we apply this eisa_set_level_irq, our laptop begin generate ACPI events, before that we have one patch that has been applied until ACPI core system 20020907 or something like that.
if you want to know more about this story in presarios 7xx laptops see this page
http://www.pps.jussieu.fr/~jch/software/presario/
Power management and Core system chapters.
I don't said nothing before because, I don't have any acknowledgments about this interrupt things.
thanks
now with 23-pre8
cat /proc/interrupts
CPU0
  0:      24319          XT-PIC  timer
  1:        717          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:        161          XT-PIC  usb-uhci
 10:          0          XT-PIC  acpi
 12:       2612          XT-PIC  PS/2 Mouse
 14:      10581          XT-PIC  ide0
 15:       2406          XT-PIC  ide1
NMI:          0
ERR:          0

Quoted 113 lines

Quoted 112 lines · Len Brown
Actually that change in -pre8 was a no-op -- we still force the PIC SCI from Edge to Level, just that now we print a message when we do so.
I expect the regression related to your lid switch is cased by something else. But since you have a box with an Edge Triggered SCI, I'd be interested if you are able to receive ACPI interrupts if we leave the SCI in Edge Triggered mode:
===== arch/i386/kernel/acpi.c 1.14 vs edited =====
arch/i386/kernel/acpi.c Thu Oct 23 23:09:05 2003 renamed from arch/i386/kernel/acpi.c Mon Oct 20 18:08:05 2003 +2 -0
@@ -492,6 +492,8 @@
        if (!(val & mask)) {
                printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
                        "setting to Level Triggerd\n", irq);
+               printk(KERN_WARNING PREFIX "NOT!\n");
+               return;
                outb(val | mask, port);
        }
 }
If you get a chance to try it, please send the /proc/interrupts from before & after.
thanks,
-Len
Quoted 82 lines · Sérgio Monteiro Basto
Hi
Seems that patch has been applied into kernel-2.4.23-pre8 and hangs my laptop when lid button is pressed.
Here is dmesg file.
where you can see ACPI: IRQ 10 was Edge Triggered, setting to Level Triggerd
Notes:
With pre7 all works fine.
I have APIC disable.
Other buttons like sleep, power have the normal beaver
if I can help testing something else tell me.
thanks
Quoted 67 lines · Len Brown
Ducrot,
I've found at least 1 system where hardcoding the PIC SCI to Level-Triggered fails, while leaving it as Edge Triggered succeeds.
The Intel SE7505VB2 "Vero Beach" when booted with "noapic" leaves IRQ9 as edge triggered.
When we force it to level triggered, we get no ACPI events. If we leave it as edge triggered, we do get ACPI events.
The other systems in my office leave the PIC SCI in Level Triggered mode, so Linux need do nothing to the trigger.
Today's patch prints a warning when the mode changes:
printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
"setting to Level Triggerd\n", irq);
But I'm thinking that by default we should _not_ change the trigger. Instead we should do so only upon, say acpi=sci_level_trigger or some such. If there is a popular model that leaves SCI as edge and requires level to work, then we can use DMI to set this param for it.
thanks,
-Len
Quoted 40 lines · Len Brown
Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · Len Brown
What does eisa_set_level_irq() do for us?
As its presence breaks the !CONFIG_PCI build, I deleted it and found that ACPI in PIC mode seems to work just fine without it (at least on 2 of 2 systems tested so far)
This ensure SCI interrupt is correctly initialized for (poorly) written BIOS. Without it, this break one of my laptop, and certainly others as well.
Do ACPI interrupt work on this latop? What happens on that system if you delete the call to eisa_set_level_irq()?
If we blindly program the PIC to be level senstive when the hardware is designed to be edge triggered, then we'll probably get no ACPI events on those systems, as the pulse may not be asserted long enough to provoke an interrupt.
We used to blindly program the APIC assuming the SCI was ACPI compliant, but we got burnt when we discovered that a significant set of system do _not_ have a level-triggered active-low SCI. Most of those specified their deviation with an SCI-over-ride in the MADT, but some did not:
http://bugzilla.kernel.org/show_bug.cgi?id=774
The APIC solution was to
1. don't hard-code level-triggered active-low
2. do whatever the SCI over-ride says
3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS programmed it.
thanks,
-Len
ps. this routine is mis-named, it it not EISA specific. Further, it is mis-located in a PCI-specific file but is not PCI specific. It should be in an X86 specific interrupt file and be named pic_something. I'm thinking I'll clone it into our x86 acpi code and add a warning when we find that it actually _changes_ the polarity.

Ducrot Bruno

2003-10-24 13:12 UTC #20 lore raw

In reply to a message not in the archive

Quoted 4 lines · Sérgio Monteiro Basto

Hi
make bzImage with your patch and make install appears your NOT! in dmesg
Resolves the hangs but ... now I don't have any events :)

I don't understand. Len's patch do not change anything actually, apart that almost toshiba satellite, some HP omnibook, your presario, some Packbard Bell and probably others will print a warning (if compiled UP and without local apic support).

Signature · 11 lines

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/

Sérgio Monteiro Basto

2003-10-24 20:03 UTC #16 lore raw

In reply to a message not in the archive

Ok works well with vanilla -pre7
so the problem is not in this patch.

cat /proc/interrupts
CPU0

  0:      19650          XT-PIC  timer
  1:        402          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  usb-uhci
 10:         15          XT-PIC  acpi
 11:         18          XT-PIC  eth0
 12:       1188          XT-PIC  PS/2 Mouse
 14:       9982          XT-PIC  ide0
 15:       1526          XT-PIC  ide1
NMI:          0
ERR:          0

Quoted 14 lines · Len Brown

Are you running with the kacpid patch to poll for acpi events as mentioned in the link below, or vanilla -pre7 and -pre8?
Does /proc/interrupts for vanilla -pre8 show any acpi interrupts after acpi events?
Does /proc/interrupts for vanilla -pre7 show any acpi interrupts after acpi events?
Please apply this patch to your -pre7 tree and tell me if you see any changes in behaviour:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.4.22/20031020180809-eisa_set_level_irq.patch

Quoted 8 lines

again showing /proc/interrupts after acpi events.
My expectation is that it should make no difference, except for printing the extra line about changing the trigger mode.
If the kacpid patch is necessary for you to get any acpi events, then the real bug here is how to get the VT82C686 to deliver acpi events without resorting to polling.

Was necessary until ACPI-20020907, not any more ok !

Quoted 5 lines

thanks,
-Len

Signature · 10 lines

Sérgio Basto




-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/

Sérgio Monteiro Basto

2003-10-25 01:50 UTC #17 lore raw

In reply to a message not in the archive

Quoted 5 lines

Quoted 5 lines · Len Brown
Quoted 4 lines
I expect the regression related to your lid switch is cased by something else. But since you have a box with an Edge Triggered SCI, I'd be interested if you are able to receive ACPI interrupts if we leave the SCI in Edge Triggered mode:

In fact is the acpi_ec_gpe_query patch that cause the regression. After some tests, I am sure, if I apply this patch, pressing lid button hangs my laptop.
and only this patch.

http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.4.22/20031017152411-acpi_ec_gpe_query.patch

thanks

Signature · 12 lines

SérgioMB
email: [email protected]

Who gives me one shell, give me everything.



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/

Ducrot Bruno

2003-10-27 13:30 UTC #19 lore raw

In reply to a message not in the archive

Quoted 7 lines · Sérgio Monteiro Basto

Hi
Quoted 5 lines
Quoted 5 lines · Len Brown
Quoted 4 lines
I expect the regression related to your lid switch is cased by something else. But since you have a box with an Edge Triggered SCI, I'd be interested if you are able to receive ACPI interrupts if we leave the SCI in Edge Triggered mode:

Quoted 7 lines

In fact is the acpi_ec_gpe_query patch that cause the regression. After some tests, I am sure, if I apply this patch, pressing lid button hangs my laptop.
and only this patch.
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.4.22/20031017152411-acpi_ec_gpe_query.patch

Hem, at first read, this patch is wrong, and seems more adapted to a perticular case, and being a bad hack in fact.

ec_device_init is always 0 if there is no ECDT table, which is wrong, or else we will have a really really long interrupt handler, not to mention that acpi_ec_gpe_query is not interrupt-context safe anyway, so calling directly this function from the interrupt handler is a mistake in all cases.

Signature · 11 lines

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/