Nabble - freebsd-acpi

Re: amd64/140751: [acpi] BIOS resource allocation and FreeBSD ACPI in TOSHIBA laptop

2009-11-21T15:14:16Z

Old Synopsis: BIOS resource allocation and FreeBSD ACPI in TOSHIBA laptop
New Synopsis: [acpi] BIOS resource allocation and FreeBSD ACPI in TOSHIBA laptop

Responsible-Changed-From-To: freebsd-amd64->freebsd-acpi
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Nov 21 23:14:02 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=140751
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: HP Pavillion does not power off

2009-11-20T02:49:48Z

On Mon, 2009-11-16 at 18:05 +0000, Jerry Marles wrote:

> On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote:
> > On Mon, 9 Nov 2009, Jerry Marles wrote:
> > > On Mon, 2009-11-09 at 20:23 +0000, Jerry Marles wrote:
> > > > On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote:
> > > > Hello,
> > > > >
> > > > > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is
> > > > > that halt -p does not power it off. The light on the power button goes
> > > > > off but I can hear that it is still running. If I hold down the power
> > > > > button for a few seconds the power can be heard to go off but then it
> > > > > boots right back up again. Windows and Linux can power it off
> > > > > successfully.
> > > > >
> > > > > Regards
> > > > >
> > > > > Jerry Marles
> > > > >
> > > >
> > > > with further investigation I have found that
> > > >
> > > > acpiconf -s 5 results in invalid sleep type (5)
> > > >
> > > > but acpiconf -s 4 powers it off successfully so if I could just make
> > > > halt -p do whatever acpiconf -s 4 is doing the problem would be solved.
> > > >
> > > > any advice would be much appreciated.
> > >
> > > dmesg after boot -v is here http://www.marles.org/acpi/dmesg.txt
> > >
> > > sysctl hw.acpi is here http://www.marles.org/acpi/hwacpi.txt
> > >
> > > acpidump is here http://www.marles.org/acpi/acpidump.txt
> >
> > Seeing noone else has had a go:
> >
> > It seems pretty strange that acpiconf -s 4 powers it off properly.
> > your hwacpi.txt only shows ..
> >
> > hw.acpi.supported_sleep_state: S1 S3 S4 S5
> > hw.acpi.power_button_state: S5
> > hw.acpi.sleep_button_state: S1
> > hw.acpi.lid_switch_state: NONE
> > hw.acpi.standby_state: S1
> > hw.acpi.suspend_state: S3
> > hw.acpi.sleep_delay: 1
> > hw.acpi.s4bios: 0
> > hw.acpi.verbose: 1
> > hw.acpi.disable_on_reboot: 0
> > hw.acpi.handle_reboot: 0
> > hw.acpi.reset_video: 0
> > hw.acpi.cpu.cx_lowest: C1
> >
> > .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened
> > to your hw.acpi.thermal settings also, but .. just a long shot ..
> >
> > What happens if you set sysctl hw.acpi.power_button_state=S4 and then
> > try halt -p ? .. probably better off using 'shutdown -p now' actually.
> >
> > cheers, Ian
>
> That does change things in that now if I hold down the power button
> after halt -p it just goes off rather than booting straight back up
> again. So that is an improvement. Thanks.
>
> Jerry

As Windows, Linux and Solaris can power this machine off would it be
reasonable to conclude that this is just a feature of FreeBSD and not a
fault in my ACPI tables? looking at the source code for acpiconf leads
me to conclude that FreeBSD just does not implement ACPI sleep state S5,
acpiconf certainly does not. In the handbook 11.16 Using and Debugging
FreeBSD ACPI says

"This means that we can use acpiconf -s to test S3, S4OS, and S5."

That is clearly wrong.

I discovered that the motherboard is actually made by Foxconn a
945GZ7MC. Googling Foxconn lead me to all sorts of interesting rants
about Linux ACPI. I also found some useful articles about how to go
about debugging ACPI tables and wondered if I could contribute something
that might be useful to others if I could get to the bottom of the
problem. I guess I would probably just waste a lot of time going down
that road.

I have been using FreeBSD since 2.15 around 1996 so I will be very
disappointed to have to confine it to VirtualBox until I replace this
hardware. I also find it hard to believe that I am the only one with
this problem should I just create a PR?

Regards

Jerry

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Windows XP blue screen error with ACPI enabled!

2009-11-18T21:31:51Z

Hi,
I am a BIOS developer, I get a blue screen error "STOP 0x0000007e
(0Xc0000005,0xf748e0bf,0xf78da208,0xf78d9f08) pci.sys -address F748e0bf base
at F7487000 , datestamp 3b7d855c. " when i try to install windows XP in the
targer motherboard.
Please help in decoding the error message.

thanks in advance.

velavan
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: Call for bge(4) testers

2009-11-17T13:17:41Z

On Tuesday 17 November 2009 5:32:08 pm Pyun YongHyeon wrote:

> On Tue, Nov 17, 2009 at 04:50:06PM -0200, Gonzalo Nemmi wrote:
>
> [...]
>
> > Well, I proceeded as I told you I would, applied your patch and
> > even if it didn't solve the problem (bge still doesn't resume) at
> > least it improved the previous situation given that now it doesn't
> > loop timing out once and again as before.
> >
> > You can find a tail from /var/log/messages in here:
> > http://pastebin.com/f643555f7
> >
> > As you can see, the first 3 lines corresponds to "kldload if_bge"
> > Line number 4 is "acpiconf -s3"
> >
> > At line number 17 bge0 finally fails and let's the machine wake up
> > at line 18.
> >
> > Then, as soon as I could I issued a "ifconfig bge0" to see what I
> > could get .. that's what you can see from line 20 to line 41. (as
> > you can see
>
> Ok, would you try this one? I guess bge(4) register access method
> could be in uninitialized state after resume.

Just did .. same result .. you´ll find the messages here:
http://pastebin.com/f38369b3c

1.- root login
2 to 9.- "kldload if_bge"
10.- "acpiconf -s3"
11 to 13.- wpi0 messages before suspending
14 to 23.- bge0 messages upon resume
24.- wakeup

BTW: is there an easy way to unroll the patches so I get a pristine copy
back and apply the patch over it again? Im asking because the 3rd chunk
of your patch ( bge_reset(sc); ) didn't apply cleanly and I had to edit
if_bge.c by hand to add that line in the right place.

Still willing to keep on trying and awaiting orders :)

Best Regards
Gonzalo Nemmi

> > in there, I found there are problems resuming umass devices as
> > well ... )
>
> Probably Hans can help you on USB issues.
>
> > Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the
> > way, once unloaded, I could load it again but bge0 never showed on
> > "ifconfig".
> >
> > Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ...
> > which ended with pulling the pendrive out as the system coldn't
> > umount it ...
> >
> > I also found I get wpi0 messages on resume .. it spouts:
> > wpi0 could not lock memory
> > wpi0 could not lock memory
> > wpi0 could not lock memory
> > wpi0 could not lock memory
> > wpi0 could not lock memory
> > wpi0 could not lock memory
> > wpi0 could not lock memory
> > and then it let's the system resume.
>
> Don't know what it really means. You'd be better to ask wpi(4)
> author Benjamin Close(benjsc@).
>
> > All in all .. there's _a_lot_of_problems_on_resume_
> >
> >
> > Pyun, if you'd like me to try a new patch or to do some tests or
> > whatever, just let me know. I'm here awaiting orders :)
> >
> > Best Regards
> > Gonzalo Nemmi

--
Blessings
Gonzalo Nemmi
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: Call for bge(4) testers

2009-11-17T11:34:16Z

On Monday 16 November 2009 3:54:50 pm Pyun YongHyeon wrote:
> On Mon, Nov 16, 2009 at 03:34:33PM -0200, Gonzalo Nemmi wrote:
> > On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote:
> > > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote:
> > > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote:
> > > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote:
> > > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon
wrote:

> > > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon
> >
> > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I had been working on fixing bus_dma(9) bugs and adding
> > > > > > > > TSO capability to bge(4). Now TSO is supported for
> > > > > > > > BCM5755 or newer controllers. Actually some pre-BCM5755
> > > > > > > > controllers also support TSO with the help of special
> > > > > > > > firmware but the license issue and lower performance of
> > > > > > > > firmware based TSO as well as TSO bug I intentionally
> > > > > > > > excluded TSO support for pre-BCM5755 controllers. You
> > > > > > > > can get the patch form the following URL. The diff was
> > > > > > > > generated against latest HEAD.
> > > > > > > >
> > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.dif
> > > > > > > >f
> > > > > > >
> > > > > > > Eh, there was a typo so I regenerated the diff.
> > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.dif
> > > > > > >f
> > > > > >
> > > > > > Hi
> > > > > > Just wanted to know before getting on to it, will your
> > > > > > patch help to resolve kern/136876?
> > > > >
> > > > > My diff includes a fix for assuming PCIe device control
> > > > > register and MSI control registers would be reside in fixed
> > > > > address. And from the pciconf output I see the your MSI
> > > > > control register is located at different address. However
> > > > > bge(4) does not touch that register for BCM5906 so I guess my
> > > > > diff may not fix the resume issue.
> > > >
> > > > Thanks a lot for your prompt, clear and straight answer.
> > >
> > > Would you try attached patch for BCM5906 resume issue? Not sure
> > > whether it help or not though.
> >
> > Hi Pyun!
> > Sorry for the delay, I was out of town and just got back.
> > I'm downloading RC3 as of now. Then I will install:
> > edit make.conf
> > edit src.conf
> > buildworld
> > buildkernel
> > installkernel
> > reboot
> >
> > mergemaster -p
> > make installworld
> > reboot
> >
> > cp bge.diff bge.patch
> > cd /usr/src/sys/dev/bge && patch < /path/to/patch
> > make
> > make install clean
> > kldunload if_bge
>
> Not sure you removed bge in GENERIC kernel configuration file.
>
> > kldload if_bge
> > pciconf -lcvb
> > ifconfig bge0 up
> > acpiconf -s3
> >
> > ... and hpefully .. resume from S3 ..
> >
> > Is that ok with you or would you like me to do it in another way?
>
> That's ok. At first I wanted to add WOL to wake up bge(4) with
> magic packet but bge(4) seems to require a lot of workaround for
> each controller and it's too complex to implement at this time.
> Just want to know whether bge(4) can resume from suspend.

Well, I proceeded as I told you I would, applied your patch and even if
it didn't solve the problem (bge still doesn't resume) at least it
improved the previous situation given that now it doesn't loop timing
out once and again as before.

