On 12 Jul 2013, at 10:01, Lundberg, Johannes
johan...@brilliantservice.co.jp wrote:
As the KMS code does not switch the display mode back, once X with KMS
starts, you can't get a console back.
Is there any solution for this in the works?
Yes. ray@ is currently being funded by the FreeBSD
On Fri, Jul 12, 2013 at 11:26:06AM +0100, David Chisnall wrote:
On 12 Jul 2013, at 10:01, Lundberg, Johannes
johan...@brilliantservice.co.jp wrote:
As the KMS code does not switch the display mode back, once X with KMS
starts, you can't get a console back.
Is there any solution for
on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre
to a followup message on using the fix posted on June 14. It' a tricky
issue with getting a string with quoted characters parsed correctly.
There have been a number of discussions on ThinkPad suspend/resume, but I
have not seen
on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre
to a followup message on using the fix posted on June 14. It' a tricky
issue with getting a string with quoted characters parsed correctly.
There have been a number of discussions on ThinkPad suspend/resume, but I
have not seen
it.
root@thinkpad:/usr/home/mpeterma # kldload acpi_video
acpi_video0: ACPI video extension on vgapci0
root@thinkpad:/usr/home/mpeterma # sysctl -a |grep bright
hw.acpi.video.lcd0.brightness: 35
root@thinkpad:/usr/home/mpeterma # sysctl
hw.acpi.video.lcd0.brightness=100
hw.acpi.video.lcd0.brightness
This is what is working on most of the other laptops I tried it.
root@thinkpad:/usr/home/**mpeterma # kldload acpi_video
acpi_video0: ACPI video extension on vgapci0
root@thinkpad:/usr/home/**mpeterma # sysctl -a |grep bright
hw.acpi.video.lcd0.brightness: 35
Switching off systems running FreeBSD 10.0-CURRENT #3 r250886: Tue May
21 23:12:29 CEST 2013 amd64 but pressing the power button doesn't switch
the box off anymore. The console is stuck with presenting last lines of
syncing disks and several numbers counting down the to-sync blocks.
This happens
' at 0xcaffd000
Table 'SSDT' at 0xcaffc000
Table 'SSDT' at 0xcaffb000
Table 'ASF!' at 0xcaff1000
Table 'HPET' at 0xcafee000
Table 'APIC' at 0xcafed000
APIC: Found table at 0xcafed000
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU
On Tue, May 21, 2013 at 12:50 PM, Artyom Mirgorodskiy
artyom.mirgorod...@gmail.com wrote:
Hi
More than a month I can not shutdown FreeBSD on my laptop correctly when
running Xorg with Intel GPU. However reboot work correctly. Shutdown work
fine if I choose Vesa driver in xorg.conf. So I can
486! system.stop after init. boot safe mode (only kernel enable?(no acpi
--
fname lname
oper...@operamail.com
--
http://www.fastmail.fm - A fast, anti-spam email service.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
on 28/01/2013 04:52 Glen Barber said the following:
On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you please
test the following
On Mon, Jan 28, 2013 at 10:16:43AM +0200, Andriy Gapon wrote:
on 28/01/2013 04:52 Glen Barber said the following:
On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never
On Sat, Jan 26, 2013 at 04:18:57PM +0200, Andriy Gapon wrote:
on 25/01/2013 18:08 Andriy Gapon said the following:
on 25/01/2013 15:51 John Baldwin said the following:
On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work
on 28/01/2013 14:45 Pawel Jakub Dawidek said the following:
FYI, it doesn't change anything for me. Resume seems to work, but
suspend just reset my laptop.
Sorry, I am a little confused by this description.
How can you know that resume works if suspend resets the machine?
--
Andriy Gapon
On Mon, Jan 28, 2013 at 03:07:59PM +0200, Andriy Gapon wrote:
on 28/01/2013 14:45 Pawel Jakub Dawidek said the following:
FYI, it doesn't change anything for me. Resume seems to work, but
suspend just reset my laptop.
Sorry, I am a little confused by this description.
How can you know
on 28/01/2013 15:24 Pawel Jakub Dawidek said the following:
On Mon, Jan 28, 2013 at 03:07:59PM +0200, Andriy Gapon wrote:
on 28/01/2013 14:45 Pawel Jakub Dawidek said the following:
FYI, it doesn't change anything for me. Resume seems to work, but
suspend just reset my laptop.
Sorry, I am a
On Mon, Jan 28, 2013 at 03:40:18PM +0200, Andriy Gapon wrote:
on 28/01/2013 15:24 Pawel Jakub Dawidek said the following:
On Mon, Jan 28, 2013 at 03:07:59PM +0200, Andriy Gapon wrote:
on 28/01/2013 14:45 Pawel Jakub Dawidek said the following:
FYI, it doesn't change anything for me. Resume
On Saturday, January 26, 2013 9:18:57 am Andriy Gapon wrote:
on 25/01/2013 18:08 Andriy Gapon said the following:
on 25/01/2013 15:51 John Baldwin said the following:
On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-26 11:58:16 -0500, Pawel Jakub Dawidek wrote:
On Fri, Jan 25, 2013 at 04:19:44PM -0500, Jung-uk Kim wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote:
On Thu, Jan 24, 2013 at
wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you
please
test the following patch and report back?
http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch
This will break
Al 25/01/2013 09:43, En/na Andriy Gapon ha escrit:
If you have ACPI suspend/resume working, if it used to work but stopped working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?
http://svn.freebsd.by/files/acpi-apic-wakeup
On Sun, Jan 27, 2013 at 4:38 PM, Gustau Pérez i Querol
gpe...@entel.upc.edu wrote:
Al 25/01/2013 09:43, En/na Andriy Gapon ha escrit:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you
please
On Sun, Jan 27, 2013 at 06:22:28PM -0800, Kevin Oberman wrote:
Very much the same on my ThinkPad T520. Suspend looks fine. Resume
turns on the backlight, but that's about it. No wireless and no
display. The power light continues to pulse, indicating the system
still considers itself suspended.
On Sun, Jan 27, 2013 at 09:32:28PM -0500, Glen Barber wrote:
On Sun, Jan 27, 2013 at 06:22:28PM -0800, Kevin Oberman wrote:
Very much the same on my ThinkPad T520. Suspend looks fine. Resume
turns on the backlight, but that's about it. No wireless and no
display. The power light continues
On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?
http://svn.freebsd.by/files
on 25/01/2013 18:08 Andriy Gapon said the following:
on 25/01/2013 15:51 John Baldwin said the following:
On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you
when display is turned off) I see this
message to be printed twice on the console:
CPU0: local APIC error 0x80
Although I must admit I see this message from time to time, but I
haven't found a pattern. Closing and opening the lid always make it
appear. Not sure how much it is related to ACPI
If you have ACPI suspend/resume working, if it used to work but stopped working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?
http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch
--
Andriy Gapon
On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?
http://svn.freebsd.by
On Fri, 25 Jan 2013 13:11:19 +0400
Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but
stopped working at some time, if it never worked, but you are still
hoping, could
On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek wrote:
One is when I leave laptop idle for some time (few hours?):
http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg
http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg
Small update. This panic doesn't
On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?
http://svn.freebsd.by/files
on 25/01/2013 15:51 John Baldwin said the following:
On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote:
If you have ACPI suspend/resume working, if it used to work but stopped
working
at some time, if it never worked, but you are still hoping, could you please
test the following
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote:
On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek
wrote:
One is when I leave laptop idle for some time (few hours?):
http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg
on 24/01/2013 02:54 Jung-uk Kim said the following:
Can you please try the attached patch? It is also available from here:
http://people.freebsd.org/~jkim/utcache.diff
Jung-uk,
I think that I have a much better patch for all potential ACPI object cache
problems :-)
http
, ACPI panics. Pictures
here:
http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg
http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg
Let me know if you need more info.
Can you please try the attached patch? It is also available from here:
http://people.freebsd.org/~jkim
that I have a much better patch for all potential ACPI
object cache problems :-)
http://people.freebsd.org/~avg/acpi-uma-cache.diff
What do you think?
We have to fix this bug because local cache is always used for
userland applications, e.g., iasl.
BTW, I tried something like that long ago
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-22 12:56:29 -0500, Pawel Jakub Dawidek wrote:
I just upgraded to HEAD today and was wondering what will explode.
Now I know.
When I unplug power cord from my laptop, ACPI panics. Pictures
here:
http://people.freebsd.org/~pjd/misc
I just upgraded to HEAD today and was wondering what will explode.
Now I know.
When I unplug power cord from my laptop, ACPI panics. Pictures here:
http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg
http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg
Let me know if you need
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
-fstack
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
On 18.01.2013 22:37, David Wolfskill wrote:
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote:
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34
+0300:
On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov
a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all) cc -O2 -pipe
On Thursday, May 24, 2012 2:15:26 am Andriy Gapon wrote:
Now that you committed the acpi_cpu fix I'd like to do the easy part -
protection from the problem in the future.
Does the following look OK?
Index: sys/kern/subr_bus.c
On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote:
on 17/05/2012 17:05 John Baldwin said the following:
On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote:
Oh, whoops. Actually, the right way to do this I think is
bus_hint_device_unit()
(and/or, not make the unit number in
we should prohibit such a combination (reject it
earlier).
I guess that in this particular case we already know that the devices are
really
CPU devices and are going to be claimed by acpi cpu driver. So we should
pass
cpu as the name.
Oh, whoops. Actually, the right way to do
on 17/05/2012 17:05 John Baldwin said the following:
On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote:
Oh, whoops. Actually, the right way to do this I think is
bus_hint_device_unit()
(and/or, not make the unit number in cpuX mean anything at all, but use a
separate
ivar to track
On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote:
on 17/05/2012 17:05 John Baldwin said the following:
On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote:
Oh, whoops. Actually, the right way to do this I think is
bus_hint_device_unit()
(and/or, not make the unit number in
already exists; skipping it
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
acpi_timer: acpi_timer0 already exists; skipping it
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect
it (be it kbdN or diskN) just because I say so. Not sure if this
ever makes sense and maybe we should prohibit such a combination (reject it
earlier).
I guess that in this particular case we already know that the devices are really
CPU devices and are going to be claimed by acpi cpu driver. So we should
know that the devices are
really
CPU devices and are going to be claimed by acpi cpu driver. So we should pass
cpu as the name.
Oh, whoops. Actually, the right way to do this I think is
bus_hint_device_unit()
(and/or, not make the unit number in cpuX mean anything at all, but use a
separate
))
acpi_timer: acpi_timer0 already exists; skipping it
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
(20120420/tbutils-293)
ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm
: acpi_sysresource devname:
(unknown))
acpi_timer: acpi_timer0 already exists; skipping it
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
(20120420/tbutils-293)
ACPI
to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
(20120420/tbutils-293)
ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0
devclass (class: acpi_sysresource devname:
(unknown))
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
(20120420/tbutils-293)
driver bug: Unable to set devclass (class
of 10, bbf0 (3) failed
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
(20120420
))
cpu0: ACPI CPU on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
(20120420/tbutils-293)
ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117)
ACPI: SSDT
on an Acer Aspire One D255E netbook. I have most
of
the
functionality I want with one major exception, when I enable ACPI my
integrated keyboard drivers aren't loaded. Without ACPI I can use my
keyboard
as atkbdc and atkbd get loaded, (not psm though), but I have problems
Andreas Tobler andre...@freebsd.org schrieb:
On 28.03.12 00:13, Jung-uk Kim wrote:
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached patch.
Note the patch reverts r233555 and applies the fix. This patch is
also
On 27/03/2012 23:13, Jung-uk Kim wrote:
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached patch.
Fixed the issue on my X61s, thanks :)
Sevan
___
On Tuesday 27 March 2012 09:39 pm, Nathan Whitehorn wrote:
On 03/27/12 17:13, Jung-uk Kim wrote:
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached
patch. Note the patch reverts r233555 and applies the fix. This
On Monday 26 March 2012 12:50 pm, Jung-uk Kim wrote:
On Monday 26 March 2012 01:42 am, Poul-Henning Kamp wrote:
I tried -current as of approx one day ago and was greeted with a
kernel printf flooding the screen with something about a ACPI(?)
mutex(?) refcount increasing.
I were unable
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached patch.
Note the patch reverts r233555 and applies the fix. This patch is
also available from here:
http://people.freebsd.org/~jkim/acpi_refcnt.diff
Thanks!
Jung-uk
On 03/27/12 17:13, Jung-uk Kim wrote:
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached patch.
Note the patch reverts r233555 and applies the fix. This patch is
also available from here:
On 28.03.12 00:13, Jung-uk Kim wrote:
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached patch.
Note the patch reverts r233555 and applies the fix. This patch is
also available from here:
On Monday 26 March 2012 01:42 am, Poul-Henning Kamp wrote:
I tried -current as of approx one day ago and was greeted with a
kernel printf flooding the screen with something about a ACPI(?)
mutex(?) refcount increasing.
I were unable to divine any identifying info from the messages
because
On 26/03/2012 06:42, Poul-Henning Kamp wrote:
I tried -current as of approx one day ago and was greeted with a
kernel printf flooding the screen with something about a ACPI(?)
mutex(?) refcount increasing.
I got the same when I built a new kernel last Thursday.
Sevan
panic: from debugger
I tried -current as of approx one day ago and was greeted with a
kernel printf flooding the screen with something about a ACPI(?)
mutex(?) refcount increasing.
I were unable to divine any identifying info from the messages
because the screen scrolled too fast and the message was longer
than
With yesterday's CURRENT (r233364) the system panics when I insert the battery
into the notebook.
milhouse.bsd-geek.de dumped core - see /var/crash/vmcore.0
Sat Mar 24 22:26:15 CET 2012
FreeBSD milhouse.bsd-geek.de 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r233364M: Fri
Mar 23 17:48:19 CET 2012
Hello Guys,
Tank you for fast andere.
I habe Check The command: 'shutdown -r now' and 'init 6'
The Same Problem!
Can anyone help me?
Thanks?
by
Markus Fischer
Germany
___
freebsd-current@freebsd.org mailing list
to freebsd-current-unsubscr...@freebsd.org
John,
Thanks for your help, but that patch doesn't appear to address the problem.
I edited the atkbdc_isa.c file as you instructed, rebuilt and installed my
kernel, but my integrated keyboard remains unresponsive with ACPI enabled.
Here's the new
appear to address the problem.
I edited the atkbdc_isa.c file as you instructed, rebuilt and installed my
kernel, but my integrated keyboard remains unresponsive with ACPI enabled.
Here's the new output of dmesg -a http://pastebin.com/h6ahmD2ddevinfo -ur
http://pastebin.com/sdNcNEJUdevinfo -vr
as you instructed, rebuilt and installed my
kernel, but my integrated keyboard remains unresponsive with ACPI enabled.
Here's the new output of dmesg -a http://pastebin.com/h6ahmD2ddevinfo -ur
http://pastebin.com/sdNcNEJUdevinfo -vr http://pastebin.com/P2yqQBLY
Perhaps I was supposed to remove
Aspire One D255E netbook. I have most of
the
functionality I want with one major exception, when I enable ACPI my
integrated keyboard drivers aren't loaded. Without ACPI I can use my
keyboard
as atkbdc and atkbd get loaded, (not psm though), but I have problems with
shutdown, time
I want with one major exception, when I enable ACPI my
integrated keyboard drivers aren't loaded. Without ACPI I can use my
keyboard
as atkbdc and atkbd get loaded, (not psm though), but I have problems with
shutdown, time settings, power settings and usb controllers.
I have tried
On Tue, Jan 10, 2012 at 7:12 PM, Fischer Markus mfisc...@reitzner.de wrote:
Hello,
I habe a BIG Problem with the ACPI Interface.
The problem is the reboot command. The Shutdown command works.
I don't think ``reboot`` is the command you want. If you want the
computer to shut down
On Monday, January 02, 2012 11:39:10 pm aconnoll...@yahoo.co.jp wrote:
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the
functionality I want with one major exception, when I enable ACPI my
integrated keyboard drivers aren't loaded. Without ACPI I can use my keyboard
On 2012/01/04, at 0:37, John Baldwin j...@freebsd.org wrote:
On Monday, January 02, 2012 11:39:10 pm aconnoll...@yahoo.co.jp wrote:
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the
functionality I want with one major exception, when I enable ACPI my
integrated
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the
functionality I want with one major exception, when I enable ACPI my integrated
keyboard drivers aren't loaded. Without ACPI I can use my keyboard as atkbdc
and atkbd get loaded, (not psm though), but I have problems
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the
functionality I want with one major exception, when I enable ACPI my integrated
keyboard drivers aren't loaded. Without ACPI I can use my keyboard as atkbdc
and atkbd get loaded, (not psm though), but I have problems
going to be the feature that's going to cause headaches
post-9.0-RELEASE based on my observations of several mailing list
posts and the fact that 9.0 isn't actually RELEASEd yet (people have
run into issues with acpi, atkbdc, mfi, and usb so far, but that's
probably not everything).
If it could
with
ACPI disabled my power button does not work. I have found that the machine
hangs at boot during a scan of the PCI bus, but if I disable that
(hw.acpi.disable=pci) then the machine cannot find a boot drive.
So I have lost functionality that worked fine in BSD 8.
Thoughts? Suggestions
had no loader.conf, and the power button worked on my desktop machine. Now
with ACPI disabled my power button does not work. I have found that the
machine hangs at boot during a scan of the PCI bus, but if I disable that
(hw.acpi.disable=pci) then the machine cannot find a boot drive.
So I
that would do the trick, but it still prints:
pci0: ACPI PCI bus on pcib0
and then hangs.
Ok. The GX270 is pretty old, so this is probably a stretch but is
there an ACPI toggle / 'conformance' option in the BIOS? My guess is
that the machine is 1.0/1.1 spec, not 2.0 spec.
-Garrett
On 31 Dec 2011, at 11:40 AM, Garrett Cooper wrote:
Is your Optiplex running the latest BIOS firmware?
My Dell OptiPlex GX270 was running BIOS A06, but I found that there was an A07.
So I installed A07 hoping that would do the trick, but it still prints:
pci0: ACPI PCI bus on pcib0
On 31 Dec 2011, at 12:16 PM, Garrett Cooper wrote:
Ok. The GX270 is pretty old, so this is probably a stretch but is
there an ACPI toggle / 'conformance' option in the BIOS? My guess is
that the machine is 1.0/1.1 spec, not 2.0 spec.
-Garrett
No, there is no such option. I have been
On Sat, Dec 31, 2011 at 11:25 AM, Dan Allen danalle...@airwired.net wrote:
On 31 Dec 2011, at 12:16 PM, Garrett Cooper wrote:
Ok. The GX270 is pretty old, so this is probably a stretch but is
there an ACPI toggle / 'conformance' option in the BIOS? My guess is
that the machine is 1.0/1.1
like
if (ACPI 2.0)
oldCode();
else
newCodeForNewACPI();
so that it will always work for everyone without having to build a special
kernel? After all, I went from a working system to a hung system which is
not the best upgrade path... ;-)
Well it's hard to test stuff out without
On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote:
Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and
try booting the new kernel. See if this works.
It worked! No hang, power button works. Nice. I hope this experimental
option stays in.
Thank you everyone for your help.
On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote:
On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote:
Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and
try booting the new kernel. See if this works.
It worked! No hang, power button works. Nice. I hope this
. I csup'd at 12:24:26 MST and discovered the
failure at 15:41 MST.
This nooptions NEW_PCIB fix does seem rather tenuous if it is not documented.
Wouldn't a better route be something like
if (ACPI 2.0)
oldCode();
else
newCodeForNewACPI();
so that it will always work for everyone
that's going to cause headaches
post-9.0-RELEASE based on my observations of several mailing list
posts and the fact that 9.0 isn't actually RELEASEd yet (people have
run into issues with acpi, atkbdc, mfi, and usb so far, but that's
probably not everything).
If it could be made into a runtime
on it without
problems.
But FreeBSD/amd64 can not. It stops after kernel detect some
devices without any errors or panics.
This box has one big difference from billions other Intel-based
boxes on market: it has very special BIOS without ACPI at all. Someone
says, that it could be reason why FreeBSD
.
But FreeBSD/amd64 can not. It stops after kernel detect some
devices without any errors or panics.
This box has one big difference from billions other Intel-based
boxes on market: it has very special BIOS without ACPI at all. Someone
says, that it could be reason why FreeBSD/amd64 could not be boot
On 2011-12-09 10:10:18, Lev Serebryakov l...@freebsd.org wrote:
Soekris (famous developer of small x86-compatible appliance-like
hardware) released *net6501* some time ago, which is based on Atom (E6xx)
CPU. It seems, that 64-bit version of Linux could run on it without
problems.
But
version of Linux could run on it without
problems.
But FreeBSD/amd64 can not. It stops after kernel detect some
devices without any errors or panics.
This box has one big difference from billions other Intel-based
boxes on market: it has very special BIOS without ACPI at all. Someone
says
: it has very special BIOS without ACPI at all. Someone
says, that it could be reason why FreeBSD/amd64 could not be boot on
this box.
Is it true? Is it possible to have FreeBSD/amd64 without ACPI?
It seems, that device mptable in kernel config helps.
Why is it not in GENERIC kernel?
Just
Hello, Andriy.
You wrote 11 декабря 2011 г., 23:12:34:
Is it true? Is it possible to have FreeBSD/amd64 without ACPI?
It seems, that device mptable in kernel config helps.
Why is it not in GENERIC kernel?
Just a guess, maybe because GENERIC kernel is for generic hardware.
Oh, yes
301 - 400 of 1744 matches
Mail list logo
