Hello all,
I have just installed the OpenBSD on a ASUS tuf f15 gaming laptop,
installation went very smooth.
But I soon as I reboot the computer, it put me in ddb shell and there was a
kernel panic related to acpi.
I searched on internet, and tried to update my bios to the latest version
root to create a bug report including acpi tables.
(you may want to sendbug -P > somefile and copy that elsewhere if the
machine isn't setup for email). Preferably with an unmodified kernel
so that the dmesg is complete.
Try to get a copy of the full error message too.
> So, I added these lines
t stopped unexpectedly after
some time (hours or minutes) without any apparent reason.
dmesg said 'acpicpu0 ... bad value ...'
(Unfortunately I don't have a copy of this dmesg).
So, I added these lines in /etc/bsd.re-config, to disable ACPI drivers at
boot:
disable acpi
disable acpitz
disable acpitz
t;bios0: vendor American Megatrends International, LLC. version "JK4LV107" date
>>04/17/2023
>
> I just found this Reddit Post [0], describing a related issue with this
> kind of board. There's also a download link [1] in the comments for the
> bios update. As soon as I found some
describing a related issue with this
kind of board. There's also a download link [1] in the comments for the
bios update. As soon as I found some time I will install the update.
Thanks!
That one works on my machine, with exactly the same config as yours. No
more ACPI GPE storm.
I don't h
"techvision" bios (like yours) exhibit this issue.
Mine had techvision bios (and the same problem) before I flashed it to the
image described below.
You need to find this bios:
bios0: vendor American Megatrends International, LLC. version "JK4LV107" date
04/17/2023
That one works o
trends rev 0x50013
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT
SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SPCR TPM2 WSMT FPDT
acpi0: wakeup devices PEGP(S3) PEGP(S3) PEGP(S3) PEGP(S3) PS2K(S3)
PS2M(S3) RP01(S
09/16/2022
bios0: Techvision TVI7309X
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x50013
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT
SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SPCR TPM2 WSMT FPDT
acp
On Mon, Jun 19, 2023 at 08:55:10AM +0300, S V wrote:
> Hello, list!
>
> Is it possible to load custom acpi table on boot ?
>
> in FreeBSD it was possible by strings in conf like
>
> acpi_dsdt_load="YES" acpi_dsdt_name="filename.aml"
no
Hello, list!
Is it possible to load custom acpi table on boot ?
in FreeBSD it was possible by strings in conf like
acpi_dsdt_load="YES" acpi_dsdt_name="filename.aml"
From: owner-m...@openbsd.org on behalf of Jeff Roach
Sent: Monday, 23 January 2023 9:08 PM
To: misc@openbsd.org
Subject: Panic in 7.2 and snapshots at boot due to acpi bios error
Hi! Really love OpenBSD and would like to get it working on my Samsung
Galaxy Book Flex2 Alpha. NP730QDA
in the acpi bios code for which there is no
firmware update. It boots, linux, win 10/11, net and freebsds fine with
acpi errors. I tried to disable acpi to see if I could get it installed
and the installer ran but could not find the ethernet, wifi or ssd.
Can anyone help with this? I'd be glad
Mike Larkin wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS
On Wed, Sep 29, 2021 at 06:29:08PM -0700, Mike Larkin wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine
On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> slowdown on my T480. Previously, I experienced slowdown after power cycling
> my machine occasionally. Currently, with this BIOS setting enabled, I
>
After enabling "BIOS Thunderbolt Assist", I experience consistent
machine slowdown on my T480. Previously, I experienced slowdown after
power cycling my machine occasionally. Currently, with this BIOS setting
enabled, I experience slowdown consistently.
I am sorry but I don't know enough
Another T480 user who has noticed the same problem. Per advice given,
I've just enabled "BIOS Thunderbolt Assist". I will report back if I
notice the problem persists.
On 9/19/21 4:50 AM, Daniel Wilkins wrote:
I've ran into this on my T480, it seems most consistently triggered by power
cycles
On Wed, Sep 29, 2021 at 11:47:34AM -0600, Theo de Raadt wrote:
> It would be great if someone figures out why "BIOS Thunderbolt Assist"
> disable, causes a pin to get stuck on resume, and/or figures out how we
> can recognize to handle/clear the event.
The detail in my BIOS options specifically
Hi,
On 2021-09-28 14>18>49, Daniel Wilkins wrote
> All you have to do is go into your bios' settings and turn on
> "BIOS Thunderbolt Assist" then everything will work 100% fine.
>
> Thanks to jcs on IRC for pointing me at that (dunno what his
> email is.)
Success! With this (and the 7.0
Jonathan Thornburg wrote:
> On 2021-09-28 14>18>49, Daniel Wilkins wrote
> > All you have to do is go into your bios' settings and turn on
> > "BIOS Thunderbolt Assist" then everything will work 100% fine.
> >
> > Thanks to jcs on IRC for pointing me at that (dunno what his
> > email is.)
>
>
On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote:
> There are a few people who have experience with this. Maybe one of
> them will mail you privately.
>
I'm glad this thread suddenly got revived, since I tried to find it
in my backlog but it got lost.
All you have to do is go into
= 16231878656 (15479MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa86db000 (62 entries)
bios0: vendor LENOVO version "N27ET43W (1.29 )" date 08/13/2021
bios0: LENOVO 20L9001GUS
acpi0 at bios0:
On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote:
> the term "runaway ACPI" is not the best. What is probably happening
> is a stuck interrupt.
>
> We continue to fight these. Some of them are BIOS bugs, some are
> undocumented behaviours, sometimes AM
> bios0: vendor LENOVO version "N27ET43W (1.29 )" date 08/13/2021
> bios0: LENOVO 20L9001GUS
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
On the other hand, your BIOS is very new. So new that it has S0.
These days Microsoft is only testing S0.
Lenovo
BTW, BIOS update has fixed interrupts issues like this in a surprising
number of cases. No promises, tho.
Jonathan Thornburg wrote:
> After more experimentation, I find that the runaway ACPI process occurs
> every time I suspend/resume (Fn-backspace). (The system resumes fine
> a
the term "runaway ACPI" is not the best. What is probably happening
is a stuck interrupt.
We continue to fight these. Some of them are BIOS bugs, some are
undocumented behaviours, sometimes AML parse errors in setting things
up, and potentially a few are due to incorrect resume
After more experimentation, I find that the runaway ACPI process occurs
every time I suspend/resume (Fn-backspace). (The system resumes fine
apart from the runaway ACPI process.)
Is there any to kill or reset the kernel ACPI process short of rebooting?
/ps/ doen't see it, and /pkill/ (even
I dunno if this is helpful, but I just unplugged my thinkpad and triggered the
behavior.
ACPI shot right up, and in this case the "charging" LED has stayed on. I've
never triggered
it by unplugging before, but the symptoms are the same. The system was under
some load while
doing so
I wrote
> During the installation (both in the bsd.rd install script and previously
> when I dropped into the bsd.rd shell to set up softraid-crypto) the machine
> acted incredibly slow, and there was a several-second delay in echoing
> typed characters. I suspected that it was some device
I've ran into this on my T480, it seems most consistently triggered by power
cycles caused by running out of battery. The bug's existed for quite a few
years (I think I first noticed it in 2019.) If I recall correctly I've
posted it to the list a couple of times but I don't think any concrete
nite-loop problem does not occur.
As I noted above, suspend-to-RAM (via Fn-Backspace, which is the key
combination marked with the usual Thinkpad "moon" icon) "just works".
Is this sort of acpi (?) runaway a known T580 problem? Neither google
nor the nycbug.org dmesg archive sho
The missing 256 MB memory is probably stolen by the onboard video; it
may be possible to reduce this to a smaller amount via a BIOS setting.
You might also try fiddling with any available ACPI settings, e.g.
sleep states, etc. (IIRC my VIA Epia M had a setting for whether
"sleep" mean
On Mon, 28 Dec 2020 13:20:29 -0500
Ian Darwin wrote:
> Boot used Kernel FromResult
> pxeboot bsd.rd tftpOK
> pxeboot bsd hd0aOK (via
> tftpboot/etc/conf) boot bsd
> hd0a panic
>
> I.e.,
e for use), while
type 1 (and generally 3) can be used by the bootloader or kernel.
> Thx for looking.
No problem, it's interesting that pxeboot actually has less memory
below 1Meg compared to normal /boot, but I guess that makes sense
in that environmnet.
But curious to hear from peo
0x0x for 631KB
Region 1: Type 2 at 0x9dc99 for 9KB
Region 2: type 2 at 0xe for 128kb
(remainder the same)
Could Region 1 being so microscopic cause problems? If it got used for anything?
Thx for looking.
> > Full dmesg below; full ACPI attached.
> >
> > Boot used
> RAM: 1GB (despite reported as 3/4 of that)
Long shot, but could you maybe show the output of "machine memory" for
both boot/pxeboot? I'm curious if the memory map is reportedly
differently between a working boot and a bad one.
-Bryan.
> Full dmesg below; full ACPI attached.
&g
e, so tiny is fine.
"Latest" BIOS (2012 edition). "BIOS reset" did not help.
cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz,
06-0d-00
RAM: 1GB (despite reported as 3/4 of that)
Full dmesg below; full ACPI attached.
Boot used
ends Inc. version "1701" date 11/18/2016
bios0: ASUSTeK Computer INC. M5A78L-M LX V2
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) RLAN(S4) PCE5(S4)
PCE6(S4) PCE7(S4) PCE9(S4) PC
Date: 8 Dec 2020, 14:35
From: tru...@tutanota.com
To: misc@openbsd.org
Subject: OT acpi failure
> hallo list,
>
> my machine had one of the ahci failures after which it very fast went
> stiff (just the caps and num locks did light on/off if appropriate keys
> got pressed). &q
s0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (52 entries)
bios0: vendor American Megatrends Inc. version "1701" date 11/18/2016
bios0: ASUSTeK Computer INC. M5A78L-M LX V2
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SS
Hi all,
error related to ACPI follows after dmesg. I can provide pcidump,
usbdevs or acpidump too if needed.
In general machine seems to be working fine (booted from USB flash in
USB 3.1 port). WiFi and LAN
works great in trunk setup, 3D on Intel VGA and X11 works.
dmesg and sensors send
was from
using acpi to msi for the device. Also that the on board NIC is no
longer seen under 6.8. The re device is seen by find but doesn't appear
from the boot process, either taken out by disabling azalia or a
separate problem. (I stuck a usb wifi dongle on the box to finish the
upgrade
ote:
>
> > I'm trying to permanently disable acpi doing the following steps[1].
> > After the first reboot OS boots fine.
> > After the second reboot acpi seems to be re-enabled at boot - I get [2].
> > What Am I doing wrong?
> >
>
> First, you should also c
On Mon, Dec 23, 2019 at 5:10 AM Radek wrote:
> I'm trying to permanently disable acpi doing the following steps[1].
> After the first reboot OS boots fine.
> After the second reboot acpi seems to be re-enabled at boot - I get [2].
> What Am I doing wrong?
>
First, you should als
Hello,
I'm trying to permanently disable acpi doing the following steps[1].
After the first reboot OS boots fine.
After the second reboot acpi seems to be re-enabled at boot - I get [2].
What Am I doing wrong?
[1]
boot -c
UKC>disable acpi
444 acpi0 disabled
UKC>quit
Continuing...
[...]
m
to avoid the problem by disabling acpi
in UKC. Naturally this makes the machine unable to sleep. I tried to
collect some obvious things, but happy to produce more upon request.
The contents of
cp -R /var/db/acpi /tmp && iasl -d /tmp/acpi/*
are here: https://blackgnezdo.github.io/hp-elitebook
it works, (did not in 6.4 )
who s the awesome fellow who did that
Thank you
--
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do
Hi all,
The PC Engines APU2/3/4 mainline firmware was updated this week and
they've enabled ACPI GPIO calls as well as IOMMU support. I saw tech@
got a patch for apugpio in March, maybe it could be updated to use ACPI?
Link to firmware is here:
https://pcengines.github.io/?utm_source=PC
On Mon, Mar 04, 2019 at 06:44:15PM -0700, Theo de Raadt wrote:
> Z Ero wrote:
>
> > Hello,
> >
> > Curious if there is a facility to save system memory state to disk for
> > recovery such as is done the ZZZ (hibernate) command without actually
> > powering down? Could be useful to return to a
Z Ero wrote:
> Hello,
>
> Curious if there is a facility to save system memory state to disk for
> recovery such as is done the ZZZ (hibernate) command without actually
> powering down? Could be useful to return to a previous active memory
> state for devices that are not on UPS or not closely
On Mon, Mar 04, 2019 at 07:06:15PM -0500, Z Ero wrote:
> Hello,
>
> Curious if there is a facility to save system memory state to disk for
> recovery such as is done the ZZZ (hibernate) command without actually
> powering down? Could be useful to return to a previous active memory
> state for
Hello,
Curious if there is a facility to save system memory state to disk for
recovery such as is done the ZZZ (hibernate) command without actually
powering down? Could be useful to return to a previous active memory
state for devices that are not on UPS or not closely monitored but do
preform
On Tue, May 01, 2018 at 03:37:50AM -0400, Ryan Lennox wrote:
If it's the same bug, you should find something like this block
of code in the file /tmp/acpi/DSDT.dsl
...
If ((TBTS == 0x01))
{
Acquire (OSUM, 0x)
\_GPE.TINI (TBSE
_add acpica
$ cp -R /var/db/acpi /tmp
$ iasl -d /tmp/acpi/*
If it's the same bug, you should find something like this block
of code in the file /tmp/acpi/DSDT.dsl
...
If ((TBTS == 0x01))
{
Acquire (OSUM, 0x)
\_GPE.TINI (TBSE)
Hi,
Just want to add the X1 Carbon Gen 6th to the list. Same problem when
plug in a thunderbolt device.
Apart from that, the other thing is that S3 (suspend to ram) mode is not
supported by the BIOS (it has a special S0i3 mode instead which is
exclusive with the S3 mode).
Hi,
I encountered the same issue on a new T480s as reported here:
https://marc.info/?l=openbsd-bugs=152022260714390=2
I am posting this to misc because the bug appears to be with Lenovo's ACPI
tables, not OpenBSD. I just wanted to provide some updated information for
anyone else who has
I use an Asus X205TA, which is an irritating system with an I2C HID
keyboard. As of revision 1.18 of sys/dev/acpi/dwiic.c, I have been
unable to upgrade to the latest snapshots as said keyboard fails to
attach during boot.
The following patch appears to resolve the problem. Also included
On Fri, Aug 14, 2015 at 03:13:17PM +0200, Frederic URBAN wrote:
Hello,
We have some ACPI problems with various IBM server X. Since it's a very
early panic when kernel boot there is now access to ddb to print the
trace. You are prompted to press any key to reboot :) It has been
verified
Frederic URBAN frederic.urban at ircad.fr writes:
We have some ACPI problems with various IBM server X. Since it's a very
early panic when kernel boot there is now access to ddb to print the
trace. You are prompted to press any key to reboot :) It has been
verified on IBM Server x3650 M1
Hello,
We have some ACPI problems with various IBM server X. Since it's a very
early panic when kernel boot there is now access to ddb to print the
trace. You are prompted to press any key to reboot :) It has been
verified on IBM Server x3650 M1, M2 and M3. We are using OpenBSD 5.7
On Mon, Jun 15, 2015 at 11:17:04PM +0200, Riccardo Mottola wrote:
Hi,
on my HP laptop (dmesg below) I notice that both with acpi and with apm,
it is always reported that the power adapter is connected, even if it is
not. The power level of the battery seems reasonable.
Can you send
Hi,
on my HP laptop (dmesg below) I notice that both with acpi and with apm,
it is always reported that the power adapter is connected, even if it is
not. The power level of the battery seems reasonable.
With power cord attached:
hw.sensors.acpitz0.temp0=56.00 degC (zone temperature
On Sun, Mar 29, 2015 at 11:55:49AM +0400, Denis Lapshin wrote:
Since 4.9 till current 8510p/w read acpi temp with error (enormous
high temp about 2000-5000 C) because SMBus data is not ready for
reading. It seems data reading should be delayed.
I thought we(I) fixed this last year. If you
ACPI tables of this machine properly.
No idea about 6005, but there are Dell 5220/6100/6220 (and some lenovo
and supermicro) with aspeed chips that work.
Beyond that: either ask the vendor to test, or buy one and if it doesn't
work you could either try and collect enough information to allow people
Since 4.9 till current 8510p/w read acpi temp with error (enormous high
temp about 2000-5000 C) because SMBus data is not ready for reading. It
seems data reading should be delayed.
Theo, you told that you don't want to implement shit in CVS
repository. Most of ACPI code should be rewritten
Since 4.9 till current 8510p/w read acpi temp with error (enormous high
temp about 2000-5000 C) because SMBus data is not ready for reading. It
seems data reading should be delayed.
Theo, you told that you don't want to implement shit in CVS
repository. Most of ACPI code should be rewritten
On 2015/03/29 11:55, Denis Lapshin wrote:
Since 4.9 till current 8510p/w read acpi temp with error (enormous high temp
about 2000-5000 C) because SMBus data is not ready for reading. It seems
data reading should be delayed.
Theo, you told that you don't want to implement shit in CVS
The machine is DCS6005. This is an old Dell branded AMD based server
node. They named it as Cloud Server Node or something like that. It
has AST2050 installed. I would like to buy some for a project, but not
sure that OpenBSD support ACPI tables of this machine properly.
Because of negative
replied
that the patch will not be implemented in CVS because all ACPI must be
rewritten in new manner. But they will do nothing since my last report...
All the troubles the same as four years ago. Only the patch can be
implemented to read ACPI data on HP 8510p properly during boot, no CVS
Every release I need to apply a patch after upgrade for reading ACPII
data from 8510p in time, to prevent wrong data on SMBUS. Theo replied
that the patch will not be implemented in CVS because all ACPI must be
rewritten in new manner. But they will do nothing since my last report...
I doubt I
On 2015-03-28, Denis Lapshin den...@mindall.org wrote:
Hi,
Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release?
The question doesn't really make sense, ACPI is a method where the
manufacturer can supply a set of BIOS tables with instructions about
how to route interrupts
Hi,
Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release?
This IC is present in some Dell branded Tyan products like DCS6005 cloud
nodes and some other Tyan MBs. Seems Aspeed its their own product
because these ICs can be found on all Tyan server mainboards as I can see
Hi all,
I want to give batmon.app ACPI support on OpenBSD.
This is what I get on my Thinkpad T60:
$ sysctl | grep acpibat
hw.sensors.acpibat0.volt0=10.80 VDC (voltage)
hw.sensors.acpibat0.volt1=12.41 VDC (current voltage)
hw.sensors.acpibat0.power0=0.00 W (rate)
hw.sensors.acpibat0.watthour0
.
Anyone hit this issue before and can advise on the matter?
Thanks,
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
What version of OpenBSD? We fixed this in April.
I can also verify that in at least one of my vms (current / i386 / SP)
acpi shutdown now works
Hello,
I'm having an issue with my OpenBSD cloud instance in that it completely
ignores the signals sent to it by qemu-kvm, so instead of getting shut down or
rebooted gracefully it has to be reset.
Anyone hit this issue before and can advise on the matter?
Thanks,
Lucian
--
Sent from the
On 13-10-2014 15:42, Nux! wrote:
I'm having an issue with my OpenBSD cloud instance in that it completely
ignores the signals sent to it by qemu-kvm, so instead of getting shut down or
rebooted gracefully it has to be reset.
Anyone hit this issue before and can advise on the matter?
Yes, this is
On Mon, Oct 13, 2014 at 07:42:34PM +0100, Nux! wrote:
Hello,
I'm having an issue with my OpenBSD cloud instance in that it completely
ignores the signals sent to it by qemu-kvm, so instead of getting shut down
or rebooted gracefully it has to be reset.
Anyone hit this issue before and can
On Mon, Oct 13, 2014 at 03:51:45PM -0300, Giancarlo Razzolini wrote:
On 13-10-2014 15:42, Nux! wrote:
I'm having an issue with my OpenBSD cloud instance in that it completely
ignores the signals sent to it by qemu-kvm, so instead of getting shut down or
rebooted gracefully it has to be reset.
On 13-10-2014 16:50, Mike Larkin wrote:
You are smoking some serious crack there.
This is the only thing that works for me on all my OpenBSD virtualized
installations. And I'm running 5.5 stable on all of them. I can't really
speak for 5.6, since I don't run current on my production systems. So
On Mon, Oct 13, 2014 at 07:02:36PM -0300, Giancarlo Razzolini wrote:
On 13-10-2014 16:50, Mike Larkin wrote:
You are smoking some serious crack there.
This is the only thing that works for me on all my OpenBSD virtualized
installations. And I'm running 5.5 stable on all of them. I can't
On 13-10-2014 19:12, Mike Larkin wrote:
isabling random parts of the kernel without understanding what you are
doing
is certainly smoking crack. I doubt you heard disable mpbios as a valid
solution from any OpenBSD developer.
No I didn't. I found it on a very old article, refering to OpenBSD
...@gmail.com
To: Nux! n...@li.nux.ro, misc@openbsd.org
Sent: Monday, 13 October, 2014 19:51:45
Subject: Re: shutdown/reboot on acpi/qemu signals
On 13-10-2014 15:42, Nux! wrote:
I'm having an issue with my OpenBSD cloud instance in that it completely
ignores
the signals sent to it by qemu-kvm
On 13-10-2014 19:56, Nux! wrote:
Thanks, but for me it did not work, the guest fails to boot after this
change.
I'll wait for 5.6 for more serious work on KVM.
Which kernel you're using? The bsd or the bsd.mp? Which message appear
on the boot? Which linux/qemu-kvm version?
Cheers
[demime 1.01d
On 13-10-2014 19:56, Nux! wrote:
Thanks, but for me it did not work, the guest fails to boot after this
change.
I'll wait for 5.6 for more serious work on KVM.
Which kernel you're using? The bsd or the bsd.mp? Which message appear
on the boot? Which linux/qemu-kvm version?
Why -- do you
Hi,
Running the install56.fs from an usb key give me the following error :
http://pbrd.co/1rWT1Us
So i disabled acpi using UKC to be able to install :
http://pbrd.co/1rWUqL0
OpenBSD is installed now, but running it with acpi support give me a
kernel panic :
http://pbrd.co/1rWTCFX
trace
On Wed, Aug 20, 2014 at 12:34:24PM +0400, Wesley MOUEDINE ASSABY wrote:
Hi,
Running the install56.fs from an usb key give me the following error :
http://pbrd.co/1rWT1Us
So i disabled acpi using UKC to be able to install :
http://pbrd.co/1rWUqL0
OpenBSD is installed now, but running
On 20.08.2014 19:27, Mike Larkin wrote:
On Wed, Aug 20, 2014 at 12:34:24PM +0400, Wesley MOUEDINE ASSABY
wrote:
Hi,
Running the install56.fs from an usb key give me the following error
:
http://pbrd.co/1rWT1Us
So i disabled acpi using UKC to be able to install :
http://pbrd.co/1rWUqL0
:
:So i disabled acpi using UKC to be able to install :
:http://pbrd.co/1rWUqL0
:
:OpenBSD is installed now, but running it with acpi support give me a
:kernel panic :
:http://pbrd.co/1rWTCFX
:
:trace :
:http://pbrd.co/1rWTKVS
:http://pbrd.co/1rWTUws
:
:and ps :
:http://pbrd.co/1rWU1bl
:
:So you expect
disabled acpi using UKC to be able to install :
http://pbrd.co/1rWUqL0
OpenBSD is installed now, but running it with acpi support give me a
kernel panic :
http://pbrd.co/1rWTCFX
trace :
http://pbrd.co/1rWTKVS
http://pbrd.co/1rWTUws
and ps :
http://pbrd.co/1rWU1bl
So you expect us
How can i get the acpidump if there 's no ddb prompt ? :)
man acpidump
Reading FAQ, there's no acpidump informations...the same for acpi(4)
I will post the dump. Thank you very much.
What would your mechanic say if you took your car to the garage
and said
My engine is making a strange
I can also confirm that newest snapshot works now.
On Thu, Jun 26, 2014 at 7:45 AM, Nils R m...@hxgn.net wrote:
Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!
I know on my laptop no acpi meant doesn't work. My saving grace is I
always keep a kernel from the previous snapshot I tried as obsd. So if
bsd doesn't work, I just boot from that. Do you have an older snapshot
kernel you can tell tech support to boot into?
On Thu, Jun 26, 2014 at 7:36 PM, Scott
Unfortunately, not. It was a fresh install from a CD image to a hard
drive which I then shipped to the ISP for installation, which replaced a
failing drive in my machine co-located there.
In any event, bypassing acpi in ukc got the machine up again, and I was
able to upgrade to the latest
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.
I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years or so - servers, laptops, standard PCs
to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.
I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years or so - servers, laptops
the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.
I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years
might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.
I think you should consider ACPI essential on pretty
whether something like
ukc disable acpi0
might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.
I think you should
circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.
I think you should consider ACPI essential on pretty much any x86
Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!
1 - 100 of 524 matches
Mail list logo
