Date: Wed, 03 Nov 1999 08:45:26 +0100 (CET) From: Michael Ranner <mranner@netway.at> To: Gary Jennejohn <garyj@muc.de>, hm@hcs.de, freebsd-isdn@freebsd.org Subject: AOCD causes kernel panic Re: a little bit more from the dump Message-ID: <XFMail.991103084526.mranner@netway.at> In-Reply-To: <199911022148.WAA08143@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Gary, Hellmuth!
It's all clear! Until Thursday last week, we dont get the AOCD packets from
our Austrian Telekom. But Friday we called the service line to activate AOCD
for our private ISDN network. So its all clear. Until Friday it was no problem
because there were no AOCD packages but since Firday we get it because we want
it ;-(
I will try to get the dump in hex.
cu
PS: Gary, I have not activated AOCD in the isdnd.rc! So your question is answere
dit causes also an panic, even when not active.
On 02-Nov-99 Gary Jennejohn wrote:
> Michael Ranner writes:
>>
>>(kgdb) where
>>#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
>>#1 0xc015b310 in at_shutdown (
>> function=0xc021fef2 <__set_sysinit_set_sym_memdev_sys_init+1050>,
>> arg=0x0,
>> queue=-1071470832) at ../../kern/kern_shutdown.c:446
>>#2 0xc01e1b81 in trap_fatal (frame=0xc022a710, eva=3227291648)
>> at ../../i386/i386/trap.c:942
>>#3 0xc01e185f in trap_pfault (frame=0xc022a710, usermode=0, eva=3227291648)
>> at ../../i386/i386/trap.c:835
>>#4 0xc01e1502 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 28,
>> tf_esi = 28, tf_ebp = -1071470748, tf_isp = -1071470792,
>> tf_ebx = -219231232, tf_edx = 14402, tf_ecx = 14, tf_eax = -1067675648,
>> tf_trapno = 12, tf_err = 0, tf_eip = -1072395457, tf_cs = 8,
>> tf_eflags = 66198, tf_esp = 28, tf_ss = -1071240252})
>> at ../../i386/i386/trap.c:437
>>#5 0xc0148b3f in do_component (length=28)
>> at ../../i4b/layer3/i4b_q932fac.c:254
>>#6 0xc0148b87 in do_component (length=30)
>> at ../../i4b/layer3/i4b_q932fac.c:273
>>#7 0xc01489ef in i4b_aoc (
>> buf=0xc05c5808
>> "\034\037\221¡\034\002\001[\002\001!0\024¡\017\201\003ATS¢\b\
>>201\003", cd=0xc0262bc4) at ../../i4b/layer3/i4
>>b_q932fac.c:138
>>#8 0xc01455c8 in i4b_decode_q931_cs0_ie (unit=0, cd=0xc0262bc4, msg_len=30,
>> msg_ptr=0xc05c5808
>> "\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 0xc0144c82 in i4b_decode_q931 (unit=0, msg_len=34,
>> msg_ptr=0xc05c5804
>> "\b\001ùb\034\037\221¡\034\002\001[\002\001!0\024¡\017\20
>>1\003ATS¢\b\201\003") at ../../i4b/layer3/i4b_q
>>931.c:236
>>#10 0xc0147c71 in i4b_dl_data_ind (unit=0, m=0xc05bdc00)
>> at ../../i4b/layer3/i4b_l2if.c:318
>>#11 0xc0143fb3 in i4b_rxd_i_frame (unit=0, m=0xc05bdc00)
>> at ../../i4b/layer2/i4b_iframe.c:134
>>#12 0xc014148b in i4b_ph_data_ind (unit=0, m=0xc05bdc00)
>> at ../../i4b/layer2/i4b_l2.c:370
>>#13 0xc01ffdb3 in isic_isac_irq (sc=0xc02693a4, ista=128)
>> at ../../i4b/layer1/i4b_isac.c:189
>>#14 0xc01fe9c9 in isicintr (unit=0) at ../../i4b/layer1/i4b_isic.c:208
>>#15 0xc01fe8f5 in isicintr_sc (sc=0xc02693a4)
>> at ../../i4b/layer1/i4b_isic.c:152
>>#16 0xc0203328 in avma1pp_intr (sc=0xc02693a4)
>> at ../../i4b/layer1/i4b_avm_fritz_pci.c:1282
>>#17 0xc014eea6 in intr_mux (arg=0xc082ef00) at ../../kern/kern_intr.c:99
>>
>>(kgdb) list
>>268 /* third component element: component contents */
>>269 /*---------------------------------------------*/
>>270
>>271 if(comp_tag_form) /* == constructor */
>>272 {
>>273 do_component(comp_length);
>>274 }
>>275 else
>>276 {
>>277 int val = 0;
>>(kgdb) down
>>#5 0xc0148b3f in do_component (length=28)
>> at ../../i4b/layer3/i4b_q932fac.c:254
>>254 comp_length += (*byte_buf * (i*256));
>>(kgdb) list
>>249 byte_len += i;
>>250
>>251 for(;i > 0;i++)
>>252 {
>>253 byte_buf++;
>>254 comp_length += (*byte_buf * (i*256));
>>255 }
>>256 }
>>257 else
>>258 {
>>(kgdb) print i
>>$8 = 0
>>(kgdb) print byte_len
>>$9 = 134
>>(kgdb) print byte_buf
>>$10 = (unsigned char *) 0xc05c9000 <Address 0xc05c9000 out of bounds>
>>
>
> oh my God, it's recursive ! The panic is evidently triggered by receipt
> of AOCD info from the telephone company. The actual length of the packet
> was 31 bytes (if I read do_component correctly), but at the time of the
> panic it was up to 134 :-(, way beyond the end of the buffer.
>
> I think the only person who even remotely understands this code is Hellmuth,
> since he wrote it.
>
> It might help if you could convince gdb to output in hex rather than
> octal. That would allow one to check whether the packet contents are
> reasonable (I don't know, I know nothing at all about what an AOCD
> packet should contain).
>
> You could try not using AOCD in isdnd.rc, I suppose. That might help.
> But the kernel will probably still try to parse the packets.
>
> A very interesting bug. I wonder why it suddenly shows up now.
>
> Hellmuth !!! ;-)
>
> ---
> Gary Jennejohn
> Home - garyj@muc.de
> Work - garyj@fkr.cpqcorp.net
>
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-isdn" in the body of the message
/\/\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/
----------------------------------------------------------------------
Miss, n.:
A title with which we brand unmarried women to indicate that
they are in the market.
-- Ambrose Bierce, "The Devil's Dictionary"
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.991103084526.mranner>