Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Alan Cox]

On Sat, Oct 24, 2020 at 2:38 PM Mark Johnston  wrote:

> On Fri, Oct 23, 2020 at 06:32:25PM +0200, Michal Meloun wrote:
> >
> >
> > On 19.10.2020 22:39, Mark Johnston wrote:
> > > On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
> > >>
> > >>
> > >> On 06.10.2020 15:37, Mark Johnston wrote:
> > >>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
> > >>>> Still seeing non-current pmap panics on the Pi3, this time a B+
> running
> > >>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
> > >>>> during a -j4 buildworld.  The backtrace reports
> > >>>>
> > >>>> panic: non-current pmap 0xa00020eab8f0
> > >>>
> > >>> Could you show the output of "show procvm" from the debugger?
> > >>
> > >> I see same panic too, in my case its very rare - typical scenario is
> > >> rebuild of kf5 ports (~250, 2 days of full load).  Any idea how to
> debug
> > >> this?
> > >> Michal
> > >
> > > I suspect that there is some race involving the pmap switching in
> > > vmspace_exit(), but I can't see it.  In the example below, presumably
> > > process 22604 on CPU 0 is also exiting?  Could you show the backtrace?>
> > > It would also be useful to see the value of PCPU_GET(curpmap) at the
> > > time of the panic.  I'm not sure if there's a way to get that from DDB,
> > > but I suspect it should be equal to >vm_pmap.
> > Mark,
> > I think that I found problem.
> > The PCPU_GET() is not (and is not supposed to be) an atomic operation,
> > it expects that thread is at least pinned.
> > This is not true for pmap_remove_pages() - so I think that the KASSERT
> > is racy and shoud be removed (or at least covered by
> > sched_pin()/sched_unpin() pair).
> > What do you think?
>
> I think you're right.  On amd64 curpmap is loaded using a single
> instruction so the assertion happens to work properly.  On arm64 we
> have:
>
>0x007ff138 <+32>:  mov x8, x18
>0x007ff13c <+36>:  ldr x8, [x8, #216]
>0x007ff140 <+40>:  mov x26, x0
>0x007ff144 <+44>:  cmp x8, x0
>
> Though, it looks like arm64's PCPU_GET could be modified to combine the
> first two instructions.
>
> To fix it, we could perhaps change the KASSERT to verify that pmap ==
> vmspace_pmap(curthread->td_proc->p_vmspace). ...
>

Just delete it.  It isn't useful.

...  The various
> implementations of pmap_remove_pages() have different flavours of the
> same check and it would be nice to unify them.  Using sched_pin() would
> also be fine I think.
>

The useful version exists on amd64, where we verify that the pmap is only
active on the processor performing pmap_remove_pages().  The reason being
that some implementations of pmap_remove_pages(), including amd64's and
arm64's, don't not use atomic RMW operations to simultaneously clear a PTE
and check the status of the dirty bit.

> > I think vmspace_exit() should issue a release fence with the cmpset and
> > > an acquire fence when handling the refcnt == 1 case,
> > Yep, true, fully agree.
>
> Alan pointed out in the review that pmap_remove_pages() acquires the
> pmap lock, which I missed, so I don't think the extra barriers are
> necessary after all.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Mark Johnston]

On Fri, Oct 23, 2020 at 06:32:25PM +0200, Michal Meloun wrote:
> 
> 
> On 19.10.2020 22:39, Mark Johnston wrote:
> > On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
> >>
> >>
> >> On 06.10.2020 15:37, Mark Johnston wrote:
> >>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
> >>>> Still seeing non-current pmap panics on the Pi3, this time a B+ running
> >>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
> >>>> during a -j4 buildworld.  The backtrace reports
> >>>>
> >>>> panic: non-current pmap 0xa00020eab8f0
> >>>
> >>> Could you show the output of "show procvm" from the debugger?
> >>
> >> I see same panic too, in my case its very rare - typical scenario is
> >> rebuild of kf5 ports (~250, 2 days of full load).  Any idea how to debug
> >> this?
> >> Michal
> > 
> > I suspect that there is some race involving the pmap switching in
> > vmspace_exit(), but I can't see it.  In the example below, presumably
> > process 22604 on CPU 0 is also exiting?  Could you show the backtrace?>
> > It would also be useful to see the value of PCPU_GET(curpmap) at the
> > time of the panic.  I'm not sure if there's a way to get that from DDB,
> > but I suspect it should be equal to >vm_pmap.
> Mark,
> I think that I found problem.
> The PCPU_GET() is not (and is not supposed to be) an atomic operation,
> it expects that thread is at least pinned.
> This is not true for pmap_remove_pages() - so I think that the KASSERT
> is racy and shoud be removed (or at least covered by
> sched_pin()/sched_unpin() pair).
> What do you think?

I think you're right.  On amd64 curpmap is loaded using a single
instruction so the assertion happens to work properly.  On arm64 we
have:

   0x007ff138 <+32>:  mov x8, x18
   0x007ff13c <+36>:  ldr x8, [x8, #216]
   0x007ff140 <+40>:  mov x26, x0
   0x007ff144 <+44>:  cmp x8, x0

Though, it looks like arm64's PCPU_GET could be modified to combine the
first two instructions.

To fix it, we could perhaps change the KASSERT to verify that pmap ==
vmspace_pmap(curthread->td_proc->p_vmspace).  The various
implementations of pmap_remove_pages() have different flavours of the
same check and it would be nice to unify them.  Using sched_pin() would
also be fine I think.

> > I think vmspace_exit() should issue a release fence with the cmpset and
> > an acquire fence when handling the refcnt == 1 case,
> Yep, true, fully agree.

Alan pointed out in the review that pmap_remove_pages() acquires the
pmap lock, which I missed, so I don't think the extra barriers are
necessary after all.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Michal Meloun]

On 19.10.2020 22:39, Mark Johnston wrote:
> On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
>>
>>
>> On 06.10.2020 15:37, Mark Johnston wrote:
>>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
>>>> Still seeing non-current pmap panics on the Pi3, this time a B+ running
>>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
>>>> during a -j4 buildworld.  The backtrace reports
>>>>
>>>> panic: non-current pmap 0xa00020eab8f0
>>>
>>> Could you show the output of "show procvm" from the debugger?
>>
>> I see same panic too, in my case its very rare - typical scenario is
>> rebuild of kf5 ports (~250, 2 days of full load).  Any idea how to debug
>> this?
>> Michal
> 
> I suspect that there is some race involving the pmap switching in
> vmspace_exit(), but I can't see it.  In the example below, presumably
> process 22604 on CPU 0 is also exiting?  Could you show the backtrace?>
> It would also be useful to see the value of PCPU_GET(curpmap) at the
> time of the panic.  I'm not sure if there's a way to get that from DDB,
> but I suspect it should be equal to >vm_pmap.
Mark,
I think that I found problem.
The PCPU_GET() is not (and is not supposed to be) an atomic operation,
it expects that thread is at least pinned.
This is not true for pmap_remove_pages() - so I think that the KASSERT
is racy and shoud be removed (or at least covered by
sched_pin()/sched_unpin() pair).
What do you think?

> 
> I think vmspace_exit() should issue a release fence with the cmpset and
> an acquire fence when handling the refcnt == 1 case,
Yep, true, fully agree.
Michal

 but I don't see why
> that would make a difference here.  So, if you can test a debug patch,
> this one will yield a bit more debug info.  If you can provide access to
> a vmcore and kernel debug symbols, that'd be even better.
> 
> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
> index 284f00b3cc0d..3c53ae3b4c1e 100644
> --- a/sys/arm64/arm64/pmap.c
> +++ b/sys/arm64/arm64/pmap.c
> @@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap)
>   int allfree, field, freed, idx, lvl;
>   vm_paddr_t pa;
>  
> - KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap));
> + KASSERT(pmap == PCPU_GET(curpmap),
> + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
>  
>   lock = NULL;
>  
> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
> index c20005ae64cf..0ad415e3b88c 100644
> --- a/sys/vm/vm_map.c
> +++ b/sys/vm/vm_map.c
> @@ -358,7 +358,10 @@ vmspace_exit(struct thread *td)
>   p = td->td_proc;
>   vm = p->p_vmspace;
>   atomic_add_int(_refcnt, 1);
> - refcnt = vm->vm_refcnt;
> + refcnt = atomic_load_int(>vm_refcnt);
> +
> + KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap),
> + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
>   do {
>   if (refcnt > 1 && p->p_vmspace != ) {
>   /* Switch now since other proc might free vmspace */
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Mark Johnston]

On Tue, Oct 20, 2020 at 11:55:30AM -0700, bob prohaska wrote:
> On Tue, Oct 20, 2020 at 12:30:05PM -0400, Mark Johnston wrote:
> > 
> > I set up a RPi3 to try and repro this and have so far managed to trigger
> > it once using Peter Holm's stress2 suite, so I'll keep investigating.  I
> > hadn't configured a dump device, but I was able to confirm from DDB that
> > PCPU_GET(curpmap) == >vm_pmap.
> > 
> 
> Is the invalid pmap fault related in any way to intensity of swap usage?
> That's easily adjusted using -j values building things like www/chromium.
> In the past, when I've reported crashes caused by stress2 I've observed
> a "that's inevitable" sort of response with some regularity. Panics when
> doing more normal things like make seem to stimulate greater interest.

I don't think there is any direct relation with swap usage.  The one
time I've reproduced this so far there was no swapping involved.  I've
noticed that stress2 runs on the RPi3 tend to abort or hang in various
ways, but so far haven't seen any panics except the one we're chasing.

> > For future reference,
> > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
> 
> The pieces are all in place, but the machine doesn't seem to find core
> dumps when coming up after a crash. It does routinely issue "no core dumps
> found" during reboot, so it's looking. It it necessary to issue a dump
> command from inside the debugger? 

It depends: if debug.debugger_on_panic is set to 1, you will indeed need
to issue a "dump" command from DDB before rebooting.  Otherwise the
system should automatically dump and reboot.  You'll need to have
"dumpdev" configured in rc.conf in order for vmcores to be recovered
automatically.  Otherwise savecore(8) can be run manually.

> Thanks for writing!
> 
> bob prohaska
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[bob prohaska]

On Tue, Oct 20, 2020 at 12:30:05PM -0400, Mark Johnston wrote:
> 
> I set up a RPi3 to try and repro this and have so far managed to trigger
> it once using Peter Holm's stress2 suite, so I'll keep investigating.  I
> hadn't configured a dump device, but I was able to confirm from DDB that
> PCPU_GET(curpmap) == >vm_pmap.
> 

Is the invalid pmap fault related in any way to intensity of swap usage?
That's easily adjusted using -j values building things like www/chromium.
In the past, when I've reported crashes caused by stress2 I've observed
a "that's inevitable" sort of response with some regularity. Panics when
doing more normal things like make seem to stimulate greater interest.


> For future reference,
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

The pieces are all in place, but the machine doesn't seem to find core
dumps when coming up after a crash. It does routinely issue "no core dumps
found" during reboot, so it's looking. It it necessary to issue a dump
command from inside the debugger? 

Thanks for writing!

bob prohaska

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Mark Johnston]

On Mon, Oct 19, 2020 at 04:09:09PM -0700, bob prohaska wrote:
> On Mon, Oct 19, 2020 at 04:39:54PM -0400, Mark Johnston wrote:
> > 
> > I think vmspace_exit() should issue a release fence with the cmpset and
> > an acquire fence when handling the refcnt == 1 case, but I don't see why
> > that would make a difference here.  So, if you can test a debug patch,
> > this one will yield a bit more debug info.  If you can provide access to
> > a vmcore and kernel debug symbols, that'd be even better.
> > 
> 
> I haven't seen an invalid pmap panic since the report of October 5th.
> Your patch  applied cleanly on the Pi3 running HEAD at r366780M, 
> the M being due to patches supplied by Kyle Evans applied to 
> M   sys/arm/broadcom/bcm2835/bcm2835_mbox.c
> M   sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
> M   sys/arm/broadcom/bcm2835/bcm2835_vcbus.c
> M   sys/arm/broadcom/bcm2835/bcm2835_vcbus.h
> 
> AIUI, they're something to do with DMA for peripherals. They've 
> caused no obvious trouble, if you anticipate conflicts let me know 
> and I'll remove them 

There should be no need to remove them.

> I've never seen either a vmcore file or debug symbols on this machine.
> A sequence of instructions to generate the data needed would be helpful.

I set up a RPi3 to try and repro this and have so far managed to trigger
it once using Peter Holm's stress2 suite, so I'll keep investigating.  I
hadn't configured a dump device, but I was able to confirm from DDB that
PCPU_GET(curpmap) == >vm_pmap.

For future reference,
https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
has some info on configuring a dump device.  For the RPi I'm just using
a USB stick as the dump device.

> Thanks for reading!
> 
> bob prohaska
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[bob prohaska]

On Mon, Oct 19, 2020 at 04:39:54PM -0400, Mark Johnston wrote:
> 
> I think vmspace_exit() should issue a release fence with the cmpset and
> an acquire fence when handling the refcnt == 1 case, but I don't see why
> that would make a difference here.  So, if you can test a debug patch,
> this one will yield a bit more debug info.  If you can provide access to
> a vmcore and kernel debug symbols, that'd be even better.
> 

I haven't seen an invalid pmap panic since the report of October 5th.
Your patch  applied cleanly on the Pi3 running HEAD at r366780M, 
the M being due to patches supplied by Kyle Evans applied to 
M   sys/arm/broadcom/bcm2835/bcm2835_mbox.c
M   sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
M   sys/arm/broadcom/bcm2835/bcm2835_vcbus.c
M   sys/arm/broadcom/bcm2835/bcm2835_vcbus.h

AIUI, they're something to do with DMA for peripherals. They've 
caused no obvious trouble, if you anticipate conflicts let me know 
and I'll remove them 

I've never seen either a vmcore file or debug symbols on this machine.
A sequence of instructions to generate the data needed would be helpful.

Thanks for reading!

bob prohaska

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Mark Johnston]

On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
> 
> 
> On 06.10.2020 15:37, Mark Johnston wrote:
> > On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
> >> Still seeing non-current pmap panics on the Pi3, this time a B+ running
> >> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
> >> during a -j4 buildworld.  The backtrace reports
> >>
> >> panic: non-current pmap 0xa00020eab8f0
> > 
> > Could you show the output of "show procvm" from the debugger?
> 
> I see same panic too, in my case its very rare - typical scenario is
> rebuild of kf5 ports (~250, 2 days of full load).  Any idea how to debug
> this?
> Michal

I suspect that there is some race involving the pmap switching in
vmspace_exit(), but I can't see it.  In the example below, presumably
process 22604 on CPU 0 is also exiting?  Could you show the backtrace?

It would also be useful to see the value of PCPU_GET(curpmap) at the
time of the panic.  I'm not sure if there's a way to get that from DDB,
but I suspect it should be equal to >vm_pmap.

I think vmspace_exit() should issue a release fence with the cmpset and
an acquire fence when handling the refcnt == 1 case, but I don't see why
that would make a difference here.  So, if you can test a debug patch,
this one will yield a bit more debug info.  If you can provide access to
a vmcore and kernel debug symbols, that'd be even better.

diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
index 284f00b3cc0d..3c53ae3b4c1e 100644
--- a/sys/arm64/arm64/pmap.c
+++ b/sys/arm64/arm64/pmap.c
@@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap)
int allfree, field, freed, idx, lvl;
vm_paddr_t pa;
 
-   KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap));
+   KASSERT(pmap == PCPU_GET(curpmap),
+   ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
 
lock = NULL;
 
diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index c20005ae64cf..0ad415e3b88c 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -358,7 +358,10 @@ vmspace_exit(struct thread *td)
p = td->td_proc;
vm = p->p_vmspace;
atomic_add_int(_refcnt, 1);
-   refcnt = vm->vm_refcnt;
+   refcnt = atomic_load_int(>vm_refcnt);
+
+   KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap),
+   ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
do {
if (refcnt > 1 && p->p_vmspace != ) {
/* Switch now since other proc might free vmspace */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Michal Meloun]

On 06.10.2020 15:37, Mark Johnston wrote:
> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
>> Still seeing non-current pmap panics on the Pi3, this time a B+ running
>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
>> during a -j4 buildworld.  The backtrace reports
>>
>> panic: non-current pmap 0xa00020eab8f0
> 
> Could you show the output of "show procvm" from the debugger?

I see same panic too, in my case its very rare - typical scenario is
rebuild of kf5 ports (~250, 2 days of full load).  Any idea how to debug
this?
Michal


panic: non-current pmap 0xa00012e92a80
cpuid = 2
time = 1602831265
KDB: stack backtrace:
db_trace_self() at db_fetch_ksymtab+0x148
 pc = 0x005f655c  lr = 0x00148804
 sp = 0x6dc41200  fp = 0x6dc41400

db_fetch_ksymtab() at kdb_backtrace+0x38
 pc = 0x00148804  lr = 0x0036d3c0
 sp = 0x6dc41410  fp = 0x6dc414d0

kdb_backtrace() at vpanic+0x19c
 pc = 0x0036d3c0  lr = 0x0032b320
 sp = 0x6dc414e0  fp = 0x6dc41530

vpanic() at panic+0x44
 pc = 0x0032b320  lr = 0x0032af3c
 sp = 0x6dc41540  fp = 0x6dc415f0

panic() at pmap_remove_pages+0x5c0
 pc = 0x0032af3c  lr = 0x0060bf0c
 sp = 0x6dc41600  fp = 0x6dc41660

pmap_remove_pages() at vmspace_exit+0xb0
 pc = 0x0060bf0c  lr = 0x005b988c
 sp = 0x6dc41670  fp = 0x6dc416d0

vmspace_exit() at exit1+0x4fc
 pc = 0x005b988c  lr = 0x002e3fcc
 sp = 0x6dc416e0  fp = 0x6dc41740

exit1() at sys_sys_exit+0x10
 pc = 0x002e3fcc  lr = 0x002e3acc
 sp = 0x6dc41750  fp = 0x6dc417a0

sys_sys_exit() at unhandled_exception+0x57c
 pc = 0x002e3acc  lr = 0x0061258c
 sp = 0x6dc417b0  fp = 0x6dc417c0

unhandled_exception() at do_el0_sync+0x324
 pc = 0x0061258c  lr = 0x00611f64
 sp = 0x6dc417d0  fp = 0x6dc41800

do_el0_sync() at do_el0_sync+0x128
 pc = 0x00611f64  lr = 0x00611d68
 sp = 0x6dc41810  fp = 0x6dc41830

do_el0_sync() at handle_el0_sync+0x90
 pc = 0x00611d68  lr = 0x005f8a24
 sp = 0x6dc41840  fp = 0x6dc41980

handle_el0_sync() at 0x407a5ed0
 pc = 0x005f8a24  lr = 0x407a5ed0
 sp = 0x6dc41990  fp = 0xbcb0

KDB: enter: panic
[ thread pid 22603 tid 100099 ]
Stopped at  0x4077df30: undefined   5442
db> show all pcpu
Current CPU: 2

cpuid= 0
dynamic pcpu = 0x66c880
curthread= 0xa000b39eb000: pid 22604 tid 100139 critnest 1 "msgfmt"
curpcb   = 0x6dd09aa0
fpcurthread  = 0xa000b39eb000: pid 22604 "msgfmt"
idlethread   = 0xa12ad5a0: tid 13 "idle: cpu0"
spin locks held:

cpuid= 1
dynamic pcpu = 0x45bfc880
curthread= 0xa000da4185a0: pid 22605 tid 101155 critnest 1 "cmake"
curpcb   = 0x6e02caa0
fpcurthread  = 0xa000da4185a0: pid 22605 "cmake"
idlethread   = 0xa12ad000: tid 14 "idle: cpu1"
spin locks held:

cpuid= 2
dynamic pcpu = 0x45c00880
curthread= 0xa00012c4c000: pid 22603 tid 100099 critnest 1 "msgfmt"
curpcb   = 0x6dc41aa0
fpcurthread  = 0xa00012c4c5a0: pid 22307 "cmake"
idlethread   = 0xa12aa5a0: tid 15 "idle: cpu2"
spin locks held:

cpuid= 3
dynamic pcpu = 0x45c04880
curthread= 0xa788d5a0: pid 7 tid 100039 critnest 1 "doneq0"
curpcb   = 0x40372aa0
fpcurthread  = 0xa00012c4c000: pid 22603 "msgfmt"
idlethread   = 0xa12aa000: tid 16 "idle: cpu3"
spin locks held:

db> show procvm
p = 0xa00012e5d000, vmspace = 0xa00012e92960, map = 0xa00012e92960, 
pmap = 0xa00012e92a80
Task map 0xa00012e92960: pmap=0xa00012e92a80, nentries=88, version=170
  map entry 0xa0002353b6c0: start=0x20, end=0x208000, eflags=0xc0c,
   prot=1/7/copy, object=0xa000ba1cec60, offset=0x0, copy (needed)
Object 0xa000ba1cec60: type=2, size=0x13, res=19, ref=4, flags=0x1000 
ruid -1 charge 0
 sref=0, backing_object(0)=(0)+0x0
  map entry 0xa000457c3180: start=0x217000, end=0x222000, eflags=0xc0c,
   prot=5/7/copy, object=0xa000ba1cec60, offset=0x7000, copy (needed)
  map entry 0xa000b3caa600: start=0x231000, end=0x232000, eflags=0,
   prot=1/7/copy, object=0xa0004b376c60, offset=0x0, obj ruid 0 charge 1000
Object 0xa0004b376c60: type=0, size=0x1, res=1, ref=1, flags=0x3010 
ruid 0 charge 1000
 sref=0, ba

Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Mark Johnston]

