Hi Jonathan,
On Tue, Jul 13, 2021 at 01:13:03PM +1000, Jonathan Gray wrote:
> On Mon, Jul 12, 2021 at 06:22:36PM +0000, Tom Murphy wrote:
> > I had firefox open (various tabs/windows) and was playing a 3D game
> > (games/quakespasm) and after a random amount of time I got a hard l
I had firefox open (various tabs/windows) and was playing a 3D game
(games/quakespasm) and after a random amount of time I got a hard lock
up, but the second time it happened I was able to get into a ddb prompt.
I've added the panic message and trace and dmesg.
I don't have a serial console on
On Sat, Mar 14, 2020 at 03:53:58PM +0100, Theo Buehler wrote:
> On Sat, Mar 14, 2020 at 02:01:23PM +0000, Tom Murphy wrote:
> > Hi,
> >
> > I've narrowed it down.
> > Further testing shows it's not kernel, but Xenocara. If I
> > install xbase66.t
Hi,
I've narrowed it down.
Further testing shows it's not kernel, but Xenocara. If I
install xbase66.tgz from 12th March, it's fine. If I use the
newest snapshot xbase66.tgz, X crashes.
Thanks,
Tom
Hi,
I tested -current src with and without jsg@'s commits from:
https://marc.info/?l=openbsd-cvs&m=158415441706312&w=2
Both kernels work fine.
It looks like the problem was introduced between the March 12 and
the March 13/14th snapshot.
So I don't think it's those commits, it'
Hi,
I upgraded from the March 8th snapshot to March 14th one and
when running various apps in X, X crashes and goes back to Xenodm
login screen.
1. Run xterm, then run tmux in it:
xterm: fatal IO error 35 (Resource temporarily unavailable) or
KillClient on X server ":0"
X
Hi Martin,
On Wed, Sep 19, 2018 at 10:36:41AM -0300, Martin Pieuchot wrote:
> At that moment you don't need to plug back the phone. The ugen(4)
> driver has a flawed logic where it waits 1min for all the transfers
> to finish. So just wait until you see:
>
> usb_detach_wait: ugen1 didn't detach
On Wed, Sep 12, 2018 at 12:55:01PM -0300, Martin Pieuchot wrote:
> Hello Tom,
>
> On 08/09/18(Sat) 12:07, Tom Murphy wrote:
> > On Thu, Sep 06, 2018 at 01:06:50PM -0300, Martin Pieuchot wrote:
> > > Tom, as I said previously you've found a race in the ugen(4) dr
Hi Martin,
On Thu, Sep 06, 2018 at 01:06:50PM -0300, Martin Pieuchot wrote:
> Tom, as I said previously you've found a race in the ugen(4) driver.
>
> That's the symptom:
>
> > [...]
> > usb_detach_wait: ugen1 didn't detach
>
> To be able to understand which race we are chasing, could you rebui
Hi Martin,
On Wed, Sep 05, 2018 at 11:19:56AM -0300, Martin Pieuchot wrote:
> On 05/09/18(Wed) 09:51, Tom Murphy wrote:
> > [...]
> > I physically unplug the phone and the kernel starts generating the xhci0:
> > timeout aborting transfer messages in a loop.
>
> A
On Tue, Sep 04, 2018 at 03:24:19PM -0300, Martin Pieuchot wrote:
> On 31/08/18(Fri) 09:19, Tom Murphy wrote:
> > [...]
> > Here's the dmesg from a XHCI_DEBUG kernel before it crashes (it appears
> > to loop quite a few times before the kernel protection fault kicks in.)
Hi Martin,
On Thu, Aug 30, 2018 at 03:38:25PM -0300, Martin Pieuchot wrote:
> On 30/08/18(Thu) 18:15, Tom Murphy wrote:
> > On Thu, Aug 30, 2018 at 10:30:04AM -0300, Martin Pieuchot wrote:
> > > On 30/08/18(Thu) 14:00, Tom Murphy wrote:
> > > > On Wed, Aug 29, 20
On Thu, Aug 30, 2018 at 10:30:04AM -0300, Martin Pieuchot wrote:
> On 30/08/18(Thu) 14:00, Tom Murphy wrote:
> > Hi Martin,
> >
> > On Wed, Aug 29, 2018 at 10:44:51AM -0300, Martin Pieuchot wrote:
> > > On 28/08/18(Tue) 22:22, Tom Murphy wrote:
> > > >
Hi Martin,
On Wed, Aug 29, 2018 at 10:44:51AM -0300, Martin Pieuchot wrote:
> On 28/08/18(Tue) 22:22, Tom Murphy wrote:
> > On Tue, Aug 28, 2018 at 04:20:41PM -0300, Martin Pieuchot wrote:
> > > Hello Tom,
> > >
> > > On 28/08/18(Tue) 11:10, Tom Murphy wrote
On Tue, Aug 28, 2018 at 04:20:41PM -0300, Martin Pieuchot wrote:
> Hello Tom,
>
> On 28/08/18(Tue) 11:10, Tom Murphy wrote:
> > On Tue, Aug 28, 2018 at 02:49:38PM +0900, Bryan Linton wrote:
> > > On 2018-08-25 21:40:57, Tom Murphy wrote:
> > > > On Thu, A
Hi Martin,
On Tue, Aug 28, 2018 at 04:20:41PM -0300, Martin Pieuchot wrote:
> Hello Tom,
>
> On 28/08/18(Tue) 11:10, Tom Murphy wrote:
> > On Tue, Aug 28, 2018 at 02:49:38PM +0900, Bryan Linton wrote:
> > > On 2018-08-25 21:40:57, Tom Murphy wrote:
> > > >
On Tue, Aug 28, 2018 at 02:49:38PM +0900, Bryan Linton wrote:
> [CCing visa@ in]
>
> On 2018-08-25 21:40:57, Tom Murphy wrote:
> > On Thu, Aug 23, 2018 at 08:45:54PM +0900, Tom Murphy wrote:
> > > I've narrowed it down.
> > >
> > >Last ker
On Thu, Aug 23, 2018 at 08:45:54PM +0900, Tom Murphy wrote:
> I've narrowed it down.
>
>Last kernel where adb works: June 24 09:59:46 MDT 2018
>1st Kernel where adb panics: June 25 13:10:32 MDT 2018
>
> I did notice when my phone's booted into LineageOS and I
On Thu, Aug 23, 2018 at 08:45:54PM +0900, Bryan Linton wrote:
> So I found some time to try to bisect this, but was hampered by my
> phone being somewhat temperamental.
>
> Everything up to July 3rd was fine. No crashes occurred.
>
> On a July 15th checkout, my system panicked when trying to run
On Thu, Aug 23, 2018 at 08:45:54PM +0900, Bryan Linton wrote:
> On 2018-08-21 17:00:50, Bryan Linton wrote:
> > On 2018-08-18 23:02:24, Tom Murphy wrote:
> > > >Synopsis:Kernel panic in xhci.c when Android phone with ADB
> > >
> > > [...]
&g
Hi,
I managed to get XHCI_DEBUG working. Here are the messages and I
connect the Android device:
xhci0: xhci_cmd_configure_ep dev 1
xhci0: xhci_cmd_slot_control
xhci0: port=7 change=0x80
xhci0: port=7 change=0x80
xhci0: xhci_cmd_slot_control
xhci0: dev 6, input=0xff00687b9000 slot=0xff
Hi,
I would like to amend the above bug report. When reproducing I
originally said it could be reproduced when the Android device was
just plugged in.
After going over my notes, and doing more testing, I found it only
occurs when 'adb start-server' is running AND the device is plugged in
via
>Synopsis: Kernel panic in xhci.c when Android phone with ADB
> connected
>Category: kernel
>Environment:
System : OpenBSD 6.4
Details : OpenBSD 6.4-beta (GENERIC.MP) #224: Fri Aug 17 23:42:30
MDT 2018
dera...@amd64.openbsd
I put in printfs and delays and found the system becomes unstable in
cpu_boot_secondary() in arch/amd64/amd64/cpu.c on line 458:
ci->ci_flags |= CPUF_GO; /* XXX atomic */
Whatever acpimadt(4) does with the processor and I/O APICs, appears to
have a knock-on effect with that piece of code
On Fri, Mar 04, 2011 at 01:29:19PM -0700, Theo de Raadt wrote:
> I don't know how to help you debug this further. You need to go into
> the code and start adding printf's and such.
>
> None of us currently have machines which fail in this way.
>
> However the issue is that whatever the problem i
The following reply was made to PR kernel/6561; it has been noted by GNATS.
From: Tom Murphy
To: gn...@openbsd.org
Cc:
Subject: Re: kernel/6561: System reboots before fully coming up
Date: Sat, 19 Feb 2011 16:06:46 +
Now, with a recent kernel:
kern.version=OpenBSD 4.9 (GENERIC.MP
>Number: 6367
>Category: amd64
>Synopsis: Running fstat on amd64 SMP kernel always results in panic
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible:bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class:
27 matches
Mail list logo
