Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
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
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
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
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
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
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
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
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
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, backing_object(0)=(0)+0x0 map entry 0xa000b3ce5720: start=0x241000, end=0x243000, eflags=0, prot=3/7/copy, object=0xa000b3a9a528, offset=0x0, obj ruid 0 charge 2000
Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
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"
Re: Panic with Current 351901 ISO image
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"
Re: panic on current during shutdown: panic: racct_adjust_resource: resource 4 usage < 0
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"
Re: Panic on current amd64
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
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
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
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
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
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
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
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
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
Re: Panic on current amd64
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
Re: panic with -CURRENT @Boot [r259130]
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]
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]
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)
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)
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)
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
Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)
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)
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: Panic on current from yesterday during boot
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
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
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
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
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
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
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
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: Panic on current from yesterday during boot
-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: Panic on current from yesterday during boot
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: Panic on current from yesterday during boot
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: 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? 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
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
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
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
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
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
Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel 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. 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
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
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
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
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
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
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
Re: panic with -current kernel ata_timeout
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]
Re: panic with -current kernel ata_timeout
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... With ata-queue.c rev 1.9 the panic is gone. Thanks. -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [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
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. It does not happen with an Oct 5 kernel. On Sun, Oct 12, 2003 at 01:52:40PM +0200, C. Kukulies wrote: with a -current cvsup I'm getting a kernel panic during boot: ata0 resetting devices is happening right before that ata_timout soft_clock ithread fork_exit fork_trampoline __trap 0x1 -- Chris Christoph Kukulies kuku_at_physik.rwth-aachen.de ___ [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
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... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: panic with -current
On 27-Jul-2002 Arun Sharma wrote: This is with the GENERIC kernel. Known problem ? How can I get a -current kernel that boots to multiuser so that I can tinker around with it ? Are there any magic config files that suppress these panics ? db trace _mtx_lock_flags(7069307e,0,c03ff2e0,530) at _mtx_lock_flags+0x3e securelevel_ge(bfbffe00,3,c0291194,c04b0e60,c04b0ca8) at securelevel_ge+0x3c ip_fw_ctl(cad2fcc0,c026213c,0,c2075410,cad2fcac) at ip_fw_ctl+0x30 rip_ctloutput(c2075410,cad2fcc0,cad2fd14,c0d6c540,cad2fcec) at rip_ctloutput+0xe sosetopt(c2075410,cad2fcc0,c2075410,1,0) at sosetopt+0x2c setsockopt(c0d6c540,cad2fd14,5,0,213) at setsockopt+0x8e syscall(2f,2f,2f,8093879,bfbffe73) at syscall+0x233 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b Knowing the actual panic message would help. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with -current
On Sat, Jul 27, 2002 at 05:15:08PM -0400, John Baldwin wrote: Knowing the actual panic message would help. :) My bad. I was loading the wrong version of a kernel module (ipfw). -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in -current when using i386_set_ioperm()
On Sun, 21 Jul 2002, Mark Peek wrote: There is a reproducible panic in -current after using i386_set_ioperm(). The extended pcb is attempted to be freed in cpu_thread_exit() using kmem_free(). Via private mail, Alan Cox explained it to me as such: The problem runs deeper than Giant not being held: cpu_thread_exit() really can't call kmem_free(). At the point of the call, a spin lock is held. Acquiring the kernel_map lock can cause you to sleep. Thus, the code could sleep with a spin lock held. The program and the panic trace is below. I figured I would post this to -current to get some more people thinking about the right fix. Mark There is a problem with set/get ioperm and threads (any variety) Ioperms should be a per-process thing, but the ioperm is stored as part of the information which turned out to be thread_specific. I.e the ioperm map is stored as part of the extended PCB as the extension of the TSS. The TSS holds information that on my reading appears to be largly thread-specific. (though some items might be interpreted as process specific) (hense the mess). The ioperm information is defined by Intel to be an extension to the context information that is in the ext-PCB, which is currently thread specific in -current.C Thus, when we change it, we need to sto pall threads, change the ioperm information or all of them and restart them, as the each have their own.. A least that is the way I remember it wothout going and looking at the 1/ sources 2/ intel docs. :-/ the iomap is in the extended pcb as ext_iomap. The extended pcb includes several things that should probably be per thread, including a TSS. I'm not sure, but there is maybe a possibility that all the TSSs in a process could share the pages used for the iomap. thus it would look like multiple TSSs but if you updated one iomap you updated the iomap for all of them. I dunnoit's a mess.. ideas anyone.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on current ACPI
On Sat, Sep 01, 2001 at 11:25:04PM +0900, Mitsuru IWASAKI wrote:
Hi, I've noticed that the recent CURRENT got panic on some machines
if we have `device acpica' in kernel config.
ata0: at 0x1f0 irq 14 on atapci0
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc058ed3c
stack pointer = 0x10:0xc05c6be0
frame pointer = 0x10:0xc05c6be0
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 = 0 (swapper)
kernel: type 12 trap, code=0
Stopped atacpi_timer_get_timecount+0x08: movl0x28(%eax),%edx
I think that this is because acpi_timer device is identified twice,
so I've just made a quick fix for this so that acpi_timer_identify()
is called only once.
I hope more proper fixes would be made...
Thanks
Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.10
diff -u -r1.10 acpi_timer.c
--- acpi_timer.c 5 Aug 2001 23:20:32 - 1.10
+++ acpi_timer.c 1 Sep 2001 12:04:14 -
@@ -55,7 +55,7 @@
#define _COMPONENT ACPI_SYSTEM
MODULE_NAME(TIMER)
-static device_t acpi_timer_dev;
+static device_t acpi_timer_dev = NULL;
struct resource *acpi_timer_reg;
#define TIMER_READ bus_space_read_4(rman_get_bustag(acpi_timer_reg), \
rman_get_bushandle(acpi_timer_reg),\
@@ -122,6 +122,9 @@
return_VOID;
if (AcpiGbl_FADT == NULL)
+ return_VOID;
+
+if (acpi_timer_dev != NULL)
return_VOID;
if ((dev = BUS_ADD_CHILD(parent, 0, acpi_timer, 0)) == NULL) {
I have the same problem. Your patch works for me.
Thanks.
--
Rgdz,/\
Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN
[EMAIL PROTECTED]X AGAINST HTML MAIL
http://freebsd.org.ru/~osa/ / \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic on current ACPI
Hi, I've noticed that the recent CURRENT got panic on some machines if we have `device acpica' in kernel config. You've loaded the ACPI module as well as compiling it into the kernel. Don't do that. I hope more proper fixes would be made... Peter has suggested that properly versioning the ACPI module should prevent it from being loaded if the kernel already contains it. I hope he's right. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during -CURRENT buildworld
Date: Mon, 28 May 2001 10:46:53 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] This is on a system (my laptop): FreeBSD localhost 5.0-CURRENT FreeBSD 5.0-CURRENT #13: Sun May 27 23:44:24 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 Mon May 28 07:27:59 PDT 2001 Recent CVSup activity: CVSup begin from cvsup14.freebsd.org at Sat May 26 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sat May 26 03:52:48 PDT 2001 CVSup begin from cvsup14.freebsd.org at Sun May 27 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun May 27 03:53:36 PDT 2001 CVSup begin from cvsup14.freebsd.org at Mon May 28 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Mon May 28 03:53:51 PDT 2001 I had tried the buildworld within X (as had been my normal practice until the recent difficulties with swap and/or VM), and the system re-booted itself. Got the well-discussed symptom of an active file system failing fsck's check of primary vs. first alternate superblock, and after fsck got finished with the file system, soft updates got turned off, so I turned soft updates back on again. I was able to do the buildworld ( friends) by booting a saved kernel from 16 May into single-user mode, so I'm now running: FreeBSD dhcp-133.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Mon May 28 09:56:14 PDT 2001 root@:/common/C/obj/usr/src/sys/LAPTOP_30W i386 And while running that kernel (no further CVSups; no further source tree mods), I was able to do a make buildworld while running X. Seems like an improvement to me, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during -CURRENT buildworld
On Fri, May 18, 2001 at 09:25:59PM -0700, David Wolfskill wrote: I haven't seen anyone else reporting any problems similar to what I experienced, so I'm not about to claim there's something that's definitely broken I have seen exactly the same - the machine (IBM thinkpad T21) freezes during buildworld (or it appears to, but as you said, it's hard to say if it panic'ed when you run X). This problem appear to have been introduced sometime within the last 3-4 days. Only reason I've been silent is that I still haven't had the time to get a trace. david Cheers, /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, TDC, IP-section. Hey, are any of you guys out there actually *using* RFC 2549? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during -CURRENT buildworld
Panic w/ softupdate disappears after I grab this revision of ffs_softdep.c: ident /usr/src/sys/ufs/ffs/ffs_softdep.c /usr/src/sys/ufs/ffs/ffs_softdep.c: $FreeBSD: src/sys/ufs/ffs/ffs_softdep.c,v 1.97 2001/05/19 19:24:26 mckusick Exp $ Now it's fairly smooth to buildworld, installworld, copy many small files bewteen different slice/media/network (Okay, samba :D) for me. -- Clive Lin (Tong-I Lin)\n =P [EMAIL PROTECTED] # Family, friends, private affairs\n =F [EMAIL PROTECTED] # Chinese ports, documentation\n =O [EMAIL PROTECTED] # Others\n =J.* # What do you think about the 'J' ?\n To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during -CURRENT buildworld
Hello everybody, attention! pure speculation and unprofessional comments follow! These problems with the alternate superblock remind me... there were reports about the same when fsck had problems some time ago. But there was a common theme to all of them: The fsck raves were a whole lot more severe if there were softupdates enabled. I for example have been running -CURRENT for quite a while here on a daily basis (although I have never tried to use the same file systems concurrently with -STABLE) doing buildowrlds, Mozilla bi-daily builds and other fun stuff, yet have not seen any problems of this kind. Even when I had a crash, a manual fsck (for safety's sake) always fixed things as it should, and never complained. And this, although I had some very unfortunate crashes, when eg I crashed from X in the middle of a Mozilla build, but even so there were almost no file structures damaged or at least not noted by fsck. But I have never enabled soft updates on any fs of mine, which of course means that some operations require all the time in the world to complete, but seems it is safer somehow. I am probably just lucky and totally wrong, but just speculating... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during -CURRENT buildworld
Date: Fri, 18 May 2001 10:48:19 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] [Excruciatingly long narrative of panic during buildworld for today's -CURRENT elided; it's in the archives. dhw] Reporting back after getting today's -CURRENT built: FreeBSD dhcp-140.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Fri May 18 11:31:46 PDT 2001 root@:/common/C/obj/usr/src/sys/LAPTOP_30W i386 Taking a cue from Szilveszter Adam's response to my note, I booted into single-user mode, turned off soft updates for the file systems on ad0s3 (all of which get used during the biuldworld/installworld process, since /usr/obj is a symlink to somwhere in /common -- df listing below for reference), and I unmounted the file systems on ad0s1 ad0s2. I then did the make buildworld/kernel/installworld mergemaster while remaining in single-user mode, running yesterday's -CURRENT (but, as noted, with soft updates turned off for all mounted file systems). As noted, it appears to have completed successfully. I have turned soft updates back on for everything. Tomorrow's build may prove interesting. Here's what df -k looks like (while I'm running -CURRENT): Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s3a 95263737821386084%/ devfs 110 100%/dev /dev/ad0s1a 95263408124683047%/S1 /dev/ad0s1e915695 7774726496892%/S1/usr /dev/ad0s2a 95263410304661247%/S2 /dev/ad0s2e915727 7761086636192%/S2/usr /dev/ad0s3e915727 733431 10903887%/usr /dev/ad0s3g254063 107557 12618146%/var /dev/ad0s3h 14116697 4180188 880717432%/common procfs 440 100%/proc /dev/md10c 520140 16 478516 0%/tmp I haven't seen anyone else reporting any problems similar to what I experienced, so I'm not about to claim there's something that's definitely broken Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
I would like to see full dump of 'vidcontrol -i adapter', 'vidcontrol -i mode' and dmesg after the vesa module is loaded (you get very verbose output from the vesa module init code if you boot the kernel with 'boot -v'). I think this is what you asked for, otherwise please let me know. Bye, Andrea -- 0 and 1. Now what could be so hard about that? fb0: vga0, type:VESA VGA (5), flags:0x700ff initial mode:24, current mode:24, BIOS mode:3 frame buffer window:0xb8000, buffer size:0x8000 window size:0x8000, origin:0x0 display start address (0, 0), scan line width:80 reserved:0x0 mode# flags typesize font window linear buffer -- 0 (0x000) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k 1 (0x001) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k 2 (0x002) 0x0001 T 80x25 8x8 0xb8000 32k 32k 0x 32k 3 (0x003) 0x0001 T 80x25 8x8 0xb8000 32k 32k 0x 32k 4 (0x004) 0x0003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x 32k 5 (0x005) 0x0003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x 32k 6 (0x006) 0x0003 G 640x200x1 1 8x8 0xb8000 32k 32k 0x 32k 13 (0x00d) 0x0003 G 320x200x4 4 8x8 0xa 64k 64k 0x 256k 14 (0x00e) 0x0003 G 640x200x4 4 8x8 0xa 64k 64k 0x 256k 16 (0x010) 0x0003 G 640x350x2 2 8x14 0xa 64k 64k 0x 128k 18 (0x012) 0x0003 G 640x350x4 4 8x14 0xa 64k 64k 0x 256k 19 (0x013) 0x0001 T 40x25 8x14 0xb8000 32k 32k 0x 32k 20 (0x014) 0x0001 T 40x25 8x14 0xb8000 32k 32k 0x 32k 21 (0x015) 0x0001 T 80x25 8x14 0xb8000 32k 32k 0x 32k 22 (0x016) 0x0001 T 80x25 8x14 0xb8000 32k 32k 0x 32k 23 (0x017) 0x0001 T 40x25 8x16 0xb8000 32k 32k 0x 32k 24 (0x018) 0x0001 T 80x25 8x16 0xb8000 32k 32k 0x 32k 26 (0x01a) 0x0003 G 640x480x4 4 8x16 0xa 64k 64k 0x 256k 27 (0x01b) 0x0003 G 640x480x4 4 8x16 0xa 64k 64k 0x 256k 28 (0x01c) 0x0003 G 320x200x8 1 8x8 0xa 64k 64k 0x 64k 30 (0x01e) 0x0001 T 80x50 8x8 0xb8000 32k 32k 0x 32k 32 (0x020) 0x0001 T 80x30 8x16 0xb8000 32k 32k 0x 32k 34 (0x022) 0x0001 T 80x60 8x8 0xb8000 32k 32k 0x 32k 37 (0x025) 0x0003 G 320x240x8 4 8x8 0xa 64k 64k 0x 256k 112 (0x070) 0x T 80x43 8x8 0xb8000 32k 32k 0x 32k 113 (0x071) 0x0001 T 80x43 8x8 0xb8000 32k 32k 0x 32k 256 (0x100) 0x000f G 640x400x8 1 8x16 0xa 64k 64k 0xf500 2496k 257 (0x101) 0x000f G 640x480x8 1 8x16 0xa 64k 64k 0xf500 2496k 258 (0x102) 0x000b G 800x600x4 4 8x16 0xa 64k 64k 0x 2496k 259 (0x103) 0x000f G 800x600x8 1 8x16 0xa 64k 64k 0xf500 2496k 260 (0x104) 0x000b G 1024x768x4 48x16 0xa 64k 64k 0x 2496k 261 (0x105) 0x000f G 1024x768x8 18x16 0xa 64k 64k 0xf500 2496k 263 (0x107) 0x000f G 1280x1024x8 1 8x16 0xa 64k 64k 0xf500 2496k 264 (0x108) 0x000f G 640x400x16 18x16 0xa 64k 64k 0xf500 2496k 269 (0x10d) 0x000f G 320x200x15 18x8 0xa 64k 64k 0xf500 2496k 270 (0x10e) 0x000f G 320x200x16 18x8 0xa 64k 64k 0xf500 2496k 272 (0x110) 0x000f G 640x480x15 18x16 0xa 64k 64k 0xf500 2496k 273 (0x111) 0x000f G 640x480x16 18x16 0xa 64k 64k 0xf500 2496k 274 (0x112) 0x000f G 640x480x24 18x16 0xa 64k 64k 0xf500 2496k 275 (0x113) 0x000f G 800x600x15 18x16 0xa 64k 64k 0xf500 2496k 276 (0x114) 0x000f G 800x600x16 18x16 0xa 64k 64k 0xf500 2496k 277 (0x115) 0x000f G 800x600x24 18x16 0xa 64k 64k 0xf500 2496k 278 (0x116) 0x000f G 1024x768x15 1 8x16 0xa 64k 64k 0xf500 2496k 279 (0x117) 0x000f G 1024x768x16 1 8x16 0xa 64k 64k 0xf500 2496k 280 (0x118) 0x000f G 1024x768x24 1 8x16 0xa 64k 64k 0xf500 2496k 288 (0x120) 0x000f G 320x240x8 1 8x8 0xa 64k 64k 0xf500 2496k 289 (0x121) 0x000f G 320x240x16 18x8 0xa 64k 64k 0xf500 2496k 290 (0x122) 0x000f G 400x300x8 1 8x8 0xa 64k 64k 0xf500 2496k 291 (0x123) 0x000f G 400x300x16 18x8 0xa 64k 64k 0xf500 2496k 292 (0x124) 0x000f G 512x384x8 1 8x8 0xa 64k 64k 0xf500 2496k 293 (0x125) 0x000f G 512x384x16 18x8 0xa 64k 64k 0xf500 2496k Dec 11 23:20:41 brian /boot/kernel/kernel: VESA: information block Dec 11 23:20:41 brian /boot/kernel/kernel: 56 45 53 41 00 02 20 01 00 01 00 00 00 00 22 00 Dec 11
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Andrea Campi [EMAIL PROTECTED] writes: Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Take a long hard look at vesa_set_mode() and vesa_set_origin() in sys/i386/isa/vesa.c. If the panic occurs while the console is still in text mode, the bug is in vesa_set_mode(); if it occurs after the console has switched to graphics mode, it's probably in vesa_set_origin(). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Andrea Campi [EMAIL PROTECTED] writes: Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Take a long hard look at vesa_set_mode() and vesa_set_origin() in sys/i386/isa/vesa.c. If the panic occurs while the console is still in text mode, the bug is in vesa_set_mode(); if it occurs after the console has switched to graphics mode, it's probably in vesa_set_origin(). The may be in the VESA BIOS on the video card :-) The vesa module calls the VESA BIOS to change video modes. The bug may not necessarily be in the BIOS "code", but the VESA video mode "table" to which the vesa module refers, when it sets up a new video mode, and calculates and initializes variables in the vesa module. I would like to see full dump of 'vidcontrol -i adapter', 'vidcontrol -i mode' and dmesg after the vesa module is loaded (you get very verbose output from the vesa module init code if you boot the kernel with 'boot -v'). You see, the VESA BIOS support on some video cards is not so complete. For example, we saw in the mailing list recently that the "VGA compatible" bit is somewhat turned off for VESA high resolution modes, didn't we? That possibly was a bug in that VESA BIOS. (OR, those mode ARE genuinely VGA-incompatible and we shouldn't use them the way the vesa modules accesses them...) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Having gone through yet another series of cvsup - make kernel - panics, I can now confirm this happens if and only if I have VESA defined. A vidcontrol -t off stops the panics. Now I will try to understand what's up, but I should warn you that I'm not really confident with this part of the kernel yet. More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 05-Dec-00 Andrea Campi wrote: db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Having gone through yet another series of cvsup - make kernel - panics, I can now confirm this happens if and only if I have VESA defined. A vidcontrol -t off stops the panics. Now I will try to understand what's up, but I should warn you that I'm not really confident with this part of the kernel yet. More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Bye, Andrea -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_saver module is obviously using a VESA mode, but I had no problem problem with it... On Mon, Dec 04, 2000 at 06:41:55PM -0800, John Baldwin wrote: On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Sorry, I guess I should specify that this is a desktop with APM enabled in the BIOS, but not being used otherwise... VESA module loaded. #uname -a FreeBSD cae88-102-101.sc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Dec 2 16:07:54 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RHIANNON i386 #kldstat Id Refs AddressSize Name 19 0xc010 234878 kernel 21 0xc0335000 5540 vesa.ko 31 0xc033b000 9eb4 cd9660.ko 41 0xc0345000 eb44 msdos.ko 51 0xc0354000 7a98 procfs.ko 61 0xc035c000 158eclinux.ko 71 0xc0372000 b2cc if_dc.ko 82 0xc037e000 10004miibus.ko 91 0xc038f000 76e0 linprocfs.ko On Mon, Dec 04, 2000 at 09:59:31PM -0500, Donald J . Maddox wrote: Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_saver module is obviously using a VESA mode, but I had no problem problem with it... On Mon, Dec 04, 2000 at 06:41:55PM -0800, John Baldwin wrote: On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Giant? (But after the mtx_exit() of callout_lock to be on the safe side). Also, add in a 'mtx_assert(Giant, MA_NOTOWNED);' in between teh splx() and splhigh() right below the "Give interrupts a chance" comment up about 15 lines or so. I used a slightly different printf and panic text in order to distinguish between the two. It's still panicing at the lower one, still pointing to scrn_timer. Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
We want mtxd_file and mtxd_line. If you look at the output of the last command, it will probably look something like this: ../../kern/kern_timeout.c, line 139 Hope it helps, Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 29-Nov-00 Andrea Campi wrote:
We want mtxd_file and mtxd_line. If you look at the output of the last
command, it will probably look something like this:
../../kern/kern_timeout.c, line 139
Hmm, and the failed assertion was:
panic: mutex Giant owned at ../../kern/kern_intr.c:238
So it looks like we aren't releasing Giant, or that one of the callouts we
called is getting giant but not releasing it. In sys/kern/kern_timeout.c, add
in this: (at around line 139)
if (!(c_flags CALLOUT_MPSAFE))
mtx_enter(Giant, MTX_DEF);
splx(s);
c_func(c_arg);
s = splhigh();
if (!(c_flags CALLOUT_MPSAFE))
mtx_exit(Giant, MTX_DEF);
/* add if statement below this */
if (mtx_owned(Giant)) {
printf("Bad callout handler: c_func = %p, c_arg = %p, c_flags = %d\n",
c_func, c_arg, c_flags);
panic("bad callout");
}
Then when it panics write down the values that get printed out. Next,
do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function
whose address matches the c_func address printed out, then send this info back
please. :)
Hope it helps,
Andrea
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Then when it panics write down the values that get printed out. Next, do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function whose address matches the c_func address printed out, then send this info back please. :) This time it took me 1 hour to get the panic, compared to a few minutes of earlier panics. So, I got: Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 29-Nov-00 Andrea Campi wrote: Then when it panics write down the values that get printed out. Next, do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function whose address matches the c_func address printed out, then send this info back please. :) This time it took me 1 hour to get the panic, compared to a few minutes of earlier panics. So, I got: Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Giant? (But after the mtx_exit() of callout_lock to be on the safe side). Also, add in a 'mtx_assert(Giant, MA_NOTOWNED);' in between teh splx() and splhigh() right below the "Give interrupts a chance" comment up about 15 lines or so. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Panic in -current
On 28-Nov-00 Andrea Campi wrote:
Latest (this night) current, no system activity:
panic: mutex Giant owned at ../../kern/kern_intr.c:238
I can sen you kernel conf if needed.
Is this known or should I invest some time to debug it?
Eek! I haven't seen this. If you can reproduce this, stick DDB, WITNESS, and
MUTEX_DEBUG in your kernel. Then when you get to the ddb prompt, do a
'x __mtx_debug_Giant' followed by 'x/x,8 __mtx_debug_Giant' (to work around
weird bugs in ddb). The last commad is a dump of Giant's mtx_debug structure:
struct mtx_debug {
struct witness *mtxd_witness;
LIST_ENTRY(mtx) mtxd_held;
const char *mtxd_file;
int mtxd_line;
const char *mtxd_description;
};
We want mtxd_file and mtxd_line. If you look at the output of the last
command, it will probably look something like this:
db x/x,8 __mtx_debug_Giant
__mtx_debug_Giant: c03303d80 cb6475ac c02fdd2a
__mtx_debug_Giant+0x10: da c02f97ad0 0
The last number of the first line is the address of the string holding the
filename:
db x/s 0xc02fdd2a
__set_sysinit_set_sym...: ../../i386/isa/ithread.c
The first number on the second line is the line number:
db x/d __mtx_debug_Giant+0x10
__mtx_debug_Giant+0x10: 218
So in this case Giant was last acquired at line 218 of ../../i386/isa/ithread.c.
Finding out where Giant was last obtained will help with finding out where it
was supposed to be dropped but wasn't.
Bye,
Andrea
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: (KAME-snap 3327) Re: Panic on current (12 Sept)
Hi ... Without starting the racoon daemon and doing a secure connect everything works fine without a problem. If I start racoon, do a tunnel connection and then run daily, the machine panics .. Reinier On 16-Sep-00 Shoichi 'Ne' Sakane wrote: I'm running a current machine of 12 Sept although this problem also occured on a current of a few days earlier ... This only happens when using the IPv6 IPSec code during the day, it is readily reproduceable. If during the day I load the racoon daemon and load keys and establish a IPSec tunnel connection everything works fine till 2:00 am when the daily script runs OR if I run the daily script by hand ... I generated the following dump and backtrace ... It seems to crash in a makedev routine using FOREACH list macro's. The problem doesn't seem to be with the list or the makedev function in kern_conf.c. It seems to me that something in the kernel corrupts the static list dev_hash when using the IPSec code. Summary - when ising IPSec ... machine panics during daily script execution. I think IPsec is not relative to this issue. To make sure, does your machine run healthy without IPsec ? Please try the following. case 1) with option IPSEC, but no SPD entry. case 2) without option IPSEC ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 18-Sep-00 Time: 10:04:59 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3327) Re: Panic on current (12 Sept)
As far as I recall ... the first kernel was before any of the SMP commits ... but in case it was not ... how do I go about going back to a "coarse grain lock" kernel ... can I set something in the config file or do I have to checkout old sources ?? Reinier On 17-Sep-00 [EMAIL PROTECTED] wrote: I'm running a current machine of 12 Sept although this problem also occured on a current of a few days earlier ... "current machine" meaning FreeBSD-current? if so, are there any locking behavior changes due to the introduction of fine grain locks? what happens if you go back to coarse grain lock kernel? itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 18-Sep-00 Time: 09:59:11 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3338) Re: Panic on current (12 Sept)
"current machine" meaning FreeBSD-current? if so, are there any locking behavior changes due to the introduction of fine grain locks? what happens if you go back to coarse grain lock kernel? As far as I recall ... the first kernel was before any of the SMP commits ... but in case it was not ... how do I go about going back to a "coarse grain lock" kernel ... can I set something in the config file or do I have to checkout old sources ?? for this part (how to get a source before fine grain SMP) I'm totally unsure. sorry itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3337) RE: Panic on current (12 Sept)
Without starting the racoon daemon and doing a secure connect everything works fine without a problem. If I start racoon, do a tunnel connection and then run daily, the machine panics .. I bet you can panic the kernel with setkey(8) in that case. am I correct? if so, something is not friendly with fine grain SMP, under sys/netkey. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3338) Re: Panic on current (12 Sept)
On Mon, 18 Sep 2000 10:00:53 +0200 (SAST) Reinier Bezuidenhout [EMAIL PROTECTED] said: rbezuide As far as I recall ... the first kernel was before any of the SMP rbezuide commits ... but in case it was not ... how do I go about rbezuide going back to a "coarse grain lock" kernel ... can I set rbezuide something in the config file or do I have to checkout old rbezuide sources ?? There is a tag just before SMPNG merge. You can do cvsup with: src-all tag=PRE_SMPNG -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3327) Re: Panic on current (12 Sept)
I'm running a current machine of 12 Sept although this problem also occured on a current of a few days earlier ... "current machine" meaning FreeBSD-current? if so, are there any locking behavior changes due to the introduction of fine grain locks? what happens if you go back to coarse grain lock kernel? itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