On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
> Still seeing non-current pmap panics on the Pi3, this time a B+ running
> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
> during a -j4 buildworld.  The backtrace reports
> 
> panic: non-current pmap 0xa00020eab8f0

Could you show the output of "show procvm" from the debugger?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[bob prohaska]

Still seeing non-current pmap panics on the Pi3, this time a B+ running
13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
during a -j4 buildworld.  The backtrace reports

panic: non-current pmap 0xa00020eab8f0
cpuid = 0
time = 1601947137
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
 pc = 0x0072999c  lr = 0x0019ec8c
 sp = 0x5d96c230  fp = 0x5d96c430

db_trace_self_wrapper() at kdb_backtrace+0x38
 pc = 0x0019ec8c  lr = 0x004b4984
 sp = 0x5d96c440  fp = 0x5d96c500

kdb_backtrace() at vpanic+0x19c
 pc = 0x004b4984  lr = 0x004734c0
 sp = 0x5d96c510  fp = 0x5d96c560

vpanic() at panic+0x44
 pc = 0x004734c0  lr = 0x004730dc
 sp = 0x5d96c570  fp = 0x5d96c620

panic() at pmap_remove_pages+0x5d8
 pc = 0x004730dc  lr = 0x0073fe58
 sp = 0x5d96c630  fp = 0x5d96c690

pmap_remove_pages() at vmspace_exit+0xb0
 pc = 0x0073fe58  lr = 0x006c77a0
 sp = 0x5d96c6a0  fp = 0x5d96c700

vmspace_exit() at exit1+0x470
 pc = 0x006c77a0  lr = 0x0042e5bc
 sp = 0x5d96c710  fp = 0x5d96c760

exit1() at sys_sys_exit+0x10
 pc = 0x0042e5bc  lr = 0x0042e148
 sp = 0x5d96c770  fp = 0x5d96c7c0

sys_sys_exit() at syscallenter+0x104
 pc = 0x0042e148  lr = 0x007463dc
 sp = 0x5d96c7d0  fp = 0x5d96c7d0

syscallenter() at svc_handler+0x4c
 pc = 0x007463dc  lr = 0x00745df8
 sp = 0x5d96c7e0  fp = 0x5d96c810

svc_handler() at do_el0_sync+0xf0
 pc = 0x00745df8  lr = 0x00745c08
 sp = 0x5d96c820  fp = 0x5d96c830

do_el0_sync() at handle_el0_sync+0x90
 pc = 0x00745c08  lr = 0x0072c224
 sp = 0x5d96c840  fp = 0x5d96c980

handle_el0_sync() at 0x40421150
 pc = 0x0072c224  lr = 0x40421150
 sp = 0x5d96c990  fp = 0xd830

KDB: enter: panic
[ thread pid 2429 tid 100951 ]
Stopped at  0x403fa408
db> 

Thanks for reading,

bob prohaska
 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Rpi3 panic: non-current pmap 0xfffffd001e05b130

[Warner Losh]

Page out errors can be caused by crappy nand...

Warner

On Sat, Nov 30, 2019, 6:53 PM bob prohaska  wrote:

> On Sat, Nov 30, 2019 at 05:16:15PM -0800, bob prohaska wrote:
> > A Pi3 running r355024 reported a panic while doing a -j3 make of
> > www/chromium:
> >
> Ok, another panic, looks like a dying storage device. This time there
> was a preamble on the console:
>
> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 c3 90 d8 00 00 08 00
> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> swap_pager: I/O error - pageout failed; blkno 1442883,size 4096, error 5
> swap_pager: I/O error - pageout failed; blkno 1442884,size 4096, error 5
> swap_pager: I/O error - pageout failed; blkno 1442885,size 8192, error 5
> swap_pager: I/O error - pageout failed; blkno 1442887,size 4096, error 5
> swap_pager: I/O error - pagein failed; blkno 1103209,size 4096, error 5
> vm_fault: pager read error, pid 681 (devd)
> swap_pager: I/O error - pagein failed; blkno 1130270,size 4096, error 5
> vm_fault: pager read error, pid 2362 (c++)
> Nov 30 17:37:34 www kernel: Failed to fully fault in a core file segment
> at VA 0x4040 with size 0x60b000 to be written at offset 0x32b000 for
> process devd
> panic: vm_page_assert_unbusied: page 0xfd0030f8af80 busy @
> /usr/src/sys/vm/vm_object.c:777
> cpuid = 3
> time = 1575164255
>
> Earlier panics didn't have any proximate warnings on the console, but
> they're
> probably the same story.
>
> apologies for the noise!
>
> bob prohaska
>
>
>
> > panic: non-current pmap 0xfd001e05b130
> > cpuid = 0
> > time = 1575161361
> > KDB: stack backtrace:
> > db_trace_self() at db_trace_self_wrapper+0x28
> >pc = 0x00729e4c  lr = 0x001066c8
> >sp = 0x59f3e2b0  fp = 0x59f3e4c0
> >
> > db_trace_self_wrapper() at vpanic+0x18c
> >pc = 0x001066c8  lr = 0x00400d7c
> >sp = 0x59f3e4d0  fp = 0x59f3e580
> >
> > vpanic() at panic+0x44
> >pc = 0x00400d7c  lr = 0x00400b2c
> >sp = 0x59f3e590  fp = 0x59f3e610
> >
> > panic() at pmap_remove_pages+0x8d4
> >pc = 0x00400b2c  lr = 0x0074154c
> >sp = 0x59f3e620  fp = 0x59f3e6e0
> >
> > pmap_remove_pages() at vmspace_exit+0xc0
> >pc = 0x0074154c  lr = 0x006c9c00
> >sp = 0x59f3e6f0  fp = 0x59f3e720
> >
> > vmspace_exit() at exit1+0x4f8
> >pc = 0x006c9c00  lr = 0x003bc2a4
> >sp = 0x59f3e730  fp = 0x59f3e7a0
> >
> > exit1() at sys_sys_exit+0x10
> >pc = 0x003bc2a4  lr = 0x003bbda8
> >sp = 0x59f3e7b0  fp = 0x59f3e7b0
> >
> > sys_sys_exit() at do_el0_sync+0x514
> >pc = 0x003bbda8  lr = 0x00747aa4
> >sp = 0x59f3e7c0  fp = 0x59f3e860
> >
> > do_el0_sync() at handle_el0_sync+0x90
> >pc = 0x00747aa4  lr = 0x0072ca14
> >sp = 0x59f3e870  fp = 0x59f3e980
> >
> > handle_el0_sync() at 0x404e6d60
> >pc = 0x0072ca14  lr = 0x404e6d60
> >sp = 0x59f3e990  fp = 0xd590
> >
> > KDB: enter: panic
> > [ thread pid 94966 tid 100145 ]
> > Stopped at  0x40505460: undefined   5442
> > db> bt
> > Tracing pid 94966 tid 100145 td 0xfd002552b000
> > db_trace_self() at db_stack_trace+0xf8
> >  pc = 0x00729e4c  lr = 0x00103b0c
> >  sp = 0x59f3de80  fp = 0x59f3deb0
> >
> > db_stack_trace() at db_command+0x228
> >  pc = 0x00103b0c  lr = 0x00103784
> >  sp = 0x59f3dec0  fp = 0x59f3dfa0
> >
> > db_command() at db_command_loop+0x58
> >  pc = 0x00103784  lr = 0x0010352c
> >  sp = 0x59f3dfb0  fp = 0x59f3dfd0
> >
> > db_command_loop() at db_trap+0xf4
> >  pc = 0x0010352c  lr = 0x00106830
> >  sp = 0x59f3dfe0  fp = 0x59f3e200
> >
> > db_trap() at kdb_trap+0x1d8
> >  pc = 0x00106830  lr = 0x004492fc
> >  sp = 0x59f3e210  fp = 0x59f3e2c0
> >
> > kdb_trap() at do_el1h_sync+0xf4
> >  pc = 0x004492fc  lr = 0x00747418
> >   

Re: Rpi3 panic: non-current pmap 0xfffffd001e05b130

[bob prohaska]

On Sat, Nov 30, 2019 at 05:16:15PM -0800, bob prohaska wrote:
> A Pi3 running r355024 reported a panic while doing a -j3 make of
> www/chromium:
> 
Ok, another panic, looks like a dying storage device. This time there
was a preamble on the console:

(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 c3 90 d8 00 00 08 00 
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
swap_pager: I/O error - pageout failed; blkno 1442883,size 4096, error 5
swap_pager: I/O error - pageout failed; blkno 1442884,size 4096, error 5
swap_pager: I/O error - pageout failed; blkno 1442885,size 8192, error 5
swap_pager: I/O error - pageout failed; blkno 1442887,size 4096, error 5
swap_pager: I/O error - pagein failed; blkno 1103209,size 4096, error 5
vm_fault: pager read error, pid 681 (devd)
swap_pager: I/O error - pagein failed; blkno 1130270,size 4096, error 5
vm_fault: pager read error, pid 2362 (c++)
Nov 30 17:37:34 www kernel: Failed to fully fault in a core file segment at VA 
0x4040 with size 0x60b000 to be written at offset 0x32b000 for process devd
panic: vm_page_assert_unbusied: page 0xfd0030f8af80 busy @ 
/usr/src/sys/vm/vm_object.c:777
cpuid = 3
time = 1575164255

Earlier panics didn't have any proximate warnings on the console, but they're
probably the same story.

apologies for the noise!

bob prohaska



> panic: non-current pmap 0xfd001e05b130
> cpuid = 0
> time = 1575161361
> KDB: stack backtrace:
> db_trace_self() at db_trace_self_wrapper+0x28
>pc = 0x00729e4c  lr = 0x001066c8
>sp = 0x59f3e2b0  fp = 0x59f3e4c0
> 
> db_trace_self_wrapper() at vpanic+0x18c
>pc = 0x001066c8  lr = 0x00400d7c
>sp = 0x59f3e4d0  fp = 0x59f3e580
> 
> vpanic() at panic+0x44
>pc = 0x00400d7c  lr = 0x00400b2c
>sp = 0x59f3e590  fp = 0x59f3e610
> 
> panic() at pmap_remove_pages+0x8d4
>pc = 0x00400b2c  lr = 0x0074154c
>sp = 0x59f3e620  fp = 0x59f3e6e0
> 
> pmap_remove_pages() at vmspace_exit+0xc0
>pc = 0x0074154c  lr = 0x006c9c00
>sp = 0x59f3e6f0  fp = 0x59f3e720
> 
> vmspace_exit() at exit1+0x4f8
>pc = 0x006c9c00  lr = 0x003bc2a4
>sp = 0x59f3e730  fp = 0x59f3e7a0
> 
> exit1() at sys_sys_exit+0x10
>pc = 0x003bc2a4  lr = 0x003bbda8
>sp = 0x59f3e7b0  fp = 0x59f3e7b0
> 
> sys_sys_exit() at do_el0_sync+0x514
>pc = 0x003bbda8  lr = 0x00747aa4
>sp = 0x59f3e7c0  fp = 0x59f3e860
> 
> do_el0_sync() at handle_el0_sync+0x90
>pc = 0x00747aa4  lr = 0x0072ca14
>sp = 0x59f3e870  fp = 0x59f3e980
> 
> handle_el0_sync() at 0x404e6d60
>pc = 0x0072ca14  lr = 0x404e6d60
>sp = 0x59f3e990  fp = 0xd590
> 
> KDB: enter: panic
> [ thread pid 94966 tid 100145 ]
> Stopped at  0x40505460: undefined   5442
> db> bt
> Tracing pid 94966 tid 100145 td 0xfd002552b000
> db_trace_self() at db_stack_trace+0xf8
>  pc = 0x00729e4c  lr = 0x00103b0c
>  sp = 0x59f3de80  fp = 0x59f3deb0
> 
> db_stack_trace() at db_command+0x228
>  pc = 0x00103b0c  lr = 0x00103784
>  sp = 0x59f3dec0  fp = 0x59f3dfa0
> 
> db_command() at db_command_loop+0x58
>  pc = 0x00103784  lr = 0x0010352c
>  sp = 0x59f3dfb0  fp = 0x59f3dfd0
> 
> db_command_loop() at db_trap+0xf4
>  pc = 0x0010352c  lr = 0x00106830
>  sp = 0x59f3dfe0  fp = 0x59f3e200
> 
> db_trap() at kdb_trap+0x1d8
>  pc = 0x00106830  lr = 0x004492fc
>  sp = 0x59f3e210  fp = 0x59f3e2c0
> 
> kdb_trap() at do_el1h_sync+0xf4
>  pc = 0x004492fc  lr = 0x00747418
>  sp = 0x59f3e2d0  fp = 0x59f3e300
> 
> do_el1h_sync() at handle_el1h_sync+0x78
>  pc = 0x00747418  lr = 0x0072c878
>  sp = 0x59f3e310  fp = 0x59f3e420
> 
> handle_el1h_sync() at kdb_enter+0x34
>  pc = 0x0072c878  lr = 0x00448948
>  sp = 0x59f3e430  fp = 0x59f3e4c0
> 
> kdb_enter() at vpanic+0x1a8
>  pc = 0x00448948  lr = 0x00400d98
>  sp = 0x59f3e4d0  fp = 0x59f3e580
> 
> vpanic() at panic+0x44
>  pc 

Rpi3 panic: non-current pmap 0xfffffd001e05b130

[bob prohaska]

A Pi3 running r355024 reported a panic while doing a -j3 make of
www/chromium:

panic: non-current pmap 0xfd001e05b130
cpuid = 0
time = 1575161361
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x00729e4c  lr = 0x001066c8
 sp = 0x59f3e2b0  fp = 0x59f3e4c0

db_trace_self_wrapper() at vpanic+0x18c
 pc = 0x001066c8  lr = 0x00400d7c
 sp = 0x59f3e4d0  fp = 0x59f3e580

vpanic() at panic+0x44
 pc = 0x00400d7c  lr = 0x00400b2c
 sp = 0x59f3e590  fp = 0x59f3e610

panic() at pmap_remove_pages+0x8d4
 pc = 0x00400b2c  lr = 0x0074154c
 sp = 0x59f3e620  fp = 0x59f3e6e0

pmap_remove_pages() at vmspace_exit+0xc0
 pc = 0x0074154c  lr = 0x006c9c00
 sp = 0x59f3e6f0  fp = 0x59f3e720

vmspace_exit() at exit1+0x4f8
 pc = 0x006c9c00  lr = 0x003bc2a4
 sp = 0x59f3e730  fp = 0x59f3e7a0

exit1() at sys_sys_exit+0x10
 pc = 0x003bc2a4  lr = 0x003bbda8
 sp = 0x59f3e7b0  fp = 0x59f3e7b0

sys_sys_exit() at do_el0_sync+0x514
 pc = 0x003bbda8  lr = 0x00747aa4
 sp = 0x59f3e7c0  fp = 0x59f3e860

do_el0_sync() at handle_el0_sync+0x90
 pc = 0x00747aa4  lr = 0x0072ca14
 sp = 0x59f3e870  fp = 0x59f3e980

handle_el0_sync() at 0x404e6d60
 pc = 0x0072ca14  lr = 0x404e6d60
 sp = 0x59f3e990  fp = 0xd590

KDB: enter: panic
[ thread pid 94966 tid 100145 ]
Stopped at  0x40505460: undefined   5442
db> bt
Tracing pid 94966 tid 100145 td 0xfd002552b000
db_trace_self() at db_stack_trace+0xf8
 pc = 0x00729e4c  lr = 0x00103b0c
 sp = 0x59f3de80  fp = 0x59f3deb0

db_stack_trace() at db_command+0x228
 pc = 0x00103b0c  lr = 0x00103784
 sp = 0x59f3dec0  fp = 0x59f3dfa0

db_command() at db_command_loop+0x58
 pc = 0x00103784  lr = 0x0010352c
 sp = 0x59f3dfb0  fp = 0x59f3dfd0

db_command_loop() at db_trap+0xf4
 pc = 0x0010352c  lr = 0x00106830
 sp = 0x59f3dfe0  fp = 0x59f3e200

db_trap() at kdb_trap+0x1d8
 pc = 0x00106830  lr = 0x004492fc
 sp = 0x59f3e210  fp = 0x59f3e2c0

kdb_trap() at do_el1h_sync+0xf4
 pc = 0x004492fc  lr = 0x00747418
 sp = 0x59f3e2d0  fp = 0x59f3e300

do_el1h_sync() at handle_el1h_sync+0x78
 pc = 0x00747418  lr = 0x0072c878
 sp = 0x59f3e310  fp = 0x59f3e420

handle_el1h_sync() at kdb_enter+0x34
 pc = 0x0072c878  lr = 0x00448948
 sp = 0x59f3e430  fp = 0x59f3e4c0

kdb_enter() at vpanic+0x1a8
 pc = 0x00448948  lr = 0x00400d98
 sp = 0x59f3e4d0  fp = 0x59f3e580

vpanic() at panic+0x44
 pc = 0x00400d98  lr = 0x00400b2c
 sp = 0x59f3e590  fp = 0x59f3e610

panic() at pmap_remove_pages+0x8d4
 pc = 0x00400b2c  lr = 0x0074154c
 sp = 0x59f3e620  fp = 0x59f3e6e0

pmap_remove_pages() at vmspace_exit+0xc0
 pc = 0x0074154c  lr = 0x006c9c00
 sp = 0x59f3e6f0  fp = 0x59f3e720

vmspace_exit() at exit1+0x4f8
 pc = 0x006c9c00  lr = 0x003bc2a4
 sp = 0x59f3e730  fp = 0x59f3e7a0

exit1() at sys_sys_exit+0x10
 pc = 0x003bc2a4  lr = 0x003bbda8
 sp = 0x59f3e7b0  fp = 0x59f3e7b0

sys_sys_exit() at do_el0_sync+0x514
 pc = 0x003bbda8  lr = 0x00747aa4
 sp = 0x59f3e7c0  fp = 0x59f3e860

do_el0_sync() at handle_el0_sync+0x90
 pc = 0x00747aa4  lr = 0x0072ca14
 sp = 0x59f3e870  fp = 0x59f3e980

handle_el0_sync() at 0x404e6d60
 pc = 0x0072ca14  lr = 0x404e6d60
 sp = 0x59f3e990  fp = 0xd590

db> 

The last top screen showed

last pid: 94966;  load averages:  1.22,  1.42,  1.40  up 
0+05:10:16  16:49:20
43 processes:  1 running, 42 sleeping
CPU:  3.7% user,  0.0% nice, 20.0% system,  5.5% interrupt, 70.8% idle
Mem: 502M Active, 6672K Inact, 150M Laundry, 184M Wired, 90M Buf, 55M Free
Swap: 7194M Total, 3835M Used, 3359M Free, 53% Inuse, 11M In, 3852K Out

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU COMMAND
71350 root  1  220   951M   144M swread   0  10:20   5.97% c++

Re: Panic with Current 351901 ISO image

[Dennis Clarke]

On 9/8/19 6:03 PM, Curtis Hamilton wrote:
I'm encountering (randomly) the below error when trying to install 
351901 from CD/DVD.




On what type of system ?



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic with Current 351901 ISO image

[Curtis Hamilton]

I'm encountering (randomly) the below error when trying to install 
351901 from CD/DVD.



timeout stopping cpus
panic: acquiring blockable sleep lock with spinlock or critical section 
held (sleep mutex) vm map (system) @ /usr/src/sys/vm/vm_map.c:4066

cpuid = 0
time = 1
KDB: stack backtrace:
0xe0008879d4f0: at .kdb_backtrace+0x5c
0xe0008879d620: at .vpanic+0x1b4
0xe0008879d6e0: at .panic+0x38
0xe0008879d770: at .witness_checkorder+0xf4
0xe0008879d860: at .__mtx_lock_flags+0xfc
0xe0008879d910: at ._vm_map_lock_read+0x34
0xe0008879d990: at .vm_map_lookup+0x94
0xe0008879dad0: at .vm_fault_hold+0x158
0xe0008879dcf0: at .vm_fault+0x94
0xe0008879dda0: at .cpu_fetch_syscall_args+0x404
0xe0008879de50: at .trap+0xf28
0xe0008879e010: at .powerpc_interrupt+0x290
0xe0008879e0b0: kernel DSI read trap @ 0x392 by 
.sched_relinquish+0x290: srr1=0x90001032
r1=0xe0008879e360 cr=0x20009032 xer=0 ctr=0xc2ea198c 
r2=0xc393f7e0 sr=0x4000

0xe0008879e360: at .sched_tdname+0xbc
0xe0008879e3f0: at .sched_switch+0x414
0xe0008879e530: at .mi_switch+0x2d4
0xe0008879e5c0: at .sched_bind+0xd8
0xe0008879e650: at .taskqgroup_config_gtask_init+0x108
0xe0008879e700: at .gtaskqueue_cancel+0x2ac
0xe0008879e7c0: at .taskqgroup_adjust+0xb0c
0xe0008879e850: at .fork_exit+0xd0
0xe0008879e8f0: at .fork_trampoline+0x10
0xe0008879e920: at -0x4
KDB: enter: panic
[ thread pid 0 tid 100144 ]
Stopped at .kdb_enter+0x60:        ld      r2, r1, 0x28
db>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Mark Peek]