You can find a tail from /var/log/messages in here:
http://pastebin.com/f643555f7

As you can see, the first 3 lines corresponds to "kldload if_bge"
Line number 4 is "acpiconf -s3"

At line number 17 bge0 finally fails and let's the machine wake up at
line 18.

Then, as soon as I could I issued a "ifconfig bge0" to see what I could
get .. that's what you can see from line 20 to line 41. (as you can see
in there, I found there are problems resuming umass devices as
well ... )

Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the way,
once unloaded, I could load it again but bge0 never showed
on "ifconfig".

Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... which
ended with pulling the pendrive out as the system coldn't umount it ...

I also found I get wpi0 messages on resume .. it spouts:
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
and then it let's the system resume.

All in all .. there's _a_lot_of_problems_on_resume_

Pyun, if you'd like me to try a new patch or to do some tests or
whatever, just let me know. I'm here awaiting orders :)

Best Regards
Gonzalo Nemmi
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: HP Pavillion does not power off

2009-11-16T10:05:35Z

On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote:

> On Mon, 9 Nov 2009, Jerry Marles wrote:
> > On Mon, 2009-11-09 at 20:23 +0000, Jerry Marles wrote:
> > > On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote:
> > > Hello,
> > > >
> > > > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is
> > > > that halt -p does not power it off. The light on the power button goes
> > > > off but I can hear that it is still running. If I hold down the power
> > > > button for a few seconds the power can be heard to go off but then it
> > > > boots right back up again. Windows and Linux can power it off
> > > > successfully.
> > > >
> > > > Regards
> > > >
> > > > Jerry Marles
> > > >
> > >
> > > with further investigation I have found that
> > >
> > > acpiconf -s 5 results in invalid sleep type (5)
> > >
> > > but acpiconf -s 4 powers it off successfully so if I could just make
> > > halt -p do whatever acpiconf -s 4 is doing the problem would be solved.
> > >
> > > any advice would be much appreciated.
> >
> > dmesg after boot -v is here http://www.marles.org/acpi/dmesg.txt
> >
> > sysctl hw.acpi is here http://www.marles.org/acpi/hwacpi.txt
> >
> > acpidump is here http://www.marles.org/acpi/acpidump.txt
>
> Seeing noone else has had a go:
>
> It seems pretty strange that acpiconf -s 4 powers it off properly.
> your hwacpi.txt only shows ..
>
> hw.acpi.supported_sleep_state: S1 S3 S4 S5
> hw.acpi.power_button_state: S5
> hw.acpi.sleep_button_state: S1
> hw.acpi.lid_switch_state: NONE
> hw.acpi.standby_state: S1
> hw.acpi.suspend_state: S3
> hw.acpi.sleep_delay: 1
> hw.acpi.s4bios: 0
> hw.acpi.verbose: 1
> hw.acpi.disable_on_reboot: 0
> hw.acpi.handle_reboot: 0
> hw.acpi.reset_video: 0
> hw.acpi.cpu.cx_lowest: C1
>
> .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened
> to your hw.acpi.thermal settings also, but .. just a long shot ..
>
> What happens if you set sysctl hw.acpi.power_button_state=S4 and then
> try halt -p ? .. probably better off using 'shutdown -p now' actually.
>
> cheers, Ian

That does change things in that now if I hold down the power button
after halt -p it just goes off rather than booting straight back up
again. So that is an improvement. Thanks.

Jerry

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Current problem reports assigned to freebsd-acpi@FreeBSD.org

2009-11-16T03:06:46Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error
o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness,
o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot
o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r
o kern/136808 acpi [acpi] panic when switching to s3
o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us
o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem
o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC
o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not
o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race?
o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D
o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop
o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode
f kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not
f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop
o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features
o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To
o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop
o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin
f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo
o amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem
o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc
o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H
o kern/118973 acpi [acpi]: Kernel panic with acpi boot
o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest
o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can
o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/114165 acpi [acpi] Dell C810 - ACPI problem
s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f
o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in
o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108017 acpi [acpi]: Acer Aspire 5600
o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320
o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975)
o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI
s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic,
s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be
o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1
f kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5
o i386/79081 acpi ACPI suspend/resume not working on HP nx6110
o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
s kern/73823 acpi [request] acpi / power-on by timer support
o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/69750 acpi Boot without ACPI failed on ASUS L5
o kern/56024 acpi ACPI suspend drains battery while in S3
o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700
o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop

54 problems total.

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: HP Pavillion does not power off

2009-11-14T21:58:13Z

On Mon, 9 Nov 2009, Jerry Marles wrote:
> On Mon, 2009-11-09 at 20:23 +0000, Jerry Marles wrote:
> > On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote:
> > Hello,
> > >
> > > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is
> > > that halt -p does not power it off. The light on the power button goes
> > > off but I can hear that it is still running. If I hold down the power
> > > button for a few seconds the power can be heard to go off but then it
> > > boots right back up again. Windows and Linux can power it off
> > > successfully.
> > >
> > > Regards
> > >
> > > Jerry Marles
> > >
> >
> > with further investigation I have found that
> >
> > acpiconf -s 5 results in invalid sleep type (5)
> >
> > but acpiconf -s 4 powers it off successfully so if I could just make
> > halt -p do whatever acpiconf -s 4 is doing the problem would be solved.
> >
> > any advice would be much appreciated.
>
> dmesg after boot -v is here http://www.marles.org/acpi/dmesg.txt
>
> sysctl hw.acpi is here http://www.marles.org/acpi/hwacpi.txt
>
> acpidump is here http://www.marles.org/acpi/acpidump.txt

Seeing noone else has had a go:

It seems pretty strange that acpiconf -s 4 powers it off properly.
your hwacpi.txt only shows ..

hw.acpi.supported_sleep_state: S1 S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 1
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 0
hw.acpi.reset_video: 0
hw.acpi.cpu.cx_lowest: C1

.. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened
to your hw.acpi.thermal settings also, but .. just a long shot ..

What happens if you set sysctl hw.acpi.power_button_state=S4 and then
try halt -p ? .. probably better off using 'shutdown -p now' actually.

cheers, Ian
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

ACPICA version 20091112 released

2009-11-12T10:42:12Z

12 November 2009. Summary of changes for version 20091112:

This release is available at www.acpica.org/downloads

1) ACPI CA Core Subsystem:

Implemented a post-order callback to AcpiWalkNamespace. The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more useful for bus scans. ACPICA BZ 779. Lin Ming. Updated the ACPICA Programmer Reference.

Modified the behavior of the operation region memory mapping cache for SystemMemory. Ensure that the memory mappings created for operation regions do not cross 4K page boundaries. Crossing a page boundary while mapping regions can cause kernel warnings on some hosts if the pages have different attributes. Such regions are probably BIOS bugs, and this is the workaround. Linux BZ 14445. Lin Ming.

Implemented an automatic repair for predefined methods that must return sorted lists. This change will repair (by sorting) packages returned by _ALR, _PSS, and _TSS. Drivers can now assume that the packages are correctly sorted and do not contain NULL package elements. Adds one new file, namespace/nsrepair2.c. ACPICA BZ 784. Lin Ming, Bob Moore.

Fixed a possible fault during predefined name validation if a return Package object contains NULL elements. Also adds a warning if a NULL element is followed by any non-null elements. ACPICA BZ 813, 814. Future enhancement may include repair or removal of all such NULL elements where possible.

Implemented additional module-level executable AML code support. This change will execute module-level code that is not at the root of the namespace (under a Device object, etc.) at table load time. Module-level executable AML code has been illegal since ACPI 2.0. ACPICA BZ 762. Lin Ming.

Implemented a new internal function to create Integer objects. This function simplifies miscellaneous object creation code. ACPICA BZ 823.

Reduced the severity of predefined repair messages, Warning to Info. Since the object was successfully repaired, a warning is too severe. Reduced to an info message for now. These messages may eventually be changed to debug-only. ACPICA BZ 812.

Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.

Previous Release:
Non-Debug Version: 85.8K Code, 18.0K Data, 103.8K Total
Debug Version: 161.8K Code, 50.6K Data, 212.4K Total
Current Release:
Non-Debug Version: 86.6K Code, 18.2K Data, 104.8K Total
Debug Version: 162.7K Code, 50.8K Data, 213.5K Total

2) iASL Compiler/Disassembler and Tools:

iASL: Implemented Switch() with While(1) so that Break works correctly. This change correctly implements the Switch operator with a surrounding While(1) so that the Break operator works as expected. ACPICA BZ 461. Lin Ming.

iASL: Added a message if a package initializer list is shorter than package length. Adds a new remark for a Package() declaration if an initializer list exists, but is shorter than the declared length of the package. Although technically legal, this is probably a coding error and it is seen in the field. ACPICA BZ 815. Lin Ming, Bob Moore.

iASL: Fixed a problem where the compiler could fault after the maximum number of errors was reached (200).

acpixtract: Fixed a possible warning for pointer cast if the compiler warning level set very high.

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-11T05:17:36Z

on 10/11/2009 20:42 Gavin Atkinson said the following:

> On Tue, 10 Nov 2009, Andriy Gapon wrote:
>> on 10/11/2009 13:54 Andriy Gapon said the following:
>>> on 09/11/2009 22:34 Gavin Atkinson said the following:
>> I think I've found one bug in the heci code that could cause this -
>> SLIST element
>> was first freed and then removed from the list.
>> I've uploaded updated sources (that should include your PCI ID too),
>> could you
>> please re-test?
>
> That seems to have fixed it, thanks! It also fixes the malloc() calls
> with locks held.
>
>> Could you please send me verbose version of driver attachment messages
>> (debug.bootverbose=1)?
>> Thank you!
>
> Sure!
>
> http://people.freebsd.org/~gavin/heci-verbose.txt

Thank you for the testing and data!

--
Andriy Gapon
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-10T11:04:08Z

Mykola Dzham wrote:

