On Tue, Apr 28, 2015 at 02:10:15PM +0200, Remi Locherer wrote:
> On Tue, Apr 28, 2015 at 01:41:29PM +0200, Martin Pieuchot wrote:
> > On 28/04/15(Tue) 13:15, Remi Locherer wrote:
> > > On Tue, Apr 28, 2015 at 10:17:16AM +0200, Martin Pieuchot wrote:
> > > > On 27/04/15(Mon) 22:45, Remi Locherer wro
On Tue, Apr 28, 2015 at 01:41:29PM +0200, Martin Pieuchot wrote:
> On 28/04/15(Tue) 13:15, Remi Locherer wrote:
> > On Tue, Apr 28, 2015 at 10:17:16AM +0200, Martin Pieuchot wrote:
> > > On 27/04/15(Mon) 22:45, Remi Locherer wrote:
> > > > On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot w
On 28/04/15(Tue) 13:15, Remi Locherer wrote:
> On Tue, Apr 28, 2015 at 10:17:16AM +0200, Martin Pieuchot wrote:
> > On 27/04/15(Mon) 22:45, Remi Locherer wrote:
> > > On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
> > > > This trace tells use that the pipe is no longer valid, whic
On Tue, Apr 28, 2015 at 10:17:16AM +0200, Martin Pieuchot wrote:
> On 27/04/15(Mon) 22:45, Remi Locherer wrote:
> > On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
> > > This trace tells use that the pipe is no longer valid, which means that
> > > the device has been removed but a
On 27/04/15(Mon) 22:45, Remi Locherer wrote:
> On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
> > This trace tells use that the pipe is no longer valid, which means that
> > the device has been removed but a xfer is still referenced by ehci.
> >
> > The output of "ps" could help
On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
> On 27/04/15(Mon) 13:55, Remi Locherer wrote:
> > On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
> > > On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
> > With a series of removals and insertions of t
On 27/04/15(Mon) 13:55, Remi Locherer wrote:
> On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
> > On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
> With a series of removals and insertions of the urtwn device I could
> provoke another panic. I didn't wait for a time
On Mon, Apr 27, 2015 at 01:55:30PM +0200, Remi Locherer wrote:
> I rebuilt a kernel with /etc/mk.conf containing this:
>
> SUDO=/usr/bin/sudo
> DEBUG=-g
> #DEBUGLIB=-g
>
> But there are no line numbers in the ddb output (see end of dmesg). Is there
> another why to build a kernel with debug symbo
On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
> On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
> > Since a couple of month every now and then I'm getting a
> > "urtwn0: device timeout". Usually I deal with it by unlugging the
> > urtwn device and plu
On 26/04/15(Sun) 09:36, Remi Locherer wrote:
> >Synopsis: crash on urtwn removal
> >Environment:
> System : OpenBSD 5.7
> Details : OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25
> 20:12:31 MDT 2015
>
> dera...@amd64.op
On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
> On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
> > Since a couple of month every now and then I'm getting a
> > "urtwn0: device timeout". Usually I deal with it by unlugging the
> > urtwn device and plu
On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
> Since a couple of month every now and then I'm getting a
> "urtwn0: device timeout". Usually I deal with it by unlugging the
> urtwn device and plug it in again, then run "sh /etc/netstart urtwn0".
Is ifconfig dow
>Synopsis: crash on urtwn removal
>Environment:
System : OpenBSD 5.7
Details : OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25
20:12:31 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Archit
13 matches
Mail list logo