On Fri, Mar 23, 2018 at 4:19 PM, Konstantin Belousov 
wrote:

> On Fri, Mar 23, 2018 at 04:06:23PM -0700, Mark Peek wrote:
> > I ran into the original issue with r330539 on a Fusion VM. Trying this
> > patch causes a different panic:
> >
> > https://people.freebsd.org/~mp/r330539-patched.png
> >
> > Thoughts?
>
> r331290 should fixed this issue.  What is your kernel sources version ?
>

Thank you for the pointer to r331290. I missed it and thought your patch to
-current was the intended fix.

Updated my kernel to r331469 and it is booting on Fusion now.

Thanks!
Mark
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Mark Peek]

On Fri, Mar 16, 2018 at 2:56 AM, Konstantin Belousov 
wrote:

> On Thu, Mar 15, 2018 at 09:38:56PM -0500, Peter Lei wrote:
> > Some recent UEFI implementations have begun to leave the CPU with page
> > write protection enabled in CR0.
> >
> > With r330539 which enables kernel page protections, interesting things
> > happen during boot (aka panic) when protection is already enabled,
> > including a write protection fault from an explicit .text fixup write
> > from xsave->xsaveopt by fpuinit().
> >
> > I see this so far booting -CURRENT under virtual environments:
> >
> > - QEMU with recent OVMF EDK2 builds: this is certainly due to UEFI
> > enabling paging and page protections.
> >
> > - VMWare Fusion 10.1.x on Mac: no specific insight on what's going
> > inside the implementation, but CR0_WP is definitely left enabled before
> > the kernel is booted.
> >
> > I have patched my kernel build to explicitly clear CR0_WP (e.g. in
> > initializecpu) prior to creating the page tables to get around this, but
> > someone might have a cleaner/better solution...
>
> Try this.
>
> diff --git a/sys/amd64/amd64/db_interface.c b/sys/amd64/amd64/db_
> interface.c
> index 9dfd44cf82c..1ecec02835c 100644
> --- a/sys/amd64/amd64/db_interface.c
> +++ b/sys/amd64/amd64/db_interface.c
>  


I ran into the original issue with r330539 on a Fusion VM. Trying this
patch causes a different panic:

https://people.freebsd.org/~mp/r330539-patched.png

Thoughts?

Mark
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Konstantin Belousov]

On Fri, Mar 23, 2018 at 04:44:36PM -0700, Mark Peek wrote:
> On Fri, Mar 23, 2018 at 4:19 PM, Konstantin Belousov 
> wrote:
> 
> > On Fri, Mar 23, 2018 at 04:06:23PM -0700, Mark Peek wrote:
> > > I ran into the original issue with r330539 on a Fusion VM. Trying this
> > > patch causes a different panic:
> > >
> > > https://people.freebsd.org/~mp/r330539-patched.png
> > >
> > > Thoughts?
> >
> > r331290 should fixed this issue.  What is your kernel sources version ?
> >
> 
> Thank you for the pointer to r331290. I missed it and thought your patch to
> -current was the intended fix.
It is, but there is more than one issue. The posted patch fixed code
patching, committed as r331258 and r331253. Then there was the fix for
sysinit sort in r331290.

> 
> Updated my kernel to r331469 and it is booting on Fusion now.
Ok.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Konstantin Belousov]

On Fri, Mar 23, 2018 at 04:06:23PM -0700, Mark Peek wrote:
> I ran into the original issue with r330539 on a Fusion VM. Trying this
> patch causes a different panic:
> 
> https://people.freebsd.org/~mp/r330539-patched.png
> 
> Thoughts?

r331290 should fixed this issue.  What is your kernel sources version ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Konstantin Belousov]

On Thu, Mar 15, 2018 at 09:38:56PM -0500, Peter Lei wrote:
> Some recent UEFI implementations have begun to leave the CPU with page
> write protection enabled in CR0.
> 
> With r330539 which enables kernel page protections, interesting things
> happen during boot (aka panic) when protection is already enabled,
> including a write protection fault from an explicit .text fixup write
> from xsave->xsaveopt by fpuinit().
> 
> I see this so far booting -CURRENT under virtual environments:
> 
> - QEMU with recent OVMF EDK2 builds: this is certainly due to UEFI
> enabling paging and page protections.
> 
> - VMWare Fusion 10.1.x on Mac: no specific insight on what's going
> inside the implementation, but CR0_WP is definitely left enabled before
> the kernel is booted.
> 
> I have patched my kernel build to explicitly clear CR0_WP (e.g. in
> initializecpu) prior to creating the page tables to get around this, but
> someone might have a cleaner/better solution...

Try this.

diff --git a/sys/amd64/amd64/db_interface.c b/sys/amd64/amd64/db_interface.c
index 9dfd44cf82c..1ecec02835c 100644
--- a/sys/amd64/amd64/db_interface.c
+++ b/sys/amd64/amd64/db_interface.c
@@ -37,6 +37,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -75,19 +76,19 @@ db_write_bytes(vm_offset_t addr, size_t size, char *data)
jmp_buf jb;
void *prev_jb;
char *dst;
-   u_long cr0save;
+   bool old_wp;
int ret;
 
-   cr0save = rcr0();
+   old_wp = false;
prev_jb = kdb_jmpbuf(jb);
ret = setjmp(jb);
if (ret == 0) {
-   load_cr0(cr0save & ~CR0_WP);
+   old_wp = disable_wp();
dst = (char *)addr;
while (size-- > 0)
*dst++ = *data++;
}
-   load_cr0(cr0save);
+   restore_wp(old_wp);
(void)kdb_jmpbuf(prev_jb);
return (ret);
 }
diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
index 72b10396341..39367fa6ffb 100644
--- a/sys/amd64/amd64/fpu.c
+++ b/sys/amd64/amd64/fpu.c
@@ -205,6 +205,7 @@ fpuinit_bsp1(void)
 {
u_int cp[4];
uint64_t xsave_mask_user;
+   bool old_wp;
 
if ((cpu_feature2 & CPUID2_XSAVE) != 0) {
use_xsave = 1;
@@ -233,8 +234,14 @@ fpuinit_bsp1(void)
 * Patch the XSAVE instruction in the cpu_switch code
 * to XSAVEOPT.  We assume that XSAVE encoding used
 * REX byte, and set the bit 4 of the r/m byte.
+*
+* It seems that some BIOSes give control to the OS
+* with CR0.WP already set, making the kernel text
+* read-only before cpu_startup().
 */
+   old_wp = disable_wp();
ctx_switch_xsave[3] |= 0x10;
+   restore_wp(old_wp);
}
 }
 
diff --git a/sys/amd64/amd64/gdb_machdep.c b/sys/amd64/amd64/gdb_machdep.c
index 68eb6002593..f7ca3c07ea3 100644
--- a/sys/amd64/amd64/gdb_machdep.c
+++ b/sys/amd64/amd64/gdb_machdep.c
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,17 +128,14 @@ gdb_cpu_signal(int type, int code)
 void *
 gdb_begin_write(void)
 {
-   u_long cr0save;
 
-   cr0save = rcr0();
-   load_cr0(cr0save & ~CR0_WP);
-   return ((void *)cr0save);
+   return (disable_wp() ? _begin_write : NULL);
 }
 
 void
 gdb_end_write(void *arg)
 {
 
-   load_cr0((u_long)arg);
+   restore_wp(arg != NULL);
 }
 
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index e340c6cd14d..fcc45eca57d 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -2597,6 +2597,31 @@ clear_pcb_flags(struct pcb *pcb, const u_int flags)
: "cc", "memory");
 }
 
