Hi,
I don't see this reported, but I may have overlooked it. From this
morning's snapshot, I'm getting a panic on reboot.
This is happening on at least one of my machines, possibly two, but I
don't have serial access to the other to confirm.
ddb{0}> bt
scsi_detach_link(8011a500,1,1e6a129
On Tue, 15 Dec 2020 at 15:03, Mark Kettenis wrote:
>
>
> Thanks. This is committed now. However, there may be other case
> where we use uvm_km_valloc() early on that will trip over the kernel
> lock assertion that mpi@ added in uvm_km_pgremove(). Ideally we
> should get rid of all the uvm_km_f
> Date: Tue, 15 Dec 2020 21:21:37 +0100
> From: Alexander Bluhm
>
> On Tue, Dec 15, 2020 at 06:57:03PM +0100, Mark Kettenis wrote:
> > Does the diff below fix this?
>
> I can reproduce the panic and your diff fixes it.
>
> Usually my regress machines do not trigger it as I do not install
> firm
On Tue, Dec 15, 2020 at 06:57:03PM +0100, Mark Kettenis wrote:
> Does the diff below fix this?
I can reproduce the panic and your diff fixes it.
Usually my regress machines do not trigger it as I do not install
firmware. fw_update and reboot makes it crash.
bluhm
OpenBSD 6.8-current (GENERIC.M
On 15.12.2020. 18:57, Mark Kettenis wrote:
>> From: jungle Boogie
>> Date: Tue, 15 Dec 2020 08:07:04 -0800
>>
>> Hi All,
>>
>> On my i386 Toshiba netbook machine, I am getting a kernel panic with
>> the latest i386 snapshot.
>>
>> I hope this
> From: jungle Boogie
> Date: Tue, 15 Dec 2020 08:07:04 -0800
>
> Hi All,
>
> On my i386 Toshiba netbook machine, I am getting a kernel panic with
> the latest i386 snapshot.
>
> I hope this information helps someone with the issue.
>
> > show
On 15.12.2020. 17:07, jungle Boogie wrote:
> Hi All,
>
> On my i386 Toshiba netbook machine, I am getting a kernel panic with
> the latest i386 snapshot.
>
> I hope this information helps someone with the issue.
>
>> show panic
> kernel diagnostic assertion "_
Hi All,
On my i386 Toshiba netbook machine, I am getting a kernel panic with
the latest i386 snapshot.
I hope this information helps someone with the issue.
> show panic
kernel diagnostic assertion "_kernel_lock_held()" failed:
"/usr/src/sys/uvm/uvm_km.c", line 246
On Wed, 2 Dec 2020 at 14:36, Martin Pieuchot wrote:
>
> On 02/12/20(Wed) 14:22, jungle Boogie wrote:
> > Hi All,
> >
> > Getting this kernel panic on my machine with the latest amd64 snapshot
> > (13:13 timestamp)
> >
> > ddb{1}> bt
&g
On 02/12/20(Wed) 14:22, jungle Boogie wrote:
> Hi All,
>
> Getting this kernel panic on my machine with the latest amd64 snapshot
> (13:13 timestamp)
>
> ddb{1}> bt
> spllower(821b8cb4) at spllower+0x21
> single_thread_check_locked(80002030,0) at
>
Hi All,
Getting this kernel panic on my machine with the latest amd64 snapshot
(13:13 timestamp)
ddb{1}> bt
spllower(821b8cb4) at spllower+0x21
single_thread_check_locked(80002030,0) at single_thread_check_locked+0x
f4
userret(80002030) at userret+0x187
sysc
Hi Miod,
Thanks for helping. With this patch unfortunatly I still get a trap 2 on
my small unifi security gateway which I pulled out again to test your patch.
--->
cnmac0: 192.168.177.35 lease accepted from 192.168.177.1 (24:a4:3c:06:9f:16)
pppoe0: received unexpected PADO
pppoe0: host uniqu
> Try changing all the final 0 in sppp_auth_send() to 0UL and this ought
> to work. This function needs __attribute__((__sentinel__)) as well to
> prevent such mistakes from occurring again.
The sentinel attribute wants a pointer, not a zero size_t,
unfortunately.
Please try this diff.
Index:
> The system has a trap 2, which I looked up as:
>
> #define T_TLB_LD_MISS 2 /* TLB miss on load or ifetch */
>
> what happens before this patch, I think, is that there is a varargs size_t
> (which is size 8 in mips64), that gets promoted (I think) in varargs to int
> (which wou
Hi Janne,
I think the way this patch is, it's ghetto, I don't even know if OpenBSD
wants to take it on, hence I sent it as a hint. What really would be cool is
to find out why exactly the trap 2 happens, because the pppoe code works on
a lot of other archs.
My effort is selfish because I want my
Den ons 23 okt. 2019 kl 09:15 skrev Peter J. Philipp :
> Hi Holger & Tech,
>
> I have made my octeon router work again and I have a patch.
>
>
Truncated it a lot, leaving the things I reacted on:
> - sppp_auth_send(&chap, sp, CHAP_RESPONSE, h->ident,
> -
On Wed, Oct 23, 2019 at 11:18:11AM +0200, Martin Pieuchot wrote:
> On 23/10/19(Wed) 08:43, Peter J. Philipp wrote:
> > Hi Holger & Tech,
>
> Hello Peter,
>
> > I have made my octeon router work again and I have a patch. But I'm not an
> > openbsd developer, nor is this patch official in any way.
On 23/10/19(Wed) 08:43, Peter J. Philipp wrote:
> Hi Holger & Tech,
Hello Peter,
> I have made my octeon router work again and I have a patch. But I'm not an
> openbsd developer, nor is this patch official in any way.
Could you explain in words what is the issue? Why does your diff
prevent it
On Wed, Oct 23, 2019 at 08:21:50AM +0200, Holger Glaess wrote:
> hi
>
>
> here the traceback , i hope ;)
Hi Holger & Tech,
I have made my octeon router work again and I have a patch. But I'm not an
openbsd developer, nor is this patch official in any way. It was a lot of
debugging and refacto
Hi All,
I logged into my erl octeon device to upgrade it. When I logged in via serial, I
received a panic.
login: root
panic: init died (signal 0, exit 10)
Stopped at 0x8135036c: jr ra
0x81350370: nop
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*3
Hi, I bought a LG AN-WF500 wifi adapter and I'm trying to use it on
OpenBSD with the driver bwfm. The driver supports the chipset BCM43242
but doesn't have the IDs for the adapter.
I tried to add the IDs to the driver (patch at the end of the mail) but
the kernel detects three devices and panics w
Finally catch kernel panic in the middle of run adapter work.
A bit different panics from time to time:
Starting stack trace...
panic() at panic+0x11b
splassert_fail(80218000,100,81180127) at splassert_fail+0x67
if_down*8021800) at if_down+0x39
if_downall() at if_downall
>
> From time to time I receive Kernel Panic on OpenBSD 6.2 amd64 when run0
> driver for RT3070 based device is attached to the Lenovo X220 laptop
> during boot.
> It appears just after file system is mounted. Next boot I receive that
> file system was not properly unmounted.
Hi All,
>From time to time I receive Kernel Panic on OpenBSD 6.2 amd64 when run0
driver for RT3070 based device is attached to the Lenovo X220 laptop
during boot.
It appears just after file system is mounted. Next boot I receive that
file system was not properly unmounted.
But after FS check
On Sat, Oct 14, 2017 at 6:57 AM, Krzysztof Strzeszewski
wrote:
> This is very interested "the kernel did non panic".
panic() is an explicit call in the kernel, made when some sanity or
consistency check fails. Dereferencing a bogus pointer results in a failed
page fault trap and goes to ddb di
14.10.2017 o 11:58, Philip Guenther pisze:
On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski
mailto:krz...@krzy.ch>> wrote:
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
It's unfortunate that no one has submitted to dm...@openbsd.org
<mailto:dm...@openbs
On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski
wrote:
> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
>
It's unfortunate that no one has submitted to dm...@openbsd.org the dmesg
from that hardware since February 2016. Please consider doing so every
time
I changed only name kernel :)
W dniu 14.10.2017 o 01:13, Mike Larkin pisze:
On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:
Hi,
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
Try 6.1 stock kernel and see if that works. Then at least we know if we
On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:
> Hi,
> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
>
Try 6.1 stock kernel and see if that works. Then at least we know if we
introduced a regression.
Nobody knows (or cares) what NROOT
Hi,
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
http://wklej.org/hash/e590382de31/
boot>
booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
[680614+82+489520+501323]=0xcc233c
entry point at 0x2000d4
[ using 1671
My system don't started Tor daemon and dnscrypt-proxy
daemon and still I get this kernel panic.
I still use Unbound.
I still have pf rules for transparent
proxying. I only disabled Tor client.
I was thinking about simplify more before I answer, but
dhill () mindcry ! org posted similar bug t
>
> > The key is really being able to reproduce the problem, Lampshade do you
> > already know which service or config triggers this panic? Could you try
> > to figure out by simplifying your setup?
>
> I don't know.
> Problem is that even with most complicated config it happens a few times
> i
Another crash.
I should note that this kernel is build by me with patches
to GENERIC (HZ from 100 to 300), pci and acpi files.
Both previous reports were from
official kernel builds (snapshots).
Source code is based on:
cvs -d$CVSROOT up -D "2016-08-26 12:45" -Pd
As always with this panic I issue
> Are you using the tor TRANS_PF stuff for transparent proxying?
Yes, I am.
# grep -v -e ^# -e Password /etc/tor/instancjaDlaFF.conf
user _tor_do_FF
RunAsDaemon 1
DataDirectory /home/_tor_do_FF/
Log notice file /home/_tor_do_FF/logs/log
SocksPort 0
TransListenAddress 172.10.0.2:9040
TransPort 90
Are you using the tor TRANS_PF stuff for transparent proxying?
On 9 August 2016 10:06:11 p.m. Lampshade wrote:
> Which daemons do you use on this machine?
# rcctl ls on
check_quotas
cron
dnscrypt_proxy_one
dnscrypt_proxy_second
messagebus
pf
pflogd
relayd
sndiod
syslogd
unbound
# rcctl ls
>
> > Which daemons do you use on this machine?
>
> # rcctl ls on
> check_quotas
> cron
> dnscrypt_proxy_one
> dnscrypt_proxy_second
> messagebus
> pf
> pflogd
> relayd
> sndiod
> syslogd
> unbound
> # rcctl ls started
> cron
> dnscrypt_proxy_one
> dnscrypt_proxy_second
> messagebus
>
On 08/09/16 20:47, Lampshade wrote:
> It happened again. I have:
That's bad.
> Tail of dmesg under kernel debugger:
> $ dmesg
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> __assert() at assert+0x25
> pf_state_key_unref() at pf_state_key_unref+0xc6
> pf_pkt_unlink_state_key() at pf_pkt_un
It happened again. I have:
$ sysctl kern.version
kern.version=OpenBSD 6.0-current (GENERIC.MP) #2325: Fri Aug 5 23:28:36 MDT
2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Command I issued before kernel panic still the same (by openbox menu):
$ sudo halt -p
> On 22/06/16(Wed) 00:53, Lampshade wrote:
> > I don't know if this is enough, but I haven't had access to web
> > using other device when kernel panicked.
>
> What's the output of ifconfig and route -n show for this system?
>
Sorry for silence.
Kernel pa
On Wed, 13 Jul 2016 03:26:34 +0200, Alexander Hall wrote:
> Then wouldn't EINVAL be a reasonable response? Am I missing something?
We typically ignore flags that don't make sense. For example,
chmod(2) doesn't return an error if you pass in a mode with the
directory bit set, it just masks it ou
On July 12, 2016 8:55:50 PM GMT+02:00, "Todd C. Miller"
wrote:
>On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote:
>
>> Here's another root-only (unless kern.usermount is set) panic issue.
>We
>> exercise it through tmpfs but it might be more general than that.
>We're
>> not sure what the
On Tue, Jul 12, 2016 at 12:55:50PM -0600, Todd C. Miller wrote:
> On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote:
>
> > Here's another root-only (unless kern.usermount is set) panic issue. We
> > exercise it through tmpfs but it might be more general than that. We're
> > not sure what the
On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote:
> Here's another root-only (unless kern.usermount is set) panic issue. We
> exercise it through tmpfs but it might be more general than that. We're
> not sure what the proper remediation should be here.
The only valid flag for umount(2) is
*
* gcc -g unmount_panic.c -o unmount_panic
*/
#ifdef BUG_WRITEUP //---
Unmounting with MNT_DOOMED flag can lead to a kernel panic
Impact:
Root users or users on systems with kern.usermount set to true can
trigger a kernel panic when unmounting a
On 22/06/16(Wed) 00:53, Lampshade wrote:
> I don't know if this is enough, but I haven't had access to web
> using other device when kernel panicked.
What's the output of ifconfig and route -n show for this system?
> sysctl kern.version
>
I don't know if this is enough, but I haven't had access to web
using other device when kernel panicked.
sysctl kern.version
kern.version=OpenBSD 6.0-beta (GENERIC.MP) #2198: Sun Jun 19 11:58:45 MDT 2016
r...@amd64.openbsd.org:/usr/src/
Great! I appreciate the commit hint.
Thanks
On Fri, May 27, 2016 at 10:46:32PM +0100, Stuart Henderson wrote:
> On 2016/05/27 17:29, David Hill wrote:
> > Hello -
> >
> > Running openbsd current via cvs from today..
> >
> > My machine keeps panic'ing with a uvm_fault in rtable_match.
> > It lo
On 2016/05/27 17:29, David Hill wrote:
> Hello -
>
> Running openbsd current via cvs from today..
>
> My machine keeps panic'ing with a uvm_fault in rtable_match.
> It locks my whole machine up, so I am unable to type anything. Perhaps
> someone can provide me some debugging printf's?
I sent mp
Hello -
Running openbsd current via cvs from today..
My machine keeps panic'ing with a uvm_fault in rtable_match.
It locks my whole machine up, so I am unable to type anything. Perhaps
someone can provide me some debugging printf's?
uvm_fault(0x81945e00, 0x1, 0, 1) -> e
kernel: page fau
On 2/2/16, Mark Kettenis wrote:
>> Date: Tue, 2 Feb 2016 21:32:13 +0100 (CET)
>> From: Mark Kettenis
>>
>> > Date: Tue, 2 Feb 2016 14:14:04 -0500
>> > From: James Hastings
>> >
>> > Native screen size is 1366x768
>> >
>> > Results:
>> > ei.config_acpi: 0x66bfe014
>> > ei.config_smbios: 0x66abef9
> Date: Tue, 2 Feb 2016 21:32:13 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Tue, 2 Feb 2016 14:14:04 -0500
> > From: James Hastings
> >
> > Native screen size is 1366x768
> >
> > Results:
> > ei.config_acpi: 0x66bfe014
> > ei.config_smbios: 0x66abef98
> > ei.fb_addr: 0x8000
> > ei.fb_si
> Date: Tue, 2 Feb 2016 14:14:04 -0500
> From: James Hastings
Best not to drop the list. There are other developers that might want
to chime in.
> On 2/2/16, Mark Kettenis wrote:
> >> Date: Tue, 2 Feb 2016 02:09:08 -0500
> >> From: James Hastings
> >>
> >> Testing UEFI booting. Willing to tes
On Sun, Nov 09, 2014 at 03:01:47PM +0100, Martin Pieuchot wrote:
> Thanks for the report. I just committed a fix for this. The problem
> was in the code closing the pipe. This would only matter for devices
> closing & opening multiple times their pipes, like mouses or keyboards
> when they are o
Hello Dimitris,
On 09/11/14(Sun) 12:39, Dimitris Papastamos wrote:
> Hi everyone,
>
> I had to type this off the screen. My USB keyboard does not work
> at the ddb prompt so I cannot provide more information.
>
> xhci_pipe_open: pipe=0x80493000 addr=2 depth=1 port=9 speed=2
> xhci0: dev
Hi,
../../../../dev/usb/xhci.c:1109
2c26: 4a 8d 14 ba lea(%rdx,%r15,4),%rdx
2c2a: 48 8d 44 10 01 lea0x1(%rax,%rdx,1),%rax
2c2f: 49 8b 84 c5 b8 05 00mov0x5b8(%r13,%rax,8),%rax
2c36: 00
2c37: 89 08
Hi everyone,
I had to type this off the screen. My USB keyboard does not work
at the ddb prompt so I cannot provide more information.
xhci_pipe_open: pipe=0x80493000 addr=2 depth=1 port=9 speed=2
xhci0: dev 1 dci 3 (epAddr=0x81)
xhci0: speed 1 mps 8 rhport 9 route 0x0
xhci0: max ESIT pay
> umct(4) has a broken descriptor and its bulk in endpoint is reported as
> interrupt in. Diff below changes the check to be less strict and avoid
> such panic. Can you confirm it?
After applying your patch the system boots without problems.
Regards,
--
Roberto E. Vargas Caballero
On 04/08/14(Mon) 21:41, Roberto E. Vargas Caballero wrote:
> Hi,
>
> After updating to the snapshot of 31 July, I get a kernel panic
> while booting if I have connected my usb devices. If I connect my
> devices (I connect them through an usb port expander) after booting
&g
Hi,
After updating to the snapshot of 31 July, I get a kernel panic
while booting if I have connected my usb devices. If I connect my
devices (I connect them through an usb port expander) after booting
everything work perfectly. I attach the best dmesg I got (I tried
several times but kernel
Hi,
On Wed, Jul 24, 2013 at 11:52:38AM +0200, Mark Kettenis wrote:
> Taking this to tech@ in the hope some more people will look into this.
Ok. And thanks for picking this up.
> > On Thu, Jul 04, 2013 at 09:56:56AM -0700, Scott Vanderbilt wrote:
> > > I've been trying to build userland repeated
> Date: Mon, 8 Jul 2013 11:06:51 +0200
> From: Christian Ehrhardt
>
> Hi,
Hi Christian,
Taking this to tech@ in the hope some more people will look into this.
> On Thu, Jul 04, 2013 at 09:56:56AM -0700, Scott Vanderbilt wrote:
> > I've been trying to build userland repeatedly over the past few
On Tue, 21 May 2013, Miod Vallat wrote:
> > While experimenting, I've found that fonts with WSDISPLAY_FONTENC_ISO
> > encoding like bold8x16-iso1 or sony8x16 are ok, while fonts with
> > WSDISPLAY_FONTENC_IBM (bold8x16, vt220l8x8) cause the kernel panic
> > belo
> While experimenting, I've found that fonts with WSDISPLAY_FONTENC_ISO
> encoding like bold8x16-iso1 or sony8x16 are ok, while fonts with
> WSDISPLAY_FONTENC_IBM (bold8x16, vt220l8x8) cause the kernel panic
> below:
Fixed. Thanks for the report!
fonts with
WSDISPLAY_FONTENC_IBM (bold8x16, vt220l8x8) cause the kernel panic
below:
---8<---
inteldrm0: 1024x600
wsdisplay0 at vga1 mux 1uvm_fault(0xd0ab0900, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at wsfont_map_unichar+0x4b:subl0(%eax),%edx
w
Hi List,
on i386-current:
OpenBSD 4.8-current (GENERIC.MP) #18: Fri Jan 7 15:22:29 WIT 2011
r...@greenservicerouter-2g.mygreenlinks.net:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error e
cpu0: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz ("GenuineIntel" 686-class) 2.41
GHz
cpu
65 matches
Mail list logo
