Hi
I just installed -current #75 and I can't enable xenodm because the system
panics 90% of the time. I'm including below basic info and pictures of
messages - any pointing to the right direction would be welcomed.
Images of error messages:
https://1drv.ms/u/s!Al64DwRfhnFCas821xILYsNzEuk?e=XKUC3H
On Thu, May 27, 2021 at 07:57:28AM +0200, Harald Dunkel wrote:
> On 5/17/21 12:27 AM, Antonino Sidoti wrote:
> > Hi,
> >
> > I also have this issue on a fresh install of 6.9 amd64. I reported it as a
> > bug last week to “bugs” mail list with all appropriate information. I can
> > confirm that p
On 5/17/21 12:27 AM, Antonino Sidoti wrote:
Hi,
I also have this issue on a fresh install of 6.9 amd64. I reported it as a bug
last week to “bugs” mail list with all appropriate information. I can confirm
that plugging in a monitor will allow my system to boot. I did not have the 001
patch in
iprt3 at acpi0: bus 3 (RP03)
>> acpiprt4 at acpi0: bus 4 (RP04)
>> acpiec0 at acpi0: not present
>> acpicmos0 at acpi0
>> acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
>> "INTCF1C" at acpi0 not configured
>> acpibtn0 at acpi0: SLPB
>
uot;Intel Braswell AHCI" rev 0x35: msi, AHCI
> 1.3.1
> ahci0: PHY offline on port 0
> ahci0: port 1: 3.0Gb/s
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 1 lun 0:
> naa.5000cca532c0fb69
> sd0: 190782MB, 512 bytes/sector, 390721968 sectors
> xhci0 at pci0 dev
Hi folks,
after installing syspatch 001 the reboot showed:
:
scsibus3 at softraid0: 256 targets
root on sd0a (614daaae133f0ac5.a) swap on sd0b dump on sd0b
uvm_fault(0x82186300, 0xb8, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at i915_ggtt_pin+0x29: movq0xb8(%
address
00:60:e0:66:70:93
ppb7 at pci5 dev 3 function 0 "Pericom PI7C9X2G404EL PCIE" rev 0x05: msi
pci8 at ppb7 bus 8
em5 at pci8 dev 0 function 0 "Intel I211" rev 0x03: msi, address
00:60:e0:66:70:94
pcib0 at pci0 dev 31 function 0 "Intel Braswell PCU LPC" rev 0x35
ic
PS: The next power cycle went fine, see attachment.
Regards
Harri
boot>
NOTE: random seed is being reused.
booting hd0a:/bsd: 14415144+3220488+34+0+1171456
[1008375+128+1145856+866050]=0x1526a80
entry point at 0x81001000
[ using 3021440 bytes of bsd ELF symbol table ]
Copyright (c)
ntel Braswell SMBus" rev 0x35: apic 1 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 SO-DIMM
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3:
there for AHCI errors.
Maybe it is worth to mention, that the original RAID tests on Debian
buster with six of 512GB Samsung PRO 860 (the same drives andf RAID6 set
with mdadm) worked without crashing the OS.
Kind regards
Mark
bs=10M count=1024
# Error messages
uvm_fault(0x821f54
On Tue, Mar 02, 2021 at 09:39:15AM +, Stuart Henderson wrote:
> putting sr_validate_io+0x44 at the xs->datalen dereference,
>
> 4580 if (sd->sd_vol_status == BIOC_SVOFFLINE) {
> 4581 DNPRINTF(SR_D_DIS, "%s: %s device offline\n",
> 4582 DEVNAME(sd->sd
n? Are the drives reliable with
this hardware configuration when not using softraid? I guess it would
need testing with simultaneous writes to the 3 drives to give a closer
match to the situation with softraid.
> > > bs=10M count=1024
> > >
> > > # Error messages
>
.00s user 0m08.14s system
# Working as expected
^^
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/10GB-urandom.bin
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap,
alled three new 1TB Samsung PRO 960 SSD drives inside a
third box (however also an ASUS mainboard with AMD FX CPU and 16GB ECC
RAM) and set RAID5 as described in the attached file.
And again a similar error after dd (slightly different values):
# ---
dd if=/dev/urandom of=/arc-3xssd/1GB-urandom.bin
GB-urandom.bin bs=1M count=1024
# Error messages
uvm_fault(0x821ede50, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{4}>
The error happens on the RAID5 level (there is no encryption).
In the test case above I use
Maybe some I/O error is happening in your case as well?
Perhaps the raid5 code doesn't handle i/o errors gracefully?
In any case, your bug report is missing important information:
> > # Error messages
> >
> > uvm_fault(0x821f5490, 0x40, 0, 1) -> e
> > kerne
ected
^^
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/10GB-urandom.bin
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{2}>
bytes/sec)
0m08.13s real 0m00.00s user 0m08.14s system
# Working as expected
^^
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/10GB-urandom.bin
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1
t;
> Todays current Kernel is crashing directly after the boot.
> Keyboard, IPMI is not working.
>
> all kernel > #109 are crashing here.
>
>>> uvm_fault (0x81da40f8, 0xe4, 0, 2) -> e
>>> kernel: page fault trap,code=0
>>> Stopped at pfi_kif_ref
board, IPMI is not working.
all kernel > #109 are crashing here.
>> uvm_fault (0x81da40f8, 0xe4, 0, 2) -> e
>> kernel: page fault trap,code=0
>> Stopped at pfi_kif_ref +0x3f: addl $0x1,0xe4(%rdi)
With GENERIC.MP#118 amd64 the problem still exists.
ssh let the system crash.
> after sysupgrade to yesterday's and also today's snapshot, I get after
> login or ssh:
>
> uvm_fault (0x81da40f8, 0xe4, 0, 2) -> e
> kernel: page fault trap,code=0
> Sto
Hello misc,
after sysupgrade to yesterday's and also today's snapshot, I get after
login or ssh:
uvm_fault (0x81da40f8, 0xe4, 0, 2) -> e
kernal: page fault trap,code=0
Stopped at pfi_kif_ref +0x3f: addl $0x1,0xe4(%rdi)
Roll back to Kernel 6.5 GENERIC.MP#109 amd64 sol
Hello,
I've recently performed an install of i386 OpenBSD 6.4 on a HP T5740
thin client (Atom N280, 2GB DDR3, 2GB FLASH, more info on
parkytowers.me.uk) and I keep running into uvm_fault errors at xenodm
startup when booting. At this point the whole computer freeyes, even
ddb prompt appe
d (and I lost the data for yet another workout)
Here's a partial transcript:
uvm_fault(0xd6bfac8c, 0x4e000, 0, 1) -> e
page fault trap, code=0
Stopped at usb_allocmem+0x15d: cmpl %ebx,0(%eax)
usb_allocmem() at usb_allocmem+0x15d
usbd_transfer +0x6a
usbd_do_request_flags
usbd_do
s, that's the expected behavior.
-ml
> - Oorspronkelijk bericht -
>
> Van: "Mike Larkin"
> Aan: "Erwin van Maanen"
> Cc: misc@openbsd.org
> Verzonden: Zondag 6 december 2015 19:12:18
> Onderwerp: Re: vmm uvm_fault in vmware player/works
n"
Cc: misc@openbsd.org
Verzonden: Zondag 6 december 2015 19:12:18
Onderwerp: Re: vmm uvm_fault in vmware player/workstation when Intel VT/AMD-v
not enabled
On Sun, Dec 06, 2015 at 10:02:50AM -0800, Mike Larkin wrote:
> On Tue, Nov 24, 2015 at 11:02:30PM +0100, Erwin van Maanen wrote:
And when enabling it, i forget to enabled "Virtualize Intel VT-x/EPT or
> > AMD-V/RVI" option in VMWare workstation an i get an uvm_fault:
> >
> > uvm_fault(0xff007f549f00, 0x60, 0, 1) -> e
> > kernel: page fault trap, code=0
> > Stopped at
V/RVI" option in VMWare workstation an i get an uvm_fault:
>
> uvm_fault(0xff007f549f00, 0x60, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at vmmioctl+0x18: movl 0x60(%rcx),%r8d
> ddb{3}>
>
> After enabling "Virtualize Intel VT-x/EPT or AMD-V/R
V/RVI" option in VMWare workstation an i get an uvm_fault:
>
> uvm_fault(0xff007f549f00, 0x60, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at vmmioctl+0x18: movl 0x60(%rcx),%r8d
> ddb{3}>
>
> After enabling "Virtualize Intel VT-x/EPT or AMD-V/R
Hello Misc,
I was playing around with the new vmm in the bsd snapshot of Nov 23 under
VMWare Workstation.
And when enabling it, i forget to enabled "Virtualize Intel VT-x/EPT or
AMD-V/RVI" option in VMWare workstation an i get an uvm_fault:
uvm_fault(0xff007f549f00, 0x60,
Hi,
I have a problem with my GPU. When I run command startx:
uvm_fault(0xfe823cb0c468, 0x278, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at radeon_vm_bo_add+0xaa: movq 0x278(%r15), %rax
My dmesg:
http://wklej.org/id/1349083/
http://krzy.ch/dmesg
OpenBSD 5.5 (GENERIC.MP) #315:
Hi,
It happened again with another machine, a R420, also running 5.4-stable. I
can reproduce the problem giving a sequence of bioctl mfi0 commands:
(Please, do not try this on production servers)
# for foo in `jot 1000`; do bioctl mfi0; sleep 1; done
The kernel panics with:
uvm_fault
Hey guys,
I have just upgraded two Dell servers (a PowerEdge R410 and a R320) to
OpenBSD 5.4-stable -- before the upgrade, these machines were running
5.3-stable without a problem.
After the upgrade to 5.4, both machines started to panic with a uvm_fault.
(3 panics so far...) The panic messages
On Sat, Nov 23, 2013 at 05:14:17PM +1000, David Gwynne wrote:
> hey josh,
>
> this should be fixed in src/sys/dev/pci/if_athn_pci.c r1.13.
Thank you, that fixed it!
-J-
uspend/resume
> will produce a uvm_fault on resume. I cannot reproduce the panic if I
> revert
> to revision 1.11.
>
> Of note: ddb(4) produces a brief traceback and a prompt but is inoperative.
> I am unable to get a dump if ddb.panic=0. This traceback was transposed
> by han
Summary: with src/sys/dev/pci/if_athn_pci.c at revision 1.12, suspend/resume
will produce a uvm_fault on resume. I cannot reproduce the panic if I revert
to revision 1.11.
Of note: ddb(4) produces a brief traceback and a prompt but is inoperative.
I am unable to get a dump if ddb.panic=0
On Fri, Nov 8, 2013 at 7:08 AM, Wiesław Kielas
wrote:
> I'm having problems with my HP ProLiant DL140 box running 5.3. About
> once every week or two the machine crashes to ddb with the following
> message:
>
>> uvm_fault(0xfe807711e1d8, 0x7fbfbe38, 0, 1) -> e
Dear misc@,
I'm having problems with my HP ProLiant DL140 box running 5.3. About
once every week or two the machine crashes to ddb with the following
message:
> uvm_fault(0xfe807711e1d8, 0x7fbfbe38, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at pmap_enter+0
Hi,
> After upgrading my AMD64-current installation to the latest snapshot it
> crashes on boot with an uvm_fault.
With the latest snapshot the problem has vanished.
Kind regards,
Martijn Rijkeboer
Hi Otto,
>> dmesg from an older kernel that does work :)
> Or boot with -c, and disable fxp
Thanks, that worked.
Kind regards,
Martijn Rijkeboer
Hi Ariane,
> dmesg from an older kernel that does work :)
Below is the dmesg from the kernel with fxp disabled (thanks Otto).
OpenBSD 5.1-current (GENERIC.MP) #248: Wed Mar 28 21:46:36 MDT 2012
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2146369536 (2046MB
On Fri, Mar 30, 2012 at 11:37:21PM +0200, Ariane van der Steldt wrote:
> On Fri, Mar 30, 2012 at 10:07:01PM +0200, Martijn Rijkeboer wrote:
> > > Please supply a trace, dmesg and the output of ps (on ddb, type
> > > 'trace' for the trace, and 'ps' for the
On Fri, Mar 30, 2012 at 10:07:01PM +0200, Martijn Rijkeboer wrote:
> > Please supply a trace, dmesg and the output of ps (on ddb, type
> > 'trace' for the trace, and 'ps' for the ps output.
> >
> > The uvm_fault is a null-pointer exception. We need the
Hi Ariane,
> Please supply a trace, dmesg and the output of ps (on ddb, type
> 'trace' for the trace, and 'ps' for the ps output.
>
> The uvm_fault is a null-pointer exception. We need the trace and ps to
> diagnose where the fault occured.
Below are th
Ariane van der Steldt [ari...@stack.nl] wrote:
> On Fri, Mar 30, 2012 at 08:42:43PM +0200, Martijn Rijkeboer wrote:
> > After upgrading my AMD64-current installation to the latest snapshot it
> > crashes on boot with an uvm_fault.
> >
> > Message:
> >
>
On Fri, Mar 30, 2012 at 08:42:43PM +0200, Martijn Rijkeboer wrote:
> After upgrading my AMD64-current installation to the latest snapshot it
> crashes on boot with an uvm_fault.
>
> Message:
>
> starting network
> uvm_fault(0xfe807f4032a0, 0x0, 0, 1) -> e
>
Hi,
After upgrading my AMD64-current installation to the latest snapshot it
crashes on boot with an uvm_fault.
Message:
starting network
uvm_fault(0xfe807f4032a0, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
stopped atfxp_load_ucode+0x8a:movzwl0x2(%rbx),eax
dd
the current firewall is running I cannot fully boot. If I press CTRL+C
> > | during the starting network section it will continue to boot. If I
> > | then run pfctl -e it states that PF is already enabled enabled but if
> > | I run pfctl -Fr -f /etc/pf.conf I get the following.
>
ates that PF is already enabled enabled but if
> | I run pfctl -Fr -f /etc/pf.conf I get the following.
> |
> | # uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
> | kernel: page fault trap, code=0
> | Stopped at pf_translate+0x154: cmpw %r13w,0(%rsi)
> | ddb{0}>
> |
>
fully boot. If I press CTRL+C
| during the starting network section it will continue to boot. If I
| then run pfctl -e it states that PF is already enabled enabled but if
| I run pfctl -Fr -f /etc/pf.conf I get the following.
|
| # uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
| kernel: page
ork
section it will continue to boot. If I then run pfctl -e it states that PF is
already enabled enabled but if I run pfctl -Fr -f /etc/pf.conf I get the
following.
# uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at pf_translate+0x154: cmpw %r13w,0(%rsi)
On Thu Dec 15 2011 11:31, co...@tetrachina.com wrote:
> Hi,
>
> OpenBSD 4.1 as firewall crashed sometimes recently everyday ,and the
> debug messages are like that:
>
> uvm_fault ( 0xe33d7ea0,0x0,0,3) -> e
> kernel:page fault trap,code=0
> stopped at pipe_crea
On Thu, 15 Dec 2011 11:31:40 +0800, "co...@tetrachina.com"
wrote:
> Hi,
>
> OpenBSD 4.1 as firewall crashed sometimes recently everyday ,and the
> debug messages are like that:
>
> uvm_fault ( 0xe33d7ea0,0x0,0,3) -> e
> kernel:page fault trap,cod
> debug messages are like that:
>
> uvm_fault ( 0xe33d7ea0,0x0,0,3) -> e
> kernel:page fault trap,code=0
> stopped at pipe_create+ 0x16: Mov1 $0,0x10(%ebx)
> ddb>
>
> anyone could tell me how to solve it .thanks in advance.
--
There are only three sports: bullfighting,
Hi,
OpenBSD 4.1 as firewall crashed sometimes recently everyday ,and the
debug messages are like that:
uvm_fault ( 0xe33d7ea0,0x0,0,3) -> e
kernel:page fault trap,code=0
stopped at pipe_create+ 0x16: Mov1 $0,0x10(%ebx)
ddb>
anyone could tell me how to solve it .thanks in advance.
On Jun 10, 2011 13:51, Dawe wrote:
> Hi,
>
> I can reliably trigger an uvm_fault on two current amd64 systems with the
> following steps:
>
> - start an xterm
> - maximize it
> - start ghci
> - type ":m + "
> - answer the question with "y"
&g
On Fri, Jun 10, 2011 at 01:51:40PM +0200, Dawe wrote:
> Hi,
>
> I can reliably trigger an uvm_fault on two current amd64 systems with the
> following steps:
>
> - start an xterm
> - maximize it
> - start ghci
> - type ":m + "
> - answer the question with
Hi,
I can reliably trigger an uvm_fault on two current amd64 systems with the
following steps:
- start an xterm
- maximize it
- start ghci
- type ":m + "
- answer the question with "y"
-> uvm_fault (no keyboard response)
uvm_fault(0xfe803cb76820, 0x0, 0, 4) ->
On 21-10-10 12:45, Bret S. Lambert wrote:
> Is the patch something like the following?
Looks right; tested: fixes the bug.
Thanks!
+++chefren
> Index: if.c
> ===
> RCS file: /cvs/src/sys/net/if.c,v
> retrieving revision 1.225
> d
On Thu, Oct 21, 2010 at 11:28:51AM +0200, chefren wrote:
> CARP, no IPsec, Dell 1950 or NIC-less: boot crash
>
> Our custom OpenBSD kernel crashes (uvm_fault) at boot on a Dell 1950.
>
> We've tracked down the problem:
> carpattach()
> ...
>
CARP, no IPsec, Dell 1950 or NIC-less: boot crash
Our custom OpenBSD kernel crashes (uvm_fault) at boot on a Dell 1950.
We've tracked down the problem:
carpattach()
...
if_creategroup("carp")
...
TAILQ_INSERT_TAIL(&ifg_head)
silen
* Marcin Wilk [2010-02-12 10:04]:
> uvm_fault(0xd0891180, 0x4000, 0, 3) ->e
> kernel: page fault trap, code=0
> Stopped at pf_state_key_detach+0x40: movl %eax0,4(%ecx)
> ddb{0}>
> dmesg:
> OpenBSD 4.6 (NICRAM.MP) #0: Wed Feb 10 12:10:36 CET 2010
get stable. and use GENE
was problem:
uvm_fault(0xd0891180, 0x4000, 0, 3) ->e
kernel: page fault trap, code=0
Stopped at pf_state_key_detach+0x40: movl %eax0,4(%ecx)
ddb{0}>
The problem is i cannot make "trace" in ddb because computer freeze then
and it do not
respond on anything. After reset i cannot al
Brett Lymn writes:
> On Tue, Jan 19, 2010 at 12:57:31PM +0100, Artur Grabowski wrote:
>> Is this really the dmesg from the machine? Not manually copied or something?
>>
>> Because every strange error I see in it looks like one bit was flipped.
>>
>> E.g. "com`at)bili4y":
>> "`" 0x60, should be
On Tue, Jan 19, 2010 at 12:57:31PM +0100, Artur Grabowski wrote:
> Is this really the dmesg from the machine? Not manually copied or something?
>
> Because every strange error I see in it looks like one bit was flipped.
>
> E.g. "com`at)bili4y":
> "`" 0x60, should be "p" 0x70
> ")" 0x29, should
Is this really the dmesg from the machine? Not manually copied or something?
Because every strange error I see in it looks like one bit was flipped.
E.g. "com`at)bili4y":
"`" 0x60, should be "p" 0x70
")" 0x29, should be "i" 0x69
"4" 0x34, should be "t" 0x74
Etc.
Although. This is pre-reboot
I suspect
> hardware but honestly after browsing the archives I am not sure what this may
> be.
>
>
> This is the error message that appears on the screen when it goes down:
>
> uvm_fault(0xd9d69d38, 0x0, 0, 1) -> e
> kernel: page fault trap, code = 0
> stopped at ski
this may
be.
This is the error message that appears on the screen when it goes down:
uvm_fault(0xd9d69d38, 0x0, 0, 1) -> e
kernel: page fault trap, code = 0
stopped at skipjack_forwards+ox517: xorb 0 (%edi,%eax,1),%cl
ddb> uvm_fault(0xd081d340, 0xd0034000, 0, 1) -> e
kernel: page fault t
> i'm running 4.6-STABLE, SMP kernel. dmesg attached:
>
> OpenBSD 4.6 (build) #5: *Thu Nov 12 10:28:47 EST 2009*
Update your tree, rebuild the kernel.
There were a few cases where fstat(1) would crash my systems as well.
http://marc.info/?l=openbsd-cvs&m=125971073002018&w=2
http://www.openbsd.o
--- Philip Guenther [Sun, Dec 27, 2009 at 03:46:33PM -0800]: ---
> On Sun, Dec 27, 2009 at 10:25 AM, John Cosimano
> wrote:
> ...
> > i saw in the archive that Stuart Henderson posted something similar a
> > while back, but didn't see any follow-up. any hints to get me looking in
> > the right d
On Sun, Dec 27, 2009 at 10:25 AM, John Cosimano
wrote:
> i was troubleshooting some work i'm doing with python, and ran fstat(1),
> as root, with no arguments.
...
> uvm_fault(0xd8227010, 0x0, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at fill_file2+0x346: movl
ed therein:
uvm_fault(0xd8227010, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at fill_file2+0x346: movl 0x44(%edx),%eax
ddb{0}>
unfortunately, due to some problems on my end, i wasn't able to get a
remote console. after the machine came back up, i ran fstat as an
unprivileged user, ag
On Fri, 28 Nov 2008 23:01:47 +0100
Thomas Pfaff <[EMAIL PROTECTED]> wrote:
[...]
> # tar -zxf ports.tar.gz
> free vnode: 0xd78023a0, type VREG, use 8, write 0, hold 1, flags
> (VBIOONFREELIST)
> tag VT_UFS, ino 432058, on dev 4, 0 flags 0x0, effnlink 1, nlink 1
> mode 0100644, owner 0,
Hi.
I'm trying to get OpenBSD 4.4/i386 working on some new hardware, but I'm
getting uvm_fault and panic that are easily reproduced. I've tried both
4.4-release and 4.4-current but they both have the same problem (crash).
It seems the problem surfaces during heavy-ish disk I/O.
> This issue is likely to have been addressed by the reliability fix #005,
> as seen on http://www.openbsd.org/errata44.html.
It helps. Thank you!
--
engineer
This issue is likely to have been addressed by the reliability fix #005,
as seen on http://www.openbsd.org/errata44.html.
-p.
Hi.
I just installed 4.4 on IBM eServer xSeries 250 (dmesg below). When I
use rtorrent and loading goes fast (more than 1000KB/s) kernel drop to
ddb with:
uvm_fault (0xd083dde0, 0x0, 0, 3) -> e
kernel: page fault trap, code=0
Stopped at uvm_pglistalloc +0x17c: movl %eax,0x4(%edx)
ddb>
Sa
Hello Tobias,
On Wed, 2008-11-05 at 12:56 +0100, Tobias Ulmer wrote:
> So you didn't test 4.4 and -current?
>
No, because it's a production machine, because I didn't have the time
to do much testing while the machine was online and because now I have
an *identical twin* machine up and running
On Tue, Nov 04, 2008 at 10:26:02PM +0100, [EMAIL PROTECTED] wrote:
> Hello again,
>
>After a long time since my initial post, I managed to test the
> machine which stopped three times in a week because of this uvm_fault.
>
>At first I thought it was the RAM. The RA
Hello again,
After a long time since my initial post, I managed to test the
machine which stopped three times in a week because of this uvm_fault.
At first I thought it was the RAM. The RAM checked out fine after a
full day of Memtest. Then some board/processor issue (the machine is a
On Thu, Sep 25, 2008 at 5:54 AM, ng-sup01 <[EMAIL PROTECTED]> wrote:
> I have 4.3 running flawlessly since almost three months on an old
> machine used as firewall: now, in less than a week, it froze twice.
>
> This time I managed to copy down what's on th
Hello again!
ng-sup01 wrote:
Rebooted in single-user and, as suggested, ran fsck on / first,
then on /usr and /var. Turned out clean.
I have been running Memtest86 v2.01 for almost a day now, turns
out there are *NO* problems in the RAM (at least so far).
So we're back at square one:
Hello,
Yesterday I managed to get my hands on the system which halted
twice with a uvm_fault (see original post).
Rebooted in single-user and, as suggested, ran fsck on / first,
then on /usr and /var.
Turned out clean.
If all goes well, I should have a replacement firewall today, so
I
Hi,
On Thu, 25.09.2008 at 13:54:53 +0200, ng-sup01 <[EMAIL PROTECTED]> wrote:
> The machine, once power-cycled, rebooted without a hitch, not even
> complaining about disk corruption or anything.
this doesn't have to mean much.
I recently wanted to install OpenBSD on a machine which also claimed
Hello,
I have 4.3 running flawlessly since almost three months on an old
machine used as firewall: now, in less than a week, it froze twice.
This time I managed to copy down what's on the screen.
uvm_fault (0xd3da32f0,0x79394000,0,1) -> e
fatal page fault (6) in supervisor mode
tra
when booting with generic.mp the system panics with:
uvm_fault(0x80b7d380, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
stopped at uvideo_vs_negotation+0xa5: movl 0x15(%rax),%eax
trace output:
http://img403.imageshack.us/img403/7062/tracebg7.jpg
show registers output:
http://img
You can probably test if I'm barking up the right tree or barking
mad by booting a 4.3 bsd.rd and see if you can fsck your root
partition. Since you appear to have a serial console, I'd try to
do this by booting single user, mount -f / (to skip the fsck), start
the rest of the system, and copy ov
Kirk Ismay wrote:
> I get the following on boot:
>
> Automatic boot in progress: starting file system checks.
> /dev/rwd0a: 1707 files, 16951 used, 283059 free (35 frags, 35378 blocks,
> 0.0% fragmentation)
> /dev/rwd0a: MARKING FILE SYSTEM CLEAN
> uvm_fault(0xd05e1aa0,
I get the following on boot:
Automatic boot in progress: starting file system checks.
/dev/rwd0a: 1707 files, 16951 used, 283059 free (35 frags, 35378 blocks,
0.0% fragmentation)
/dev/rwd0a: MARKING FILE SYSTEM CLEAN
uvm_fault(0xd05e1aa0, 0x800, 0, 1) -> e
kernel: page fault trap, cod
trace
> > pmap_enter(d69c7a2c, 1c022000, 2353000,5,20,1c027000,da433ea4,0) at
> > pmap_enter+0xaf
> > uvm_fault(d687875c,1c023000,0,1,da3efea0) at uvm_fault+0xd0c
> > trap() at trap+0x269
>
> every fault i've had in the area of pmap on i386 has been due to bad
>
027000,da433ea4,0) at
> pmap_enter+0xaf
> uvm_fault(d687875c,1c023000,0,1,da3efea0) at uvm_fault+0xd0c
> trap() at trap+0x269
every fault i've had in the area of pmap on i386 has been due to bad
ram, at least 6 or more times in my experience with garbage resecued
machines.
se it's crashed on
me. It has literally nothing running except the standard daemons
(ntpd, sshd, httpd...) when this (faithfully transcribed) happens:
uvm_fault(0xd687875c, 0xcfc7, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at pmap_enter+0xaf:movl0(%edx,%
I could use to test any changes.
Thanks
Jonathan Steel
uvm_fault(0x..., 0x..., 0, 1) -> e
kernel: page fault trap, code = 0
stopped at pmap_page_remove_86+0x114:
0(%eax, %edx, 4), %eax
The trace output is:
pmap_page_remove_86(d0d31420,c0,e9b57e2c,d04adeb9,e99f) at
pmap_page_remove_86+0x
Just for the record, I've been able to obtain a stable bios
configuration. See the dmesg output below. I've realized that the
problems I've been experiencing (uvm_fault previously, and strange
unexpected reboots during boot-ups recently) are related with the audio
configuration i
I actually only add some packages in install.site script, during my 3-4
trials I got uvm_fault error in one of the following lines:
pkg_add php5-mysql-5.1.6p1.tgz 2>&1 | tee -a $LOG_FILE
pkg_add php5-pear-5.1.6p0.tgz 2>&1 | tee -a $LOG_FILE
/usr/local/sbin/phpxs -s 2>&1 |
ng installation I got the following blue lines (which I've noted
> on a piece of paper by hand):
>
> uvm_fault (0xfe80 0a2de810, 0x7f8000267000, 0, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip 802540a7 cs 8 vflags 10216 cr2
> 7f8000267fb
ue lines (which I've
noted
on a piece of paper by hand):
uvm_fault (0xfe80 0a2de810, 0x7f8000267000, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 802540a7 cs 8 vflags 10216 cr2
7f8000267fb0 cpl1 0 rsp 800067015c80
syncing discs ...done
At which t
Today I was trying to install OpenBSD/amd64 4.1 GENERIC on a system with
the following motherboard:
http://www.asus.com/products4.aspx?modelmenu=2&model=1418&l1=3&l2=101&l3=324&l4=0
But during installation I got the following blue lines (which I've noted
on a piece of p
On Fri, 30 Mar 2007 at 16:48 -0400, Matthew Szudzik wrote:
> I suspect that I may be experiencing the same problem.
After talking with Art, we've decided that I'm probably experiencing a
problem with the ath driver, and not the SMP uvm_fault bug. My problem
disappears when
> Then after about an hour, when you try and reboot, I get an error:
>
> uvm_fault(0x..., 0x..., 0, 1) -> e
> kernel: page fault trap, code = 0
> stopped at pmap_page_remove_86+0x114:
> 0(%eax, %edx, 4), %eax
>
I suspect that I may be experiencing the same prob
1 - 100 of 125 matches
Mail list logo