+/*
+ * Enable and restore kernel text write permissions.
+ * Callers must ensure that disable_wp()/restore_wp() are executed
+ * without rescheduling on the same core.
+ */
+bool
+disable_wp(void)
+{
+   u_int cr0;
+
+   cr0 = rcr0();
+   if ((cr0 & CR0_WP) == 0)
+   return (false);
+   load_cr0(cr0 & ~CR0_WP);
+   return (true);
+}
+
+void
+restore_wp(bool old_wp)
+{
+
+   if (old_wp)
+   load_cr0(rcr0() | CR0_WP);
+}
+
 #ifdef KDB
 
 /*
diff --git a/sys/amd64/include/md_var.h b/sys/amd64/include/md_var.h
index 63dabaf4047..abcc273b6c6 100644
--- a/sys/amd64/include/md_var.h
+++ b/sys/amd64/include/md_var.h
@@ -53,6 +53,8 @@ void  amd64_conf_fast_syscall(void);
 void   amd64_db_resume_dbreg(void);
 void   amd64_lower_shared_page(struct sysentvec *);
 void   amd64_syscall(struct thread *td, int traced);
+bool   disable_wp(void);
+void   restore_wp(bool old_wp);
 void   doreti_iret(void) __asm(__STRING(doreti_iret));
 void   doreti_iret_fault(void) __asm(__STRING(doreti_iret_fault));
 void   ld_ds(void) __asm(__STRING(ld_ds));
___

amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Peter Lei]

Some recent UEFI implementations have begun to leave the CPU with page
write protection enabled in CR0.

With r330539 which enables kernel page protections, interesting things
happen during boot (aka panic) when protection is already enabled,
including a write protection fault from an explicit .text fixup write
from xsave->xsaveopt by fpuinit().

I see this so far booting -CURRENT under virtual environments:

- QEMU with recent OVMF EDK2 builds: this is certainly due to UEFI
enabling paging and page protections.

- VMWare Fusion 10.1.x on Mac: no specific insight on what's going
inside the implementation, but CR0_WP is definitely left enabled before
the kernel is booted.

I have patched my kernel build to explicitly clear CR0_WP (e.g. in
initializecpu) prior to creating the page tables to get around this, but
someone might have a cleaner/better solution...

--peter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: panic on current during shutdown: panic: racct_adjust_resource: resource 4 usage < 0

[Andriy Gapon]

On 20/01/2017 02:09, Larry Rosenman wrote:
> Thu Jan 19 18:03:38 CST 2017
> 
> FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r311997: Sat Jan
> 14 22:35:29 CST 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  
> amd64
> 
> panic: racct_adjust_resource: resource 4 usage < 0
[snip]

Very interesting.
Could you please contribute this information to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210315
?
These could be related issues.

> Unread portion of the kernel message buffer:
> <118>.
> <118>Terminated
> <118>Jan 19 17:54:50 192.168.200.11 last message repeated 13 times
> <118>Jan 19 17:54:59 borg syslogd: exiting on signal 15
> panic: racct_adjust_resource: resource 4 usage < 0
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe2eb7c18830
> vpanic() at vpanic+0x186/frame 0xfe2eb7c188b0
> kassert_panic() at kassert_panic+0x126/frame 0xfe2eb7c18920
> racct_adjust_resource() at racct_adjust_resource+0xca/frame 0xfe2eb7c18950
> racct_set_locked() at racct_set_locked+0xec/frame 0xfe2eb7c18990
> racct_set() at racct_set+0x54/frame 0xfe2eb7c189c0
> vmspace_exit() at vmspace_exit+0x147/frame 0xfe2eb7c18a00
> exit1() at exit1+0x56b/frame 0xfe2eb7c18a60
> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe2eb7c18a70
> amd64_syscall() at amd64_syscall+0x2ea/frame 0xfe2eb7c18bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe2eb7c18bf0
> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8025c916a, rsp =
> 0x7fffebd8, rbp = 0x7fffebf0 ---
> Uptime: 4d4h19m38s
> Dumping 12670 out of 64463 
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
[snip]
> __curthread () at ./machine/pcpu.h:222
> 222 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:222
> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318
> #2  0x80a2ffb5 in kern_reboot (howto=)
> at /usr/src/sys/kern/kern_shutdown.c:386
> #3  0x80a30590 in vpanic (fmt=, ap=0xfe2eb7c188f0)
> at /usr/src/sys/kern/kern_shutdown.c:779
> #4  0x80a303c6 in kassert_panic (
> fmt=0x813ee4fb "%s: resource %d usage < 0")
> at /usr/src/sys/kern/kern_shutdown.c:669
> #5  0x80a21eca in racct_adjust_resource (racct=0xf8001b7c00d0,
> resource=4, amount=) at /usr/src/sys/kern/kern_racct.c:528
> #6  0x80a21acc in racct_set_locked (p=0xf80055f41528,
> resource=, amount=0, force=0)
> at /usr/src/sys/kern/kern_racct.c:718
> #7  0x80a21994 in racct_set (p=0xf80055f41528, resource=4,
> amount=0) at /usr/src/sys/kern/kern_racct.c:741
> #8  0x80d0f8e7 in vmspace_container_reset (p=)
> at /usr/src/sys/vm/vm_map.c:311
> #9  vmspace_exit (td=) at /usr/src/sys/vm/vm_map.c:420
> #10 0x809f01ab in exit1 (td=, rval=,
> signo=) at /usr/src/sys/kern/kern_exit.c:399
> #11 0x809efc3d in sys_sys_exit (td=, uap=)
> at /usr/src/sys/kern/kern_exit.c:178
> #12 0x80e9a98a in syscallenter (td=0xf80055de6000,
> sa=)
> at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
> #13 amd64_syscall (td=0xf80055de6000, traced=0)
> at /usr/src/sys/amd64/amd64/trap.c:902
> #14 
> Can't read data for section '.eh_frame' in file '/'
> (kgdb)
> 
> vmcore IS available.
> 
> 


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic on current during shutdown: panic: racct_adjust_resource: resource 4 usage < 0

[Larry Rosenman]

Thu Jan 19 18:03:38 CST 2017

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r311997: 
Sat Jan 14 22:35:29 CST 2017 
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64


panic: racct_adjust_resource: resource 4 usage < 0

GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.

done.

Unread portion of the kernel message buffer:
<118>.
<118>Terminated
<118>Jan 19 17:54:50 192.168.200.11 last message repeated 13 times
<118>Jan 19 17:54:59 borg syslogd: exiting on signal 15
panic: racct_adjust_resource: resource 4 usage < 0
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe2eb7c18830

vpanic() at vpanic+0x186/frame 0xfe2eb7c188b0
kassert_panic() at kassert_panic+0x126/frame 0xfe2eb7c18920
racct_adjust_resource() at racct_adjust_resource+0xca/frame 
0xfe2eb7c18950

racct_set_locked() at racct_set_locked+0xec/frame 0xfe2eb7c18990
racct_set() at racct_set+0x54/frame 0xfe2eb7c189c0
vmspace_exit() at vmspace_exit+0x147/frame 0xfe2eb7c18a00
exit1() at exit1+0x56b/frame 0xfe2eb7c18a60
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe2eb7c18a70
amd64_syscall() at amd64_syscall+0x2ea/frame 0xfe2eb7c18bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe2eb7c18bf0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8025c916a, rsp = 
0x7fffebd8, rbp = 0x7fffebf0 ---

Uptime: 4d4h19m38s
Dumping 12670 out of 64463 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%


Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.

done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.

done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.

done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.

done.
Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/if_lagg.ko.debug...done.

done.
Reading symbols from /boot/kernel/snd_envy24ht.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/snd_envy24ht.ko.debug...done.

done.
Reading symbols from /boot/kernel/snd_spicds.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/snd_spicds.ko.debug...done.

done.
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.

done.
Reading symbols from /boot/kernel/fuse.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fuse.ko.debug...done.

done.
Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichsmb.ko.debug...done.

done.
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/smbus.ko.debug...done.

done.
Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichwd.ko.debug...done.

done.
Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/cpuctl.ko.debug...done.

done.
Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/cryptodev.ko.debug...done.

done.
Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtraceall.ko.debug...done.

done.
Reading symbols from /boot/kernel/profile.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/profile.ko.debug...done.

done.
Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtrace.ko.debug...done.

done.
Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading 
symbols from 
/usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done.

done.
Reading symbols from /boot/kernel/systrace.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/systrace.ko.debug...done.

done.
Reading symbols from /boot/kernel/sdt.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/sdt.ko.debug...done.

done.
Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from 

reproducible kernel panic on CURRENT, I/O related

[Johannes Dieterich]

Dear all,

since approximately three weeks I am seeing kernel panics on CURRENT
that are in so far reproducible as that they typically occur when I
run svn up on the ports tree. Hence, it seems I/O related to me. Sorry
that I only now got around to reporting it!

The system is a CURRENT amd64 running ZFS on root w/ GELI. It has the
aesni kernel module loaded. The world and kernel are on SVN r285764.

The kernel stack backtrace looks as follows (transcript):

db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe03d0394830
vpanic() at vpanic+0x189/frame 0xe03d03948b0
panic() at panic+0x43/frame 0xfe03d0394910
trash_ctor() at trash_ctor+0x48/frame 0xfe03d0394920
uma_zalloc_arg() at uma_zalloc_arg+0x573/frame 0xfe03d0394990
g_clone_bio() at g_clone_bio+0x1d/frame 0xfe03d03949b0
g_part_start() at g_part_start+0x8e/frame 0xfe03d0394a30
g_io_schedule_down() at g_io_schedule_down+0xe6/frame 0xfe03d0394a60
g_down_procbody() at g_down_procbody+0x7d/frame 0xfee03d0394a70
fork_exit() at fork_exit+0x84/frame 0xfe03d0394ab0
fork_trampoline at fork_trampoline+0xe/frame 0xfe03d0394ab0
--- trap 0, rip = 0, rsp =0xfe03d0394b90, rbp = 0---
KDB: enter: panic
[ thread pid 13 tid 100017 ]
Stopped at kdb_enter+0x3e: movq $0,kdb_why

Due to above setup, I cannot provide a core file, sorry.

Please let me know if there is any data you want me to obtain for
debugging. As I said above, it is fairly simple for me to hit the
panic.

Best

Johannes
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Hans Petter Selasky]

On 03/31/15 02:15, Konstantin Belousov wrote:

On Tue, Mar 31, 2015 at 02:51:47AM +0300, Konstantin Belousov wrote:

On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote:

On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote:
H On 03/30/15 23:19, Gleb Smirnoff wrote:
H  On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
H  M I get the following panic on current svn ver  r280793:
H  M
H  M Sat Mar 28 14:41:28 PDT 2015
H  M
H  M FreeBSD/amd64 (pozo.com) (ttyu0)
H  M
H  M panic: Invalid CPU in callout 16
H 
H  The same happened to me in the OFED code. After investigation
H  it appeared that for some unknown reason, the OFED code used
H  /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h,
H  that yield in wrong value passing as parameter.
H 
H  I failed to reproduce the problem. :( So, the fix is a rebuild
H  of kernel. But the right fix is to understand what went wrong
H  in the previous build.
H
H How did you compile the OFED stuff? Did you set the SYSDIR variable when
H building?

I just have this in my kernel config:

options OFED
device  mlxen


Quick grep of the sys/ofed immediately shows the following:

sys/ofed/include/linux/wait.h:#include sys/param.h
sys/ofed/include/linux/wait.h:#include sys/systm.h
sys/ofed/include/linux/wait.h:#include sys/sleepqueue.h
sys/ofed/include/linux/wait.h:#include sys/kernel.h
sys/ofed/include/linux/wait.h:#include sys/proc.h

ys/ofed/include/linux/timer.h:#include sys/callout.h
sys/ofed/include/linux/types.h:#include sys/cdefs.h
sys/ofed/include/linux/types.h:#include sys/types.h
sys/ofed/include/linux/types.h:#include sys/param.h
sys/ofed/include/linux/types.h:#include sys/systm.h

and so on.


Err, I am sorry, scratch this.


Hi,

Could you:

cd sys/amd64/conf
config YOURCONFIG

cd ../compile/YOURCONFIG
less Makefile

and see if it includes something outside /sys ?

OFED uses its own CFLAGS and check if some include directives have space 
after the -Ixxxspace, because then this simple flag conversion will fail:


OFEDCFLAGS= ${CFLAGS:N-I*} ${OFEDINCLUDES} ${CFLAGS:M-I*} ${OFEDNOERR}

Thank you!

--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Gleb Smirnoff]

On Mon, Mar 30, 2015 at 02:30:04PM -0700, Adrian Chadd wrote:
A Would you mind filing a PR for it so it isn't forgotten?

If I could provide enough information to fix that, I would either
fix myself or forward information to someone confident in build.

Creating PR with what I have now means simply garbaging the bugzilla.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Gleb Smirnoff]

On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
M I get the following panic on current svn ver  r280793:
M 
M Sat Mar 28 14:41:28 PDT 2015
M 
M FreeBSD/amd64 (pozo.com) (ttyu0)
M 
M panic: Invalid CPU in callout 16

The same happened to me in the OFED code. After investigation
it appeared that for some unknown reason, the OFED code used
/usr/include/sys/callout.h instead of SYSDIR/sys/callout.h,
that yield in wrong value passing as parameter.

I failed to reproduce the problem. :( So, the fix is a rebuild
of kernel. But the right fix is to understand what went wrong
in the previous build.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Hans Petter Selasky]

On 03/30/15 23:19, Gleb Smirnoff wrote:

On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
M I get the following panic on current svn ver  r280793:
M
M Sat Mar 28 14:41:28 PDT 2015
M
M FreeBSD/amd64 (pozo.com) (ttyu0)
M
M panic: Invalid CPU in callout 16

The same happened to me in the OFED code. After investigation
it appeared that for some unknown reason, the OFED code used
/usr/include/sys/callout.h instead of SYSDIR/sys/callout.h,
that yield in wrong value passing as parameter.

I failed to reproduce the problem. :( So, the fix is a rebuild
of kernel. But the right fix is to understand what went wrong
in the previous build.



Hi,

How did you compile the OFED stuff? Did you set the SYSDIR variable when 
building?


--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Gleb Smirnoff]

On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote:
H On 03/30/15 23:19, Gleb Smirnoff wrote:
H  On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
H  M I get the following panic on current svn ver  r280793:
H  M
H  M Sat Mar 28 14:41:28 PDT 2015
H  M
H  M FreeBSD/amd64 (pozo.com) (ttyu0)
H  M
H  M panic: Invalid CPU in callout 16
H 
H  The same happened to me in the OFED code. After investigation
H  it appeared that for some unknown reason, the OFED code used
H  /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h,
H  that yield in wrong value passing as parameter.
H 
H  I failed to reproduce the problem. :( So, the fix is a rebuild
H  of kernel. But the right fix is to understand what went wrong
H  in the previous build.
H 
H How did you compile the OFED stuff? Did you set the SYSDIR variable when 
H building?

I just have this in my kernel config:

options OFED
device  mlxen

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Adrian Chadd]

Hi,

Would you mind filing a PR for it so it isn't forgotten?


-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Konstantin Belousov]

On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote:
 On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote:
 H On 03/30/15 23:19, Gleb Smirnoff wrote:
 H  On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
 H  M I get the following panic on current svn ver  r280793:
 H  M
 H  M Sat Mar 28 14:41:28 PDT 2015
 H  M
 H  M FreeBSD/amd64 (pozo.com) (ttyu0)
 H  M
 H  M panic: Invalid CPU in callout 16
 H 
 H  The same happened to me in the OFED code. After investigation
 H  it appeared that for some unknown reason, the OFED code used
 H  /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h,
 H  that yield in wrong value passing as parameter.
 H 
 H  I failed to reproduce the problem. :( So, the fix is a rebuild
 H  of kernel. But the right fix is to understand what went wrong
 H  in the previous build.
 H 
 H How did you compile the OFED stuff? Did you set the SYSDIR variable when 
 H building?
 
 I just have this in my kernel config:
 
 options OFED
 device  mlxen

Quick grep of the sys/ofed immediately shows the following:

sys/ofed/include/linux/wait.h:#include sys/param.h
sys/ofed/include/linux/wait.h:#include sys/systm.h
sys/ofed/include/linux/wait.h:#include sys/sleepqueue.h
sys/ofed/include/linux/wait.h:#include sys/kernel.h
sys/ofed/include/linux/wait.h:#include sys/proc.h

ys/ofed/include/linux/timer.h:#include sys/callout.h
sys/ofed/include/linux/types.h:#include sys/cdefs.h
sys/ofed/include/linux/types.h:#include sys/types.h
sys/ofed/include/linux/types.h:#include sys/param.h
sys/ofed/include/linux/types.h:#include sys/systm.h

and so on.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Konstantin Belousov]

On Tue, Mar 31, 2015 at 02:51:47AM +0300, Konstantin Belousov wrote:
 On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote:
  On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote:
  H On 03/30/15 23:19, Gleb Smirnoff wrote:
  H  On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
  H  M I get the following panic on current svn ver  r280793:
  H  M
  H  M Sat Mar 28 14:41:28 PDT 2015
  H  M
  H  M FreeBSD/amd64 (pozo.com) (ttyu0)
  H  M
  H  M panic: Invalid CPU in callout 16
  H 
  H  The same happened to me in the OFED code. After investigation
  H  it appeared that for some unknown reason, the OFED code used
  H  /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h,
  H  that yield in wrong value passing as parameter.
  H 
  H  I failed to reproduce the problem. :( So, the fix is a rebuild
  H  of kernel. But the right fix is to understand what went wrong
  H  in the previous build.
  H 
  H How did you compile the OFED stuff? Did you set the SYSDIR variable when 
  H building?
  
  I just have this in my kernel config:
  
  options OFED
  device  mlxen
 
 Quick grep of the sys/ofed immediately shows the following:
 
 sys/ofed/include/linux/wait.h:#include sys/param.h
 sys/ofed/include/linux/wait.h:#include sys/systm.h
 sys/ofed/include/linux/wait.h:#include sys/sleepqueue.h
 sys/ofed/include/linux/wait.h:#include sys/kernel.h
 sys/ofed/include/linux/wait.h:#include sys/proc.h
 
 ys/ofed/include/linux/timer.h:#include sys/callout.h
 sys/ofed/include/linux/types.h:#include sys/cdefs.h
 sys/ofed/include/linux/types.h:#include sys/types.h
 sys/ofed/include/linux/types.h:#include sys/param.h
 sys/ofed/include/linux/types.h:#include sys/systm.h
 
 and so on.

Err, I am sorry, scratch this.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Davide Italiano]

On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar n...@pozo.com wrote:
 I get the following panic on current svn ver  r280793:



Revert to r280784. This should fix.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Panic on current amd64

[Manfred Antar]

I get the following panic on current svn ver  r280793:

Sat Mar 28 14:41:28 PDT 2015

FreeBSD/amd64 (pozo.com) (ttyu0)

login: panic: Invalid CPU in callout 16
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe023705f370
panic() at panic+0x1c1/frame 0xfe023705f430
callout_reset_sbt_on() at callout_reset_sbt_on+0x3cc/frame 0xfe023705f4b0
nv_start_rc_timer() at nv_start_rc_timer+0x5b/frame 0xfe023705f4e0
_nv000780rm() at _nv000780rm+0x52c/frame 0xfe0001e8af88
dmapbase() at 0xf800b78c7000/frame 0xfe0001f18000
uart_sab82532_class() at 0/frame 0xfe0001e7b000
dmapbase() at 0xf800703a6500/frame 0xfe0001f1c000
(null)() at 0xf801f8ed6000/frame 0xfe0001f26000
uart_sab82532_class() at 0/frame 0xf801f8dbd000
uart_sab82532_class() at 0/frame 0xf8000f758800
uart_sab82532_class() at 0/frame 0xf801f8cac000
dmapbase() at 0xf8000f838400/frame 0xf800700b8800
uart_sab82532_class() at 0/frame 0xf8000f838000
uart_sab82532_class() at 0/frame 0xfe0001f3a000
uart_sab82532_class() at 0/frame 0xfe0001f3e000
uart_sab82532_class() at 0/frame 0xfe0001d5b000
dmapbase() at 0xf800703aaa00/frame 0xfe0001f4
uart_sab82532_class() at 0/frame 0xfe0001f42000
uart_sab82532_class() at 0/frame 0xf8000f76
dmapbase() at 0xf8000f867000/frame 0xf801f8cb3000
dmapbase() at 0xf8000d0ce800/frame 0xf800700b7000
dmapbase() at 0xf800052de000/frame 0xfe0001f52000
uart_sab82532_class() at 0/frame 0xfe0001f54000
uart_sab82532_class() at 0/frame 0xf801f8f85000
uart_sab82532_class() at 0/frame 0xfe0001f5c000
uart_sab82532_class() at 0/frame 0xf8000f833c00
uart_sab82532_class() at 0/frame 0xf8000f761800
uart_sab82532_class() at 0/frame 0xf8000f872800
uart_sab82532_class() at 0/frame 0xf8000f833800
uart_sab82532_class() at 0/frame 0xf800703bc000
uart_sab82532_class() at 0/frame 0xf801f8d04000
uart_sab82532_class() at 0/frame 0xfe0001f5e000
uart_sab82532_class() at 0/frame 0xfe0001f6
(null)() at 0xf801f860c200/frame 0xf8000f833400
uart_sab82532_class() at 0/frame 0xf8000f833000
uart_sab82532_class() at 0/frame 0xf8000f73b800
KDB: enter: panic
[ thread pid 1732 tid 100222 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why
db  

I just added device  uart_sab82532 to kernel config I'll try that
Manfred


||  n...@pozo.com   ||
||  ||
 



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current amd64

[Manfred Antar]

At 03:06 PM 3/28/2015, Davide Italiano wrote:
On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar n...@pozo.com wrote:
 I get the following panic on current svn ver  r280793:



Revert to r280784. This should fix.

That works 
Thanks


||  n...@pozo.com   ||
||  ||
 



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Memory modified after free Kernel panic with current (r278031)

[Luca Pizzamiglio]

Hallo,

I'm still fighting with MinnowBoard...
When I set the network interface I get a bunch of Memory modified
after free messages.
If I wait long enough (a couple of minutes) I get a kernel panic.

Here an example with the dmesg (https://pastebin.mozilla.org/8657938)

I've tested it using 10.1-STABLE, same messages after ifconfig, but
the kernel panic is different.
Here a verbose example of it (https://pastebin.mozilla.org/8658082)

On 10, I see really often the value 0x3201c040 causing segmentation
fault (!), but I don't know where it comes from.

I'm still debugging it, but it could be that the init procedure of
re(4) cannot correctly stop the device (a normal Realtek 8168) and the
dma address are rewritten by receiving packets.

Has someone some tip/ideas?

thanks in advance for the help

Best regards,
pizzamig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[R. Tyler Croy]

(follow up below)

On 04/01/2014 06:57, R. Tyler Croy wrote:

On Tue, 01 Apr 2014 09:41:45 +0300
Andriy Gapon a...@freebsd.org wrote:


on 01/04/2014 02:22 R. Tyler Croy said the following:

Bumping this with more details

On Fri, 28 Mar 2014 09:53:32 -0700
R Tyler Croy ty...@monkeypox.org wrote:


Apologies for the rough format here, I had to take a picture of
this failure because I didn't know what else to do.

http://www.flickr.com/photos/agentdero/13469355463/

I'm building off of the GitHub freebsd.git mirror here, and the
latest commit in the tree is neel@'s Add an ioctl to suspend..

My dmesg/pciconf are here:
https://gist.github.com/rtyler/1faa854dff7c4396d9e8

As linked before, the dmesg and `pciconf -lv` output can be found
here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8

Also in addition to the photo from before of the panic, here's
another reproduction photo:
https://www.flickr.com/photos/agentdero/13472248423/

Are you or have you even been running with any ZFS-related kernel
patches?

Negative, I've never run any specific ZFS patches on this machine (or
any machine for that matter!)

One other unique clue might be that I'm running with an encrypted
zpool, other than that, nothing fancy here.



I've upgraded my machine to r264387 and I still experience the issue, 
here's the latest pretty picture of my panicked laptop :) 
https://secure.flickr.com/photos/agentdero/13880032704/


The issue still seems to stem from a failed assertion in 
zap_leaf_lookup_closest() 
(http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c?revision=249195view=markup#l446) 
but I'm not sure which assertion might be failing.


This is somewhat problematic because I cannot perform *any* FS 
operations with the tainted directory tree, not even a `du -hcs *` to 
find out how much space I can never access again :P



I can reproduce this consistently, if anybody has the time to get onto 
IRC (rtyler on Freenode and EFNet) and debug this, I can certainly act 
as remote hands with kdb to help ascertain more information about the panic.



Cheers


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[Andriy Gapon]

on 01/04/2014 16:57 R. Tyler Croy said the following:
 On Tue, 01 Apr 2014 09:41:45 +0300
 Andriy Gapon a...@freebsd.org wrote:
 
 on 01/04/2014 02:22 R. Tyler Croy said the following:
...
 Also in addition to the photo from before of the panic, here's
 another reproduction photo:
 https://www.flickr.com/photos/agentdero/13472248423/

 Are you or have you even been running with any ZFS-related kernel
 patches?
 
 
 Negative, I've never run any specific ZFS patches on this machine (or
 any machine for that matter!)
 
 One other unique clue might be that I'm running with an encrypted
 zpool, other than that, nothing fancy here.

Your problem looks like a corruption of on-disk data.
I can not say how it came to be or how to fix it now.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[R. Tyler Croy]

On Wed, 02 Apr 2014 09:58:37 +0300
Andriy Gapon a...@freebsd.org wrote:

 on 01/04/2014 16:57 R. Tyler Croy said the following:
  On Tue, 01 Apr 2014 09:41:45 +0300
  Andriy Gapon a...@freebsd.org wrote:
  
  on 01/04/2014 02:22 R. Tyler Croy said the following:
 ...
  Also in addition to the photo from before of the panic, here's
  another reproduction photo:
  https://www.flickr.com/photos/agentdero/13472248423/
 
  Are you or have you even been running with any ZFS-related kernel
  patches?
  
  
  Negative, I've never run any specific ZFS patches on this machine
  (or any machine for that matter!)
  
  One other unique clue might be that I'm running with an encrypted
  zpool, other than that, nothing fancy here.
 
 Your problem looks like a corruption of on-disk data.
 I can not say how it came to be or how to fix it now.
 


This is concerning to me, I'm using an intel 128GB SSD which is less
than 6 months old. If there is an actual disk-level corruption,
shouldn't that manifest itself as a zpool error?


:/

-- 

- R. Tyler Croy

--
 Code: https://github.com/rtyler
  Chatter: https://twitter.com/agentdero

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[Andriy Gapon]

on 02/04/2014 19:48 R. Tyler Croy said the following:
 On Wed, 02 Apr 2014 09:58:37 +0300
 Andriy Gapon a...@freebsd.org wrote:
 
 on 01/04/2014 16:57 R. Tyler Croy said the following:
 On Tue, 01 Apr 2014 09:41:45 +0300
 Andriy Gapon a...@freebsd.org wrote:

 on 01/04/2014 02:22 R. Tyler Croy said the following:
 ...
 Also in addition to the photo from before of the panic, here's
 another reproduction photo:
 https://www.flickr.com/photos/agentdero/13472248423/

 Are you or have you even been running with any ZFS-related kernel
 patches?


 Negative, I've never run any specific ZFS patches on this machine
 (or any machine for that matter!)

 One other unique clue might be that I'm running with an encrypted
 zpool, other than that, nothing fancy here.

 Your problem looks like a corruption of on-disk data.
 I can not say how it came to be or how to fix it now.

 
 
 This is concerning to me, I'm using an intel 128GB SSD which is less
 than 6 months old. If there is an actual disk-level corruption,
 shouldn't that manifest itself as a zpool error?

I am afraid that this is a different kind of corruption.  Either a bug (possibly
old, already fixes) in ZFS or a corruption that happened in RAM before a buffer
was sent to a disk.


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[Andriy Gapon]

on 01/04/2014 02:22 R. Tyler Croy said the following:
 Bumping this with more details
 
 On Fri, 28 Mar 2014 09:53:32 -0700
 R Tyler Croy ty...@monkeypox.org wrote:
 
 Apologies for the rough format here, I had to take a picture of this
 failure because I didn't know what else to do.

 http://www.flickr.com/photos/agentdero/13469355463/

 I'm building off of the GitHub freebsd.git mirror here, and the
 latest commit in the tree is neel@'s Add an ioctl to suspend..

 My dmesg/pciconf are here:
 https://gist.github.com/rtyler/1faa854dff7c4396d9e8
 
 
 As linked before, the dmesg and `pciconf -lv` output can be found here:
 https://gist.github.com/rtyler/1faa854dff7c4396d9e8
 
 Also in addition to the photo from before of the panic, here's another
 reproduction photo:
 https://www.flickr.com/photos/agentdero/13472248423/

Are you or have you even been running with any ZFS-related kernel patches?

 I'm running -CURRENT as of r263881 right now, with a custom kernel
 which is built on top of the VT kernel
 (https://github.com/rtyler/freebsd/blob/5e324960f1f2b7079de369204fe228db4a2ec99d/sys/amd64/conf/KIWI)
 
 I'm able to get this panic *consistently* whenever a process accesses
 my maildir folder which I sync with the mbsync program (isync package),
 such as `mbsync personal` or when I back up the maildir with duplicity.
 The commonality seems to be listing or accessing portions of this file
 tree. Curiously enough it only seems to be isolated to that single
 portion of the filesystem tree.
 
 The zpool is also clean as far as errors go:
 
 [16:11:03] tyler:freebsd git:(master*) $ zpool status zroot
   pool: zroot
  state: ONLINE
 status: Some supported features are not enabled on the pool. The pool
 can still be used, but some features are unavailable.
 action: Enable all features using 'zpool upgrade'. Once this is done,
 the pool may no longer be accessible by software that does not
 support the features. See zpool-features(7) for details.
   scan: scrub repaired 0 in 0h18m with 0 errors on Fri Mar 28 11:55:03
 2014 config:

 NAME  STATE READ WRITE CKSUM
 zroot ONLINE   0 0 0
   ada0p3.eli  ONLINE   0 0 0

 errors: No known data errors
 [16:19:57] tyler:freebsd git:(master*) $ 
 
 
 I'm not sure what other data would be useful here, I can consistently
 see the panic, but this data is highly personal, so I'm not sure how
 much of a repro case I can give folks. :(
 
 Cheers
 


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[R. Tyler Croy]

On Tue, 01 Apr 2014 09:41:45 +0300
Andriy Gapon a...@freebsd.org wrote:

 on 01/04/2014 02:22 R. Tyler Croy said the following:
  Bumping this with more details
  
  On Fri, 28 Mar 2014 09:53:32 -0700
  R Tyler Croy ty...@monkeypox.org wrote:
  
  Apologies for the rough format here, I had to take a picture of
  this failure because I didn't know what else to do.
 
  http://www.flickr.com/photos/agentdero/13469355463/
 
  I'm building off of the GitHub freebsd.git mirror here, and the
  latest commit in the tree is neel@'s Add an ioctl to suspend..
 
  My dmesg/pciconf are here:
  https://gist.github.com/rtyler/1faa854dff7c4396d9e8
  
  
  As linked before, the dmesg and `pciconf -lv` output can be found
  here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8
  
  Also in addition to the photo from before of the panic, here's
  another reproduction photo:
  https://www.flickr.com/photos/agentdero/13472248423/
 
 Are you or have you even been running with any ZFS-related kernel
 patches?


Negative, I've never run any specific ZFS patches on this machine (or
any machine for that matter!)

One other unique clue might be that I'm running with an encrypted
zpool, other than that, nothing fancy here.



- R. Tyler Croy

--
 Code: https://github.com/rtyler
  Chatter: https://twitter.com/agentdero

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS panic in -CURRENT

[R. Tyler Croy]

Bumping this with more details

On Fri, 28 Mar 2014 09:53:32 -0700
R Tyler Croy ty...@monkeypox.org wrote:

 Apologies for the rough format here, I had to take a picture of this
 failure because I didn't know what else to do.
 
 http://www.flickr.com/photos/agentdero/13469355463/
 
 I'm building off of the GitHub freebsd.git mirror here, and the
 latest commit in the tree is neel@'s Add an ioctl to suspend..
 
 My dmesg/pciconf are here:
 https://gist.github.com/rtyler/1faa854dff7c4396d9e8


As linked before, the dmesg and `pciconf -lv` output can be found here:
https://gist.github.com/rtyler/1faa854dff7c4396d9e8

Also in addition to the photo from before of the panic, here's another
reproduction photo:
https://www.flickr.com/photos/agentdero/13472248423/

I'm running -CURRENT as of r263881 right now, with a custom kernel
which is built on top of the VT kernel
(https://github.com/rtyler/freebsd/blob/5e324960f1f2b7079de369204fe228db4a2ec99d/sys/amd64/conf/KIWI)

I'm able to get this panic *consistently* whenever a process accesses
my maildir folder which I sync with the mbsync program (isync package),
such as `mbsync personal` or when I back up the maildir with duplicity.
The commonality seems to be listing or accessing portions of this file
tree. Curiously enough it only seems to be isolated to that single
portion of the filesystem tree.

The zpool is also clean as far as errors go:

 [16:11:03] tyler:freebsd git:(master*) $ zpool status zroot
   pool: zroot
  state: ONLINE
 status: Some supported features are not enabled on the pool. The pool
 can still be used, but some features are unavailable.
 action: Enable all features using 'zpool upgrade'. Once this is done,
 the pool may no longer be accessible by software that does not
 support the features. See zpool-features(7) for details.
   scan: scrub repaired 0 in 0h18m with 0 errors on Fri Mar 28 11:55:03
 2014 config:
 
 NAME  STATE READ WRITE CKSUM
 zroot ONLINE   0 0 0
   ada0p3.eli  ONLINE   0 0 0
 
 errors: No known data errors
 [16:19:57] tyler:freebsd git:(master*) $ 


I'm not sure what other data would be useful here, I can consistently
see the panic, but this data is highly personal, so I'm not sure how
much of a repro case I can give folks. :(

Cheers
-- 

- R. Tyler Croy

--
 Code: https://github.com/rtyler
  Chatter: https://twitter.com/agentdero

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

ZFS panic in -CURRENT

[R Tyler Croy]

Apologies for the rough format here, I had to take a picture of this failure 
because I didn't know what else to do.

http://www.flickr.com/photos/agentdero/13469355463/

I'm building off of the GitHub freebsd.git mirror here, and the latest commit 
in the tree is neel@'s Add an ioctl to suspend..

My dmesg/pciconf are here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic with -CURRENT @Boot [r259130]

[Andreas Tobler]

On 10.12.13 03:52, Larry Rosenman wrote:
 On 2013-12-09 16:04, Aleksandr Rybalko wrote:
 On Mon, 9 Dec 2013 10:36:34 -0600
 Larry Rosenman l...@lerctr.org wrote:


 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Relative URL: ^/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 259130
 Node Kind: directory
 Schedule: normal
 Last Changed Author: ray
 Last Changed Rev: 259130
 Last Changed Date: 2013-12-09 09:28:34 -0600 (Mon, 09 Dec 2013)

 [[cut]]

 Can you please share core and kernel with modules.
 I'm not sure, but looks like it is related to vt (newcons).
 So I have to investigate.

 Thanks!

 WBW
 I've passed ray@ credentials to get at the core/kernel/etc on the system 
 that generated it.

I have a +2, the same panic as Larry plus another one on my Thinkpads.

The second panic looks like this:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x807b8147
stack pointer   = 0x28:0xfe00dd97f8e0
frame pointer   = 0x28:0x333231302f2e2d2c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1132 (vidcontrol)


I 'fixed' this with the attached patch. I have to test tomorrow if the
first panic (the one Larry sees) on my Dell also goes away with this 'fix'.

I compared with syscons.c and there the ival/data assigment is always
done inside the case label and not at the end.

maybe I'm papering over ... but at least a starting point to investigate.

Andreas


Index: dev/vt/vt_core.c
===
--- dev/vt/vt_core.c(revision 259154)
+++ dev/vt/vt_core.c(working copy)
@@ -1294,37 +1295,55 @@
switch (cmd) {
case _IO('v', 4):
cmd = VT_RELDISP;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('v', 5):
cmd = VT_ACTIVATE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('v', 6):
cmd = VT_WAITACTIVE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 20):
cmd = KDSKBSTATE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 67):
cmd = KDSETRAD;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 7):
cmd = KDSKBMODE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 8):
cmd = KDMKTONE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 63):
cmd = KIOCSOUND;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 66):
cmd = KDSETLED;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('c', 110):
cmd = CONS_SETKBD;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
}
-   ival = IOCPARM_IVAL(data);
-   data = (caddr_t)ival;
 #endif
 
switch (cmd) {
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic with -CURRENT @Boot [r259130]

[Aleksandr Rybalko]

On Mon, 9 Dec 2013 10:36:34 -0600
Larry Rosenman l...@lerctr.org wrote:

 
 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Relative URL: ^/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 259130
 Node Kind: directory
 Schedule: normal
 Last Changed Author: ray
 Last Changed Rev: 259130
 Last Changed Date: 2013-12-09 09:28:34 -0600 (Mon, 09 Dec 2013)
 
[[cut]]

Can you please share core and kernel with modules.
I'm not sure, but looks like it is related to vt (newcons).
So I have to investigate.

Thanks!

WBW
-- 
Aleksandr Rybalko r...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic with -CURRENT @Boot [r259130]

[Larry Rosenman]

On 2013-12-09 16:04, Aleksandr Rybalko wrote:

On Mon, 9 Dec 2013 10:36:34 -0600
Larry Rosenman l...@lerctr.org wrote:



Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 259130
Node Kind: directory
Schedule: normal
Last Changed Author: ray
Last Changed Rev: 259130
Last Changed Date: 2013-12-09 09:28:34 -0600 (Mon, 09 Dec 2013)


[[cut]]

Can you please share core and kernel with modules.
I'm not sure, but looks like it is related to vt (newcons).
So I have to investigate.

Thanks!

WBW
I've passed ray@ credentials to get at the core/kernel/etc on the system 
that generated it.


Thanks all.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)

[Olivier Cochard-Labbé]

On Tue, Sep 11, 2012 at 6:32 PM, Glen Barber g...@freebsd.org wrote:

 I'd blame this one:

 http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html


 Yes, reverting that commit allows the system to boot.


Hi,

Same problem on my side (under Virtualbox or on an IBM 3550 M2).

Regards,

Olivier
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)

[O. Hartmann]

Am 09/12/12 09:30, schrieb Olivier Cochard-Labbé:
 On Tue, Sep 11, 2012 at 6:32 PM, Glen Barber g...@freebsd.org wrote:

 I'd blame this one:

 http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html


 Yes, reverting that commit allows the system to boot.

 
 Hi,
 
 Same problem on my side (under Virtualbox or on an IBM 3550 M2).
 
 Regards,
 
 Olivier


That should be solved by now (at least with r240369.

I ran into the same problem on several FreeBSD 10.0-CURRENT boxes.

Oliver



















signature.asc
Description: OpenPGP digital signature

Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)

[Andriy Gapon]

on 12/09/2012 10:30 Olivier Cochard-Labbé said the following:
 On Tue, Sep 11, 2012 at 6:32 PM, Glen Barber g...@freebsd.org wrote:

 I'd blame this one:

 http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html


 Yes, reverting that commit allows the system to boot.

 
 Hi,
 
 Same problem on my side (under Virtualbox or on an IBM 3550 M2).

This should be fixed already.
Sorry for the breakage and for not writing about the fix to this thread.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[panic] 10-CURRENT r239865: General protection fault (sysctl)

[Glen Barber]

Hi,

I upgraded to head/ r239865 (Last Changed Date: 2012-09-11 09:29:50).

My laptop now panics with on boot with the new kernel.

Backtrace (and hopefully some useful) information is attached.  I can
provide any additional information necessary.

Regards,

Glen

Script started on Tue Sep 11 12:03:54 2012
root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug 
/var/crash/vmcore.3
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #29 r240362: Tue Sep 11 11:12:10 EDT 2012
root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Core(TM) i3 CPU   M 370  @ 2.40GHz (2394.06-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x20655  Family = 6  Model = 25  Stepping = 5
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  
Features2=0x9ae3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT
  AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 7867260928 (7502 MB)
Event timer LAPIC quality 600
ACPI APIC Table: ACRSYS ACRPRDCT
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  4
 cpu3 (AP): APIC ID:  5
ioapic0: Changing APIC ID to 2
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
ctl: CAM Target Layer loaded
cryptosoft0: software crypto on motherboard
acpi0: ACRSYS ACRPRDCT on motherboard
acpi0: Power Button (fixed)
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
cpu2: ACPI CPU on acpi0
cpu3: ACPI CPU on acpi0
hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter HPET frequency 14318180 Hz quality 950
Event timer HPET frequency 14318180 Hz quality 550
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
Event timer HPET3 frequency 14318180 Hz quality 440
Event timer HPET4 frequency 14318180 Hz quality 440
atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer RTC frequency 32768 Hz quality 0
attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
vgapci0: VGA-compatible display port 0x3050-0x3057 mem 
0xb000-0xb03f,0xa000-0xafff irq 16 at device 2.0 on pci0
pci0: simple comms at device 22.0 (no driver attached)
ehci0: Intel PCH USB 2.0 controller USB-B mem 0xb4405c00-0xb4405fff irq 16 at 
device 26.0 on pci0
usbus0: EHCI version 1.0
usbus0 on ehci0
hdac0: Intel 5 Series/3400 Series HDA Controller mem 0xb440-0xb4403fff 
irq 22 at device 27.0 on pci0
pcib1: ACPI PCI-PCI bridge at device 28.0 on pci0
pci1: ACPI PCI bus on pcib1
bge0: Broadcom BCM57780 A1, ASIC rev. 0x57780001 mem 0xb340-0xb340 
irq 16 at device 0.0 on pci1
bge0: CHIP ID 0x57780001; ASIC REV 0x57780; CHIP REV 0x577800; PCI-E
miibus0: MII bus on bge0
brgphy0: BCM57780 1000BASE-T media interface PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: Ethernet address: b8:70:f4:8a:b8:15
pcib2: ACPI PCI-PCI bridge at device 28.1 on pci0
pcib2: failed to allocate initial I/O port window: 0x1000-0x1fff
pci2: ACPI PCI bus on pcib2
ath0: Atheros 9287 mem 0xb240-0xb240 irq 17 at device 0.0 on pci2
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9287 mac 384.2 RF5133 phy 15.15
ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0
ehci1: Intel PCH USB 2.0 controller USB-A mem 0xb4405800-0xb4405bff irq 23 at 
device 29.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci1
pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0
pci3: ACPI PCI bus on pcib3
isab0: PCI-ISA bridge at 

Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)

[Gleb Smirnoff]

On Tue, Sep 11, 2012 at 12:12:34PM -0400, Glen Barber wrote:
G Hi,
G 
G I upgraded to head/ r239865 (Last Changed Date: 2012-09-11 09:29:50).
G 
G My laptop now panics with on boot with the new kernel.
G 
G Backtrace (and hopefully some useful) information is attached.  I can
G provide any additional information necessary.

I'd blame this one:

http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html

G Regards,
G 
G Glen
G 
G Script started on Tue Sep 11 12:03:54 2012
G root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug 
/var/crash/vmcore.3
G GNU gdb 6.1.1 [FreeBSD]
G Copyright 2004 Free Software Foundation, Inc.
G GDB is free software, covered by the GNU General Public License, and you are
G welcome to change it and/or distribute copies of it under certain conditions.
G Type show copying to see the conditions.
G There is absolutely no warranty for GDB.  Type show warranty for details.
G This GDB was configured as amd64-marcel-freebsd...
G 
G Unread portion of the kernel message buffer:
G Copyright (c) 1992-2012 The FreeBSD Project.
G Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
G The Regents of the University of California. All rights reserved.
G FreeBSD is a registered trademark of The FreeBSD Foundation.
G FreeBSD 10.0-CURRENT #29 r240362: Tue Sep 11 11:12:10 EDT 2012
G root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64
G WARNING: WITNESS option enabled, expect reduced performance.
G CPU: Intel(R) Core(TM) i3 CPU   M 370  @ 2.40GHz (2394.06-MHz K8-class 
CPU)
G   Origin = GenuineIntel  Id = 0x20655  Family = 6  Model = 25  Stepping = 5
G   
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
G   
Features2=0x9ae3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT
G   AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
G   AMD Features2=0x1LAHF
G   TSC: P-state invariant, performance statistics
G real memory  = 8589934592 (8192 MB)
G avail memory = 7867260928 (7502 MB)
G Event timer LAPIC quality 600
G ACPI APIC Table: ACRSYS ACRPRDCT
G FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
G FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads
G  cpu0 (BSP): APIC ID:  0
G  cpu1 (AP): APIC ID:  1
G  cpu2 (AP): APIC ID:  4
G  cpu3 (AP): APIC ID:  5
G ioapic0: Changing APIC ID to 2
G ioapic0 Version 2.0 irqs 0-23 on motherboard
G kbd1 at kbdmux0
G ctl: CAM Target Layer loaded
G cryptosoft0: software crypto on motherboard
G acpi0: ACRSYS ACRPRDCT on motherboard
G acpi0: Power Button (fixed)
G cpu0: ACPI CPU on acpi0
G cpu1: ACPI CPU on acpi0
G cpu2: ACPI CPU on acpi0
G cpu3: ACPI CPU on acpi0
G hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
G Timecounter HPET frequency 14318180 Hz quality 950
G Event timer HPET frequency 14318180 Hz quality 550
G Event timer HPET1 frequency 14318180 Hz quality 440
G Event timer HPET2 frequency 14318180 Hz quality 440
G Event timer HPET3 frequency 14318180 Hz quality 440
G Event timer HPET4 frequency 14318180 Hz quality 440
G atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
G atrtc0: Warning: Couldn't map I/O.
G Event timer RTC frequency 32768 Hz quality 0
G attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 0 on acpi0
G Timecounter i8254 frequency 1193182 Hz quality 0
G Event timer i8254 frequency 1193182 Hz quality 100
G Timecounter ACPI-fast frequency 3579545 Hz quality 900
G acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
G acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0
G pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
G pci0: ACPI PCI bus on pcib0
G vgapci0: VGA-compatible display port 0x3050-0x3057 mem 
0xb000-0xb03f,0xa000-0xafff irq 16 at device 2.0 on pci0
G pci0: simple comms at device 22.0 (no driver attached)
G ehci0: Intel PCH USB 2.0 controller USB-B mem 0xb4405c00-0xb4405fff irq 16 
at device 26.0 on pci0
G usbus0: EHCI version 1.0
G usbus0 on ehci0
G hdac0: Intel 5 Series/3400 Series HDA Controller mem 0xb440-0xb4403fff 
irq 22 at device 27.0 on pci0
G pcib1: ACPI PCI-PCI bridge at device 28.0 on pci0
G pci1: ACPI PCI bus on pcib1
G bge0: Broadcom BCM57780 A1, ASIC rev. 0x57780001 mem 0xb340-0xb340 
irq 16 at device 0.0 on pci1
G bge0: CHIP ID 0x57780001; ASIC REV 0x57780; CHIP REV 0x577800; PCI-E
G miibus0: MII bus on bge0
G brgphy0: BCM57780 1000BASE-T media interface PHY 1 on miibus0
G brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
G bge0: Ethernet address: b8:70:f4:8a:b8:15
G pcib2: ACPI PCI-PCI bridge at device 28.1 on pci0
G pcib2: failed to allocate initial I/O port window: 0x1000-0x1fff
G pci2: ACPI PCI bus on pcib2
G ath0: Atheros 9287 mem 0xb240-0xb240 irq 17 at device 0.0 on pci2
G ath0: [HT] enabling HT modes
G ath0: [HT] enabling short-GI in 20MHz mode
G ath0: [HT] 2 RX 

Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)

[Glen Barber]

Hi,

On Tue, Sep 11, 2012 at 08:19:54PM +0400, Gleb Smirnoff wrote:
 G I upgraded to head/ r239865 (Last Changed Date: 2012-09-11 09:29:50).
 G 
 G My laptop now panics with on boot with the new kernel.
 G 
 
 I'd blame this one:
 
 http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html
 

Yes, reverting that commit allows the system to boot.

Glen



pgpGgiRkfTCUm.pgp
Description: PGP signature

Re: Tmpfs panic in -current

[Gleb Kurtsou]

On (27/06/2012 13:29), Kevin Lo wrote:
 Kevin Lo wrote:
  Konstantin Belousov wrote:
   On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
 On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
  I've observed a panic in recent -current several times but I only
  have a picture of the backtrace:
  http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
  
  Does this look at all familiar to anyone?
 
 Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
 address
 in your kernel ?

Sure.

 The screenshot looks strange. The instruction on which the kernel 
 trapped
 is int 0x28 which should not appear in the compiled code.

Kevin, do you have fuse modules loaded? It looks much like memmory
corruption issue.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Kevin Lo]

On 四, 2012-06-28 at 10:09 +0300, Gleb Kurtsou wrote:
 On (27/06/2012 13:29), Kevin Lo wrote:
  Kevin Lo wrote:
   Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
   I've observed a panic in recent -current several times but I only
   have a picture of the backtrace:
   http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
   
   Does this look at all familiar to anyone?
  
  Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
  address
  in your kernel ?
 
 Sure.
 
  The screenshot looks strange. The instruction on which the kernel 
  trapped
  is int 0x28 which should not appear in the compiled code.
 
 Kevin, do you have fuse modules loaded? It looks much like memmory
 corruption issue.

No, I don't have that module loaded.
# kldstat
Id Refs AddressSize Name
 1   14 0xc040 bab9e8   kernel
 21 0xc0fac000 1d58 msdosfs_iconv.ko
 32 0xc0fae000 67a8 libiconv.ko
 41 0xc728e000 9000 tmpfs.ko
 51 0xc789b000 4000 uhid.ko



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andriy Gapon]

on 27/06/2012 08:27 Andrey Fesenko said the following:
 On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky
 erichfreebsdl...@ovitrap.com wrote:
 Hi,

 I am getting a panix when I boot a newly compiled system with sources 
 downloaded yesterday. The panic was still there with the sources from three 
 days ago.

 The panic regards /usr/src/sys/vm/uma_core/c line 2040.

 The machine is a Lenovo X220. I do not expect anything specific loaded yet 
 as I load the Intel KMS module manually after the system is up and running 
 on the console.

 
 confirm faced with the same error
 FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565

You haven't provided a full stack trace, but let me take a guess:
http://article.gmane.org/gmane.os.freebsd.devel.cvs/477167
Perhaps this could be useful.

-- 
Andriy Gapon

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Erich Dollansky]

Hi,

On Wednesday 27 June 2012 13:20:10 Andriy Gapon wrote:
 on 27/06/2012 08:27 Andrey Fesenko said the following:
  On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky
  erichfreebsdl...@ovitrap.com wrote:
  Hi,
 
  I am getting a panix when I boot a newly compiled system with sources 
  downloaded yesterday. The panic was still there with the sources from 
  three days ago.
 
  The panic regards /usr/src/sys/vm/uma_core/c line 2040.
 
  The machine is a Lenovo X220. I do not expect anything specific loaded yet 
  as I load the Intel KMS module manually after the system is up and running 
  on the console.
 
  
  confirm faced with the same error
  FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565
 
 You haven't provided a full stack trace, but let me take a guess:
 http://article.gmane.org/gmane.os.freebsd.devel.cvs/477167

this is a direct hit.

 Perhaps this could be useful.

I assume that you do not need one then.

Anyway, What would be a save way to get a trace to a disk as I do not have a 
backup system with me?

Erich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andriy Gapon]

on 27/06/2012 11:39 Erich Dollansky said the following:
 Anyway, What would be a save way to get a trace to a disk as I do not have a
 backup system with me?

Assuming I understand the question correctly your options are:
- remote console (serial/firewire/etc) from another machine
- digital camera
- produce a crash dump (possible only after a certain point in boot sequence)

-- 
Andriy Gapon


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Erich Dollansky]

Hi,

On Wednesday 27 June 2012 15:42:43 Andriy Gapon wrote:
 on 27/06/2012 11:39 Erich Dollansky said the following:
  Anyway, What would be a save way to get a trace to a disk as I do not have a
  backup system with me?
 
 Assuming I understand the question correctly your options are:
 - remote console (serial/firewire/etc) from another machine

this is the problem as I do not have it here.

 - digital camera

So, this is really the only option then.

The photos I really have. Would you still need them? I do not think so after 
seeing the other post.

 - produce a crash dump (possible only after a certain point in boot sequence)

I think that this was too early.

Erich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andrey Fesenko]

On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote:
 on 27/06/2012 11:39 Erich Dollansky said the following:
 Anyway, What would be a save way to get a trace to a disk as I do not have a
 backup system with me?

 Assuming I understand the question correctly your options are:
 - remote console (serial/firewire/etc) from another machine
 - digital camera
 - produce a crash dump (possible only after a certain point in boot sequence)


FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631

https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg

In the VirtualBox this system boot no error.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andriy Gapon]

on 27/06/2012 11:49 Erich Dollansky said the following:
 Hi,
 
 On Wednesday 27 June 2012 15:42:43 Andriy Gapon wrote:
 on 27/06/2012 11:39 Erich Dollansky said the following:
 Anyway, What would be a save way to get a trace to a disk as I do not have a
 backup system with me?

 Assuming I understand the question correctly your options are:
 - remote console (serial/firewire/etc) from another machine
 
 this is the problem as I do not have it here.
 
 - digital camera
 
 So, this is really the only option then.
 
 The photos I really have. Would you still need them? I do not think so after 
 seeing the other post.

Not really, I think that you've already confirmed that that is the same issue.
I just listed possibilities for future reference.

 - produce a crash dump (possible only after a certain point in boot sequence)
 
 I think that this was too early.

Yes.

-- 
Andriy Gapon


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andrey Fesenko]

On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko f0and...@gmail.com wrote:
 On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote:
 on 27/06/2012 11:39 Erich Dollansky said the following:
 Anyway, What would be a save way to get a trace to a disk as I do not have a
 backup system with me?

 Assuming I understand the question correctly your options are:
 - remote console (serial/firewire/etc) from another machine
 - digital camera
 - produce a crash dump (possible only after a certain point in boot sequence)


 FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631

 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg

 In the VirtualBox this system boot no error.

FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun
27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC
amd64

if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andriy Gapon]

on 27/06/2012 13:44 Andrey Fesenko said the following:
 On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko f0and...@gmail.com wrote:
 On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote:
 on 27/06/2012 11:39 Erich Dollansky said the following:
 Anyway, What would be a save way to get a trace to a disk as I do not have 
 a
 backup system with me?

 Assuming I understand the question correctly your options are:
 - remote console (serial/firewire/etc) from another machine
 - digital camera
 - produce a crash dump (possible only after a certain point in boot 
 sequence)


 FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631

 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg

 In the VirtualBox this system boot no error.
 
 FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun
 27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC
 amd64
 
 if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error
 

Thank you for the confirmation.

-- 
Andriy Gapon


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Removing an SDHC card causes a kernel panic on -current

[Michael Butler]

On 06/26/12 22:29, Kenneth D. Merry wrote:
 On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote:
 On Tue, 26 Jun 2012, Michael Butler wrote:

 As follows, in g_disk_providergone, a NULL pointer reference?:

 g_disk_providergone() is new in r237518 (by ken); ken cc'd.
 
 Can you try the attached patch to sys/geom/geom_disk.c?

This fixes the panic :-)

 
 Also, do you have full dmesg information for when the panic happened?
 
 It looks like disk_destroy() has already been called in this case, and I
 suppose that's likely to happen for any of the users of the GEOM disk class
 that haven't been updated with the reference count changes I made in da(4).
 (i.e. all of the rest of them.)
 
 Let me know whether this works for you.

All I have is the following leading up to my removal of the card (and
the restart afterwards):

Jun 26 08:57:11 toshi kernel: sdhci0-slot0: Card inserted
Jun 26 08:57:11 toshi kernel: mmc0: MMC/SD bus on sdhci0
Jun 26 08:57:11 toshi kernel: mmc0: Probing bus
Jun 26 08:57:11 toshi kernel: mmc0: SD probe: OK (OCR: 0x00ff8000)
Jun 26 08:57:11 toshi kernel: mmc0: Current OCR: 0x00ff8000
Jun 26 08:57:11 toshi kernel: mmc0: Probing cards
Jun 26 08:57:11 toshi kernel: mmc0: New card detected (CID
03534453553136478080d4290400a300)
Jun 26 08:57:11 toshi kernel: mmc0: New card detected (CSD
400e00325b5976b27f800a404000)
Jun 26 08:57:11 toshi kernel: mmc0: Card at relative address 36832 added:
Jun 26 08:57:11 toshi kernel: mmc0:  card: SDHC SU16G 8.0 SN -2133579516
MFG 03/2010 by 3 SD
Jun 26 08:57:11 toshi kernel: mmc0:  bus: 4bit, 50MHz, high speed timing
Jun 26 08:57:11 toshi kernel: mmc0:  memory: 31116288 blocks, erase
sector 8192 blocks
Jun 26 08:57:12 toshi kernel: mmc0: setting transfer rate to 25.000MHz
Jun 26 08:57:12 toshi kernel: mmcsd0: 14GB SDHC SU16G 8.0 SN
-2133579516 MFG 03/2010 by 3 SD at mmc0 24.0MHz/4bit/65535-block
Jun 26 08:57:12 toshi kernel: GEOM: new disk mmcsd0
Jun 26 08:57:12 toshi kernel: mmc0: setting bus width to 4 bits

Jun 26 08:58:44 toshi syslogd: kernel boot file is /boot/kernel/kernel
Jun 26 08:58:44 toshi kernel: Copyright (c) 1992-2012 The FreeBSD Project.
Jun 26 08:58:44 toshi kernel: Copyright (c) 1979, 1980, 1983, 1986,
1988, 1989, 1991, 1992, 1993, 1994
Jun 26 08:58:44 toshi kernel: The Regents of the University of
California. All rights reserved.
Jun 26 08:58:44 toshi kernel: FreeBSD is a registered trademark of The
FreeBSD Foundation.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Konstantin Belousov]

On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
 Kevin Lo wrote:
  Konstantin Belousov wrote:
   On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
 On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
  I've observed a panic in recent -current several times but I only
  have a picture of the backtrace:
  http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
  
  Does this look at all familiar to anyone?
 
 Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
 address
 in your kernel ?

Sure.

 The screenshot looks strange. The instruction on which the kernel 
 trapped
 is int 0x28 which should not appear in the compiled code.

# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize 
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c

In tmpfs_subr.c:
 999 if (m != NULL) {
1000 if ((m-oflags  VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == 
VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, 
NULL, NU
LL)) {

   Hm, can you get a core and
   - obtain backtrace in kgdb;
   - print the *m content for the page that triggered the assertion ?
   
   The only possible 'new size' value for the truncation from open(2) is 
   zero,
   so I do not understand why the asserted block was executed at all.
  
  Thanks for looking into it. Unfortunately I can't get a crash dump 
  due to lack of disk space and memory.
 
 I triggered the KASSERT on a different machine in the last hour.
It is not 'the' KASSERT, it is something different.

Are you sure that you do not have some systematic build issues on your
machines ? Although I do not think that tmpfs is 'ready for production use'
for arbitrary low value of this statement, there is no steady flow of
similar reports from other users. This makes me somewhat suspicious that
either you might have inconsistent build issues, or unrelated memory
corruption problems.

 
 panic: Assertion (vp) !=NULL  (vp)-v_data != NULL failed at 
 @/fs/tmpfs/tmpfs.h:527
 
 The bad news is my coworker rebooted that machine after panic :-(
 
   Kevin


pgpNw7ZYZRW88.pgp
Description: PGP signature

Re: Removing an SDHC card causes a kernel panic on -current

[Kenneth D. Merry]

On Wed, Jun 27, 2012 at 10:22:59 -0400, Michael Butler wrote:
 On 06/26/12 22:29, Kenneth D. Merry wrote:
  On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote:
  On Tue, 26 Jun 2012, Michael Butler wrote:
 
  As follows, in g_disk_providergone, a NULL pointer reference?:
 
  g_disk_providergone() is new in r237518 (by ken); ken cc'd.
  
  Can you try the attached patch to sys/geom/geom_disk.c?
 
 This fixes the panic :-)

Great!  I just committed it.

  Also, do you have full dmesg information for when the panic happened?
  
  It looks like disk_destroy() has already been called in this case, and I
  suppose that's likely to happen for any of the users of the GEOM disk class
  that haven't been updated with the reference count changes I made in da(4).
  (i.e. all of the rest of them.)
  
  Let me know whether this works for you.
 
 All I have is the following leading up to my removal of the card (and
 the restart afterwards):

Thanks!

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2012-06-27 07:07:40 -0400, Andriy Gapon wrote:
 on 27/06/2012 13:44 Andrey Fesenko said the following:
 On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko
 f0and...@gmail.com wrote:
 On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon
 a...@freebsd.org wrote:
 on 27/06/2012 11:39 Erich Dollansky said the following:
 Anyway, What would be a save way to get a trace to a disk
 as I do not have a backup system with me?
 
 Assuming I understand the question correctly your options
 are: - remote console (serial/firewire/etc) from another
 machine - digital camera - produce a crash dump (possible
 only after a certain point in boot sequence)
 
 
 FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631
 
 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg


 
In the VirtualBox this system boot no error.
 
 FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M:
 Wed Jun 27 13:51:55 MSK 2012
 root@bsdx220:/usr/obj/usr/src/sys/GENERIC amd64
 
 if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no
 error
 
 
 Thank you for the confirmation.
 

Committed as r237652:

http://svnweb.freebsd.org/base?view=revisionrevision=237652

I really wanted to get confirmation from ACPICA developers first but I
had no choice. :-(

Sorry for the delay,

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/rMrkACgkQmlay1b9qnVOg5gCeNcFWPjIcqTN3DyQttmtLC5bN
EskAn083+eY8WWer4AFhYtT5pkmkmV+F
=PKC4
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Kevin Lo]

Konstantin Belousov wrote:
 On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
  Kevin Lo wrote:
   Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
   I've observed a panic in recent -current several times but I only
   have a picture of the backtrace:
   http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
   
   Does this look at all familiar to anyone?
  
  Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
  address
  in your kernel ?
 
 Sure.
 
  The screenshot looks strange. The instruction on which the kernel 
  trapped
  is int 0x28 which should not appear in the compiled code.
 
 # gdb tmpfs.ko
 (gdb) l *tmpfs_reg_resize+0x627
 0xbf37 is in tmpfs_reg_resize 
 (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
 1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
 
 In tmpfs_subr.c:
  999 if (m != NULL) {
 1000 if ((m-oflags  VPO_BUSY) != 0 
 ||
 1001 m-busy != 0) {
 1002 vm_page_sleep(m, 
 tmfssz);
 1003 goto retry;
 1004 }
 1005 MPASS(m-valid == 
 VM_PAGE_BITS_ALL);
 1006 } else if (vm_pager_has_page(uobj, idx, 
 NULL, NU
 LL)) {
 
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?

The only possible 'new size' value for the truncation from open(2) is 
zero,
so I do not understand why the asserted block was executed at all.
   
   Thanks for looking into it. Unfortunately I can't get a crash dump 
   due to lack of disk space and memory.
  
  I triggered the KASSERT on a different machine in the last hour.
 It is not 'the' KASSERT, it is something different.
 
 Are you sure that you do not have some systematic build issues on your
 machines ? Although I do not think that tmpfs is 'ready for production use'
 for arbitrary low value of this statement, there is no steady flow of
 similar reports from other users. This makes me somewhat suspicious that
 either you might have inconsistent build issues, or unrelated memory
 corruption problems.

As I mentioned, I'm running -CURRENT on a number of systems.
I haven't seen tmpfs panics on machines running FreeBSD 9.

Kevin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Erich Dollansky]

Hi,

On Wednesday 27 June 2012 23:20:09 Jung-uk Kim wrote:
 On 2012-06-27 07:07:40 -0400, Andriy Gapon wrote:
  on 27/06/2012 13:44 Andrey Fesenko said the following:
  On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko
  f0and...@gmail.com wrote:
  On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon
  a...@freebsd.org wrote:

 Committed as r237652:
 
 http://svnweb.freebsd.org/base?view=revisionrevision=237652
 
I updated my sources around midnight (GMT) and compiled them again. The system 
then booted without any problems.

Perfect!

Erich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Konstantin Belousov]

On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
   I've observed a panic in recent -current several times but I only
   have a picture of the backtrace:
   http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
   
   Does this look at all familiar to anyone?
  
  Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
  in your kernel ?
 
 Sure.
 
  The screenshot looks strange. The instruction on which the kernel trapped
  is int 0x28 which should not appear in the compiled code.
 
 # gdb tmpfs.ko
 (gdb) l *tmpfs_reg_resize+0x627
 0xbf37 is in tmpfs_reg_resize 
 (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
 1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
 
 In tmpfs_subr.c:
  999 if (m != NULL) {
 1000 if ((m-oflags  VPO_BUSY) != 0 ||
 1001 m-busy != 0) {
 1002 vm_page_sleep(m, tmfssz);
 1003 goto retry;
 1004 }
 1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
 1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU
 LL)) {
 
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?

The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.


pgpcAmL5mkan1.pgp
Description: PGP signature

Removing an SDHC card causes a kernel panic on -current

[Michael Butler]

As follows, in g_disk_providergone, a NULL pointer reference?:

imb@toshi:/home/imb sudo less /var/crash/core.txt.4
toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4

Tue Jun 26 08:59:01 EDT 2012

FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD
10.0-CURRENT #12 r237599M: Tue Jun 26 07:52:01 EDT 2012
i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI
 i386

panic: page fault

[ .. ]

Unread portion of the kernel message buffer:
sdhci0-slot0: Card removed
mmc0: detached

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc070a4bc
stack pointer   = 0x28:0xc6fb7c54
frame pointer   = 0x28:0xc6fb7c54
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14 (g_event)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 7m8s
Physical memory: 3045 MB
Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10

Reading symbols from /boot/kernel/drm.ko...Reading symbols from
/boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/i915.ko...Reading symbols from
/boot/kernel/i915.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/i915.ko
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/modules/cuse4bsd.ko...done.
Loaded symbols for /boot/modules/cuse4bsd.ko
Reading symbols from /boot/modules/vboxnetflt.ko...done.
Loaded symbols for /boot/modules/vboxnetflt.ko
Reading symbols from /boot/modules/vboxnetadp.ko...done.
Loaded symbols for /boot/modules/vboxnetadp.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
#0  doadump (textdump=1) at pcpu.h:244
244 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=1) at pcpu.h:244
#1  0xc07ae76c in kern_reboot (howto=260)
at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:449
#2  0xc07aee41 in panic (fmt=0x104 Address 0x104 out of bounds)
at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:637
#3  0xc0af13d1 in trap_fatal (frame=0xc6fb7c14, eva=40)
at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1022
#4  0xc0af16a8 in trap_pfault (frame=0xc6fb7c14, usermode=0, eva=0)
at /usr/home/imb/svn/head/sys/i386/i386/trap.c:936
#5  0xc0af29ef in trap (frame=0xc6fb7c14)
at /usr/home/imb/svn/head/sys/i386/i386/trap.c:546
#6  0xc0adcbdc in calltrap ()
at /usr/home/imb/svn/head/sys/i386/i386/exception.s:169
#7  0xc070a4bc in g_disk_providergone (pp=0xcb33ab80)
at /usr/home/imb/svn/head/sys/geom/geom_disk.c:505
#8  0xc070f8ba in g_destroy_provider (pp=0xcb33ab80)
at /usr/home/imb/svn/head/sys/geom/geom_subr.c:643
#9  0xc070fb6e in g_wither_washer ()
at /usr/home/imb/svn/head/sys/geom/geom_subr.c:462
#10 0xc070cb62 in g_run_events ()
at /usr/home/imb/svn/head/sys/geom/geom_event.c:289
#11 0xc077bd8b in fork_exit (callout=0xc070de54 g_event_procbody,
arg=0x0,
frame=0xc6fb7d08) at /usr/home/imb/svn/head/sys/kern/kern_fork.c:995
#12 0xc0adcc84 in fork_trampoline ()
at /usr/home/imb/svn/head/sys/i386/i386/exception.s:276
(kgdb)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Removing an SDHC card causes a kernel panic on -current

[Benjamin Kaduk]

On Tue, 26 Jun 2012, Michael Butler wrote:


As follows, in g_disk_providergone, a NULL pointer reference?:


g_disk_providergone() is new in r237518 (by ken); ken cc'd.

-Ben Kaduk



imb@toshi:/home/imb sudo less /var/crash/core.txt.4
toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4

Tue Jun 26 08:59:01 EDT 2012

FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD
10.0-CURRENT #12 r237599M: Tue Jun 26 07:52:01 EDT 2012
i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI
i386

panic: page fault

[ .. ]

Unread portion of the kernel message buffer:
sdhci0-slot0: Card removed
mmc0: detached

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc070a4bc
stack pointer   = 0x28:0xc6fb7c54
frame pointer   = 0x28:0xc6fb7c54
code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14 (g_event)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 7m8s
Physical memory: 3045 MB
Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10

Reading symbols from /boot/kernel/drm.ko...Reading symbols from
/boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/i915.ko...Reading symbols from
/boot/kernel/i915.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/i915.ko
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/modules/cuse4bsd.ko...done.
Loaded symbols for /boot/modules/cuse4bsd.ko
Reading symbols from /boot/modules/vboxnetflt.ko...done.
Loaded symbols for /boot/modules/vboxnetflt.ko
Reading symbols from /boot/modules/vboxnetadp.ko...done.
Loaded symbols for /boot/modules/vboxnetadp.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
#0  doadump (textdump=1) at pcpu.h:244
244 pcpu.h: No such file or directory.
   in pcpu.h
(kgdb) #0  doadump (textdump=1) at pcpu.h:244
#1  0xc07ae76c in kern_reboot (howto=260)
   at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:449
#2  0xc07aee41 in panic (fmt=0x104 Address 0x104 out of bounds)
   at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:637
#3  0xc0af13d1 in trap_fatal (frame=0xc6fb7c14, eva=40)
   at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1022
#4  0xc0af16a8 in trap_pfault (frame=0xc6fb7c14, usermode=0, eva=0)
   at /usr/home/imb/svn/head/sys/i386/i386/trap.c:936
#5  0xc0af29ef in trap (frame=0xc6fb7c14)
   at /usr/home/imb/svn/head/sys/i386/i386/trap.c:546
#6  0xc0adcbdc in calltrap ()
   at /usr/home/imb/svn/head/sys/i386/i386/exception.s:169
#7  0xc070a4bc in g_disk_providergone (pp=0xcb33ab80)
   at /usr/home/imb/svn/head/sys/geom/geom_disk.c:505
#8  0xc070f8ba in g_destroy_provider (pp=0xcb33ab80)
   at /usr/home/imb/svn/head/sys/geom/geom_subr.c:643
#9  0xc070fb6e in g_wither_washer ()
   at /usr/home/imb/svn/head/sys/geom/geom_subr.c:462
#10 0xc070cb62 in g_run_events ()
   at /usr/home/imb/svn/head/sys/geom/geom_event.c:289
#11 0xc077bd8b in fork_exit (callout=0xc070de54 g_event_procbody,
arg=0x0,
   frame=0xc6fb7d08) at /usr/home/imb/svn/head/sys/kern/kern_fork.c:995
#12 0xc0adcc84 in fork_trampoline ()
   at /usr/home/imb/svn/head/sys/i386/i386/exception.s:276
(kgdb)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Kevin Lo]

Konstantin Belousov wrote:
 On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
  Konstantin Belousov wrote:
   On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg

Does this look at all familiar to anyone?
   
   Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
   in your kernel ?
  
  Sure.
  
   The screenshot looks strange. The instruction on which the kernel trapped
   is int 0x28 which should not appear in the compiled code.
  
  # gdb tmpfs.ko
  (gdb) l *tmpfs_reg_resize+0x627
  0xbf37 is in tmpfs_reg_resize 
  (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
  1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
  
  In tmpfs_subr.c:
   999 if (m != NULL) {
  1000 if ((m-oflags  VPO_BUSY) != 0 ||
  1001 m-busy != 0) {
  1002 vm_page_sleep(m, tmfssz);
  1003 goto retry;
  1004 }
  1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
  1006 } else if (vm_pager_has_page(uobj, idx, NULL, 
  NU
  LL)) {
  
 Hm, can you get a core and
 - obtain backtrace in kgdb;
 - print the *m content for the page that triggered the assertion ?
 
 The only possible 'new size' value for the truncation from open(2) is zero,
 so I do not understand why the asserted block was executed at all.

Thanks for looking into it. Unfortunately I can't get a crash dump 
due to lack of disk space and memory.

Kevin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Removing an SDHC card causes a kernel panic on -current

[Kenneth D. Merry]

On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote:
 On Tue, 26 Jun 2012, Michael Butler wrote:
 
 As follows, in g_disk_providergone, a NULL pointer reference?:
 
 g_disk_providergone() is new in r237518 (by ken); ken cc'd.

Can you try the attached patch to sys/geom/geom_disk.c?

Also, do you have full dmesg information for when the panic happened?

It looks like disk_destroy() has already been called in this case, and I
suppose that's likely to happen for any of the users of the GEOM disk class
that haven't been updated with the reference count changes I made in da(4).
(i.e. all of the rest of them.)

Let me know whether this works for you.

Thanks,

Ken
-- 
Kenneth Merry
k...@freebsd.org
 //depot/users/kenm/FreeBSD-test2/sys/geom/geom_disk.c#7 - 
/usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/geom/geom_disk.c 
*** /tmp/tmp.75357.20   Tue Jun 26 20:25:44 2012
--- /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/geom/geom_disk.cTue Jun 
26 20:25:29 2012
***
*** 502,507 
--- 502,515 
struct g_disk_softc *sc;
  
sc = (struct g_disk_softc *)pp-geom-softc;
+ 
+   /*
+* If the softc is already NULL, then we've probably been through
+* g_disk_destroy already; there is nothing for us to do anyway.
+*/
+   if (sc == NULL)
+   return;
+ 
dp = sc-dp;
  
