From bahamasfranks at gmail.com Sun Nov 1 19:24:36 2009 From: bahamasfranks at gmail.com (Steve Franks) Date: Sun Nov 1 19:24:42 2009 Subject: suspend help Message-ID: <539c60b90911011055q2444592byac4c2716107786ad@mail.gmail.com> Hi, I was told on freebsd-questions a couple months back that suspend/resume support is broken on SMP kernels, which is pretty much all my systems in the era of dual-core. Assuming that is not my problem (on amd64 on this particular system), Anyway, when I call acipconf -s3 (in single-user mode or console), my screen flashes black, then comes right back to where is was, but the system is locked. I'm disabling usb, my wifi, linux, and snd_hda in rc.suspend, so I'm probably off on the wrong track, since I can't think of anything else to disable... Thanks, Steve FreeBSD fyre.franks-development.dyndns.biz 8.0-RC1 FreeBSD 8.0-RC1 #0: Thu Sep 17 18:50:57 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 From bugmaster at FreeBSD.org Mon Nov 2 11:06:47 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 2 11:07:11 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200911021106.nA2B6lAn033492@freefall.freebsd.org> 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 avg at icyb.net.ua Mon Nov 2 17:03:16 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Nov 2 17:03:23 2009 Subject: for review: retire 'magic' ivar Message-ID: <4AEF10D0.7020908@icyb.net.ua> ACPI bus defines two ivars with similar purposes - magic and private. It seems that this is redundant. Please review the following patch that removes 'magic' ivar. magic is used in three places, please see below for how it is replaced. 1. acpi_cpu magic is used was storing cpu id. Using integer type for that is, of course, more natural, but 'private' (void *) can be used without any problems. 2. acpi_hpet magic is used to distinguish between a device explicitly created in identify and devices auto-created by bus enumeration. The same could be done by examining 'handle' ivar, because bus enumeration always sets handle to non-NULL, but identify doesn't set it. Please note that there is a buglet in current code that doesn't have any practical consequences: magic is set to address of a variable that holds acpi_hpet_devclass, not to the devclass itself. Thus, if hpet driver were ever unloaded and reloaded it wouldn't recognize its device created on the first identify run. 3. acpi_ec magic is used in this driver similarly to acpi_hpet case. Big difference though, is that acpi_ec identify routine also sets handle ivar of explicitly created device. But it also sets private ivar. So we make use of that fact instead: private is set for explicitly created device, while it is not set for auto-created devices. The same buglet with no consequences is also found here. diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index 525824a..4ed7078 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -900,9 +900,6 @@ acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) case ACPI_IVAR_HANDLE: *(ACPI_HANDLE *)result = ad->ad_handle; break; - case ACPI_IVAR_MAGIC: - *(uintptr_t *)result = ad->ad_magic; - break; case ACPI_IVAR_PRIVATE: *(void **)result = ad->ad_private; break; @@ -938,9 +935,6 @@ acpi_write_ivar(device_t dev, device_t child, int index, uintptr_t value) case ACPI_IVAR_HANDLE: ad->ad_handle = (ACPI_HANDLE)value; break; - case ACPI_IVAR_MAGIC: - ad->ad_magic = (uintptr_t)value; - break; case ACPI_IVAR_PRIVATE: ad->ad_private = (void *)value; break; diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c index 8fe9de6..c16dcb1 100644 --- a/sys/dev/acpica/acpi_cpu.c +++ b/sys/dev/acpica/acpi_cpu.c @@ -255,7 +255,7 @@ acpi_cpu_probe(device_t dev) /* Mark this processor as in-use and save our derived id for attach. */ cpu_softc[cpu_id] = (void *)1; - acpi_set_magic(dev, cpu_id); + acpi_set_private(dev, (void*)(intptr_t)cpu_id); device_set_desc(dev, "ACPI CPU"); return (0); @@ -286,7 +286,7 @@ acpi_cpu_attach(device_t dev) sc = device_get_softc(dev); sc->cpu_dev = dev; sc->cpu_handle = acpi_get_handle(dev); - cpu_id = acpi_get_magic(dev); + cpu_id = (int)(intptr_t)acpi_get_private(dev); cpu_softc[cpu_id] = sc; pcpu_data = pcpu_find(cpu_id); pcpu_data->pc_device = dev; diff --git a/sys/dev/acpica/acpi_ec.c b/sys/dev/acpica/acpi_ec.c index a5a81dc..b339ba1 100644 --- a/sys/dev/acpica/acpi_ec.c +++ b/sys/dev/acpica/acpi_ec.c @@ -129,9 +129,6 @@ struct acpi_ec_params { int uid; }; -/* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) - /* * Driver softc. */ @@ -332,7 +329,6 @@ acpi_ec_ecdt_probe(device_t parent) params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -348,6 +344,7 @@ acpi_ec_probe(device_t dev) ACPI_STATUS status; device_t peer; char desc[64]; + int ecdt; int ret; struct acpi_ec_params *params; static char *ec_ids[] = { "PNP0C09", NULL }; @@ -362,11 +359,12 @@ acpi_ec_probe(device_t dev) * duplicate probe. */ ret = ENXIO; - params = NULL; + ecdt = 0; buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; - if (DEV_ECDT(dev)) { - params = acpi_get_private(dev); + params = acpi_get_private(dev); + if (params != NULL) { + ecdt = 1; ret = 0; } else if (!acpi_disabled("ec") && ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids)) { @@ -439,7 +437,7 @@ out: if (ret == 0) { snprintf(desc, sizeof(desc), "Embedded Controller: GPE %#x%s%s", params->gpe_bit, (params->glk) ? ", GLK" : "", - DEV_ECDT(dev) ? ", ECDT" : ""); + ecdt ? ", ECDT" : ""); device_set_desc_copy(dev, desc); } diff --git a/sys/dev/acpica/acpi_hpet.c b/sys/dev/acpica/acpi_hpet.c index ac28031..875ef07 100644 --- a/sys/dev/acpica/acpi_hpet.c +++ b/sys/dev/acpica/acpi_hpet.c @@ -66,8 +66,6 @@ static void acpi_hpet_test(struct acpi_hpet_softc *sc); static char *hpet_ids[] = { "PNP0103", NULL }; -#define DEV_HPET(x) (acpi_get_magic(x) == (uintptr_t)&acpi_hpet_devclass) - struct timecounter hpet_timecounter = { .tc_get_timecount = hpet_get_timecount, .tc_counter_mask = ~0u, @@ -153,8 +151,6 @@ acpi_hpet_identify(driver_t *driver, device_t parent) return; } - /* Record a magic value so we can detect this device later. */ - acpi_set_magic(child, (uintptr_t)&acpi_hpet_devclass); bus_set_resource(child, SYS_RES_MEMORY, 0, hpet->Address.Address, HPET_MEM_WIDTH); } @@ -166,7 +162,7 @@ acpi_hpet_probe(device_t dev) if (acpi_disabled("hpet")) return (ENXIO); - if (!DEV_HPET(dev) && + if (acpi_get_handle(dev) != NULL && (ACPI_ID_PROBE(device_get_parent(dev), dev, hpet_ids) == NULL || device_get_unit(dev) != 0)) return (ENXIO); diff --git a/sys/dev/acpica/acpivar.h b/sys/dev/acpica/acpivar.h index f4d27e4..abfaa8b 100644 --- a/sys/dev/acpica/acpivar.h +++ b/sys/dev/acpica/acpivar.h @@ -88,7 +88,6 @@ struct acpi_softc { struct acpi_device { /* ACPI ivars */ ACPI_HANDLE ad_handle; - uintptr_t ad_magic; void *ad_private; int ad_flags; @@ -224,7 +223,7 @@ extern int acpi_quirks; * attach to ACPI. */ #define ACPI_IVAR_HANDLE 0x100 -#define ACPI_IVAR_MAGIC 0x101 +#define ACPI_IVAR_UNUSED 0x101 /* Unused/reserved. */ #define ACPI_IVAR_PRIVATE 0x102 #define ACPI_IVAR_FLAGS 0x103 @@ -250,7 +249,6 @@ } __ACPI_BUS_ACCESSOR(acpi, handle, ACPI, HANDLE, ACPI_HANDLE) -__ACPI_BUS_ACCESSOR(acpi, magic, ACPI, MAGIC, uintptr_t) __ACPI_BUS_ACCESSOR(acpi, private, ACPI, PRIVATE, void *) __ACPI_BUS_ACCESSOR(acpi, flags, ACPI, FLAGS, int) -- Andriy Gapon From alexbestms at math.uni-muenster.de Tue Nov 3 15:30:07 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 15:39:12 2009 Subject: kern/136808: [acpi] panic when switching to s3 Message-ID: <200911031530.nA3FU60M047653@freefall.freebsd.org> The following reply was made to PR kern/136808; it has been noted by GNATS. From: Alexander Best To: Cc: Subject: Re: kern/136808: [acpi] panic when switching to s3 Date: Tue, 03 Nov 2009 16:27:19 +0100 (CET) running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198850: Tue Nov 3 13:00:55 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 shipped with debug.acpi.acpi_ca_version: 20091013 this panic no longer occurs. S3 however still doesn't work. the computer shuts down, but then instantly comes back up again. this however results in a state where no video signal is being sent to the monitor and nothing seems to happen (no hdd activity). after a hard reset the computer boots regularly (with all fs being clean). please ask if you need any more details about configs, sysctl values etc. alex From dgerow at afflictions.org Tue Nov 3 16:51:25 2009 From: dgerow at afflictions.org (Damian Gerow) Date: Tue Nov 3 16:51:31 2009 Subject: suspend help In-Reply-To: <539c60b90911011055q2444592byac4c2716107786ad@mail.gmail.com> References: <539c60b90911011055q2444592byac4c2716107786ad@mail.gmail.com> Message-ID: <20091103161847.GA46493@plebeian.afflictions.org> Steve Franks wrote: : I was told on freebsd-questions a couple months back that : suspend/resume support is broken on SMP kernels, which is pretty much : all my systems in the era of dual-core. Assuming that is not my : problem (on amd64 on this particular system), I believe that's only true for i386. I currently use S3 sleep without issue regularly, on an SMP amd64 laptop. Which branch are you using? : Anyway, when I call acipconf -s3 (in single-user mode or console), my : screen flashes black, then comes right back to where is was, but the : system is locked. I'm disabling usb, my wifi, linux, and snd_hda in : rc.suspend, so I'm probably off on the wrong track, since I can't : think of anything else to disable... Are you in X at the time? Could you look into setting up something like textdump(4) to see if your system is panicing? From jerry at marles.org Sun Nov 8 11:11:04 2009 From: jerry at marles.org (Jerry Marles) Date: Sun Nov 8 11:11:18 2009 Subject: HP Pavillion does not power off Message-ID: <1257676862.3860.14.camel@lenny.internal> 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 bschmidt at techwires.net Sun Nov 8 11:31:38 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Sun Nov 8 11:31:44 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) Message-ID: <200911081219.09397.bschmidt@techwires.net> 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 bugmaster at FreeBSD.org Mon Nov 9 11:06:46 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 9 11:07:10 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200911091106.nA9B6jaJ078893@freefall.freebsd.org> 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 jhb at freebsd.org Mon Nov 9 15:50:20 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 9 15:50:26 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <200911081219.09397.bschmidt@techwires.net> References: <200911081219.09397.bschmidt@techwires.net> Message-ID: <200911090743.48565.jhb@freebsd.org> 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 freebsd at levsha.org.ua Mon Nov 9 16:55:53 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Mon Nov 9 16:56:04 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <200911090743.48565.jhb@freebsd.org> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> Message-ID: <20091109161102.GJ30605@expo.ukrweb.net> 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 bschmidt at techwires.net Mon Nov 9 17:03:26 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Mon Nov 9 17:03:32 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <200911090743.48565.jhb@freebsd.org> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> Message-ID: <200911091803.19057.bschmidt@techwires.net> 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 rpaulo at FreeBSD.org Mon Nov 9 18:33:57 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Mon Nov 9 18:34:04 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <200911091803.19057.bschmidt@techwires.net> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <200911091803.19057.bschmidt@techwires.net> Message-ID: <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> 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 serge at a-1.com.ua Mon Nov 9 18:35:18 2009 From: serge at a-1.com.ua (Serge Semenenko) Date: Mon Nov 9 18:35:25 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <200911090743.48565.jhb@freebsd.org> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> Message-ID: <4AF85BFA.6090107@a-1.com.ua> 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 jhb at freebsd.org Mon Nov 9 19:52:26 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 9 19:52:32 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <4AF85BFA.6090107@a-1.com.ua> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <4AF85BFA.6090107@a-1.com.ua> Message-ID: <200911091401.30401.jhb@freebsd.org> 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 bschmidt at techwires.net Mon Nov 9 19:58:03 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Mon Nov 9 19:58:09 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> References: <200911081219.09397.bschmidt@techwires.net> <200911091803.19057.bschmidt@techwires.net> <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> Message-ID: <200911092049.35249.bschmidt@techwires.net> 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 jerry at marles.demon.co.uk Mon Nov 9 21:00:49 2009 From: jerry at marles.demon.co.uk (Jerry Marles) Date: Mon Nov 9 21:00:56 2009 Subject: HP Pavillion does not power off Message-ID: <1257798198.3265.12.camel@lenny.internal> 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 gavin at FreeBSD.org Mon Nov 9 21:05:19 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Nov 9 21:05:31 2009 Subject: heci: a new driver for review and testing In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> Message-ID: <20091109195045.Q13027@ury.york.ac.uk> 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 serge at a-1.com.ua Mon Nov 9 21:34:41 2009 From: serge at a-1.com.ua (Serge Semenenko) Date: Mon Nov 9 21:34:47 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <200911091401.30401.jhb@freebsd.org> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <4AF85BFA.6090107@a-1.com.ua> <200911091401.30401.jhb@freebsd.org> Message-ID: <4AF88AE6.2060406@a-1.com.ua> 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 freebsd at levsha.org.ua Mon Nov 9 22:00:18 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Mon Nov 9 22:00:26 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> References: <200911081219.09397.bschmidt@techwires.net> <200911090743.48565.jhb@freebsd.org> <200911091803.19057.bschmidt@techwires.net> <71290651-9DBE-4B3E-81A5-10023E90B43D@FreeBSD.org> Message-ID: <20091109220027.GK30605@expo.ukrweb.net> 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 jerry at marles.org Mon Nov 9 22:23:01 2009 From: jerry at marles.org (Jerry Marles) Date: Mon Nov 9 22:23:08 2009 Subject: HP Pavillion does not power off In-Reply-To: <1257798198.3265.12.camel@lenny.internal> References: <1257798198.3265.12.camel@lenny.internal> Message-ID: <1257805380.3265.21.camel@lenny.internal> 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 avg at icyb.net.ua Tue Nov 10 11:54:13 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 10 11:54:25 2009 Subject: heci: a new driver for review and testing In-Reply-To: <20091109195045.Q13027@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> Message-ID: <4AF95461.2030700@icyb.net.ua> 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 avg at icyb.net.ua Tue Nov 10 17:12:51 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 10 17:12:59 2009 Subject: heci: a new driver for review and testing In-Reply-To: <4AF95461.2030700@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> Message-ID: <4AF99F10.8020703@icyb.net.ua> 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 gavin at FreeBSD.org Tue Nov 10 18:42:34 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 10 18:42:49 2009 Subject: heci: a new driver for review and testing In-Reply-To: <4AF99F10.8020703@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> Message-ID: <20091110184016.S61601@ury.york.ac.uk> 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 freebsd at levsha.org.ua Tue Nov 10 19:04:00 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Tue Nov 10 19:04:08 2009 Subject: general issue with suspend/resume with iwn(4)/bge(4) In-Reply-To: <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> <20091109220027.GK30605@expo.ukrweb.net> Message-ID: <20091110190408.GB2216@expo.ukrweb.net> 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 avg at icyb.net.ua Wed Nov 11 13:17:39 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Nov 11 13:17:51 2009 Subject: heci: a new driver for review and testing In-Reply-To: <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> <20091110184016.S61601@ury.york.ac.uk> Message-ID: <4AFAB970.6060603@icyb.net.ua> 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 robert.moore at intel.com Thu Nov 12 18:42:15 2009 From: robert.moore at intel.com (Moore, Robert) Date: Thu Nov 12 20:16:23 2009 Subject: ACPICA version 20091112 released Message-ID: <4911F71203A09E4D9981D27F9D8308583E3066A4@orsmsx503.amr.corp.intel.com> 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 interface 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 SystemMemory. Ensure that the memory mappings created for operation regions do not cross 4K page boundaries. Crossing a page boundary while mapping regions can cause kernel warnings on some hosts if the pages have different attributes. Such regions are probably BIOS bugs, and this is the workaround. Linux BZ 14445. Lin Ming. Implemented an automatic repair for predefined methods that must return sorted lists. This change will repair (by sorting) packages returned by _ALR, _PSS, and _TSS. Drivers can now assume that the packages are correctly sorted and do not contain NULL package elements. Adds one new file, namespace/nsrepair2.c. ACPICA BZ 784. Lin Ming, Bob Moore. Fixed a possible fault during predefined name validation if a return Package object contains NULL elements. Also adds a warning if a NULL element is followed by any non-null elements. ACPICA BZ 813, 814. Future enhancement may include repair or removal of all such NULL elements where possible. Implemented additional module-level executable AML code support. This change 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 AML code has been illegal since ACPI 2.0. ACPICA BZ 762. Lin Ming. Implemented a new internal function to create Integer objects. This function 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 an info message for now. These messages may eventually be changed to debug-only. ACPICA BZ 812. Example Code and Data Size: These are the sizes for the OS-independent acpica.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 much 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. This 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 list 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 field. ACPICA BZ 815. Lin Ming, Bob Moore. iASL: Fixed a problem where the compiler could fault after the maximum number of errors was reached (200). acpixtract: Fixed a possible warning for pointer cast if the compiler warning level set very high. From smithi at nimnet.asn.au Sun Nov 15 05:58:17 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Nov 15 05:58:24 2009 Subject: HP Pavillion does not power off In-Reply-To: <1257805380.3265.21.camel@lenny.internal> References: <1257798198.3265.12.camel@lenny.internal> <1257805380.3265.21.camel@lenny.internal> Message-ID: <20091115164712.D65262@sola.nimnet.asn.au> On Mon, 9 Nov 2009, Jerry Marles wrote: > 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 Seeing noone else has had a go: It seems pretty strange that acpiconf -s 4 powers it off properly. your hwacpi.txt only shows .. 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 .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened to your hw.acpi.thermal settings also, but .. just a long shot .. What happens if you set sysctl hw.acpi.power_button_state=S4 and then try halt -p ? .. probably better off using 'shutdown -p now' actually. cheers, Ian From bugmaster at FreeBSD.org Mon Nov 16 11:06:47 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 16 11:07:13 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200911161106.nAGB6kfC011067@freefall.freebsd.org> 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 jerry at marles.org Mon Nov 16 18:05:47 2009 From: jerry at marles.org (Jerry Marles) Date: Mon Nov 16 18:05:52 2009 Subject: HP Pavillion does not power off In-Reply-To: <20091115164712.D65262@sola.nimnet.asn.au> References: <1257798198.3265.12.camel@lenny.internal> <1257805380.3265.21.camel@lenny.internal> <20091115164712.D65262@sola.nimnet.asn.au> Message-ID: <1258394735.3278.34.camel@lenny.internal> On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote: > On Mon, 9 Nov 2009, Jerry Marles wrote: > > 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 > > Seeing noone else has had a go: > > It seems pretty strange that acpiconf -s 4 powers it off properly. > your hwacpi.txt only shows .. > > 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 > > .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened > to your hw.acpi.thermal settings also, but .. just a long shot .. > > What happens if you set sysctl hw.acpi.power_button_state=S4 and then > try halt -p ? .. probably better off using 'shutdown -p now' actually. > > cheers, Ian That does change things in that now if I hold down the power button after halt -p it just goes off rather than booting straight back up again. So that is an improvement. Thanks. Jerry From gnemmi at gmail.com Tue Nov 17 19:34:22 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Nov 17 19:34:29 2009 Subject: Call for bge(4) testers Message-ID: <200911171734.16920.gnemmi@gmail.com> On Monday 16 November 2009 3:54:50 pm Pyun YongHyeon wrote: > On Mon, Nov 16, 2009 at 03:34:33PM -0200, Gonzalo Nemmi wrote: > > On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote: > > > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote: > > > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > > > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding > > > > > > > > TSO capability to bge(4). Now TSO is supported for > > > > > > > > BCM5755 or newer controllers. Actually some pre-BCM5755 > > > > > > > > controllers also support TSO with the help of special > > > > > > > > firmware but the license issue and lower performance of > > > > > > > > firmware based TSO as well as TSO bug I intentionally > > > > > > > > excluded TSO support for pre-BCM5755 controllers. You > > > > > > > > can get the patch form the following URL. The diff was > > > > > > > > generated against latest HEAD. > > > > > > > > > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.dif > > > > > > > >f > > > > > > > > > > > > > > Eh, there was a typo so I regenerated the diff. > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.dif > > > > > > >f > > > > > > > > > > > > Hi > > > > > > Just wanted to know before getting on to it, will your > > > > > > patch help to resolve kern/136876? > > > > > > > > > > My diff includes a fix for assuming PCIe device control > > > > > register and MSI control registers would be reside in fixed > > > > > address. And from the pciconf output I see the your MSI > > > > > control register is located at different address. However > > > > > bge(4) does not touch that register for BCM5906 so I guess my > > > > > diff may not fix the resume issue. > > > > > > > > Thanks a lot for your prompt, clear and straight answer. > > > > > > Would you try attached patch for BCM5906 resume issue? Not sure > > > whether it help or not though. > > > > Hi Pyun! > > Sorry for the delay, I was out of town and just got back. > > I'm downloading RC3 as of now. Then I will install: > > edit make.conf > > edit src.conf > > buildworld > > buildkernel > > installkernel > > reboot > > > > mergemaster -p > > make installworld > > reboot > > > > cp bge.diff bge.patch > > cd /usr/src/sys/dev/bge && patch < /path/to/patch > > make > > make install clean > > kldunload if_bge > > Not sure you removed bge in GENERIC kernel configuration file. > > > kldload if_bge > > pciconf -lcvb > > ifconfig bge0 up > > acpiconf -s3 > > > > ... and hpefully .. resume from S3 .. > > > > Is that ok with you or would you like me to do it in another way? > > That's ok. At first I wanted to add WOL to wake up bge(4) with > magic packet but bge(4) seems to require a lot of workaround for > each controller and it's too complex to implement at this time. > Just want to know whether bge(4) can resume from suspend. Well, I proceeded as I told you I would, applied your patch and even if it didn't solve the problem (bge still doesn't resume) at least it improved the previous situation given that now it doesn't loop timing out once and again as before. You can find a tail from /var/log/messages in here: http://pastebin.com/f643555f7 As you can see, the first 3 lines corresponds to "kldload if_bge" Line number 4 is "acpiconf -s3" At line number 17 bge0 finally fails and let's the machine wake up at line 18. Then, as soon as I could I issued a "ifconfig bge0" to see what I could get .. that's what you can see from line 20 to line 41. (as you can see in there, I found there are problems resuming umass devices as well ... ) Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the way, once unloaded, I could load it again but bge0 never showed on "ifconfig". Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... which ended with pulling the pendrive out as the system coldn't umount it ... I also found I get wpi0 messages on resume .. it spouts: wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory wpi0 could not lock memory and then it let's the system resume. All in all .. there's _a_lot_of_problems_on_resume_ Pyun, if you'd like me to try a new patch or to do some tests or whatever, just let me know. I'm here awaiting orders :) Best Regards Gonzalo Nemmi From gnemmi at gmail.com Tue Nov 17 21:17:48 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Nov 17 21:17:54 2009 Subject: Call for bge(4) testers In-Reply-To: <20091117193208.GI1262@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911171650.06834.gnemmi@gmail.com> <20091117193208.GI1262@michelle.cdnetworks.com> Message-ID: <200911171917.41906.gnemmi@gmail.com> On Tuesday 17 November 2009 5:32:08 pm Pyun YongHyeon wrote: > On Tue, Nov 17, 2009 at 04:50:06PM -0200, Gonzalo Nemmi wrote: > > [...] > > > Well, I proceeded as I told you I would, applied your patch and > > even if it didn't solve the problem (bge still doesn't resume) at > > least it improved the previous situation given that now it doesn't > > loop timing out once and again as before. > > > > You can find a tail from /var/log/messages in here: > > http://pastebin.com/f643555f7 > > > > As you can see, the first 3 lines corresponds to "kldload if_bge" > > Line number 4 is "acpiconf -s3" > > > > At line number 17 bge0 finally fails and let's the machine wake up > > at line 18. > > > > Then, as soon as I could I issued a "ifconfig bge0" to see what I > > could get .. that's what you can see from line 20 to line 41. (as > > you can see > > Ok, would you try this one? I guess bge(4) register access method > could be in uninitialized state after resume. Just did .. same result .. you?ll find the messages here: http://pastebin.com/f38369b3c 1.- root login 2 to 9.- "kldload if_bge" 10.- "acpiconf -s3" 11 to 13.- wpi0 messages before suspending 14 to 23.- bge0 messages upon resume 24.- wakeup BTW: is there an easy way to unroll the patches so I get a pristine copy back and apply the patch over it again? Im asking because the 3rd chunk of your patch ( bge_reset(sc); ) didn't apply cleanly and I had to edit if_bge.c by hand to add that line in the right place. Still willing to keep on trying and awaiting orders :) Best Regards Gonzalo Nemmi > > in there, I found there are problems resuming umass devices as > > well ... ) > > Probably Hans can help you on USB issues. > > > Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the > > way, once unloaded, I could load it again but bge0 never showed on > > "ifconfig". > > > > Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... > > which ended with pulling the pendrive out as the system coldn't > > umount it ... > > > > I also found I get wpi0 messages on resume .. it spouts: > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > wpi0 could not lock memory > > and then it let's the system resume. > > Don't know what it really means. You'd be better to ask wpi(4) > author Benjamin Close(benjsc@). > > > All in all .. there's _a_lot_of_problems_on_resume_ > > > > > > Pyun, if you'd like me to try a new patch or to do some tests or > > whatever, just let me know. I'm here awaiting orders :) > > > > Best Regards > > Gonzalo Nemmi -- Blessings Gonzalo Nemmi From velai4all at gmail.com Thu Nov 19 06:03:50 2009 From: velai4all at gmail.com (job s) Date: Thu Nov 19 06:03:57 2009 Subject: Windows XP blue screen error with ACPI enabled! Message-ID: Hi, I am a BIOS developer, I get a blue screen error "STOP 0x0000007e (0Xc0000005,0xf748e0bf,0xf78da208,0xf78d9f08) pci.sys -address F748e0bf base at F7487000 , datestamp 3b7d855c. " when i try to install windows XP in the targer motherboard. Please help in decoding the error message. thanks in advance. velavan From jerry at marles.org Fri Nov 20 10:50:01 2009 From: jerry at marles.org (Jerry Marles) Date: Fri Nov 20 10:50:08 2009 Subject: HP Pavillion does not power off In-Reply-To: <1258394735.3278.34.camel@lenny.internal> References: <1257798198.3265.12.camel@lenny.internal> <1257805380.3265.21.camel@lenny.internal> <20091115164712.D65262@sola.nimnet.asn.au> <1258394735.3278.34.camel@lenny.internal> Message-ID: <1258714188.3487.38.camel@lenny.internal> On Mon, 2009-11-16 at 18:05 +0000, Jerry Marles wrote: > On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote: > > On Mon, 9 Nov 2009, Jerry Marles wrote: > > > 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 > > > > Seeing noone else has had a go: > > > > It seems pretty strange that acpiconf -s 4 powers it off properly. > > your hwacpi.txt only shows .. > > > > 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 > > > > .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened > > to your hw.acpi.thermal settings also, but .. just a long shot .. > > > > What happens if you set sysctl hw.acpi.power_button_state=S4 and then > > try halt -p ? .. probably better off using 'shutdown -p now' actually. > > > > cheers, Ian > > That does change things in that now if I hold down the power button > after halt -p it just goes off rather than booting straight back up > again. So that is an improvement. Thanks. > > Jerry As Windows, Linux and Solaris can power this machine off would it be reasonable to conclude that this is just a feature of FreeBSD and not a fault in my ACPI tables? looking at the source code for acpiconf leads me to conclude that FreeBSD just does not implement ACPI sleep state S5, acpiconf certainly does not. In the handbook 11.16 Using and Debugging FreeBSD ACPI says "This means that we can use acpiconf -s to test S3, S4OS, and S5." That is clearly wrong. I discovered that the motherboard is actually made by Foxconn a 945GZ7MC. Googling Foxconn lead me to all sorts of interesting rants about Linux ACPI. I also found some useful articles about how to go about debugging ACPI tables and wondered if I could contribute something that might be useful to others if I could get to the bottom of the problem. I guess I would probably just waste a lot of time going down that road. I have been using FreeBSD since 2.15 around 1996 so I will be very disappointed to have to confine it to VirtualBox until I replace this hardware. I also find it hard to believe that I am the only one with this problem should I just create a PR? Regards Jerry From linimon at FreeBSD.org Sat Nov 21 23:14:17 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 21 23:14:28 2009 Subject: amd64/140751: [acpi] BIOS resource allocation and FreeBSD ACPI in TOSHIBA laptop Message-ID: <200911212314.nALNEGSL037716@freefall.freebsd.org> Old Synopsis: BIOS resource allocation and FreeBSD ACPI in TOSHIBA laptop New Synopsis: [acpi] BIOS resource allocation and FreeBSD ACPI in TOSHIBA laptop Responsible-Changed-From-To: freebsd-amd64->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 21 23:14:02 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140751 From smithi at nimnet.asn.au Sun Nov 22 14:23:50 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Nov 22 14:23:57 2009 Subject: HP Pavillion does not power off In-Reply-To: <1258714188.3487.38.camel@lenny.internal> References: <1257798198.3265.12.camel@lenny.internal> <1257805380.3265.21.camel@lenny.internal> <20091115164712.D65262@sola.nimnet.asn.au> <1258394735.3278.34.camel@lenny.internal> <1258714188.3487.38.camel@lenny.internal> Message-ID: <20091122235353.R65262@sola.nimnet.asn.au> On Fri, 20 Nov 2009, Jerry Marles wrote: > On Mon, 2009-11-16 at 18:05 +0000, Jerry Marles wrote: > > On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote: > > > On Mon, 9 Nov 2009, Jerry Marles wrote: > > > > 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 > > > > > > Seeing noone else has had a go: > > > > > > It seems pretty strange that acpiconf -s 4 powers it off properly. > > > your hwacpi.txt only shows .. > > > > > > 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 > > > > > > .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened > > > to your hw.acpi.thermal settings also, but .. just a long shot .. > > > > > > What happens if you set sysctl hw.acpi.power_button_state=S4 and then > > > try halt -p ? .. probably better off using 'shutdown -p now' actually. > > That does change things in that now if I hold down the power button > > after halt -p it just goes off rather than booting straight back up > > again. So that is an improvement. Thanks. This is not the right way to do things though .. > > Jerry > > As Windows, Linux and Solaris can power this machine off would it be > reasonable to conclude that this is just a feature of FreeBSD and not a > fault in my ACPI tables? looking at the source code for acpiconf leads No I don't think you can assume that; S5 poweroff works for most folks, and there seems to be a lot of sloppy if not broken AML out there. > me to conclude that FreeBSD just does not implement ACPI sleep state S5, > acpiconf certainly does not. In the handbook 11.16 Using and Debugging > FreeBSD ACPI says > > "This means that we can use acpiconf -s to test S3, S4OS, and S5." > > That is clearly wrong. It's wrong on two counts, at least on my 7.0-R and your 7.2-R; you're right that acpiconf doesn't try S5, and AFAIK S4OS does not yet exist on FreeBSD, so the handbook is, er, a bit optimistic in a couple of places! (I haven't checked what's new in 8.0, but think I'd have heard if S4OS was any further along than an incomplete Google SoC project a while ago) To be fair, acpi(4) under S4 does say that S4OS isn't yet supported. Here S5 (from the power button) works fine on my Thinkpad T23; properly running shutdown scripts and synching disks before powering off cleanly. And S3 (suspend to RAM) and subsequent resume works fine either by using acpiconf -s3 or the sleep button, which is Fn-F4 here. You didn't mention whether your system works with S3 suspend/resume? So just for kicks I tried acpiconf -s4 which hard powered down, without properly shutting down or synching disks (ie dirty after reboot) which I guess is a "don't do that then!" though in theory it should check that S4bios is 1 (or S4OS has arrived!) before diving off into space. > I discovered that the motherboard is actually made by Foxconn a > 945GZ7MC. Googling Foxconn lead me to all sorts of interesting rants > about Linux ACPI. I also found some useful articles about how to go > about debugging ACPI tables and wondered if I could contribute > something that might be useful to others if I could get to the bottom > of the problem. I guess I would probably just waste a lot of time > going down that road. You'd likely spend a lot of time, can't say if it'd be wasted or not :) > I have been using FreeBSD since 2.15 around 1996 so I will be very > disappointed to have to confine it to VirtualBox until I replace this > hardware. I also find it hard to believe that I am the only one with > this problem should I just create a PR? You got me rereading the handbook section, after a long time. There are some things you could try before (or while preparing to) submit a PR, in the light of scanning your posted AML. Have you tried? (from handbook): 11.16.3.5 System Powers Up After Suspend or Shutdown "First, try setting hw.acpi.disable_on_poweroff="0" in loader.conf(5). This keeps ACPI from disabling various events during the shutdown process. Some systems need this value set to 1 (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff." And/or from acpi(4) have you tried? maybe playing with: hw.acpi.disable_on_reboot Disable ACPI during the reboot process. Most systems reboot fine with ACPI still enabled, but some require exiting to legacy mode first. Default is 0, leave ACPI enabled. hw.acpi.handle_reboot Use the ACPI Reset Register capability to reboot the system. Default is 0, use legacy reboot support. Some newer systems require use of this register, while some only work with legacy rebooting support. Now I know very little about AML, and the folks that do must be on holidays :) but starting at the end, methods PTS and WAK are clearly about suspend and wakeup, and method _PTS refers to OSFL () which returns OSVR according to OS version: if I read it right, 4 for win2k and NT, 0 for most windows versions, 2 for winME (hee) and - perhaps usefully - 3 for Linux, and 1 otherwise, with reference to: 11.16.5.1 _OS dependencies "Some AML assumes the world consists of various Windows versions. You can tell FreeBSD to claim it is any OS to see if this fixes problems you may have. An easy way to override this is to set hw.acpi.osname="Windows 2001" in /boot/loader.conf or other similar strings you find in the ASL." OSFL is called in various places as well as in _PTS (put to sleep?) so a choice may well influence other aspects of ACPI as well as sleep states. (If anyone who actually knows what they're talking about is out there, please chime in; you can see I'm paddling way out of my depth ..) cheers, Ian From freebsd at abv.bg Sun Nov 22 15:30:52 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Sun Nov 22 15:30:59 2009 Subject: BIOS resource allocation and FreeBSD ACPI Message-ID: <24772986.196751.1258902794788.JavaMail.apache@mail53.abv.bg> Hi, I see this problem over and over again... some time ago I created this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/135070 and I just saw it has been duplicated: http://www.freebsd.org/cgi/query-pr.cgi?pr=140751 maybe the later one should be closed as a duplicate... anyway I think I saw this problem reported for more than 10 different laptops in the lists and the forums...maybe it's time someone to fix this issue ... I'm willing to donate money if someone can take and fix this (yes, I'm serious, I think it's worth it) regards, mgp ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From bugmaster at FreeBSD.org Mon Nov 23 11:06:47 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 23 11:07:11 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200911231106.nANB6kpo070026@freefall.freebsd.org> 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 amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO 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 55 problems total. From jerry at marles.org Mon Nov 23 18:28:07 2009 From: jerry at marles.org (Jerry Marles) Date: Mon Nov 23 18:28:28 2009 Subject: HP Pavillion does not power off In-Reply-To: <20091122235353.R65262@sola.nimnet.asn.au> References: <1257798198.3265.12.camel@lenny.internal> <1257805380.3265.21.camel@lenny.internal> <20091115164712.D65262@sola.nimnet.asn.au> <1258394735.3278.34.camel@lenny.internal> <1258714188.3487.38.camel@lenny.internal> <20091122235353.R65262@sola.nimnet.asn.au> Message-ID: <1259000870.3465.14.camel@lenny.internal> On Mon, 2009-11-23 at 01:23 +1100, Ian Smith wrote: > On Fri, 20 Nov 2009, Jerry Marles wrote: > > On Mon, 2009-11-16 at 18:05 +0000, Jerry Marles wrote: > > > On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote: > > > > On Mon, 9 Nov 2009, Jerry Marles wrote: > > > > > 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 > > > > > > > > Seeing noone else has had a go: > > > > > > > > It seems pretty strange that acpiconf -s 4 powers it off properly. > > > > your hwacpi.txt only shows .. > > > > > > > > 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 > > > > > > > > .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened > > > > to your hw.acpi.thermal settings also, but .. just a long shot .. > > > > > > > > What happens if you set sysctl hw.acpi.power_button_state=S4 and then > > > > try halt -p ? .. probably better off using 'shutdown -p now' actually. > > > > That does change things in that now if I hold down the power button > > > after halt -p it just goes off rather than booting straight back up > > > again. So that is an improvement. Thanks. > > This is not the right way to do things though .. > > > > Jerry > > > > As Windows, Linux and Solaris can power this machine off would it be > > reasonable to conclude that this is just a feature of FreeBSD and not a > > fault in my ACPI tables? looking at the source code for acpiconf leads > > No I don't think you can assume that; S5 poweroff works for most folks, > and there seems to be a lot of sloppy if not broken AML out there. > > > me to conclude that FreeBSD just does not implement ACPI sleep state S5, > > acpiconf certainly does not. In the handbook 11.16 Using and Debugging > > FreeBSD ACPI says > > > > "This means that we can use acpiconf -s to test S3, S4OS, and S5." > > > > That is clearly wrong. > > It's wrong on two counts, at least on my 7.0-R and your 7.2-R; you're > right that acpiconf doesn't try S5, and AFAIK S4OS does not yet exist on > FreeBSD, so the handbook is, er, a bit optimistic in a couple of places! > > (I haven't checked what's new in 8.0, but think I'd have heard if S4OS > was any further along than an incomplete Google SoC project a while ago) > > To be fair, acpi(4) under S4 does say that S4OS isn't yet supported. > > Here S5 (from the power button) works fine on my Thinkpad T23; properly > running shutdown scripts and synching disks before powering off cleanly. > > And S3 (suspend to RAM) and subsequent resume works fine either by using > acpiconf -s3 or the sleep button, which is Fn-F4 here. > > You didn't mention whether your system works with S3 suspend/resume? > > So just for kicks I tried acpiconf -s4 which hard powered down, without > properly shutting down or synching disks (ie dirty after reboot) which I > guess is a "don't do that then!" though in theory it should check that > S4bios is 1 (or S4OS has arrived!) before diving off into space. > > > I discovered that the motherboard is actually made by Foxconn a > > 945GZ7MC. Googling Foxconn lead me to all sorts of interesting rants > > about Linux ACPI. I also found some useful articles about how to go > > about debugging ACPI tables and wondered if I could contribute > > something that might be useful to others if I could get to the bottom > > of the problem. I guess I would probably just waste a lot of time > > going down that road. > > You'd likely spend a lot of time, can't say if it'd be wasted or not :) > > > I have been using FreeBSD since 2.15 around 1996 so I will be very > > disappointed to have to confine it to VirtualBox until I replace this > > hardware. I also find it hard to believe that I am the only one with > > this problem should I just create a PR? > > You got me rereading the handbook section, after a long time. There are > some things you could try before (or while preparing to) submit a PR, in > the light of scanning your posted AML. Have you tried? (from handbook): > > 11.16.3.5 System Powers Up After Suspend or Shutdown > > "First, try setting hw.acpi.disable_on_poweroff="0" in loader.conf(5). > This keeps ACPI from disabling various events during the shutdown > process. Some systems need this value set to 1 (the default) for the > same reason. This usually fixes the problem of a system powering up > spontaneously after a suspend or poweroff." > > And/or from acpi(4) have you tried? maybe playing with: > > hw.acpi.disable_on_reboot > Disable ACPI during the reboot process. Most systems reboot fine > with ACPI still enabled, but some require exiting to legacy mode > first. Default is 0, leave ACPI enabled. > > hw.acpi.handle_reboot > Use the ACPI Reset Register capability to reboot the system. > Default is 0, use legacy reboot support. Some newer systems > require use of this register, while some only work with legacy > rebooting support. > > Now I know very little about AML, and the folks that do must be on > holidays :) but starting at the end, methods PTS and WAK are clearly > about suspend and wakeup, and method _PTS refers to OSFL () which > returns OSVR according to OS version: if I read it right, 4 for win2k > and NT, 0 for most windows versions, 2 for winME (hee) and - perhaps > usefully - 3 for Linux, and 1 otherwise, with reference to: > > 11.16.5.1 _OS dependencies > > "Some AML assumes the world consists of various Windows versions. You can > tell FreeBSD to claim it is any OS to see if this fixes problems you may > have. An easy way to override this is to set hw.acpi.osname="Windows > 2001" in /boot/loader.conf or other similar strings you find in the ASL." > > OSFL is called in various places as well as in _PTS (put to sleep?) so a > choice may well influence other aspects of ACPI as well as sleep states. > > (If anyone who actually knows what they're talking about is out there, > please chime in; you can see I'm paddling way out of my depth ..) > > cheers, Ian Thanks Ian, Suspend/Resume does not work either but that is not a problem as this is not a laptop so I don't have any need to use it. I have tried all the above suggestions and none of them have helped. I thought I had read somewhere that FreeBSD and Linux are already pretending to be Windows in order to avoid acpi bugs that don't show up in testing because hardware often only gets tested on Windows. Perhaps the handbook and man pages are a little out of date. I tried changing acpiconf.c to make it try to do sleep state S5 the result was. # ./acpiconf -s 5 power off via acpi ioctl not supported acpiconf: request sleep type (5) failed: Device not configured I guess I am looking for a device that is not being detected properly. Perhaps the power button? acpi0: Power Button (fixed) Is it really fixed? Or is this the problem? acpi0: reservation of 0, a0000 (3) failed I am trying to compare what Linux does with FreeBSD but I have not found any other clues yet. Any suggestions on where to look would be very welcome. . Regards Jerry From jkim at FreeBSD.org Tue Nov 24 18:09:39 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Nov 24 18:09:45 2009 Subject: HP Pavillion does not power off In-Reply-To: <1257676862.3860.14.camel@lenny.internal> References: <1257676862.3860.14.camel@lenny.internal> Message-ID: <200911241309.30193.jkim@FreeBSD.org> On Sunday 08 November 2009 05:41 am, 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. I have a hunch that your SSDT is broken. In fact, it looks little unusual. Have you tried to update your BIOS? You seem to have two year old BIOS and it claims it only complies with ACPI 1.0, which has been dead for many years. :-) BTW, 'holding down power button for a few seconds' performs emergency shutdown sequence, which is usually done without ACPI intervention. Jung-uk Kim From jkim at FreeBSD.org Tue Nov 24 18:14:17 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Nov 24 18:14:24 2009 Subject: HP Pavillion does not power off In-Reply-To: <200911241309.30193.jkim@FreeBSD.org> References: <1257676862.3860.14.camel@lenny.internal> <200911241309.30193.jkim@FreeBSD.org> Message-ID: <200911241314.10392.jkim@FreeBSD.org> On Tuesday 24 November 2009 01:09 pm, Jung-uk Kim wrote: > I have a hunch that your SSDT is broken. In fact, it looks little > unusual. Have you tried to update your BIOS? You seem to have two > year old BIOS and it claims it only complies with ACPI 1.0, which ^^^^^^^^ > has been dead for many years. :-) Please ignore this part, I read wrong bit, sorry. Jung-uk Kim