acpi problem on dell latitude d830
Hello, I'm still investigating the problem with my dell latitude d830 notebook. ACPI states S3 and S4 don't work... Here comes dmesg: xueyu@monopohl:~% dmesg Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #2: Wed Dec 14 03:15:04 CET 2011 root@:/usr/obj/usr/src/sys/MONOPOHL i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2081214464 (1984 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, 7f55b800 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xefe8-0xefef mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory vgapci1: mem 0xfeb0-0xfebf at device 2.1 on pci0 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 hdac0: mem 0xfe9fc000-0xfe9f irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: at device 28.0 on pci0 pci11: on pcib1 pcib2: at device 28.1 on pci0 pci12: on pcib2 wpi0: mem 0xfe8ff000-0xfe8f irq 17 at device 0.0 on pci12 wpi0: [ITHREAD] pcib3: at device 28.3 on pci0 pci13: on pcib3 pcib4: at device 28.5 on pci0 pci9: on pcib4 bge0: 0x00a002> mem 0xfe5f-0xfe5f irq 17 at device 0.0 on pci9 bge0: CHIP ID 0xa002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: [FILTER] uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 uhci2: [ITHREAD] usbus3: on uhci2 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib5: at device 30.0 on pci0 pci3: on pcib5 cbb0: at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] fwohci0: <1394 Open Host Controller Interface> mem 0xfe4ff000-0xfe4f,0xfe4fe800-0xfe4fefff irq 19 at device 1.4 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 35:4f:c0:00:0b:25:ec:70 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x109 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 36:4f:c0:25:ec:70 fwe0: Ethernet address: 36:4f:c0:25:ec:70 fwip0: on firewire0 fwip0: Firewire address: 35:4f:c0:00:0b:25:ec:70 @ 0xfffe, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eef,0xeff0-0xefff irq 17 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint,
Re: acpi problem on dell latitude d830
Ouyang Xueyu writes: > Hello! > > I`ve just installed freebsd 8.2 i386 stable on a Dell Latitude D830. > I`m using gnome 2 with HAL and DBUS successfully. > > My notebook is not able to go into sleeping mode, it doesn`t work when I use > "acpiconf -s 3" or "acpiconf -s 4". Mode S3 gets it into sleep mode, but it > freezes > after wake-up with a distorted screen. > In mode S4 (suspend-to-disk) it isn`t even able to > get into sleeping mode. I want to initiate S4 state by closing the lid. I have a Latitude D630, which is basically the smaller brother of the D830. When it ran FreeBSD I had success in getting the D630 to sleep (s3) and resume. This was a while ago on 8-STABLE with amd64. At least back then, you would need an amd64 install to get this working (something with acpi being better in amd64 then it was in i386). I am not sure that is still the case, but I would not be surprised if it is. However, before you run off and reinstall: (again back then) both the bge and wpi driver (i.e. LAN and WLAN) did not work properly after resuming. This basically made sleeping the laptop useless. I'm not sure this is such good news, but I hope it is informative. If you manage to get it working let me know. Regards, -- - Frank ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
acpi problem on dell latitude d830
Hello! I`ve just installed freebsd 8.2 i386 stable on a Dell Latitude D830. I`m using gnome 2 with HAL and DBUS successfully. My notebook is not able to go into sleeping mode, it doesn`t work when I use "acpiconf -s 3" or "acpiconf -s 4". Mode S3 gets it into sleep mode, but it freezes after wake-up with a distorted screen. In mode S4 (suspend-to-disk) it isn`t even able to get into sleeping mode. I want to initiate S4 state by closing the lid. I also want to use the docking station. I would like to use the hot-docking functionality. The docking station has a power switch, which functions properly. It also has an undocking-button, which causes a freeze of the system. The audio-out on the docking-station is also not working. PS/2 keyboard, ethernet and USB on the docking-station is working. My kernel was compiled with acpi_dock. dmesg says: acpi_dock0: on acpi0 acpi_dock0: _DCK failed Xueyu ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ACPI? problem with release 8.0 | Perhaps solved?
On Fri, 16 Apr 2010 17:13:48 +0930, Malcolm Kay wrote: > My RELEASE-8.0 has now been up for about 2hr, not > long enough to be sure the difficulty is circumvented, > but long enough to look promising. Previously RELEASE-8.0 > has not stayed up more than about 4min. Sounds promising .. > I tried setting machdep.idle to acpi and then to hlt without > success. But I now have set machdep.idle=spin. Wow, ok. I only have a vague idea of how these work, but having to change this definitely indicates a bug somewhere; whether your BIOS settings or ACPI implementation or kernel or what else, I've no idea. > Discovered there can be some problem in trying to set this > too early -- in particular in loader.conf -- presumably because > acpi.ko is not yet loaded. I ended up making sure everything was > ready by putting: Don't presume too easily .. acpi.ko gets loaded really early, it's needed fired up even before scanning busses and initialising most devices. A verbose dmesg.boot should give some indication to anyone familiar with what should be. An acpidump may be useful too. Can you put files up anywhere to fetch? If not, you can mail me them, they're each too big to attach to -questions. The usual deal on acpi@ is to put up URL(s) to such files; I'd be happy to host them here. But you really should take this afresh to acpi@ .. they don't bite, the worst that can happen is they'll ignore you :) and with a new message with the concise story to date, I'd expect someone to take an interest; maybe just to say 'turn this off|on' or or 'that was fixed in -stable last month' or 'try this patch' or 'show us your [whatever]' .. >#!/bin/sh >echo "setting machdep.idle=spin" >/sbin/sysctl machdep.idle=spin > in /etc/rc.local Ok. dmesg.boot then will show what happens before that gets switched. If you enable console.log in syslog.conf that change will show up there after boot messages, maybe other useful stuff, but at least show dmesg. > To check what is happening I've created /usr/local/bin/sysctldump.sh as: >#!/bin/sh >[ -f /tmp/sysctl.dump.4 ] && mv -f /tmp/sysctl.dump.4 /tmp/sysctl.dump.5 >[ -f /tmp/sysctl.dump.3 ] && mv -f /tmp/sysctl.dump.3 /tmp/sysctl.dump.4 >[ -f /tmp/sysctl.dump.2 ] && mv -f /tmp/sysctl.dump.2 /tmp/sysctl.dump.3 >[ -f /tmp/sysctl.dump.1 ] && mv -f /tmp/sysctl.dump.1 /tmp/sysctl.dump.2 >[ -f /tmp/sysctl.dump ] && mv -f /tmp/sysctl.dump /tmp/sysctl.dump.1 >sysctl -ao > /tmp/sysctl.dump > and adding: >#sysctl dump >1-59/2 * * * * root /usr/local/bin/sysctldump.sh > to /etc/crontab. sysctl -ao is likely Way Too Much Information, though I suppose diffs between them might show something useful changing over time. 'sysctl hw dev acpi' is probably plenty to chew on. > I feel somewhat concerned that this cronjob may be sufficiently frequent to > prevent the system looking for the idle state and thus circumventing the > problem in same other way. So I'm not yet convinced that I have a real > solution. We're not talking about idle in the sense top shows you - this is about the kernel having nothing to do for perhaps hundreds of microseconds so entering a microsleep state. The old 386s just had the HLT instruction which had the CPU wait for an interrupt (to save power). These days there are multiple C-states with varying levels of power reduction with different latencies, ie times to wake up, usually managed by ACPI. I suspect 'spin' just loops awaiting an interrupt, staying busy? C1E is one such newer state. I know nothing about it, but that's what your system thought it should use the amdc1e cpufreq? driver for, so your problem definitely seems related to that. This clearly is within the ambit of the acpi@ list, and most of those folks seem rarely to have the sort of spare time needed to follow -questions. Also at least check the change log between your BIOS and the latest; if there's anything related to C states or similar, you should try it; they always say not to do it unless you need to - you might need to, and that might be all you need to do. > I'll try removing the cronjob. > > Thanks again for your attention, > Regards, > > Malcolm Kay Thanks for cc'ing me, I read -digests which can take half a day and make replying a bit tedious, not to mention breaking list threading. cheers, Ian [..] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ACPI? problem with release 8.0 | Perhaps solved?
My RELEASE-8.0 has now been up for about 2hr, not long enough to be sure the difficulty is circumvented, but long enough to look promising. Previously RELEASE-8.0 has not stayed up more than about 4min. I tried setting machdep.idle to acpi and then to hlt without success. But I now have set machdep.idle=spin. Discovered there can be some problem in trying to set this too early -- in particular in loader.conf -- presumably because acpi.ko is not yet loaded. I ended up making sure everything was ready by putting: #!/bin/sh echo "setting machdep.idle=spin" /sbin/sysctl machdep.idle=spin in /etc/rc.local To check what is happening I've created /usr/local/bin/sysctldump.sh as: #!/bin/sh [ -f /tmp/sysctl.dump.4 ] && mv -f /tmp/sysctl.dump.4 /tmp/sysctl.dump.5 [ -f /tmp/sysctl.dump.3 ] && mv -f /tmp/sysctl.dump.3 /tmp/sysctl.dump.4 [ -f /tmp/sysctl.dump.2 ] && mv -f /tmp/sysctl.dump.2 /tmp/sysctl.dump.3 [ -f /tmp/sysctl.dump.1 ] && mv -f /tmp/sysctl.dump.1 /tmp/sysctl.dump.2 [ -f /tmp/sysctl.dump ] && mv -f /tmp/sysctl.dump /tmp/sysctl.dump.1 sysctl -ao > /tmp/sysctl.dump and adding: #sysctl dump 1-59/2 * * * * root /usr/local/bin/sysctldump.sh to /etc/crontab. I feel somewhat concerned that this cronjob may be sufficiently frequent to prevent the system looking for the idle state and thus circumventing the problem in same other way. So I'm not yet convinced that I have a real solution. I'll try removing the cronjob. Thanks again for your attention, Regards, Malcolm Kay On Tue, 13 Apr 2010 02:38 pm, Malcolm Kay wrote: > On Tue, 13 Apr 2010 04:03 am, Ian Smith wrote: > > In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 > > > > On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay > > wrote: > > > I desperately need to make some progress on this issue. > > > > Then I suggest taking it to freebsd-acpi@ without passing go > > .. maybe with a bit more data to hand, as outlined in the > > ACPI debugging section of the handbook. > > Yes, I have now realised this; but now somewhat reticent to > move there now and be criticised for cross-posting > > > > Is it likely that the issue is real rather than hardware > > > or disk corruption? Earlier releases are operating OK on > > > the same machine. > > > > Sounds like a real issue, but I don't know the hardware. > > Does it have the latest available BIOS update? If not, > > that's step one. Will it stay up long enough to get a > > verbose dmesg off it? Do you have a verbose dmesg from an > > earlier working release for comparison? > > Probably not; I have considered it. > But the manufacturer's site warns not to upgrade unless you > have identifyable problems (or something similar). > And since earlier release work well I'm not anxious to open a > new can of worms. If I become sufficiently desparate I'll try > it. > > > > I have now confirmed that: > > > debug.acpi.disabled=acad button cpu lid thermal timer > > > video still leaves the system crashing and powering down > > > when idle for a while. And the more extensive: > > > debug.acpi.disabled=acad bus children button cmbat cpu > > > ec isa lid pci pci_link sysresource thermal timer video > > > does the same. > > > > > > I don't really need power management but with acpi > > > disabled the disks are not visible to the system. > > > > ACPI needs to work on modern hardware, no question. > > > > > Are there sysctl variables that can influence this > > > behaviour? Currently I believe we have: > > > > > > hw.acpi.supported_sleep_state: S1 S4 S5 > > > hw.acpi.power_button_state: S5 > > > hw.acpi.sleep_button_state: S1 > > > hw.acpi.lid_switch_state: NONE > > > hw.acpi.standby_state: S1 > > > hw.acpi.suspend_state: NONE > > > hw.acpi.sleep_delay: 1 > > > hw.acpi.s4bios: 0 > > > hw.acpi.verbose: 0 > > > > May help to set hw.acpi.verbose=1 in /boot/loader.conf while > > debugging; especially useful after verbose boot for detail > > in dmesg and messages. > > Looks as though it might be useful, but I'm starting to > believe acpi itself may not be the problem > > > > hw.acpi.disable_on_reboot: 0 > > > hw.acpi.handle_reboot: 0 > > > hw.acpi.reset_video: 0 > > > hw.acpi.cpu.cx_lowest: C1 > > > > Is that with acpi.thermal disabled? > > No, this is run with acpi as default configured. > Boot | login as root | sysctl -a > sysctl.dump | shutdown -p > now (Get out before crash so that I don't get into trouble > with fsck on reboot, yes it runs in the background but takes > forever.) > > Rebooting in FreeBSD 7.0 I can now mount the 8.0 partitions > and look at the dump in my own time -- and also prepare these > emails. (Fsck also runs under 7.0 on the 8.0 partitions if 8.0 > was allowed to crash.) > > > If so, showing hw.acpi > > and debug.acpi with everything enabled might provide more > > clues. > > OK > > > > machdep.idle: amdc1e > > > machdep.idle_available: spin, amdc1e, hlt, acpi, > > > > > > However on the earlier RELEASEs that
Re: ACPI? problem with release 8.0
On Tue, 13 Apr 2010 04:03 am, Ian Smith wrote: > In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 > > On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay wrote: > > I desperately need to make some progress on this issue. > > Then I suggest taking it to freebsd-acpi@ without passing go > .. maybe with a bit more data to hand, as outlined in the ACPI > debugging section of the handbook. Yes, I have now realised this; but now somewhat reticent to move there now and be criticised for cross-posting > > > Is it likely that the issue is real rather than hardware > > or disk corruption? Earlier releases are operating OK on > > the same machine. > > Sounds like a real issue, but I don't know the hardware. Does > it have the latest available BIOS update? If not, that's step > one. Will it stay up long enough to get a verbose dmesg off > it? Do you have a verbose dmesg from an earlier working > release for comparison? Probably not; I have considered it. But the manufacturer's site warns not to upgrade unless you have identifyable problems (or something similar). And since earlier release work well I'm not anxious to open a new can of worms. If I become sufficiently desparate I'll try it. > > > I have now confirmed that: > > debug.acpi.disabled=acad button cpu lid thermal timer > > video still leaves the system crashing and powering down > > when idle for a while. And the more extensive: > > debug.acpi.disabled=acad bus children button cmbat cpu ec > > isa lid pci pci_link sysresource thermal timer video > > does the same. > > > > I don't really need power management but with acpi disabled > > the disks are not visible to the system. > > ACPI needs to work on modern hardware, no question. > > > Are there sysctl variables that can influence this > > behaviour? Currently I believe we have: > > > > hw.acpi.supported_sleep_state: S1 S4 S5 > > hw.acpi.power_button_state: S5 > > hw.acpi.sleep_button_state: S1 > > hw.acpi.lid_switch_state: NONE > > hw.acpi.standby_state: S1 > > hw.acpi.suspend_state: NONE > > hw.acpi.sleep_delay: 1 > > hw.acpi.s4bios: 0 > > hw.acpi.verbose: 0 > > May help to set hw.acpi.verbose=1 in /boot/loader.conf while > debugging; especially useful after verbose boot for detail in > dmesg and messages. Looks as though it might be useful, but I'm starting to believe acpi itself may not be the problem > > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C1 > > Is that with acpi.thermal disabled? No, this is run with acpi as default configured. Boot | login as root | sysctl -a > sysctl.dump | shutdown -p now (Get out before crash so that I don't get into trouble with fsck on reboot, yes it runs in the background but takes forever.) Rebooting in FreeBSD 7.0 I can now mount the 8.0 partitions and look at the dump in my own time -- and also prepare these emails. (Fsck also runs under 7.0 on the 8.0 partitions if 8.0 was allowed to crash.) > If so, showing hw.acpi > and debug.acpi with everything enabled might provide more > clues. OK > > > machdep.idle: amdc1e > > machdep.idle_available: spin, amdc1e, hlt, acpi, > > > > However on the earlier RELEASEs that work I note we do not > > have machdep.idle or machdep.idle_available. Instead I > > find: machdep.cpu_idle_hlt: 1 > > machdep.hlt_cpus: 0 > > > > Although I've not been able to relate this directly to my > > problem from Googling it seems that there some issues with > > amdc1e under BSD, Linux and perhaps Windows. But all the > > references seem to amd c1e are related to systems in 64 bit > > mode while I am running (or trying to run) i386 so I wonder > > why I have: > > machdep.idle: amdc1e > > > > Maybe my problem is not acpi as such but this idle mode. > > Could well be. Someone on acpi@ will know about amdc1e, I > don't, but any BIOS setting re C1E could be relevant to this. > > > My thought is to change this to > > machdep.idle: hlt > > or even > > machdep.idle: acpi > > Maybe try setting it to acpi first (without any disabled > parts) and try? Can't do any worse than crash the same? I think this should be my next task. I have on hand another machine (not mine) running realease 8.0 but using an Intel Core i7 processor. This shows machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, > > > Any comments or ideas please! > > > > Thank you for your attention. > > > > Malcolm Kay > > > > On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote: > > > My machine had two SATA 300GB drives > > > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD > > > RELEASE-6.3 and the other RELEASE-7.0 all of which worked > > > OK. > > > > > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) > > > and installed RELEASE 8.0 thereon. When I boot to RELEASE > > > 8.0 I find after some time, few minutes to rather more > > > minutes the system just powers down without warning or > >
Re: ACPI? problem with release 8.0
On Mon, 12 Apr 2010 04:40 pm, Adam Vande More wrote: > On Mon, Apr 12, 2010 at 1:01 AM, Malcolm Kay > > wrote: > > I desperately need to make some progress on this issue. > > > > Is it likely that the issue is real rather than hardware > > or disk corruption? Earlier releases are operating OK on the > > same machine. > > > > I have now confirmed that: > > debug.acpi.disabled=acad button cpu lid thermal timer video > > still leaves the system crashing and powering down when idle > > for a while. And the more extensive: > > debug.acpi.disabled=acad bus children button cmbat cpu ec > > isa lid pci pci_link sysresource thermal timer video > > does the same. > > > > I don't really need power management but with acpi disabled > > the disks are not visible to the system. > > > > Are there sysctl variables that can influence this > > behaviour? Currently I believe we have: > > > > hw.acpi.supported_sleep_state: S1 S4 S5 > > hw.acpi.power_button_state: S5 > > hw.acpi.sleep_button_state: S1 > > hw.acpi.lid_switch_state: NONE > > hw.acpi.standby_state: S1 > > hw.acpi.suspend_state: NONE > > hw.acpi.sleep_delay: 1 > > hw.acpi.s4bios: 0 > > hw.acpi.verbose: 0 > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C1 > > machdep.idle: amdc1e > > machdep.idle_available: spin, amdc1e, hlt, acpi, > > > > However on the earlier RELEASEs that work I note we do not > > have machdep.idle or machdep.idle_available. Instead I find: > > machdep.cpu_idle_hlt: 1 > > machdep.hlt_cpus: 0 > > > > Although I've not been able to relate this directly to my > > problem from Googling it seems that there some issues with > > amdc1e under BSD, Linux and perhaps Windows. But all the > > references seem to amd c1e are related to systems in 64 bit > > mode while I am running (or trying to run) i386 so I wonder > > why I have: > > machdep.idle: amdc1e > > > > Maybe my problem is not acpi as such but this idle mode. > > > > My thought is to change this to > > machdep.idle: hlt > > or even > > machdep.idle: acpi > > > > Any comments or ideas please! > > > > Thank you for your attention. > > Is there anything in /var/log/messages which indicates the > cause? Can you monitor cpu temp? No clues in messages -- seems to just power down without any warning. I don't seem to have any thermal monitoring readily available except in the BIOS screens -- which seem to indicate everything is fine. But I guess this is not really indicative of what is happening with a running system. But the same machine has run earlier versions of FreeBSD staying up months at a time and only going down on power failures or on odd occassions I might want to look at BIOS settings or some such, so I feel fairly confident it is not a thermal issue. Hmm, I think there might be a BIOS setting to switch on health reporting which I expect would show up under sysctl. Thanks for the contribution. The more I think about it the more I believe the issue is connected with machdep.idle: amdc1e I am going to try changing this. Thanks and regards, Malcolm ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ACPI? problem with release 8.0
In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay wrote: > I desperately need to make some progress on this issue. Then I suggest taking it to freebsd-acpi@ without passing go .. maybe with a bit more data to hand, as outlined in the ACPI debugging section of the handbook. > Is it likely that the issue is real rather than hardware > or disk corruption? Earlier releases are operating OK on the same > machine. Sounds like a real issue, but I don't know the hardware. Does it have the latest available BIOS update? If not, that's step one. Will it stay up long enough to get a verbose dmesg off it? Do you have a verbose dmesg from an earlier working release for comparison? > I have now confirmed that: > debug.acpi.disabled=acad button cpu lid thermal timer video > still leaves the system crashing and powering down when idle for > a while. And the more extensive: > debug.acpi.disabled=acad bus children button cmbat cpu ec isa > lid pci pci_link sysresource thermal timer video > does the same. > > I don't really need power management but with acpi disabled the > disks are not visible to the system. ACPI needs to work on modern hardware, no question. > Are there sysctl variables that can influence this behaviour? > Currently I believe we have: > > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: NONE > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 May help to set hw.acpi.verbose=1 in /boot/loader.conf while debugging; especially useful after verbose boot for detail in dmesg and messages. > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 Is that with acpi.thermal disabled? If so, showing hw.acpi and debug.acpi with everything enabled might provide more clues. > machdep.idle: amdc1e > machdep.idle_available: spin, amdc1e, hlt, acpi, > > However on the earlier RELEASEs that work I note we do not have > machdep.idle or machdep.idle_available. Instead I find: > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 0 > > Although I've not been able to relate this directly to my problem > from Googling it seems that there some issues with amdc1e under > BSD, Linux and perhaps Windows. But all the references seem to > amd c1e are related to systems in 64 bit mode while I am running > (or trying to run) i386 so I wonder why I have: > machdep.idle: amdc1e > > Maybe my problem is not acpi as such but this idle mode. Could well be. Someone on acpi@ will know about amdc1e, I don't, but any BIOS setting re C1E could be relevant to this. > My thought is to change this to > machdep.idle: hlt > or even > machdep.idle: acpi Maybe try setting it to acpi first (without any disabled parts) and try? Can't do any worse than crash the same? > Any comments or ideas please! > > Thank you for your attention. > > Malcolm Kay > > On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote: > > My machine had two SATA 300GB drives > > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD > > RELEASE-6.3 and the other RELEASE-7.0 all of which worked OK. > > > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) and > > installed RELEASE 8.0 thereon. When I boot to RELEASE 8.0 > > I find after some time, few minutes to rather more minutes > > the system just powers down without warning or any obvious > > cause. It seems to mostly happen when the system is relatively > > quiet. Adam's suggestion to check that esp. CPU temperature is within spec is worth checking; if you don't have any thermal zones in your ACPI I'd be surprised, and maybe concerned. A finger on the heatsink is next best. > > Suspecting the ACPI I added: > > hint.acpi.0.disabled=1 > > to loader.conf. > > I then found RELEASE 8.0 would not boot -- or at least > > it was unable to mount root. I get a "mountroot>" prompt > > but this seemed not to accept anything I could think of, > > and "?" to list available targets yielded nothing. Rebooting > > and overriding this with option 2 (enable ACPI) in the boot > > menu took me back to a bootable but fragile system. > > > > Changing the loader.conf entry to: > > debug.acpi.disabled=all > > had the same effect as the hint.acpi.0.disabled=1. As it should. > > I then thought to be somewhat selective with > > debug.acpi.disabled and intended to try: > > debug.acpi.disabled=acad button cpu lid thermal timer video > > only now as I write this I discover I actually entered: > > debug.acpi.disabled=acadbutton cpu lid thermal timer video > > > > Now the RELEASE-8.0 booted but remained fragile. > > > > I've repaired this last entry and will proceed to try it. > > Meanwhile I feel I am fumbling about in the dark without > > sufficient (or any re
Re: ACPI? problem with release 8.0
On Mon, Apr 12, 2010 at 1:01 AM, Malcolm Kay wrote: > I desperately need to make some progress on this issue. > > Is it likely that the issue is real rather than hardware > or disk corruption? Earlier releases are operating OK on the same > machine. > > I have now confirmed that: > debug.acpi.disabled=acad button cpu lid thermal timer video > still leaves the system crashing and powering down when idle for > a while. And the more extensive: > debug.acpi.disabled=acad bus children button cmbat cpu ec isa > lid pci pci_link sysresource thermal timer video > does the same. > > I don't really need power management but with acpi disabled the > disks are not visible to the system. > > Are there sysctl variables that can influence this behaviour? > Currently I believe we have: > > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: NONE > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > machdep.idle: amdc1e > machdep.idle_available: spin, amdc1e, hlt, acpi, > > However on the earlier RELEASEs that work I note we do not have > machdep.idle or machdep.idle_available. Instead I find: > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 0 > > Although I've not been able to relate this directly to my problem > from Googling it seems that there some issues with amdc1e under > BSD, Linux and perhaps Windows. But all the references seem to > amd c1e are related to systems in 64 bit mode while I am running > (or trying to run) i386 so I wonder why I have: > machdep.idle: amdc1e > > Maybe my problem is not acpi as such but this idle mode. > > My thought is to change this to > machdep.idle: hlt > or even > machdep.idle: acpi > > Any comments or ideas please! > > Thank you for your attention. > Is there anything in /var/log/messages which indicates the cause? Can you monitor cpu temp? -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ACPI? problem with release 8.0
I desperately need to make some progress on this issue. Is it likely that the issue is real rather than hardware or disk corruption? Earlier releases are operating OK on the same machine. I have now confirmed that: debug.acpi.disabled=acad button cpu lid thermal timer video still leaves the system crashing and powering down when idle for a while. And the more extensive: debug.acpi.disabled=acad bus children button cmbat cpu ec isa lid pci pci_link sysresource thermal timer video does the same. I don't really need power management but with acpi disabled the disks are not visible to the system. Are there sysctl variables that can influence this behaviour? Currently I believe we have: hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: NONE hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 machdep.idle: amdc1e machdep.idle_available: spin, amdc1e, hlt, acpi, However on the earlier RELEASEs that work I note we do not have machdep.idle or machdep.idle_available. Instead I find: machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 Although I've not been able to relate this directly to my problem from Googling it seems that there some issues with amdc1e under BSD, Linux and perhaps Windows. But all the references seem to amd c1e are related to systems in 64 bit mode while I am running (or trying to run) i386 so I wonder why I have: machdep.idle: amdc1e Maybe my problem is not acpi as such but this idle mode. My thought is to change this to machdep.idle: hlt or even machdep.idle: acpi Any comments or ideas please! Thank you for your attention. Malcolm Kay On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote: > My machine had two SATA 300GB drives > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD > RELEASE-6.3 and the other RELEASE-7.0 all of which worked OK. > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) and > installed RELEASE 8.0 thereon. When I boot to RELEASE 8.0 > I find after some time, few minutes to rather more minutes > the system just powers down without warning or any obvious > cause. It seems to mostly happen when the system is relatively > quiet. > > Suspecting the ACPI I added: > hint.acpi.0.disabled=1 > to loader.conf. > I then found RELEASE 8.0 would not boot -- or at least > it was unable to mount root. I get a "mountroot>" prompt > but this seemed not to accept anything I could think of, > and "?" to list available targets yielded nothing. Rebooting > and overriding this with option 2 (enable ACPI) in the boot > menu took me back to a bootable but fragile system. > > Changing the loader.conf entry to: > debug.acpi.disabled=all > had the same effect as the hint.acpi.0.disabled=1. > > I then thought to be somewhat selective with > debug.acpi.disabled and intended to try: > debug.acpi.disabled=acad button cpu lid thermal timer video > only now as I write this I discover I actually entered: > debug.acpi.disabled=acadbutton cpu lid thermal timer video > > Now the RELEASE-8.0 booted but remained fragile. > > I've repaired this last entry and will proceed to try it. > Meanwhile I feel I am fumbling about in the dark without > sufficient (or any real) knowledge of the range of tasks > performed by ACPI. > > Is my guess that I have an interaction problem between ACPI > and RELEASE-8.0 a reasonable one? Where can I go from here? > > The system uses a Gigabyte GA-M55SLI-S4 mother board and the > prcessor is AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ > > Please offer suggestions or comments. > > Malcolm Kay > > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
ACPI? problem with release 8.0
My machine had two SATA 300GB drives (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD RELEASE-6.3 and the other RELEASE-7.0 all of which worked OK. Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) and installed RELEASE 8.0 thereon. When I boot to RELEASE 8.0 I find after some time, few minutes to rather more minutes the system just powers down without warning or any obvious cause. It seems to mostly happen when the system is relatively quiet. Suspecting the ACPI I added: hint.acpi.0.disabled=1 to loader.conf. I then found RELEASE 8.0 would not boot -- or at least it was unable to mount root. I get a "mountroot>" prompt but this seemed not to accept anything I could think of, and "?" to list available targets yielded nothing. Rebooting and overriding this with option 2 (enable ACPI) in the boot menu took me back to a bootable but fragile system. Changing the loader.conf entry to: debug.acpi.disabled=all had the same effect as the hint.acpi.0.disabled=1. I then thought to be somewhat selective with debug.acpi.disabled and intended to try: debug.acpi.disabled=acad button cpu lid thermal timer video only now as I write this I discover I actually entered: debug.acpi.disabled=acadbutton cpu lid thermal timer video Now the RELEASE-8.0 booted but remained fragile. I've repaired this last entry and will proceed to try it. Meanwhile I feel I am fumbling about in the dark without sufficient (or any real) knowledge of the range of tasks performed by ACPI. Is my guess that I have an interaction problem between ACPI and RELEASE-8.0 a reasonable one? Where can I go from here? The system uses a Gigabyte GA-M55SLI-S4 mother board and the prcessor is AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ Please offer suggestions or comments. Malcolm Kay ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: SMP and ACPI problem ??
"Alain G. Fabry" writes (in *extremely* long lines, which I wrapped for him): > To make a long story shorteverything worked fine on my system > (7.0-RELEASE FreeBSD). Last night I was updating stuff on my windoswXP > guess (under qemu) and performed a clean shutdown. > > This morning, after bringing back up my system it has been unbearably > slow. Without doing anyting to FreeBSD, it suddenly started working in > SMP mode -> recognizing my 2 processors. Before, it never did > this...and looking at the speed it is going now, I'm happy it didn't. > > After googling a bit, I tried to disable ACPI in order to fall back to > single processor mode, but my system keeps acting up like it never did > before. Very slow booting and KDM/KDE loading. Once up it's ok until I > run a portupgrade or such. That's weird all right. My first guess would be interrupt problems. vmstat(8) will show you what is happening on that front. > 1. What are some suggestions as to make it run 'normal' again? > You need to understand what's going wrong first. > 2. Is it possible to make it actually run better in SMP mode? Your system has an SMP kernel, I presume? [The GENERIC kernel does, these days.] > 3. Can my updates on the Qemu WindowsXP host make my FreeBSD system > suddenly recognize the 2nd CPU? -> this doesn't make sense to me but > that's the only thing I worked on last night. Vanishingly unlikely, but not completely impossible. > I hope I can get some pointers as to what could have caused this and > what I can do to get it back to the way it was. I wouldn't be surprised if it were a hardware problem, which can be tricky to trace down from the software side. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
SMP and ACPI problem ??
Hi, To make a long story shorteverything worked fine on my system (7.0-RELEASE FreeBSD). Last night I was updating stuff on my windoswXP guess (under qemu) and performed a clean shutdown. This morning, after bringing back up my system it has been unbearably slow. Without doing anyting to FreeBSD, it suddenly started working in SMP mode -> recognizing my 2 processors. Before, it never did this...and looking at the speed it is going now, I'm happy it didn't. After googling a bit, I tried to disable ACPI in order to fall back to single processor mode, but my system keeps acting up like it never did before. Very slow booting and KDM/KDE loading. Once up it's ok until I run a portupgrade or such. 1. What are some suggestions as to make it run 'normal' again? 2. Is it possible to make it actually run better in SMP mode? 3. Can my updates on the Qemu WindowsXP host make my FreeBSD system suddenly recognize the 2nd CPU? -> this doesn't make sense to me but that's the only thing I worked on last night. I hope I can get some pointers as to what could have caused this and what I can do to get it back to the way it was. Thanks in advance, Alain ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ACPI Problem: "acpi_tz0:_TMP value is absurd"
I located a file for upgrading the BIOS for my Compaq machine but it requires Windows to install it. I deleted the Windows that came with the machine several months ago, so, for now, that option is out. I created a file with the following commands: sysctl hw.acpi.thermal.user_override=1 sysctl hw.acpi.thermal.polling_rate=1800 sysctl hw.acpi.thermal.user_override=0 and run it right after logging in as root using: source where is the file name. The message: acpi_tz0: _TMP value is absurd, ignored (-269.8C) still appears, but not as often. I could, of course, adjust it later if temperature might become a problem but, for now, the machine isn't on long enough for that to be a concern. It still doesn't fix the problem of an incorrect temperature, but at least I can read my monitor without it being cluttered with those messages. BMJ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI Problem: "acpi_tz0:_TMP value is absurd"
A few weeks ago, I upgraded my Compaq Presario desktop machine from FreeBSD 6.2 to 6.3. I soon noticed this message on the screen. Apparently, the system is measuring the temperature of absolute zero. At first, I thought it to be an installation error on my part, but reformatting the hard drive and re-installing 6.3 didn't change anything. This message still appears in 7.0. I installed 6.3 on a Thinkpad laptop but there doesn't seem to be a problem with that machine. A search through Google showed that other users are having the same difficulty but I haven't found a solution yet. It's quite frustrating as there doesn't seem to be a file which I could edit to reset ACPI, either is there anything in the desktop machine's BIOS. Does anyone have any suggestions? Thank you. BMJ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problem
Hello, when I install R6.2 in a USB drive on my laptop, I am using Boot FreeBSD [default], everything is o.k., when I finished the installation and reboot, if I still using Boot FreeBSD [default], I got following error message during ACPI: ACPI-501: *** Error Handler for [EmbeddedControl] returned AE_NO HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.C003.C004.C154] (Node 0x363d880) AE_NO HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.C154] (Node 0xc3642000) AE_NO HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.C15E._BIF] (Node 0xc3640d40) AE_NO HARDWARE_RESPONSE but if I using Boot FreeBSD with ACPI disabled, and the system running very well, what is the problem and how to fix it? many thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP LC II Netserver ACPI problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I haven't found a way, no mention of it. Pretty old BIOS. Went to HP's site, d/l the last one one they had (even it was old) & flashed it. Still pretty old comparatively. As for the dmesg errors, yeah, I guess I'll have to ignore them. I've tried everything I can to get rid of them, but it ain't happening. I read this in /usr/src/sys/i386/conf/NOTES: device eisa # By default, only 10 EISA slots are probed, since the slot numbers # above clash with the configuration address space of the PCI subsystem, # and the EISA probe is not very smart about this. This is sufficient # for most machines, but in particular the HP NetServer LC series comes # with an onboard AIC7770 dual-channel SCSI controller on EISA slot #11, # thus you need to bump this figure to 12 for them. options EISA_SLOTS=12 I recompiled my kernel with that option but it didn't help. So, there are no choices in the BIOS for ACPI that I can find. Nor is there anything about PNP except for a section where you can reserve areas of memory, interrupts, ports, etc., for PNP. But they're all set to the default, which is to be available for the system. So, I guess I'm in ignoring mode until maybe in the future when I find a fix. Thanks for the answer & help. On Sun, 29 May 2005, Paul Dufresne wrote: 1. Can't use ACPI on here. Machine not capable, apparently. Hence, the following: In my BIOS, I can enable and disable ACPI. (IBM PC 300GL). Could it be just that ACPI is disable in BIOS? 2. Have apic enabled in kernel & no problems that I know of Watch out ACPI and apic are two different things. Your problem is with ACPI, when I boot without ACPI (option 2 in 5.4-RELEASE, I get the same error messages. Couldn't these messages be simply ignored? --Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCmeQ4y0Ty5RZE55oRAi1CAJ96jBe0Ku3jydRHnA4RJUADLMUi8wCgjcmD YU8E+cCWaig/V6X/8IB/JZo= =EKMn -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP LC II Netserver ACPI problem
> 1. Can't use ACPI on here. Machine not capable, apparently. > Hence, the following: In my BIOS, I can enable and disable ACPI. (IBM PC 300GL). Could it be just that ACPI is disable in BIOS? > 2. Have apic enabled in kernel & no problems that I know of Watch out ACPI and apic are two different things. Your problem is with ACPI, when I boot without ACPI (option 2 in 5.4-RELEASE, I get the same error messages. Couldn't these messages be simply ignored? --Paul ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HP LC II Netserver ACPI problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is from dmesg: vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) I've read and googled for days and the following is what I'v either learned or think I've learned: 1. Can't use ACPI on here. Machine not capable, apparently. Hence, the following: ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES ACPI: table load failed: AE_NO_ACPI_TABLES 2. Have apic enabled in kernel & no problems that I know of 3. I think I'm supposed to disable plug and play in the bios but I can't find any simple way to do it. There are some choices under the "Configuration" portion of the bios menu under ISA non-Plug-and-Play Devices List of Memory resources, all available, none reserved List of Interrupt resources, all available, none reserved List of DMA resources, all available, none reserved List of I/O resources, all available, none reserved I have no idea how to match them up with the output of vga0 shown above, that is, to reserve the proper areas for its use. I tried working with it the other night & wound up locking the computer up rock solid. Would not boot. Had to pull the cmos battery & put back & reset everything back to where it had been to boot again. One of the first things I did after reading in the mail archives, googling, etc., was to boot to ACPI enabled, I assume which loads a kernel module instead of it having to be compiled in. Have output of that error message above too. Any help would sure be appreciated. Tired of no sleep, trying to figure this out. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCl5eay0Ty5RZE55oRAkMuAJ9CiDSYXnQxCrRFnWH43QZWW7JI2wCgk0P6 DddWLVPPwlPZkUuU3/67Ao8= =yD5c -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient issue with 5.4... ACPI problem..
"mojo fms" <[EMAIL PROTECTED]> writes: > I tryed loading the system with ACPI disabled and it worked just > fine. I have looked through the handbook but i cant seem to find a way > to permently disable it or how to fix the problem through it. Any help > on the issue would be great... According to "man acpi", putting hint.acpi.0.disabled="1" in /boot/loader.conf will disable ACPI completely. The Handbook also has a *very* extensive section on "Using and Debugging FreeBSD ACPI". ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient issue with 5.4... ACPI problem..
I tryed loading the system with ACPI disabled and it worked just fine. I have looked through the handbook but i cant seem to find a way to permently disable it or how to fix the problem through it. Any help on the issue would be great... From: Lowell Gilbert <[EMAIL PROTECTED]> Reply-To: freebsd-questions@freebsd.org To: "mojo fms" <[EMAIL PROTECTED]> CC: freebsd-questions@freebsd.org Subject: Re: dhclient issue with 5.4... Date: 13 May 2005 09:19:49 -0400 "mojo fms" <[EMAIL PROTECTED]> writes: > I did a reinstall recently and since then i can not connect the > internet using dhclient on that machine. I looked around on google for > a bit but found nothing that fixed the problem. I checked the PnP OS > option in the bios, it is already set to No, and i played around with > new network cables and such. If i plug the cable modem in to my wifes > windows computer it pops up with the new DHCP info almost right > away. Thanks for any help anyone can provide. What happens when you try to run dhclient by hand? Use the '-v' flag so that you will get the maximum amount of information from dhclient. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