if (dp-d_gone != NULL)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Panic on current from yesterday during boot

[Erich Dollansky]

Hi,

I am getting a panix when I boot a newly compiled system with sources 
downloaded yesterday. The panic was still there with the sources from three 
days ago.

The panic regards /usr/src/sys/vm/uma_core/c line 2040.

The machine is a Lenovo X220. I do not expect anything specific loaded yet as I 
load the Intel KMS module manually after the system is up and running on the 
console.

How could I help you there?

I would need some hand holding there as I am travelling at the moment and have 
only this machine with me without much documentation available.

Moving back to this

FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Thu Jun 21 
14:29:15 WIT 2012

solves the problem for me.

Erich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current from yesterday during boot

[Andrey Fesenko]

On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky
erichfreebsdl...@ovitrap.com wrote:
 Hi,

 I am getting a panix when I boot a newly compiled system with sources 
 downloaded yesterday. The panic was still there with the sources from three 
 days ago.

 The panic regards /usr/src/sys/vm/uma_core/c line 2040.

 The machine is a Lenovo X220. I do not expect anything specific loaded yet as 
 I load the Intel KMS module manually after the system is up and running on 
 the console.


confirm faced with the same error
FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Kevin Lo]

Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
   Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
 I've observed a panic in recent -current several times but I only
 have a picture of the backtrace:
 http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
 
 Does this look at all familiar to anyone?

Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
address
in your kernel ?
   
   Sure.
   