> Rui Paulo wrote:
> > On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote:
> >
> > > On Monday 09 November 2009 13:43:48 John Baldwin wrote:
> > >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
> > >>> Hi,
> > >>>
> > >>> I hope this is the correct list for an issue like that, if not, a
> > >>> pointer
> > >>> would be appreciated.
> > >>>
> > >>> I've been in contact with Mykola Dzham quite some time now and we
> > >>> are
> > >>> trying to figure out a resume issue on his iwn(4) device. It does
> > >>> seem
> > >>> that this device does not come up correctly after suspend. The
> > >>> interesting part is, that even pciconf -l -bcv ist not able to get
> > >>> all
> > >>> information.
> > >>>
> > >>> Before suspend:
> > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
> > >>> chip=0x42328086
> > >>> rev=0x00 hdr=0x00
> > >>> vendor = 'Intel Corporation'
> > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
> > >>> 5100)'
> > >>> class = network
> > >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192,
> > >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0
> > >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1
> > >>> message
> > >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
> > >>>
> > >>> After resume:
> > >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
> > >>> chip=0x42328086
> > >>> rev=0x00 hdr=0x00
> > >>> vendor = 'Intel Corporation'
> > >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
> > >>> 5100)'
> > >>> class = network
> > >>
> > >> Are you sure you didn't forget the extra options to pciconf here?
> > >> The bar
> > >> should definitely not disappear since we save that state in
> > >> software, not
> > >> in hardware. Also, the capability pointer register is set by the
> > >> hardware,
> > >> software never changes it.
> > >
> > > The complete pciconf before suspend:
> > > http://techwires.net/~bschmidt/pciconf.before.txt
> > > The complete pciconf after resume:
> > > http://techwires.net/~bschmidt/pciconf.after.txt
> > >
> > > Comparing both yields exactly those 4 lines missing.
> >
> > We should check if the device driver is doing something evil on
> > suspend/resume. Can you boot without iwn loaded and suspend/resume ?
>
> Same result.
> Before:
>
> none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> class = network
> bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
> cap 01[c8] = powerspec 3 supports D0 D3 current D0
> cap 05[d0] = MSI supports 1 message, 64 bit
> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
>
> After:
>
> none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> class = network

I tested possible pciconf output changes on em ethernet card on my
notebook (without if_iwn loaded) before and after suspend/resume. On
ethernet card no changes in output, same output before and after:

none0@pci0:0:25:0: class=0x020000 card=0x9025104d chip=0x10f58086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82567LM-2 Gigabit Network Connection (82567LM)'
class = network
subclass = ethernet
bar [10] = type Memory, range 32, base 0xee900000, size 131072, enabled
bar [14] = type Memory, range 32, base 0xee924000, size 4096, enabled
bar [18] = type I/O Port, range 32, base 0x8100, size 32, enabled
cap 01[c8] = powerspec 2 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 13[e0] = PCI Advanced Features: FLR TP

--
LEFT-(UANIC|RIPE)
JID: levsha@...
PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-10T10:42:26Z

On Tue, 10 Nov 2009, Andriy Gapon wrote:

> on 10/11/2009 13:54 Andriy Gapon said the following:
>> on 09/11/2009 22:34 Gavin Atkinson said the following:
>>> Secondly, I get a panic on module unlaod. I haven't spent any time
>>> looking at this, if you haven't fixed it yet let me know and I'll look
>>> into it further.
>>
>> To my shame I still haven't got around to testing the driver with head tree and
>> diagnostics enabled. I do not see any problems on stable/7 without diagnostics.
>> Robert Noland has reported that he had a lockup on module unload with head
>> sources. I will investigate this.
>> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
>> debugger reports it correctly). This looks like the memory was already freed.
>
> I think I've found one bug in the heci code that could cause this - SLIST element
> was first freed and then removed from the list.
> I've uploaded updated sources (that should include your PCI ID too), could you
> please re-test?

That seems to have fixed it, thanks! It also fixes the malloc() calls
with locks held.

> Could you please send me verbose version of driver attachment messages
> (debug.bootverbose=1)?
> Thank you!

Sure!

http://people.freebsd.org/~gavin/heci-verbose.txt

Gavin
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-10T09:12:48Z

on 10/11/2009 13:54 Andriy Gapon said the following:

> on 09/11/2009 22:34 Gavin Atkinson said the following:
>> Secondly, I get a panic on module unlaod. I haven't spent any time
>> looking at this, if you haven't fixed it yet let me know and I'll look
>> into it further.
>
> To my shame I still haven't got around to testing the driver with head tree and
> diagnostics enabled. I do not see any problems on stable/7 without diagnostics.
> Robert Noland has reported that he had a lockup on module unload with head
> sources. I will investigate this.
> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
> debugger reports it correctly). This looks like the memory was already freed.

I think I've found one bug in the heci code that could cause this - SLIST element
was first freed and then removed from the list.
I've uploaded updated sources (that should include your PCI ID too), could you
please re-test?

>> I'm not even sure how it's getting that far into the detach routine
>> before panicing, if dev really does = 0xdeadc0dedeadc0de
>>
>> #8 0xffffffff808580d3 in calltrap ()
>> at /usr/src/sys/amd64/amd64/exception.S:224
>> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
>> at /usr/src/sys/kern/kern_mutex.c:827
>> #10 0xffffffff812221c6 in heci_detach ()
>> from /usr/src/sys/modules/heci/heci.ko
>> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
>> at device_if.h:212
>> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
>> what=Variable "what" is not available.
>> ) at /usr/src/sys/kern/subr_bus.c:1156
>> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
>> at /usr/src/sys/kern/kern_module.c:266
>> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
>> flags=0) at /usr/src/sys/kern/kern_linker.c:633
>> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
>> fileid=Variable "fileid" is not available.
>> ) at /usr/src/sys/kern/kern_linker.c:1092
>>
>> Let me know if there's anything else I can test.
>>
>> Thanks,
>
> Nothing else I can think of right now.

OK, I came up with something :)
Could you please send me verbose version of driver attachment messages
(debug.bootverbose=1)?
Thank you!

BTW, Robert, you also promised me those :)

--
Andriy Gapon
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-10T03:54:09Z

on 09/11/2009 22:34 Gavin Atkinson said the following:

> On Wed, 14 Oct 2009, Andriy Gapon wrote:
>> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
>> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>>
>> I actually got around to implementing it (in initial/basic form):
>> http://people.freebsd.org/~avg/heci.tgz
>
> Nice!
>
> I've got the following device in my laptop:
>
> heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086
> rev=0x07 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel Management Engine Interface (Mobile 4 Series
> Chipset)'
> class = simple comms
>
> I've added this device to the code, and loaded it:
>
> heci0: <Intel ICH9 (Cantiga) Express HECI/MEI Controller> mem
> 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0

I will add this ID and name to the driver.

> heci0: using MSI
> heci0: [ITHREAD]
> heci0: found ME client at address 0x02:
> heci0: status = 0x00
> heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
> heci0: found ME client at address 0x06:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
> heci0: found ME client at address 0x07:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
> heci0: found ME client at address 0x20:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
> heci0: found ME client at address 0x21:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
> heci0: found ME client at address 0x22:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
> heci0: found ME client at address 0x23:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
> heci0: found ME client at address 0x24:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

Thanks a lot for testing!

> However, running the heci-qst.c program you supplied:
>
> psi# ./heci-qst
> ioctl HECI_CONNECT: No such file or directory
>
> And output to the console:
>
> heci0: could not find ME client with given guid:
> 6B5205B9-8185-4519-B889-D98724B58607
>
> Other than seeing that it doesn't appear in the list above, I don't know
> if this is expected or not...

Yes, this is expected if you don't have ME client with this GUID.
Perhaps, there is no QST firmware in the ME or it is disabled. Also, I am not
sure but I think that it could be possible that you have a newer version of QST
and its GUID is different. If you feel adventurous, you could try substituting
GUID value in heci-qst.c with values reported by the driver. Perhaps it would
work, perhaps you'd get a crash or hang or just an ioctl error.

> Secondly, I get a panic on module unlaod. I haven't spent any time
> looking at this, if you haven't fixed it yet let me know and I'll look
> into it further.

To my shame I still haven't got around to testing the driver with head tree and
diagnostics enabled. I do not see any problems on stable/7 without diagnostics.
Robert Noland has reported that he had a lockup on module unload with head
sources. I will investigate this.
BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
debugger reports it correctly). This looks like the memory was already freed.

> I'm not even sure how it's getting that far into the detach routine
> before panicing, if dev really does = 0xdeadc0dedeadc0de
>
> #8 0xffffffff808580d3 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:224
> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
> at /usr/src/sys/kern/kern_mutex.c:827
> #10 0xffffffff812221c6 in heci_detach ()
> from /usr/src/sys/modules/heci/heci.ko
> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
> at device_if.h:212
> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
> what=Variable "what" is not available.
> ) at /usr/src/sys/kern/subr_bus.c:1156
> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
> at /usr/src/sys/kern/kern_module.c:266
> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
> flags=0) at /usr/src/sys/kern/kern_linker.c:633
> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
> fileid=Variable "fileid" is not available.
> ) at /usr/src/sys/kern/kern_linker.c:1092
>
> Let me know if there's anything else I can test.
>
> Thanks,

Nothing else I can think of right now.
Thanks again!

--
Andriy Gapon
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: HP Pavillion does not power off

2009-11-09T14:23:00Z

On Mon, 2009-11-09 at 20:23 +0000, Jerry Marles wrote:

> On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote:
> Hello,
> >
> > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is
> > that halt -p does not power it off. The light on the power button goes
> > off but I can hear that it is still running. If I hold down the power
> > button for a few seconds the power can be heard to go off but then it
> > boots right back up again. Windows and Linux can power it off
> > successfully.
> >
> > Regards
> >
> > Jerry Marles
> >
>
> with further investigation I have found that
>
> acpiconf -s 5 results in invalid sleep type (5)
>
> but acpiconf -s 4 powers it off successfully so if I could just make
> halt -p do whatever acpiconf -s 4 is doing the problem would be solved.
>
> any advice would be much appreciated.

dmesg after boot -v is here http://www.marles.org/acpi/dmesg.txt

sysctl hw.acpi is here http://www.marles.org/acpi/hwacpi.txt

acpidump is here http://www.marles.org/acpi/acpidump.txt

_______________________________________________
> freebsd-acpi@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T14:00:27Z

Rui Paulo wrote:

