From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 8 11:11:04 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B6A2106566C for ; Sun, 8 Nov 2009 11:11:04 +0000 (UTC) (envelope-from jerry@marles.org) Received: from mailforwards.extendcp.co.uk (mailforwards.extendcp.co.uk [79.170.40.74]) by mx1.freebsd.org (Postfix) with ESMTP id AA12E8FC1D for ; Sun, 8 Nov 2009 11:11:03 +0000 (UTC) Received: from marles.demon.co.uk ([83.104.58.197] helo=[192.168.1.181]) by mailforwards.extendcp.com with esmtpa (Exim 4.63) id 1N75Cf-0005Z0-Dg for freebsd-acpi@freebsd.org; Sun, 08 Nov 2009 10:41:02 +0000 From: Jerry Marles To: freebsd-acpi@freebsd.org Content-Type: text/plain Date: Sun, 08 Nov 2009 10:41:02 +0000 Message-Id: <1257676862.3860.14.camel@lenny.internal> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: HP Pavillion does not power off X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 11:11:04 -0000 Hello, I have a HP Pavillion desktop PC model g3001.uk. The problem I have is that halt -p does not power it off. The light on the power button goes off but I can hear that it is still running. If I hold down the power button for a few seconds the power can be heard to go off but then it boots right back up again. Windows and Linux can power it off successfully. Regards Jerry Marles sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 dmesg after boot -v Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e67000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0e67174. Calibrating clock(s) ... i8254 clock: 1193153 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2992521060 Hz CPU: Intel(R) Pentium(R) D CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf65 Stepping = 5 Features=0xbfebfbff Features2=0xe49d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 2138832896 (2039 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001025000 - 0x000000007d38ffff, 2083958784 bytes (508779 pages) avail memory = 2083315712 (1986 MB) Table 'FACP' at 0x7f7c0200 Table 'APIC' at 0x7f7c0390 MADT: Found table at 0x7f7c0390 MP Configuration Table version 1.4 found at 0xc00fd190 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f57a0 pnpbios: Entry = f0000:6e6a Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf9850/0x0014 (v 0 HPQOEM) ACPI: RSDT @ 0x0x7f7c0000/0x0040 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) ACPI: FACP @ 0x0x7f7c0200/0x0084 (v 2 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) ACPI: DSDT @ 0x0x7f7c0600/0x5312 (v 1 HPQOEM SLIC-CPC 0x00000010 INTL 0x20051117) ACPI: FACS @ 0x0x7f7ce000/0x0040 ACPI: APIC @ 0x0x7f7c0390/0x006C (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) ACPI: MCFG @ 0x0x7f7c0440/0x003C (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) ACPI: SLIC @ 0x0x7f7c0480/0x0176 (v 1 HPQOEM SLIC-CPC 0x00000001 MSFT 0x00000001) ACPI: DBGP @ 0x0x7f7c0400/0x0034 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) ACPI: OEMB @ 0x0x7f7ce040/0x0061 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) ACPI: HPET @ 0x0x7f7c59c0/0x0038 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT 0x00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (May 1 2009 08:47:24) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc507c000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27708086) pcibios: BIOS version 3.00 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.FHR0 -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 4 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2770, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2772, revid=0x02 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xffa80000, size 19, enabled map[14]: type I/O Port, range 32, base 0xec00, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xffa40000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d8, revid=0x01 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xffa3c000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d2, revid=0x01 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[20]: type I/O Port, range 32, base 0xd880, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type I/O Port, range 32, base 0xd800, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xffa3bc00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xe880, size 3, enabled map[14]: type I/O Port, range 32, base 0xe800, size 2, enabled map[18]: type I/O Port, range 32, base 0xe480, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe400, size 2, enabled map[20]: type I/O Port, range 32, base 0xe080, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0xec00-0xec07 mem 0xffa80000-0xffafffff,0xd0000000-0xdfffffff,0xffa40000-0xffa7ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffa80000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xffa40000 agp0: detected 7932k stolen memory agp0: aperture size is 256M pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 17 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xff700000-0xff7fffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8136, revid=0x01 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0xc800, size 8, enabled pcib2: requested I/O range 0xc800-0xc8ff: in range map[18]: type Memory, range 64, base 0xff7ff000, size 12, enabled pcib2: requested memory range 0xff7ff000-0xff7fffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 re0: port 0xc800-0xc8ff mem 0xff7ff000-0xff7fffff irq 17 at device 0.0 on pci2 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xff7ff000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 256 to vector 50 re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x34000000 re0: MAC rev. 0x00000000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:1c:25:26:af:a4 re0: [MPSAFE] re0: [FILTER] uhci0: port 0xe000-0xe01f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdc00 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd880-0xd89f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd880 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd800-0xd81f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa3bc00-0xffa3bfff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xffa3bc00 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: memory decode 0xff800000-0xff8fffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=3, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0016, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=4 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff8f0000, size 16, enabled pcib3: requested memory range 0xff8f0000-0xff8fffff: good pcib3: matched entry for 3.1.INTA pcib3: slot 1 INTA hardwired to IRQ 22 ath0: mem 0xff8f0000-0xff8fffff irq 22 at device 1.0 on pci3 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xff8f0000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54 ath0: [MPSAFE] ath0: [ITHREAD] ath0: hal channel 2412/a0 -> 1 ath0: hal channel 2412/c0 -> 1 ath0: hal channel 2417/a0 -> 2 ath0: hal channel 2417/c0 -> 2 ath0: hal channel 2422/a0 -> 3 ath0: hal channel 2422/c0 -> 3 ath0: hal channel 2427/a0 -> 4 ath0: hal channel 2427/c0 -> 4 ath0: hal channel 2432/a0 -> 5 ath0: hal channel 2432/c0 -> 5 ath0: hal channel 2437/a0 -> 6 ath0: hal channel 2437/c0 -> 6 ath0: hal channel 2437/d0 -> 6 ath0: hal channel 2442/a0 -> 7 ath0: hal channel 2442/c0 -> 7 ath0: hal channel 2447/a0 -> 8 ath0: hal channel 2447/c0 -> 8 ath0: hal channel 2452/a0 -> 9 ath0: hal channel 2452/c0 -> 9 ath0: hal channel 2457/a0 -> 10 ath0: hal channel 2457/c0 -> 10 ath0: hal channel 2462/a0 -> 11 ath0: hal channel 2462/c0 -> 11 ath0: WARNING: using obsoleted if_watchdog interface ath0: bpf attached ath0: Ethernet address: 00:0f:b5:f8:27:3b ath0: bpf attached ath0: bpf attached ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: mac 7.9 phy 4.5 radio 5.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0xe880-0xe887,0xe800-0xe803,0xe480-0xe487,0xe400-0xe403,0xe080-0xe08f irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe080 atapci1: [MPSAFE] atapci1: [ITHREAD] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xe880 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xe800 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe480 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xe400 ata3: reset tp1 mask=03 ostat0=00 ostat1=00 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: reset tp2 stat0=00 stat1=00 devices=0xc ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 cpu0: on acpi0 ACPI: SSDT @ 0x0x7f7ce0b0/0x01D2 (v 1 AMI CPU1PM 0x00000001 INTL 0x20051117) cpu0: switching to generic Cx mode est0: on cpu0 est0: Invalid id16 (set, cur) = (3104, 3111) est0: Invalid freq 2400, ignored. p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x7f7ce290/0x0143 (v 1 AMI CPU2PM 0x00000001 INTL 0x20051117) est1: on cpu1 est1: Invalid id16 (set, cur) = (3104, 3111) est1: Invalid freq 2400, ignored. p4tcc1: on cpu1 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() ata: ata0 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4cb9 0x4cb9 0x4cb9 0x4cb9 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4cb9 0x4cb9 0x4cb9 0x4cb9 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4cb9 0x4cb9 0x4cb9 0x4cb9 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 133590 -> 100000 procfs registered lapic: Divisor 2, Frequency 99750708 hz Timecounter "TSC" frequency 2992521060 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on ICH7 chip ad0: setting UDMA100 on ICH7 chip ad0: 114473MB at ata0-master UDMA100 ad0: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ad4: 114473MB at ata2-master SATA150 ad4: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed GEOM: new disk ad4 GEOM_LABEL: Label for provider ad0s3a is ufsid/4af56ad7460adb4d. GEOM_LABEL: Label for provider ad0s3d is ufsid/4af56ad9ae586101. GEOM_LABEL: Label for provider ad0s3e is ufsid/4af56ad89984eff9. GEOM_LABEL: Label for provider ad0s3f is ufsid/4af56ad8f8d7e5eb. GEOM_LABEL: Label for provider ad0s5 is ext2fs//. GEOM_LABEL: Label for provider ad4s1 is ext2fs//1. ata3: reiniting channel .. ata3: reset tp1 mask=03 ostat0=00 ostat1=00 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: reset tp2 stat0=00 stat1=00 devices=0xc ata3: reinit done .. ata3: reiniting channel .. ata3: reset tp1 mask=03 ostat0=00 ostat1=00 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: reset tp2 stat0=00 stat1=00 devices=0xc ata3: reinit done .. ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: DVDR drive at ata3 as master acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 2048KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 1 msi: Assigning MSI IRQ 256 to local APIC 0 Trying to mount root from ufs:/dev/ad0s3a start_init: trying /sbin/init GEOM_LABEL: Label ufsid/4af56ad7460adb4d removed. GEOM_LABEL: Label for provider ad0s3a is ufsid/4af56ad7460adb4d. GEOM_LABEL: Label ufsid/4af56ad89984eff9 removed. GEOM_LABEL: Label for provider ad0s3e is ufsid/4af56ad89984eff9. GEOM_LABEL: Label ufsid/4af56ad8f8d7e5eb removed. GEOM_LABEL: Label for provider ad0s3f is ufsid/4af56ad8f8d7e5eb. GEOM_LABEL: Label ufsid/4af56ad9ae586101 removed. GEOM_LABEL: Label for provider ad0s3d is ufsid/4af56ad9ae586101. GEOM_LABEL: Label ufsid/4af56ad7460adb4d removed. GEOM_LABEL: Label ufsid/4af56ad89984eff9 removed. GEOM_LABEL: Label ufsid/4af56ad8f8d7e5eb removed. GEOM_LABEL: Label ufsid/4af56ad9ae586101 removed. Linux ELF exec handler installed splash: image decoder found: logo_saver From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 8 11:31:37 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE098106566B for ; Sun, 8 Nov 2009 11:31:37 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE9F8FC12 for ; Sun, 8 Nov 2009 11:31:37 +0000 (UTC) Received: from maja.lab.techwires.net (dslb-088-065-210-226.pools.arcor-ip.net [88.65.210.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.netsrc.de (Postfix) with ESMTP id 431CB192FD9; Sun, 8 Nov 2009 12:19:06 +0100 (CET) Received: from maja.lab.techwires.net (localhost [127.0.0.1]) by maja.lab.techwires.net (8.14.3/8.14.3) with ESMTP id nA8BJAf4026753; Sun, 8 Nov 2009 12:19:10 +0100 (CET) (envelope-from bschmidt@techwires.net) Received: (from bschmidt@localhost) by maja.lab.techwires.net (8.14.3/8.14.3/Submit) id nA8BJ97X026752; Sun, 8 Nov 2009 12:19:09 +0100 (CET) (envelope-from bschmidt@techwires.net) X-Authentication-Warning: maja.lab.sad1.techwires.net: bschmidt set sender to bschmidt@techwires.net using -f From: Bernhard Schmidt To: freebsd-acpi@freebsd.org Date: Sun, 8 Nov 2009 12:19:09 +0100 User-Agent: KMail/1.12.1 (FreeBSD/9.0-CURRENT; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911081219.09397.bschmidt@techwires.net> Cc: Subject: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 11:31:38 -0000 Hi, I hope this is the correct list for an issue like that, if not, a pointer would be appreciated. I've been in contact with Mykola Dzham quite some time now and we are trying to figure out a resume issue on his iwn(4) device. It does seem that this device does not come up correctly after suspend. The interesting part is, that even pciconf -l -bcv ist not able to get all information. Before suspend: iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) After resume: iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network Note the last 4 missing lines. After a bit of searching i stumbled across kern/136876 which described a very similar (same?) issue for a bge(4) device. The question now is, might there be any special "power management" feature which prevents proper resume? How might a solution look like? Thanks. -- Bernhard From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 11:06:46 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BCD910656B0 for ; Mon, 9 Nov 2009 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F3F2E8FC24 for ; Mon, 9 Nov 2009 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nA9B6jmU078896 for ; Mon, 9 Nov 2009 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nA9B6jaJ078893 for freebsd-acpi@FreeBSD.org; Mon, 9 Nov 2009 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Nov 2009 11:06:45 GMT Message-Id: <200911091106.nA9B6jaJ078893@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o kern/136808 acpi [acpi] panic when switching to s3 o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode f kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 f kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 54 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 15:50:20 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C88A1065676 for ; Mon, 9 Nov 2009 15:50:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2BC78FC2B for ; Mon, 9 Nov 2009 15:50:19 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id ED51546B1A; Mon, 9 Nov 2009 10:50:18 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1AEB88A01D; Mon, 9 Nov 2009 10:50:18 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Mon, 9 Nov 2009 07:43:48 -0500 User-Agent: KMail/1.9.7 References: <200911081219.09397.bschmidt@techwires.net> In-Reply-To: <200911081219.09397.bschmidt@techwires.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911090743.48565.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 09 Nov 2009 10:50:18 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:50:20 -0000 On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > Hi, > > I hope this is the correct list for an issue like that, if not, a pointer > would be appreciated. > > I've been in contact with Mykola Dzham quite some time now and we are trying > to figure out a resume issue on his iwn(4) device. It does seem that this > device does not come up correctly after suspend. The interesting part is, that > even pciconf -l -bcv ist not able to get all information. > > Before suspend: > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > class = network > bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > After resume: > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > class = network Are you sure you didn't forget the extra options to pciconf here? The bar should definitely not disappear since we save that state in software, not in hardware. Also, the capability pointer register is set by the hardware, software never changes it. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 16:55:53 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B832106566C; Mon, 9 Nov 2009 16:55:53 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 423688FC08; Mon, 9 Nov 2009 16:55:53 +0000 (UTC) Received: from levsha by expo.ukrweb.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N7Wpb-00025U-3P; Mon, 09 Nov 2009 18:11:03 +0200 Date: Mon, 9 Nov 2009 18:11:03 +0200 From: Mykola Dzham To: John Baldwin Message-ID: <20091109161102.GJ30605@expo.ukrweb.net> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911090743.48565.jhb@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:55:53 -0000 John Baldwin wrote: > On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > > Hi, > > > > I hope this is the correct list for an issue like that, if not, a pointer > > would be appreciated. > > > > I've been in contact with Mykola Dzham quite some time now and we are trying > > to figure out a resume issue on his iwn(4) device. It does seem that this > > device does not come up correctly after suspend. The interesting part is, that > > even pciconf -l -bcv ist not able to get all information. > > > > Before suspend: > > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > > class = network > > bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled > > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > > > After resume: > > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > > class = network > > Are you sure you didn't forget the extra options to pciconf here? The bar > should definitely not disappear since we save that state in software, not > in hardware. Also, the capability pointer register is set by the hardware, > software never changes it. Sure. I saved all pciconf -l -bcv (all devices). Difference is only in this lines and in on unuased cardbus: --- pciconf.before.txt 2009-11-07 21:38:21.000000000 +0200 +++ pciconf.after.txt 2009-11-07 21:38:21.000000000 +0200 @@ -180,16 +180,12 @@ vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network - bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled - cap 01[c8] = powerspec 3 supports D0 D3 current D0 - cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message - cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) none1@pci0:11:4:0: class=0x060700 card=0x9025104d chip=0x04761180 rev=0xba hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'Ricoh R/RL/5C476(II) (unknown)' class = bridge subclass = PCI-CardBus - bar [10] = type Memory, range 32, base 0xe8000000, size 4096, enabled + bar [10] = type Memory, range 32, base 0xe8000000, size 4096, disabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 fwohci0@pci0:11:4:1: class=0x0c0010 card=0x9025104d chip=0x08321180 rev=0x04 hdr=0x00 vendor = 'Ricoh Company, Ltd.' -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 17:03:26 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A795B106568B for ; Mon, 9 Nov 2009 17:03:26 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id 523E38FC15 for ; Mon, 9 Nov 2009 17:03:26 +0000 (UTC) Received: from jessie.localnet (unknown [212.185.121.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.netsrc.de (Postfix) with ESMTP id 281F1192FD9; Mon, 9 Nov 2009 18:03:25 +0100 (CET) From: Bernhard Schmidt To: John Baldwin Date: Mon, 9 Nov 2009 18:03:18 +0100 User-Agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.2; i686; ; ) References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> In-Reply-To: <200911090743.48565.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911091803.19057.bschmidt@techwires.net> Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:03:26 -0000 On Monday 09 November 2009 13:43:48 John Baldwin wrote: > On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > > Hi, > > > > I hope this is the correct list for an issue like that, if not, a pointer > > would be appreciated. > > > > I've been in contact with Mykola Dzham quite some time now and we are > > trying to figure out a resume issue on his iwn(4) device. It does seem > > that this device does not come up correctly after suspend. The > > interesting part is, that even pciconf -l -bcv ist not able to get all > > information. > > > > Before suspend: > > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > > class = network > > bar [10] = type Memory, range 64, base 0xec800000, size 8192, > > enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > > > After resume: > > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > > class = network > > Are you sure you didn't forget the extra options to pciconf here? The bar > should definitely not disappear since we save that state in software, not > in hardware. Also, the capability pointer register is set by the hardware, > software never changes it. The complete pciconf before suspend: http://techwires.net/~bschmidt/pciconf.before.txt The complete pciconf after resume: http://techwires.net/~bschmidt/pciconf.after.txt Comparing both yields exactly those 4 lines missing. -- Bernhard From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 18:33:57 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADDA4106566B; Mon, 9 Nov 2009 18:33:57 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 1493C8FC17; Mon, 9 Nov 2009 18:33:56 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so749782fga.13 for ; Mon, 09 Nov 2009 10:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=WSomzzKl+NJ/3/d/0vIimtY0mI/tDGYpzqsq2XrjVPE=; b=xe2UxBgEcHX2nDYVc7Sd0YKZe8brQoitdk8jdNdh2Dhjk11dCTQNZZeUUN7jLztOlb HnicUf77WYZZaips5cVTpnE31aKe/3dw9mrtym+oGI8yu7jW/oC/f1n2wBk26ZH1luFC pHgBmzZyW66VhS8CHHrAjuH8fXAz3tDHoGmsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=FH+a7ZcB9G5M4ijo0Ga1KCa/ryThYpUzrafIITXRWuSK5GUZHUJNn3llnRAAARqu8i LJKUke/rPgAebBLQex1CqRKg0+E5bg5tw9Lw/4SxvhjguOWt7s6bd7RJo+uWpSEQtR/H RxbT1Fjy3+wfNH5A4e8LRBmuabxRJnxsVqCzE= Received: by 10.86.13.37 with SMTP id 37mr1063918fgm.58.1257791636129; Mon, 09 Nov 2009 10:33:56 -0800 (PST) Received: from rui-macbook.lan (bl7-119-16.dsl.telepac.pt [85.240.119.16]) by mx.google.com with ESMTPS id l12sm7330354fgb.17.2009.11.09.10.33.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 10:33:55 -0800 (PST) Sender: Rui Paulo References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <200911091803.19057.bschmidt@techwires.net> In-Reply-To: <200911091803.19057.bschmidt@techwires.net> Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Rui Paulo Date: Mon, 9 Nov 2009 18:33:53 +0000 To: Bernhard Schmidt X-Mailer: Apple Mail (2.1076) Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:33:57 -0000 On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote: > On Monday 09 November 2009 13:43:48 John Baldwin wrote: >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: >>> Hi, >>> >>> I hope this is the correct list for an issue like that, if not, a >>> pointer >>> would be appreciated. >>> >>> I've been in contact with Mykola Dzham quite some time now and we >>> are >>> trying to figure out a resume issue on his iwn(4) device. It does >>> seem >>> that this device does not come up correctly after suspend. The >>> interesting part is, that even pciconf -l -bcv ist not able to get >>> all >>> information. >>> >>> Before suspend: >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 >>> chip=0x42328086 >>> rev=0x00 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link >>> 5100)' >>> class = network >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192, >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 >>> message >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) >>> >>> After resume: >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 >>> chip=0x42328086 >>> rev=0x00 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link >>> 5100)' >>> class = network >> >> Are you sure you didn't forget the extra options to pciconf here? >> The bar >> should definitely not disappear since we save that state in >> software, not >> in hardware. Also, the capability pointer register is set by the >> hardware, >> software never changes it. > > The complete pciconf before suspend: > http://techwires.net/~bschmidt/pciconf.before.txt > The complete pciconf after resume: > http://techwires.net/~bschmidt/pciconf.after.txt > > Comparing both yields exactly those 4 lines missing. We should check if the device driver is doing something evil on suspend/resume. Can you boot without iwn loaded and suspend/resume ? -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 18:35:18 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7090F106566C; Mon, 9 Nov 2009 18:35:18 +0000 (UTC) (envelope-from serge@a-1.com.ua) Received: from a1.com.ua (www.a-1.com.ua [82.207.103.158]) by mx1.freebsd.org (Postfix) with ESMTP id E273C8FC38; Mon, 9 Nov 2009 18:35:17 +0000 (UTC) Received: from serge.a1.lan ([10.1.1.137]) by a1.com.ua with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1N7Ykx-000BbV-UH; Mon, 09 Nov 2009 20:14:26 +0200 Message-ID: <4AF85BFA.6090107@a-1.com.ua> Date: Mon, 09 Nov 2009 20:14:18 +0200 From: Serge Semenenko User-Agent: Thunderbird 2.0.0.21 (X11/20090423) To: John Baldwin , freebsd-acpi@freebsd.org References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> In-Reply-To: <200911090743.48565.jhb@freebsd.org> Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 10.1.1.137 X-SA-Exim-Mail-From: serge@a-1.com.ua X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on a-1.com.ua X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=3.2.3 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on a1.com.ua) MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-U" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:35:18 -0000 John Baldwin wrote: On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: Hi, I hope this is the correct list for an issue like that, if not, a pointer would be appreciated. I've been in contact with Mykola Dzham quite some time now and we are trying to figure out a resume issue on his iwn(4) device. It does seem that this device does not come up correctly after suspend. The interesting part is, that even pciconf -l -bcv ist not able to get all information. Before suspend: iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) After resume: iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network Are you sure you didn't forget the extra options to pciconf here? The bar should definitely not disappear since we save that state in software, not in hardware. Also, the capability pointer register is set by the hardware, software never changes it. It looks similar to PR [1]http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 for me. And if I understood right you're already working on the solution... References 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 19:52:26 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4C9106566B for ; Mon, 9 Nov 2009 19:52:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 029EE8FC15 for ; Mon, 9 Nov 2009 19:52:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8D72A46B23; Mon, 9 Nov 2009 14:52:25 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9409D8A01D; Mon, 9 Nov 2009 14:52:24 -0500 (EST) From: John Baldwin To: Serge Semenenko Date: Mon, 9 Nov 2009 14:01:30 -0500 User-Agent: KMail/1.9.7 References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <4AF85BFA.6090107@a-1.com.ua> In-Reply-To: <4AF85BFA.6090107@a-1.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911091401.30401.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 09 Nov 2009 14:52:24 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:52:26 -0000 On Monday 09 November 2009 1:14:18 pm Serge Semenenko wrote: > John Baldwin wrote: > On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > > Hi, > > I hope this is the correct list for an issue like that, if not, a pointer > would be appreciated. > > I've been in contact with Mykola Dzham quite some time now and we are trying > to figure out a resume issue on his iwn(4) device. It does seem that this > device does not come up correctly after suspend. The interesting part is, that > even pciconf -l -bcv ist not able to get all information. > > Before suspend: > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > class = network > bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > After resume: > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > class = network > > > Are you sure you didn't forget the extra options to pciconf here? The bar > should definitely not disappear since we save that state in software, not > in hardware. Also, the capability pointer register is set by the hardware, > software never changes it. > > > > It looks similar to PR http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 for me. And if I understood right you're already working on the solution... No, having the capability registers and a BAR disappear after they were programmed is entirely different. That PR is about being able to allocate space for the BAR on boot, not about losing it entirely after resume. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 19:58:03 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AE5E1065679; Mon, 9 Nov 2009 19:58:03 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id 85CEF8FC08; Mon, 9 Nov 2009 19:58:02 +0000 (UTC) Received: from maja.lab.techwires.net (p54B4DBF9.dip.t-dialin.net [84.180.219.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.netsrc.de (Postfix) with ESMTP id 5ACB019300D; Mon, 9 Nov 2009 20:58:01 +0100 (CET) Received: from maja.lab.techwires.net (localhost [127.0.0.1]) by maja.lab.techwires.net (8.14.3/8.14.3) with ESMTP id nA9Jw0BC002785; Mon, 9 Nov 2009 20:58:00 +0100 (CET) (envelope-from bschmidt@techwires.net) Received: (from bschmidt@localhost) by maja.lab.techwires.net (8.14.3/8.14.3/Submit) id nA9JneOv002618; Mon, 9 Nov 2009 20:49:40 +0100 (CET) (envelope-from bschmidt@techwires.net) X-Authentication-Warning: maja.lab.techwires.net: bschmidt set sender to bschmidt@techwires.net using -f From: Bernhard Schmidt To: Rui Paulo Date: Mon, 9 Nov 2009 20:49:35 +0100 User-Agent: KMail/1.12.1 (FreeBSD/9.0-CURRENT; KDE/4.3.1; amd64; ; ) References: <200911081219.09397.bschmidt@techwires.net> <200911091803.19057.bschmidt@techwires.net> <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> In-Reply-To: <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911092049.35249.bschmidt@techwires.net> Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:58:03 -0000 On Monday 09 November 2009 19:33:53 Rui Paulo wrote: > On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote: > > On Monday 09 November 2009 13:43:48 John Baldwin wrote: > >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > >>> Hi, > >>> > >>> I hope this is the correct list for an issue like that, if not, a > >>> pointer > >>> would be appreciated. > >>> > >>> I've been in contact with Mykola Dzham quite some time now and we > >>> are > >>> trying to figure out a resume issue on his iwn(4) device. It does > >>> seem > >>> that this device does not come up correctly after suspend. The > >>> interesting part is, that even pciconf -l -bcv ist not able to get > >>> all > >>> information. > >>> > >>> Before suspend: > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 > >>> chip=0x42328086 > >>> rev=0x00 hdr=0x00 > >>> vendor = 'Intel Corporation' > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link > >>> 5100)' > >>> class = network > >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192, > >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 > >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > >>> message > >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > >>> > >>> After resume: > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 > >>> chip=0x42328086 > >>> rev=0x00 hdr=0x00 > >>> vendor = 'Intel Corporation' > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link > >>> 5100)' > >>> class = network > >> > >> Are you sure you didn't forget the extra options to pciconf here? > >> The bar > >> should definitely not disappear since we save that state in > >> software, not > >> in hardware. Also, the capability pointer register is set by the > >> hardware, > >> software never changes it. > > > > The complete pciconf before suspend: > > http://techwires.net/~bschmidt/pciconf.before.txt > > The complete pciconf after resume: > > http://techwires.net/~bschmidt/pciconf.after.txt > > > > Comparing both yields exactly those 4 lines missing. > > We should check if the device driver is doing something evil on > suspend/resume. Can you boot without iwn loaded and suspend/resume ? I'm sorry if it might came out wrong in my first email. It's Mykola Dzham's system which has those issue, I'm posting all information on prior discussions with him. I can suspend/resume with iwn loaded, device works after resume as its supposed to. For him kldload/kldunload does work too, those issues just come up after suspend. Based on that I had doubts that it is a general issue with the iwn driver. -- Bernhard From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 21:00:49 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA5D1065672 for ; Mon, 9 Nov 2009 21:00:49 +0000 (UTC) (envelope-from jerry@marles.demon.co.uk) Received: from lon1-post-2.mail.demon.net (lon1-post-2.mail.demon.net [195.173.77.149]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5248FC17 for ; Mon, 9 Nov 2009 21:00:49 +0000 (UTC) Received: from marles.demon.co.uk ([83.104.58.197] helo=[192.168.1.181]) by lon1-post-2.mail.demon.net with esmtp (Exim 4.69) id 1N7aol-00046J-av for freebsd-acpi@freebsd.org; Mon, 09 Nov 2009 20:26:27 +0000 From: Jerry Marles To: freebsd-acpi@freebsd.org Content-Type: text/plain Date: Mon, 09 Nov 2009 20:23:18 +0000 Message-Id: <1257798198.3265.12.camel@lenny.internal> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: Re: HP Pavillion does not power off X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:00:49 -0000 On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote: Hello, > > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is > that halt -p does not power it off. The light on the power button goes > off but I can hear that it is still running. If I hold down the power > button for a few seconds the power can be heard to go off but then it > boots right back up again. Windows and Linux can power it off > successfully. > > Regards > > Jerry Marles > with further investigation I have found that acpiconf -s 5 results in invalid sleep type (5) but acpiconf -s 4 powers it off successfully so if I could just make halt -p do whatever acpiconf -s 4 is doing the problem would be solved. any advice would be much appreciated. Regards Jerry Marles From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 21:05:19 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A939D106566B; Mon, 9 Nov 2009 21:05:19 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5836B8FC08; Mon, 9 Nov 2009 21:05:18 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id nA9KYBiL016294; Mon, 9 Nov 2009 20:34:11 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N7awF-0007OB-NH; Mon, 09 Nov 2009 20:34:11 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id nA9KYBkC071706; Mon, 9 Nov 2009 20:34:11 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id nA9KYAxG071694; Mon, 9 Nov 2009 20:34:10 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 9 Nov 2009 20:34:09 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Andriy Gapon In-Reply-To: <4AD6067E.2010503@icyb.net.ua> Message-ID: <20091109195045.Q13027@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:05:19 -0000 On Wed, 14 Oct 2009, Andriy Gapon wrote: > Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > > I actually got around to implementing it (in initial/basic form): > http://people.freebsd.org/~avg/heci.tgz Nice! I've got the following device in my laptop: heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Management Engine Interface (Mobile 4 Series Chipset)' class = simple comms I've added this device to the code, and loaded it: heci0: mem 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x02: heci0: status = 0x00 heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 heci0: found ME client at address 0x06: heci0: status = 0x00 heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 heci0: found ME client at address 0x22: heci0: status = 0x00 heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 heci0: found ME client at address 0x23: heci0: status = 0x00 heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C heci0: found ME client at address 0x24: heci0: status = 0x00 heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB However, running the heci-qst.c program you supplied: psi# ./heci-qst ioctl HECI_CONNECT: No such file or directory And output to the console: heci0: could not find ME client with given guid: 6B5205B9-8185-4519-B889-D98724B58607 Other than seeing that it doesn't appear in the list above, I don't know if this is expected or not... Secondly, I get a panic on module unlaod. I haven't spent any time looking at this, if you haven't fixed it yet let me know and I'll look into it further. I'm not even sure how it's getting that far into the detach routine before panicing, if dev really does = 0xdeadc0dedeadc0de #8 0xffffffff808580d3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) at /usr/src/sys/kern/kern_mutex.c:827 #10 0xffffffff812221c6 in heci_detach () from /usr/src/sys/modules/heci/heci.ko #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) at device_if.h:212 #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, what=Variable "what" is not available. ) at /usr/src/sys/kern/subr_bus.c:1156 #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) at /usr/src/sys/kern/kern_module.c:266 #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, flags=0) at /usr/src/sys/kern/kern_linker.c:633 #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, fileid=Variable "fileid" is not available. ) at /usr/src/sys/kern/kern_linker.c:1092 Let me know if there's anything else I can test. Thanks, Gavin From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 21:34:41 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 853921065676; Mon, 9 Nov 2009 21:34:41 +0000 (UTC) (envelope-from serge@a-1.com.ua) Received: from a1.com.ua (a1.com.ua [82.207.103.158]) by mx1.freebsd.org (Postfix) with ESMTP id 039E68FC27; Mon, 9 Nov 2009 21:34:40 +0000 (UTC) Received: from serge.a1.lan ([10.1.1.137]) by a1.com.ua with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1N7bsh-000Cuc-7o; Mon, 09 Nov 2009 23:34:39 +0200 Message-ID: <4AF88AE6.2060406@a-1.com.ua> Date: Mon, 09 Nov 2009 23:34:30 +0200 From: Serge Semenenko User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: John Baldwin , freebsd-acpi@freebsd.org References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <4AF85BFA.6090107@a-1.com.ua> <200911091401.30401.jhb@freebsd.org> In-Reply-To: <200911091401.30401.jhb@freebsd.org> X-SA-Exim-Connect-IP: 10.1.1.137 X-SA-Exim-Mail-From: serge@a-1.com.ua X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on a-1.com.ua X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.3 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on a1.com.ua) Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:34:41 -0000 John Baldwin wrote: > On Monday 09 November 2009 1:14:18 pm Serge Semenenko wrote: > >> John Baldwin wrote: >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: >> >> Hi, >> >> I hope this is the correct list for an issue like that, if not, a pointer >> would be appreciated. >> >> I've been in contact with Mykola Dzham quite some time now and we are trying >> to figure out a resume issue on his iwn(4) device. It does seem that this >> device does not come up correctly after suspend. The interesting part is, >> > that > >> even pciconf -l -bcv ist not able to get all information. >> >> Before suspend: >> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 >> rev=0x00 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' >> class = network >> bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled >> cap 01[c8] = powerspec 3 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) >> >> After resume: >> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 >> rev=0x00 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' >> class = network >> >> >> Are you sure you didn't forget the extra options to pciconf here? The bar >> should definitely not disappear since we save that state in software, not >> in hardware. Also, the capability pointer register is set by the hardware, >> software never changes it. >> >> >> >> It looks similar to PR http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 >> > for me. And if I understood right you're already working on the solution... > > No, having the capability registers and a BAR disappear after they were > programmed is entirely different. That PR is about being able to allocate > space for the BAR on boot, not about losing it entirely after resume. > > Not sure about nature of things happened but on my system resources programmed with mentioned in PR hack are also disappears on resume and to get things working the hack should be applied both on attach and on resume. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 22:00:18 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D06106566C; Mon, 9 Nov 2009 22:00:18 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 593DE8FC0A; Mon, 9 Nov 2009 22:00:18 +0000 (UTC) Received: from levsha by expo.ukrweb.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N7cHj-0007OE-Ey; Tue, 10 Nov 2009 00:00:27 +0200 Date: Tue, 10 Nov 2009 00:00:27 +0200 From: Mykola Dzham To: Rui Paulo Message-ID: <20091109220027.GK30605@expo.ukrweb.net> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <200911091803.19057.bschmidt@techwires.net> <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:00:18 -0000 Rui Paulo wrote: > On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote: > > > On Monday 09 November 2009 13:43:48 John Baldwin wrote: > >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > >>> Hi, > >>> > >>> I hope this is the correct list for an issue like that, if not, a > >>> pointer > >>> would be appreciated. > >>> > >>> I've been in contact with Mykola Dzham quite some time now and we > >>> are > >>> trying to figure out a resume issue on his iwn(4) device. It does > >>> seem > >>> that this device does not come up correctly after suspend. The > >>> interesting part is, that even pciconf -l -bcv ist not able to get > >>> all > >>> information. > >>> > >>> Before suspend: > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 > >>> chip=0x42328086 > >>> rev=0x00 hdr=0x00 > >>> vendor = 'Intel Corporation' > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link > >>> 5100)' > >>> class = network > >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192, > >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 > >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > >>> message > >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > >>> > >>> After resume: > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 > >>> chip=0x42328086 > >>> rev=0x00 hdr=0x00 > >>> vendor = 'Intel Corporation' > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link > >>> 5100)' > >>> class = network > >> > >> Are you sure you didn't forget the extra options to pciconf here? > >> The bar > >> should definitely not disappear since we save that state in > >> software, not > >> in hardware. Also, the capability pointer register is set by the > >> hardware, > >> software never changes it. > > > > The complete pciconf before suspend: > > http://techwires.net/~bschmidt/pciconf.before.txt > > The complete pciconf after resume: > > http://techwires.net/~bschmidt/pciconf.after.txt > > > > Comparing both yields exactly those 4 lines missing. > > We should check if the device driver is doing something evil on > suspend/resume. Can you boot without iwn loaded and suspend/resume ? Same result. Before: none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) After: none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' class = network -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 22:23:01 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29EAD106566C for ; Mon, 9 Nov 2009 22:23:01 +0000 (UTC) (envelope-from jerry@marles.org) Received: from mailforwards.extendcp.co.uk (mailforwards.extendcp.co.uk [79.170.40.74]) by mx1.freebsd.org (Postfix) with ESMTP id E5E288FC0A for ; Mon, 9 Nov 2009 22:23:00 +0000 (UTC) Received: from marles.demon.co.uk ([83.104.58.197] helo=[192.168.1.181]) by mailforwards.extendcp.com with esmtpa (Exim 4.63) id 1N7cdX-0001kS-Dk for freebsd-acpi@freebsd.org; Mon, 09 Nov 2009 22:22:59 +0000 From: Jerry Marles To: freebsd-acpi@freebsd.org In-Reply-To: <1257798198.3265.12.camel@lenny.internal> References: <1257798198.3265.12.camel@lenny.internal> Content-Type: text/plain Date: Mon, 09 Nov 2009 22:23:00 +0000 Message-Id: <1257805380.3265.21.camel@lenny.internal> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: Re: HP Pavillion does not power off X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:23:01 -0000 On Mon, 2009-11-09 at 20:23 +0000, Jerry Marles wrote: > On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote: > Hello, > > > > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is > > that halt -p does not power it off. The light on the power button goes > > off but I can hear that it is still running. If I hold down the power > > button for a few seconds the power can be heard to go off but then it > > boots right back up again. Windows and Linux can power it off > > successfully. > > > > Regards > > > > Jerry Marles > > > > with further investigation I have found that > > acpiconf -s 5 results in invalid sleep type (5) > > but acpiconf -s 4 powers it off successfully so if I could just make > halt -p do whatever acpiconf -s 4 is doing the problem would be solved. > > any advice would be much appreciated. dmesg after boot -v is here http://www.marles.org/acpi/dmesg.txt sysctl hw.acpi is here http://www.marles.org/acpi/hwacpi.txt acpidump is here http://www.marles.org/acpi/acpidump.txt _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 10 11:54:13 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A91A106566B; Tue, 10 Nov 2009 11:54:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9443A8FC22; Tue, 10 Nov 2009 11:54:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA11835; Tue, 10 Nov 2009 13:54:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AF95461.2030700@icyb.net.ua> Date: Tue, 10 Nov 2009 13:54:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> In-Reply-To: <20091109195045.Q13027@ury.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 11:54:13 -0000 on 09/11/2009 22:34 Gavin Atkinson said the following: > On Wed, 14 Oct 2009, Andriy Gapon wrote: >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 >> >> I actually got around to implementing it (in initial/basic form): >> http://people.freebsd.org/~avg/heci.tgz > > Nice! > > I've got the following device in my laptop: > > heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Management Engine Interface (Mobile 4 Series > Chipset)' > class = simple comms > > I've added this device to the code, and loaded it: > > heci0: mem > 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0 I will add this ID and name to the driver. > heci0: using MSI > heci0: [ITHREAD] > heci0: found ME client at address 0x02: > heci0: status = 0x00 > heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 > heci0: found ME client at address 0x06: > heci0: status = 0x00 > heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 > heci0: found ME client at address 0x07: > heci0: status = 0x00 > heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB > heci0: found ME client at address 0x20: > heci0: status = 0x00 > heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 > heci0: found ME client at address 0x21: > heci0: status = 0x00 > heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 > heci0: found ME client at address 0x22: > heci0: status = 0x00 > heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 > heci0: found ME client at address 0x23: > heci0: status = 0x00 > heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C > heci0: found ME client at address 0x24: > heci0: status = 0x00 > heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB Thanks a lot for testing! > However, running the heci-qst.c program you supplied: > > psi# ./heci-qst > ioctl HECI_CONNECT: No such file or directory > > And output to the console: > > heci0: could not find ME client with given guid: > 6B5205B9-8185-4519-B889-D98724B58607 > > Other than seeing that it doesn't appear in the list above, I don't know > if this is expected or not... Yes, this is expected if you don't have ME client with this GUID. Perhaps, there is no QST firmware in the ME or it is disabled. Also, I am not sure but I think that it could be possible that you have a newer version of QST and its GUID is different. If you feel adventurous, you could try substituting GUID value in heci-qst.c with values reported by the driver. Perhaps it would work, perhaps you'd get a crash or hang or just an ioctl error. > Secondly, I get a panic on module unlaod. I haven't spent any time > looking at this, if you haven't fixed it yet let me know and I'll look > into it further. To my shame I still haven't got around to testing the driver with head tree and diagnostics enabled. I do not see any problems on stable/7 without diagnostics. Robert Noland has reported that he had a lockup on module unload with head sources. I will investigate this. BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if debugger reports it correctly). This looks like the memory was already freed. > I'm not even sure how it's getting that far into the detach routine > before panicing, if dev really does = 0xdeadc0dedeadc0de > > #8 0xffffffff808580d3 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) > at /usr/src/sys/kern/kern_mutex.c:827 > #10 0xffffffff812221c6 in heci_detach () > from /usr/src/sys/modules/heci/heci.ko > #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) > at device_if.h:212 > #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, > what=Variable "what" is not available. > ) at /usr/src/sys/kern/subr_bus.c:1156 > #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) > at /usr/src/sys/kern/kern_module.c:266 > #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, > flags=0) at /usr/src/sys/kern/kern_linker.c:633 > #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, > fileid=Variable "fileid" is not available. > ) at /usr/src/sys/kern/kern_linker.c:1092 > > Let me know if there's anything else I can test. > > Thanks, Nothing else I can think of right now. Thanks again! -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 10 17:12:51 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37E71065670; Tue, 10 Nov 2009 17:12:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 74D608FC0C; Tue, 10 Nov 2009 17:12:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA19720; Tue, 10 Nov 2009 19:12:48 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AF99F10.8020703@icyb.net.ua> Date: Tue, 10 Nov 2009 19:12:48 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> In-Reply-To: <4AF95461.2030700@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, Robert Noland Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 17:12:51 -0000 on 10/11/2009 13:54 Andriy Gapon said the following: > on 09/11/2009 22:34 Gavin Atkinson said the following: >> Secondly, I get a panic on module unlaod. I haven't spent any time >> looking at this, if you haven't fixed it yet let me know and I'll look >> into it further. > > To my shame I still haven't got around to testing the driver with head tree and > diagnostics enabled. I do not see any problems on stable/7 without diagnostics. > Robert Noland has reported that he had a lockup on module unload with head > sources. I will investigate this. > BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if > debugger reports it correctly). This looks like the memory was already freed. I think I've found one bug in the heci code that could cause this - SLIST element was first freed and then removed from the list. I've uploaded updated sources (that should include your PCI ID too), could you please re-test? >> I'm not even sure how it's getting that far into the detach routine >> before panicing, if dev really does = 0xdeadc0dedeadc0de >> >> #8 0xffffffff808580d3 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:224 >> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) >> at /usr/src/sys/kern/kern_mutex.c:827 >> #10 0xffffffff812221c6 in heci_detach () >> from /usr/src/sys/modules/heci/heci.ko >> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) >> at device_if.h:212 >> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, >> what=Variable "what" is not available. >> ) at /usr/src/sys/kern/subr_bus.c:1156 >> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) >> at /usr/src/sys/kern/kern_module.c:266 >> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, >> flags=0) at /usr/src/sys/kern/kern_linker.c:633 >> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, >> fileid=Variable "fileid" is not available. >> ) at /usr/src/sys/kern/kern_linker.c:1092 >> >> Let me know if there's anything else I can test. >> >> Thanks, > > Nothing else I can think of right now. OK, I came up with something :) Could you please send me verbose version of driver attachment messages (debug.bootverbose=1)? Thank you! BTW, Robert, you also promised me those :) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 10 18:42:33 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C111065672; Tue, 10 Nov 2009 18:42:33 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 782FC8FC24; Tue, 10 Nov 2009 18:42:33 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id nAAIgR3l015505; Tue, 10 Nov 2009 18:42:27 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N7vfe-0001gy-V6; Tue, 10 Nov 2009 18:42:26 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id nAAIgQSQ066589; Tue, 10 Nov 2009 18:42:26 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id nAAIgQev066586; Tue, 10 Nov 2009 18:42:26 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Tue, 10 Nov 2009 18:42:26 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Andriy Gapon In-Reply-To: <4AF99F10.8020703@icyb.net.ua> Message-ID: <20091110184016.S61601@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:42:34 -0000 On Tue, 10 Nov 2009, Andriy Gapon wrote: > on 10/11/2009 13:54 Andriy Gapon said the following: >> on 09/11/2009 22:34 Gavin Atkinson said the following: >>> Secondly, I get a panic on module unlaod. I haven't spent any time >>> looking at this, if you haven't fixed it yet let me know and I'll look >>> into it further. >> >> To my shame I still haven't got around to testing the driver with head tree and >> diagnostics enabled. I do not see any problems on stable/7 without diagnostics. >> Robert Noland has reported that he had a lockup on module unload with head >> sources. I will investigate this. >> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if >> debugger reports it correctly). This looks like the memory was already freed. > > I think I've found one bug in the heci code that could cause this - SLIST element > was first freed and then removed from the list. > I've uploaded updated sources (that should include your PCI ID too), could you > please re-test? That seems to have fixed it, thanks! It also fixes the malloc() calls with locks held. > Could you please send me verbose version of driver attachment messages > (debug.bootverbose=1)? > Thank you! Sure! http://people.freebsd.org/~gavin/heci-verbose.txt Gavin From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 10 19:04:00 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D43D1065670; Tue, 10 Nov 2009 19:03:59 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 44DEE8FC0C; Tue, 10 Nov 2009 19:03:59 +0000 (UTC) Received: from levsha by expo.ukrweb.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N7w0e-0004h3-6s; Tue, 10 Nov 2009 21:04:08 +0200 Date: Tue, 10 Nov 2009 21:04:08 +0200 From: Mykola Dzham To: Rui Paulo Message-ID: <20091110190408.GB2216@expo.ukrweb.net> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <200911091803.19057.bschmidt@techwires.net> <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> <20091109220027.GK30605@expo.ukrweb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091109220027.GK30605@expo.ukrweb.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-acpi@freebsd.org Subject: Re: general issue with suspend/resume with iwn(4)/bge(4) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:04:00 -0000 Mykola Dzham wrote: > Rui Paulo wrote: > > On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote: > > > > > On Monday 09 November 2009 13:43:48 John Baldwin wrote: > > >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote: > > >>> Hi, > > >>> > > >>> I hope this is the correct list for an issue like that, if not, a > > >>> pointer > > >>> would be appreciated. > > >>> > > >>> I've been in contact with Mykola Dzham quite some time now and we > > >>> are > > >>> trying to figure out a resume issue on his iwn(4) device. It does > > >>> seem > > >>> that this device does not come up correctly after suspend. The > > >>> interesting part is, that even pciconf -l -bcv ist not able to get > > >>> all > > >>> information. > > >>> > > >>> Before suspend: > > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 > > >>> chip=0x42328086 > > >>> rev=0x00 hdr=0x00 > > >>> vendor = 'Intel Corporation' > > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link > > >>> 5100)' > > >>> class = network > > >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192, > > >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 > > >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > > >>> message > > >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > >>> > > >>> After resume: > > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 > > >>> chip=0x42328086 > > >>> rev=0x00 hdr=0x00 > > >>> vendor = 'Intel Corporation' > > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link > > >>> 5100)' > > >>> class = network > > >> > > >> Are you sure you didn't forget the extra options to pciconf here? > > >> The bar > > >> should definitely not disappear since we save that state in > > >> software, not > > >> in hardware. Also, the capability pointer register is set by the > > >> hardware, > > >> software never changes it. > > > > > > The complete pciconf before suspend: > > > http://techwires.net/~bschmidt/pciconf.before.txt > > > The complete pciconf after resume: > > > http://techwires.net/~bschmidt/pciconf.after.txt > > > > > > Comparing both yields exactly those 4 lines missing. > > > > We should check if the device driver is doing something evil on > > suspend/resume. Can you boot without iwn loaded and suspend/resume ? > > Same result. > Before: > > none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > class = network > bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > After: > > none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)' > class = network I tested possible pciconf output changes on em ethernet card on my notebook (without if_iwn loaded) before and after suspend/resume. On ethernet card no changes in output, same output before and after: none0@pci0:0:25:0: class=0x020000 card=0x9025104d chip=0x10f58086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82567LM-2 Gigabit Network Connection (82567LM)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xee900000, size 131072, enabled bar [14] = type Memory, range 32, base 0xee924000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x8100, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 13[e0] = PCI Advanced Features: FLR TP -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 11 13:17:39 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D61B6106566C; Wed, 11 Nov 2009 13:17:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AE6F68FC08; Wed, 11 Nov 2009 13:17:38 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12149; Wed, 11 Nov 2009 15:17:37 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AFAB970.6060603@icyb.net.ua> Date: Wed, 11 Nov 2009 15:17:36 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> <20091110184016.S61601@ury.york.ac.uk> In-Reply-To: <20091110184016.S61601@ury.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:17:39 -0000 on 10/11/2009 20:42 Gavin Atkinson said the following: > On Tue, 10 Nov 2009, Andriy Gapon wrote: >> on 10/11/2009 13:54 Andriy Gapon said the following: >>> on 09/11/2009 22:34 Gavin Atkinson said the following: >> I think I've found one bug in the heci code that could cause this - >> SLIST element >> was first freed and then removed from the list. >> I've uploaded updated sources (that should include your PCI ID too), >> could you >> please re-test? > > That seems to have fixed it, thanks! It also fixes the malloc() calls > with locks held. > >> Could you please send me verbose version of driver attachment messages >> (debug.bootverbose=1)? >> Thank you! > > Sure! > > http://people.freebsd.org/~gavin/heci-verbose.txt Thank you for the testing and data! -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 12 18:42:15 2009 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78CFE106566C for ; Thu, 12 Nov 2009 18:42:15 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 546A78FC1A for ; Thu, 12 Nov 2009 18:42:15 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 12 Nov 2009 10:42:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,729,1249282800"; d="scan'208";a="210825256" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by azsmga001.ch.intel.com with ESMTP; 12 Nov 2009 10:42:13 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Thu, 12 Nov 2009 10:42:13 -0800 From: "Moore, Robert" To: "Moore, Robert" Date: Thu, 12 Nov 2009 10:42:12 -0800 Thread-Topic: ACPICA version 20091112 released Thread-Index: Acpjx9jcYvGD7/zXTjqYkQu+j/2eGQ== Message-ID: <4911F71203A09E4D9981D27F9D8308583E3066A4@orsmsx503.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Nov 2009 20:16:21 +0000 Cc: Subject: ACPICA version 20091112 released X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:42:15 -0000 12 November 2009. Summary of changes for version 20091112: This release is available at www.acpica.org/downloads 1) ACPI CA Core Subsystem: Implemented a post-order callback to AcpiWalkNamespace. The existing interf= ace only has a pre-order callback. This change adds an additional parameter= for a post-order callback which will be more useful for bus scans. ACPICA = BZ 779. Lin Ming. Updated the ACPICA Programmer Reference. Modified the behavior of the operation region memory mapping cache for Syst= emMemory. Ensure that the memory mappings created for operation regions do = not cross 4K page boundaries. Crossing a page boundary while mapping region= s can cause kernel warnings on some hosts if the pages have different attri= butes. Such regions are probably BIOS bugs, and this is the workaround. Lin= ux BZ 14445. Lin Ming. Implemented an automatic repair for predefined methods that must return sor= ted lists. This change will repair (by sorting) packages returned by _ALR, = _PSS, and _TSS. Drivers can now assume that the packages are correctly sort= ed and do not contain NULL package elements. Adds one new file, namespace/n= srepair2.c. ACPICA BZ 784. Lin Ming, Bob Moore. Fixed a possible fault during predefined name validation if a return Packag= e object contains NULL elements. Also adds a warning if a NULL element is f= ollowed by any non-null elements. ACPICA BZ 813, 814. Future enhancement ma= y include repair or removal of all such NULL elements where possible. Implemented additional module-level executable AML code support. This chang= e will execute module-level code that is not at the root of the namespace (= under a Device object, etc.) at table load time. Module-level executable AM= L code has been illegal since ACPI 2.0. ACPICA BZ 762. Lin Ming. Implemented a new internal function to create Integer objects. This functio= n simplifies miscellaneous object creation code. ACPICA BZ 823. Reduced the severity of predefined repair messages, Warning to Info. Since = the object was successfully repaired, a warning is too severe. Reduced to a= n info message for now. These messages may eventually be changed to debug-o= nly. ACPICA BZ 812. Example Code and Data Size: These are the sizes for the OS-independent acpi= ca.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug = version of the code includes the debug output trace mechanism and has a muc= h larger code and data size. Previous Release: Non-Debug Version: 85.8K Code, 18.0K Data, 103.8K Total Debug Version: 161.8K Code, 50.6K Data, 212.4K Total Current Release: Non-Debug Version: 86.6K Code, 18.2K Data, 104.8K Total Debug Version: 162.7K Code, 50.8K Data, 213.5K Total 2) iASL Compiler/Disassembler and Tools: iASL: Implemented Switch() with While(1) so that Break works correctly. Thi= s change correctly implements the Switch operator with a surrounding While(= 1) so that the Break operator works as expected. ACPICA BZ 461. Lin Ming. iASL: Added a message if a package initializer list is shorter than package= length. Adds a new remark for a Package() declaration if an initializer li= st exists, but is shorter than the declared length of the package. Although= technically legal, this is probably a coding error and it is seen in the f= ield. ACPICA BZ 815. Lin Ming, Bob Moore. iASL: Fixed a problem where the compiler could fault after the maximum numb= er of errors was reached (200). acpixtract: Fixed a possible warning for pointer cast if the compiler warni= ng level set very high.