Date: Tue, 02 Nov 1999 10:41:00 +0100 (CET) From: Michael Ranner <mranner@netway.at> To: Gary Jennejohn <garyj@muc.de> Cc: freebsd-isdn@FreeBSD.ORG Subject: screenblanker (splash, green) causes i4b to freeze and kernel to Message-ID: <XFMail.991102103703.mranner@netway.at> In-Reply-To: <199911011229.NAA00490@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Gary!
Now I have an excerpt from my kgdb output and an interessting
knowledge:
On my 2 machines I have the kernel screenblanker running, one
the green blanker and on the other a splash blanker with "fire".
After I recognized that a connect/disconnect trigger the screenblanker
(the normal view comes back without any key press), I had the idea that
the blanker is the problem for my kernel panics. I set the blanktime to
30 sec and started a download with a few mb's. ppp and isdnd dials out and
the download starts. But after 30 seconds the screenblanker gets active and
freezes the download (no disconnect), after a keypress the download continues.
After the next 30 seconds the same game, but after the next keypress the
kernel panics. Because i4b triggers the blanker without any keypress the
same problems occure without any human interaction.
I have tried this several times on both machines and every time the screen
blanekr starts to blank the download freezes and restarts after key press.
After the second keypress -> kernel panic:
--- snip - my kgdb output ---
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 2957312
initial pcb at 254dfc
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc05e0000
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc014bed3
stack pointer = 0x10:0xc023a8c8
frame pointer = 0x10:0xc023a8e0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net tty
trap number = 12
panic: page fault
syncing disks... 15 15 done
dumping to dev 30005, offset 1996999
dump 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38
37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11
10 9 8 7 6 5 4 3 2 1 0
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc015e6a4 in at_shutdown (
function=0xc022ee96 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0,
queue=-1071404916) at ../../kern/kern_shutdown.c:446
#2 0xc01e7361 in trap_fatal (frame=0xc023a88c, eva=3227385856)
at ../../i386/i386/trap.c:942
#3 0xc01e703f in trap_pfault (frame=0xc023a88c, usermode=0, eva=3227385856)
at ../../i386/i386/trap.c:835
#4 0xc01e6ce2 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 1,
tf_esi = 28, tf_ebp = -1071404832, tf_isp = -1071404876,
tf_ebx = 2105870848, tf_edx = 100403, tf_ecx = 14, tf_eax = -1067581440,
tf_trapno = 12, tf_err = 0, tf_eip = -1072382253, tf_cs = 8,
tf_eflags = 66198, tf_esp = 28, tf_ss = -1071165128})
at ../../i386/i386/trap.c:437
#5 0xc014bed3 in do_component (length=28)
at ../../i4b/layer3/i4b_q932fac.c:254
#6 0xc014bf1b in do_component (length=30)
at ../../i4b/layer3/i4b_q932fac.c:273
#7 0xc014bd83 in i4b_aoc (
buf=0xc05c7808
"\034\037\221”\034\002\001³\002\001!0\024”\017\201\003ATS¢\b\201\003",
cd=0xc0275138) at ../../i4b/layer3/i4
b_q932fac.c:138
#8 0xc014895c in i4b_decode_q931_cs0_ie (unit=0, cd=0xc0275138, msg_len=30,
msg_ptr=0xc05c7808
"\034\037\221”\034\002\001³\002\001!0\024”\017\201\003ATS¢\b\201\003") at
../../i4b/layer3/i4b_q931.c:41
6
#9 0xc0148016 in i4b_decode_q931 (unit=0, msg_len=34,
msg_ptr=0xc05c7804
"\b\001¬b\034\037\221”\034\002\001³\002\001!0\024”\017\201\003ATS¢\b\201\003")
at ../../i4b/layer3/i4b_q
931.c:236
#10 0xc014b005 in i4b_dl_data_ind (unit=0, m=0xc05aec80)
at ../../i4b/layer3/i4b_l2if.c:318
#11 0xc0147347 in i4b_rxd_i_frame (unit=0, m=0xc05aec80)
at ../../i4b/layer2/i4b_iframe.c:134
#12 0xc014481f in i4b_ph_data_ind (unit=0, m=0xc05aec80)
at ../../i4b/layer2/i4b_l2.c:370
#13 0xc020c3e7 in isic_isac_irq (sc=0xc027ddc4, ista=128)
at ../../i4b/layer1/i4b_isac.c:189
#14 0xc020affd in isicintr (unit=0) at ../../i4b/layer1/i4b_isic.c:208
#15 0xc020af29 in isicintr_sc (sc=0xc027ddc4)
at ../../i4b/layer1/i4b_isic.c:152
#16 0xc020f95c in avma1pp_intr (sc=0xc027ddc4)
at ../../i4b/layer1/i4b_avm_fritz_pci.c:1282
#17 0xc015223a in intr_mux (arg=0xc082ef00) at ../../kern/kern_intr.c:99
--- snip ---
On 01-Nov-99 Gary Jennejohn wrote:
> Michael Ranner writes:
> [snip info about a kernel panic]
>>Does anybody experienced similar?
>>
>
> This is the first report I've seen about kernel panics.
>
>>I have not found something strange in messages, isdnd.log or isdntrace.
>>
>
> Try to get a kernel dump. Nothing else will be of any use to debug this
> sort of thing. Read the handbook section about kernel debugging.
Should I mail you the dump ;)
cu
/\/\ichael Ranner - Michael Ranner <mranner@netway.at>
Michael.Ranner@netway.at - webmaster@mariazell.org
----------------------------------------------------------------------
Homepage: http://www.netlounge.at/mranner/
Mariazell Online: http://www.mariazell.at/
----------------------------------------------------------------------
Democracy is the recurrent suspicion that more than half of the people
are right more than half of the time.
-- E. B. White
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.991102103703.mranner>