A related thread (for the record):
http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-February/000648.html
Markiyan.
On 15.02.2012 12:34, Markiyan Kushnir wrote:
Here it is:
(kgdb) bt
#0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263
#1 0x8036da50 in boot
Tried the case w/o VIMAGE in the kernel (RTL8187L is on in the BIOS) --
no panic.
Also, with the VNET_DEBUG on, got a couple of CURVNET_SET() recursion in
the logs:
Feb 15 14:08:03 mkushnir kernel: CURVNET_SET() recursion in
unp_connect() line 1237, prev in soconnect()
Feb 15 14:08:03 mkus
Any way, I'm still unsure if the urtw's logic of "ignore device
identification failure, and attach" is correct.
--
Markiyan.
2012/2/15 Markiyan Kushnir :
> looks like that's it ...
>
> --
> Markiyan.
___
freebsd-stable@freebsd.org mailing list
http://l
looks like that's it ...
--
Markiyan.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Here it is:
(kgdb) bt
#0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263
#1 0x8036da50 in boot (howto=260) at
/usr/RELENG_8/src/sys/kern/kern_shutdown.c:441
#2 0x8036def1 in panic (fmt=Variable "fmt" is not available.
) at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:
On 15 February 2012 13:01, Markiyan Kushnir wrote:
> Hello,
>
> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, both
> csup'ed around Feb. 10.
>
> Now worked around by turning the RTL8187L off in the BIOS.
>
> %uname -a
> FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STAB
Hello,
[First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8,
both csup'ed around Feb. 10.
Now worked around by turning the RTL8187L off in the BIOS.
%uname -a
FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11
19:39:29 EET 2012
r...@mkushnir.zapto.org:/u
As Andrey V. Elsukov wrote:
> > Anyway, it appears to be a software bug. Ah, OK, it's quite possible
> > the bug has always been there, even in RELENG_7 ... I just never
> > tested that one against INVARIANTS.
>
> I committed the fix in the r83, can you test it?
Works fine!
--
cheers, J"or
As Andrey V. Elsukov wrote:
> > Anyway, it appears to be a software bug. Ah, OK, it's quite possible
> > the bug has always been there, even in RELENG_7 ... I just never
> > tested that one against INVARIANTS.
>
> I committed the fix in the r83, can you test it?
Спасибо, I'll test it tonigh
On 25.05.2011 15:15, Joerg Wunsch wrote:
>> Or maybe you added options INVARIANTS
>> to your kernel?
>
> I did (for other rasons, which you can read about in the freebsd-scsi
> list).
>
> Anyway, it appears to be a software bug. Ah, OK, it's quite possible
> the bug has always been there, even i
As Andrey V. Elsukov wrote:
> Are you sure that it is RELENG_8?
Yes, I am.
> Or maybe you added options INVARIANTS
> to your kernel?
I did (for other rasons, which you can read about in the freebsd-scsi
list).
Anyway, it appears to be a software bug. Ah, OK, it's quite possible
the bug has al
On 25.05.2011 13:36, Joerg Wunsch wrote:
> Well, the workaround is easy (just return -1 from gv_taste() when
> noticing the offset is not on a sector boundary - this can never be a
> valid gvinum device anyway), but I'm curious about why this panic now
> happens in RELENG_8 when it didn't before.
As Jeremy Chadwick wrote:
> Just an informational note about inducing a panic: I tend to, once at
> the db> prompt, do "bt" then immediately "call doadump". That induces
> memory being written to swap, then do "reboot".
OK, reproduced the panic (which was easy ;), and did it that way.
Now, the s
Am 24.05.2011 10:53, schrieb Jeremy Chadwick:
> On Tue, May 24, 2011 at 09:26:18AM +0200, Joerg Wunsch wrote:
>> As Andriy Gapon wrote:
>>
panic: wrong offset 4096 for sectorsize 2352
Any ideas why this happens, and how to avoid it?
>>
>>> Backtrace would be a first thing.
>>
>> OK,
On Tue, May 24, 2011 at 09:26:18AM +0200, Joerg Wunsch wrote:
> As Andriy Gapon wrote:
>
> > > panic: wrong offset 4096 for sectorsize 2352
> > >
> > > Any ideas why this happens, and how to avoid it?
>
> > Backtrace would be a first thing.
>
> OK, here we go (the core has been dumped from with
on 24/05/2011 10:26 Joerg Wunsch said the following:
> As Andriy Gapon wrote:
>
>>> panic: wrong offset 4096 for sectorsize 2352
>>>
>>> Any ideas why this happens, and how to avoid it?
>
>> Backtrace would be a first thing.
>
> OK, here we go (the core has been dumped from within a serial conso
As Andriy Gapon wrote:
> > panic: wrong offset 4096 for sectorsize 2352
> >
> > Any ideas why this happens, and how to avoid it?
> Backtrace would be a first thing.
OK, here we go (the core has been dumped from within a serial console
BREAK DDB entry, I'm omitting the frames related to that):
on 24/05/2011 08:54 Joerg Wunsch said the following:
> After I recently (finally) upgraded my main machine to RELENG_8, I
> tried to rip a CD today, using abcde, and got
>
> panic: wrong offset 4096 for sectorsize 2352
>
> Any ideas why this happens, and how to avoid it?
>
> (I've got a coredump
After I recently (finally) upgraded my main machine to RELENG_8, I
tried to rip a CD today, using abcde, and got
panic: wrong offset 4096 for sectorsize 2352
Any ideas why this happens, and how to avoid it?
(I've got a coredump of the kernel, so I could analyze it if
someone has got an idea wher
At 05:04 PM 8/20/2010, Mike Tancsa wrote:
The box is a moderately busy LNS running mpd5. I have another box
running the same load that has not crashed so I am wondering if its
hardware or this box is just "lucky" ? its crashed a couple of times
now, but the watchdog rebooted it prior to the du
The box is a moderately busy LNS running mpd5. I have another box
running the same load that has not crashed so I am wondering if its
hardware or this box is just "lucky" ? its crashed a couple of times
now, but the watchdog rebooted it prior to the dump being written out.
Fatal trap 12: pag
The box is a moderately busy LNS running mpd5. I have another box
running the same load that has not crashed so I am wondering if its
hardware or this box is just "lucky" ?
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x1378af
fault code
22 matches
Mail list logo