> On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote:
>
> > On Monday 09 November 2009 13:43:48 John Baldwin wrote:
> >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
> >>> Hi,
> >>>
> >>> I hope this is the correct list for an issue like that, if not, a
> >>> pointer
> >>> would be appreciated.
> >>>
> >>> I've been in contact with Mykola Dzham quite some time now and we
> >>> are
> >>> trying to figure out a resume issue on his iwn(4) device. It does
> >>> seem
> >>> that this device does not come up correctly after suspend. The
> >>> interesting part is, that even pciconf -l -bcv ist not able to get
> >>> all
> >>> information.
> >>>
> >>> Before suspend:
> >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
> >>> chip=0x42328086
> >>> rev=0x00 hdr=0x00
> >>> vendor = 'Intel Corporation'
> >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
> >>> 5100)'
> >>> class = network
> >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192,
> >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0
> >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1
> >>> message
> >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
> >>>
> >>> After resume:
> >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
> >>> chip=0x42328086
> >>> rev=0x00 hdr=0x00
> >>> vendor = 'Intel Corporation'
> >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
> >>> 5100)'
> >>> class = network
> >>
> >> Are you sure you didn't forget the extra options to pciconf here?
> >> The bar
> >> should definitely not disappear since we save that state in
> >> software, not
> >> in hardware. Also, the capability pointer register is set by the
> >> hardware,
> >> software never changes it.
> >
> > The complete pciconf before suspend:
> > http://techwires.net/~bschmidt/pciconf.before.txt
> > The complete pciconf after resume:
> > http://techwires.net/~bschmidt/pciconf.after.txt
> >
> > Comparing both yields exactly those 4 lines missing.
>
> We should check if the device driver is doing something evil on
> suspend/resume. Can you boot without iwn loaded and suspend/resume ?

Same result.
Before:

none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network
bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
cap 01[c8] = powerspec 3 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)

After:

none1@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086 rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network

--
LEFT-(UANIC|RIPE)
JID: levsha@...
PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T13:34:30Z

John Baldwin wrote:

> On Monday 09 November 2009 1:14:18 pm Serge Semenenko wrote:
>
>> John Baldwin wrote:
>> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
>>
>> Hi,
>>
>> I hope this is the correct list for an issue like that, if not, a pointer
>> would be appreciated.
>>
>> I've been in contact with Mykola Dzham quite some time now and we are trying
>> to figure out a resume issue on his iwn(4) device. It does seem that this
>> device does not come up correctly after suspend. The interesting part is,
>>
> that
>
>> even pciconf -l -bcv ist not able to get all information.
>>
>> Before suspend:
>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
>> rev=0x00 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
>> class = network
>> bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
>> cap 01[c8] = powerspec 3 supports D0 D3 current D0
>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
>>
>> After resume:
>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
>> rev=0x00 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
>> class = network
>>
>>
>> Are you sure you didn't forget the extra options to pciconf here? The bar
>> should definitely not disappear since we save that state in software, not
>> in hardware. Also, the capability pointer register is set by the hardware,
>> software never changes it.
>>
>>
>>
>> It looks similar to PR http://www.freebsd.org/cgi/query-pr.cgi?pr=135070
>>
> for me. And if I understood right you're already working on the solution...
>
> No, having the capability registers and a BAR disappear after they were
> programmed is entirely different. That PR is about being able to allocate
> space for the BAR on boot, not about losing it entirely after resume.
>
>

Not sure about nature of things happened but on my system resources
programmed with mentioned in PR hack are also disappears on resume and
to get things working the hack should be applied both on attach and on
resume.

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-09T12:34:09Z

On Wed, 14 Oct 2009, Andriy Gapon wrote:
> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>
> I actually got around to implementing it (in initial/basic form):
> http://people.freebsd.org/~avg/heci.tgz

Nice!

I've got the following device in my laptop:

heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel Management Engine Interface (Mobile 4 Series Chipset)'
class = simple comms

I've added this device to the code, and loaded it:

heci0: <Intel ICH9 (Cantiga) Express HECI/MEI Controller> mem 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0
heci0: using MSI
heci0: [ITHREAD]
heci0: found ME client at address 0x02:
heci0: status = 0x00
heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
heci0: found ME client at address 0x06:
heci0: status = 0x00
heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
heci0: found ME client at address 0x07:
heci0: status = 0x00
heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
heci0: found ME client at address 0x20:
heci0: status = 0x00
heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
heci0: found ME client at address 0x21:
heci0: status = 0x00
heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
heci0: found ME client at address 0x22:
heci0: status = 0x00
heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
heci0: found ME client at address 0x23:
heci0: status = 0x00
heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
heci0: found ME client at address 0x24:
heci0: status = 0x00
heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

However, running the heci-qst.c program you supplied:

psi# ./heci-qst
ioctl HECI_CONNECT: No such file or directory

And output to the console:

heci0: could not find ME client with given guid: 6B5205B9-8185-4519-B889-D98724B58607

Other than seeing that it doesn't appear in the list above, I don't know
if this is expected or not...

Secondly, I get a panic on module unlaod. I haven't spent any time
looking at this, if you haven't fixed it yet let me know and I'll look
into it further.
I'm not even sure how it's getting that far into the detach routine before
panicing, if dev really does = 0xdeadc0dedeadc0de

#8 0xffffffff808580d3 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:224
#9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
at /usr/src/sys/kern/kern_mutex.c:827
#10 0xffffffff812221c6 in heci_detach ()
from /usr/src/sys/modules/heci/heci.ko
#11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
at device_if.h:212
#12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
what=Variable "what" is not available.
) at /usr/src/sys/kern/subr_bus.c:1156
#13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
at /usr/src/sys/kern/kern_module.c:266
#14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
flags=0) at /usr/src/sys/kern/kern_linker.c:633
#15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
fileid=Variable "fileid" is not available.
) at /usr/src/sys/kern/kern_linker.c:1092

Let me know if there's anything else I can test.

Thanks,

Gavin
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: HP Pavillion does not power off

2009-11-09T12:23:18Z

On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote:
Hello,

>
> I have a HP Pavillion desktop PC model g3001.uk. The problem I have is
> that halt -p does not power it off. The light on the power button goes
> off but I can hear that it is still running. If I hold down the power
> button for a few seconds the power can be heard to go off but then it
> boots right back up again. Windows and Linux can power it off
> successfully.
>
> Regards
>
> Jerry Marles
>

with further investigation I have found that

acpiconf -s 5 results in invalid sleep type (5)

but acpiconf -s 4 powers it off successfully so if I could just make
halt -p do whatever acpiconf -s 4 is doing the problem would be solved.

any advice would be much appreciated.

Regards

Jerry Marles

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T11:49:35Z

On Monday 09 November 2009 19:33:53 Rui Paulo wrote:

> On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote:
> > On Monday 09 November 2009 13:43:48 John Baldwin wrote:
> >> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
> >>> Hi,
> >>>
> >>> I hope this is the correct list for an issue like that, if not, a
> >>> pointer
> >>> would be appreciated.
> >>>
> >>> I've been in contact with Mykola Dzham quite some time now and we
> >>> are
> >>> trying to figure out a resume issue on his iwn(4) device. It does
> >>> seem
> >>> that this device does not come up correctly after suspend. The
> >>> interesting part is, that even pciconf -l -bcv ist not able to get
> >>> all
> >>> information.
> >>>
> >>> Before suspend:
> >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
> >>> chip=0x42328086
> >>> rev=0x00 hdr=0x00
> >>> vendor = 'Intel Corporation'
> >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
> >>> 5100)'
> >>> class = network
> >>> bar [10] = type Memory, range 64, base 0xec800000, size 8192,
> >>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0
> >>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1
> >>> message
> >>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
> >>>
> >>> After resume:
> >>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
> >>> chip=0x42328086
> >>> rev=0x00 hdr=0x00
> >>> vendor = 'Intel Corporation'
> >>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
> >>> 5100)'
> >>> class = network
> >>
> >> Are you sure you didn't forget the extra options to pciconf here?
> >> The bar
> >> should definitely not disappear since we save that state in
> >> software, not
> >> in hardware. Also, the capability pointer register is set by the
> >> hardware,
> >> software never changes it.
> >
> > The complete pciconf before suspend:
> > http://techwires.net/~bschmidt/pciconf.before.txt
> > The complete pciconf after resume:
> > http://techwires.net/~bschmidt/pciconf.after.txt
> >
> > Comparing both yields exactly those 4 lines missing.
>
> We should check if the device driver is doing something evil on
> suspend/resume. Can you boot without iwn loaded and suspend/resume ?

I'm sorry if it might came out wrong in my first email. It's Mykola Dzham's
system which has those issue, I'm posting all information on prior discussions
with him.

I can suspend/resume with iwn loaded, device works after resume as its
supposed to.

For him kldload/kldunload does work too, those issues just come up after
suspend. Based on that I had doubts that it is a general issue with the iwn
driver.

--
Bernhard
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T11:01:30Z

On Monday 09 November 2009 1:14:18 pm Serge Semenenko wrote:

> John Baldwin wrote:
> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
>
> Hi,
>
> I hope this is the correct list for an issue like that, if not, a pointer
> would be appreciated.
>
> I've been in contact with Mykola Dzham quite some time now and we are trying
> to figure out a resume issue on his iwn(4) device. It does seem that this
> device does not come up correctly after suspend. The interesting part is,

that

> even pciconf -l -bcv ist not able to get all information.
>
> Before suspend:
> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> class = network
> bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
> cap 01[c8] = powerspec 3 supports D0 D3 current D0
> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
>
> After resume:
> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> class = network
>
>
> Are you sure you didn't forget the extra options to pciconf here? The bar
> should definitely not disappear since we save that state in software, not
> in hardware. Also, the capability pointer register is set by the hardware,
> software never changes it.
>
>
>
> It looks similar to PR http://www.freebsd.org/cgi/query-pr.cgi?pr=135070

for me. And if I understood right you're already working on the solution...

No, having the capability registers and a BAR disappear after they were
programmed is entirely different. That PR is about being able to allocate
space for the BAR on boot, not about losing it entirely after resume.

--
John Baldwin
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T10:33:53Z

On 9 Nov 2009, at 17:03, Bernhard Schmidt wrote:

> On Monday 09 November 2009 13:43:48 John Baldwin wrote:
>> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
>>> Hi,
>>>
>>> I hope this is the correct list for an issue like that, if not, a
>>> pointer
>>> would be appreciated.
>>>
>>> I've been in contact with Mykola Dzham quite some time now and we
>>> are
>>> trying to figure out a resume issue on his iwn(4) device. It does
>>> seem
>>> that this device does not come up correctly after suspend. The
>>> interesting part is, that even pciconf -l -bcv ist not able to get
>>> all
>>> information.
>>>
>>> Before suspend:
>>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
>>> chip=0x42328086
>>> rev=0x00 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
>>> 5100)'
>>> class = network
>>> bar [10] = type Memory, range 64, base 0xec800000, size 8192,
>>> enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0
>>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1
>>> message
>>> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
>>>
>>> After resume:
>>> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086
>>> chip=0x42328086
>>> rev=0x00 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link
>>> 5100)'
>>> class = network
>>
>> Are you sure you didn't forget the extra options to pciconf here?
>> The bar
>> should definitely not disappear since we save that state in
>> software, not
>> in hardware. Also, the capability pointer register is set by the
>> hardware,
>> software never changes it.
>
> The complete pciconf before suspend:
> http://techwires.net/~bschmidt/pciconf.before.txt
> The complete pciconf after resume:
> http://techwires.net/~bschmidt/pciconf.after.txt
>
> Comparing both yields exactly those 4 lines missing.

