Re: [CFT] SMP/i386 suspend/resume
Hi, From: mbsd m...@isgroup.com.ua Subject: Re: [CFT] SMP/i386 suspend/resume Date: Wed, 20 Jun 2012 22:31:44 +0300 Message-ID: 1340220704.2098.8.camel@localhost Hi developers. I want help you with your acpi work. I have thinkpad t61. Could you write a small to do. Step by step, how tests your patches? Which information is important for send. The patches were already merged to CURRENT and RELENG_9. So, please try RELENG_9 and report any problems suspend/resume. I'll try to fix them until 9.1-RELEASE :) Thanks! On Wed, 2012-05-16 at 11:31 +0900, Mitsuru IWASAKI wrote: Hi, First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, +1. I've really liked to use more than one CPU on my netbook for a while :). A basic suspend test worked on my netbook. I'll have to see about some edgecases I've run into in the past where UP wouldn't resume if the system had been sitting for an extensive period of time, etc. Very cool though -- thanks for your work so far on this ;)! I'm glad to hear this :) I'll try to fix suspend/resume related problems when I have spare time. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, Thanks for your report. From: Peter Jeremy pe...@rulingia.com Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 21:20:05 +1000 Message-ID: 2012052005.ga87...@server.rulingia.com On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI iwas...@jp.freebsd.org wrote: I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: Thank you for that. Since I was in the process of upgrading my netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8 patch on top of r235229. Unfortunately, the result hasn't been a complete success. I can suspend to S3 with no problems (though that worked before). The resume is less successful. If X is running, I get a garbage screen. If I suspend at a VTY, the screen comes back correctly but there is no response from keyboard, touchpad or wired network (though it has the correct lights). Let me know if you have any suggestions for debugging. I think graphic driver (or pic?) has some problems on resume and they are out of scope of my patches. HEAD and RELENG_9 have better support on interrupt re-enabling than RELENG_8 I think. Could you try them? And for ps/2 mouse, kernel option PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. Thanks -- Peter Jeremy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, Thanks for you report. From: David Wolfskill d...@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 13:22:57 + Message-ID: 20120511132257.ga96...@freefall.freebsd.org On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote: Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff ... I'm sorry to report that while head stable/9 did work for me (see previous notes in this thread), stable/8 did not. Well, suspend seemed to, but on resume, the screen stayed dark and the machine was (as far as I could tell without trying to ping it from another machine) unresponsive. OK, we need some more investigation on RELENG_8 SMP. I think Core 2 Duo can run amd64, would like to confirm this problem can be reproduced only on i386 or not. Could you try same thing on amd64? Thanks This was on the same Dell Precision M4400 as before (Core(TM)2 Duo CPU T9600), running: FreeBSD localhost 8.3-STABLE FreeBSD 8.3-STABLE #382 235262M: Fri May 11 04:45:52 EDT 2012 root@localhost:/common/S1/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskilld...@freebsd.org There is a use for spam: it helps identify spammers. I have no use for spammers. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, Thanks for your report. From: Gustau Pérez i Querol gpe...@entel.upc.edu Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 09:57:33 +0200 Message-ID: 4faf696d.3060...@entel.upc.edu Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff A lot of portion of the patches was ported from amd64. Testing on Thinkpad X60 (Core Duo T2300), so far so good :) I'll commit them against CURRENT hopefully next week. Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. I think this is graphic driver problem. nvidia's driver seems to have correct suspend/resume method. http://www.nvidia.com/object/freebsd_archive.html Have you try it? Thanks Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, From: David Wolfskill da...@catwhisker.org Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 07:03:02 -0700 Message-ID: 20120513140302.gi13...@albert.catwhisker.org On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote: OK, we need some more investigation on RELENG_8 SMP. I think Core 2 Duo can run amd64, would like to confirm this problem can be reproduced only on i386 or not. Could you try same thing on amd64? Well, that will require a bit more work -- I'm pretty sure the hardware can run amd64, but I only have i386 inistalled presently. And I'm getting ready to head to the airport to fly back home now. Understood. I don't need to hurry on this. BTW, amd64 Live CD might be useful for this purpose. Thanks! Peace, david -- David H. Wolfskillda...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. I think this is graphic driver problem. nvidia's driver seems to have correct suspend/resume method. http://www.nvidia.com/object/freebsd_archive.html Have you try it? Yes, it is running the propietary driver. Everything was done with it loaded. Do you want me to try without the nvidia binary driver? Yes, if it doesn't bother you. Hmmm, it doesn't seem related with my SMP/i386 sleep patches. Could you try also Uni-processer kernel (w/o SMP and apic from config file) without my patches? OTOH, IIRC the console only test (without X) without acpi_video lead to freeze. No crash dump. The machine has no serial or fwire ports :( We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) http://www.kernel.org/doc/Documentation/power/video.txt I believe there are some solutions for you in this document, then we can implement them in our source if found. Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[CFT] SMP/i386 suspend/resume
Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff A lot of portion of the patches was ported from amd64. Testing on Thinkpad X60 (Core Duo T2300), so far so good :) I'll commit them against CURRENT hopefully next week. Thanks and have fun! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[patch] iwi(4) suspend/resume broken
Hi, I've noticed that iwi(4) doesn't have ieee80211_new_state(IEEE80211_S_INIT) in iwi_stop_locked() since 8.0-RELEASE (comparing with RELENG_7's). It seems that this prevent if_iwi from working properly after resuming, no data frames were sent. The patches is available at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120314.diff Now that iwi(4) is working well for me :) I'll commit this coming weekend if there are no objections. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. OK, I'd do so. I don't need mcast stuff for the time being, instead I'd check other area such as suspend/resume for the next target. Today's one at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120308.diff # 2 lines fix, after all ;) Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
I'd rather you file a PR first describing what you just did, then commit the fix and close the PR. OK, I've just submitted a PR. I'll follow the procedure you suggested. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165819 Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
In RELENG_7, data frame is transmitted by iwi_tx_start() like this. ether_output ether_output_frame IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start iwi_start iwi_tx_start After 8.0-RELEASE, device specific if_transmit() is called via net80211 layer. ether_output ether_output_frame if_transmit IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start ieee80211_start parent-if_transmit(ie. iwi_transmit()) There was not if_transmit method in iwi(4), so I add it. On if_qflush(), CURRENT kernel complains that `transmit and qflush must both either be set or both be NULL' from if.c. I wrote iwi_qflush(), but actually never tested it... Hmm, it still is the case for = 8 afaik, there is a default if_transmit() which is used for all wireless drivers which seems to work pretty well. That's why I'm wondering, iwi(4) would be the first driver to have it's own if_transmit() function. I'm not aware of any technical reason for adding one, or did I miss something? If not I'd rather not have one added, for sake of consistency. By your this comment, I noticed that my understanding on iwi_start() call stack 8.0 was wrong a bit, correct one is like this; ether_output ether_output_frame if_transmit IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start ieee80211_start parent-if_transmit(ie. if_transmit()) IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start iwi_start iwi_start_locked iwi_tx_start So iwi_transmit and iwi_qflush would not be necessary. Today's version of patches at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120307.diff This would be the final version I hope. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Thanks Bernhard and Adrian, I think the problem seems to be solved.
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
As you suggested, iwi_checkforqos() has problems, wrong asresp
frame parsing.
@@ -1357,8 +1365,8 @@
frm += 2;
wme = NULL;
- while (frm efrm) {
- IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1], return);
+ while (efrm - frm 1) {
+ IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1] + 2, return);
switch (*frm) {
case IEEE80211_ELEMID_VENDOR:
if (iswmeoui(frm))
Bacause of the condition `while (frm efrm)',
IEEE80211_VERIFY_LENGTH() was checking item length beyond the
ieee80211_frame region, and returned from iwi_checkforqos() without
setting flags, capinfo and associd!
I made above changes referring to net80211 code such as
ieee80211_sta.c.
Today's version of patches at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120306.diff
This one don't have changes on net80211 part at all.
What's the reason behing adding if_qflush()/if_transmit()?
In RELENG_7, data frame is transmitted by iwi_tx_start() like this.
ether_output
ether_output_frame
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
iwi_start
iwi_tx_start
After 8.0-RELEASE, device specific if_transmit() is called via net80211 layer.
ether_output
ether_output_frame
if_transmit
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
ieee80211_start
parent-if_transmit(ie. iwi_transmit())
There was not if_transmit method in iwi(4), so I add it.
On if_qflush(), CURRENT kernel complains that `transmit and qflush
must both either be set or both be NULL' from if.c.
I wrote iwi_qflush(), but actually never tested it...
From: Adrian Chadd adr...@freebsd.org
Would you please open a PR with this particular issue and then attach
the patch to it?
I prefer committing changes on iwi(4) by myself, because grimreaper@
keep giving pressure to me `Your src commit bit is still idle.' for
long time :)
I just want to stop it.
I'd rather you not commit the net80211 change until I've verified that
WEP works or doesn't work with ath(4).
Never mind, I think I don't need to touch on net80211.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
patches for if_iwi and wlan for WEP mode
Hi,
I've fixed iwi(4) so that Intel(R) PRO/Wireless 2915ABG work
in WEP mode, which seems to be broken since 8.0-RELEASE.
The patches against HEAD at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120305.diff
I'm not sure that changes on ieee80211 layer are right fixes,
but all of mbufs were discarded in ieee80211_start() in WEP mode.
void
ieee80211_start(struct ifnet *ifp)
{
[snip]
if (ni-ni_associd == 0
(ni-ni_flags IEEE80211_NODE_ASSOCID)) {
IEEE80211_DISCARD_MAC(vap, IEEE80211_MSG_OUTPUT,
eh-ether_dhost, NULL,
sta not associated (type 0x%04x),
htons(eh-ether_type));
vap-iv_stats.is_tx_notassoc++;
ifp-if_oerrors++;
m_freem(m);
ieee80211_free_node(ni);
continue;
}
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
I'm going to commit the changes coming weekend.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: APM not working on Dell Latitude D600
If hint.apm.0.disabled=1 in your /boot/device.hints, try removing it. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm remaining problem (possible ACPI too)
Hi, Since rescent -CURRENT is stable enough, I have the chance to find out remaining pcm problem. My MP box no more has double fatal fault and turns into random sleep. The random sleep happens after pcm having its own problem. uname -av is FreeBSD cartier.home 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed Dec 4 23:07:36 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERI i386 Kernel config is simply a modified GENERIC, with options SMP, APIC_IO, and ident GENERI. Below is what I've got in my dmesg. Complete dmesg is at http://fatpipi.cirx.org/~clive/cartier_dmesg.txt lock order reversal 1st 0xc6992900 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc0524600 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225 acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 wakeup from sleeping state (slept 00:02:06) ata0: resetting devices .. done I think the real problem is in pcm on MP system as you said, IRQ 9 maybe shared with pcm0 and acpi. Could you show me this? # acpidump | grep SCI_INT Also, I'd like to see which acpi event was occured on ramdom sleep. Backtrace is helpful to track this down. Press Ctrl+Alt+Esc into DDB, enter db b acpi_SetSleepState to set break point, then send me the output of db t when the ramdom sleep is occurred. BTW, you can set ignoring some of acpi events like this: # sysctl hw.acpi.power_button_state=NONE # sysctl hw.acpi.sleep_button_state=NONE # sysctl hw.acpi.lid_switch_state=NONE acpi0: RCCRCCNILE on motherboard # I worry about this... :P Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in ithread_loop()
This is 100% reproducible with a top-of-tree kernel, but didn't happen with Wednesday's sources: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc01e8d fault code = supervisor write, page not present instruction pointer = 0x8:0xc045dc80 stack pointer = 0x10:0xd536dce4 frame pointer = 0x10:0xd536dd00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: tty:sio clock) kernel: type 12 trap, code=0 Stopped at 0xc045dc80: movb%al,0xc01e8d I saw this panics many times recently. After totally fresh buildworld and buildkernel (i.e. rm -rf /usr/obj/* and w/o -DNOCLEAN), problem was gone. Please note that recently we had gcc changes. I've noticed -freg-struct-return brakages, some important ports which using ndbm library (such as qpopper) is broken right now... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 2013] RE: ACPI errors w/ latest ACPI code on GA BX2000 based system
Thanks, Bob.
I think this code is the problem:
Scope(\_TZ_) {
ThermalZone(THRM) {
Name(_AL0, Package(0x1) {
FAN_,
})
The name FAN_ is not defined elsewhere in the namespace.
I guess that BIOS writer forgot to delete _AL0 definition :)
Instead, you can delete these lines and override DSDT, I think.
Name(_AL0, Package(0x1) {
FAN_,
})
Thanks
To my memo:
DefinitionBlock (
acpi_dsdt.aml,//Output filename
DSDT, //Signature
0x1,//DSDT Revision
COMPAQ, //OEMID
AWRDACPI, //TABLE ID
0x1000 //OEM Revision
)
Bob
-Original Message-
From: Thomas Seck [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 30, 2002 4:34 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 2009] Re: ACPI errors w/ latest ACPI code on GA BX2000
based system
* Mitsuru IWASAKI ([EMAIL PROTECTED]):
Iwasaki-san,
list members,
ACPI-0438: *** Error: Looking up [FAN_] in namespace, AE_NOT_FOUND
ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND
I think that this was caused by the following spec changes.
From CHANGES.txt:
22 October 2002. Summary of changes for version 20021022.
1) ACPI CA Core Subsystem:
Implemented a restriction on the Scope operator that the
target must already exist in the namespace at the time the
operator is encountered (during table load or method
execution). In other words, forward references are not
allowed and Scope() cannot create a new object. This changes
the previous behavior where the interpreter would create the
name if not found. This new behavior correctly enables the
search-to-root algorithm during namespace lookup of the target
name. Because of this upsearch, this fixes the known Compaq
_SB_.OKEC problem and makes both the AML interpreter and iASL
compiler compatible with other ACPI implementations.
Could you send your acpidump output to this acpi-jp ML?
Of course. And thank you very much for working on this. Please see the
attached file.
--Thomas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 2015] Re: ACPI Poweroff problem
Hi,
* Nate Lawson ([EMAIL PROTECTED]):
Power System off using ACPI
ACPI -1287 *** Error: Method execution failed
AE_AML_UNINITIALIZED_LOCAL
ACPI -1287 *** Error: Method execution failed
AE_AML_UNINITIALIZED_LOCAL
ACPIEnterSleepStatePrep failed AE_AML_UNINITIALIZED_LOCAL
(so, or similar).
PS : I have an VIA KT266 chipset.
Please cc acpi-jp list with acpi problems, as I have on this reply. Check
the current@ archives for the patch 20021122 that iwasaki@ posted. It may
fix your problem.
It seems that some problems were introduced with that patch.
Really? If so, could you describe them? We need to report any
problems to Intel in order to obtain good ACPI support.
BTW, I've seen some AE_AML_UNINITIALIZED_LOCAL problems in DSDT,
especially about one year ago. Typical ASL code is like this:
Method(_PS0) {
Store(Local0, Local0)
Store(0x1, _PSC)
}
As you noticed, uninitialized Local0 is referred in Store operator.
It's easy to fix this kind DSDT errors in most cases.
# or updated BIOS may be already provided.
Please check and fix your acpidump output, or send it to acpi-jp ML.
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 2004] ACPI errors w/ latest ACPI code on GA BX2000based system
Hi, A freshly built system with Now 28 sources now throws the ACPI errors seen in the dmesg output. The former ACPI snapshot did not complain in any way on this system. [snip] ACPI-0438: *** Error: Looking up [FAN_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND I think that this was caused by the following spec changes. From CHANGES.txt: 22 October 2002. Summary of changes for version 20021022. 1) ACPI CA Core Subsystem: Implemented a restriction on the Scope operator that the target must already exist in the namespace at the time the operator is encountered (during table load or method execution). In other words, forward references are not allowed and Scope() cannot create a new object. This changes the previous behavior where the interpreter would create the name if not found. This new behavior correctly enables the search-to-root algorithm during namespace lookup of the target name. Because of this upsearch, this fixes the known Compaq _SB_.OKEC problem and makes both the AML interpreter and iASL compiler compatible with other ACPI implementations. Could you send your acpidump output to this acpi-jp ML? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problem with laptop?
Then you'll get thermal operation messages, something like: Nov 26 19:34:13 mybox kernel: acpi_tz0: _AC0: temperature 60.0 = setpoint 60.0 Nov 26 19:34:13 mybox kernel: acpi_tz0: switched from NONE to _AC0: 60.0C We need the messages like this, acpidump output, and sysctl hw.acpi output to track this down. [snip] Patch added. acpidump adds this (except for the log): acpidump: DSDT is corrupt To get acpidump properly, I recommend not loading acpi.ko. # Maybe other kernel modules also. acpidump is a very simple utility, doesn't require acpi modules. Running it in single user mode is better, I think. There were no thermal info in /var/log/messages or anywhere else for that matter I'm afraid that your ACPI BIOS don't have ThermalZone definitions... If so, ACPI cannot help to control thermal of your system. Anyway, I'm waiting for your acpidump output. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1988] Re: ACPI errors and then panic - fixed!
Hi, Intel folks.
It seems that there is a bug in cached object utilization.
This causes strange behavior;
first evaluation of \_SB_.PCI0.LPC_.EC__.BAT0._BST is OK, but
second (or later) evaluation returns AE_TYPE.
acpi_cmbat0: error fetching current battery status -- AE_TYPE
The raw DSDT is at:
http://www.root.org/~nate/acpi/ibm.dsdt
I guess that InternalObject was returned to cache in AcpiUtReleaseToCache()
but the same object is still in use somewhere (for ResultObj ?).
I could reproduce this problem with acpica debugger. Trace output attached.
I'll track this down later.
Thanks
% acpicadb ibm.dsdt
Loading Acpi table from file ibm.dsdt
utmisc-0802 [11] UtAcquireMutex: Mutex [ACPI_MTX_Namespace] already acquired
by this thread [C25]
utmisc-0802 [11] UtAcquireMutex: Mutex [ACPI_MTX_Namespace] already acquired
by this thread [C25]
Parsing
Methods:..
Table [DSDT] - 1208 Objects with 61 Devices 354 Methods 18 Regions
Acpi table [DSDT] successfully installed and loaded
- f _BST
\_SB_.PCI0.LPC_.EC__.BAT0._BST (0x80ba0a8) - Method
\_SB_.PCI0.LPC_.EC__.BAT1._BST (0x80ba6a8) - Method
- debug _SB_.PCI0.LPC_.EC__.BAT0._BST
Executing \_SB_.PCI0.LPC_.EC__.BAT0._BST
0 #007F XOr (DerefOf (Index (BT0I, 0x00)))
%
ArgObj:0x80b9ea8 NodeName BT0I Package 0x80e1ba8
ArgObj:0x80f9fa8 Obj Integer
ArgObj:0x80fe028 Obj Integer
0 #0037 [EvalSubTree] (Package (0x0D)
{
0x00,
0x,
0x,
0x01,
0x2A30,
0x00,
0x00,
0x01,
0x01,
,
,
,
})
%
ArgObj:0x80fe0a8 Obj Integer 000D
ResultObj: 0x80e1ba8 Obj Package 0x80e1ba8
ResultObj: 0x80fe828 [Index] Integer
0 #007F XOr (DerefOf (-Return Value- ()))
%
ArgObj:0x80abf28 Parser
ArgObj:0x80fe828 [Index] Integer
ResultObj: 0x80fe0a8 Obj Integer
0 #007F XOr (-Return Value- (), 0x01, Local0)
%
ArgObj:0x80b02a8 Parser
ArgObj:0x80fe0a8 Obj Integer
ArgObj:0x80fe828 Obj Integer 0001
ArgObj:0x80fe028 [Local0] 0x0 Uninitialized
ResultObj: 0x80f9fa8 Obj Integer 0001
D #00A4 Return (E #0035 GBST (0x00, HB0S, Local0, BT0P))
% into
ArgObj:0x80fe028 Obj Integer
ArgObj:0x80b7828 NodeName HB0S RegionField 0x80df5a8
ArgObj:0x80fe828 [Local0] 0x80f9fa8 Integer 0001
ArgObj:0x80b9f28 NodeName BT0P Package 0x80e1c28
0 #5B80 OperationRegion (ECOR (Path \_SB_.PCI0.LPC_.EC__.ECOR), EmbeddedControl,
0x00, 0x0100)
%
ArgObj:0x80fe928 Obj Integer
ArgObj:0x80fe9a8 Obj Integer 0100
DEBUG[read (EC, 8, 0x38)](default: 0x0 / 0)
0 #0037 [EvalSubTree] (Package (0x04) {})
%
ArgObj:0x80fe828 Obj Integer 0004
ResultObj: 0x80e1c28 Obj Package 0x80e1c28
0 #5B23 Acquire (BATM, 0x)
%
ArgObj:0x80b9aa8 NodeName BATM Mutex 0x80e18a8
ArgObj:0x80fe828 Obj Integer
ResultObj: 0x80fe928 Obj Integer
8 #00A0 If (And (Arg1, 0x20)) {}
%
ArgObj:0x80fe928 [Arg1] 0x80fe8a8 Integer
ArgObj:0x80fe828 Obj Integer 0020
ArgObj:0x80fe9a8 Obj Integer
ResultObj: 0x80fe928 Obj Integer
8 #00A0 If (Predicate = [False], Skipping IF block
%
00015 #00A0 If (And (Arg1, 0x40)) {}
%
ArgObj:0x80fe928 [Arg1] 0x80fe8a8 Integer
ArgObj:0x80fe9a8 Obj Integer 0040
ArgObj:0x80fe828 Obj Integer
ResultObj: 0x80fe928 Obj Integer
00015 #00A0 If (Predicate = [False], Skipping IF block
%
00022 #0070 Store (0x00, Local0)
%
ArgObj:0x80fe928 Obj Integer
ArgObj:0x80fe828 [Local0] 0x0 Uninitialized
ResultObj: 0x80fe928 Obj Integer
00020 #00A1 Else
{
Predicate = [False], ELSE block was executed
%
00013 #00A1 Else
{
Predicate = [False], ELSE block was executed
%
00026 #00A0 If (And (Arg1, 0x0F)) {}
%
ArgObj:0x80fe828 [Arg1] 0x80fe8a8 Integer
ArgObj:0x80fe9a8 Obj Integer 000F
ArgObj:
Re: [acpi-jp 2000] RE: ACPI errors and then panic - fixed!
Hi, Our web person is out today, so things will be posted Monday at the earliest. I'll email Iwasaki-san the latest release, so y'all can get going if you want. Thank you! I've just confirmed that the deleted object problem had been solved in the latest release (Andy sent it to me). I'll make diffs for FreeBSD soon. John, there is new OS layer function for PCI. Could you help? Thanks /* * Interim function needed for PCI IRQ routing */ void AcpiOsDerivePciId( ACPI_HANDLE rhandle, ACPI_HANDLE chandle, ACPI_PCI_ID **PciId); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for testers: acpica-unix-20021122 (was Re: ACPI errors andthen panic - fixed!)
Hi all, Our web person is out today, so things will be posted Monday at the earliest. I'll email Iwasaki-san the latest release, so y'all can get going if you want. Thank you! I've just confirmed that the deleted object problem had been solved in the latest release (Andy sent it to me). I'll make diffs for FreeBSD soon. The patches against today's CURRENT at: http://people.freebsd.org/~iwasaki/acpi/acpica-20021118-20021122-test20021128.diff Please try this if you have problems about ACPI interpreter or GPE initialization. Please note that tarball for acpica-unix-20021122 and CHANGES.txt on Intel Web site is not available yet (will be availalbe next week), refer the Release notes from sourceforge.net instead. http://sourceforge.net/project/shownotes.php?group_id=36832release_id=124563 Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problem with laptop?
Hi, If I choose to make world under -CURRENT the laptop gets hotter (well the processor/hd and so on gets used and causes heat) now, the fan starts to spin faster and so on, but the computer never gets cooler even a day after a build it still is hot and the fan never stops spinning, is there a way to let my processor know how to calm down? This problem dosn't occur when I'm running Windows (XP) Hmm, we need further info. on this. Please add the following lines into your /boor/loader.conf: hw.acpi.verbose=1 debug.acpi.layer=ACPI_ALL_COMPONENTS ACPI_BUS debug.acpi.level=ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS Then you'll get thermal operation messages, something like: Nov 26 19:34:13 mybox kernel: acpi_tz0: _AC0: temperature 60.0 = setpoint 60.0 Nov 26 19:34:13 mybox kernel: acpi_tz0: switched from NONE to _AC0: 60.0C We need the messages like this, acpidump output, and sysctl hw.acpi output to track this down. BTW, does new acpica patches give any effects for your? http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20021118.tar.gz
Hi,
the new snapshot boots fine here.
However, I still get the message
acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND
OK, never mind. This is normal because your DSDT doesn't have
_S1_ object.
Name(\_S0_, Package(0x4) {
0x0,
0x0,
0x0,
0x0,
})
Name(\_S3_, Package(0x4) {
0x5,
0x5,
0x0,
0x0,
})
Name(\_S4_, Package(0x4) {
0x6,
0x6,
0x0,
0x0,
})
Name(\_S5_, Package(0x4) {
0x7,
0x7,
0x0,
0x0,
})
when I try to suspend the machine or anything with closing the lid,
or using the keyboard buttons, or when I try something like
acpiconf -s 1.
The box in question is an IBM Thinkpad R32.
Any ideas?
Instead of _S1_, you can specify _S3_ (or _S4_ if you setup for
hibernation properly) for ACPI configuration.
Please try:
# sysctl hw.acpi.sleep_button_state=S3
# sysctl hw.acpi.lid_switch_state=S3
# sysctl hw.acpi.standby_state=S3
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI errors - IBM Thinkpad A31p
Hi, Are you trying this with acpica-unix-20021118 patch which was announced recently? http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff Also [EMAIL PROTECTED] is better place for ACPI CA related problem reports. Thanks From: Sid Carter [EMAIL PROTECTED] Subject: ACPI errors - IBM Thinkpad A31p Date: 26 Nov 2002 10:35:41 +0530 Message-ID: [EMAIL PROTECTED] Hi Folks, I see this error while booting into BSD and I presume this might be the problem that acpi on my TP does not work. The errors are something like this. acpi0: IBMTP-1Gon motherboard Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 Dmesg on the box FreeBSD 5.0-CURRENT #0: Fri Nov 22 17:37:35 IST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc0618000. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc06180a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0618154. Preloaded elf module /boot/kernel/acpi.ko at 0xc0618200. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1198990668 Hz CPU: Pentium 4 (1198.99-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 267780096 (255 MB) avail memory = 253579264 (241 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface uname -a FreeBSD tango 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Nov 22 17:37:35 IST 2002 root@tango:/usr/obj/usr/src/sys/GENERIC i386 Any fix for this ? I am unable to use ACPI in FBSD. TIA Regards Sid -- When I was in school, I cheated on my metaphysics exam: I looked into the soul of the boy sitting next to me. -- Woody Allen Sid Carter - http://khader.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lots of swapping from 'kldload acpi'
On Fri, Nov 22, 2002 at 04:08:05PM -0500, John Baldwin wrote: Can something be done to guard against this? It's supposed to do that already: If that isn't working then there is a bug. There's a bug :-) Ah, Yes. The function is called via SYSINIT. We need more `if (!cold)' checkings. I'll take this one. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1940] Re: ACPI errors and then panic
Hi, On Sat, 5 Oct 2002, Mitsuru IWASAKI wrote: From: Nate Lawson [EMAIL PROTECTED] Subject: ACPI errors and then panic Date: Fri, 4 Oct 2002 17:14:31 -0700 (PDT) Message-ID: [EMAIL PROTECTED] My laptop appears to work ok without ACPI but of course I don't get suspend, resume, etc. I have never been able to get ACPI to work with it, including with a -current as of 2 hours ago. If ACPI is enabled, I get a spew of: ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name and then a panic from acpi_attach. I sent a reply including the requested traces on Oct 25. Do you need any more information? Please try with new ACPI CA patches at: http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff Some memory leak releated bugs were fixed, so your problem might be solved by this hopefully. One interesting thing is that the oem sysctl node seems bogus: hint.acpi.0.oem=IBM ?? where the ?'s are invalid characters like the happy face. I saw similar problem long time ago. My problem was acpi.ko is too old and badly matched with kernel. Please make sure that your acpi.ko is fresh as well as kernel when you try. BTW, what's model name? Some ThinkPad's are blacklisted such as IBM 600E. And may I add your ACPI data to our repo. (in Japan) ? IBM T23. Feel free to use the dsdt and/or asl however you wish. OK, I'll add them to our CVS repo. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 (I think!) crash booting from floppies
Hi, On Wed, 20 Nov 2002, Terry Lambert wrote: local.freebsd.current wrote: I got a pair of floppies from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/5.0-20021103-SNAP/floppies/ and booted them on a Dell Dimension XPS D300 which is currently running 4.7. It's a PII/300 with an Adaptec 2940 SCSI and an STB Riva graphics card. When booting the kernel off the second floppy I get: Booting [/kernel]... / Fatal trap 12: page fault while in vm86 mode fault virtual address = 0x9f800 instruction pointer= 0xf000:0x8c3e Patch which was never integrated. Build a new kernel. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=341812+0+archive/2002/freebsd-current/20021027.freebsd-current Can someone get the memory detection (int 12) back to stable? The conservative approach seems to only have the limitation of losing 640k whereas the experimental approach causes panics. Can we take such critical experiments out of the base system and let them mature as a patch? I heard something about a release coming up or something like that. I already got the memory detection (int 12) back to STABLE and CURRENT. After all, nothing had changed there except for having new loader tunable. If you find 'Fatal trap 12: page fault while in vm86 mode' message at early kernel boot stage, your BIOS probably has broken INT 12H (in my case, it was not implemented by BIOS writer). The loader tunable 'hw.hasbrokenint12' is workaround for it. Try this at loader prompt: ok set hw.hasbrokenint12=1 Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.c problem
Hi, Thus spake Mitsuru IWASAKI [EMAIL PROTECTED]: OK, it seems to be difficult to determine the region for any BIOSes. I've decided to introduce a new loader tunable to indicate that BIOS has broken int 12H. Attached patch back out 1.385.2.26 changes to support older BIOSes, and add support for broken int 12 BIOSes by new loader tunable. I don't think this is the best solution, but it is probably good for all people for now. I'll make the equivalent patches for CURRENT and commit them, then MFC soon. Sorry for inconvenience, folks. This approach is okay with me in the sense that it doesn't break anything that wasn't already broken, but as you say, I think we can do better. Below is a patch that merely extracts the basemem size from the bootinfo structure for the purposes of mapping the EBDA. I retained the int 12h fallback just to be safe, but I think the bootinfo structure is initialized with a valid basemem for all loaders since at least 1998. (Maybe the fallbacks in the kernel should be removed entirely to avoid redundancy, or moved from loader and boot2 to locore.s.) Yes, this idea was in my first patch actually, and this was not good solution as Bruce explained. Please see the archive at: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=94412+0+archive/2002/freebsd-current/20021006.freebsd-current I think that this is not so easy problem, we need to re-design memory size detection code carefully considering PAE support in future. This will take time, so the patch I committed into CURRENT last night is reasonable for the time being, I think. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CF-PCMCIA Adapter + CF-Card
Hi, On todays Current i get on Insertion: pccard0: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 ad4: 61MB SanDisk SDCFB-64 [490/8/32] at ata2-master BIOSPIO On todays Current i get on Boot: pccard0: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 ad0: 19077MB HITACHI_DK23BA-20B [41344/15/63] at ata0-master UDMA33 ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. done ad4: read interrupt arrived early ad4: read error detected (too) late ad4: SanDisk SDCFB-64 [490/8/32] at ata2-master BIOSPIO ad4: hard error cmd=read fsbn 104458130 of 0-3 status=51 error=10 ad4: 51004MB SanDisk SDCFB-64 [21318/70/70] at ata2-master BIOSPIO at that point the kernel hangs :-) Yes, this problem was already analysed and I sent the patches to Soren and Warner. I couldn't find the patches right now, but they might still have it... Could you ask for them? I'll inform you when I can find it. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
Hi, Try backing out 1.544 of src/sys/i386/i386/machdep.c You'll need to do it as a reversed patch or by hand, as there are some unrelated signal handling things in 1.545 which you'll really need. Hmmm, I didn't notice that there is a BIOS which requires memory area below 640K even when calling INT 15H/E820. We cannot trust that today's BOISes have INT 12H, so it's difficult to determine base memory size w/o INT 15H/E820. OK, some questions: - What is the size of your base memory (reported by boot loader)? - Does attached patches solve your problem? - Is this problem specific to IBM Netvista? Thanks Index: locore.s === RCS file: /home/ncvs/src/sys/i386/i386/locore.s,v retrieving revision 1.160 diff -u -r1.160 locore.s --- locore.s25 Oct 2002 19:10:56 - 1.160 +++ locore.s8 Nov 2002 04:48:32 - @@ -851,6 +851,11 @@ movl$(KSTACK_PAGES), %ecx fillkptphys($PG_RW) +/* Map base memory */ + movl$0, %eax + movl$0xaPAGE_SHIFT, %ecx + fillkptphys($PG_RW|PG_U) + /* Map ISA hole */ movl$ISA_HOLE_START, %eax movl$ISA_HOLE_LENGTHPAGE_SHIFT, %ecx Drew Michael G. Petry writes: I'm noticing the same behavior on a PPro system I have and am following the thread SMP broken on PPro. It looks like the problem is not SMP specific, but it does seem PPro centric. Are the modules also new? On Thu, 7 Nov 2002, Sidcarter wrote: Hi Folks, I just did a cvsup and installed a kernel. I have been trying this from the past few days with the same error. I am copying this by hand, since it crashes immediately after loading the modules. The error message is here Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x30dbc data=0x1a58+0xb48 syms=[0x4+0x5770+0x4+0x 73b9/]\ Fatal trap 12: page fault while in vm86 mode fault virtual address = 0x9fdc8 fault code = user read, page not present instruction pointer= 0xf000:0x145e stack pointer = 0x0:0xfb4 frame pointer = 0x0:0xfca code segment = base 0x0, limit 0x0, type 0x0 DPL 0, pres 0, def32, gran 0 processsor eflags = interrupt enabled, resume, vm86, IOPL=0 current process= 0 () kernel: type 12 trap, code=0 Stopped at 0x145e: addb%al,0(%eax) db t (null)(eee06c0,1,e820,fee06c0,9775a707) at 0x145e db uname -a FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 24 15:46:54 IST 2002 root@calvin:/usr/obj/usr/src/sys/HOGWARTS i386 Any idea what could be wrong ? Becoz of this problem, I am also unable to do an install world as the it is looking for sigaction in the kernel. TIA Regards Sid To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Michael Petry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
OK, some questions:
- What is the size of your base memory (reported by boot loader)?
- Does attached patches solve your problem?
- Is this problem specific to IBM Netvista?
Thanks
Index: locore.s
===
RCS file: /home/ncvs/src/sys/i386/i386/locore.s,v
Oops, not this file.
Thanks
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.545
diff -u -r1.545 machdep.c
--- machdep.c 25 Oct 2002 19:10:56 - 1.545
+++ machdep.c 8 Nov 2002 04:50:05 -
@@ -1513,6 +1513,7 @@
struct vm86context vmc;
vm_offset_t pa, physmap[PHYSMAP_SIZE];
pt_entry_t *pte;
+ pt_entry_t saved_pte[160];
char *cp;
struct bios_smap *smap;
@@ -1520,6 +1521,14 @@
bzero(physmap, sizeof(physmap));
basemem = 0;
+ for (pa = (4 PAGE_SHIFT); pa ISA_HOLE_START; pa += PAGE_SIZE)
+ pmap_kenter(KERNBASE + pa, pa);
+ pte = (pt_entry_t *)vm86paddr;
+ for (i = 4; i 160; i++) {
+ saved_pte[i] = pte[i];
+ pte[i] |= PG_V | PG_RW | PG_U;
+ }
+
/*
* map page 1 R/W into the kernel page table so we can use it
* as a buffer. The kernel will unmap this page later.
@@ -1629,6 +1638,12 @@
* pmap_mapdev, but since no memory needs to be
* allocated we simply change the mapping.
*/
+ pte = (pt_entry_t *)vm86paddr;
+ for (i = 4; i 160; i++)
+ pte[i] = saved_pte[i];
+ for (pa = (4 PAGE_SHIFT); pa ISA_HOLE_START; pa += PAGE_SIZE)
+ pmap_kremove(KERNBASE + pa);
+
for (pa = trunc_page(basemem * 1024);
pa ISA_HOLE_START; pa += PAGE_SIZE)
pmap_kenter(KERNBASE + pa, pa);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] NEWCARD: pccardc power support
Hi, In message: [EMAIL PROTECTED] Mitsuru IWASAKI [EMAIL PROTECTED] writes: : I've implemented pccardc power and boot_deactivated support code for : NEWCARD. They are needed for some mobile users including me. : : - Add pccardc power support code. Yes, it's OLDCARD compatible. : - Add new loader tunable hw.cbb.boot_deactivated to prevent pccards :from attaching automatically. [snip] So this is a good hack, and likely useful to a lot of people. However, I'd like to see a more thoughtful design of a good device control interface. I think that it dovetails nicely with the work I'm doing for devd. Yes, my understanding of the goal of devd is that. Also I understand that NEWCARD users will be eager for suggested features until devd development is completed. So I'll leave the patches for such a people for a while at: http://people.freebsd.org/~iwasaki/pccard/cbb-pccardc-power-support-20021029.diff BTW, I think that some developers are interested in devd. Do we have mailing list for it? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] NEWCARD: pccardc power support
Hi,
I've implemented pccardc power and boot_deactivated support code for
NEWCARD. They are needed for some mobile users including me.
- Add pccardc power support code. Yes, it's OLDCARD compatible.
- Add new loader tunable hw.cbb.boot_deactivated to prevent pccards
from attaching automatically.
Some people want to keep pccards in slots all the time even if they
don't want to use the pccard. They can power pccard on via pccardc
command now (and in OLDCARD days) when it's required, so automatic
attaching pccards at boot time is not desired behavior for them.
This is quick hack actually (took about 1 hour), so it's not
clean at all.
But it's good enough for prototype, working great for me actually :)
Enjoy!
Index: pccbb.c
===
RCS file: /home/ncvs/src/sys/dev/pccbb/pccbb.c,v
retrieving revision 1.59
diff -u -r1.59 pccbb.c
--- pccbb.c 11 Oct 2002 04:30:59 - 1.59
+++ pccbb.c 29 Oct 2002 10:55:48 -
@@ -86,6 +86,8 @@
#include sys/sysctl.h
#include sys/kthread.h
#include sys/bus.h
+#include sys/conf.h
+#include sys/ioccom.h
#include machine/bus.h
#include sys/rman.h
#include machine/resource.h
@@ -210,6 +212,13 @@
SYSCTL_ULONG(_hw_cbb, OID_AUTO, debug, CTLFLAG_RW, cbb_debug, 0,
Verbose cardbus bridge debugging);
+int cbb_boot_deactivated = 0;
+TUNABLE_INT(hw.cbb.boot_deactivated, cbb_boot_deactivated);
+SYSCTL_INT(_hw_cbb, OID_AUTO, boot_deactivated, CTLFLAG_RD,
+cbb_boot_deactivated, 0,
+Override the automatic powering up of pccards at boot.);
+
+
static int cbb_chipset(uint32_t pci_id, const char **namep);
static int cbb_probe(device_t brdev);
static voidcbb_chipinit(struct cbb_softc *sc);
@@ -264,6 +273,93 @@
static voidcbb_write_config(device_t brdev, int b, int s, int f,
int reg, uint32_t val, int width);
+static d_open_tcrdopen;
+static d_close_t crdclose;
+static d_ioctl_t crdioctl;
+
+#define CDEV_MAJOR 50
+static struct cdevsw crd_cdevsw = {
+ /* open */ crdopen,
+ /* close */ crdclose,
+ /* read */ noread,
+ /* write */ nowrite,
+ /* ioctl */ crdioctl,
+ /* poll */ nopoll,
+ /* mmap */ nommap,
+ /* strategy */ nostrategy,
+ /* name */ crd,
+ /* maj */ CDEV_MAJOR,
+ /* dump */ nodump,
+ /* psize */ nopsize,
+ /* flags */ 0,
+};
+
+#define PIOCSVIR _IOW('P', 10, int) /* Virtual insert/remove */
+
+static int
+crdopen(dev_t dev, int oflags, int devtype, d_thread_t *td)
+{
+ if (dev == NULL || dev-si_drv1 == NULL) {
+ return (ENXIO);
+ }
+
+ return (0);
+}
+
+static int
+crdclose(dev_t dev, int fflag, int devtype, d_thread_t *td)
+{
+ return (0);
+}
+
+static int
+crdioctl(dev_t dev, u_long cmd, caddr_t data, int fflag, d_thread_t *td)
+{
+ struct cbb_softc *sc;
+ int error;
+ int pwval;
+
+ sc = dev-si_drv1;
+ error = 0;
+
+ switch(cmd) {
+ /*
+* Set power values.
+*/
+ case PIOCSVIR:
+ pwval = *(int *)data;
+
+ switch (pwval) {
+ case 0:
+ if (!(sc-flags CBB_CARD_OK)) {
+ error = EINVAL;
+ break;
+ }
+
+ sc-flags |= CBB_INACTIVATE;
+ cbb_removal(sc);
+ break;
+
+ case 1:
+ if (sc-flags CBB_CARD_OK) {
+ error = EINVAL;
+ break;
+ }
+
+ sc-flags = ~CBB_INACTIVATE;
+ cbb_insert(sc);
+ break;
+ }
+
+ break;
+
+ default:
+ error = ENOTTY;
+ }
+
+ return (error);
+}
+
/*
*/
static __inline void
@@ -560,6 +656,8 @@
{
struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(brdev);
int rid;
+ int unit;
+ dev_t cbb_dev_t;
mtx_init(sc-mtx, device_get_nameunit(brdev), cbb, MTX_DEF);
cv_init(sc-cv, cbb cv);
@@ -680,6 +778,10 @@
/* reset interrupt */
cbb_set(sc, CBB_SOCKET_EVENT, cbb_get(sc, CBB_SOCKET_EVENT));
+ if (cbb_boot_deactivated) {
+ sc-flags |= CBB_INACTIVATE;
+ }
+
/* Start the thread */
if (kthread_create(cbb_event_thread, sc, sc-event_thread, 0, 0,
%s%d, device_get_name(sc-dev), device_get_unit(sc-dev))) {
@@ -687,6 +789,10 @@
panic (cbb_create_event_thread);
}
+ unit = device_get_unit(sc-dev);
+ cbb_dev_t = make_dev(crd_cdevsw, unit, 0, 0, 0664, card%d, unit);
+ cbb_dev_t-si_drv1 = sc;
+
return (0);
err:
if
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
Hmmm, actually no. I know that some machines get panic with fatal trap
12 if we do 0x12 call. The worst case is getting panic, not losing
640K memory.
Where does the panic occur? I checked that there is no problem here if
the result of INT 0x12 is ignored and basemem is set to 0.
panic messages attached. It seems to be within BIOS routine after reti
jumped from vm86_bioscall.
Strangely, this panic can be recovered by continue command in DDB,
FreeBSD continues its boot process after this. So, this panic problem
is not serious for me :)
OTOH, the same problem in boot program is very critical, completely stops
with register dump...
FYI: On RELENG_4, this problem is critical too because this panic
isn't recoverable. This means that it's impossible to install onto
some newer machines.
And it seems that today's Linux don't have 0x12 calling any more,
so I didn't see any problem on the machines.
Now I have some ideas on this issue;
- 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?)
- 0x15/0xe820 call in locore.s before calling init386().
- specify the size by loader tunable (e.g. hw.basememsize).
I would first fix all the broken code that doesn't check for errors
and see if the problem goes away. Then recover any low memory not
reported by int 0x12 in the int 0x15/0xe820 code in i386/machdep.c,
like libi386/biosmem.c does it (I think machdep.c intentionally skips
the low memory, while biosmem.c tries to find it).
Cool. Thanks!
Stopped at 0xf842:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xf842
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc03b5108
stack pointer = 0x10:0xc0a68e90
frame pointer = 0x10:0xc0a68e94
code segment = base 0x0,limit 0xf, type 0x1b
= DPL 0, press 1, def32 1, gran 1
processor eflags = resume,IOPL = 0
current process = 0 ()
kernel:type 12 trap,code=0
db t
Fatal trap 12: page fault while in kernel mode
I've recalled that FreeBSD used RTC to determine base memory size in
old days. I've tested this method on my machines and confirmed it's
working well.
I'll commit this coming weekend if no objections.
Thanks
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.541
diff -u -r1.541 machdep.c
--- machdep.c 5 Oct 2002 14:36:14 - 1.541
+++ machdep.c 21 Oct 2002 15:27:02 -
@@ -1284,8 +1284,14 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)8)) 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)8)) 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
This would reintroduce a large bug. The RTC gives the hardware memory
size, but the interrupt gives the software memory size. These differ
for one of two machines under my desk (both have Award BIOSes). The
BIOS often steals some of the base memory. It's hard to tell whether
this memory will be used after FreeBSD determines the memory size. It
might be used for VM86 or (much more magically) for SMM.
Reading the memory size from BIOS RAM (offset 0x413) would be safer.
I'm not sure how standard this is. I thought that it is less standard
than INT 0x12.
OK, RELENG_3 GENERIC kernel might have problems with base memory, RTC
was used there...
How about this? It's my original idea.
Thanks
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.542
diff -u -r1.542 machdep.c
--- machdep.c 12 Oct 2002 05:32:23 - 1.542
+++ machdep.c 22 Oct 2002 03:04:15 -
@@ -1281,49 +1281,7 @@
bzero(vmf, sizeof(struct vm86frame));
bzero(physmap, sizeof(physmap));
-
- /*
-* Perform base memory related probes setup
-*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
- if (basemem 640) {
- printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
- basemem);
- basemem = 640;
- }
-
- /*
-* XXX if biosbasemem is now 640, there is a `hole'
-* between the end of base memory and the start of
-* ISA memory. The hole may be empty or it may
-* contain BIOS code or data. Map it read/write so
-* that the BIOS can write to it. (Memory from 0 to
-* the physical end of the kernel is mapped read-only
-* to begin with and then parts of it are remapped.
-* The parts that aren't remapped form holes that
-* remain read-only and are unused by the kernel.
-* The base memory area is below the physical end of
-* the kernel and right now forms a read-only hole.
-* The part of it from PAGE_SIZE to
-* (trunc_page(biosbasemem * 1024) - 1) will be
-* remapped and used by the kernel later.)
-*
-* This code is similar to the code used in
-* pmap_mapdev, but since no memory needs to be
-* allocated we simply change the mapping.
-*/
- for (pa = trunc_page(basemem * 1024);
-pa ISA_HOLE_START; pa += PAGE_SIZE)
- pmap_kenter(KERNBASE + pa, pa);
-
- /*
-* if basemem != 640, map pages r/w into vm86 page table so
-* that the bios can scribble on it.
-*/
- pte = (pt_entry_t *)vm86paddr;
- for (i = basemem / 4; i 160; i++)
- pte[i] = (i PAGE_SHIFT) | PG_V | PG_RW | PG_U;
+ basemem = 0;
/*
* map page 1 R/W into the kernel page table so we can use it
@@ -1391,6 +1349,60 @@
physmap[physmap_idx + 1] = smap-base + smap-length;
next_run: ;
} while (vmf.vmf_ebx != 0);
+
+ /*
+* Perform base memory related probes setup
+*/
+ for (i = 0; i = physmap_idx; i += 2) {
+ if (physmap[i] == 0x) {
+ basemem = physmap[i + 1] / 1024;
+ break;
+ }
+ }
+
+ /* Fall back to the old compatibility function for base memory */
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
+ if (basemem 640) {
+ printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
+ basemem);
+ basemem = 640;
+ }
+
+ /*
+* XXX if biosbasemem is now 640, there is a `hole'
+* between the end of base memory and the start of
+* ISA memory. The hole may be empty or it may
+* contain BIOS code or data. Map it read/write so
+* that the BIOS can write to it. (Memory from 0 to
+* the physical end of the kernel is mapped read-only
+* to begin with and then parts of it are remapped.
+* The parts that aren't remapped form holes that
+* remain read-only and are unused by the kernel.
+* The base memory area is below the physical end of
+* the kernel and right now forms a read-only hole.
+* The part of it from PAGE_SIZE to
+* (trunc_page(biosbasemem * 1024) - 1) will be
+* remapped and used by the kernel
Re: PCI problems with today's current
If still NG, please try the attached patch against SupermicroP3TDE6.asl. # _BBN is bridge bus number, my guess is 0x3. You can try to change it # if failed. Maybe 0x2 is correct. I tried 2, and it seems to work correctly now. Thanks! Congratulations! # Now we can start discussing ACPI PCI vs. legacy PCI :) DSDT in ACPI BIOS on Supermicro P3TDE6 has obviously wrong _BBN value, but previous kernel can fall back to legacy PCI bridge probing even if PCI bridge probing by ACPI is failed. From: Kenneth D. Merry [EMAIL PROTECTED] Subject: PCI problems with today's current Date: Thu, 3 Oct 2002 17:57:06 -0600 Message-ID: [EMAIL PROTECTED] acpi_pcib1: Host-PCI bridge on acpi0 acpi_pcib1: we have duplicate bus number 0 - not probing bus [snip] pcib2: ServerWorks host to PCI bridge at pcibus 2 on motherboard IOAPIC #1 intpin 8 - irq 16 pci2: PCI bus on pcib2 ti0: Netgear GA620 1000baseT Gigabit Ethernet mem 0xfebfc000-0xfebf irq 16 at device 2.0 on pci2 I think that previous probing system is much more robust and safer in many cases, especially buggy ACPI BIOS. John, can we have previous PCI probing system again? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
Hi, But never mind, you can force to compile the ASL and generate DSDT; # iasl -i SupermicroP3TDE6.new.asl then copy generated acpi_dsdt.aml to /boot/. # cp acpi_dsdt.aml /boot/ Okay, I did that, and then typed the following at the boot prompt: set acpi_dsdt_load=YES set acpi_dsdt_name=/boot/acpi_dsdt.aml Things still don't seem to be working properly. I've attached dmesg output. [snip] Preloaded elf kernel /boot/kernel.test32/kernel at 0xc0569000. Preloaded elf module /boot/kernel.test32/acpi.ko at 0xc05690b0. Timecounter i8254 frequency 1193182 Hz Hmm, it seems that /boot/acpi_dsdt.aml doesn't to be loaded. I think `set acpi_dsdt_load=YES' at the boot prompt is not effective. How about having acpi_dsdt_load=YES in your loader.conf, or typing `load -t acpi_dsdt /boot/acpi_dsdt.aml' at the boot prompt ? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
How about having acpi_dsdt_load=YES in your loader.conf, or typing `load -t acpi_dsdt /boot/acpi_dsdt.aml' at the boot prompt ? I tried 'load -t...', and the aml file seems to get loaded. Things don't fail in the same way now, but I still can't see ti0, which is on the PCI bus in question. OK, now that all PCI bridges were probed, but the last one seems to have wrong bus number. pcib2: ACPI Host-PCI bridge on acpi0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci3: ACPI PCI bus on pcib2 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 As I told before, could you change _BBN value in the patch and try again? From: Mitsuru IWASAKI [EMAIL PROTECTED] Subject: Re: PCI problems with today's current Date: Sat, 05 Oct 2002 12:09:47 +0900 (JST) Message-ID: [EMAIL PROTECTED] If still NG, please try the attached patch against SupermicroP3TDE6.asl. # _BBN is bridge bus number, my guess is 0x3. You can try to change it # if failed. Maybe 0x2 is correct. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
Hi,
I tried the patches you checked in, and PCI bus 2 on my machine still isn't
probed. See the attached dmesg.
I'm a bit confused about just what sort of file the ACPI code expects to
load on boot.
I installed the acpicatools port, so I've got iasl(1), but it appears to
have 4 output modes (C or assembly source, C or assembly hex table), at
least for AML output (which acpi(4) says is what you need to load), and
no output modes for DSDT files.
Ok, you got errors from iasl, like;
SupermicroP3TDE6.new.asl56: Scope(DEB_) {
Error1077 - ^ Existing object has invalid type for Scope
operator (DEB_, Integer)
This is invalid, so ACPI CA interpreter in our kernel complains;
ACPI-0623: *** Warning: Type override - [DEB_] had invalid type (Integer) for
Scope operator, changed to (Scope)
But never mind, you can force to compile the ASL and generate DSDT;
# iasl -i SupermicroP3TDE6.new.asl
then copy generated acpi_dsdt.aml to /boot/.
# cp acpi_dsdt.aml /boot/
I'll think about other possibilities to solve this...
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
HEADSUP: acpica-unix-20021002 imported (Re: cvs commit:src/sys/contrib/dev/acpica - Imported sources)
I've imported Intel acpica-unix-20021002 which is the latest version. It seems that some problems related with ACPI namespace parsing are solved from 20020815. Detailed info. about changes is available at: http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt If you have any problems with the new version, please report to [EMAIL PROTECTED] Thanks! From: Mitsuru IWASAKI [EMAIL PROTECTED] Subject: cvs commit: src/sys/contrib/dev/acpica - Imported sources Date: Fri, 4 Oct 2002 13:07:58 -0700 (PDT) Message-ID: [EMAIL PROTECTED] iwasaki 2002/10/04 13:07:58 PDT src/sys/contrib/dev/acpica - Imported sources Update of /home/ncvs/src/sys/contrib/dev/acpica In directory freefall.freebsd.org:/d/home/iwasaki/tmp/acpica/acpi_ca_destination Log Message: Vendor import of the Intel ACPI CA 20021002 drop. Status: Vendor Tag: INTEL Release Tags: r20021002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI errors and then panic
Hi, # ACPI CA related problem should be sent to [EMAIL PROTECTED] # so that Intel folks can be aware of the problem. From: Nate Lawson [EMAIL PROTECTED] Subject: ACPI errors and then panic Date: Fri, 4 Oct 2002 17:14:31 -0700 (PDT) Message-ID: [EMAIL PROTECTED] My laptop appears to work ok without ACPI but of course I don't get suspend, resume, etc. I have never been able to get ACPI to work with it, including with a -current as of 2 hours ago. If ACPI is enabled, I get a spew of: ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name and then a panic from acpi_attach. First several lines of DDB backtrace would be very helpful to track the problem down. Also having following lines in your loader.conf would be helpful to determine which object causes the ACPI CA Eroor. debug.acpi.layer=ACPI_ALL_COMPONENTS ACPI_BUS debug.acpi.level=ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS BTW, what's model name? Some ThinkPad's are blacklisted such as IBM 600E. And may I add your ACPI data to our repo. (in Japan) ? Here are the appropriate files... http://www.root.org/~nate/acpi/ibm.aml http://www.root.org/~nate/acpi/ibm.dsdt http://www.root.org/~nate/acpi/ibm.dmesg (from a working boot) Let me know if you need more info. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
Hi, From: John Baldwin [EMAIL PROTECTED] Subject: RE: PCI problems with today's current Date: Fri, 04 Oct 2002 16:03:08 -0400 (EDT) Message-ID: [EMAIL PROTECTED] On 03-Oct-2002 Kenneth D. Merry wrote: I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that won't boot with today's -current. -current from August 23rd sources boots fine. It looks like the PCI bus probe is failing somehow. I've seen other folks complaining about PCI problems, and I suppose this is related, but I don't think I've seen quite the same failure reported. I've attached dmesg output from the working kernel (August 23rd sources) and the broken kernel (sources from ~1500 MDT today). Any ideas on how to fix this? Turn off ACPI for now (set hint.acpi.0.disabled=1). Iwasaki-san has a fix for this that I guess he should commit. OK, just committed. Also imported the latest version of ACPI CA. Ken, if your problem still remains with acpi enabled, I'll report this to Intel folks. So, please let me know the result. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
Hi, OK, just committed. Also imported the latest version of ACPI CA. Ken, if your problem still remains with acpi enabled, I'll report this to Intel folks. So, please let me know the result. Looks like your mail crossed mine on the wire. :) indeed :) I'm having trouble with the latest ACPI drop still, but I don't have the patches you just checked in. Will the patches you just checked in possibly fix the problem? If so, I'll cvsup and try them out. 99.999%, Yes. BTW, I'm interested in ACPI BIOS of your motherboard. Could you send me dumped ACPI data? I'd like to add them to our development resource. Just like this. # acpidump -o SupermicroP3TDE6.dsdt SupermicroP3TDE6.asl Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
Hi,
Will the patches you just checked in possibly fix the problem? If so, I'll
cvsup and try them out.
99.999%, Yes.
Cool! I'll cvsup and try it out.
If still NG, please try the attached patch against SupermicroP3TDE6.asl.
# _BBN is bridge bus number, my guess is 0x3. You can try to change it
# if failed.
Then please generate DSDT file and orverride DSDT at kernel boot.
You can find detail procedures in acpi(4) 'OVERRIDING YOUR BIOS BYTECODE'.
Could you send me dumped ACPI data? I'd like to add them to
our development resource.
Just like this.
# acpidump -o SupermicroP3TDE6.dsdt SupermicroP3TDE6.asl
Sure. I assume you want the .asl file only? I've attached that. I can
send the other one too if you need it.
Yes, please send me SupermicroP3TDE6.dsdt directly.
Thanks
--- SupermicroP3TDE6.asl- Sat Oct 5 11:51:34 2002
+++ SupermicroP3TDE6.aslSat Oct 5 11:52:06 2002
@@ -2508,7 +2508,7 @@
Name(_HID, 0x030ad041)
Name(_UID, 0x2)
Name(_ADR, 0x3)
-Name(_BBN, 0x0)
+Name(_BBN, 0x3)
Method(OINI) {
Noop
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PCI brokenness
# I could be wrong, please correct me :)
I think that Libretto 110CT doesn't have PCI-ISA bridge , so no isab,
no isa, no isahint (requires isa) w/ acpi enabled.
Hmmm, \_SB.PCI0.EIO has no _ADR, _HID instead.
But I think ISA or LPC controller exists in this system.
Adding some device ID to isa_pci.c will solve this?
OK, I enclose dmesg w/ boot -v from mark's first post for convenience.
pci0: physical bus=0
found- vendor=0x1179, dev=0x0601, revid=0x2e
bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
map[10]: type 3, range 32, base fd00, size 24, enabled
map[14]: type 1, range 32, base ffc0, size 21, enabled
map[18]: type 1, range 32, base ffb0, size 20, enabled
found- vendor=0x10c8, dev=0x0004, revid=0x01
bus=0, slot=4, func=0
class=03-00-00, hdrtype=0x00, mfdev=0
intpin=a, irq=255
map[10]: type 4, range 32, base , size 5, port disabled
found- vendor=0x1179, dev=0x0701, revid=0x22
bus=0, slot=17, func=0
class=07-80-00, hdrtype=0x00, mfdev=0
intpin=a, irq=255
found- vendor=0x1179, dev=0x060f, revid=0x20
bus=0, slot=19, func=0
class=06-07-00, hdrtype=0x02, mfdev=1
intpin=a, irq=255
found- vendor=0x1179, dev=0x060f, revid=0x20
bus=0, slot=19, func=1
class=06-07-00, hdrtype=0x02, mfdev=1
intpin=b, irq=255
In legacy case, we have at least isa0 on motherboard even if there
is no ISA bridge. OTOH, we never see isa0 if there is no ISA bridge
in ACPI case.
Also, most of isa device driver (more than 70!) don't have acpi
attachment yet, including some important drivers such as sc0.
Hmmm, it's not so simple...
How about having acpi_isa bus code so that we have at least isa0
on the system w/o ISA bridge ?
Is that be able multiple multipule isa bus exist in the system?
I'm not sure, but my thought was something like following patches.
Thanks
Index: dev/acpica/acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.75
diff -u -r1.75 acpi.c
--- dev/acpica/acpi.c 6 Sep 2002 17:01:06 - 1.75
+++ dev/acpica/acpi.c 3 Oct 2002 10:13:51 -
@@ -777,6 +777,10 @@
if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, scopes[i], parent)))
AcpiWalkNamespace(ACPI_TYPE_ANY, parent, 100, acpi_probe_child, bus, NULL);
+if (devclass_get_device(devclass_find(isa), 0) == NULL) {
+ device_set_flags(BUS_ADD_CHILD(bus, 0, isa, 0), 1);
+}
+
/*
* Scan all of the child devices we have created and let them probe/attach.
*/
Index: isa/isa_common.c
===
RCS file: /home/ncvs/src/sys/isa/isa_common.c,v
retrieving revision 1.31
diff -u -r1.31 isa_common.c
--- isa/isa_common.c30 Sep 2002 07:56:12 - 1.31
+++ isa/isa_common.c3 Oct 2002 10:13:04 -
@@ -1107,6 +1107,60 @@
1, /* no softc */
};
+static int
+acpi_isa_probe(device_t dev)
+{
+
+ if (device_get_flags(dev) == 0) {
+ return (ENXIO);
+ }
+
+ return (isa_probe(dev));
+}
+
+static device_method_t acpi_isa_methods[] = {
+ /* Device interface */
+ DEVMETHOD(device_probe, acpi_isa_probe),
+ DEVMETHOD(device_attach,isa_attach),
+ DEVMETHOD(device_detach,bus_generic_detach),
+ DEVMETHOD(device_shutdown, bus_generic_shutdown),
+ DEVMETHOD(device_suspend, bus_generic_suspend),
+ DEVMETHOD(device_resume,bus_generic_resume),
+
+ /* Bus interface */
+ DEVMETHOD(bus_add_child,isa_add_child),
+ DEVMETHOD(bus_print_child, isa_print_child),
+ DEVMETHOD(bus_probe_nomatch,isa_probe_nomatch),
+ DEVMETHOD(bus_read_ivar,isa_read_ivar),
+ DEVMETHOD(bus_write_ivar, isa_write_ivar),
+ DEVMETHOD(bus_child_detached, isa_child_detached),
+ DEVMETHOD(bus_driver_added, isa_driver_added),
+ DEVMETHOD(bus_setup_intr, isa_setup_intr),
+ DEVMETHOD(bus_teardown_intr,isa_teardown_intr),
+
+ DEVMETHOD(bus_get_resource_list,isa_get_resource_list),
+ DEVMETHOD(bus_alloc_resource, isa_alloc_resource),
+ DEVMETHOD(bus_release_resource, isa_release_resource),
+ DEVMETHOD(bus_set_resource, isa_set_resource),
+ DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
+ DEVMETHOD(bus_delete_resource, bus_generic_rl_delete_resource),
+ DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
+ DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
+
+ /* ISA interface */
+ DEVMETHOD(isa_add_config, isa_add_config),
+ DEVMETHOD(isa_set_config_callback, isa_set_config_callback),
+ DEVMETHOD(isa_pnp_probe,isa_pnp_probe),
+
+ { 0,
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
Hi, The patch makes no difference for booting directly from boot2 ... except memsize() in boot2 also fails to check for errors, so it returns garbage values. Yes I know that :-) But booting kernel directly from boot2 is not working at all for several years, so my understanding is that /boot/loader is necessary to boot kernel. It mostly works. I submitted patches in a PR many years ago and still use them. Great! I tried to find the PR, but couldn't find... Why isn't it committed yet? :-) Hmmm, actually no. I know that some machines get panic with fatal trap 12 if we do 0x12 call. The worst case is getting panic, not losing 640K memory. Where does the panic occur? I checked that there is no problem here if the result of INT 0x12 is ignored and basemem is set to 0. panic messages attached. It seems to be within BIOS routine after reti jumped from vm86_bioscall. Strangely, this panic can be recovered by continue command in DDB, FreeBSD continues its boot process after this. So, this panic problem is not serious for me :) OTOH, the same problem in boot program is very critical, completely stops with register dump... And it seems that today's Linux don't have 0x12 calling any more, so I didn't see any problem on the machines. Now I have some ideas on this issue; - 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?) - 0x15/0xe820 call in locore.s before calling init386(). - specify the size by loader tunable (e.g. hw.basememsize). I would first fix all the broken code that doesn't check for errors and see if the problem goes away. Then recover any low memory not reported by int 0x12 in the int 0x15/0xe820 code in i386/machdep.c, like libi386/biosmem.c does it (I think machdep.c intentionally skips the low memory, while biosmem.c tries to find it). Cool. Thanks! Stopped at 0xf842: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf842 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03b5108 stack pointer = 0x10:0xc0a68e90 frame pointer = 0x10:0xc0a68e94 code segment= base 0x0,limit 0xf, type 0x1b = DPL 0, press 1, def32 1, gran 1 processor eflags= resume,IOPL = 0 current process = 0 () kernel:type 12 trap,code=0 db t Fatal trap 12: page fault while in kernel mode To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI brokenness
Hmm, ata0 may be getting the wrong resources. Hmm. Try iwasaki-san's patch to acpi_pcib_* instead and see if it that helps. Either that or turn off ACPI for the time being. Iwasaki-San's patch made no difference that I could see. Disabling ACPI causes my system to hard-hang during reboot. I might be able to fix that by futzing with device.hints, but that took me a whole weekend and a reinstall last time I tried. Device.hints is a dangerous thing to play with. Hmmm, did you rebuild and reinstall acpi.ko ? At least cbb should be appeared under pci0 Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Call for testers] acpica-unix-20020918
[forgot to announce] Please try the latest version acpica-unix-20020829, patches for FreeBSD at: http://people.freebsd.org/~iwasaki/acpi/acpica-20020815-20020918-test20020920.diff CHANGES.txt can be fould as always at: http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt I'll import this coming weekend. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI brokenness
Hi,
On 01-Oct-2002 Michael McGoldrick wrote:
On Tue, Oct 01, 2002 at 12:48:47PM -0400, John Baldwin wrote:
On 01-Oct-2002 Michael McGoldrick wrote:
'Me too'
Dmesg from working kernel attached, not sure how to get a dmesg from the
broken one. :(
Send me a mail if any further info would help.
(I have built two kernels recently, both have had this problem)
What exact problem do you have. No PCI devices?
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Yes, the kernel seems to attempt to mount root right after this line:
device_probe_and_attach: acpi0 attach returned 6
Can you try with the stuff I committed yesterday? It fixed the case (for
my tests at least) of legacy0 failing to attach or probe when acpi failed
to attach.
If still failed, please try this.
I've noticed that no chance to call pci_cfgregopen() before probing
PCI children in case Host PCI bridge _CRS is not method or _INI method
don't access to PCI config space or something.
Thanks
Index: acpi_pcib_acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_acpi.c,v
retrieving revision 1.23
diff -u -r1.23 acpi_pcib_acpi.c
--- acpi_pcib_acpi.c26 Aug 2002 18:30:27 - 1.23
+++ acpi_pcib_acpi.c1 Oct 2002 23:17:51 -
@@ -114,6 +115,9 @@
!acpi_disabled(pci)
acpi_MatchHid(dev, PNP0A03)) {
+ if (!pci_cfgregopen())
+ return(ENXIO);
+
/*
* Set device description
*/
Index: acpi_pcib_pci.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_pci.c,v
retrieving revision 1.1
diff -u -r1.1 acpi_pcib_pci.c
--- acpi_pcib_pci.c 26 Aug 2002 18:30:27 - 1.1
+++ acpi_pcib_pci.c 1 Oct 2002 23:18:38 -
@@ -114,6 +115,9 @@
return (ENXIO);
if (acpi_get_handle(dev) == NULL)
return (ENXIO);
+if (!pci_cfgregopen())
+ return (ENXIO);
+
device_set_desc(dev, ACPI PCI-PCI bridge);
return (-1000);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
Hi,
Index: sys/i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.532
diff -u -r1.532 machdep.c
--- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 - 1.532
+++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -
@@ -1269,8 +1269,12 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if (bootinfo.bi_basemem != 0) {
+ basemem = bootinfo.bi_basemem;
+ } else {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
The kernel hasn't used bootinfo.bi_basemem for a long time and shouldn't
start using it again now. It already uses the 0x15/0xe820 call for
everything except basemem (except when the this call fails, it falls
back to 0x15/0xe801). Maybe the bug has something to do with the
kernel using the 0x12 call without checking whether the call succeeded.
When both the 0x15/0xe820 and the 0x15/0xe801 calls fail, the kernel
falls back to an 0x15/0x88 call for determining extmem ... except this
is ifdefed out and replaced by looking at the rtc values. Maybe the
unreliability of the 0x15/0x88 call has something to do with not
checking if the call succeeded.
Yes, I think the best way to determine base mem size in getmemsize()
is to try 0x15/0xe820 call first, then fall back to 0x12 call. But
I'm not sure whether it's OK to call vm86_datacall(0x15) before
determining base mem size...
The patch makes no difference for booting directly from boot2 ... except
memsize() in boot2 also fails to check for errors, so it returns garbage
values.
Yes I know that :-)
But booting kernel directly from boot2 is not working at all for
several years, so my understanding is that /boot/loader is necessary
to boot kernel.
I think the basemem == 0 case should just work, so the systems with a
broken INT 0x12 should at worst lose 640K of memory, no matter whether
basemem is set to 0 because INT 0x12 fails or because it actually
returns 0.
Hmmm, actually no. I know that some machines get panic with fatal trap
12 if we do 0x12 call. The worst case is getting panic, not losing
640K memory.
And it seems that today's Linux don't have 0x12 calling any more,
so I didn't see any problem on the machines.
Now I have some ideas on this issue;
- 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?)
- 0x15/0xe820 call in locore.s before calling init386().
- specify the size by loader tunable (e.g. hw.basememsize).
Comments?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[PATCH] Workaround for bogus INT 12H BIOS service implementation
Hi, I've found that some recent machine's BIOS doesn't support INT 12H
(Get base memory size) BIOS service, instead they seems to support
SMAP (system memory map: INT 15H function e820H) for this purpose.
I already checked that there is no problems on Linux or Windows or
others, but FreeBSD won't boot at all.
I'll report bogus INT 12H BIOS service implementation to BIOS vendors
if I get chances. On the other hand, I think we need to have a
workaround in a safety way for this problem for newer machines.
Here is the patches. I'll commit them in a few days if no objection.
Thanks
Index: sys/boot/i386/boot2/boot2.c
===
RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot2.c,v
retrieving revision 1.44
diff -u -r1.44 boot2.c
--- sys/boot/i386/boot2/boot2.c 1 Sep 2002 21:29:10 - 1.44
+++ sys/boot/i386/boot2/boot2.c 29 Sep 2002 21:16:19 -
@@ -231,7 +231,7 @@
dsk.slice = *(uint8_t *)PTOV(ARGS + 1) + 1;
bootinfo.bi_version = BOOTINFO_VERSION;
bootinfo.bi_size = sizeof(bootinfo);
-bootinfo.bi_basemem = memsize(MEM_BASE);
+bootinfo.bi_basemem = 0; /* XXX will be filled at loader or kernel */
bootinfo.bi_extmem = memsize(MEM_EXT);
bootinfo.bi_memsizes_valid++;
for (i = 0; i N_BIOS_GEOM; i++)
Index: sys/boot/i386/loader/main.c
===
RCS file: /home/ncvs/src/sys/boot/i386/loader/main.c,v
retrieving revision 1.25
diff -u -r1.25 main.c
--- sys/boot/i386/loader/main.c 5 Nov 2001 19:03:01 - 1.25
+++ sys/boot/i386/loader/main.c 29 Sep 2002 21:01:51 -
@@ -129,6 +129,10 @@
if (devsw[i]-dv_init != NULL)
(devsw[i]-dv_init)();
printf(BIOS %dkB/%dkB available memory\n, bios_basemem / 1024, bios_extmem /
1024);
+if (initial_bootinfo != NULL) {
+ initial_bootinfo-bi_basemem = bios_basemem / 1024;
+ initial_bootinfo-bi_extmem = bios_extmem / 1024;
+}
/* detect ACPI for future reference */
biosacpi_detect();
Index: sys/i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.532
diff -u -r1.532 machdep.c
--- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 - 1.532
+++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -
@@ -1269,8 +1269,12 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if (bootinfo.bi_basemem != 0) {
+ basemem = bootinfo.bi_basemem;
+ } else {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[PATCH] Broadcom BCM5702X Gigabit Ethernet support
# I'm not sure whom to send this patch, but the last person edited
# if_bge.c seems to be you :)
Hi, I got a new machine with Broadcom BCM5702X Gigabit Ethernet.
This NIC isn't supported yet, so I wrote simple patches for it.
It's working now, so far so good :)
Could you review the patches and commit them if acceptable?
# Or may I commit this with confidence?
Thanks
Index: sys/dev/bge/if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.19
diff -u -r1.19 if_bge.c
--- sys/dev/bge/if_bge.c8 Sep 2002 19:11:58 - 1.19
+++ sys/dev/bge/if_bge.c28 Sep 2002 09:56:11 -
@@ -141,6 +141,8 @@
Broadcom BCM5700 Gigabit Ethernet },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5701,
Broadcom BCM5701 Gigabit Ethernet },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5702X,
+ Broadcom BCM5702X Gigabit Ethernet },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5703X,
Broadcom BCM5703X Gigabit Ethernet },
{ SK_VENDORID, SK_DEVICEID_ALTIMA,
Index: sys/dev/bge/if_bgereg.h
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.7
diff -u -r1.7 if_bgereg.h
--- sys/dev/bge/if_bgereg.h 8 Sep 2002 19:11:58 - 1.7
+++ sys/dev/bge/if_bgereg.h 28 Sep 2002 09:56:15 -
@@ -1784,6 +1784,7 @@
#define BCOM_VENDORID 0x14E4
#define BCOM_DEVICEID_BCM5700 0x1644
#define BCOM_DEVICEID_BCM5701 0x1645
+#define BCOM_DEVICEID_BCM5702X 0x16A6
#define BCOM_DEVICEID_BCM5703X 0x16A7
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: booting hangs at acpi.ko
Hi, I'm trying to upgrade from 4.6-Stable to Current. I had some difficulties to make buildworld/buildkernel complete. Then I created an empty /boot/device.hints to make. Now when trying to boot it hangs: Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x37174 data=0x1a84+0x6e0 syms=[0x4+0x5540+0x4+0x702d/ ] Is there a way this can be solved? Or should I install 4.6.2 again and upgrade again? If you think this is caused by acpi.ko, just disable acpi.ko loading. Please read thru loader(8) and device.hints(5). Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] Promise PDC20277 ATA RAID controller support
Hi, I got a new machine with Promise PDC20277 ATA RAID controller.
This controller isn't supported yet, so I wrote simple patches for it.
It's working now, so far so good :)
Soren, Could you review the patches and commit them if acceptable?
Thanks
Index: dev/ata/ata-dma.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v
retrieving revision 1.102
diff -u -r1.102 ata-dma.c
--- dev/ata/ata-dma.c 14 Sep 2002 18:59:32 - 1.102
+++ dev/ata/ata-dma.c 27 Sep 2002 14:50:30 -
@@ -1042,6 +1042,7 @@
case 0x4d69105a: /* Promise TX2 ATA133 controllers */
case 0x5275105a: /* Promise TX2 ATA133 controllers */
case 0x6269105a: /* Promise TX2 ATA133 controllers */
+case 0x7275105a: /* Promise PDC20277 controllers */
ATA_OUTB(atadev-channel-r_bmio, ATA_BMDEVSPEC_0, 0x0b);
if (udmamode = 6
!(ATA_INB(atadev-channel-r_bmio, ATA_BMDEVSPEC_1) 0x04)) {
Index: dev/ata/ata-pci.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-pci.c,v
retrieving revision 1.45
diff -u -r1.45 ata-pci.c
--- dev/ata/ata-pci.c 14 Sep 2002 18:59:32 - 1.45
+++ dev/ata/ata-pci.c 27 Sep 2002 10:34:56 -
@@ -282,6 +282,9 @@
case 0x6269105a:
return Promise TX2 ATA133 controller;
+case 0x7275105a:
+ return Promise PDC20277 controller;
+
case 0x00041103:
switch (pci_get_revid(dev)) {
case 0x00:
@@ -594,6 +597,7 @@
case 0x4d69105a: /* Promise TX2 ATA133 */
case 0x5275105a: /* Promise TX2 ATA133 */
case 0x6269105a: /* Promise TX2 ATA133 */
+case 0x7275105a: /* Promise PDC20277 */
ATA_OUTB(ch-r_bmio, ATA_BMDEVSPEC_0, 0x0b);
if (!(ATA_INB(ch-r_bmio, ATA_BMDEVSPEC_1) 0x20))
return 1;
Index: dev/ata/ata-raid.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-raid.c,v
retrieving revision 1.47
diff -u -r1.47 ata-raid.c
--- dev/ata/ata-raid.c 12 Apr 2002 14:10:19 - 1.47
+++ dev/ata/ata-raid.c 27 Sep 2002 09:38:15 -
@@ -123,6 +123,7 @@
case 0x4d33105a: case 0x4d38105a: case 0x4d30105a:
case 0x0d30105a: case 0x4d68105a: case 0x6268105a:
case 0x4d69105a: case 0x5275105a: case 0x6269105a:
+case 0x7275105a:
/* test RAID bit in PCI reg XXX */
return (ar_promise_read_conf(adp, ar_table, 0));
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1789] Re: ACPI video driver (for Dell Latitude C640)
On Thu, Aug 29, 2002 at 11:11:15PM +0200, Mark Santcroos wrote: I worked around this by making the driver a child of pci instead of a child of acpi. (Which is even more correct too) My driver is a child of acpi again and at this point it always seems to be called at resume too. I don't know whether that is due to the latest acpi patches (29/8) or other changes in the kernel. (At this point I don't want to spent time tracking that down) Sorry for my late response. I've been checking your driver, and it always seems suspend/resume methods are called. It's; DRIVER_MODULE(acpi_agp, acpi, acpi_agp_driver, acpi_agp_devclass, 0, 0); version. However, getting my screen back doesn't work yet. So there might be more too it. (In the worst case, the 'OFF' I do, is different than the 'OFF' the system does, so doing my 'ON' doesn't influence the systems 'OFF') It turned out to be the 'worst case'. The 'OFF' I was doing is not the same 'OFF' as the system itself is doing. (Actually my OFF was a display switch from one to another without going to the other actually. It was a wild guess and turned to be wrong) Do you think that there is a change that this is in the direction of DPMS, or is that very unliky? I tried to find the spec for DPMS but it seems to be a closed on (at least to non-members). It seems that old laptops don't have VGA specific ACPI objects, so many people will be happy if we can implement non-ACPI VGA driver w/ ATI chips hack. BTW, have you checked for XFree86 code? Hopefully we might find some hints on DPMS for ATI chips. I'm back to where I started basicly (besides knowing more about acpi now). Never mind. I know one more guy who writing ACPI VGA driver, takawata-san([EMAIL PROTECTED]). Could you send him your latest code and contact him? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI support (was Re: apm support)
[subject was changed] Hi, WinXP, it was running under ACPI. However, with the GENERIC kernel, the fan doesn't seem to go on. Is there a way to disable the system from suspending when the lid is closed? or would adding device apm to the kernel and then enabling apmd and apm in rc.conf cause it to read the settings in the BIOS which I used the ThinkPad PS2 utility to configure instead? When I attempt to do a make buildworld, after about 5 minutes it would display the following message and then the system shuts off by itself shortly thereafter. Sep 9 11:01:32 exabyte kernel: acpi_tz0: WARNING - current temperature (97.8C) exceeds system limits It seems that your sysctl has wrong configuration and your kernel maybe too old. to disable sleep state transition by lid switch: hw.acpi.lid_switch_state=NONE APM BIOS is completely disabled when acpi(4) is enabled. The acpi(4) just emulates limited functions of APM by using acpi functions. Cooling system control code had serious bugs, fixed at 8/27. hw.acpi.thermal.tz0.active=-1 should be OK if you want auto-thermal management. To force thermal zones activated: hw.acpi.thermal.tz0.active=0 hw.acpi.thermal.tz1.active=0 [snip] hw.acpi.thermal.tz5.active=0 hw.acpi.thermal.tz6.active=0 Note that hw.acpi.thermal.tz0.active=1 is worng because it is not bool value, and hw.acpi.thermal.tz0._ACx: 3632 -1 -1 -1 -1 -1 -1 -1 -1 -1 there is no _AC1. There is only _AC0, so 0 must be specified to hw.acpi.thermal.tz0.active to force tz0 activated. ACPI for FreeBSD is still under development, the best way to obtain the most accurate info. is check /sys/dev/acpica/*.[ch] files for now :-) Documents at http://acpi.info/spec.htm would be helpful too. Of course, volunteers for development and documentation always are welcome. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] 'ata_dmasetup: transfer active on this device!' problem onresume
Hi, Soren. I got panics with 'ata_dmasetup: transfer active on this
device!' on resume, and have made patches for this.
Problem was that certain process is accessing ATA disk via DMA
transfer on suspend, however the transfer was not completed in most cases,
then ata_dmastart() (called by ata_reinit()) got panic on resume.
My patches will do those things during suspend time;
- wait for DMA transfer completion if it is on the way.
- cancel new requests (yes, it's possible even during suspend
time) for ATA disks and remain them in ATA queue.
Could you review the patches and commit them if OK?
Thanks
Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.153
diff -u -r1.153 ata-all.c
--- ata-all.c 9 Aug 2002 20:51:53 - 1.153
+++ ata-all.c 4 Sep 2002 10:21:22 -
@@ -279,8 +279,46 @@
}
int
+ata_suspend(device_t dev)
+{
+struct ata_channel *ch;
+
+ch = device_get_softc(dev);
+
+#ifdef DEV_ATADISK
+if (ch-devices ATA_ATA_MASTER ch-device[MASTER].driver) {
+ ch-device[MASTER].suspended = 1;
+ if (ch-device[MASTER].mode = ATA_DMA) {
+ ata_waitdmadone(ch-device[MASTER]);
+ }
+}
+if (ch-devices ATA_ATA_SLAVE ch-device[SLAVE].driver) {
+ ch-device[SLAVE].suspended = 1;
+ if (ch-device[SLAVE].mode = ATA_DMA) {
+ ata_waitdmadone(ch-device[SLAVE]);
+ }
+}
+#endif
+
+return 0;
+}
+
+int
ata_resume(device_t dev)
{
+struct ata_channel *ch;
+
+ch = device_get_softc(dev);
+
+#ifdef DEV_ATADISK
+if (ch-devices ATA_ATA_MASTER ch-device[MASTER].driver) {
+ ch-device[MASTER].suspended = 0;
+}
+if (ch-devices ATA_ATA_SLAVE ch-device[SLAVE].driver) {
+ ch-device[SLAVE].suspended = 0;
+}
+#endif
+
return ata_reinit(device_get_softc(dev));
}
@@ -674,6 +712,20 @@
ad_start(ch-device[MASTER]);
if (ch-devices (ATA_ATA_SLAVE) ch-device[SLAVE].driver)
ad_start(ch-device[SLAVE]);
+}
+if (ch-devices (ATA_ATA_MASTER) ch-device[MASTER].driver) {
+ if (ch-device[MASTER].suspended ch-device[MASTER].mode = ATA_DMA) {
+ printf(%s: going to suspend, ignoring.\n, __func__);
+ splx(s);
+ return;
+}
+}
+if (ch-devices (ATA_ATA_SLAVE) ch-device[SLAVE].driver) {
+ if (ch-device[SLAVE].suspended ch-device[MASTER].mode = ATA_DMA) {
+ printf(%s: going to suspend, ignoring.\n, __func__);
+ splx(s);
+ return;
+}
}
if ((ad_request = TAILQ_FIRST(ch-ata_queue))) {
TAILQ_REMOVE(ch-ata_queue, ad_request, chain);
Index: ata-all.h
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v
retrieving revision 1.53
diff -u -r1.53 ata-all.h
--- ata-all.h 18 Apr 2002 19:11:43 - 1.53
+++ ata-all.h 4 Sep 2002 06:25:24 -
@@ -189,6 +189,7 @@
intcmd;/* last cmd executed */
void *result;/* misc data */
struct ata_dmastatedmastate; /* dma state */
+intsuspended; /* 0 = normal 1 = suspended */
};
/* structure describing an ATA channel */
@@ -252,6 +253,7 @@
int ata_probe(device_t);
int ata_attach(device_t);
int ata_detach(device_t);
+int ata_suspend(device_t);
int ata_resume(device_t);
void ata_start(struct ata_channel *);
@@ -280,6 +282,7 @@
int ata_dmasetup(struct ata_device *, caddr_t, int32_t);
int ata_dmastart(struct ata_device *, caddr_t, int32_t, int);
int ata_dmastatus(struct ata_channel *);
+void ata_waitdmadone(struct ata_device *);
int ata_dmadone(struct ata_device *);
/* macros for locking a channel */
Index: ata-dma.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v
retrieving revision 1.100
diff -u -r1.100 ata-dma.c
--- ata-dma.c 19 Jul 2002 22:14:54 - 1.100
+++ ata-dma.c 4 Sep 2002 11:15:50 -
@@ -31,6 +31,7 @@
#include sys/param.h
#include sys/systm.h
#include sys/ata.h
+#include sys/kernel.h
#include sys/bio.h
#include sys/endian.h
#include sys/malloc.h
@@ -1284,8 +1285,11 @@
struct ata_dmastate *ds = atadev-dmastate;
struct ata_dmasetup_data_cb_args cba;
-if (ds-flags ATA_DS_ACTIVE)
- panic(ata_dmasetup: transfer active on this device!);
+if (ds-flags ATA_DS_ACTIVE) {
+ printf(ata_dmastart: transfer active on this device!\n);
+ Debugger(ata_dmastart);
+ return -1;
+}
cba.dmatab = ds-dmatab;
bus_dmamap_sync(ds-cdmatag, ds-cdmamap, BUS_DMASYNC_PREWRITE);
@@ -1312,6 +1316,16 @@
return 0;
}
+void
+ata_waitdmadone(struct ata_device *atadev)
+{
+if (atadev-dmastate.flags ATA_DS_ACTIVE) {
+ printf(%s: waiting for
Re: [PATCH] 'ata_dmasetup: transfer active on this device!'problem on resume
Sorry, typo...
@@ -674,6 +712,20 @@
ad_start(ch-device[MASTER]);
if (ch-devices (ATA_ATA_SLAVE) ch-device[SLAVE].driver)
ad_start(ch-device[SLAVE]);
+}
+if (ch-devices (ATA_ATA_MASTER) ch-device[MASTER].driver) {
+ if (ch-device[MASTER].suspended ch-device[MASTER].mode = ATA_DMA) {
+ printf(%s: going to suspend, ignoring.\n, __func__);
+ splx(s);
+ return;
+ }
+}
+if (ch-devices (ATA_ATA_SLAVE) ch-device[SLAVE].driver) {
+ if (ch-device[SLAVE].suspended ch-device[MASTER].mode = ATA_DMA) {
^^^ SLAVE
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
acpica-unix-20020829 patches (was Re: Lots of ACPI errors whenbooting yesterdays CURRENT
Hi, Below is a trimmed dmesg from booting yesterdays CURRENT on my SuperMicro P3TDE6 machine (RCC/ServerWorks HE-SLt chipset). I heven't found anything wrong with the OS, it is just that the boot seems to be a bit on the chatty side :-) Is this caused by a bad BIOS setting or is there something strange with this board/BIOS or the acpi support in CURRENT? I also noticed support for four acpi_cpu:s is, this as intended, the board only have room for two? Please try the latest version acpica-unix-20020829, patches for FreeBSD at: http://people.freebsd.org/~iwasaki/acpi/acpica-20020815-20020829-test20020905.diff Hopefully some of the problems will be solved. From CHANGES.txt If the target of a Scope() operator already exists, it must be an object type that actually opens a scope -- such as a Device, Method, Scope, etc. This is a fatal runtime error. Similar error check has been added to the iASL compiler also. Tightened up the namespace load to disallow multiple names in the same scope. This previously was allowed if both objects were of the same type. (i.e., a lookup was the same as entering a new name). Thanks Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Tue Sep 3 17:41:10 CEST 2002 [EMAIL PROTECTED]:/usr/obj/ext/FreeBSD/CURRENT/sys/EUKLIDES Preloaded elf kernel /boot/kernel/kernel at 0xc04c7000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04c70a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1266068553 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1266.07-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536805376 (524224K bytes) avail memory = 515674112 (503588K bytes) Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f52e0 ACPI-0536: *** Error: Field name [INDX] already exists in current scope ACPI-0536: *** Error: Field name [DATA] already exists in current scope ACPI-0536: *** Error: Field name [INDX] already exists in current scope ACPI-0536: *** Error: Field name [DATA] already exists in current scope ACPI-0536: *** Error: Field name [C000] already exists in current scope ACPI-0536: *** Error: Field name [C010] already exists in current scope ACPI-0536: *** Error: Field name [C020] already exists in current scope ACPI-0685: *** Warning: NsLookup: INDX, type 1, checking for type 11 ACPI-0685: *** Warning: NsLookup: DATA, type 2, checking for type 11 ACPI-0685: *** Warning: NsLookup: INDX, type 1, checking for type 11 ACPI-0685: *** Warning: NsLookup: DATA, type 2, checking for type 11 ACPI-0685: *** Warning: NsLookup: C000, type 8, checking for type 13 ACPI-0685: *** Warning: NsLookup: C010, type 8, checking for type 13 ACPI-0685: *** Warning: NsLookup: C020, type 8, checking for type 13 npx0: math processor on motherboard npx0: INT 16 interface acpi0: RCCRCCNILE on motherboard ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz ACPI-1354: *** Error: Method execution failed, AE_NOT_FOUND --- 15 identical lines removed acpi_timer0: 32-bit timer at 3.579545MHz port 0x508-0x50b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 acpi_cpu3: CPU on acpi0 acpi_button0: Sleep Button on acpi0 pcib1: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib1 pcib3: ACPI PCI-PCI bridge at device 0.1 on pci0 pci1: ACPI PCI bus on pcib3 pci1: display, VGA at device 0.0 (no driver attached) nge0: National Semiconductor Gigabit Ethernet port 0xde00-0xdeff mem 0xfeadb000-0xfeadbfff irq 11 at device 1.0 on pci0 nge0: Ethernet address: 00:40:33:af:35:33 miibus0: MII bus on nge0 nsgphy0: DP83861 10/100/1000 media interface on miibus0 nsgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto pci0: network, ethernet at device 2.0 (no driver attached) pcm0: AudioPCI ES1370 port 0xdf00-0xdf3f irq 11 at device 3.0 on pci0 ahc_pci0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeadc000-0xfeadcfff irq 5 at device 5.0 on pci0 aic7899: Ultra160
HEADS UP: Method of disabling acpi(4) has changed
If you want to stop auto-loading acpi.ko or to disable acpi(4), please change hint.acpi.0.disable=1 to hint.acpi.0.disabled=1 in your /boot/device.hints. Thanks From: Mitsuru IWASAKI [EMAIL PROTECTED] Subject: cvs commit: src/share/man/man5 device.hints.5 src/sys/boot/common loader.8 src/sys/boot/i386/libi386 i386_module.c src/sys/boot/i386/loader help.i386 src/sys/dev/acpica acpi.c Date: Fri, 30 Aug 2002 04:11:07 -0700 (PDT) Message-ID: [EMAIL PROTECTED] iwasaki 2002/08/30 04:11:07 PDT Modified files: share/man/man5 device.hints.5 sys/boot/common loader.8 sys/boot/i386/libi386 i386_module.c sys/boot/i386/loader help.i386 sys/dev/acpica acpi.c Log: s/hint.acpi.0.disable/hint.acpi.0.disabled/ Fix device hints entry for disabling acpi(4). This also should fix the arbitration with apm(4) when both drivers are enabled. Note that your /boot/device.hints needs to be updated if you want to stop auto-loading acpi.ko or disable acpi(4). Revision ChangesPath 1.6 +1 -1 src/share/man/man5/device.hints.5 1.47 +1 -1 src/sys/boot/common/loader.8 1.8 +1 -1 src/sys/boot/i386/libi386/i386_module.c 1.7 +1 -1 src/sys/boot/i386/loader/help.i386 1.72 +5 -0 src/sys/dev/acpica/acpi.c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1753] RE: Call for testers: acpica-unix-20020815
1) Fix the ASL so that it compiles without errors or warnings
2) Override the BIOS version of the table with your new one. (I don't know
how this is done on FreeBSD, someone else will have to help you.
Attached patches will fix the ASL.
For compiling and overriding, please refer to acpi(4).
# iasl Tecra8200.asl
# cp acpi_dsdt.aml /boot/
# echo 'acpi_dsdt_load=YES' /boot/loader.conf
Thanks
--- Tecra8200.asl- Wed Aug 28 19:30:30 2002
+++ Tecra8200.asl Wed Aug 28 19:26:57 2002
@@ -79,11 +79,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x1)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQA)
+Return(STAL(\_SB_.PCI0.FNC0.IRQA))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQA)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQA))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQA, Local0)
@@ -108,11 +108,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x2)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQB)
+Return(STAL(\_SB_.PCI0.FNC0.IRQB))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQB)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQB))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQB, Local0)
@@ -137,11 +137,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x3)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQC)
+Return(STAL(\_SB_.PCI0.FNC0.IRQC))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQC)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQC))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQC, Local0)
@@ -166,11 +166,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x4)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQD)
+Return(STAL(\_SB_.PCI0.FNC0.IRQD))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQD)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQD))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQD, Local0)
@@ -195,11 +195,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x5)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQE)
+Return(STAL(\_SB_.PCI0.FNC0.IRQE))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQE)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQE))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQE, Local0)
@@ -224,11 +224,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x8)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQH)
+Return(STAL(\_SB_.PCI0.FNC0.IRQH))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQH)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQH))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQH, Local0)
@@ -253,7 +253,7 @@
Name(_HID, 0x010cd041)
Name(_STA, 0xf)
Method(_CRS) {
-CRS_(0x1)
+Return(CRS_(0x1))
}
OperationRegion(SRAM, SystemMemory, 0x000ee800, 0x1800)
Field(SRAM, AnyAcc, NoLock, Preserve) {
@@ -944,13 +944,13 @@
Name(_HID, 0x000ed041)
Name(_UID, 0x2)
Method(_STA) {
-STA_(0x25)
+Return(STA_(0x25))
}
Method(_CRS) {
-CRS_(0x25)
+Return(CRS_(0x25))
}
Method(_PRS) {
-PRS_(0x25)
+Return(PRS_(0x25))
}
Method(_SRS, 1) {
SRS_(0x25, Arg0)
@@ -965,7 +965,7 @@
PS3_(0x25)
}
Method(_PSC) {
-PSC_(0x25)
+Return(PSC_(0x25))
}
Name(_PRW, Package(0x2) {
0xb,
@@ -982,7 +982,7 @@
Device(VDSC) {
Name(_HID, 0x1001a865)
Method(_STA) {
-STA_(0x26)
+Return(STA_(0x26))
}
}
PowerResource(PDOC, 1, 0) {
@@ -1006,7 +1006,7 @@
Event(DKSQ)
Device(DLAN) {
Name(_ADR, 0x000a)
-Name(_EJD, \_SB_.PCI0.PCIB.DOCK)
+Name(_EJD, _SB_.PCI0.PCIB.DOCK)
Re: [acpi-jp 1745] Re: Call for testers: acpica-unix-20020815
Thanks a lot. I must apologize though, I had the same error with previous versions of acpi (I should have checked, sorry, I confounded 2 laptops) This is very important fact for me! OK, I'll import 20020815 version today. BTW, Could you check your BIOS setting and see if printer port is disabled? And if so, how about enabling printer port? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1766] acpi issues on IBM A30p and -current
Hi,
acpi on my IBM A30p doesn't seem to work as expected.
Closing the display gives me a syslog entry:
...
system power profile changed to 'economy'
acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND
It's expected :-)
Because there is no _S1_ object in your ACPI BIOS,
and the system is going to enter S1 sleep by lid switch.
hw.acpi.lid_switch_state: S1
hw.acpi.battery.life: 100
hw.acpi.battery.time: -1
hw.acpi.battery.state: 0
hw.acpi.battery.units: 2
hw.acpi.battery.info_expire: 5
hw.acpi.acline: 0
machdep.acpi_timer_freq: 3579545
where the *battery* entries do not seem to be right.
seem to be right for me. If you concern about time = -1,
never mind, it's normal. Many machines doesn't report
correct info. when AC-line is plugged.
BTW:
When re-compiling the A30p.asl file I got with:
acpidump -o A30p.dsdt A30p.asl
I get:
(nihil)(root) # iasl A30p.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20020815 [Aug 28 2002]
Copyright (C) 2000 - 2002 Intel Corporation
Supports ACPI Specification Revision 2.0a
A30p.asl 102: If(\_OSI) {
Error1028 - Too few arguments ^ (\_OSI requires 1)
Hmmm, our acpidump don't understand _OSI method...
Any volunteers to implement parser for pre-defined methods?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
Hi, On Mon, Aug 26, 2002 at 10:32:58PM +0900, Mitsuru IWASAKI wrote: Any volunteers to solve this problem? Well yes, me. Like I said, I don't have experience with ACPI yet, but basicly I need to get this working so that makes me a good candidate ;) Thanks, very cool! Am I correct in stating that I should extend your vga_pci driver to do the correct actions on suspend/resume or are there also other places that need changes? For starting, I think just extending vga_pci would be OK. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Hi,
Could you put the following lines into /boot/loader.conf and send
dmesg output again?
debug.acpi.layer=ACPI_ALL_COMPONENTS
debug.acpi.level=ACPI_LV_ERROR
[sent privately to not spam the lists with my dump files]
On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote:
FYI, I have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ -
AE_BAD_DATA with acpica-unix-20020815 during boot.
I'd like to make sure if AE_BAD_DATA error occurred w/ previous
versions (acpica-unix-20020725, 20020611, 20020404...) ?
Or first time w/ acpica-unix-20020815 ?
This error did not happened with previous versions of acpi
Hmmm... OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1content-type=text/x-cvsweb-markupcvsroot=freebsd-jp
It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}
Intel folks, any ideas?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1744] RE: Call for testers: acpica-unix-20020815
Hi,
This looks like the (in)famous implicit return problem that is in some
Toshiba ASL files.
Method(_CRS) {
CRS_(0x10)
}
No, this is not implicit return problem. We have a workaround in
ACPI CA code in FreeBSD locally, and it is functioning properly even
now (checked on my Toshiba PORTEGE 3110CT).
Real problem is;
rsirq-0234 [15] RsIrqResource : Invalid interrupt polarity/trigger in
resource list
can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA
I guess that
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
this buffer value causes AE_BAD_DATA error in RsIrqResource() ?
Or
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
wrong value came from from _SB_.MEM_.PAR3 or _SB_.MEM_.PRES ?
I'll track this down...
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
FYI, I have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA with acpica-unix-20020815 during boot. I'd like to make sure if AE_BAD_DATA error occurred w/ previous versions (acpica-unix-20020725, 20020611, 20020404...) ? Or first time w/ acpica-unix-20020815 ? Anyway, I didn't receive serious problem reports of degrade so far, will do importing tomorrow. I have not yet correct battery info either. Laptop : Toshiba Tecra 8200, dmeg attached. I can provide more info if needed :) Please send me acpidump output (DSDT and ASL file): # acpidump -o Tecra8200.dsdt Tecra8200.asl I'll put them to our CVS repo. in Japan as test data. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
One other note: At boot time the VGA is reported as: Aug 25 21:15:20 laptop kernel: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 And when I load your module: Aug 25 21:12:44 laptop kernel: vga_pci0: Generic PCI VGA port 0xc000-0xc0ff mem 0xfcff-0xfcff,0xe000-0xe7ff irq 11 at device 0.0 on pci1 In other words, is it a problem that it is already configured as an ISA device or is that normal? It's normal. My vga_pci driver only provide suspend/resume methods so that kernel manipulate PCI power state for VGA device. Usually do nothing. If this don't solve your problem, I think graphic chip need to be re-initialized on wakeup. Maybe needs time... Ah, that makes sense. I was searching through the acpi documentation and couldn't find anything about displays actually. So this is fully controlled by the graphics controller? Some VAIO machines (w/ ATI graphic chip), also have the same problem. I also have an ATI chip. ATI Radeon to be precise, is that a possible explanation? Yes, I think so too. Any volunteers to solve this problem? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH]: resource manager (subr_rman.c) has a serious bug
[resent a few times, sorry if you receive the same messages]
Hi, I've found that there is a serious bug in sys/kern/subr_rman.c
about finding an acceptable region. I'm sure it's a obvious bug and
going to commit it soon, but this is my first commit to resource
manager code, so please review my patch. I'll commit this 2 or 3 days
later.
OK, when I trying to use wi PCCard with NEWCARD, sometimes wrong
I/O port range was allocated and attaching the card was failed
depending on the usage of I/O port resources.
Here is the kernel message w/ RMAN_DEBUG option in subr_rman.c.
rman_reserve_resource: I/O ports request: [0x100, 0x], length 0x40, flags
6144, device pccard1
considering [0x100, 0x107]
region is allocated
considering [0x108, 0x10d]
truncated region: [0x140, 0x10d]; size 0xffce (requested 0x40)
^ ^
start end, hmmm, very odd.
The resource manager is trying to find the I/O port resource range
(length = 0x40) checking the range [0x108 - 0x10d]. Adjusted start
address on boundary and alignment is [0x140], but this address already
exceeds end address of the range. That's the problem.
As the result, wrong address range [0x140 - 0x17f] was allocated.
Here is my patch. very simple but correct I think.
Index: subr_rman.c
===
RCS file: /home/ncvs/src/sys/kern/subr_rman.c,v
retrieving revision 1.24
diff -u -r1.24 subr_rman.c
--- subr_rman.c 4 Apr 2002 21:03:26 - 1.24
+++ subr_rman.c 25 Aug 2002 14:49:20 -
@@ -232,6 +234,10 @@
} while ((rstart amask) != 0 rstart end
rstart s-r_end);
rend = ulmin(s-r_end, ulmax(rstart + count, end));
+ if (rstart rend) {
+ DPRINTF((adjusted start exceeds end\n));
+ continue;
+ }
DPRINTF((truncated region: [%#lx, %#lx]; size %#lx (requested
%#lx)\n,
rstart, rend, (rend - rstart + 1), count));
The kernel message w/ my patch is:
rman_reserve_resource: I/O ports request: [0x100, 0x], length 0x40, flags
6144, device pccard1
considering [0x100, 0x107]
region is allocated
considering [0x108, 0x10d]
adjusted start exceeds end
considering [0x10e, 0x10e]
region is allocated
considering [0x10f, 0x16f]
truncated region: [0x140, 0x16f]; size 0x30 (requested 0x40)
considering [0x170, 0x177]
region is allocated
considering [0x178, 0x1ef]
truncated region: [0x180, 0x1ef]; size 0x70 (requested 0x40)
It seems that correct range is allocated, and wi PCCard is always
working correctly now :-)
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
I applied the patches, and I still have the same results on my laptop.
I have a Dell Latitude C640 and my screen won't come back after a suspend.
The machine works fine besides that.
OK, I think this is not related with ACPI CA code update.
Our device driver (maybe syscons?) or X server issue.
Do you have any idea/advice how this can be debugged?
If you have this problem w/ X running, and don't have w/o X,
please try attached patches.
Thanks
Index: isa/syscons_isa.c
===
RCS file: /home/ncvs/src/sys/isa/syscons_isa.c,v
retrieving revision 1.17
diff -u -r1.17 syscons_isa.c
--- isa/syscons_isa.c 30 Jun 2001 10:15:06 - 1.17
+++ isa/syscons_isa.c 16 Feb 2002 13:11:50 -
@@ -88,6 +88,39 @@
return sc_attach_unit(device_get_unit(dev), device_get_flags(dev));
}
+static int sc_cur_scr;
+
+static int
+scsuspend(device_t dev)
+{
+ int retry = 10;
+ static int dummy;
+ sc_softc_t *sc;
+
+ sc = main_softc;
+ sc_cur_scr = sc-cur_scp-index;
+ do {
+ sc_switch_scr(sc, 0);
+ if (!sc-switch_in_progress) {
+ break;
+ }
+ tsleep(dummy, 0, scsuspend, 100);
+ } while (retry--);
+
+ return (0);
+}
+
+static int
+scresume(device_t dev)
+{
+ sc_softc_t *sc;
+
+ sc = main_softc;
+ sc_switch_scr(sc, sc_cur_scr);
+
+ return (0);
+}
+
int
sc_max_unit(void)
{
@@ -230,6 +263,8 @@
DEVMETHOD(device_identify, scidentify),
DEVMETHOD(device_probe, scprobe),
DEVMETHOD(device_attach,scattach),
+ DEVMETHOD(device_suspend, scsuspend),
+ DEVMETHOD(device_resume,scresume),
{ 0, 0 }
};
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
I have a Dell Latitude C640 and my screen won't come back after a suspend. The machine works fine besides that. OK, I think this is not related with ACPI CA code update. If that was not clear, it also didn't work before. understood. I meant that ACPI CA code changes won't solve the individual device problems in many cases. If you have this problem w/ X running, and don't have w/o X, please try attached patches. It's unrelated to X. Other ideas? How about this one? http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. If this don't solve your problem, I think graphic chip need to be re-initialized on wakeup. Maybe needs time... Some VAIO machines (w/ ATI graphic chip), also have the same problem. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
iwasaki Index: isa/syscons_isa.c iwasaki === iwasaki RCS file: /home/ncvs/src/sys/isa/syscons_isa.c,v iwasaki retrieving revision 1.17 iwasaki diff -u -r1.17 syscons_isa.c iwasaki --- isa/syscons_isa.c30 Jun 2001 10:15:06 - 1.17 iwasaki +++ isa/syscons_isa.c16 Feb 2002 13:11:50 - I need this patch to do suspend/resume my laptop (Victor InterLink XP). This patch is also required for FIVA. OK, commited. It may better to have kernel option or sysctl to enable/disable this function. I think this has no side effect but if I get any reports, I'll consider the option. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for testers: acpica-unix-20020815
I'm going to import Intel acpica-unix-20020815 sometime early next week. Please test new version of acpica and give feedback before my importing. Major fix in this version is Ref/Deref operators bug fix. Personally I'm very happy with the new version because now my laptop (FIVA 206VL) reports correct battery info. :-) The full change log: http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt The patches against CURRENT sys tree are available at: http://people.freebsd.org/~iwasaki/acpi/acpica-20020725-20020815-test20020822.diff Please note that any feedback should be sent to [EMAIL PROTECTED] Enjoy! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpi prevents fdc to detect correctly
my kernel can't detect fdc anymore when loading acpi. does anybody else have such issues? i know that it worked with a Aug 6 or a Aug 3 kernel, this was the last time i accessed my fd0. though reverting to a -D 08/06/2002 src/sys doesn't bring the desired effect (working fdc). Hmmm, there are very few changes on ACPI between 08/06/2002 and 08/19/2002... Sorry, I have no idea. Guys, any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI errors
[move to -current because STABLE don't have acpica support yet] Hi, System: TOS 5005-S504 Error with any kernel build: Using $PIR table, 0 entries at 0xc00f0190 ACPI-0171: *** Error: AcpiLoadTables: RSDP Failed validation: AE_BAD_SIGNATURE ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE ACPI: Table load failed: AE_BAD_SIGNATURE It seems that this problem happens after sys/i386/i386/pmap.c rev 1.352 changes. Could you replace pmap.c with 1.351 ? Peter, do you have any ideas with this ? Same thing happens if I do an unset acpi_load or if I try boot -s, or both. I think your kernel config file includes 'device acpica'. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment = base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: APIC on UP motherboard, Kernel trap
The patch corrected the Panic and ACPI loads. Will it be submitted? I'll import the latest version of Intel ACPICA shortly. The bug was fixed already. One outstanding problem. When enabling APIC _AND_ having run X11, i get a hang after the line: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped when halting the system. If i select PIC in the bios i can do a clean shutdown. I'm using a Promise MBFastTrak133 embedded raid controller with 2 disks in raid1 configuration. Hmm, I have no idea on this part. Anyone? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT bootup panics (ACPI related?)
Hi, I just got myself an IBM Thinkpad T30, most things work fine on -STABLE (trying to get specs from IBM for the rest), but -CURRENT won't boot with ACPI enabled. I'd be glad to track that down, but I have no clue where to start, nor do I have any more than a passing knowledge of ACPI. I could disable it and boot -CURRENT (and install works fine since there's no ACPI there), but things go wrong as soon as the kernel touches UFS. This [snip] db trace crfree(73cc3000,c04aa2e0,5,0,d68cb6e4) at crfree+0x8 getnewbuf(0,0,800,4000,4000) at getnewbuf+0x187 getblk(c4236a00,0,0,800,0) at getblk+0x269 breadn(c4236a00,0,0,800,0) at breadn+0x2f bread(c4236a00,0,0,800,0) at bread+0x20 ffs_blkatoff(c4236a00,0,0,0,d68cb848) at ffs_blkatoff+0xb2 ufs_lookup(d68cb970,d68cb9ac,c029c751,d68cb970,c4236e74) at ufs_lookup+0x32a I'm not sure if this is directly related with ACPI. We had unstability on FS code, so could you try again with newer kernel? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: APIC on UP motherboard, Kernel trap
Hi, I upgraded today (as of 30 min ago) to a current kernel from pre-KSE. When trying to boot with APIC set in BIOS i get: acpi0:ASUS A7V333 on motherboard Fatal trap 12: page fault while in kernel mode fault virtual address = 0x16 fault code= supervisor read, page not present Please try the patch at: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1102262+0+archive/2002/freebsd-current/20020707.freebsd-current Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1661] Re: ASUS CUSL2 panic on acpi
My analysis was finished. Please try this patch.
--- exfield.c- Thu Jul 4 21:54:24 2002
+++ exfield.c Thu Jul 4 21:55:02 2002
@@ -200,7 +200,7 @@
/* Handle both ACPI 1.0 and ACPI 2.0 Integer widths */
IntegerSize = sizeof (ACPI_INTEGER);
-if (WalkState-MethodNode-Flags ANOBJ_DATA_WIDTH_32)
+if (WalkState-MethodNode != NULL WalkState-MethodNode-Flags
+ANOBJ_DATA_WIDTH_32)
{
/*
* We are running a method that exists in a 32-bit ACPI table.
BTW, this bug already fixed in 20020517 version.
acpi0: ASUS CUSL2on motherboard
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x16
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04f9aca
stack pointer = 0x10:0xc054ea14
frame pointer = 0x10:0xc054ea34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax
db trace
AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at
AcpiExReadDataFromField+0x5a
# if my understanding on i386 asm is correct,
I think this is at (exfield.c):
203:if (WalkState-MethodNode-Flags ANOBJ_DATA_WIDTH_32)
where WalkState-MethodNode is NULL, this caused page fault.
I'm waiting for further debug info. but I'll try to find where
WalkState-MethodNode suppose to be set...
WalkState-MethodNode was initialized to NULL in AcpiDsInitAmlWalk()
which called by AcpiDsExecuteArguments(). AcpiExReadDataFromField()
assumes that WalkState-MethodNode always has a correct pointer.
That's the problem, I think.
ACPI_STATUS
AcpiDsExecuteArguments (
ACPI_NAMESPACE_NODE *Node,
ACPI_NAMESPACE_NODE *ScopeNode,
UINT32 AmlLength,
UINT8 *AmlStart)
...
Status = AcpiDsInitAmlWalk (WalkState, Op, NULL, AmlStart,
AmlLength, NULL, NULL, 3);
...
AcpiDsInitAmlWalk (
ACPI_WALK_STATE *WalkState,
ACPI_PARSE_OBJECT *Op,
ACPI_NAMESPACE_NODE *MethodNode,
UINT8 *AmlStart,
UINT32 AmlLength,
ACPI_OPERAND_OBJECT **Params,
ACPI_OPERAND_OBJECT **ReturnObjDesc,
UINT32 PassNumber)
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ASUS CUSL2 panic on acpi
# Cc acpi-jp From: Shizuka Kudo [EMAIL PROTECTED] Subject: ASUS CUSL2 panic on acpi Date: Tue, 2 Jul 2002 11:55:18 -0700 (PDT) Message-ID: [EMAIL PROTECTED] Dear all, I wonder if anyone experienced the same issue as mime. I have an ASUS CUSL2 running -current and starting about three days ago, it panic when acpi is autoloaded. If I unset acpi_load at the boot prompt, the machine works fine. Could you send ACPI related data to [EMAIL PROTECTED] as follows? # acpidump -o ASUS-CUSL2.dsdt ASUS-CUSL2.asl # tar czvf ASUS-CUSL2.tar.gz ASUS-CUSL2.dsdt ASUS-CUSL2.asl And one more thing, recompile acpi module w/ ACPI_DEBUG, add 2 lines to your /boot/loader.conf and send new panic message? debug.acpi.layer=ACPI_ALL_COMPONENTS debug.acpi.level=ACPI_LV_EXEC Thanks Here's the panic message and a trace for those interested acpi0: ASUS CUSL2on motherboard Fatal trap 12: page fault while in kernel mode fault virtual address = 0x16 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04f9aca stack pointer = 0x10:0xc054ea14 frame pointer = 0x10:0xc054ea34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax db trace AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at AcpiExReadDataFromField+0x5a AcpiExResolveNodeToValue(c0f005b0,c0f00400,1,c0ed6d40,c054eab0) at AcpiExResolveNodeToValue+0xd9 AcpiExResolveToValue(c0f005b0,c0f00400,c0f00400,0,c054eab0) at AcpiExResolveToValue+0x53 AcpiExResolveOperands(5b80,c0f005b4,c0f00400,c0efbe00,c0f00400) at AcpiExResolveOperands+0x1cf AcpiDsEvalRegionOperands(c0f00400,c25d6480,c050411e,c25d6480,0) at AcpiDsEvalRegionOperands+0x50 AcpiDsExecEndOp(c0f00400,c054eb14,c0f00414,c0f0040c,cdd4f1b1) at AcpiDsExecEndOp+0x258 AcpiPsParseLoop(c0f00400,c257f900,c054eb74,0,0) at AcpiPsParseLoop+0x579 AcpiPsParseAml(c0f00400,c25dcc40,0,cdd4f1a6,e) at AcpiPsParseAml+0x7c AcpiDsExecuteArguments(c0efbe00,c051de10,e,cdd4f1a6,c257fdc0) at AcpiDsExecuteArguments+0x182 AcpiDsGetRegionArguments(c257fdc0,0,c0efbe00,1,c054ec10) at AcpiDsGetRegionArguments+0x56 AcpiNsInitOneObject(c0efbe00,1,c054ec60,0,0) at AcpiNsInitOneObject+0xd8 AcpiNsWalkNamespace(0,,,1,c0500620) at AcpiNsWalkNamespace+0xad AcpiWalkNamespace(0,,,c0500620,c054ec60) at AcpiWalkNamespace+0x77 AcpiNsInitializeObjects(0,c054ecc8,c050b8ab,0,2) at AcpiNsInitializeObjects+0x4d AcpiEnableSubsystem(0,2,c04fd110,0,0) at AcpiEnableSubsystem+0x8a acpi_attach(c25d7580,c25b5090,c03d3590,c0ed4d00,c0f04c80) at acpi_attach+0x13b device_probe_and_attach(c25d7580,c0f04c80,c054ed2c,c0368864,c0f04c80) at device_probe_and_attach+0xaf bus_generic_attach(c0f04c80,0,c0ed4d00,c0efda80,c0f04c80) at bus_generic_attach+0x28 nexus_attach(c0f04c80,c2596090,c03d3590,c03c4480,0) at nexus_attach+0x14 device_probe_and_attach(c0f04c80,c0ef9780,c054ed80,c035b5e5,c0f04f00) at device_probe_and_attach+0xaf root_bus_configure(c0f04f00,c03c4480,0,c054ed98,c020b175) at root_bus_configure+0x28 configure(0,54b000,54bc00,54b000,0) at configure+0x35 mi_startup() at mi_startup+0xb5 begin() at begin+0x43 db __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1371] Re: ACPI: problem with fdc resource allocation
# Congratulations, Maxim! On Thu, Oct 25, 2001 at 05:13:56PM +0300, Maxim Sobolev wrote: 6. And finally I've put back corrected ACPI table back into BIOS image using CBROM.EXE, flashed resulting BIOS image and voila - the ACPI problem gone. :) Way cool. :) Yeah, Maxim is maniac :) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Hi, Maxim. Thanks for reporting and reminding us.
I think this is very difficult to fix, because;
1. Basically, this is a bug in BIOS, should be reported to vendor.
2. ACPI CA is developed by Intel. We'd like to have less local
workaround changes as possible.
3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).
I'll describe again the problem. This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.
Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.
Maxim, could you apply the following patches and try DSDT overriding?
Thanks
--- Tyan-S1590.asl.org Wed Oct 24 22:00:44 2001
+++ Tyan-S1590.asl Wed Oct 24 22:02:09 2001
@@ -884,12 +884,14 @@
}
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79,
0x0 })
+/*
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
+*/
Return(BUF0)
}
Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x38,
0x79, 0x0 })
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1343] Re: ACPI panic at boot time in -current
Hi, Intel folks. I've just found the bug in rsutils.c which double free(); AcpiUtRemoveReference() and ACPI_MEM_FREE(). Here is a fix. Index: rsutils.c === RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsutils.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 rsutils.c --- rsutils.c 4 Oct 2001 23:12:13 - 1.1.1.7 +++ rsutils.c 14 Oct 2001 15:23:13 - @@ -490,7 +490,6 @@ */ Cleanup: -ACPI_MEM_FREE (ByteStream); return_ACPI_STATUS (Status); } I suspect that this should be removed in ACPICA 20010831-to-20010920 changes. Matsuda-san, thanks. I missed the original mail in current ML written by brian. Thanks Hi all, From: Brian Somers [EMAIL PROTECTED] Date: Fri, 12 Oct 2001 01:15:38 +0100 ::Hi, :: ::I was wondering if anybody has any suggestions about why this might ::be happening in -current: cut ::pccbb1: RF5C478 PCI-CardBus Bridge irq 0 at device 10.1 on pci0 ::pccbb1: PCI Memory allocated: 10001000 ::acpi_pcib0: possible interrupts: 9 ::panic: free: multiple freed item 0xc14f75f0 ::Debugger(panic) ::Stopped at Debugger+0x44: pushl %ebx ::db t I also get the same kind of panic, after import of ACPICA 20010920 snapshot. If I boot very current kernel with old acpi.ko based on 20010831 snapshot, system boots up just fine. Panic message from current kernel with acpi.ko based on 20010920 snapshot: -8-8-8-8-8-8-8 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfc60-0xfc7f at device 7. 2 on pci0 acpi_pcib0: possible interrupts: 9 panic: free: multiple freed item 0xc13843d0 Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db -8-8-8-8-8-8-8 Related dmesg from the same kernel with old acpi.ko based on 20010831 snapshot: -8-8-8-8-8-8-8 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfc60-0xfc7f at device 7.2 on pci0 acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 3 ports with 3 removable, self powered -8-8-8-8-8-8-8 Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI and APM interoperability?
Hi, On Mon, Oct 01, 2001 at 10:50:17AM +0200, Georg-W. Koltermann wrote: Hi, I'm wondering how I should handle APM now that ACPI has basically taken over power management responsibility. APM and ACPI are mutually exclusive from what I understand. You should remove the apm device from your kernel config. Yes, some older machines w/ ACPI can support both of them at the same time, but most modern machines don't. It seems I still need to configure APM so that /dev/apm is there and battery monitoring utilities like the GNOME battery_applet can work. Battery, temp, etc, can be monitored via the hw.acpi sysctl tree. Someone will have to do the required conversion to the various APM utilities is GNOME and whatever else. Yes, you can get battery info. in C code like; sysctlbyname(hw.acpi.battery.time, percent, len, NULL, 0); Note that these MIBs maybe change in future... Generalized power-management interface API to have compatibility with APM and ACPI also is suggested long time ago; http://www.freebsd.org/cgi/getmsg.cgi?fetch=403390+406841+/usr/local/www/db/text/2001/freebsd-current/20010114.freebsd-current Device node for ACPI is discussed bofore too; having only one /dev/acpi or having generalized nodes for each device types such as /dev/battery0 but we couldn't reach the conclusion, now discussion stops... Any suggestions on it? Once we get the conclusion, we can start developing API and convert userland tools. I also was able to suspend and resume my machine (DELL Inspiron 7500) with APM being configured (and ACPI being active by default). Sound is dead after a resume, What sound card? PCMCIA is dead after a couple of resumes, Resource leak? Warner? Is yours similar to any data at there (Dell_I7500*) ? http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp I guess CardBus controllers are _SB_.PCI0.CB1_ and _SB_.PCI0.CB2_ but I didn't see any sleep/wakeup hack for them... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, I'm not sure exactly what's the problem you are having, but it's too little information to track it down... Could you send [EMAIL PROTECTED] ; - acpidump output; like # acpidump -o your_machine_name.dsdt your_machine_name.dsdt.asl I'll add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp - dmesg output of kernel boot -v Just sent it to you privately. After hiting sed button I've realised that machine_name that you have requested != host_name. Since it isn't a brandname model you can identify it after the mainboard name - Tyan-S1590. Thanks, I've just add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tyan-S1590.asl?cvsroot=freebsd-jp The problem is here, right? can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some problems (not sure in BIOS or ACPICA yet). I could reproduce the problem which you reported. Trace attached in this mail. I'll try to make a workaround tomorrow or next, sorry. # Here in Japan, it's midnight... Thanks % acpicadb Tyan-S1590.dsdt Parsing Methods:... 55 Control Methods found and parsed (259 nodes total) ACPI Namespace successfully loaded at root 0x8087414 - f FDC0 \_SB_.PCI0.ISA_.FDC0 (0x8098da8) - Device - debug _SB_.PCI0.ISA_.FDC0._CRS Executing \_SB_.PCI0.ISA_.FDC0._CRS 0 #0008 [00] Name BUF0 (Path \) [00] ( 5 #0011 [01] Buffer [01] ( 7 #000A [02] (UINT8) 0x18, 9 #0033 [02] ByteList (Length 0x0018) [02] } [01] } % ArgObj:0x80acfa8 Obj Integer 0018 00021 #008C [00] CreateByteField [00] ( 00022 #002D [01] BUF0, (Path 00026 #000A [01] (UINT8) 0x02, 00028 #002D [01] IOLO (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af1a8 Obj Integer 0002 ArgObj:0x80af0a8 NodeName IOLO Type-BuffField 0002C #008C [00] CreateByteField [00] ( 0002D #002D [01] BUF0, (Path 00031 #000A [01] (UINT8) 0x03, 00033 #002D [01] IOHI (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af328 Obj Integer 0003 ArgObj:0x80af228 NodeName IOHI Type-BuffField 00037 #008C [00] CreateByteField [00] ( 00038 #002D [01] BUF0, (Path 0003C #000A [01] (UINT8) 0x04, 0003E #002D [01] IORL (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af4a8 Obj Integer 0004 ArgObj:0x80af3a8 NodeName IORL Type-BuffField 00042 #008C [00] CreateByteField [00] ( 00043 #002D [01] BUF0, (Path 00047 #000A [01] (UINT8) 0x05, 00049 #002D [01] IORH (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af628 Obj Integer 0005 ArgObj:0x80af528 NodeName IORH Type-BuffField 0004D #008C [00] CreateByteField [00] ( 0004E #002D [01] BUF0, (Path 00052 #000A [01] (UINT8) 0x19, 00054 #002D [01] IRQL (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af7a8 Obj Integer 0019 ArgObj:0x80af6a8 NodeName IRQL Type-BuffField dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192 (bits) PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8) Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, Maxim Sobolev wrote: Maxim Sobolev wrote: Andrey A. Chernov wrote: On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. Knock, knock... Is anybody home? Hmm, it is very sad to see that acpi code is totally unsupported, especially in the spite of recent how to attract people to test -current thread. The problem is still here, as of today's kernel. I'm not sure exactly what's the problem you are having, but it's too little information to track it down... Could you send [EMAIL PROTECTED] ; - acpidump output; like # acpidump -o your_machine_name.dsdt your_machine_name.dsdt.asl I'll add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp - dmesg output of kernel boot -v Mike, anything add to this? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how to make acpi go away.
Hi, try adding a line hint.acpi.0.disable=1 to /boot/device.hints, or disable it at boot time unset acpi_load then boot as usual. Thank you, that fixed everything. Also, this works too: echo NO_MODULES=yes /etc/make.conf; rm /boot/kernel/acpi.ko :-) Also, it's good idea. echo device acpi /sys/i386/conf/GENERIC; cd /usr/src; make kernel # then try debugging hard together :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI, PS/2 and USB (was: Re: ThinkPad, ACPI, and PS/2 mouse)
This is not a ThinkPad, but FIVA 206VL (PS/2 mouse PnP ID = 0x130fd041; normal one), the psm is no longer recognized if USB is not compiled (or USB module is not loaded at loader). I have never heard of this type of error before! Me too! I was surprised when I noticed this. I cannot think of a reason why the presence or absence of the usb module affects the behavior of the motherboard keyboard controller... I must say this is the most arcane error. Yes, very odd. But I think I was lucky to find a workaround... Ok, this is strictly the psm and usb modules' problem, then. Do you remember when your PS/2 mouse was detected correctly without the usb module? I'm not sure, but I think I used compile USB stuff in my kernel all the time. Then I noticed this strange behavior when I tried to remove USB stuff from kernel config. BTW, I've found that this appear on 4-STABLE too. I attached dmesg diffs. And I heard that some Acer Labs Inc. PCI South Bridge chips has support for integrated controllers including USB and PS/2. Perhaps Ali specific problem? # If so, is anyone already working on this? The following is pciconf -lv output on this laptop (FIVA 206VL). Thanks hostb0@pci0:0:0:class=0x06 card=0x02951279 chip=0x03951279 rev=0x00 hdr=0x00 vendor = 'Transmeta Corp.' device = 'LongRun Northbridge' class= bridge subclass = HOST-PCI none0@pci0:0:1: class=0x05 card=0x02951279 chip=0x03961279 rev=0x00 hdr=0x00 vendor = 'Transmeta Corp.' device = 'SDRAM Controller' class= memory subclass = RAM none1@pci0:0:2: class=0x05 card=0x02951279 chip=0x03971279 rev=0x00 hdr=0x00 vendor = 'Transmeta Corp.' device = 'BIOS scratchpad' class= memory subclass = RAM pcm0@pci0:4:0: class=0x040100 card=0x01001265 chip=0x545110b9 rev=0x01 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5451 PCI AC-Link Controller Audio Device' class= multimedia subclass = audio isab0@pci0:7:0: class=0x060100 card=0x153310b9 chip=0x153310b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA none2@pci0:9:0: class=0x03 card=0x0712126f chip=0x0712126f rev=0xa0 hdr=0x00 vendor = 'Silicon Motion' device = 'SM712 LynxEM+' class= display subclass = VGA pcic0@pci0:10:0:class=0x060700 card=0x chip=0xac51104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments' device = 'PCI1420 PC card Cardbus Controller' class= bridge subclass = PCI-CardBus pcic1@pci0:10:1:class=0x060700 card=0x chip=0xac51104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments' device = 'PCI1420 PC card Cardbus Controller' class= bridge subclass = PCI-CardBus none3@pci0:11:0:class=0x0c0010 card=0x8011104c chip=0x8020104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments' device = 'OHCI Compliant FireWire Controller' class= serial bus subclass = FireWire rl0@pci0:12:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet atapci0@pci0:15:0: class=0x0101a4 card=0x chip=0x522910b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA none4@pci0:17:0:class=0x068000 card=0x chip=0x710110b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M7101 Power Management Controller' class= bridge subclass = PCI-unknown ohci0@pci0:20:0:class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB --- dmesg-4-nousb Mon Sep 17 22:41:14 2001 +++ dmesg-4-usb Mon Sep 17 22:41:14 2001 @@ -1,12 +1,12 @@ Copyright (c) 1992-2001 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 4.4-STABLE #3: Mon Sep 17 18:16:17 JST 2001 -root@fivavl:/usr/STABLE/src/sys/compile/FIVA -Calibrating clock(s) ... TSC clock: 597298266 Hz, i8254 clock: 1360243 Hz -1360243 Hz differs from default of 1193182 Hz by more than 1% +FreeBSD 4.4-STABLE #4: Mon Sep 17 18:43:25 JST 2001 +iwasaki@fivavl:/usr/STABLE/src/sys/compile/FIVA +Calibrating clock(s) ... TSC clock: 597300672 Hz, i8254 clock: 1276722 Hz +1276722 Hz differs from default of 1193182 Hz by more than 1% Timecounter i8254 frequency 1193182 Hz -CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 (573.41-MHz 586-class CPU) +CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 (597.30-MHz 586-class CPU) Origin = GenuineTMx86 Id = 0x543 Processor revision
Re: ThinkPad, ACPI, and PS/2 mouse
Hi, I've just noticed strange behavior of psm probing (w/ and w/o acpi). It now appears that some IBM ThinkPad models assign a distinct PnP ID to the PS/2 mouse port. If you have ThinkPad and its pointing device is not recognized when ACPI is loaded in the latest -current system, please do the following 1. Disable ACPI and boot unset acpi_load boot -v 2. Send the entire dmesg output to me. Don't forget to tell me the model name of your ThinkPad too. ThinkPad models currently known to have this behavior: model PnP ID for the PS/2 mouse port ThinkPad 570E IBM3780 I also have a ThinkPad i1620 (PS/2 mouse PnP ID = 0x80374d24) here and now that the mouse is recognized correctly with ACPI module by your last commit. This is not a ThinkPad, but FIVA 206VL (PS/2 mouse PnP ID = 0x130fd041; normal one), the psm is no longer recognized if USB is not compiled (or USB module is not loaded at loader). Here is difference between dmesgs of kernel w/o and w/ usb module. --- dmesg-nousb Mon Sep 17 01:24:17 2001 +++ dmesg-usb Mon Sep 17 01:26:47 2001 @@ -3,7 +3,7 @@ The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #52: Mon Sep 17 01:16:21 JST 2001 root@fivavl:/usr/obj/usr/CURRENT/src/sys/FIVA -Calibrating clock(s) ... TSC clock: 597277464 Hz, i8254 clock: 1193158 Hz +Calibrating clock(s) ... TSC clock: 597277748 Hz, i8254 clock: 1193162 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method @@ -16,16 +16,17 @@ real memory = 251592704 (245696K bytes) Physical memory chunk(s): 0x1000 - 0x0009afff, 630784 bytes (154 pages) -0x0049f000 - 0x0efe7fff, 246714368 bytes (60233 pages) -avail memory = 240271360 (234640K bytes) +0x004be000 - 0x0efe7fff, 246587392 bytes (60202 pages) +avail memory = 240144384 (234516K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f82a0 bios32: Entry = 0xfd770 (c00fd770) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd770+0x11e pnpbios: Found PnP BIOS data at 0xc00f82f0 pnpbios: Entry = f:a965 Rev = 1.0 Other BIOS signatures found: -Preloaded elf kernel /boot/kernel/kernel at 0xc0478000. -Preloaded elf module /boot/kernel/logo_saver.ko at 0xc04780b4. +Preloaded elf kernel /boot/kernel/kernel at 0xc0497000. +Preloaded elf module /boot/kernel/logo_saver.ko at 0xc04970b4. +Preloaded elf module /boot/kernel/usb.ko at 0xc0497164. null: null device, zero device mem: memory I/O random: entropy source @@ -117,11 +118,11 @@ pcm0: ac97 codec id 0x41445348 (Analog Devices AD1881A) pcm0: ac97 codec features headphone, 6 bit master volume, Analog Devices Phat Stereo pcm0: ac97 primary codec extended features variable rate PCM -pcm: setmap 50e000, 1000; 0xc15fa000 - 50e000 -pcm: setmap 4f1000, 1000; 0xc15fd000 - 4f1000 -pcm: setmap 4f3000, 1000; 0xc15ff000 - 4f3000 -pcm: setmap 4d5000, 1000; 0xc1601000 - 4d5000 -pcm: setmap 4d7000, 1000; 0xc1603000 - 4d7000 +pcm: setmap 514000, 1000; 0xc160 - 514000 +pcm: setmap 4f7000, 1000; 0xc1603000 - 4f7000 +pcm: setmap 4f9000, 1000; 0xc1605000 - 4f9000 +pcm: setmap 51b000, 1000; 0xc1607000 - 51b000 +pcm: setmap 51d000, 1000; 0xc1609000 - 51d000 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: display, VGA at device 9.0 (no driver attached) @@ -285,7 +286,13 @@ ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0x1808 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at device 17.0 (no driver attached) -pci0: serial bus, USB at device 20.0 (no driver attached) +ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xd-0xd0fff irq 11 at +device 20.0 on pci0 +usb0: OHCI version 1.0, legacy support +usb0: SMM does not respond, resetting +usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 +usb0: USB revision 1.0 +uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 +uhub0: 2 ports with 2 removable, self powered ex_isa_identify() ata-: ata0 already exists, using ata2 instead ata-: ata1 already exists, using ata3 instead @@ -370,7 +377,10 @@ kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: current command byte:0047 -psm0: the aux port is not functioning (-1). +psm0: PS/2 Mouse irq 12 on atkbdc0 +psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons +psm0: config:, flags:, packet size:3 +psm0: syncmask:c0, syncbits:00 bt0 failed to probe on isa0 cs0 failed to probe at port 0x300 on isa0 ed0 failed to probe at port 0x280-0x29f iomem 0xd8000 irq 10 on isa0 @@ -430,10 +440,8 @@ unknown: PNP0800 failed to probe at port 0x61 on isa0 unknown: PNP0c02 can't assign resources unknown: PNP0c02 at iomem 0xd8000-0xdbfff on isa0 -psmcpnp0: PS/2 mouse port at irq 12 on isa0 -atkbd1: unable to allocate IRQ -psm0:
Re: ThinkPad, ACPI, and PS/2 mouse
Hi, yokota-san thank you very much. It now appears that some IBM ThinkPad models assign a distinct PnP ID to the PS/2 mouse port. If you have ThinkPad and its pointing device is not recognized when ACPI is loaded in the latest -current system, please do the following 1. Disable ACPI and boot unset acpi_load boot -v 2. Send the entire dmesg output to me. Don't forget to tell me the model name of your ThinkPad too. ThinkPad models currently known to have this behavior: model PnP ID for the PS/2 mouse port ThinkPad 570E IBM3780 I also have a ThinkPad i1620 (PS/2 mouse PnP ID = 0x80374d24) here and now that the mouse is recognized correctly with ACPI module by your last commit. Thanks again To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI kills my current-box frequently.
Hi, NAKAJI-san. Thank you for reporting. Just after rebooting with this kernel and installworld, this host reboots frequently, about every 10 minutes. /var/log/messages shows that Could you describe your hardware? I'd like see boot -v dmesg and ACPI data. Please send them to acpi-jp ML. Also could you try adjust loader variable `debug.acpi.disable' and see if which component is causing the problem? Possible values to debug.acpi.disable are; bus, children, button, cpu, ec, lid, pci, sysresource, thermal and timer. You can specify them in loader, like; ok set debug.acpi.disable=cpu ec lid pci sysresource thermal timer See also acpi(4). Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1255] Re: ACPI and PS/2 mouse problem
Hi, I have the same laptop but a different problem, with today kernel. The following is copied by hand, no serial console at home: wait: panic: free: address 0xcbf5e5fe db trace panic(...) at panic+0xb6 free(...) at free+0x32 AcpiOsFree(...) at AcpiOsFree+0x11 AcpiExCopyStringToString(...) at AcpiExCopyStringToString+0x4d Yes, this is already analyzed in http://home.jp.FreeBSD.org/cgi-bin/showmail/acpi-jp/1239 Try following patch. This fix will be appear in next Intel ACPICA snapshot release. Index: dsobject.c === RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsobject.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 dsobject.c --- dsobject.c 26 Aug 2001 22:28:16 - 1.1.1.9 +++ dsobject.c 3 Sep 2001 11:45:49 - @@ -558,6 +558,7 @@ break; } +ObjDesc-Common.Flags |= AOPOBJ_STATIC_POINTER; return (AE_OK); } Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1258] ACPI Data for a Dell Inspiron 8000 Laptop
Hi, thanks for your report. I'll add submitted ACPI data to our collection. Find attached some data to help out with getting ACPI running smoothly. Many features work with this laptop but the most annoying complaint is the lack of console display being restored after a suspend/resume. Are you using APM suspend/resume on ACPI enabled system? I know that some machines can support both at the same time, but many machines cannnot. Please try to use acpiconf(8) under ACPI instead of apm(8)/zzz(8), then report the problems to acpi-jp ML if exists. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How can I turn off acpi 100%?
Hi, was comming. Mistake. It comes up fine, I think because all I can see are: acpi_cmbat0: bif size changed 0 at what looks like several per second. In single user I am getting: acpi-ec0: evaluation of CPE query method _Q3F failed - AE_NOT_FOUND Hmm, I think these two problems are the same; i.e. Embedded Controller problem. Could you get ACPI data from your machine, like # acpidump -o Compaq_1700.dsdt Compaq_1700.asl and send them (plus boot -v dmesg) to [EMAIL PROTECTED] ? How can I turn all this off? Can I send any info that might help someone else? It's very easy to disable ACPI, but I think we had better to improve our ACPI implementation :-) Because newer Intel-based machines (not only Laptops) have become strongly depending on ACPI. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Thanks Yokota-san for tracking down the problem.
As reported in this list by several people, you may be seeing that
your PS/2 mouse is not detected after the recent ACPI update.
This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse
interrupt) to both the PS/2 mouse device node and the system reserved
resource node.
And if such a problem was found, please send ACPI data with the
report. This is very useful info. for our debugging.
To get ACPI data,
# acpidump -o foo.dsdt foo.asl
and send both files to acpi-jp@. See also acpidump(8).
To see if this is to be your case, put the following line in
/boot/device.hints and reboot.
debug.acpi.disable=sysresource
I personally, don't have enough time to hack the code for now (sorry),
but I think that newly added `placeholders' code causes the problem
for my first impression.
for (i = 0; i 100; i++) {
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IOPORT, rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_MEMORY, rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IRQ, rid, 0, ~0, 1, 0);
}
Mike, do you have any idea on this?
Anyway, Yokota-san thank you very much for finding a workaround.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
