Re: aperf/mperf
On 11/19/2010 6:39 AM, Andriy Gapon wrote: > > I am thinking about providing two APIs for this. > > 1. KPI > void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); > > 2. Userland > sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. > > But I am not sure where to put the code for both APIs. > Adding another device under cpu seems like an overkill. These can be exported as a common interface from cpufreq (dev,cpu.X.perf_stats) and supplied by the child acpi_perf driver on each cpu. -- Nate ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ideas for _PSD/_CSD/_TSD
On 11/18/2010 11:09 AM, Andriy Gapon wrote: > I am trying to solicit some architectural/design ideas for implementing logic > that > would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. > Well, I am primarily interested in _PSD, but I think that some general > principles > could be shared. > > In simple terms. > Currently we do only the "global" P-state management. cpufreq advertises a > common > set of frequencies/P-states and a single P-state/frequency is set on all > (logical) > processors by e.g. powerd based on global system load. > The downsides are obvious, I think. > > Modern systems can provide _PSD method which describes grouping of logical > processors into P-state domains and nature of dependency between the > processors in > the domain. E.g. on some systems putting a single processor from the domain > into > a Px state results in all the processors being put into that state. On other > systems, all processors have to be put into the same state for it to become > effective. On yet other systems there could be no coordination required > between > the processors (even when they are all cores in the same package), so each > would > be placed in its own domain. > > I think that this issue may get more prominence because of the new > technologies > that combine power saving with "turbo boosting". E.g. there could be a > technology > where some processor's performance would only be boosted if other processors > are > at or above some state Pt. With current cpufreq design we would not be able > to > take an advantage of that, because we always put all the processors into the > same > state. As you can see from the codebase, cpufreq was designed with this model in mind. I spent a lot of work adding the cpu devices to newbus in order to have cpufreq attach per-cpu. Each instance has its own dev.cpu.X.freq setting. Of course, there weren't any asymmetrical CPU Px states back then so calculation of levels is shared as you point out. But since it's done in cpufreq attach(), it is easy to make that independent while still merging states with global settings (e.g., p4tcc relative levels that apply system-wide, not per-cpu). What you want is to have a flag that indicates if Px states are global or not. If global, you can still attach a cpufreq device to each cpu but make changing any of their settings loop through changing all cpu settings equally. This is how it currently works. If the flag is false, then only apply a setting to the device it was received on. -- Nate ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Event based scheduling and USB.
On 10/26/2010 12:57 PM, Alexander Motin wrote: > Takanori Watanabe wrote: >> I updated my FreeBSD tree on laptop, to the current >> as of 18 Oct.2010, it works fine with CPU C3 state enabled, >> >> I think this is your achievement of event time scheduler, >> thanks! Ah, so mav@ implemented a tickless-scheduler? That is nice. >> But when USB driver is enabled, the load average is considerablly >> high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. >> Then kern.eventtimer.periodic is set to 1, the load average goes >> to 0 quickly as before, but almost never transit to C3. >> >> Is this behavior expected, or something wrong? The USB controller often keeps the bus mastering bit set. This keeps the system out of C3. The way to fix this is to implement global suspend. Put a device in suspend mode and then turn off power to the USB port it is on. Then the USB controller will stop polling the bus. >> I noticed one of usb host controller device shares HPET irq. >> When I implement interrupt filter in uhci driver, the load average >> goes to 0 as before. >> >> >> >> % vmstat -i >> interrupt total rate >> irq1: atkbd0 398 2 >> irq9: acpi0 408 2 >> irq12: psm03 0 >> irq19: ehci1 37 0 >> irq20: hpet0 uhci0 35970230 >> irq22: ehci0 2 0 >> irq256: em04 0 >> irq257: ahci0 1692 10 >> Total 38514246 >> === > > I haven't noticed that issue and it is surely not expected for me. I > will try to reproduce it. > > Most likely you should be able to avoid interrupt sharing using some > additional HPET options, described at hpet(4). This seems silly. The whole point of APIC is to avoid clustering on a single interrupt but the BIOS put the timer on the USB controller irq? >> It's time to implement powertop for freebsd, isn't it? > > Surely it is. I was even thinking about possibility to port one from > OpenSolaris, but other work distracted me. You may take it, it you wish. It seems worth doing the internals new, but maybe outputting information in a compatible format for reporting tools. -- Nate ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Norikatsu Shigemura wrote: > Hi ACPI specialists! > > I noticed that CPU cooling doesn't work with testing mav@'s > timers_oneshot*.patch, so I got following results: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% last 24us > dev.cpu.1.cx_supported: C1/3 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% last 485us > dev.cpu.2.cx_supported: C1/3 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% last 155us > dev.cpu.3.cx_supported: C1/3 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% last 590us I think the problem is here. > cpu0: on acpi0 > PROCESSOR-0311 [230584] cpu_attach: acpi_cpu0: P_BLK at 0x410/6 > ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109) > ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109) > PROCESSOR-0696 [241753] cpu_cx_cst: acpi_cpu0: C2[1] not > available. > PROCESSOR-0730 [241753] cpu_cx_cst: acpi_cpu0: Got C3 - 245 > latency > cpu1: on acpi0 > PROCESSOR-0311 [241991] cpu_attach: acpi_cpu1: P_BLK at 0x410/6 > ACPI: SSDT 0xda9aca98 00303 (v01 PmRefApIst 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00303 (v01 PmRefApIst 3000 INTL 20061109) > ACPI: SSDT 0xda9aad98 00119 (v01 PmRefApCst 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00119 (v01 PmRefApCst 3000 INTL 20061109) > PROCESSOR-0696 [254000] cpu_cx_cst: acpi_cpu1: C2[1] not > available. > PROCESSOR-0730 [254000] cpu_cx_cst: acpi_cpu1: Got C3 - 245 > latency > cpu2: on acpi0 > PROCESSOR-0311 [254238] cpu_attach: acpi_cpu2: P_BLK at 0x410/6 > PROCESSOR-0696 [255657] cpu_cx_cst: acpi_cpu2: C2[1] not > available. > PROCESSOR-0730 [255657] cpu_cx_cst: acpi_cpu2: Got C3 - 245 > latency > cpu3: on acpi0 > PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6 > PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not > available. > PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 > latency I think the issue is that C2 is not available for some reason and thus C3 can't be used either. The way to tell is to use acpidump and look for the CPU objects' _CST fields. -- Nate ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel SE7500WV2 not working with ACPI
Brooks Davis wrote: >> Since acpi0 failed to probe, ACPI isn't used to route interrupts. However, >> the apic code expects ACPI to do that since it enumerated CPUs and I/O >> APICs. You are just going to have to disable ACPI for now. >> >> > acpi0: on motherboard >> > ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] >> > (Node 0xc29b4660), AE_NOT_EXIST >> > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST >> > device_probe_and_attach: acpi0 attach returned 6 >> >> If you can get this fixed, then you can re-enable ACPI again. > > What I can't figure out is why this is failing since acpi was at least > partialy working before. For instance, soft power was definalty > working. Doesn't that depend on acpi attaching? I plan on updating our ACPI-CA to the 20031202 dist after the code freeze is over. It has some important fixes, including this one: --- Changed the initialization of Operation Regions during subsystem init to perform two entire walks of the ACPI namespace; The first to initialize the regions themselves, the second to execute the _REG methods. This fixed some interdependencies across _REG methods found on some machines. --- You might be able to work around this problem by setting: debug.acpi.disable="ec" or debug.acpi.avoid="\_SB_.PCI0.SBRG" -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem, my VAIO won't come back from suspension
On Wed, 3 Dec 2003, Melvyn Sopacua wrote: > On Tuesday 02 December 2003 23:34, Nate Lawson wrote: > > Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, > > try disabling acpi and using apm(4) to suspend and resume. > > Normally that would be grand, but now that I've not compiled acpi into the > kernel, I have no /dev/apm anymore as well. If you don't have acpi(4), then you need to add "device apm" to your kernel to enable apm(4) support. > Even with acpi, I never got a /dev/apmctl so apmd never worked. I've read > through devfs(5)/(8), but as far as I understand, it is the driver's > responsibility to create the device and even if you could do it in userland, > than it will just be a non-configured device. You can't use apmd with acpi(4). It has /dev/acpictl. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem, my VAIO won't come back from suspension
Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, try disabling acpi and using apm(4) to suspend and resume. Suspend/resume is far down my list of things to troubleshoot and most of the problems are very hw-specific. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /dev/fd0 not working with ACPI
dmesg, please, including error. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Lukas Ertl wrote: > On Tue, 2 Dec 2003, Nate Lawson wrote: > > Um, you have no _ACx values so the fan will be controlled by the BIOS. We > > should probably provide a way for users to supply their own _ACx values if > > they're not happy with the BIOS's but I'm not sure your ASL exports a > > power resource for the fan object. Do you have an object with id PNP0C0B? > > No, there's no PNP0C0B device. Build with options ACPI_DEBUG and boot with this in loader.conf: debug.acpi.layer=ACPI_POWER debug.acpi.level=ACPI_LV_OBJECTS It will print any power resources you have. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Lukas Ertl wrote: > On Wed, 26 Nov 2003, Nate Lawson wrote: > > I need the output of sysctl hw.acpi.thermal to see your _ACx values. > > hw.acpi.thermal.tz0.temperature: 3072 > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 3627 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 3662 > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On Tue, 25 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > > > Please also send the output of acpidump -t -d > jdp-P2.asl > > I booted the 5.1R live CD in an attempt to get this output. I > discovered that the machine hangs the same way with 5.1R as it does > with -current. (When I originally installed 5.1R, the machine had > an older, non-ACPI BIOS.) > > I've attached the verbose boot messages from 5.1R, in case that's > worth anything. Such a shame -- it gets within a hair's breadth of > running init, but it just can't quite make it all the way there. Would you try this patch? http://people.freebsd.org/~jhb/patches/acpi_sci.patch -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: psmintr not attached w/ acpi
On Mon, 1 Dec 2003, Slawa Olhovchenkov wrote:
> On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote:
> > Your ASL indicates that it returns different values for present (based on
> > PS2F) and current resources (based on KBDI). Please send me the URL to
> > the full ASL so I can see what sets those two variables.
>
> http://zxy.spb.ru/acpi.dump
>
> Do you need additional information?
Try this workaround, recompile your asl, set dsdt_load in loader.conf.
See acpi(4) if you need info on this process. I think your BIOS needs a
workaround. I wonder if the MS interpreter ignores _STA for some devices.
--- slawa-IntelLaptop.asl.orig Mon Dec 1 10:54:18 2003
+++ slawa-IntelLaptop.asl Mon Dec 1 10:57:39 2003
@@ -3353,14 +3353,7 @@
Name (_HID, EisaId ("PNP0F13"))
Method (_STA, 0, NotSerialized)
{
-If (LEqual (PS2F, 0x00))
-{
Return (0x0F)
-}
-Else
-{
-Return (0x00)
-}
}
Method (_CRS, 0, NotSerialized)
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: psmintr not attached w/ acpi
Your ASL indicates that it returns different values for present (based on PS2F) and current resources (based on KBDI). Please send me the URL to the full ASL so I can see what sets those two variables. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Lukas Ertl wrote: > On Wed, 26 Nov 2003, Nate Lawson wrote: > > It's possible the fan is under BIOS control so make sure you have an > > up-to-date bios. If not, you should get a console printout when acpi > > switches the fan on. sysctl hw.acpi.thermal > > Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least > no 'standard' one - anyone knows what hides behind this HKEY device > every ThinkPad seems to have?) It's not called FAN. It is a device with a certain PNP id and controlled by a power resource. I need the output of sysctl hw.acpi.thermal to see your _ACx values. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Fri, 21 Nov 2003, Lukas Ertl wrote: > On Fri, 21 Nov 2003, Nate Lawson wrote: > > > > On Tue, 18 Nov 2003, Lukas Ertl wrote: > > > > > I'm gonna try some "buildkernelstones" with the different settings. If > > > > > you have some special benchmarks in mind I'd be happy to run them. > > > > > > > > That's probably ok. It has a lot of IO. > > > > > > Now I've tried running make buildkernel and tarring /usr/src to a > > > different location, with different setting for hw.acpi.cpu.cx_lowest. I > > > couldn't see any real difference - neither in performance nor in heat > > > emission. > > > > Well, heat emission will be high during benchmarks because the CPU is > > rarely idle. My fan always comes on my laptop during buildworld. But the > > difference is when it's mostly idle (checking email, web browsing). With > > machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting > > there. With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the > > box is still warm. With cx_lowest=2 (C3, 120 us transition time), the box > > is very cool but some IO gets a little slower (serial port). But not > > much. > > The problem is that the fan in this machine always kicks in after several > minutes, and then stays on. This is very annoying. If you're testing C3 states, you have to disable USB in your kernel config. (I just load USB as modules since performance is not an issue and I like to use C3 while on the road to get max power savings). It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal > BTW, I'm having another ACPI question, do these figures here make sense? > > hw.acpi.thermal.tz0._PSV: 3627 > hw.acpi.thermal.tz0._CRT: 3662 They are valid, yes. > If I understood the ACPI spec correctly, _PSV is the temperature where > passive cooling actions begin, and _CRT is the critical temp, where the OS > should initiate a shutdown. First, _PSV seems to be way to high, and > second, they are so close to each other. You are correct. _PSV is not currently implemented by FreeBSD but I hope to do it at some point. Once we have all methods of processor control (cpufreq, Cx, and throttling), we can use them to implement _PSV. In any case, I think the _PSV value is set high because your platform designer expects active cooling to be the most effective and passive, since it slows down performance, is a last resort. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: NULL softc for 0
This should be completely resolved by the commit I just made. Please test. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
acpi_cpu changes complete
I believe this completes the changes to acpi_cpu for 5.2. Please test on SMP boxes and laptops and if you were disabling it before, please re-enable it to test. (To do that, remove debug.acpi.disable from loader.conf). Thanks, Nate -- Forwarded message -- Date: Wed, 26 Nov 2003 11:02:07 -0800 (PST) From: Nate Lawson <[EMAIL PROTECTED]> Modified files: sys/dev/acpica acpi_cpu.c sys/modules/acpi Makefile Log: * Add acpi_pcpu_get_id(idx, *acpi_id, *cpu_id) which fetches the idx'th present CPU with pc_acpi_id equal to *acpi_id. If *acpi_id does not match that processor's pc_acpi_id, return the value for ProcId derived from the MADT in *acpi_id. If pc_acpi_id is 0x, always override it with the value of *acpi_id. Finally, return pc_cpuid in *cpu_id and use that as our primary key. * Use pc_cpuid as our unique key because we know it is valid since MD code set it. The values for ProcId in the ASL and MADT don't match up on some machines (!), forcing us to fall back to ordered probing in that case. * Remove some #ifdef SMP since the refcount doesn't hurt performance and will be needed for dynamic _CST objects. Only one #ifdef SMP (for smp_rendezvous) remains. * Hook up SMP in the compile flags in the Makefile. Tested by: marcel, truckman Approved by:re (scottl) Revision ChangesPath 1.21 +48 -49src/sys/dev/acpica/acpi_cpu.c 1.33 +5 -2 src/sys/modules/acpi/Makefile ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Me too]: rc scripts run double on boot?
On Tue, 25 Nov 2003, Marco Wertejuk wrote: > | Of course, make sure you don't have local changes in /etc/rc.d first. > > Shouldn't these be placed in /usr/local/etc/rc.d Sure. I was just being overly careful since I just suggested someone rm -rf a directory. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel SE7500WV2 not working with ACPI
> acpi0: on motherboard > ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node > 0xc29b4660), AE_NOT_EXIST > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > device_probe_and_attach: acpi0 attach returned 6 This is the source of the problems. When acpi0 fails to attach, everything else is done through the legacy PCI code. The question is, why is it failing? The above-mentioned EC method could indicate the problem is in walking the namespace but we'll have to look at the ASL to be sure. Please send a url to the output of: acpidump -t -d > brooks-Intel.asl Also, build with options ACPI_DEBUG and set these in your loader.conf: debug.acpi.layer="ACPI_ALL_COMPONENTS" debug.acpi.level="ACPI_LV_OPREGION" -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Me too]: rc scripts run double on boot?
On Tue, 25 Nov 2003, it was written: > On Tuesday 25 November 2003 18:35, Nate Lawson wrote: > > With a recent -current, I've noticed double prints for the last few > > rc scripts, like this: > > > > Starting cron. > > Local package initialization:. > > Local package initialization:. > > Additional TCP options:. > > Additional TCP options:. > > > > Anyone else seeing this? > > Yes, since the last buldworld, which was quite a while ago: > # uname -a > FreeBSD kiste.local 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Wed Oct 29 > 20:49:45 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 The suggested fix works for me: rm -rf /etc/rc.d/* mergemaster Of course, make sure you don't have local changes in /etc/rc.d first. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rc scripts run double on boot?
With a recent -current, I've noticed double prints for the last few rc scripts, like this: Starting cron. Local package initialization:. Local package initialization:. Additional TCP options:. Additional TCP options:. Anyone else seeing this? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > > > Trace 1: > > wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 > > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 > > AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c > > AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at > > AcpiUtReleaseToCache+0x8c > > > > Trace 2: > > _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96 > > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8 > > AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c > > AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at > > AcpiUtAcquireFromCache+0x53 > > > > Both of these show that acpi_task_thread is calling a task and then > > AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't > > handle the acpi interrupt being moved to irq 20. Please try this > > (untested) patch that should disable moving the SCI to irq 20. > > As I mentioned a minute ago, the patch didn't help. But I grabbed > another stack trace while I was at it. This one is quite different > from the others. I don't think it's different because of your > patch, though. I saw one like this earlier, but thought it might > have been an anomaly caused by my own mucking around in DDB. > > siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec > siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35 > intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at > intr_execute_handlers+0xc8 > lapic_handle_intr(34) at lapic_handle_intr+0x3a > Xapic_isr1() at Xapic_isr1+0x33 > --- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc --- > critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a > _mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at > _mtx_unlock_spin_flags+0x9d > ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e > fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 --- Someone more familiar with ithread_loop should probably answer this. One workaround might be to enable ACPI_NO_SEMAPHORES on your box. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> >
> > Please also send the output of acpidump -t -d > jdp-P2.asl
>
> When I try to run that command, I get:
>
> acpidump: sysctl machdep.acpi_root does not point to RSDP
>
> The sysctl command shows that machdep.acpi_root is 0.
> Remember, though, in order to boot it I had to disable ACPI in
> /boot/loader.conf.
Yes, I see. You could use an older kernel like the 5.1R cd.
> > If you can break to the debugger after it has hung, a tr would be nice.
>
> The fact that it didn't occur to me to try that says a lot about how
> long I've been away from -current. :-( I've attached traces from
> two different boots. They seem to vary somewhat. I can supply line
> numbers on request.
Trace 1:
wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8
AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c
AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at
AcpiUtReleaseToCache+0x8c
Trace 2:
_mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8
AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c
AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at
AcpiUtAcquireFromCache+0x53
Both of these show that acpi_task_thread is calling a task and then
AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't
handle the acpi interrupt being moved to irq 20. Please try this
(untested) patch that should disable moving the SCI to irq 20. jhb can
probably address this better than I.
-Nate
Index: /sys/i386/acpica/madt.c
===
RCS file: /home/ncvs/src/sys/i386/acpica/madt.c,v
retrieving revision 1.7
diff -u -r1.7 madt.c
--- /sys/i386/acpica/madt.c 14 Nov 2003 22:26:29 - 1.7
+++ /sys/i386/acpica/madt.c 24 Nov 2003 21:51:02 -
@@ -538,11 +538,13 @@
}
if (intr->Source != intr->GlobalSystemInterrupt) {
+#if 0
/* XXX: This assumes that the SCI uses IRQ 9. */
if (intr->GlobalSystemInterrupt > 15 && intr->Source == 9)
acpi_OverrideInterruptLevel(
intr->GlobalSystemInterrupt);
else
+#endif
ioapic_remap_vector(new_ioapic, new_pin, intr->Source);
if (madt_find_interrupt(intr->Source, &old_ioapic,
&old_pin) != 0)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Polstra writes: > >On 24-Nov-2003 Nate Lawson wrote: > >> It's a long shot, but what about setting kern.timecounter.hardware to > >> i8254. It appears your ACPI timer is bad. The reason why I suggest this > >> is that it seems like interrupts are being lost. > > > >I put kern.timecounter.hardware="i8254" into /boot/loader.conf, but > >it didn't make any difference. Are you sure it even works from > >loader.conf? From the sources it looks like this is a sysctl rather > >than a tunable. I could change it to a tunable, though, if you > >think it's worthwhile. > > It would be rather complicated to make it a tunable. Far easier to > go into the ACPI timecounter and just give it a negative quality, > that will disable it. > > I'm not sure why Nate think this will change anything with respect > to interrupts, but I pressume he knows what he's talking about. Some ACPI timecounters on old systems would hang on a read from the register and so moving to i8254 would help if it was being used. But farther down, I see that he was already using TSC so it won't make a difference. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IRQ problem with VAIO laptop again
> uhci2: port 0x1840-0x185f > at device 29.2 on pci0 > pcib0: _PRS resource entry has unsupported type 0 > uhci2: Could not allocate irq > device_probe_and_attach: uhci2 attach returned 6 >This one loses the memory-stick slot > pcib1: at device 30.0 on pci0 > pci2: on pcib1 > pcib1: _PRS resource entry has unsupported type 0 > pcib1: slot 8 INTA is routed to irq 9 > fwohci0: mem > 0xe020-0xe0203fff,0xe0205000-0xe02057ff at device 2.0 on pci2 > pcib1: _PRS resource entry has unsupported type 0 > fwohci0: Could not allocate irq > device_probe_and_attach: fwohci0 attach returned 6 >> This one loses firewire The problem is that your _PRS values are incorrect. Actually, I think jhb committed some code to deal with extended irq resources. Send me the output of acpidump -t -d > pete-SonyVaio.asl Also, does booting without ACPI fix things? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > Please add debug.acpi.disable="cpu" to loader.conf or type that in at the > > loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup > > path. > > Thanks. It still hangs even with debug.acpi.disable="cpu". I have > attached the verbose boot messages. They are essentially the same as > the previous messages, except that the acpi_cpu messages are gone now > as expected. > > If there's anything else I should try, just let me know. It's a long shot, but what about setting kern.timecounter.hardware to i8254. It appears your ACPI timer is bad. The reason why I suggest this is that it seems like interrupts are being lost. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > Please add debug.acpi.disable="cpu" to loader.conf or type that in at the > > loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup > > path. > > Thanks. It still hangs even with debug.acpi.disable="cpu". I have > attached the verbose boot messages. They are essentially the same as > the previous messages, except that the acpi_cpu messages are gone now > as expected. Ok, that indicates that it's not the acpi_cpu changes. > If there's anything else I should try, just let me know. Please also send the output of acpidump -t -d > jdp-P2.asl If you can break to the debugger after it has hung, a tr would be nice. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
No way! Good (non-386) equipment is never to old. :) Please add debug.acpi.disable="cpu" to loader.conf or type that in at the loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup path. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Sat, 22 Nov 2003, Lukas Ertl wrote: > On Fri, 21 Nov 2003, Nate Lawson wrote: > > > Those are what is more interesting. Also, can you send me your sysctl > > hw.acpi.cpu.cx_history after you've used it for a while with the maximum > > cx_lowest setting? > > hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 > hw.acpi.cpu.cx_lowest: 3 > hw.acpi.cpu.cx_history: 0/0 1143097/0 0/0 0/0 > > This is after 1:22h doing things like eMail, web surfing, IRC... Ah, I see the C3 states aren't being used. If you are playing mp3s or have usb enabled in your kernel, they won't be used (because we can't use them when bus mastering transfers are active.) Try making usb a module and not loading it and test this again. I've been working on a change to USB to disable polling for devices when we are attempting to sleep in idle but this may take a while. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: NULL softc for 0
On Sat, 22 Nov 2003, Alex Deiter wrote: > > Sorry to reply to myself. Are you loading acpi as a module and have an > > SMP box? If so, please try this patch, recompile the module, and go > > again: > > i applay this patch, comment device acpi in GENERIC and rebuild kernel. > After reboot it work, does not panic: Apply which patch? The one I posted a while ago? If you cvsup to today's -current, you'll have that and should not use any patches. > Copyright (c) 1992-2003 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 5.1-CURRENT #1: Sat Nov 22 06:01:54 MSK 2003 > [EMAIL PROTECTED]:/home/obj/mnt/devel/ncvs/current/src/sys/GENERIC > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a8. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a80244. Ok, loading as module. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.00GHz (1993.58-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > Features=0xbfebfbff CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 1073676288 (1023 MB) > avail memory = 1033596928 (985 MB) > MPTable: Booting with MP table, not madt? > acpi0: on motherboard > ACPI-1287: *** Error: Method execution failed > [\_SB_.PCI0.SBRG.EC0_._REG] (Node 0xc299a500), AE_NOT_EXIST > pcibios: BIOS version 2.10 > Using $PIR table, 19 entries at 0xc00f3400 > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_cpu0: on acpi0 > acpi_cpu1: on acpi0 > device_probe_and_attach: acpi_cpu1 attach returned 6 > acpi_cpu1: on acpi0 > device_probe_and_attach: acpi_cpu1 attach returned 6 > acpi_cpu1: on acpi0 > device_probe_and_attach: acpi_cpu1 attach returned 6 > acpi_button0: on acpi0 Yes, the code in cvs should not panic but I see your CPUs still do fail to probe. I'll look into addressing that. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: NULL softc for 0
On Sat, 22 Nov 2003, Alex Deiter wrote:
> > Is this an SMP box? If so, please do:
>
> This Intel® Server Board SE7501BR2 with one CPU and enabled Hyper-Threading.
>
> > x/xl cpu_softc
> > x/xl cpu_softc+4
> > x/xl cpu_softc+8
>
> panic: NULL softc for 0
> cpuid = 0;
> Debugger("panic")
> Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
> db> x/xl cpu_softc
> cpu_softc: 0
> db> x/xl cpu_softc+4
> cpu_softc+0x4: c68e8a00
> db> x/xl cpu_softc+8
> cpu_softc+0x8: 0
> db>
>
> > And send me the output of
> > acpidump -t -d > tiamat-MachineType.asl
>
> ok.
John, I've identified the problem. Here is his MADT:
Type=Local APIC
ACPI CPU=0
APIC ID=0
Type=Local APIC
ACPI CPU=1
APIC ID=1
Type=Local APIC
ACPI CPU=2
APIC ID=0
Type=Local APIC
ACPI CPU=3
APIC ID=0
And here are his Processor objects:
Scope (\_PR)
{
Processor (CPU1, 0x01, 0x0410, 0x06) {}
Processor (CPU2, 0x02, 0x0410, 0x06) {}
Processor (CPU3, 0x06, 0x0410, 0x06) {}
Processor (CPU4, 0x07, 0x0410, 0x06) {}
}
So all the ACPI CPU ids don't match between the MADT and the Processor
object. I'm not sure what to do to solve this.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: NULL softc for 0
On Sat, 22 Nov 2003, Alex Deiter wrote:
> > Is this an SMP box? If so, please do:
>
> This Intel® Server Board SE7501BR2 with one CPU and enabled Hyper-Threading.
>
> > x/xl cpu_softc
> > x/xl cpu_softc+4
> > x/xl cpu_softc+8
>
> panic: NULL softc for 0
> cpuid = 0;
> Debugger("panic")
> Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
> db> x/xl cpu_softc
> cpu_softc: 0
> db> x/xl cpu_softc+4
> cpu_softc+0x4: c68e8a00
> db> x/xl cpu_softc+8
> cpu_softc+0x8: 0
> db>
Ok, please also do:
x/xl cpu_softc+24
x/xl cpu_softc+28
Did you compile acpi as a module?
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
> > On Tue, 18 Nov 2003, Lukas Ertl wrote: > > > I'm gonna try some "buildkernelstones" with the different settings. If > > > you have some special benchmarks in mind I'd be happy to run them. > > > > That's probably ok. It has a lot of IO. > > Now I've tried running make buildkernel and tarring /usr/src to a > different location, with different setting for hw.acpi.cpu.cx_lowest. I > couldn't see any real difference - neither in performance nor in heat > emission. Well, heat emission will be high during benchmarks because the CPU is rarely idle. My fan always comes on my laptop during buildworld. But the difference is when it's mostly idle (checking email, web browsing). With machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting there. With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the box is still warm. With cx_lowest=2 (C3, 120 us transition time), the box is very cool but some IO gets a little slower (serial port). But not much. So there are actually two things to test for each setting: temperature when mostly idle/low use and performance loss for IO latency benchmarks. Those are what is more interesting. Also, can you send me your sysctl hw.acpi.cpu.cx_history after you've used it for a while with the maximum cx_lowest setting? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: NULL softc for 0
Sorry to reply to myself. Are you loading acpi as a module and have an
SMP box? If so, please try this patch, recompile the module, and go
again:
retrieving revision 1.32
diff -u -r1.32 Makefile
--- Makefile15 Nov 2003 19:26:06 - 1.32
+++ Makefile21 Nov 2003 21:37:41 -
@@ -44,11 +44,14 @@
SRCS+= OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
SRCS+= opt_acpi.h opt_bus.h opt_ddb.h
SRCS+= device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+.if ACPI_MAX_THREADS
+CFLAGS+=-DACPI_MAX_THREADS=${ACPI_MAX_THREADS}
+.endif
.if ACPI_NO_SEMAPHORES
CFLAGS+=-DACPI_NO_SEMAPHORES
.endif
-.if ACPI_MAX_THREADS
-CFLAGS+=-DACPI_MAX_THREADS=${ACPI_MAX_THREADS}
+.if SMP
+CFLAGS+=-DSMP
.endif
# Debugging support
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: NULL softc for 0
Is this an SMP box? If so, please do: x/xl cpu_softc x/xl cpu_softc+4 x/xl cpu_softc+8 And send me the output of acpidump -t -d > tiamat-MachineType.asl -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spin lock sched lock held by 0xc25a8640 for > 5 seconds
Since both of these happen in irq handlers, you might want to look at the new random entropy gathering use of locking. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
grub on -current?
Is anyone using this successfully? I had to install it from Linux. The grub.conf below works when installed by the Linux grub-install but FreeBSD's port always fails with the below messages. Package: grub-0.92 The other problem is I think grub cannot boot UFS2 partitions so I'm using UFS1. laptop# grub-install /dev/ad0 /dev/ad0 does not have any corresponding BIOS drive. laptop# grub-install '(hd0)' /dev/ad0s4a does not have any corresponding BIOS drive. laptop# cat /boot/grub/grub.conf default 0 timeout 10 title Windows root (hd0,0) makeactive chainloader +1 title FreeBSD root (hd0,3,a) kernel /boot/loader title Linux kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 Thanks, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu
On Wed, 19 Nov 2003, Eric Anderson wrote: > Nate Lawson wrote: > >You should run a benchmark with different values for > >hw.acpi.cpu.current_speed to be sure the throttling control still works > >ok. I left it mostly intact so you shouldn't see any problems but it's > >still good to test. As you change it, you should see dmesg output of > >"acpi_cpu0: set speed to xx%" > > I can change the hw.acpi.cpu.economy_speed value, but the current_speed > is read only. When I set economy speed, it automatically bumps the > current speed down to my economy value (as expected). However, no dmesg > output. The only note I see is when going from AC to battery, I get: > kernel: system power profile changed to 'economy' > and of course going back to aAC shows 'performance' instead of economy. > I never see any "set speed to xx%". That is correct behavior. The printf is either under bootverbose or an ACPI debugging print so you won't see it normally. > >You should set hw.acpi.cpu.cx_lowest to 1 regularly and 2 or 3 if you're > >using battery. This will save on heat. I'd also be interested in if > >you'd set it to 3 while on battery and run a typical workload for an hour > >and then send me the result of sysctl hw.acpi.cpu. The cx_history value > >helps me know if my scheduler is accurate. > > I'll try this tomorrow - anyway to get it to automatically set it to a > value when going in to economy mode? Not yet, but working on a generalized way to program a variety of settings for economy/performance mode based on devd. > On a side note - can I do anything with the "lid control switch" acpi > piece? I'd like to make it turn off the screen and go into a sleep > mode (it goes into sleep, but the screen stays lit up). ACPI events now are accessible through devd. So if you look at /etc/*mumble*/devd.conf, you can see an example for getting the lid switch state. However, the more direct way to do this is via sysctl hw.acpi.lid_switch_state=S3 (or whatever state you want the laptop to go into when you close the lid). Please test the desired state manually with acpiconf before enabling it by default. Much of our suspend/resume support is still incomplete. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Harald Schmalzbauer wrote: > On Wednesday 19 November 2003 16:31, Nate Lawson wrote: > > Ok, here's the final patch. I believe it fixes both problems. > > > *SCHNIP* > > Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure > to have the correct one and applied your patch. > > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 27743/0 > > No Problems at booting/rebooting Thanks, I'll commit it now. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Robert Watson wrote: > On Wed, 19 Nov 2003, Nate Lawson wrote: > > On Wed, 19 Nov 2003, Robert Watson wrote: > > > Success! The system rebooted without panicking. It even came back up > > > cleanly. :-) > > > > Good to hear. I think Don has the same problem as Harald so perhaps he > > can report on the patch. > > > > > In an earlier e-mail, you asked me for dmesg output. I've attached it on > > > the off chance you still want it. > > > > Looks great! sysctl hw.acpi.cpu? > > crash2:~> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 2902705/0 Ok, this is correct. Hopefully SMP boxes in the future will have multiple P_BLKs and/or _CST and we can have better power savings. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Robert Watson wrote: > On Wed, 19 Nov 2003, Nate Lawson wrote: > > > Ok, here's the final patch. I believe it fixes both problems. > > Success! The system rebooted without panicking. It even came back up > cleanly. :-) Good to hear. I think Don has the same problem as Harald so perhaps he can report on the patch. > In an earlier e-mail, you asked me for dmesg output. I've attached it on > the off chance you still want it. Looks great! sysctl hw.acpi.cpu? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
Ok, here's the final patch. I believe it fixes both problems.
* Add a DEVMETHOD for acpi so that child detach methods get called. Add
an acpi_cpu method for both detach and shutdown that disables entry to
acpi_cpu_idle and then IPIs/waits for threads to exit. This fixes a panic
late in reboot in the SMP case.
* In the !SMP case, don't use the processor id filled out by the MADT
since there can only be one processor. This was causing a panic in
acpi_cpu_idle if the id was 1 since the data was being dereferenced from
cpu_softc[1] even though the actual data was in cpu_softc[0] (which is
correct).
* Rework the initialization functions so that cpu_idle_hook is written
late in the boot process.
* Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables.
This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes
are known at this time.
* Always allocate the C1 state, even if the P_BLK is invalid. This means
we will always take over idling if enabled. Remove the value -1 as valid
for cx_lowest since this is redundant with machdep.cpu_idle_hlt.
* Reduce locking for the throttle initialization case to around the write
to the smi_cmd port. Add disabled code to write the CST_CNT. It will be
enabled once _CST re-evaluation is tested (post 5.2R).
Thank you: dfr, imp, jhb, marcel, peter
-Nate
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 19 Nov 2003 15:21:07 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -30,20 +30,21 @@
#include "opt_acpi.h"
#include
-#include
-#include
#include
+#include
+#include
#include
+#include
#include
-#include
#include
#include
+#include
#include
-#include
#ifdef __ia64__
#include
#endif
+#include
#include "acpi.h"
#include
@@ -77,9 +78,11 @@
device_tcpu_dev;
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
+uint32_tcpu_p_blk; /* ACPI P_BLK location */
+uint32_tcpu_p_blk_len; /* P_BLK length (must be 6). */
struct resource*cpu_p_cnt; /* Throttling control register */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
+int cpu_cx_count; /* Number of valid Cx states. */
};
#define CPU_GET_REG(reg, width)\
@@ -116,10 +119,9 @@
#define PCI_REVISION_4M3
/* Platform hardware resource information. */
-static uint32_t cpu_p_blk; /* ACPI P_BLK location */
-static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
static uint8_t cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */
static uint32_t cpu_rid; /* Driver-wide resource id. */
static uint32_t cpu_quirks;/* Indicate any hardware bugs. */
@@ -128,6 +130,9 @@
static uint32_t cpu_cx_next; /* State to use for next sleep. */
static uint32_t cpu_non_c3;/* Index of lowest non-C3 state. */
static struct acpi_cx_stats cpu_cx_stats[MAX_CX_STATES];
+#ifdef SMP
+static int cpu_idle_busy; /* Count of CPUs in acpi_cpu_idle. */
+#endif
/* Values for sysctl. */
static uint32_t cpu_current_state;
@@ -146,11 +151,13 @@
static int acpi_cpu_probe(device_t dev);
static int acpi_cpu_attach(device_t dev);
+static int acpi_cpu_detach(device_t dev);
static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static voidacpi_cpu_startup(void *arg);
static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
static voidacpi_cpu_throttle_set(uint32_t speed);
static voidacpi_cpu_idle(void);
static voidacpi_cpu_c1(void);
@@ -166,6 +173,8 @@
/* Device interface */
DEVMETHOD(device_probe,acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
+DEVMETHOD(device_shutdown, acpi_cpu_detach),
{0, 0}
};
@@ -178,6 +187,7 @@
static devclass_t acpi_cpu_devclass;
DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
static int
acpi_cpu_probe(devic
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tue, 18 Nov 2003, Eric Anderson wrote: > Nate Lawson wrote: > >cvsup to -current as of today would be a good first start. The code was > >committed Nov 15. Then boot with acpi enabled and post the output of > >sysctl hw.acpi.cpu. You can try different levels by doing sysctl > >hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) > > > Thanks! I've rebuilt and am happy to say that nothing is hosed and I > booted successfully :) > > Here's my sysctl output: > $ sysctl hw.acpi.cpu > hw.acpi.cpu.max_speed: 8 > hw.acpi.cpu.current_speed: 4 > hw.acpi.cpu.performance_speed: 8 > hw.acpi.cpu.economy_speed: 4 You should run a benchmark with different values for hw.acpi.cpu.current_speed to be sure the throttling control still works ok. I left it mostly intact so you shouldn't see any problems but it's still good to test. As you change it, you should see dmesg output of "acpi_cpu0: set speed to xx%" > hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 > > I played with the different levels a bit, and can't tell much difference > in them. Let me know what else I can try to break with this. Just for > the info, I booted with a/c plugged in, but did the sysctl running on > battery. You should set hw.acpi.cpu.cx_lowest to 1 regularly and 2 or 3 if you're using battery. This will save on heat. I'd also be interested in if you'd set it to 3 while on battery and run a typical workload for an hour and then send me the result of sysctl hw.acpi.cpu. The cx_history value helps me know if my scheduler is accurate. > Eric AndersonSystems Administrator Centaur Technology Say hi to Tom Crispin for me. :) -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tue, 18 Nov 2003, Eric Anderson wrote: > >And here is what you requested in your first patch: > > > >cale:~> sysctl hw.acpi.cpu > >hw.acpi.cpu.cx_supported: C1/0 > >hw.acpi.cpu.cx_lowest: 0 > >hw.acpi.cpu.cx_history: 0/0 > > Ok - what do I need to do to try this new acpi stuff out? I'm running > -current as of Nov 14th, and I'd like to help debug/test this on my > notebook.. cvsup to -current as of today would be a good first start. The code was committed Nov 15. Then boot with acpi enabled and post the output of sysctl hw.acpi.cpu. You can try different levels by doing sysctl hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Don Lewis wrote: > On 18 Nov, Lukas Ertl wrote: > > On Tue, 18 Nov 2003, Nate Lawson wrote: > > >> This excerpt from truckman@'s asl shows that 4 Cx states are only > >> available when the AC adapter is not attached. (The C*NA memory addresses > >> appear to be managed by the BIOS and not the AML but the PSR access is > >> clear). > > > > This part of the ASL looks the one here - let me guess, is it a ThinkPad? > > :-) > > Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode > when I run "shutdown -p". That's an old problem that Linux is also trying to work around. It appears to be buggy hw. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Robert Watson wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Could you add a printf to the start of acpi_cpu_detach()? I want to see
> > if we're being called before or after ACPI is stopped ("Shutting down
>
> So indeed, it doesn't look like the ACPI detach call has gone out yet.
Yes, I'm certain acpi_cpu_detach is not being called before
AcpiTerminate(). Can someone with some newbus knowledge explain this?
devinfo shows acpi_cpu0 as a child of acpi0 so its detach should be called
before acpi0's. Perhaps the fact that there is no DEVMETHOD for
acpi_detach means that its children never have their detach methods
called?
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote: > On Tue, 18 Nov 2003, Nate Lawson wrote: > > Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is > > available). I'm interested in any benchmark results, especially IO. I'm > > hoping the scheduling of sleeps is good enough that you don't experience > > much performance loss even with lower sleeps. > > I'm gonna try some "buildkernelstones" with the different settings. If > you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. > > This excerpt from truckman@'s asl shows that 4 Cx states are only > > available when the AC adapter is not attached. (The C*NA memory addresses > > appear to be managed by the BIOS and not the AML but the PSR access is > > clear). > > This part of the ASL looks the one here - let me guess, is it a ThinkPad? > :-) Yes, R40. I'm scared because I'm beginning to recognize chipsets by their ASL organization. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Robert Watson wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
>
> > Below you'll find the update patch for acpi_cpu. Please test this,
> > especially for SMP and laptops with _CST objects in their ASL.
> ...
> > Notes:
> > * Add a detach method that disables entry to acpi_cpu_idle and in the SMP
> > case, IPIs all processors to exit sleeping. This fixes a panic on
> > shutdown for MP boxes.
>
> Sigh, I appear to have been mistaken about the SMP reboot problem being
> fixed, sorry about that. Mark's random_harvest panic appears to have
> caused me to miss the other failure mode in my last test. Stack trace
> attached, and I believe I'm running with your latest patch.
Could you add a printf to the start of acpi_cpu_detach()? I want to see
if we're being called before or after ACPI is stopped ("Shutting down
ACPI"). Also, please do:
l *AcpiGetRegister+0x61
I think it's the call to get the bus master status, which is interesting
since this means that cpu_cx_count != 0 which means that acpi_cpu_detach
hasn't run yet.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Below you'll find the update patch for acpi_cpu. Please test this,
> > especially for SMP and laptops with _CST objects in their ASL.
>
> Looks good here on a Centrino based laptop, which has a _CST method in
> its ASL:
>
> acpi_cpu0: on acpi0
> acpi_cpu0: C2 state 1 lat
> acpi_cpu0: C3 state 85 lat
I'll be moving some printfs under bootverbose before release.
> hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
> hw.acpi.cpu.cx_lowest: 0
> hw.acpi.cpu.cx_history: 86231/0 0/0 0/0
Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
available). I'm interested in any benchmark results, especially IO. I'm
hoping the scheduling of sleeps is good enough that you don't experience
much performance loss even with lower sleeps.
> Although it seems I have lost a C3 state (before, I had an additional
> C3/185).
_CST can change dynamically at runtime. If you booted with the AC adapter
attached, your laptop may not offer all the sleep states. When you unplug
the AC adapter, we get a notify on _CST to re-evaluate it and look for new
states. However, that code is currently disabled due to complex locking
issues (i.e. what to do when a Cx state is being accessed but _CST is
being re-evaluated). _CST re-evaluation won't be enabled until after
5.2R. However, you can reboot your laptop with the AC adapter detached
(or attached) to see what states are available.
This excerpt from truckman@'s asl shows that 4 Cx states are only
available when the AC adapter is not attached. (The C*NA memory addresses
appear to be managed by the BIOS and not the AML but the PSR access is
clear).
Method (_CST, 0, NotSerialized)
{
If (\C2NA)
{
Return (CST1)
}
If (\C3NA)
{
Return (CST2)
}
If (\_SB.PCI0.LPC.EC.AC._PSR ())
{
Return (CST3)
}
If (\C4NA)
{
Return (CST3)
}
Return (CST4)
}
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EISA Adaptec 274X SCSI panic (ISRng related)
On Tue, 18 Nov 2003, Andy Farkas wrote: > My EISA AHA2740's don't work no more :( > > # grep ahc /var/run/dmesg.boot > ahc0: at 0x2c00-0x2cff, irq 10 (level) > ahc0: on eisa0 slot 2 > ahc1: at 0x4c00-0x4cff, irq 11 (level) > ahc1: on eisa0 slot 4 > ahc2: port 0xf800-0xf8ff mem > 0xf68fb000-0xf68fbfff irq 17 at device 11.0 on pci1 > ahc2: Using left over BIOS settings > ahc3: port 0xf400-0xf4ff mem > 0xf68fa000-0xf68fafff irq 18 at device 12.0 on pci1 > ahc3: Using left over BIOS settings > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code= supervisor write, page not present > instruction pointer = 0x8:0xc0649083 > stack pointer = 0x10:0xd763ac5c > frame pointer = 0x10:0xd763ac84 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 14 (idle: cpu0) > kernel: type 12 trap, code=0 > Stopped at intr_execute_handlers+0x23: lock addl %eax,0(%edx) > db> tr > intr_execute_handlers(c06d5084,d763ac9c,d763ace0,c065bbae,7) at > intr_execute_handlers+0x23 > atpic_handle_intr(7) at atpic_handle_intr+0x42 > Xatpic_intr7() at Xatpic_intr7+0x1e > --- interrupt, eip = 0xc064d655, esp = 0xd763ace0, ebp = 0xd763ace0 --- This is almost certainly addressed by jhb's atpic patch. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Updated acpi_cpu patch
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
Thanks,
Nate
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a panic on
shutdown for MP boxes.
* Rework the initialization functions so that cpu_idle_hook is written
late in the boot process. This fixes a panic on boot where acpi_cpu_idle
was called before the cpu_cx_states entry was filled out.
* Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables.
This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes
are known at this time.
* Always allocate the C1 state, even if the P_BLK is invalid. This means
we will always take over idling if enabled. Remove the value -1 as valid
for cx_lowest since this is redundant with machdep.cpu_idle_hlt.
* Reduce locking for the throttle initialization case to around the write
to the smi_cmd port.
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 18 Nov 2003 17:46:23 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -77,9 +77,11 @@
device_tcpu_dev;
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
+uint32_tcpu_p_blk; /* ACPI P_BLK location */
+uint32_tcpu_p_blk_len; /* P_BLK length (must be 6). */
struct resource*cpu_p_cnt; /* Throttling control register */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
+int cpu_cx_count; /* Number of valid Cx states. */
};
#define CPU_GET_REG(reg, width)\
@@ -116,10 +118,9 @@
#define PCI_REVISION_4M3
/* Platform hardware resource information. */
-static uint32_t cpu_p_blk; /* ACPI P_BLK location */
-static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
static uint8_t cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */
static uint32_t cpu_rid; /* Driver-wide resource id. */
static uint32_t cpu_quirks;/* Indicate any hardware bugs. */
@@ -146,11 +147,13 @@
static int acpi_cpu_probe(device_t dev);
static int acpi_cpu_attach(device_t dev);
+static int acpi_cpu_detach(device_t dev);
static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static voidacpi_cpu_startup(void *arg);
static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
static voidacpi_cpu_throttle_set(uint32_t speed);
static voidacpi_cpu_idle(void);
static voidacpi_cpu_c1(void);
@@ -166,6 +169,7 @@
/* Device interface */
DEVMETHOD(device_probe,acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
{0, 0}
};
@@ -178,6 +182,7 @@
static devclass_t acpi_cpu_devclass;
DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
static int
acpi_cpu_probe(device_t dev)
{
@@ -272,11 +277,10 @@
AcpiEvaluateObject(sc->cpu_handle, "_INI", NULL, NULL);
/* Get various global values from the Processor object. */
-cpu_p_blk = pobj.Processor.PblkAddress;
-cpu_p_blk_len = pobj.Processor.PblkLength;
+sc->cpu_p_blk = pobj.Processor.PblkAddress;
+sc->cpu_p_blk_len = pobj.Processor.PblkLength;
ACPI_DEBUG_PRINT((ACPI_DB_IO, "acpi_cpu%d: P_BLK at %#x/%d%s\n",
-device_get_unit(dev), cpu_p_blk, cpu_p_blk_len,
-sc->cpu_p_cnt ? "" : " (shadowed)"));
+device_get_unit(dev), sc->cpu_p_blk, sc->cpu_p_blk_len));
acpi_sc = acpi_device_get_parent_softc(dev);
sysctl_ctx_init(&acpi_cpu_sysctl_ctx);
@@ -297,7 +301,8 @@
if (thr_ret == 0 || cx_ret == 0) {
status = AcpiInstallNotifyHandler(sc->cpu_handle, ACPI_DEVICE_NOTIFY,
acpi_cpu_notify, sc);
- AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, sc);
+ if (device_get_unit(dev) == 0)
+ AcpiOsQueueForExecution(OSD_PRIOR
Re: Two panics for the price of one: acpi_cpu_idle *and* turnstiles
Thanks for the info. His analysis is correct. I'll add a detach method that disables sleeping during shutdown. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
> On Sunday 16 November 2003 21:11, Nate Lawson wrote:
> > The panic you see is a result of the new acpi_cpu driver, not ULE. In any
> > case, it appears that acpi_cpu_idle is being called and trying to read one
> > of the processor control registers before they are present. Please send
> > me privately the output of:
> >acpidump -t -d > harald-MachineType.asl
> >
> > As a workaround, please set this in loader.conf:
> >debug.acpi.disable="cpu"
> >
> > That will allow you to get running and give me some time to look into
> > this.
>
> Now I followed your advise and found out the following (source from some hours
> ago, 4BSD scheduler, and the acpidump went away to you by private mail)
> The panic only occurs if the nvidia.ko module is was loaded.
> I use it straight from the ports.
> But your sysctl tweak keeps the whole thing working (I'm writing with kmail)!
Please try the patch below. It does more than fix your problem but the
other changes will be needed eventually anyways. If your system boots ok,
please send me the output of sysctl hw.acpi.cpu
Also, be sure to comment out the disable CPU line in loader.conf while
testing the patch.
Thanks,
Nate
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 17 Nov 2003 17:39:54 -
@@ -78,8 +78,8 @@
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
struct resource*cpu_p_cnt; /* Throttling control register */
+int cpu_cx_count; /* Number of valid Cx states. */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
};
#define CPU_GET_REG(reg, width)\
@@ -151,6 +151,7 @@
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static voidacpi_cpu_startup(void *arg);
static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
static voidacpi_cpu_throttle_set(uint32_t speed);
static voidacpi_cpu_idle(void);
static voidacpi_cpu_c1(void);
@@ -406,8 +407,7 @@
{
ACPI_GENERIC_ADDRESS gas;
struct acpi_cx *cx_ptr;
-struct sbuf sb;
-int i, error;
+int error;
/* Bus mastering arbitration control is needed for C3. */
if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) {
@@ -420,11 +420,9 @@
* First, check for the ACPI 2.0 _CST sleep states object.
* If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3.
*/
-cpu_cx_count = 0;
+sc->cpu_cx_count = 0;
error = acpi_cpu_cx_cst(sc);
if (error != 0) {
- if (cpu_p_blk_len != 6)
- return (ENXIO);
cx_ptr = sc->cpu_cx_states;
/* C1 has been required since just after ACPI 1.0 */
@@ -432,7 +430,10 @@
cx_ptr->trans_lat = 0;
cpu_non_c3 = 0;
cx_ptr++;
- cpu_cx_count++;
+ sc->cpu_cx_count++;
+
+ if (cpu_p_blk_len != 6)
+ goto done;
/* Validate and allocate resources for C2 (P_LVL2). */
gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
@@ -446,7 +447,7 @@
cx_ptr->trans_lat = AcpiGbl_FADT->Plvl2Lat;
cpu_non_c3 = 1;
cx_ptr++;
- cpu_cx_count++;
+ sc->cpu_cx_count++;
}
}
@@ -461,40 +462,16 @@
cx_ptr->type = ACPI_STATE_C3;
cx_ptr->trans_lat = AcpiGbl_FADT->Plvl3Lat;
cx_ptr++;
- cpu_cx_count++;
+ sc->cpu_cx_count++;
}
}
}
+done:
/* If no valid registers were found, don't attach. */
-if (cpu_cx_count == 0)
+if (sc->cpu_cx_count == 0)
return (ENXIO);
-sbuf_new(&sb, cpu_cx_supported, sizeof(cpu_cx_supported), SBUF_FIXEDLEN);
-for (i = 0; i < cpu_cx_count; i++) {
- sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
- sc->cpu_cx_states[i].trans_lat);
-}
-sbuf_trim(&sb);
-sbuf_finish(&sb);
-SYSCTL_ADD_STRING(&acpi_cpu_sysctl_ctx,
- SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
- OID_AUTO, "cx_supported", CTLFLAG_RD, cpu_cx_supported,
- 0, "Cx/microsecond values for supported Cx states");
-SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx,
- SYSCTL_CHILDREN(acpi_c
Re: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 src/sys/conf files src/sys/modules/acpi Makefile
On Sun, 16 Nov 2003, Lukas Ertl wrote: > On Sat, 15 Nov 2003, Nate Lawson wrote: > > > Please test this to be sure that it boots ok on your machine, especially > > SMP boxes. Throttling should still work ok also. > > Seems to work here: > > hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 173839/0 0/0 0/0 0/0 > > I've no idea if it actually has an effect. Yes, it is working fine for you. Those states look like a Centrino. (I've gotten familiar with how different chipsets look). In any case, the default is to just use C1 which is the same as previous behavior. To get better power savings, set cx_lowest to 1, 2, or 3. The counters in the appropriate slots will go up in cx_history. From your latencies, you should be fine with a value of 1 and see a slight performance loss for 2 or 3 (but very small). I'd be interested in any testing results you find for each of those values (in terms of power and performance). -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
The panic you see is a result of the new acpi_cpu driver, not ULE. In any case, it appears that acpi_cpu_idle is being called and trying to read one of the processor control registers before they are present. Please send me privately the output of: acpidump -t -d > harald-MachineType.asl As a workaround, please set this in loader.conf: debug.acpi.disable="cpu" That will allow you to get running and give me some time to look into this. Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 src/sys/conf files src/sys/modules/acpi Makefile
The default value of this driver is to use C1 (HLT), which is equivalent to previous behavior. To use lower idle states, set hw.acpi.cpu.cx_lowest to the index of the desired state. See sysctl hw.acpi.cpu output to get an idea of the values. Here is the result on my IBM T23: hw.acpi.cpu.cx_supported: C1/0 C2/84 C3/120 hw.acpi.cpu.cx_lowest: 2 hw.acpi.cpu.cx_history: 1996/0 0/0 43011/82 This means I have 3 idle states. C1 = HLT (at index 0). The lowest is C3 (index 2). The cx_history is a summary of long/short sleeps for each supported state. The lower idle states use less power but also add more latency so you will probably see some decrease in IO benchmarks if you enable them. Please test this to be sure that it boots ok on your machine, especially SMP boxes. Throttling should still work ok also. Thanks, Nate -- Forwarded message -- Date: Sat, 15 Nov 2003 11:26:41 -0800 (PST) njl 2003/11/15 11:26:06 PST FreeBSD src repository Modified files: sys/dev/acpica acpi_cpu.c share/man/man4 acpi.4 sys/conf files sys/modules/acpi Makefile Log: Implement Cx CPU idle states and updated throttling support. * Use the cpu_idle_hook() to do idling for C1-C3. * Use both _CST and the FADT to detect Cx states. * Use both _PTC and P_CNT for controlling throttling. * Add a notify handler to detect changes in _CST and _PSS * Call the _INI function for each processor if present. This will be done by ACPI-CA in the future. * Fix a bug on SMP systems where CPUs will attach multiple times if the bus is rescan. * Document new sysctls for controlling idling. Revision ChangesPath 1.17 +25 -7 src/share/man/man4/acpi.4 1.853 +1 -0 src/sys/conf/files 1.19 +784 -162 src/sys/dev/acpica/acpi_cpu.c 1.32 +2 -1 src/sys/modules/acpi/Makefile ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
On Thu, 30 Oct 2003, Jeremy Bingham wrote: > On 29/10/03 18:18 -0800, Nate Lawson wrote: > > I looked at a few other ASL copies I have and you have an old version. > > Have you done a BIOS update recently? > > > > Yours: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d0040b, > > Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d20b07, > > Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d3050f, > > > > Update your BIOS and then do acpidump -t to verify your revision is the > > latest. > > > > -Nate > > Success! I updated my BIOS from A05 to A14, and -CURRENT works > beautifully. I only wish that I had read this email a few hours earlier, > before I got frustrated and decided to give Debian a shot on this > laptop. Linux would probably have had the same problem with your AML since we use the same interpreter. > Happily running FreeBSD again, Glad to hear it. Anyone else having ACPI trouble should please update to their latest BIOS revision before reporting a problem. Thanks, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
On Wed, 1 Oct 2003, Jeremy Bingham wrote:
> > > On 30/09/03 15:04 -0700, Nate Lawson wrote:
> > > > As far as debugging prints, add the following printfs to
> > > > acpi_cmbat_get_bif():
> > > >
> > > > printf("Before getting BIF\n");
> > > > as = AcpiEvaluateObject(h, "_BIF", NULL, &bif_buffer);
> > > > printf("After getting BIF\n");
>
> The second one did not trigger (I had actually been using ACPI_VPRINT
> for a while to get info like that). I have a dump of my ASL here:
> http://home.satanosphere.com/bsd/jeremy.asl.gz. As far as my dmesg goes,
> I can get you one where it boots w/ ACPI disabled, but when it hangs, it
> hangs before / is mounted at all, so I can't really get it. Should I
> boot it again and just type the last lines out?
I looked at a few other ASL copies I have and you have an old version.
Have you done a BIOS update recently?
Yours: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d0040b,
Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d20b07,
Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d3050f,
Update your BIOS and then do acpidump -t to verify your revision is the
latest.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI trouble with EPIA-M
On Mon, 27 Oct 2003, Thorsten Greiner wrote: > * Nate Lawson <[EMAIL PROTECTED]> [2003-10-27 22:13]: > > ... What you probably want to do now is do "tr " for the > > pids below to see what they're blocked on. Likely culprits are 24 > > (since it's on irq 7), 23 (acpi), 29, and 25. The most likely one > > is 24 because irq 7 is normally edge triggered/legacy and that > > means it cannot be shared. But in your config, it is shared. So > > my guess is that acpi is routing interrupts differently than $PIR > > mode. > > OK, here we go: > > pid 24 ([IWAIT] irq7: fwohci0 uhci1) > pid 35 ([IWAIT] irq0: ppc0) ^^ No such irq. As a workaround, try disabling your parallel port drivers (lpt, ppc, plip, ppi, etc.) If things work then with ACPI enabled, we're certain it's the parallel port irq routing. But I'm pretty certain that's the case. Please send me a link to the output of acpidump -t -d > thorsten.asl I'll look at the _PRT entry. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI trouble with EPIA-M
On Fri, 24 Oct 2003, Thorsten Greiner wrote: > * Nate Lawson <[EMAIL PROTECTED]> [2003-10-24 22:57]: > > Type "tr" at the DDB prompt to get a trace of what is hanging. > > At the time of the hang a 'ps' in DDB shows two screenful's of > processes. Doing a simple 'tr' just gives the backtrace of how I got > into DDB which - I presume - is not relevant to this problem. Yes, that's true. What you probably want to do now is do "tr " for the pids below to see what they're blocked on. Likely culprits are 24 (since it's on irq 7), 23 (acpi), 29, and 25. The most likely one is 24 because irq 7 is normally edge triggered/legacy and that means it cannot be shared. But in your config, it is shared. So my guess is that acpi is routing interrupts differently than $PIR mode. > I have no serial console, so I have to copy things by hand. A ps > shows (only selected columns): > > pid ... flag stat ... > 38204 new [IWAIT] irq8: rtc > 37204 new [IWAIT] irq4: sio0 > 36204 new [IWAIT] swi0: tty:sio > 35204 [IWAIT] irq0: ppc0 > 34204 new [IWAIT] irq12: psm0 > 33204 [CPU0] irq1: atkbd0 > 32204 [IWAIT] irq15: ata1 > 31204 [IWAIT] irq14: ata0 > 30204 [SLP]usbdly 0x... usb2 > 29204 new [IWAIT] irq10: uhci2 pcm0 > 28204 [SLP] usbdly 0x... usb1 > 27204 [SLP] usbtsk 0x... usbtask > 26204 [SLP] usbdly 0q... usb0 > 25204 new [IWAIT] irq11: vr0 uhci0 > 24204 [IWAIT] irq7: fwohci0 uhci1 > 8204 [SLP]actask 0x... acpi_task2 > 7204 [SLP]actask 0x... acpi_task1 > 6204 [SLP]actask 0x... acpi_task0 > 23204 new [IWAIT] irq9: acpi0 > 22204 new [IWAIT] irq13: > 21204 new [IWAIT] swi3: cambio > 20204 new [IWAIT] swi2: camnet > 19204 new [IWAIT] swi5:+ > 5204 [SLP]tqthr 0x... taskqueue > 18204 [IWAIT] swi7: acpitaskq > 17204 [IWAIT] swi6:+ > 16204 [IWAIT] swi6: task queue > 15204 [SLP]- 0x... random > 4204 [SLP]- 0x... g_down > 3204 [SLP]- 0x... g_up > 2204 [SLP]- 0x... g_event > 14204 new [IWAIT] swi5: vm > 1320c new [IWAIT] swi8: tty:sio clock > 12204 new [IWAIT] swi1: net > 1120c [Can run] idle > 1200 new [INACTIVE] swapper > 10204 [CV]ktrace 0x... ktrace > 0200 [SLP]conifhk 0x... swapper > > This state seems to be pretty reproducible. Any idea what is wrong? Something is blocked, no idea exactly what without more info. I have an EPIA-M 6000 but it's not set up. Perhaps I'll find some time to boot current on it to see. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Warnings with libstdc++ build
My /etc/make.conf is empty. c++ -pg -O -pipe -mcpu=pentiumpro -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/home/src/gnu/lib/libstdc++ -I/home/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/home/src/gnu/lib/libstdc++/../../../contrib/gcc -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /home/src/contrib/libstdc++/libsupc++/tinfo.cc -o tinfo.po cc1plus: warning: -ffunction-sections disabled; it makes profiling impossible -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng issues status report
On Fri, 10 Oct 2003, Soren Schmidt wrote: > It seems Nate Lawson wrote: > > Here is an updated status of ATAng for me. I periodically test it to see > > if any of the following problems go away. > > > > * Panic occurs after ATAFD fails to probe. Last event: 2003/10/6 > > I have no ATAFD device on my system and normally no messages are printed > > about it on boot. However, periodically ATAFD will print a bunch of > > messages on console about failing to probe. The machine works normally > > but at some point during use, it panics with a re-use of freed memory, > > last user was ATAFD. Most of the time the machine doesn't print anything > > about ATAFD and there is no panic but maybe 1/5 reboots it does. > > This should be fixed in current. Fixed for me. Sometimes acd0 takes a little longer to probe but otherwise I have not been able to recreate the panic now. > > * Resume fails, hanging with drive light on. Last event: 2003/10/2 > > Appears to be a lost interrupt during reset. > > I've just committed some changes that makes suspend/resume work just > fine on the notebooks I have access to. This works great for me! I have suspended/resumed to S3 many times now, no problems. > > * Lost interrupt for ATA-SLAVE on reboot. Last event: 2003/10/7 > > I'm unsure if this is actually a problem but occasionally it prints a > > message right before rebooting about loosing an interrupt. I'll try to > > get more info. > > No idea about that on. It's gone as well. I can't reproduce any more whereas before I could reproduce often. So now I have no problems with ATAng and I can run it on all [EMAIL PROTECTED] panic ;-) Thanks again, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: irq conflict laptop with 5.1-current
What exact date did this problem appear? If recently, I suspect the ep(4) changes. But there are other problems... Can you update the BIOS to a newer version? Please send me a link to the output of: acpidump -t -d > klop-cpq7400.asl These errors mean your AML is buggy: can't fetch resources for \\_SB_.C09B - AE_AML_INVALID_RESOURCE_TYPE can't fetch resources for \\_SB_.C187 - AE_AML_INVALID_RESOURCE_TYPE can't fetch resources for \\_SB_.C188 - AE_AML_INVALID_RESOURCE_TYPE can't fetch resources for \\_SB_.C189 - AE_AML_INVALID_RESOURCE_TYPE can't fetch resources for \\_SB_.C18A - AE_AML_INVALID_RESOURCE_TYPE can't fetch resources for \\_SB_.C18B - AE_AML_INVALID_RESOURCE_TYPE can't fetch resources for \\_SB_.C18C - AE_AML_INVALID_RESOURCE_TYPE pcib0: _CRS resource entry has unsupported type 14 pcib0: _CRS resource entry has unsupported type 14 pcib0: _CRS resource entry has unsupported type 14 pcib1: at device 0.1 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.C000.C013 - AE_NOT_FOUND I have no idea how this could happen: -0255: *** Error: UtCallocate: Could not allocate size 30 ACPI-1287: *** Error: Method execution failed [\\_SB_.C0D7] (Node 0xc18a6ae0), AE_NO_MEMORY ACPI-1287: *** Error: Method execution failed [\\_GPE._L00] (Node 0xc18ab640), AE_NO_MEMORY ACPI-0388: *** Error: AE_NO_MEMORY while evaluating method [_L00] for GPE[ 0] Have you always had those error messages? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI trouble with EPIA-M
> I have a VIA EPIA-M 1 board which works mostly when I disable > ACPI in the bios. Unfortunately the parallel port is controlled by > some Super-IO chip and is not recognized during boot. The same holds > true for serial ports and the floppy controller. > > When I enable ACPI in the bios the machine boots normally and > recognizes the parallel port BUT stops after displaying the hd/cdrom > identification , at the point where it would normally start init > (before the "Mounting root from ..." is displayed). > > At this point it just stops. I can break into DDB but nothing > else... Type "tr" at the DDB prompt to get a trace of what is hanging. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi on fujitsu-siemens
> ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.LNKU._CRS] (Node > 0xc40e49c0), AE_AML_UNINITIALIZED_LOCAL > ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.LNKU._CRS] (Node > 0xc40e49c0), AE_AML_UNINITIALIZED_LOCAL This means your AML is lousy. Try some of the hints on this page: http://www.cpqlinux.com/acpi-howto.html Please also post a link to your ASL, produced by: acpidump -t -d > fujitsu.asl -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2745] ACPI, USB, and the tangled web
On Thu, 16 Oct 2003, Anish Mistry wrote: > -BEGIN PGP SIGNED MESSAGE- Um, that's great. :) > First off, if you've been following my dabbling in fixing the USB resume > problem on my laptop you know that I have been plauged by the infamous > restart on second suspend with a usb device being accessed during the second > suspend (ie. wiggling mouse). Yesterday after finally updating to a current > that boots my system after a couple of weeks without it I suspended the > system and resumed it to check some ACPI issues had been fixed, but that's > for another time. After resume I realized I needed my mouse, so I plugged it > in, dynamically loaded the kernel module and the mouse worked (normal/ > previous). Then I suspend the laptop and was wiggling the mouse while it was > suspending (bad habit from testing) and the system REBOOTED, and my patches > weren't even applied! The problem is USB although ACPI magnifies it. USB devices can generate wake events. In my current testing of a new acpi_cpu driver, I've found that just having the USB bus enabled in the kernel (with no devices attached) causes it to generate a steady stream of bm_sts sets even though the laptop is completely idle. Try disabling usb in your kernel config and see if it helps your laptop not wake up. If that works, we've narrowed it down a little. You can also try setting debug.acpi.avoid to USB_ to try to get it to avoid evaluating that namespace. I'll probably get around to looking at the USB issue at some point. There's a lot of work needed there: suspend/resume for *hci, possibly avoiding setting acpi wake events on usb, etc. > There seems to be some ACPI problem, since I just tested the same procedure > on with ACPI disabled and there was no reboot. How were you able to test that with it disabled? Were you suspending with apm instead? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupt statistics?
On Mon, 13 Oct 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Nate Lawson <[EMAIL PROTECTED]> writes: > : Given that, my biggest concern now is IO corruption. Are there any > : devices that have a low interrupt rate (or bus mastering rate) that cannot > : handle a few hundred us latency added to their handler startup? I'm > : thinking something like a floppy drive where the time between interrupts > : is great enough that cpu_idle() is called but that need to be serviced > : quickly or data is over/underrun. > > sio/uart > > At 115200 baud, you have 173us to service the interrupt when the FIFO > interrupt level is set to HI. At 460800 at HI you have 43us. With > the more conservative MED settings, these numbers are 4 times better > (670us and 173us). 200us is smack dab in the middle of these times. > This is inbound data, so things could be idle and there be issues. > > Not sure about other devices. Ok, I've instrumented the driver and found that most of the time, sleeps are 2-6 ms. Once in a while, they are a few hundred us. Rarely, they are tens of us. I'll test the driver with periodic serial IO to see if there is any data loss. I assume it's ok to tell people who are running high serial port speeds to disable the lowest sleep states. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupt statistics?
On Sun, 12 Oct 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Nate Lawson <[EMAIL PROTECTED]> writes: > : I am very interested in our idle load characteristics. It seems > : most systems I've analyzed have an average idle interrupt rate of about > : 225 per second, dominated by the clk and rtc interrupts as shown below. > : > : clk irq099/sec > : rtc irq8 127/sec > : > : Since these are both clocks, I assume the arrival of their interrupts are > : equally spaced and not correlated to each other. How much latency do the > : handlers for these have? Are there any system processes which generate > : repetitive bursts of very short tasks? If so, how long do those tasks > : take? > > These are clock interrupts. One is used for timing the system (clk), > while the other is used for profiling the system. They are > asynchronous to each other so that the profiling can profile more > effectively. On my systems with higher HZ setting, the clk interrupts > will happen more often, obviously. Yes, I understand. > : The reason why I ask is I'm coming up with a default policy for CPU sleep > : states which can have as high a latency as a few hundred microseconds. On > : an idle system, this should be fine although it does add to the latency > : for the above clock handlers. But I also need to be able to demote > : quickly to short sleep states (e.g., HLT) if the system is becoming active > : to decrease response times. > > The important thig with the time keeping devices is not to loose > interrupts, since that's how we tick out time. On non-idle systems, > there's issues with latency on the ticks, but on idle systems there > wouldn't be. 100us of latency would effecively limit HZ to 5000 or so > (I think that the Nyquist limit would apply, otherwise it is 1). > Some time units have a wrap around that makes 100Hz impossible and > faster rates must be used. > > If you are going into a CPU state that's low, it might make sense to > increase the tick time, but I'm sure phk would have things to say > about that and its wisdom (or lack there of). A better workaround is that I will not allow selecting a state that has a latency >= 1 / (hz / 2). In practice, this would allow a sleep delay of up to 500 us for the faster HZ setting people use of 1000 (1 ms). Even the deepest Cx states are typically less than 200 us although they also disable bus mastering while sleeping. >From other email, it appears that we bounce between idle (with only clock interrupts that can easily handle a few hundred us of latency) and running, where cpu_idle() is not even called. Given that, my biggest concern now is IO corruption. Are there any devices that have a low interrupt rate (or bus mastering rate) that cannot handle a few hundred us latency added to their handler startup? I'm thinking something like a floppy drive where the time between interrupts is great enough that cpu_idle() is called but that need to be serviced quickly or data is over/underrun. Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/sound/pci ich.c
On Mon, 13 Oct 2003, Mark Santcroos wrote: > On Mon, Sep 15, 2003 at 02:16:47PM -0700, Nate Lawson wrote: > > njl 2003/09/15 14:16:47 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/dev/sound/pciich.c > > Log: > > Correctly reset ich[3-5] sound cards on resume. This fixes audio playback > > after suspend/resume for me. > > > > Submitted by: iwasaki > > Reviewed by:orion > > Approved by:cg > > Hi Nate, > > Sorry for the late reply, this breaks resuming from S4BIOS on my Latitude > C640. > > In message <[EMAIL PROTECTED]> to current@ in June I > posted my fix. I just tried to find your message through the web search interface. No such luck. (Speaking of which, the mailing list search interface is HORRIBLE. It only seems to check the first word entered.) > While it was not very clean, it worked: > > # set nambar > pciconf -w -b pci0:31:5 0x11 0xd8 > # set nabmbar: > pciconf -w -b pci0:31:5 0x14 0x81 > pciconf -w -b pci0:31:5 0x15 0xdc > # set pcicmd: > pciconf -w -b pci0:31:5 0x4 0x5 > > I also did the same thing at resume in ich.c, don't have the patch at hand > right now, but you get the idea. > > It would be nice if we could get your changes also to work on my system. It looks like you are resetting the BARs on resume. If that's all that's needed, I believe Warner was working on code to do this in the general case. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Interrupt statistics?
Does anyone have recent statistics for interrupt latency and arrival timings? I am very interested in our idle load characteristics. It seems most systems I've analyzed have an average idle interrupt rate of about 225 per second, dominated by the clk and rtc interrupts as shown below. clk irq099/sec rtc irq8 127/sec Since these are both clocks, I assume the arrival of their interrupts are equally spaced and not correlated to each other. How much latency do the handlers for these have? Are there any system processes which generate repetitive bursts of very short tasks? If so, how long do those tasks take? The reason why I ask is I'm coming up with a default policy for CPU sleep states which can have as high a latency as a few hundred microseconds. On an idle system, this should be fine although it does add to the latency for the above clock handlers. But I also need to be able to demote quickly to short sleep states (e.g., HLT) if the system is becoming active to decrease response times. Thanks for any info, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATAng issues status report
Here is an updated status of ATAng for me. I periodically test it to see if any of the following problems go away. * Panic occurs after ATAFD fails to probe. Last event: 2003/10/6 I have no ATAFD device on my system and normally no messages are printed about it on boot. However, periodically ATAFD will print a bunch of messages on console about failing to probe. The machine works normally but at some point during use, it panics with a re-use of freed memory, last user was ATAFD. Most of the time the machine doesn't print anything about ATAFD and there is no panic but maybe 1/5 reboots it does. * Resume fails, hanging with drive light on. Last event: 2003/10/2 Appears to be a lost interrupt during reset. * Lost interrupt for ATA-SLAVE on reboot. Last event: 2003/10/7 I'm unsure if this is actually a problem but occasionally it prints a message right before rebooting about loosing an interrupt. I'll try to get more info. Device is Intel 82801CA/CAM ICH3 ATA100 controller. There are no slave devices, just one master hard drive on primary and one master DVD/CDRW on secondary. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: msdosfs mask?
On Mon, 6 Oct 2003, Bruce Evans wrote: > On Sun, 5 Oct 2003, Nate Lawson wrote: > > In the past, msdosfs has taken its permissions from the mountpoint. > > Recently I noticed that this still works for files in the root directory > > but subdirectories are all chmod 000. Has anyone else seen this? Adding > > the -m=755 flag for instance does work for the files in the top of the > > mountpoint (i.e. command.com) but not subdirectories, which are still 000. > > What's going on? > > Perhaps your mount_msdosfs binary is out of date. Rev.1.25 of > mount_msdosfs.c is required to keep up with corresponding kernel > changes. It passes a separate mask for directories. Thanks! That was it. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
msdosfs mask?
In the past, msdosfs has taken its permissions from the mountpoint. Recently I noticed that this still works for files in the root directory but subdirectories are all chmod 000. Has anyone else seen this? Adding the -m=755 flag for instance does work for the files in the top of the mountpoint (i.e. command.com) but not subdirectories, which are still 000. What's going on? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI shutdown problem
> Now I'm having an issue with ACPI. I used to hit the power button and > that would initiate a proper shutdown. Now it seems to do nothing, > but when I reboot the system goes into a suspended state before > completing the shutdown. The motherboard beeps three times, the > screen goes blank, and will complete the shutdown after I hit the any > key. > > The strange thing is that in the past, a user initiated suspend while > the system is running would never blank the screen, but this > suspend-before-shutdown does... > > What do you need from me to help resolve this? First, please don't hijack another thread. I've started another one for this. sysctl hw.acpi should show you what the power button event generates. It should be set to S5. What does yours say? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
On Wed, 1 Oct 2003, Jeremy Bingham wrote:
> On 01/10/03 09:33 -0700, Nate Lawson wrote:
> > > > As far as debugging prints, add the following printfs to
> > > > acpi_cmbat_get_bif():
> > > >
> > > > printf("Before getting BIF\n");
> > > > as = AcpiEvaluateObject(h, "_BIF", NULL, &bif_buffer);
> > > > printf("After getting BIF\n");
> > > >
> > > > -Nate
> >
> > Ok, that's good to know. How about the printfs? Did the second one
> > trigger? I could use a URL to your ASL and full dmesg on boot:
>
> The second one did not trigger (I had actually been using ACPI_VPRINT
> for a while to get info like that). I have a dump of my ASL here:
> http://home.satanosphere.com/bsd/jeremy.asl.gz.
dmesg is not necessary. The only way to find what is hanging is to keep
working printfs deeper into the _BIF method. Start with
AcpiEvaluateObject in sys/contrib/dev/acpica/nsxfeval.c and sprinkle
printf A, B, C etc. throughout to find where it hangs. Alternatively, if
you have a serial console and gdb, you can step through the method.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass(4)/uhci(4) REALLY slow
On Wed, 1 Oct 2003, Bruce Evans wrote: > On Tue, 30 Sep 2003, Nate Lawson wrote: > > Here are "iostat 5" results for my USB thumb drive on a uhci(4) controller > > with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly. > > On FreeBSD, it really lags. This is for a cp of a large file to a > > msdosfs-mounted flash drive. > > > > da0 > > KB/t tps MB/s > > 1.07 41 0.04 > > 1.00 41 0.04 > > 1.02 41 0.04 > > > > Is there something we're doing on uhci(4) that makes each transfer only > > 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec > > which is still well under the USB 1.1 max speed. > > This is probably due to something we're not doing in msdosfs. 1K is > probably your msdosfs file system block size. Yes, I checked and it has a 1K block size. The flash device is 64 MB. > msdosfs is missing support > for clustering. None of the lower levels (buffer cache, driver, usb) > in FreeBSD does clustering (the buffer cache has some support for it, > but this is mostly turned off because the file system doesn't ask for > it). The lower levels not in FreeBSD (firmware and hardware) apparently > don't do clustering either. This results in abysmal performance if > the msdosfs block size is small. It would be twice as abysmal with > the minimum block size of 512. Similarly for ffs with small block sizes > and lots of fragments if write clustering is turned off if the drive > doesn't do it. What would need to be done to add msdosfs clustered reads/writes or perhaps do this in a more general way in the buffer cache? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
On Wed, 1 Oct 2003, Jeremy Bingham wrote:
> On 30/09/03 15:04 -0700, Nate Lawson wrote:
> > Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please
> > try with _just_ DDB and see if you can still reproduce the problem. If
> > so, then when it hangs, hit CTRL-ALT-ESC and type "tr". This will tell
> > who is hung.
> >
> > As far as debugging prints, add the following printfs to
> > acpi_cmbat_get_bif():
> >
> > printf("Before getting BIF\n");
> > as = AcpiEvaluateObject(h, "_BIF", NULL, &bif_buffer);
> > printf("After getting BIF\n");
> >
> > -Nate
>
> Tried compiling a kernel with just DDB, and I got no love. It still
> hung, and although I tried hitting CTRL-ALT-ESC and typing "tr", it hung
> so hard that even that didn't work.
Ok, that's good to know. How about the printfs? Did the second one
trigger? I could use a URL to your ASL and full dmesg on boot:
acpidump -t -d | gzip > jeremy.asl.gz
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
umass(4)/uhci(4) REALLY slow
Here are "iostat 5" results for my USB thumb drive on a uhci(4) controller with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly. On FreeBSD, it really lags. This is for a cp of a large file to a msdosfs-mounted flash drive. da0 KB/t tps MB/s 1.07 41 0.04 1.00 41 0.04 1.02 41 0.04 Is there something we're doing on uhci(4) that makes each transfer only 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec which is still well under the USB 1.1 max speed. Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
On Tue, 30 Sep 2003, Jeremy Bingham wrote:
> On 30/09/03 14:48 -0700, Nate Lawson wrote:
> > Please do not start new threads for the same problem as it makes it hard
> > to track down what your problem even was originally. I assume your
> > problem is hangs during boot, it appeared since 5.1R, and it goes away if
> > you enable "options INVARIANTS". Is that right?
> >
> > -Nate
>
> Yes, that is the case. It was only today that I managed to track down
> where the problem was cropping up, though.
Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please
try with _just_ DDB and see if you can still reproduce the problem. If
so, then when it hangs, hit CTRL-ALT-ESC and type "tr". This will tell
who is hung.
As far as debugging prints, add the following printfs to
acpi_cmbat_get_bif():
printf("Before getting BIF\n");
as = AcpiEvaluateObject(h, "_BIF", NULL, &bif_buffer);
printf("After getting BIF\n");
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT
On Tue, 23 Sep 2003, Jeremy Bingham wrote: > On 23/09/03 18:07 -0700, Nate Lawson wrote: > > Enable options DDB. When it hangs, press CTRL-ALT-ESC and then "tr" to > > get a traceback. > > > > While ACPI influences this problem, I am uncertain it is the root cause. > > > > -Nate > > Way ahead of you there. I compiled a kernel with DDB on, installed it, > and everything worked fine. No hangs or anything. When I recompiled the > kernel with the debugging options off, the same hang happened again. > Bizarre, to say the least. Again, booting with ACPI turned off worked > fine. I'm making another debug kernel, and I'll try running that for a > while. When you say "debugging options", do you mean you added things other than "options DDB" (i.e. INVARIANTS or others)? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
Please do not start new threads for the same problem as it makes it hard to track down what your problem even was originally. I assume your problem is hangs during boot, it appeared since 5.1R, and it goes away if you enable "options INVARIANTS". Is that right? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2706] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Kevin Oberman wrote: > > Date: Mon, 29 Sep 2003 13:33:06 -0700 (PDT) > > From: Nate Lawson <[EMAIL PROTECTED]> > > ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: > > > > /* > > * Scan all of the child devices we have created and let them probe/attach. > > */ > > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n")); > > bus_generic_attach(bus); > > > > /* > > * Some of these children may have attached others as part of their attach > > * process (eg. the root PCI bus driver), so rescan. > > */ > > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n")); > > bus_generic_attach(bus); > > Thanks. That explains why I get the message twice, but why do I get it > at all when the device is disabled in the device.hints file? Dunno. That's probably an sio(4) problem. It does that on my laptop also. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2704] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Kevin Oberman wrote: > > Date: Mon, 29 Sep 2003 16:04:25 -0400 (EDT) > > From: John Baldwin <[EMAIL PROTECTED]> > > > > On 29-Sep-2003 Kevin Oberman wrote: > > > I recently noticed that, when I boot with ACPI on my IBM T30, I get > > > errors trying to probe the BIOS disabled sio1. This does not happen > > > under apm and happens twice(?) when booting with ACPI and happens even > > > though I have the line 'hint.sio.1.disabled="1"' in /boot/device.hints. > > >>From my dmesg: > > > sio0: type 16550A > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > sio1: port may not be enabled > > > acpi_cmbat0: on acpi0 > > > acpi_cmbat1: on acpi0 > > > acpi_acad0: on acpi0 > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > sio1: port may not be enabled > > > > Do you kldload a module at some point during your boot? If so, that > > would explain the double probe. > > Yes, it would, but I am not loading any kernel modules except the > slightly automatic loads of ACPI, itself and a few others which should > not cause a probe: ntfs, linux, linprocfs, and daemon_saver. ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: /* * Scan all of the child devices we have created and let them probe/attach. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n")); bus_generic_attach(bus); /* * Some of these children may have attached others as part of their attach * process (eg. the root PCI bus driver), so rescan. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n")); bus_generic_attach(bus); -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH sound after suspend/resume
On Mon, 29 Sep 2003, Kevin Oberman wrote: > Re: kern/55395 > > I see a patch to ich.c back on the 15th to "Correctly reset ich[3-5] > sound cards on resume.", but I am still not able to properly use my > sound card after a resume because the card starts clocking at the wrong > rate, about 52K instead of the correct 48,000. > > There is nothing in the tying it to any PR, but it looks like it's > trying to do the "right thing" on resume. > > As before, the sysctl for the sampling rate has no effect. > > Any ideas what I might try? I'll take a look at this eventually. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT
On Thu, 25 Sep 2003, Jeremy Bingham wrote: > > Unfortunately, no. You can cvsup to 2003/8/23 on just the sys/dev/ata > > directory and revert the change to sys/conf/files. That does the trick. > > Currently ATAng causes a hang on resume from suspend whereas it has worked > > for months before ATAng. I am running -current without ATAng with no > > problems. > > > > -Nate > > Herm. I checked out a copy of the sys tree from 8/23, copied the files > from sys/dev/ata over (after deleting the current ones), made the > changes in sys/conf/files, and tried making a new kernel, but it won't > do it. I get errors like: > > ../../../dev/ata/ata-all.c: In function `ataioctl': > ../../../dev/ata/ata-all.c:409: error: `ATAPICMD' undeclared (first use > in this function) > ... etc. etc. etc. > > What am I missing? /sys/sys/ata.h needs to be reverted. You should look at the original commit message to have a full understanding of what needs to be reverted. > Incidentally, compiling a kernel w/ ACPI_DEBUG and > putting those lines in /boot/loader.conf that you mentioned in that > other email did nothing -- booting with verbose logging gave the same > amount of logging, and booting normally didn't give any more messages > than normal. That's because ACPI is a module and options defined in the kernel config do not apply to the modules. I think someone was working on fixing this annoyance. To rebuild it, cd /sys/modules/acpi and do: make ACPI_DEBUG=1 cp acpi.ko /boot/kernel.test (or wherever your test kernel is) reboot An easier way is to just include acpi in the kernel build. Add this to your kernel config and rebuild: device acpica options ACPI_DEBUG -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT
On Thu, 25 Sep 2003, Jeremy Bingham wrote: > On 25/09/03 11:54 -0700, Nate Lawson wrote: > > Interesting. Try turning on ACPI_LV_FUNCTIONS (see the email I just sent > > to -current) as well as ACPI_DEBUG and let me know the last 3-4 prints > > before it hangs. Not blaming anyone here, but could you also try without > > ATAng? I am unable to use ATAng on my laptop. > > > > -Nate > > Will do. One question, though, before I get to recompiling -- is there > some specific option for ATAng in the kernel that I'm missing? The only > thing I see that looks similar is 'device ata'. Unfortunately, no. You can cvsup to 2003/8/23 on just the sys/dev/ata directory and revert the change to sys/conf/files. That does the trick. Currently ATAng causes a hang on resume from suspend whereas it has worked for months before ATAng. I am running -current without ATAng with no problems. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT
> So, after running this laptop with debugging stuff and INVARIANTS on all > day and having it work fine, I decided to try taking the INVARIANTS > options out of the kernel. Lo and behold, it now hangs again when I try > to boot. I can't even get it to respond when I hit Ctrl-Alt-Esc and try > to get it to go into debugging mode and get a stack trace. When I was > looking at where it was dying before with verbose logging turned on, it > seemed to be dying when it was trying to initialize the battery. I > looked at the ACPI stuff in the kernel, and I think I may have found > where it stops working. (It's where the kernel tries to initialize the > battery - somewhere in sys/dev/acpia/acpi_cmbat.c.) Interesting. Try turning on ACPI_LV_FUNCTIONS (see the email I just sent to -current) as well as ACPI_DEBUG and let me know the last 3-4 prints before it hangs. Not blaming anyone here, but could you also try without ATAng? I am unable to use ATAng on my laptop. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ThinkPad R40 hangs during ACPI power down
> I've got an IBM ThinkPad R40 that hangs when I do a "shutdown -p". It > wedges after printing "Powering system off using ACPI". > > Attempting to use 'acpiconf -s" to suspend produces similar hangs. Your system is halting correctly but powering off is failing. A cursory glance at your ASL shows nothing particularly amiss. It's very similar to my laptop (T23). > I tried compiling a version of the kernel with the ACPI_DEBUG option > listed in NOTES, but buildkernel dies This was fixed on Sept 21 so cvsup and recompile. Set hw.acpi.verbose=1 in loader.conf to get more messages. To debug this, please boot a newer kernel with the ACPI_DEBUG option with the following options in loader.conf: debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_FUNCTIONS" You'll get spammed with way too many messages on boot but just ignore these. Then do shutdown -p and log the printed messages (hopefully you have a serial console). I'll map the debugging tunables to a sysctl since it would be better if you could just set this just before testing rather than for the full boot. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT
>When booting FreeBSD normally or in single-user mode, these are the last >messages displayed: > >Timecounter "TSC" frequency 498470127 Hz quality 800 >Timecounters tick every 10.000 msec >^^^ hangs after that > > >When booting FreeBSD with ACPI turned off or in "Safe Mode", the computer >boots normally. Enable options DDB. When it hangs, press CTRL-ALT-ESC and then "tr" to get a traceback. While ACPI influences this problem, I am uncertain it is the root cause. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and a Toshiba Tecra 8000
On Mon, 22 Sep 2003, Andrew Thompson wrote: > Andrew Thompson wrote: > > I fixed the other null derefernce in sc_bell() and the laptop is now > > suspending with the serial console the same as without. > > as it should, but the second suspend it only does acpi_SetSleepState() > -> AcpiEnterSleepStatePrep() and then the laptop suspends itself. I am > unsure why it is not getting as far the second time... > > > Breakpoint at acpi_SetSleepState: pushl %ebp > db> c > Breakpoint at AcpiEnterSleepStatePrep:pushl %ebp > db> c > I'll have to look at your acpidump to have a guess. It could be that running the _PTS method causes your laptop to enter suspend the second time due to an improperly resumed device from the first suspend. acpidump -t -d > andy.asl -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and a Toshiba Tecra 8000
On Wed, 17 Sep 2003, Andrew Thompson wrote: > Nate Lawson wrote: > > On Wed, 17 Sep 2003, Andrew Thompson wrote: > > > >>111 sc_cur_scr = sc->cur_scp->index; > > > > For a temporary workaround, try changing line 111 to: > > if (sc->cur_scp == NULL) > > return (0); > > > > This may not help things though. > > It has helped and the laptop is able to suspend with the serial cable > attached (further than before). It now panics on the first resume with > the following (gdb output at bottom). > > I think the serial cable is masking the problem as without it I can > suspend/resume once and it only panics on the second resume. I guess I > need the serail working to see that panic anyway. You should do a quick grep through sys/dev/syscons for "= sc->cur_scp->index" and replace them all with the above NULL check. I'm interested if this will fix things. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2674] ACPI S3 battery drain
On Wed, 17 Sep 2003, Anish Mistry wrote: > I reported this serveral times and no one seemed to be able to > reproduce the problem, and I couldn't figure out what wasn't being > shutoff. FInally I think that I figured it out. The display is the > thing that is not being shutoff. The reason I missed this is because > the backlight would shutoff and unless you look really close you > can't tell that the display is still active. Not sure if this helps > anyone, but it is one step closer. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=56024 Just a short heads-up. I have been focusing attention on fixing panics first and will eventually get around to other problem reports. I have been logging reports but not working on them. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng panic: ATAFD re-using freed memory
On Mon, 8 Sep 2003, Soren Schmidt wrote: > It seems Nate Lawson wrote: > > With a fresh checkout of last night's -current, I cannot boot my laptop. > > ATAFD panics the box by reusing freed memory. I do not have a floppy > > drive in the laptop and when I do, it's a legacy floppy, not atapi. Here > > are the messages: > > > > [normal ad0/acd0 probe message] > > afd0: timeout waiting for ATAPI ready > > afd0: timeout waiting for ATAPI ready > > afd0: timeout waiting for ATAPI ready > > afd0: timeout waiting for ATAPI ready > > afd0: timeout waiting for ATAPI ready > > panic: Memory modified after free: 0xc33ed400 (252) > > Most recently used by AFD driver > > > > A working dmesg: > > http://www.root.org/~nate/acpi/ibm.dmesg > > >From the above I can tell whats going on, please upgrade to the latest > -current as I've fixed a couble of things in the probe code there. > > If it still panic's please include a verbose boot from a atapicam-less > kernel... This has been fixed. However, ATAng is still not usable for the reasons in my next email message: Message-ID: <[EMAIL PROTECTED]> -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with this morning's -CURRENT [SOLVED]
On Tue, 16 Sep 2003, Damian Gerow wrote: > Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 16:24]: > > I have no time to track this down but the output of acpidump -t may help > > someone else who might be interested. You're looking for the pointers > > that are stored in RSD PTR. > > I'm still on 5.1-R, and there's no '-t' flag to acpidump. However, I've > posted the dump on the web: > > <http://www.sentex.net/~damian/acpidump> > > so people can browse as they wish. As expected, your ACPI tables are at the top of physmem: RSDT=0x1fff3000. This is only 52k from 512MB. Something in how MAXMEM affects setup of physical memory is truncating physmem by at least 64k. In short, Don't Do That. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with this morning's -CURRENT [SOLVED]
On Tue, 16 Sep 2003, Damian Gerow wrote: > Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 15:00]: > > I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that > > from your kernel config and try again. MAXMEM causes all kinds of > > problems. If this doesn't solve it, start with the stock GENERIC and add > > back in your custom kernel options until it fails. The last option you > > add is the faulty one. > > I was wondering the same thing myself last night actually... > > I just pulled that line, and it now works. Which is weird -- I have two > other 5.1 machines that I have specified MAXMEM in, without any troubles. > It's also strange that this would only be brought out with ACPI...? > > Anyhow, it's working for me now. If anyone feels like further debugging, > I'm all game. It probably has something to do with the virtual/physical gymnastics ACPI has to do to map its tables into memory. I have no time to track this down but the output of acpidump -t may help someone else who might be interested. You're looking for the pointers that are stored in RSD PTR. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and a Toshiba Tecra 8000
On Wed, 17 Sep 2003, Andrew Thompson wrote: > (gdb) l *scsuspend+0x17 > 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111). > 106 int retry = 10; > 107 static int dummy; > 108 sc_softc_t *sc; > 109 > 110 sc = &main_softc; > 111 sc_cur_scr = sc->cur_scp->index; > 112 > 113 if (sc_no_suspend_vtswitch) > 114 return (0); > 115 For a temporary workaround, try changing line 111 to: if (sc->cur_scp == NULL) return (0); This may not help things though. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and a Toshiba Tecra 8000
On Wed, 17 Sep 2003, Andrew Thompson wrote: > Nate Lawson wrote: > >gdb kernel.debug > >l *scsuspend+0x17 > >That should show the offending code segment. > > (gdb) l *scsuspend+0x17 > 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111). > 106 int retry = 10; > 107 static int dummy; > 108 sc_softc_t *sc; > 109 > 110 sc = &main_softc; > 111 sc_cur_scr = sc->cur_scp->index; > 112 > 113 if (sc_no_suspend_vtswitch) > 114 return (0); > 115 Ok, this shows it's not ok to unconditionally deref sc->cur_scp. Now I'll look for what cases it is NULL. I'll get back to you in a day or so. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with this morning's -CURRENT
> (To recap: I'm having ACPI problems on a DFI CD70-SC, with both 5.1-R and > 5-CURRENT. Booting GENERIC doesn't show any problems, however, so there's > a good chance it's a misconfiguration issue.) > > Thus spake Damian Gerow ([EMAIL PROTECTED]) [15/09/03 17:34]: > > It's attached. There's no APM in there. I did some more testing -- > GENERIC works for the -CURRENT date I stated before, and 5.1-R. As soon > as I compile my own kernel, it breaks. > >Okay, here's a backtrace with debugging. Unfortunately, when dropped to the >debugging prompt, I don't know what to do. Attached is the kernel config I >used to generate this on 5.1-R, I can re-do this on -CURRENT if need be. > >Here's a snippet of boot, and the stack backtrace: > >... >Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b8000 >Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04b81f4 >... >real memory = 536870912 (512 MB) >avail memory = 516313088 (492 MB) >panic: pmap_mapdev: Couldn't allocate kernel virtual memory >Stack backtrace: >backtrace(c035b0cc,c03baea0,c0372994,c04dabbc,100) at backtrace+0x17 >panic(c0372994,c036f000,0,0,0) at panic+0x93 >pmap_mapdev(1fff3000,c036ec14,c04dac48,c04dabcc,c048e880) at pmap_mapdev+0x4b >AcpiOsMapMemory(1fff3000,0,c036ec14,c04dabbc,c04dabc4) atAcpiOsMapMemory+0x1e I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that from your kernel config and try again. MAXMEM causes all kinds of problems. If this doesn't solve it, start with the stock GENERIC and add back in your custom kernel options until it fails. The last option you add is the faulty one. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and a Toshiba Tecra 8000
Please compile your kernel with debug symbols (config -g KERNEL) and load it into gdb to get the actual line of code that is getting that NULL deref: gdb kernel.debug l *scsuspend+0x17 That should show the offending code segment. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng suspend/resume support broken
On Mon, 1 Sep 2003, Soren Schmidt wrote: > It seems Nate Lawson wrote: > > This worked with old ATA. For now I've supped sys/dev/ata back to > > 2003/8/23. Ideas? > > Not really, it does work on my laptop hmm.. > > I'll try to get it onto a few other laptops at work, see if I can > reproduce the problem.. I cvsupped to the 2003/9/13 (today) and built a kernel. It still has some problems: 1. Panic on uninitialized FD data fixed, thank you 2. Resume still fails/hangs with the drive light on. 3. Message on console when rebooting that ata slave missed interrupt Dmesg is below: Copyright (c) 1992-2003 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 5.1-CURRENT #0: Sat Sep 13 16:01:05 PDT 2003 [EMAIL PROTECTED]:/home/nate/src/sys/i386/compile/LAPTOP Preloaded elf kernel "/boot/kernel.bad/kernel" at 0xc04bc000. Preloaded elf module "/boot/kernel.bad/acpi.ko" at 0xc04bc27c. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III Mobile CPU 1000MHz (999.16-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383f9ff real memory = 402063360 (383 MB) avail memory = 385294336 (367 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x66,0x62 on acpi0 pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_ec0: info: new max delay is 35 us acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 29 INTA is routed to irq 11 pcib0: slot 29 INTB is routed to irq 11 pcib0: slot 29 INTC is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 pcib2: slot 0 INTA is routed to irq 11 pcib2: slot 0 INTB is routed to irq 11 pcib2: slot 2 INTA is routed to irq 11 pcib2: slot 8 INTA is routed to irq 11 cbb0: mem 0x5000-0x5fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb1: mem 0x5100-0x51000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] pci2: at device 2.0 (no driver attached) pci2: at device 8.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ichsmb0: port 0x1880-0x189f irq 11 at device 31.3 on pci0 smbus0: on ichsmb0 pci0: at device 31.5 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio1 port 0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A acpi_ec0: Changing GLK from 1 to 0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xe-0xe,0xdc000-0xd,0xcf000-0xc,0xce000-0xcefff,0xc-0xcdfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 999155716 Hz quality 800 Timecounters tick every 10.000 msec acpi_cmbat0: battery initialization start acpi_ec0: info: new max delay is 45