We should check if the device driver is doing something evil on
suspend/resume. Can you boot without iwn loaded and suspend/resume ?

--
Rui Paulo

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T10:14:18Z

John Baldwin wrote:

On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:

Hi,

I hope this is the correct list for an issue like that, if not, a pointer
would be appreciated.

I've been in contact with Mykola Dzham quite some time now and we are trying
to figure out a resume issue on his iwn(4) device. It does seem that this
device does not come up correctly after suspend. The interesting part is, that
even pciconf -l -bcv ist not able to get all information.

Before suspend:
iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network
bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
cap 01[c8] = powerspec 3 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)

After resume:
iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network

Are you sure you didn't forget the extra options to pciconf here? The bar
should definitely not disappear since we save that state in software, not
in hardware. Also, the capability pointer register is set by the hardware,
software never changes it.

It looks similar to PR
[1]http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 for me. And if I
understood right you're already working on the solution...

References

1. http://www.freebsd.org/cgi/query-pr.cgi?pr=135070
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T09:03:18Z

On Monday 09 November 2009 13:43:48 John Baldwin wrote:

> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
> > Hi,
> >
> > I hope this is the correct list for an issue like that, if not, a pointer
> > would be appreciated.
> >
> > I've been in contact with Mykola Dzham quite some time now and we are
> > trying to figure out a resume issue on his iwn(4) device. It does seem
> > that this device does not come up correctly after suspend. The
> > interesting part is, that even pciconf -l -bcv ist not able to get all
> > information.
> >
> > Before suspend:
> > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> > rev=0x00 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> > class = network
> > bar [10] = type Memory, range 64, base 0xec800000, size 8192,
> > enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0
> > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
> >
> > After resume:
> > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> > rev=0x00 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> > class = network
>
> Are you sure you didn't forget the extra options to pciconf here? The bar
> should definitely not disappear since we save that state in software, not
> in hardware. Also, the capability pointer register is set by the hardware,
> software never changes it.

The complete pciconf before suspend:
http://techwires.net/~bschmidt/pciconf.before.txt
The complete pciconf after resume:
http://techwires.net/~bschmidt/pciconf.after.txt

Comparing both yields exactly those 4 lines missing.

--
Bernhard
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T08:11:03Z

John Baldwin wrote:

> On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:
> > Hi,
> >
> > I hope this is the correct list for an issue like that, if not, a pointer
> > would be appreciated.
> >
> > I've been in contact with Mykola Dzham quite some time now and we are trying
> > to figure out a resume issue on his iwn(4) device. It does seem that this
> > device does not come up correctly after suspend. The interesting part is, that
> > even pciconf -l -bcv ist not able to get all information.
> >
> > Before suspend:
> > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> > rev=0x00 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> > class = network
> > bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
> > cap 01[c8] = powerspec 3 supports D0 D3 current D0
> > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
> >
> > After resume:
> > iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> > rev=0x00 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> > class = network
>
> Are you sure you didn't forget the extra options to pciconf here? The bar
> should definitely not disappear since we save that state in software, not
> in hardware. Also, the capability pointer register is set by the hardware,
> software never changes it.

Sure. I saved all pciconf -l -bcv (all devices). Difference is only in
this lines and in on unuased cardbus:

--- pciconf.before.txt 2009-11-07 21:38:21.000000000 +0200
+++ pciconf.after.txt 2009-11-07 21:38:21.000000000 +0200
@@ -180,16 +180,12 @@
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network
- bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
- cap 01[c8] = powerspec 3 supports D0 D3 current D0
- cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
- cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
none1@pci0:11:4:0: class=0x060700 card=0x9025104d chip=0x04761180 rev=0xba hdr=0x02
vendor = 'Ricoh Company, Ltd.'
device = 'Ricoh R/RL/5C476(II) (unknown)'
class = bridge
subclass = PCI-CardBus
- bar [10] = type Memory, range 32, base 0xe8000000, size 4096, enabled
+ bar [10] = type Memory, range 32, base 0xe8000000, size 4096, disabled
cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0
fwohci0@pci0:11:4:1: class=0x0c0010 card=0x9025104d chip=0x08321180 rev=0x04 hdr=0x00
vendor = 'Ricoh Company, Ltd.'

--
LEFT-(UANIC|RIPE)
JID: levsha@...
PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: general issue with suspend/resume with iwn(4)/bge(4)

2009-11-09T04:43:48Z

On Sunday 08 November 2009 6:19:09 am Bernhard Schmidt wrote:

> Hi,
>
> I hope this is the correct list for an issue like that, if not, a pointer
> would be appreciated.
>
> I've been in contact with Mykola Dzham quite some time now and we are trying
> to figure out a resume issue on his iwn(4) device. It does seem that this
> device does not come up correctly after suspend. The interesting part is, that
> even pciconf -l -bcv ist not able to get all information.
>
> Before suspend:
> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> class = network
> bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
> cap 01[c8] = powerspec 3 supports D0 D3 current D0
> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
>
> After resume:
> iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
> class = network

Are you sure you didn't forget the extra options to pciconf here? The bar
should definitely not disappear since we save that state in software, not
in hardware. Also, the capability pointer register is set by the hardware,
software never changes it.

--
John Baldwin
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Current problem reports assigned to freebsd-acpi@FreeBSD.org

2009-11-09T03:06:45Z

general issue with suspend/resume with iwn(4)/bge(4)

2009-11-08T03:19:09Z

Hi,

I hope this is the correct list for an issue like that, if not, a pointer
would be appreciated.

I've been in contact with Mykola Dzham quite some time now and we are trying
to figure out a resume issue on his iwn(4) device. It does seem that this
device does not come up correctly after suspend. The interesting part is, that
even pciconf -l -bcv ist not able to get all information.

Before suspend:
iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network
bar [10] = type Memory, range 64, base 0xec800000, size 8192, enabled
cap 01[c8] = powerspec 3 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)

After resume:
iwn0@pci0:6:0:0: class=0x028000 card=0x13018086 chip=0x42328086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Carte Intel WiFi Link 5100 AGN (Intel WiFi Link 5100)'
class = network

Note the last 4 missing lines. After a bit of searching i stumbled across
kern/136876 which described a very similar (same?) issue for a bge(4) device.
The question now is, might there be any special "power management" feature
which prevents proper resume? How might a solution look like?

Thanks.

--
Bernhard
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

HP Pavillion does not power off

2009-11-08T02:41:02Z

Hello,

I have a HP Pavillion desktop PC model g3001.uk. The problem I have is
that halt -p does not power it off. The light on the power button goes
off but I can hear that it is still running. If I hold down the power
button for a few seconds the power can be heard to go off but then it
boots right back up again. Windows and Linux can power it off
successfully.

Regards

Jerry Marles

sysctl hw.acpi

hw.acpi.supported_sleep_state: S1 S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 1
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 0
hw.acpi.reset_video: 0
hw.acpi.cpu.cx_lowest: C1