The screenshot looks strange. The instruction on which the kernel 
trapped
is int 0x28 which should not appear in the compiled code.
   
   # gdb tmpfs.ko
   (gdb) l *tmpfs_reg_resize+0x627
   0xbf37 is in tmpfs_reg_resize 
   (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
   1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
   
   In tmpfs_subr.c:
999 if (m != NULL) {
   1000 if ((m-oflags  VPO_BUSY) != 0 ||
   1001 m-busy != 0) {
   1002 vm_page_sleep(m, tmfssz);
   1003 goto retry;
   1004 }
   1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
   1006 } else if (vm_pager_has_page(uobj, idx, 
   NULL, NU
   LL)) {
   
  Hm, can you get a core and
  - obtain backtrace in kgdb;
  - print the *m content for the page that triggered the assertion ?
  
  The only possible 'new size' value for the truncation from open(2) is zero,
  so I do not understand why the asserted block was executed at all.
 
 Thanks for looking into it. Unfortunately I can't get a crash dump 
 due to lack of disk space and memory.

I triggered the KASSERT on a different machine in the last hour.

panic: Assertion (vp) !=NULL  (vp)-v_data != NULL failed at 
@/fs/tmpfs/tmpfs.h:527

The bad news is my coworker rebooted that machine after panic :-(

Kevin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Konstantin Belousov]

On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
 I've observed a panic in recent -current several times but I only
 have a picture of the backtrace:
 http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
 
 Does this look at all familiar to anyone?

Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
in your kernel ?

The screenshot looks strange. The instruction on which the kernel trapped
is int 0x28 which should not appear in the compiled code.


pgp3Si8Kma4hb.pgp
Description: PGP signature

Re: Tmpfs panic in -current

[Marcelo Araujo]

Hello Kevin,

May you rebuild your kernel with some options that will make the dump of
the crash easier to send to people?
Try to follow these steps:
1) Configure KERNEL with the folowing options:
options KDB
options GDB
options DDB

2) Configure rc.conf:
dumpdev=/dev/ad0s1b #Your swap slice.
dumpdir=/var/crash  #By default.
crashinfo_enable=YES
crashinfo_program=/usr/sbin/crashinfo

