Re: aperf/mperf

2010-11-19 Thread Nate Lawson
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

2010-11-18 Thread Nate Lawson
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.

2010-10-26 Thread Nate Lawson
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

2010-09-11 Thread Nate Lawson
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: ACPI CPU 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: ACPI CPU 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: ACPI CPU 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: ACPI CPU 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: ACPI problem, my VAIO won't come back from suspension

2003-12-03 Thread Nate Lawson
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: Intel SE7500WV2 not working with ACPI

2003-12-03 Thread Nate Lawson
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: INTEL  SWV20on 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: PII SMP system hangs during boot with ACPI enabled

2003-12-02 Thread Nate Lawson
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: Updated acpi_cpu patch

2003-12-02 Thread Nate Lawson
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: Updated acpi_cpu patch

2003-12-02 Thread Nate Lawson
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: /dev/fd0 not working with ACPI

2003-12-02 Thread Nate Lawson
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: ACPI problem, my VAIO won't come back from suspension

2003-12-02 Thread Nate Lawson
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: psmintr not attached w/ acpi

2003-12-01 Thread Nate Lawson
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: psmintr not attached w/ acpi

2003-12-01 Thread Nate Lawson
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]


acpi_cpu changes complete

2003-11-26 Thread Nate Lawson
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: panic: NULL softc for 0

2003-11-26 Thread Nate Lawson
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]


Re: Updated acpi_cpu patch

2003-11-26 Thread Nate Lawson
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: Updated acpi_cpu patch

2003-11-26 Thread Nate Lawson
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]


rc scripts run double on boot?

2003-11-25 Thread Nate Lawson
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: [Me too]: rc scripts run double on boot?

2003-11-25 Thread Nate Lawson
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]


Re: Intel SE7500WV2 not working with ACPI

2003-11-25 Thread Nate Lawson
 acpi0: INTEL  SWV20on 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?

2003-11-25 Thread Nate Lawson
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: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread Nate Lawson
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

2003-11-24 Thread Nate Lawson
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: IRQ problem with VAIO laptop again

2003-11-24 Thread Nate Lawson
 uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C 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: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci2: ACPI PCI bus on pcib1
 pcib1: _PRS resource entry has unsupported type 0
 pcib1: slot 8 INTA is routed to irq 9
 fwohci0: Texas Instruments TSB43AB22/A 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

2003-11-24 Thread Nate Lawson
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: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread Nate Lawson
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

2003-11-24 Thread Nate Lawson
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

2003-11-23 Thread Nate Lawson
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: acpi_cpu

2003-11-21 Thread Nate Lawson
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]


grub on -current?

2003-11-21 Thread Nate Lawson
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: spin lock sched lock held by 0xc25a8640 for 5 seconds

2003-11-21 Thread Nate Lawson
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]


Re: panic: NULL softc for 0

2003-11-21 Thread Nate Lawson
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: panic: NULL softc for 0

2003-11-21 Thread Nate Lawson
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: Updated acpi_cpu patch

2003-11-21 Thread Nate Lawson
  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

2003-11-21 Thread Nate Lawson
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: panic: NULL softc for 0

2003-11-21 Thread Nate Lawson
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

2003-11-21 Thread Nate Lawson
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,M
 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: INTELSBR20   

Booting with MP table, not madt?

 acpi0: INTEL  SBR20on 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: CPU on acpi0
 acpi_cpu1: CPU on acpi0
 device_probe_and_attach: acpi_cpu1 attach returned 6
 acpi_cpu1: CPU on acpi0
 device_probe_and_attach: acpi_cpu1 attach returned 6
 acpi_cpu1: CPU on acpi0
 device_probe_and_attach: acpi_cpu1 attach returned 6
 acpi_button0: Sleep Button 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: Updated acpi_cpu patch

2003-11-21 Thread Nate Lawson
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: Updated acpi_cpu patch

2003-11-19 Thread Nate Lawson
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 sys/param.h
-#include sys/kernel.h
-#include sys/proc.h
 #include sys/bus.h
+#include sys/kernel.h
+#include sys/pcpu.h
 #include sys/power.h