dmesg after boot -v

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009
root@...:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e67000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0e67174.
Calibrating clock(s) ... i8254 clock: 1193153 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2992521060 Hz
CPU: Intel(R) Pentium(R) D CPU 3.00GHz (2992.52-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf65 Stepping = 5

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0xe49d<SSE3,DTES64,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR,PDCM>
AMD Features=0x20100000<NX,LM>
AMD Features2=0x1<LAHF>
Cores per package: 2

Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128
entries
Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries
1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64
byte line size
Trace cache: 12K-uops, 8-way set associative
2nd-level cache: 2-MB, 8-way set associative, 64-byte line size
L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line
real memory = 2138832896 (2039 MB)
Physical memory chunk(s):
0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages)
0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)
0x0000000001025000 - 0x000000007d38ffff, 2083958784 bytes (508779 pages)
avail memory = 2083315712 (1986 MB)
Table 'FACP' at 0x7f7c0200
Table 'APIC' at 0x7f7c0390
MADT: Found table at 0x7f7c0390
MP Configuration Table version 1.4 found at 0xc00fd190
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 2: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 130 ACPI ID 3: disabled
MADT: Found CPU APIC ID 131 ACPI ID 4: disabled
ACPI APIC Table: <HPQOEM SLIC-CPC>
INTR: Adding local APIC 1 as a target
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
bios32: Found BIOS32 Service Directory header at 0xc00f0000
bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xf0000+0x31
pnpbios: Found PnP BIOS data at 0xc00f57a0
pnpbios: Entry = f0000:6e6a Rev = 1.0
Other BIOS signatures found:
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
ULE: setup cpu group 0
ULE: setup cpu 0
ULE: adding cpu 0 to group 0: cpus 1 mask 0x1
ULE: setup cpu group 1
ULE: setup cpu 1
ULE: adding cpu 1 to group 1: cpus 1 mask 0x2
ACPI: RSDP @ 0x0xf9850/0x0014 (v 0 HPQOEM)
ACPI: RSDT @ 0x0x7f7c0000/0x0040 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
ACPI: FACP @ 0x0x7f7c0200/0x0084 (v 2 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
ACPI: DSDT @ 0x0x7f7c0600/0x5312 (v 1 HPQOEM SLIC-CPC 0x00000010 INTL
0x20051117)
ACPI: FACS @ 0x0x7f7ce000/0x0040
ACPI: APIC @ 0x0x7f7c0390/0x006C (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
ACPI: MCFG @ 0x0x7f7c0440/0x003C (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
ACPI: SLIC @ 0x0x7f7c0480/0x0176 (v 1 HPQOEM SLIC-CPC 0x00000001 MSFT
0x00000001)
ACPI: DBGP @ 0x0x7f7c0400/0x0034 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
ACPI: OEMB @ 0x0x7f7ce040/0x0061 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
ACPI: HPET @ 0x0x7f7c59c0/0x0038 (v 1 HPQOEM SLIC-CPC 0x20070706 MSFT
0x00000097)
MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000
ioapic0: Routing external 8259A's -> intpin 0
MADT: Interrupt override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
MADT: Interrupt override: source 9, irq 9
ioapic0: intpin 9 trigger: level
ioapic0 <Version 2.0> irqs 0-23 on motherboard
cpu0 BSP:
ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000
wlan_amrr: <AMRR Transmit Rate Control Algorithm>
wlan: <802.11 Link Layer>
null: <null device, zero device>
random: <entropy source, Software, Yarrow>
nfslock: pseudo-device
io: <I/O>
kbd: new array size 4
kbd1 at kbdmux0
mem: <memory>
Pentium Pro MTRR support enabled
hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (May 1 2009
08:47:24)
npx0: INT 16 interface
acpi0: <HPQOEM SLIC-CPC> on motherboard
ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48
acpi0: [MPSAFE]
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: wakeup code va 0xc507c000 pa 0x1000
pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090
pci_open(1a): mode1res=0x80000000 (0x80000000)
pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27708086)
pcibios: BIOS version 3.00
AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0
AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.FHR0 -> bus 0 dev 31 func 0
AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0
acpi0: reservation of 0, a0000 (3) failed
ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pci_link0: Index IRQ Rtd Ref IRQs
Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link1: Index IRQ Rtd Ref IRQs
Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link2: Index IRQ Rtd Ref IRQs
Initial Probe 0 7 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 7 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link3: Index IRQ Rtd Ref IRQs
Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link4: Index IRQ Rtd Ref IRQs
Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link5: Index IRQ Rtd Ref IRQs
Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link6: Index IRQ Rtd Ref IRQs
Initial Probe 0 4 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 4 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
pci_link7: Index IRQ Rtd Ref IRQs
Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15
Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15
After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
acpi0
acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route
64-bit
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: domain=0, physical bus=0
found-> vendor=0x8086, dev=0x2770, revid=0x02
domain=0, bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x2772, revid=0x02
domain=0, bus=0, slot=2, func=0
class=03-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
powerspec 2 supports D0 D3 current D0
MSI supports 1 message
map[10]: type Memory, range 32, base 0xffa80000, size 19, enabled
map[14]: type I/O Port, range 32, base 0xec00, size 3, enabled
map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28,
enabled
map[1c]: type Memory, range 32, base 0xffa40000, size 18, enabled
pcib0: matched entry for 0.2.INTA
pcib0: slot 2 INTA hardwired to IRQ 16
found-> vendor=0x8086, dev=0x27d8, revid=0x01
domain=0, bus=0, slot=27, func=0
class=04-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
powerspec 2 supports D0 D3 current D0
MSI supports 1 message, 64 bit
map[10]: type Memory, range 64, base 0xffa3c000, size 14, enabled
pcib0: matched entry for 0.27.INTA
pcib0: slot 27 INTA hardwired to IRQ 16
found-> vendor=0x8086, dev=0x27d0, revid=0x01
domain=0, bus=0, slot=28, func=0
class=06-04-00, hdrtype=0x01, mfdev=1
cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
powerspec 2 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTA
pcib0: slot 28 INTA hardwired to IRQ 16
found-> vendor=0x8086, dev=0x27d2, revid=0x01
domain=0, bus=0, slot=28, func=1
class=06-04-00, hdrtype=0x01, mfdev=1
cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
intpin=b, irq=11
powerspec 2 supports D0 D3 current D0
MSI supports 1 message
pcib0: matched entry for 0.28.INTB
pcib0: slot 28 INTB hardwired to IRQ 17
found-> vendor=0x8086, dev=0x27c8, revid=0x01
domain=0, bus=0, slot=29, func=0
class=0c-03-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=3
map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled
pcib0: matched entry for 0.29.INTA
pcib0: slot 29 INTA hardwired to IRQ 23
found-> vendor=0x8086, dev=0x27c9, revid=0x01
domain=0, bus=0, slot=29, func=1
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=5
map[20]: type I/O Port, range 32, base 0xdc00, size 5, enabled
pcib0: matched entry for 0.29.INTB
pcib0: slot 29 INTB hardwired to IRQ 19
found-> vendor=0x8086, dev=0x27ca, revid=0x01
domain=0, bus=0, slot=29, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=7
map[20]: type I/O Port, range 32, base 0xd880, size 5, enabled
pcib0: matched entry for 0.29.INTC
pcib0: slot 29 INTC hardwired to IRQ 18
found-> vendor=0x8086, dev=0x27cb, revid=0x01
domain=0, bus=0, slot=29, func=3
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=d, irq=10
map[20]: type I/O Port, range 32, base 0xd800, size 5, enabled
pcib0: matched entry for 0.29.INTD
pcib0: slot 29 INTD hardwired to IRQ 16
found-> vendor=0x8086, dev=0x27cc, revid=0x01
domain=0, bus=0, slot=29, func=7
class=0c-03-20, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=3
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 32, base 0xffa3bc00, size 10, enabled
pcib0: matched entry for 0.29.INTA
pcib0: slot 29 INTA hardwired to IRQ 23
found-> vendor=0x8086, dev=0x244e, revid=0xe1
domain=0, bus=0, slot=30, func=0
class=06-04-01, hdrtype=0x01, mfdev=0
cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x27b8, revid=0x01
domain=0, bus=0, slot=31, func=0
class=06-01-00, hdrtype=0x00, mfdev=1
cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x27df, revid=0x01
domain=0, bus=0, slot=31, func=1
class=01-01-8a, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=255
map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled
found-> vendor=0x8086, dev=0x27c0, revid=0x01
domain=0, bus=0, slot=31, func=2
class=01-01-8f, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=5
powerspec 2 supports D0 D3 current D0
map[10]: type I/O Port, range 32, base 0xe880, size 3, enabled
map[14]: type I/O Port, range 32, base 0xe800, size 2, enabled
map[18]: type I/O Port, range 32, base 0xe480, size 3, enabled
map[1c]: type I/O Port, range 32, base 0xe400, size 2, enabled
map[20]: type I/O Port, range 32, base 0xe080, size 4, enabled
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
found-> vendor=0x8086, dev=0x27da, revid=0x01
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=5
map[20]: type I/O Port, range 32, base 0x400, size 5, enabled
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
vgapci0: <VGA-compatible display> port 0xec00-0xec07 mem
0xffa80000-0xffafffff,0xd0000000-0xdfffffff,0xffa40000-0xffa7ffff irq 16
at device 2.0 on pci0
agp0: <Intel 82945G (945G GMCH) SVGA controller> on vgapci0
vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000
vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffa80000
vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xffa40000
agp0: detected 7932k stolen memory
agp0: aperture size is 256M
pci0: <multimedia, HDA> at device 27.0 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pcib1: domain 0
pcib1: secondary bus 1
pcib1: subordinate bus 1
pcib1: I/O decode 0x0-0x0
pcib1: no prefetched decode
pci1: <ACPI PCI bus> on pcib1
pci1: domain=0, physical bus=1
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.1 on pci0
pcib2: domain 0
pcib2: secondary bus 2
pcib2: subordinate bus 2
pcib2: I/O decode 0xc000-0xcfff
pcib2: memory decode 0xff700000-0xff7fffff
pcib2: no prefetched decode
pci2: <ACPI PCI bus> on pcib2
pci2: domain=0, physical bus=2
found-> vendor=0x10ec, dev=0x8136, revid=0x01
domain=0, bus=2, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=11
powerspec 2 supports D0 D1 D2 D3 current D0
MSI supports 2 messages, 64 bit
map[10]: type I/O Port, range 32, base 0xc800, size 8, enabled
pcib2: requested I/O range 0xc800-0xc8ff: in range
map[18]: type Memory, range 64, base 0xff7ff000, size 12, enabled
pcib2: requested memory range 0xff7ff000-0xff7fffff: good
pcib2: matched entry for 2.0.INTA
pcib2: slot 0 INTA hardwired to IRQ 17
re0: <RealTek 8101E/8102E/8102EL PCIe 10/100baseTX> port 0xc800-0xc8ff
mem 0xff7ff000-0xff7fffff irq 17 at device 0.0 on pci2
re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xff7ff000
re0: MSI count : 2
re0: attempting to allocate 1 MSI vectors (2 supported)
msi: routing MSI IRQ 256 to vector 50
re0: using IRQ 256 for MSI
re0: Using 1 MSI messages
re0: Chip rev. 0x34000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rlphy0: <RTL8201L 10/100 media interface> PHY 1 on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: bpf attached
re0: Ethernet address: 00:1c:25:26:af:a4
re0: [MPSAFE]
re0: [FILTER]
uhci0: <UHCI (generic) USB controller> port 0xe000-0xe01f irq 23 at
device 29.0 on pci0
uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000
ioapic0: routing intpin 23 (PCI IRQ 23) to vector 49
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <UHCI (generic) USB controller> port 0xdc00-0xdc1f irq 19 at
device 29.1 on pci0
uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdc00
ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <UHCI (generic) USB controller> port 0xd880-0xd89f irq 18 at
device 29.2 on pci0
uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd880
ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <UHCI (generic) USB controller> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <UHCI (generic) USB controller> port 0xd800-0xd81f irq 16 at
device 29.3 on pci0
uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800
ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <UHCI (generic) USB controller> on uhci3
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem
0xffa3bc00-0xffa3bfff irq 23 at device 29.7 on pci0
ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xffa3bc00
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pcib3: domain 0
pcib3: secondary bus 3
pcib3: subordinate bus 3
pcib3: I/O decode 0x0-0x0
pcib3: memory decode 0xff800000-0xff8fffff
pcib3: no prefetched decode
pcib3: Subtractively decoded bridge.
pci3: <ACPI PCI bus> on pcib3
pci3: domain=0, physical bus=3
found-> vendor=0x168c, dev=0x0013, revid=0x01
domain=0, bus=3, slot=1, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0016, statreg=0x0290, cachelnsz=8 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns)
intpin=a, irq=4
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 32, base 0xff8f0000, size 16, enabled
pcib3: requested memory range 0xff8f0000-0xff8fffff: good
pcib3: matched entry for 3.1.INTA
pcib3: slot 1 INTA hardwired to IRQ 22
ath0: <Atheros 5212> mem 0xff8f0000-0xff8fffff irq 22 at device 1.0 on
pci3
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xff8f0000
ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54
ath0: [MPSAFE]
ath0: [ITHREAD]
ath0: hal channel 2412/a0 -> 1
ath0: hal channel 2412/c0 -> 1
ath0: hal channel 2417/a0 -> 2
ath0: hal channel 2417/c0 -> 2
ath0: hal channel 2422/a0 -> 3
ath0: hal channel 2422/c0 -> 3
ath0: hal channel 2427/a0 -> 4
ath0: hal channel 2427/c0 -> 4
ath0: hal channel 2432/a0 -> 5
ath0: hal channel 2432/c0 -> 5
ath0: hal channel 2437/a0 -> 6
ath0: hal channel 2437/c0 -> 6
ath0: hal channel 2437/d0 -> 6
ath0: hal channel 2442/a0 -> 7
ath0: hal channel 2442/c0 -> 7
ath0: hal channel 2447/a0 -> 8
ath0: hal channel 2447/c0 -> 8
ath0: hal channel 2452/a0 -> 9
ath0: hal channel 2452/c0 -> 9
ath0: hal channel 2457/a0 -> 10
ath0: hal channel 2457/c0 -> 10
ath0: hal channel 2462/a0 -> 11
ath0: hal channel 2462/c0 -> 11
ath0: WARNING: using obsoleted if_watchdog interface
ath0: bpf attached
ath0: Ethernet address: 00:0f:b5:f8:27:3b
ath0: bpf attached
ath0: bpf attached
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps
ath0: mac 7.9 phy 4.5 radio 5.6
ath0: Use hw queue 1 for WME_AC_BE traffic
ath0: Use hw queue 0 for WME_AC_BK traffic
ath0: Use hw queue 2 for WME_AC_VI traffic
ath0: Use hw queue 3 for WME_AC_VO traffic
ath0: Use hw queue 8 for CAB traffic
ath0: Use hw queue 9 for beacons
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH7 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0
ata0: <ATA channel 0> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
ata0: reset tp1 mask=03 ostat0=50 ostat1=00
ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
ata0: reset tp2 stat0=50 stat1=00 devices=0x1<ATA_MASTER>
ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55
ata0: [MPSAFE]
ata0: [ITHREAD]
atapci1: <Intel ICH7 SATA300 controller> port
0xe880-0xe887,0xe800-0xe803,0xe480-0xe487,0xe400-0xe403,0xe080-0xe08f
irq 19 at device 31.2 on pci0
atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe080
atapci1: [MPSAFE]
atapci1: [ITHREAD]
ata2: <ATA channel 0> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xe880
atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xe800
ata2: reset tp1 mask=03 ostat0=50 ostat1=00
ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
ata2: reset tp2 stat0=50 stat1=00 devices=0x1<ATA_MASTER>
ata2: [MPSAFE]
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe480
atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xe400
ata3: reset tp1 mask=03 ostat0=00 ostat1=00
ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata3: reset tp2 stat0=00 stat1=00 devices=0xc<ATAPI_SLAVE,ATAPI_MASTER>
ata3: [MPSAFE]
ata3: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_button0: <Power Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0065
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: unable to allocate IRQ
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons
psm0: config:00000000, flags:00000008, packet size:4
psm0: syncmask:08, syncbits:00
cpu0: <ACPI CPU> on acpi0
ACPI: SSDT @ 0x0x7f7ce0b0/0x01D2 (v 1 AMI CPU1PM 0x00000001 INTL
0x20051117)
cpu0: switching to generic Cx mode
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est0: Invalid id16 (set, cur) = (3104, 3111)
est0: Invalid freq 2400, ignored.
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
ACPI: SSDT @ 0x0x7f7ce290/0x0143 (v 1 AMI CPU2PM 0x00000001 INTL
0x20051117)
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est1: Invalid id16 (set, cur) = (3104, 3111)
est1: Invalid freq 2400, ignored.
p4tcc1: <CPU Frequency Thermal Control> on cpu1
unknown: status reg test failed ff
unknown: status reg test failed ff
unknown: status reg test failed ff
unknown: status reg test failed ff
unknown: status reg test failed ff
unknown: status reg test failed ff
ahc_isa_probe 13: ioport 0xdc00 alloc failed
ahc_isa_probe 14: ioport 0xec00 alloc failed
ex_isa_identify()
ata: ata0 already exists; skipping it
atkbdc: atkbdc0 already exists; skipping it
pnp_identify: Trying Read_Port at 203
pnp_identify: Trying Read_Port at 243
pnp_identify: Trying Read_Port at 283
pnp_identify: Trying Read_Port at 2c3
pnp_identify: Trying Read_Port at 303
pnp_identify: Trying Read_Port at 343
pnp_identify: Trying Read_Port at 383
pnp_identify: Trying Read_Port at 3c3
PNP Identify complete
sc: sc0 already exists; skipping it
vga: vga0 already exists; skipping it
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
pmtimer0 on isa0
adv0: not probed (disabled)
aha0: not probed (disabled)
aic0: not probed (disabled)
ata1 failed to probe at port 0x170 irq 15 on isa0
bt0: not probed (disabled)
cs0: not probed (disabled)
ed0: not probed (disabled)
fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fe0: not probed (disabled)
ie0: not probed (disabled)
le0: not probed (disabled)
ppc0: parallel port not found.
ppc0: <Parallel port> failed to probe at irq 7 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sc0: fb0, kbd1, terminal emulator: sc (syscons terminal)
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: irq maps: 0x4cb9 0x4cb9 0x4cb9 0x4cb9
sio0: probe failed test(s): 0 1 2 4 6 7 9
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: irq maps: 0x4cb9 0x4cb9 0x4cb9 0x4cb9
sio0: probe failed test(s): 0 1 2 4 6 7 9
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1: irq maps: 0x4cb9 0x4cb9 0x4cb9 0x4cb9
sio1: probe failed test(s): 0 1 2 4 6 7 9
sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0
sio2: not probed (disabled)
sio3: not probed (disabled)
sn0: not probed (disabled)
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0
vt0: not probed (disabled)
isa_probe_children: probing PnP devices
Device configuration finished.
Reducing kern.maxvnodes 133590 -> 100000
procfs registered
lapic: Divisor 2, Frequency 99750708 hz
Timecounter "TSC" frequency 2992521060 Hz quality -100
Timecounters tick every 1.000 msec
lo0: bpf attached
hptrr: no controller detected.
ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire
ad0: setting PIO4 on ICH7 chip
ad0: setting UDMA100 on ICH7 chip
ad0: 114473MB <Seagate ST3120213A 2AAA> at ata0-master UDMA100
ad0: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth
queue
GEOM: new disk ad0
ad0: Intel check1 failed
ad0: Adaptec check1 failed
ad0: LSI (v3) check1 failed
ad0: LSI (v2) check1 failed
ad0: FreeBSD check1 failed
ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire
ad4: 114473MB <Seagate ST3120213AS 3.AHL> at ata2-master SATA150
ad4: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth
queue
ad4: Intel check1 failed
ad4: Adaptec check1 failed
ad4: LSI (v3) check1 failed
ad4: LSI (v2) check1 failed
ad4: FreeBSD check1 failed
GEOM: new disk ad4
GEOM_LABEL: Label for provider ad0s3a is ufsid/4af56ad7460adb4d.
GEOM_LABEL: Label for provider ad0s3d is ufsid/4af56ad9ae586101.
GEOM_LABEL: Label for provider ad0s3e is ufsid/4af56ad89984eff9.
GEOM_LABEL: Label for provider ad0s3f is ufsid/4af56ad8f8d7e5eb.
GEOM_LABEL: Label for provider ad0s5 is ext2fs//.
GEOM_LABEL: Label for provider ad4s1 is ext2fs//1.
ata3: reiniting channel ..
ata3: reset tp1 mask=03 ostat0=00 ostat1=00
ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata3: reset tp2 stat0=00 stat1=00 devices=0xc<ATAPI_SLAVE,ATAPI_MASTER>
ata3: reinit done ..
ata3: reiniting channel ..
ata3: reset tp1 mask=03 ostat0=00 ostat1=00
ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata3: reset tp2 stat0=00 stat1=00 devices=0xc<ATAPI_SLAVE,ATAPI_MASTER>
ata3: reinit done ..
ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire
acd0: <HL-DT-STDVDRRW GSA-H30L/S856> DVDR drive at ata3 as master
acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 2048KB buffer,
SATA150
acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet
acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof
acd0: Mechanism: ejectable tray, unlocked
acd0: Medium: no/blank disc
ATA PseudoRAID loaded
SMP: AP CPU #1 Launched!
cpu1 AP:
ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000
ioapic0: Assigning ISA IRQ 1 to local APIC 0
ioapic0: Assigning ISA IRQ 4 to local APIC 1
ioapic0: Assigning ISA IRQ 9 to local APIC 0
ioapic0: Assigning ISA IRQ 12 to local APIC 1
ioapic0: Assigning ISA IRQ 14 to local APIC 0
ioapic0: Assigning PCI IRQ 16 to local APIC 1
ioapic0: Assigning PCI IRQ 18 to local APIC 0
ioapic0: Assigning PCI IRQ 19 to local APIC 1
ioapic0: Assigning PCI IRQ 22 to local APIC 0
ioapic0: Assigning PCI IRQ 23 to local APIC 1
msi: Assigning MSI IRQ 256 to local APIC 0
Trying to mount root from ufs:/dev/ad0s3a
start_init: trying /sbin/init
GEOM_LABEL: Label ufsid/4af56ad7460adb4d removed.
GEOM_LABEL: Label for provider ad0s3a is ufsid/4af56ad7460adb4d.
GEOM_LABEL: Label ufsid/4af56ad89984eff9 removed.
GEOM_LABEL: Label for provider ad0s3e is ufsid/4af56ad89984eff9.
GEOM_LABEL: Label ufsid/4af56ad8f8d7e5eb removed.
GEOM_LABEL: Label for provider ad0s3f is ufsid/4af56ad8f8d7e5eb.
GEOM_LABEL: Label ufsid/4af56ad9ae586101 removed.
GEOM_LABEL: Label for provider ad0s3d is ufsid/4af56ad9ae586101.
GEOM_LABEL: Label ufsid/4af56ad7460adb4d removed.
GEOM_LABEL: Label ufsid/4af56ad89984eff9 removed.
GEOM_LABEL: Label ufsid/4af56ad8f8d7e5eb removed.
GEOM_LABEL: Label ufsid/4af56ad9ae586101 removed.
Linux ELF exec handler installed
splash: image decoder found: logo_saver

_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: suspend help

2009-11-03T08:18:48Z

Steve Franks wrote:
: I was told on freebsd-questions a couple months back that
: suspend/resume support is broken on SMP kernels, which is pretty much
: all my systems in the era of dual-core. Assuming that is not my
: problem (on amd64 on this particular system),

I believe that's only true for i386. I currently use S3 sleep without issue
regularly, on an SMP amd64 laptop.

Which branch are you using?

: Anyway, when I call acipconf -s3 (in single-user mode or console), my
: screen flashes black, then comes right back to where is was, but the
: system is locked. I'm disabling usb, my wifi, linux, and snd_hda in
: rc.suspend, so I'm probably off on the wrong track, since I can't
: think of anything else to disable...

Are you in X at the time? Could you look into setting up something like
textdump(4) to see if your system is panicing?
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Re: kern/136808: [acpi] panic when switching to s3

2009-11-03T07:30:06Z

The following reply was made to PR kern/136808; it has been noted by GNATS.

From: Alexander Best <alexbestms@...>
To: <bug-followup@...>
Cc:
Subject: Re: kern/136808: [acpi] panic when switching to s3
Date: Tue, 03 Nov 2009 16:27:19 +0100 (CET)

running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198850: Tue Nov 3
13:00:55 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386

shipped with

debug.acpi.acpi_ca_version: 20091013

this panic no longer occurs. S3 however still doesn't work. the computer shuts
down, but then instantly comes back up again. this however results in a state
where no video signal is being sent to the monitor and nothing seems to happen
(no hdd activity). after a hard reset the computer boots regularly (with all
fs being clean).

please ask if you need any more details about configs, sysctl values etc.

alex
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

for review: retire 'magic' ivar

2009-11-02T09:03:12Z

ACPI bus defines two ivars with similar purposes - magic and private.
It seems that this is redundant.
Please review the following patch that removes 'magic' ivar.

magic is used in three places, please see below for how it is replaced.

1. acpi_cpu
magic is used was storing cpu id. Using integer type for that is, of course, more
natural, but 'private' (void *) can be used without any problems.

2. acpi_hpet
magic is used to distinguish between a device explicitly created in identify and
devices auto-created by bus enumeration. The same could be done by examining
'handle' ivar, because bus enumeration always sets handle to non-NULL, but
identify doesn't set it. Please note that there is a buglet in current code that
doesn't have any practical consequences: magic is set to address of a variable
that holds acpi_hpet_devclass, not to the devclass itself. Thus, if hpet driver
were ever unloaded and reloaded it wouldn't recognize its device created on the
first identify run.

3. acpi_ec
magic is used in this driver similarly to acpi_hpet case. Big difference though,
is that acpi_ec identify routine also sets handle ivar of explicitly created
device. But it also sets private ivar. So we make use of that fact instead:
private is set for explicitly created device, while it is not set for auto-created
devices. The same buglet with no consequences is also found here.

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index 525824a..4ed7078 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -900,9 +900,6 @@ acpi_read_ivar(device_t dev, device_t child, int index,
uintptr_t *result)
case ACPI_IVAR_HANDLE:
*(ACPI_HANDLE *)result = ad->ad_handle;
break;
- case ACPI_IVAR_MAGIC:
- *(uintptr_t *)result = ad->ad_magic;
- break;
case ACPI_IVAR_PRIVATE:
*(void **)result = ad->ad_private;
break;
@@ -938,9 +935,6 @@ acpi_write_ivar(device_t dev, device_t child, int index,
uintptr_t value)
case ACPI_IVAR_HANDLE:
ad->ad_handle = (ACPI_HANDLE)value;
break;
- case ACPI_IVAR_MAGIC:
- ad->ad_magic = (uintptr_t)value;
- break;
case ACPI_IVAR_PRIVATE:
ad->ad_private = (void *)value;
break;
diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
index 8fe9de6..c16dcb1 100644
--- a/sys/dev/acpica/acpi_cpu.c
+++ b/sys/dev/acpica/acpi_cpu.c
@@ -255,7 +255,7 @@ acpi_cpu_probe(device_t dev)

/* Mark this processor as in-use and save our derived id for attach. */
cpu_softc[cpu_id] = (void *)1;
- acpi_set_magic(dev, cpu_id);
+ acpi_set_private(dev, (void*)(intptr_t)cpu_id);
device_set_desc(dev, "ACPI CPU");

return (0);
@@ -286,7 +286,7 @@ acpi_cpu_attach(device_t dev)
sc = device_get_softc(dev);
sc->cpu_dev = dev;
sc->cpu_handle = acpi_get_handle(dev);
- cpu_id = acpi_get_magic(dev);
+ cpu_id = (int)(intptr_t)acpi_get_private(dev);
cpu_softc[cpu_id] = sc;
pcpu_data = pcpu_find(cpu_id);
pcpu_data->pc_device = dev;
diff --git a/sys/dev/acpica/acpi_ec.c b/sys/dev/acpica/acpi_ec.c
index a5a81dc..b339ba1 100644
--- a/sys/dev/acpica/acpi_ec.c
+++ b/sys/dev/acpica/acpi_ec.c
@@ -129,9 +129,6 @@ struct acpi_ec_params {
int uid;
};

-/* Indicate that this device has already been probed via ECDT. */
-#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass)
-
/*
* Driver softc.
*/
@@ -332,7 +329,6 @@ acpi_ec_ecdt_probe(device_t parent)
params->uid = ecdt->Uid;
acpi_GetInteger(h, "_GLK", ¶ms->glk);
acpi_set_private(child, params);
- acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass);