3) When the FreeBSD crash, it won't rebut, but will be stop on a gdb prompt.
3.1) gdb continue
3.2) gdb dump

4) kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0
5) kgdb backtrace
6) kgdb up 4
7) kgdb up

6 -- Up to line number 4.
7 -- Up to the next line.


Best Regards,
- Araujo


2012/6/25 Konstantin Belousov kostik...@gmail.com

 On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
  I've observed a panic in recent -current several times but I only
  have a picture of the backtrace:
  http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
 
  Does this look at all familiar to anyone?

 Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
 in your kernel ?

 The screenshot looks strange. The instruction on which the kernel trapped
 is int 0x28 which should not appear in the compiled code.




-- 
Marcelo Araujo
ara...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Tmpfs panic in -current

[Kevin Lo]

Konstantin Belousov wrote:
 On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
  I've observed a panic in recent -current several times but I only
  have a picture of the backtrace:
  http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
  
  Does this look at all familiar to anyone?
 
 Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
 in your kernel ?

Sure.

 The screenshot looks strange. The instruction on which the kernel trapped
 is int 0x28 which should not appear in the compiled code.

# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize 
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c

In tmpfs_subr.c:
 999 if (m != NULL) {
1000 if ((m-oflags  VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU
LL)) {

Thanks!

Kevin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Tmpfs panic in -current

[Kevin Lo]

I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg

Does this look at all familiar to anyone?

Kevin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Panic on current when enabling SUJ

[John Doe]

Boot into single user-mode

# tunefs -j enable /
# tunefs -j enable /usr
# tunefs -j enable /tmp
# tunefs -j enable /var
# reboot

The machine then panics.

Looks like the machine is trying to write to a read-only filesystem.


  
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current when enabling SUJ

[Jeff Roberson]

On Thu, 3 Jun 2010, John Doe wrote:


Boot into single user-mode

# tunefs -j enable /
# tunefs -j enable /usr
# tunefs -j enable /tmp
# tunefs -j enable /var
# reboot

The machine then panics.

Looks like the machine is trying to write to a read-only filesystem.


Can you please give me information on the panic?  What was the state of 
the filesystems upon reboot?  Does dumpfs show suj enabled?


Thanks,
Jeff





___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic on current when enabling SUJ

[John Doe]

From: Jeff Roberson jrober...@jroberson.net
To: John Doe lex...@ymail.com
Cc: curr...@freebsd.org
Sent: Thu, June 3, 2010 7:19:59 PM
Subject: Re: Panic on current when enabling SUJ

On Thu, 3 Jun 2010, John Doe wrote:

 Boot into single user-mode

 # tunefs -j enable /
 # tunefs -j enable /usr
 # tunefs -j enable /tmp
 # tunefs -j enable /var
 # reboot

 The machine then panics.

 Looks like the machine is trying to write to a read-only filesystem.

Can you please give me information on the panic?  What was the state of 
the filesystems upon reboot?  Does dumpfs show suj enabled?


I wasn't able to get a dump.

The filesystem did not have SUJ enable before booting into single user more.
It appears SUJ was correctly enable by tunefs while in single user-mode.
The problem appears to be isolated to enabling SUJ for the first time while in 
single user-mode, then rebooting.

Let me know if you need anymore information.


  
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[David Wolfskill]

On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
 Could you please try with 207902?
 ...

I saved that environment (documented elsewhere ini the thread), then
performed the normal (for me) daily update, this time, to r207911.

Again, I see a panic during transition from single-user mode to
multi-user mode:

...
 3  Select option, [Enter] for default 3
 3  or [Space] to pause timer  9   3
 @DY


GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #156 r207911: Tue May 11 05:55:18 PDT 2010
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2086129664 (1989 MB)
ACPI APIC Table: PTLTD  APIC  
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0: PTLTD   RSDT on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: unknown at device 0.1 (no driver attached)
pci0: base peripheral at device 1.0 (no driver attached)
pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
aac0: Enable Raw I/O
aac0: New comm. interface enabled
aac0: [ITHREAD]
aac0: Adaptec 2200S, aac driver 2.1.9-1
aacp0: SCSI Passthrough Bus on aac0
aacp1: SCSI Passthrough Bus on aac0
pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
pci3: ACPI PCI bus on pcib3
em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f mem 
0xd820-0xd821 irq 54 at device 2.0 on pci3
em0: [FILTER]
em0: Ethernet address: 00:30:48:2d:32:6a
em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f mem 
0xd822-0xd823 irq 55 at device 2.1 on pci3
em1: [FILTER]
em1: Ethernet address: 00:30:48:2d:32:6b
pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
pci5: ACPI PCI bus on pcib5
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at 
device 29.0 on pci0
uhci0: [ITHREAD]
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at 
device 29.1 on pci0
uhci1: [ITHREAD]
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at 
device 29.2 on pci0
uhci2: [ITHREAD]
usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at 
device 29.3 on pci0
uhci3: [ITHREAD]
usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
irq 23 at device 29.7 on pci0
ehci0: [ITHREAD]
usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
pci6: ACPI PCI bus on pcib6
vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
pci0: serial bus, SMBus at device 31.3 (no driver attached)
acpi_button0: Power Button on acpi0
atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: 

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

Please try 207949 

Thanks,
Kip



On Tue, May 11, 2010 at 6:18 AM, David Wolfskill da...@catwhisker.org wrote:
 On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
 Could you please try with 207902?
 ...

 I saved that environment (documented elsewhere ini the thread), then
 performed the normal (for me) daily update, this time, to r207911.

 Again, I see a panic during transition from single-user mode to
 multi-user mode:

 ...
  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  9           3
 �...@dy


 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2010 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-CURRENT #156 r207911: Tue May 11 05:55:18 PDT 2010
    r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
 WARNING: WITNESS option enabled, expect reduced performance.
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2086129664 (1989 MB)
 ACPI APIC Table: PTLTD          APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 kbd1 at kbdmux0
 acpi0: PTLTD   RSDT on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 Timecounter ACPI-fast frequency 3579545 Hz quality 1000
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pci0: base peripheral at device 1.0 (no driver attached)
 pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
 pci2: ACPI PCI bus on pcib2
 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 
 1.0 on pci2
 aac0: Enable Raw I/O
 aac0: New comm. interface enabled
 aac0: [ITHREAD]
 aac0: Adaptec 2200S, aac driver 2.1.9-1
 aacp0: SCSI Passthrough Bus on aac0
 aacp1: SCSI Passthrough Bus on aac0
 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f 
 mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
 em0: [FILTER]
 em0: Ethernet address: 00:30:48:2d:32:6a
 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f 
 mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
 em1: [FILTER]
 em1: Ethernet address: 00:30:48:2d:32:6b
 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
 pci4: ACPI PCI bus on pcib4
 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
 pci5: ACPI PCI bus on pcib5
 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 
 at device 29.0 on pci0
 uhci0: [ITHREAD]
 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 
 at device 29.1 on pci0
 uhci1: [ITHREAD]
 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 
 at device 29.2 on pci0
 uhci2: [ITHREAD]
 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 
 at device 29.3 on pci0
 uhci3: [ITHREAD]
 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
 irq 23 at device 29.7 on pci0
 ehci0: [ITHREAD]
 usbus4: EHCI version 1.0
 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci6: ACPI PCI bus on pcib6
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci0: Intel ICH5 UDMA100 controller port 
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
 ata0: ATA channel 0 on atapci0
 ata0: [ITHREAD]
 ata1: ATA channel 1 on atapci0
 ata1: [ITHREAD]
 pci0: serial bus, SMBus at device 31.3 (no driver attached)
 

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[David Wolfskill]

On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote:
 Please try 207949 
 ...

The panic (this time) didn't show up until about 10 seconds after the
login: prompt showed up on the serial console.  Here's what it looks
like:

...
 3  Select option, [Enter] for default 3
 3  or [Space] to pause timer  9   3
 @DY


GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #157 r207911M: Tue May 11 20:54:25 PDT 2010
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2086129664 (1989 MB)
ACPI APIC Table: PTLTD  APIC  
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0: PTLTD   RSDT on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: unknown at device 0.1 (no driver attached)
pci0: base peripheral at device 1.0 (no driver attached)
pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
aac0: Enable Raw I/O
aac0: New comm. interface enabled
aac0: [ITHREAD]
aac0: Adaptec 2200S, aac driver 2.1.9-1
aacp0: SCSI Passthrough Bus on aac0
aacp1: SCSI Passthrough Bus on aac0
pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
pci3: ACPI PCI bus on pcib3
em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f mem 
0xd820-0xd821 irq 54 at device 2.0 on pci3
em0: [FILTER]
em0: Ethernet address: 00:30:48:2d:32:6a
em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f mem 
0xd822-0xd823 irq 55 at device 2.1 on pci3
em1: [FILTER]
em1: Ethernet address: 00:30:48:2d:32:6b
pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
pci5: ACPI PCI bus on pcib5
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at 
device 29.0 on pci0
uhci0: [ITHREAD]
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at 
device 29.1 on pci0
uhci1: [ITHREAD]
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at 
device 29.2 on pci0
uhci2: [ITHREAD]
usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at 
device 29.3 on pci0
uhci3: [ITHREAD]
usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
irq 23 at device 29.7 on pci0
ehci0: [ITHREAD]
usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
pci6: ACPI PCI bus on pcib6
vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
pci0: serial bus, SMBus at device 31.3 (no driver attached)
acpi_button0: Power Button on acpi0
atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: 

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

On Tue, May 11, 2010 at 9:24 PM, David Wolfskill da...@catwhisker.org wrote:
 On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote:
 Please try 207949 
 ...

 The panic (this time) didn't show up until about 10 seconds after the
 login: prompt showed up on the serial console.  Here's what it looks
 like:

 ...
  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  9           3
 �...@dy


 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2010 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-CURRENT #157 r207911M: Tue May 11 20:54:25 PDT 2010
    r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
 WARNING: WITNESS option enabled, expect reduced performance.
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2086129664 (1989 MB)
 ACPI APIC Table: PTLTD          APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 kbd1 at kbdmux0
 acpi0: PTLTD   RSDT on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 Timecounter ACPI-fast frequency 3579545 Hz quality 1000
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pci0: base peripheral at device 1.0 (no driver attached)
 pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
 pci2: ACPI PCI bus on pcib2
 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 
 1.0 on pci2
 aac0: Enable Raw I/O
 aac0: New comm. interface enabled
 aac0: [ITHREAD]
 aac0: Adaptec 2200S, aac driver 2.1.9-1
 aacp0: SCSI Passthrough Bus on aac0
 aacp1: SCSI Passthrough Bus on aac0
 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f 
 mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
 em0: [FILTER]
 em0: Ethernet address: 00:30:48:2d:32:6a
 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f 
 mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
 em1: [FILTER]
 em1: Ethernet address: 00:30:48:2d:32:6b
 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
 pci4: ACPI PCI bus on pcib4
 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
 pci5: ACPI PCI bus on pcib5
 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 
 at device 29.0 on pci0
 uhci0: [ITHREAD]
 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 
 at device 29.1 on pci0
 uhci1: [ITHREAD]
 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 
 at device 29.2 on pci0
 uhci2: [ITHREAD]
 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 
 at device 29.3 on pci0
 uhci3: [ITHREAD]
 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
 irq 23 at device 29.7 on pci0
 ehci0: [ITHREAD]
 usbus4: EHCI version 1.0
 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci6: ACPI PCI bus on pcib6
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci0: Intel ICH5 UDMA100 controller port 
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
 ata0: ATA channel 0 on atapci0
 ata0: [ITHREAD]
 ata1: ATA channel 1 on atapci0
 ata1: [ITHREAD]
 pci0: serial bus, SMBus at device 31.3 (no driver attached)
 acpi_button0: Power Button on acpi0
 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
 atkbdc0: Keyboard controller 

Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[David Wolfskill]

During transition to multi-user mode on first reboot after upgrading
from r207812 - r207844; from the sserial console:

 3  Select option, [Enter] for default 3
 3  or [Space] to pause timer  0   3
 @DY


GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #154 r207844: Mon May 10 06:03:54 PDT 2010
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.54-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2086129664 (1989 MB)
ACPI APIC Table: PTLTD  APIC  
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0: PTLTD   RSDT on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: unknown at device 0.1 (no driver attached)
pci0: base peripheral at device 1.0 (no driver attached)
pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
aac0: Enable Raw I/O
aac0: New comm. interface enabled
aac0: [ITHREAD]
aac0: Adaptec 2200S, aac driver 2.1.9-1
aacp0: SCSI Passthrough Bus on aac0
aacp1: SCSI Passthrough Bus on aac0
pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
pci3: ACPI PCI bus on pcib3
em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f mem 
0xd820-0xd821 irq 54 at device 2.0 on pci3
em0: [FILTER]
em0: Ethernet address: 00:30:48:2d:32:6a
em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f mem 
0xd822-0xd823 irq 55 at device 2.1 on pci3
em1: [FILTER]
em1: Ethernet address: 00:30:48:2d:32:6b
pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
pci5: ACPI PCI bus on pcib5
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at 
device 29.0 on pci0
uhci0: [ITHREAD]
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at 
device 29.1 on pci0
uhci1: [ITHREAD]
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at 
device 29.2 on pci0
uhci2: [ITHREAD]
usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at 
device 29.3 on pci0
uhci3: [ITHREAD]
usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
irq 23 at device 29.7 on pci0
ehci0: [ITHREAD]
usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
pci6: ACPI PCI bus on pcib6
vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
pci0: serial bus, SMBus at device 31.3 (no driver attached)
acpi_button0: Power Button on acpi0
atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[David Wolfskill]

On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
 ...
 You don't happen to have a backtrace?

Oops -- sorry; got caught up in getting ready to head in to work:

db bt
Tracing pid 20 tid 100067 td 0xc5a19000
_mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46
flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at 
flowtable_free_stale+0x2fb
flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at 
flowtable_cleaner+0xd0
fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe9bc6d70, ebp = 0 ---
db 

Anything else that might be useful or interesting, please let me
know; as noted earlier, I left the machine in that state.  (I
normally power it off after the morning's  build/test festivities,
as it's loud  uses a fair amount of power.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpHvtGLX3oQp.pgp
Description: PGP signature

RE: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while inkernel mode

[Li, Qing]

Hi David,

I will take a look later this afternoon PST.

Thanks,

-- Qing

 -Original Message-
 From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
 curr...@freebsd.org] On Behalf Of David Wolfskill
 Sent: Monday, May 10, 2010 11:26 AM
 To: Ed Schouten
 Cc: curr...@freebsd.org
 Subject: Re: Panic @r207844;current process: flowcleaner Fatal trap
12:
 page fault while inkernel mode
 
 On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
  ...
  You don't happen to have a backtrace?
 
 Oops -- sorry; got caught up in getting ready to head in to work:
 
 db bt
 Tracing pid 20 tid 100067 td 0xc5a19000
 _mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46
 flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at
 flowtable_free_stale+0x2fb
 flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at
 flowtable_cleaner+0xd0
 fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0, eip = 0, esp = 0xe9bc6d70, ebp = 0 ---
 db
 
 Anything else that might be useful or interesting, please let me
 know; as noted earlier, I left the machine in that state.  (I
 normally power it off after the morning's  build/test festivities,
 as it's loud  uses a fair amount of power.)
 
 Peace,
 david
 --
 David H. Wolfskillda...@catwhisker.org
 Depriving a girl or boy of an opportunity for education is evil.
 
 See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

Could you please try with 207902?

Thanks,
Kip

On Mon, May 10, 2010 at 11:26 AM, David Wolfskill da...@catwhisker.org wrote:
 On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
 ...
 You don't happen to have a backtrace?

 Oops -- sorry; got caught up in getting ready to head in to work:

 db bt
 Tracing pid 20 tid 100067 td 0xc5a19000
 _mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46
 flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at 
 flowtable_free_stale+0x2fb
 flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at 
 flowtable_cleaner+0xd0
 fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0, eip = 0, esp = 0xe9bc6d70, ebp = 0 ---
 db

 Anything else that might be useful or interesting, please let me
 know; as noted earlier, I left the machine in that state.  (I
 normally power it off after the morning's  build/test festivities,
 as it's loud  uses a fair amount of power.)

 Peace,
 david
 --
 David H. Wolfskill                              da...@catwhisker.org
 Depriving a girl or boy of an opportunity for education is evil.

 See http://www.catwhisker.org/~david/publickey.gpg for my public key.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

On Mon, May 10, 2010 at 2:32 PM, K. Macy km...@freebsd.org wrote:
 Could you please try with 207902?

And if not, please get a coredump with a backtrace with symbols.

Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[David Wolfskill]

On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
 Could you please try with 207902?
 ...

First, thanks for the response.

OK; I grabbed r207902  applied it (via patch -p1), then rebuilt the
kernel  rebooted; here's the panic now:

 3  Select option, [Enter] for default 3
 3  or [Space] to pause timer  9   3
 @DY


GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #155 r207844M: Mon May 10 14:55:41 PDT 2010
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3610.95-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2086129664 (1989 MB)
ACPI APIC Table: PTLTD  APIC  
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0: PTLTD   RSDT on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: unknown at device 0.1 (no driver attached)
pci0: base peripheral at device 1.0 (no driver attached)
pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
aac0: Enable Raw I/O
aac0: New comm. interface enabled
aac0: [ITHREAD]
aac0: Adaptec 2200S, aac driver 2.1.9-1
aacp0: SCSI Passthrough Bus on aac0
aacp1: SCSI Passthrough Bus on aac0
pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
pci3: ACPI PCI bus on pcib3
em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f mem 
0xd820-0xd821 irq 54 at device 2.0 on pci3
em0: [FILTER]
em0: Ethernet address: 00:30:48:2d:32:6a
em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f mem 
0xd822-0xd823 irq 55 at device 2.1 on pci3
em1: [FILTER]
em1: Ethernet address: 00:30:48:2d:32:6b
pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
pci5: ACPI PCI bus on pcib5
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at 
device 29.0 on pci0
uhci0: [ITHREAD]
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at 
device 29.1 on pci0
uhci1: [ITHREAD]
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at 
device 29.2 on pci0
uhci2: [ITHREAD]
usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at 
device 29.3 on pci0
uhci3: [ITHREAD]
usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
irq 23 at device 29.7 on pci0
ehci0: [ITHREAD]
usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
pci6: ACPI PCI bus on pcib6
vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
pci0: serial bus, SMBus at device 31.3 (no driver attached)
acpi_button0: Power Button on acpi0
atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: 

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[K. Macy]

Are you not able to dump core?

Thanks,
Kip

On Mon, May 10, 2010 at 3:08 PM, David Wolfskill da...@catwhisker.org wrote:
 On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
 Could you please try with 207902?
 ...

 First, thanks for the response.

 OK; I grabbed r207902  applied it (via patch -p1), then rebuilt the
 kernel  rebooted; here's the panic now:

  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  9           3
 �...@dy


 GDB: no debug ports present
 KDB: debugger backends: ddb
 KDB: current backend: ddb
 Copyright (c) 1992-2010 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-CURRENT #155 r207844M: Mon May 10 14:55:41 PDT 2010
    r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
 WARNING: WITNESS option enabled, expect reduced performance.
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3610.95-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR
  AMD Features=0x2010NX,LM
  TSC: P-state invariant
 real memory  = 2147483648 (2048 MB)
 avail memory = 2086129664 (1989 MB)
 ACPI APIC Table: PTLTD          APIC  
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 2 package(s) x 1 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 ioapic1 Version 2.0 irqs 24-47 on motherboard
 ioapic2 Version 2.0 irqs 48-71 on motherboard
 kbd1 at kbdmux0
 acpi0: PTLTD   RSDT on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 Timecounter ACPI-fast frequency 3579545 Hz quality 1000
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pci0: base peripheral at device 1.0 (no driver attached)
 pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
 pci2: ACPI PCI bus on pcib2
 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 
 1.0 on pci2
 aac0: Enable Raw I/O
 aac0: New comm. interface enabled
 aac0: [ITHREAD]
 aac0: Adaptec 2200S, aac driver 2.1.9-1
 aacp0: SCSI Passthrough Bus on aac0
 aacp1: SCSI Passthrough Bus on aac0
 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2000-0x203f 
 mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
 em0: [FILTER]
 em0: Ethernet address: 00:30:48:2d:32:6a
 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x2040-0x207f 
 mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
 em1: [FILTER]
 em1: Ethernet address: 00:30:48:2d:32:6b
 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0
 pci4: ACPI PCI bus on pcib4
 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0
 pci5: ACPI PCI bus on pcib5
 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 
 at device 29.0 on pci0
 uhci0: [ITHREAD]
 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 
 at device 29.1 on pci0
 uhci1: [ITHREAD]
 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 
 at device 29.2 on pci0
 uhci2: [ITHREAD]
 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 
 at device 29.3 on pci0
 uhci3: [ITHREAD]
 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff 
 irq 23 at device 29.7 on pci0
 ehci0: [ITHREAD]
 usbus4: EHCI version 1.0
 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci6: ACPI PCI bus on pcib6
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem 
 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci0: Intel ICH5 UDMA100 controller port 
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
 ata0: ATA channel 0 on atapci0
 ata0: [ITHREAD]
 ata1: ATA channel 1 on atapci0
 ata1: [ITHREAD]
 pci0: serial bus, SMBus at device 31.3 (no driver attached)
 acpi_button0: Power Button on acpi0
 atrtc0: AT realtime clock port 

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

[David Wolfskill]

On Mon, May 10, 2010 at 03:52:07PM -0700, David Wolfskill wrote:
 On Mon, May 10, 2010 at 03:39:11PM -0700, K. Macy wrote:
  Are you not able to dump core?
  
 
 Here's the crash summary; I can put the dump on my Web server on request.
 (It weighs in at 89MB.)
 

Compression reduced the resulting file to 10MB; it may be found at
http://www.catwhisker.org/~david/FreeBSD/vmcore.0.gz.

I'll be leaving the office to head home between 16:50 - 16:55, and I'll
be off-Net until I get home (no earlier than 18:00, but probably before
19:00 -- depending on errands being run).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpJaft5n9JXz.pgp
Description: PGP signature

[CURRENT] Panic in -CURRENT of 20031105

[Jaco H. van Tonder]

Hi All,

I get panics at random times of the day with -CURRENT from 20031105, with
absolutely no load on the machine.

The machine acts as a dial-up server/gateway/firewall for my local lan. I
managed to get a coredump.

The contents of the rt pointer passed to RTFREE() does really not look right
to me. These in particular:
rt_llinfo = 0xc0f95880 \220ǼÁ\200qùÀ
rn_Key = 0xc1bcc7a0 0AùÀ8AùÀ

Anyone got any ideas?

Thanks
Jaco

firewall# uname -a

FreeBSD firewall.symphiano 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Nov 7
15:31:34 SAST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/FIREWALL i386

firewall# dmesg
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Fri Nov 7 15:31:34 SAST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/FIREWALL
Preloaded elf kernel /boot/kernel/kernel at 0xc06cf000.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x665 Stepping = 5
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,
PAT,PSE36,MMX,FXSR
real memory = 134217728 (128 MB)
avail memory = 124952576 (119 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00fded0
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pci_cfgintr: 0:8 INTA BIOS irq 11
pci_cfgintr: 0:10 INTA BIOS irq 10
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci_cfgintr: 0:1 INTA routed to irq 11
pcib1: slot 0 INTA is routed to irq 11
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 82C596 UDMA33 controller port 0xe000-0xe00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
pci0: serial bus, USB at device 7.2 (no driver attached)
pci0: bridge, HOST-PCI at device 7.3 (no driver attached)
xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xe800-0xe87f mem
0xdf80-0xdf80007f irq 11 at device 8.0 on pci0
xl0: Ethernet address: 00:50:da:45:92:81
miibus0: MII bus on xl0
xlphy0: 3c905C 10/100 internal PHY on miibus0
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0: multimedia, audio at device 10.0 (no driver attached)
orm0: Option ROMs at iomem 0xc8000-0xc87ff,0xc-0xc7fff on isa0
atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: Parallel port bus on ppc0
ppi0: Parallel I/O on ppbus0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: PNP0303 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0700 can't assign resources (port)
unknown: PNP0400 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
Timecounter TSC frequency 501139304 Hz quality 800
Timecounters tick every 10.000 msec
ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to
deny, logging limited to 1000 packets/entry by default
GEOM: create disk ad0 dp=0xc1c48370
ad0: 2014MB ST32122A [4092/16/63] at ata0-master UDMA33
acd0: CDROM CD-ROM 50X at ata1-slave PIO4
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted
WARNING: /tmp was not properly dismounted
WARNING: /usr was not properly dismounted
WARNING: /var was not properly dismounted

firewall# cat /usr/src/sys/i386/conf/FIREWALL
machine i386
cpu I686_CPU
ident   FIREWALL
maxusers0

options SCHED_4BSD  #4BSD scheduler
options INET#InterNETworking
#optionsINET6   #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_ACL #Support for access control lists
options UFS_DIRHASH #Improve performance on big
directories
options CD9660  #ISO 9660 Filesystem
options PROCFS  #Process filesystem (requires
PSEUDOFS)
options PSEUDOFS#Pseudo-filesystem framework
options COMPAT_43   #Compatible 

Re: [CURRENT] Panic in -CURRENT of 20031105

[Sam Leffler]

On Friday 07 November 2003 07:49 am, Jaco H. van Tonder wrote:
 Hi All,

 I get panics at random times of the day with -CURRENT from 20031105, with
 absolutely no load on the machine.

 The machine acts as a dial-up server/gateway/firewall for my local lan. I
 managed to get a coredump.

 The contents of the rt pointer passed to RTFREE() does really not look
 right to me. These in particular:
 rt_llinfo = 0xc0f95880 \220ǼÁ\200qùÀ
 rn_Key = 0xc1bcc7a0 0AùÀ8AùÀ

 Anyone got any ideas?

This looks like the problem I fixed yesterday.

Sam

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: panic with -current kernel ata_timeout

[Christoph P. Kukulies]

On Tue, Oct 14, 2003 at 10:14:37PM +0200, Soren Schmidt wrote:
 It seems Christoph P. Kukulies wrote:
  Help! Am I alone with this? I cvsuped again today built world,kernel.
  Still this panic. Soeren, do you get this also? You have the Motherboard
  P4S8X which I donated a couple of months ago.
 
 Nope, I dont see this at all. No problems whatsoever with the P3S8X...
 Are you sure you have rev 1.9 of ata-queue.c ? That has the lost
 interrupt recover code redone...

Looks like I have not:

#include sys/cdefs.h
__FBSDID($FreeBSD: src/sys/dev/ata/ata-queue.c,v 1.8 2003/10/12 12:38:03 sos Ex
p $);

 
 -Søren

Thanks.

Will try that one. Well, it's dated Oct 14, seems I had sharply missed it.

--
Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]