+#include sys/proc.h
 #include sys/sbuf.h
-#include sys/pcpu.h
 #include sys/smp.h

 #include dev/pci/pcivar.h
+#include machine/atomic.h
 #include machine/bus.h
-#include sys/rman.h
 #ifdef __ia64__
 #include machine/pal.h
 #endif
+#include sys/rman.h

 #include acpi.h
 #include dev/acpica/acpivar.h
@@ -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

Re: Updated acpi_cpu patch

2003-11-19 Thread Nate Lawson
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

2003-11-19 Thread Nate Lawson
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

2003-11-19 Thread Nate Lawson
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]


Updated acpi_cpu patch

2003-11-18 Thread Nate Lawson
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_PRIORITY_LO, acpi_cpu_startup, NULL);
 } else {
sysctl_ctx_free

Re: EISA Adaptec 274X SCSI panic (ISRng related)

2003-11-18 Thread Nate Lawson
On Tue, 18 Nov 2003, Andy Farkas wrote:
 My EISA AHA2740's don't work no more :(

 # grep ahc /var/run/dmesg.boot
 ahc0: Adaptec 274X SCSI adapter at 0x2c00-0x2cff, irq 10 (level)
 ahc0: on eisa0 slot 2
 ahc1: Adaptec 274X SCSI adapter at 0x4c00-0x4cff, irq 11 (level)
 ahc1: on eisa0 slot 4
 ahc2: Adaptec aic7880 Ultra SCSI adapter port 0xf800-0xf8ff mem 
 0xf68fb000-0xf68fbfff irq 17 at device 11.0 on pci1
 ahc2: Using left over BIOS settings
 ahc3: Adaptec aic7880 Ultra SCSI adapter 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]


Re: Updated acpi_cpu patch

2003-11-18 Thread Nate Lawson
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: CPU 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: Updated acpi_cpu patch

2003-11-18 Thread Nate Lawson
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

2003-11-18 Thread Nate Lawson
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

2003-11-18 Thread Nate Lawson
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

2003-11-18 Thread Nate Lawson
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: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-18 Thread Nate Lawson
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: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-18 Thread Nate Lawson
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)

2003-11-17 Thread Nate Lawson
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_cpu_sysctl_tree),
-   OID_AUTO, cx_lowest, CTLTYPE_INT | CTLFLAG_RW,
-   NULL, 0, acpi_cpu_cx_lowest_sysctl, I,
-   lowest Cx sleep state to use);
-SYSCTL_ADD_PROC(acpi_cpu_sysctl_ctx,
-   SYSCTL_CHILDREN

Re: Two panics for the price of one: acpi_cpu_idle *and* turnstiles

2003-11-17 Thread Nate Lawson
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)

2003-11-16 Thread Nate Lawson
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

2003-11-16 Thread Nate Lawson
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: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 src/sys/conf files src/sys/modules/acpi Makefile

2003-11-15 Thread Nate Lawson
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

2003-10-30 Thread Nate Lawson
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

2003-10-29 Thread Nate Lawson
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

2003-10-27 Thread Nate Lawson
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 pid 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]


Re: ACPI trouble with EPIA-M

2003-10-27 Thread Nate Lawson
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 pid 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]


Warnings with libstdc++ build

2003-10-25 Thread Nate Lawson
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

2003-10-24 Thread Nate Lawson
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: ACPI trouble with EPIA-M

2003-10-23 Thread Nate Lawson
 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: irq conflict laptop with 5.1-current

2003-10-23 Thread Nate Lawson
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: ACPI PCI-PCI bridge 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 on fujitsu-siemens

2003-10-20 Thread Nate Lawson
   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

2003-10-17 Thread Nate Lawson
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?

2003-10-14 Thread Nate Lawson
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: cvs commit: src/sys/dev/sound/pci ich.c

2003-10-13 Thread Nate Lawson
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]


Re: Interrupt statistics?

2003-10-13 Thread Nate Lawson
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]


Interrupt statistics?

2003-10-12 Thread Nate Lawson
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]


Re: msdosfs mask?

2003-10-07 Thread Nate Lawson
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]