/* Finish the attach process. */
if (device_probe_and_attach(child) != 0)
@@ -348,6 +344,7 @@ acpi_ec_probe(device_t dev)
ACPI_STATUS status;
device_t peer;
char desc[64];
+ int ecdt;
int ret;
struct acpi_ec_params *params;
static char *ec_ids[] = { "PNP0C09", NULL };
@@ -362,11 +359,12 @@ acpi_ec_probe(device_t dev)
* duplicate probe.
*/
ret = ENXIO;
- params = NULL;
+ ecdt = 0;
buf.Pointer = NULL;
buf.Length = ACPI_ALLOCATE_BUFFER;
- if (DEV_ECDT(dev)) {
- params = acpi_get_private(dev);
+ params = acpi_get_private(dev);
+ if (params != NULL) {
+ ecdt = 1;
ret = 0;
} else if (!acpi_disabled("ec") &&
ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids)) {
@@ -439,7 +437,7 @@ out:
if (ret == 0) {
snprintf(desc, sizeof(desc), "Embedded Controller: GPE %#x%s%s",
params->gpe_bit, (params->glk) ? ", GLK" : "",
- DEV_ECDT(dev) ? ", ECDT" : "");
+ ecdt ? ", ECDT" : "");
device_set_desc_copy(dev, desc);
}

