Re: Timer panic on boot (r209434)
On 06/22/10 12:55, Doug Barton wrote: Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg Hmmm, that could use a little more detail. :) I have a Dell laptop with a core 2 duo processor, running 9-current SMP i386. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: Timer panic on boot (r209434)
Doug Barton wrote:
On 06/22/10 12:55, Doug Barton wrote:
Howdy,
I tried upgrading from r209351 to r209434 and got a panic related to the
timer stuff while booting. You can see the panic and the backtrace here:
http://people.freebsd.org/~dougb/timer-panic-1.jpg
http://people.freebsd.org/~dougb/timer-panic-2.jpg
http://people.freebsd.org/~dougb/timer-panic-3.jpg
Hmmm, that could use a little more detail. :) I have a Dell laptop with
a core 2 duo processor, running 9-current SMP i386.
Your ACPI seems reports that attimer uses IRQ2, instead of usual IRQ0.
It is either a bug, or it is a very rare feature.
I am not sure it is not a hack, but you may try attached patch. If it
helps, it would be nice it you tried to use i8254 event timer, to check
is this a bug or feature.
--
Alexander Motin
diff -ruNp sys/isa.prev/atrtc.c sys/isa/atrtc.c
--- sys/isa.prev/atrtc.c2010-06-22 23:01:13.0 +0300
+++ sys/isa/atrtc.c 2010-06-22 23:01:38.0 +0300
@@ -259,6 +259,7 @@ atrtc_attach(device_t dev)
if (!atrtcclock_disable
(resource_int_value(device_get_name(dev), device_get_unit(dev),
clock, i) != 0 || i != 0)) {
+ sc-intr_rid = -1;
if (!(sc-intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
sc-intr_rid, 8, 8, 1, RF_ACTIVE))) {
device_printf(dev,Can't map interrupt.\n);
diff -ruNp sys/isa.prev/clock.c sys/isa/clock.c
--- sys/isa.prev/clock.c2010-06-22 20:19:00.0 +0300
+++ sys/isa/clock.c 2010-06-22 23:01:27.0 +0300
@@ -535,6 +535,7 @@ attimer_attach(device_t dev)
tc_init(sc-tc);
if (resource_int_value(device_get_name(dev), device_get_unit(dev),
clock, i) != 0 || i != 0) {
+ sc-intr_rid = -1;
if (!(sc-intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
sc-intr_rid, 0, 0, 1, RF_ACTIVE))) {
device_printf(dev,Can't map interrupt.\n);
___
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: Timer panic on boot (r209434)
On 06/22/10 13:10, Alexander Motin wrote: Doug Barton wrote: On 06/22/10 12:55, Doug Barton wrote: Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg Hmmm, that could use a little more detail. :) I have a Dell laptop with a core 2 duo processor, running 9-current SMP i386. Your ACPI seems reports that attimer uses IRQ2, instead of usual IRQ0. It is either a bug, or it is a very rare feature. I am not sure it is not a hack, but you may try attached patch. Ok, I updated to r209441, then applied your patch. FYI, I applied it in src/sys/x86/isa/ using -p2. This allowed me to boot, verbose dmesg is at http://people.freebsd.org/~dougb/dmesg-verbose-norid-patch.txt If it helps, it would be nice it you tried to use i8254 event timer, to check is this a bug or feature. Ok, I'm willing to give that a try if you tell me how. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: Timer panic on boot (r209434)
Doug Barton wrote: On 06/22/10 13:10, Alexander Motin wrote: Doug Barton wrote: On 06/22/10 12:55, Doug Barton wrote: Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg Hmmm, that could use a little more detail. :) I have a Dell laptop with a core 2 duo processor, running 9-current SMP i386. Your ACPI seems reports that attimer uses IRQ2, instead of usual IRQ0. It is either a bug, or it is a very rare feature. I am not sure it is not a hack, but you may try attached patch. Ok, I updated to r209441, then applied your patch. FYI, I applied it in src/sys/x86/isa/ using -p2. This allowed me to boot, verbose dmesg is at http://people.freebsd.org/~dougb/dmesg-verbose-norid-patch.txt If it helps, it would be nice it you tried to use i8254 event timer, to check is this a bug or feature. Ok, I'm willing to give that a try if you tell me how. :) Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check messages to see if system liked this timer (it should fall back automatically if it's not), then check 'vmstat -ia' to see whether irq0 interrupts are arriving, then run 'systat -vm 1' to be absolutely sure. If `vmstat -ia` won't show irq0 interrupts, try to figure out what else can arrive instead of it. -- Alexander Motin ___ 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: Timer panic on boot (r209434)
On 06/22/10 14:17, Alexander Motin wrote: Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check messages to see if system liked this timer (it should fall back automatically if it's not), Seems ok. Here is what I got on the console, no error messages in /var/log/all. sysctl kern.eventtimer.timer2=i8254 kern.eventtimer.timer2: HPET1Starting kernel event timers: HPET @ 100Hz, i8254 @ 128Hz - i8254 t_delta 16.01a20d312197c8b0 too long then check 'vmstat -ia' to see whether irq0 interrupts are arriving, This also seems fine: interrupt total rate ???0 0 irq1: atkbd03448 1 stray irq1 0 0 irq0: attimer0 15756 6 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 The total for irq0 is going up consistently. then run 'systat -vm 1' to be absolutely sure. That also seemed fine. Here is a sample: 104 hpet0 uhci If I did nothing but stare at the screen the value was fairly consistently 100, with occasional values of 99 or 107. Once I started moving the mouse it jumped around a little, but stabilized again when I left the mouse alone. Should I continue using the HPET timer? Is it better in some way? Anything else I can do to help? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: Timer panic on boot (r209434)
Doug Barton wrote: On 06/22/10 14:17, Alexander Motin wrote: Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check messages to see if system liked this timer (it should fall back automatically if it's not), Seems ok. Here is what I got on the console, no error messages in /var/log/all. sysctl kern.eventtimer.timer2=i8254 kern.eventtimer.timer2: HPET1Starting kernel event timers: HPET @ 100Hz, i8254 @ 128Hz - i8254 t_delta 16.01a20d312197c8b0 too long then check 'vmstat -ia' to see whether irq0 interrupts are arriving, This also seems fine: interrupt total rate ???0 0 irq1: atkbd03448 1 stray irq1 0 0 irq0: attimer0 15756 6 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 The total for irq0 is going up consistently. OK, thanks. It means that your ACPI is lying for some reason. I'll probably commit this patch tomorrow. Should I continue using the HPET timer? As you wish. Is it better in some way? Comparing to what? Comparing to LAPIC - it is not dying in C3. Comparing to RTC - if is faster and much more flexible. Comparing to i8254 - it can work per-CPU and supports one-shot mode, both not very important now, but should benefit later. Anything else I can do to help? Find any more issues to fix. :) As you have latest HEAD, you may try my latest addition (r209440) - HPET legacy route support. It should allow HPET to work per-CPU on your hardware. To enable it, add such lines to /boot/loader.conf: hint.atrtc.0.clock=0 hint.attimer.0.clock=0 hint.hpet.0.legacy_route=1 -- Alexander Motin ___ 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