ATAng issues status report

2003-10-07 Thread Nate Lawson
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]


msdosfs mask?

2003-10-05 Thread Nate Lawson
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]


Re: Problem w/ ACPI in -CURRENT: Update

2003-10-01 Thread Nate Lawson
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]


Re: umass(4)/uhci(4) REALLY slow

2003-10-01 Thread Nate Lawson
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

2003-10-01 Thread Nate Lawson
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]


ACPI shutdown problem

2003-10-01 Thread Nate Lawson
 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

2003-09-30 Thread Nate Lawson
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: Problem w/ ACPI in -CURRENT

2003-09-30 Thread Nate Lawson
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

2003-09-30 Thread Nate Lawson
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]


umass(4)/uhci(4) REALLY slow

2003-09-30 Thread Nate Lawson
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: ICH sound after suspend/resume

2003-09-29 Thread Nate Lawson
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: [acpi-jp 2704] Re: Odd ACPI behavior

2003-09-29 Thread Nate Lawson
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: Control method Battery on acpi0
   acpi_cmbat1: Control method Battery on acpi0
   acpi_acad0: AC adapter 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: [acpi-jp 2706] Re: Odd ACPI behavior

2003-09-29 Thread Nate Lawson
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: ThinkPad R40 hangs during ACPI power down

2003-09-25 Thread Nate Lawson
 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

2003-09-25 Thread Nate Lawson
 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: Problem w/ ACPI in -CURRENT

2003-09-25 Thread Nate Lawson
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

2003-09-25 Thread Nate Lawson
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: ACPI and a Toshiba Tecra 8000

2003-09-23 Thread Nate Lawson
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...

 suspend #2
 Breakpoint at   acpi_SetSleepState: pushl   %ebp
 db c
 Breakpoint at   AcpiEnterSleepStatePrep:pushl   %ebp
 db c
 laptop suspends here, reboots on resume

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: Problem w/ ACPI in -CURRENT

2003-09-23 Thread Nate Lawson
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

2003-09-19 Thread Nate Lawson
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

2003-09-17 Thread Nate Lawson
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: ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Nate Lawson
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: ACPI problems with this morning's -CURRENT

2003-09-16 Thread Nate Lawson
 (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

2003-09-16 Thread Nate Lawson
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 and a Toshiba Tecra 8000

2003-09-16 Thread Nate Lawson
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 problems with this morning's -CURRENT [SOLVED]

2003-09-16 Thread Nate Lawson
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 problems with this morning's -CURRENT [SOLVED]

2003-09-16 Thread Nate Lawson
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: ATAng panic: ATAFD re-using freed memory

2003-09-16 Thread Nate Lawson
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: USB da(4) quirks deprecated

2003-09-13 Thread Nate Lawson
On Sat, 13 Sep 2003, John-Mark Gurney wrote:
 Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200:
  I have just got around to trying this pen-drive again and have been
  trying tracking down data corruptions.  If I mount the drive, write a
  file, umount/mount again the file is different.
 
  Using cmp I have found that there are consistent blocks of nulls in the
  written file where data should be. The block is always 0xfff bytes long
  and starts at 0x3000.  I have tried many files and the offsets are
  always the same. All the other data in the file is correct and at the
  right location.
 
  0x3000 - 0x3fff
  0x7000 - 0x7fff
  0xb000 - 0xbfff
  0xf000 - 0x
  0x13000 - 0x13fff
  ... and so on until the end of the file ...
 
  Any suggestions?

This almost certainly has nothing to do with quirks.

 Is this on an ohci controller?

 I'm trying to track down mbr's problem also that appears to do the
 same thing.  Have you tried doing an fstat before umounting the fs?

I think you mean fsync?

 (There is a bug in msdosfs that doesn't sync the disk before unmount
 completes.)

 This is wierd in that it's the second page of the second transfer.
 The ohci can do up to 8k transfers in one TD, and then chain the TD's
 together if a larger block sized is used.

Maybe you can provide him a patch that limits transfers to a single page
as multi-page descriptors might be broken on his controller.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


  1   2   3   4   5   >