diff --git a/sys/dev/acpica/acpi_hpet.c b/sys/dev/acpica/acpi_hpet.c
index ac28031..875ef07 100644
--- a/sys/dev/acpica/acpi_hpet.c
+++ b/sys/dev/acpica/acpi_hpet.c
@@ -66,8 +66,6 @@ static void acpi_hpet_test(struct acpi_hpet_softc *sc);

static char *hpet_ids[] = { "PNP0103", NULL };

-#define DEV_HPET(x) (acpi_get_magic(x) == (uintptr_t)&acpi_hpet_devclass)
-
struct timecounter hpet_timecounter = {
.tc_get_timecount = hpet_get_timecount,
.tc_counter_mask = ~0u,
@@ -153,8 +151,6 @@ acpi_hpet_identify(driver_t *driver, device_t parent)
return;
}

- /* Record a magic value so we can detect this device later. */
- acpi_set_magic(child, (uintptr_t)&acpi_hpet_devclass);
bus_set_resource(child, SYS_RES_MEMORY, 0, hpet->Address.Address,
HPET_MEM_WIDTH);
}
@@ -166,7 +162,7 @@ acpi_hpet_probe(device_t dev)

if (acpi_disabled("hpet"))
return (ENXIO);
- if (!DEV_HPET(dev) &&
+ if (acpi_get_handle(dev) != NULL &&
(ACPI_ID_PROBE(device_get_parent(dev), dev, hpet_ids) == NULL ||
device_get_unit(dev) != 0))
return (ENXIO);
diff --git a/sys/dev/acpica/acpivar.h b/sys/dev/acpica/acpivar.h
index f4d27e4..abfaa8b 100644
--- a/sys/dev/acpica/acpivar.h
+++ b/sys/dev/acpica/acpivar.h
@@ -88,7 +88,6 @@ struct acpi_softc {
struct acpi_device {
/* ACPI ivars */
ACPI_HANDLE ad_handle;
- uintptr_t ad_magic;
void *ad_private;
int ad_flags;

@@ -224,7 +223,7 @@ extern int acpi_quirks;
* attach to ACPI.
*/
#define ACPI_IVAR_HANDLE 0x100
-#define ACPI_IVAR_MAGIC 0x101
+#define ACPI_IVAR_UNUSED 0x101 /* Unused/reserved. */
#define ACPI_IVAR_PRIVATE 0x102
#define ACPI_IVAR_FLAGS 0x103

@@ -250,7 +249,6 @@
}

__ACPI_BUS_ACCESSOR(acpi, handle, ACPI, HANDLE, ACPI_HANDLE)
-__ACPI_BUS_ACCESSOR(acpi, magic, ACPI, MAGIC, uintptr_t)
__ACPI_BUS_ACCESSOR(acpi, private, ACPI, PRIVATE, void *)
__ACPI_BUS_ACCESSOR(acpi, flags, ACPI, FLAGS, int)

--
Andriy Gapon
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Current problem reports assigned to freebsd-acpi@FreeBSD.org

2009-11-02T03:06:47Z

suspend help

2009-11-01T10:55:43Z

Hi,

I was told on freebsd-questions a couple months back that
suspend/resume support is broken on SMP kernels, which is pretty much
all my systems in the era of dual-core. Assuming that is not my
problem (on amd64 on this particular system),

Anyway, when I call acipconf -s3 (in single-user mode or console), my
screen flashes black, then comes right back to where is was, but the
system is locked. I'm disabling usb, my wifi, linux, and snd_hda in
rc.suspend, so I'm probably off on the wrong track, since I can't
think of anything else to disable...

Thanks,
Steve

FreeBSD fyre.franks-development.dyndns.biz 8.0-RC1 FreeBSD 8.0-RC1 #0:
Thu Sep 17 18:50:57 UTC 2009
root@...:/usr/obj/usr/src/sys/GENERIC amd64
_______________________________________________
freebsd-acpi@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@..."

Current problem reports assigned to freebsd-acpi@FreeBSD.org

2009-10-26T04:06:52Z