From owner-freebsd-isdn Mon Nov 22 4:24:15 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (Postfix) with SMTP id 8D8E814C48 for ; Mon, 22 Nov 1999 04:24:12 -0800 (PST) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1364 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Mon, 22 Nov 1999 13:23:23 +0100 (CET) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11) Received: by hcswork.hcs.de (Postfix, from userid 200) id E050838E2; Mon, 22 Nov 1999 13:23:19 +0100 (MET) Subject: Re: Infinite loop (sppp/lcp) In-Reply-To: <199911190406.FAA13704@oranje.my.domain> from Marc van Woerkom at "Nov 19, 99 05:06:47 am" To: van.woerkom@netcologne.de Date: Mon, 22 Nov 1999 13:23:19 +0100 (MET) Cc: freebsd-isdn@FreeBSD.ORG Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 513 Message-Id: <19991122122319.E050838E2@hcswork.hcs.de> From: hm@hcs.de (Hellmuth Michaelis) Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From the keyboard of Marc van Woerkom: > I am referring to: > > $FreeBSD: src/sys/net/if_spppsubr.c,v 1.57 1999/10/29 17:57:42 joerg Exp $ Thanks a lot! Please make a PR for this fix! hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Nov 23 16:18: 4 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from mout00.kundenserver.de (mout00.kundenserver.de [195.20.224.69]) by hub.freebsd.org (Postfix) with ESMTP id 36DC715489 for ; Tue, 23 Nov 1999 16:17:52 -0800 (PST) (envelope-from tobi@themaster.de) Received: from [195.20.224.68] (helo=mx02.kundenserver.de) by mout00.kundenserver.de with esmtp (Exim 2.12 #2) id 11qQ7t-0004BG-00 for Freebsd-isdn@freebsd.org; Wed, 24 Nov 1999 01:17:37 +0100 Received: from h1-dial6.privat.kkf.net ([212.63.34.37] helo=puretec.de) by mx02.kundenserver.de with smtp (Exim 2.12 #2) id 11qQ7p-0000G8-00 for Freebsd-isdn@freebsd.org; Wed, 24 Nov 1999 01:17:33 +0100 From: Tobias Seiler Reply-To: tobi@themaster.de To: Freebsd-isdn@freebsd.org Date: Wed, 24 Nov 1999 01:18:29 +0100 Message-ID: X-Mailer: YAM 2.0 [060] AmigaOS E-Mail Client (c) 1995-1999 by Marcel Beck http://www.yam.ch Organization: TheMaster.de Subject: TELES 16.3 (no f*** c or PnP) MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, some of you may remember me. Formerly I had a problem to get i4b 0.80 running on a 1.4 NetBSD machine. Well, this machine still runs like a charm and runs since this time without any problems or crashes 24hours a day 7 days a week. Now I tried to setup a similar machine with almost the same setup. A TELES 16.3 card NetBSD1.4 (i386) and i4b 0.80 (this is working without any problems on the other machine and I didn't want to ran into new probs). The strange thing is, that I have done all the things to make i4b work on this machine, the machine boots up fine i4b is probing the card attaching the devices is setting config doesn't moan about anything and also the complete IP setup is done as it should be. The only thing is that the machine doesn't dial out. I copied the config from the other running machine and applied only slight changes to it (other ip address and similar things). Isdntrace simply does nothing and does not recognise when there something happening on the ISDN chain. It only creates an almost empty file with its standard header. spppcontrol says that the phase is always dead in every situation I can think of. Also the isdntest application does not dial out, well it gives some messages but nothing particulary. When I do an 'ifconfig isp0 debug' I get the message 'lcp closed (initial)' (or somthing similar, I dont have the machine here) and nothing more. I have created the /dev files on that machine and compiled the userland apps on that machine. The card must also be ok. It works in that machine with linux and in another one with w95. The ISDN line used here is the same and must also be ok then. Any idea is welcome. (The machine will be the dial out and file server for my own company and for that it is most appreciated to work flawlessly like the other machine). Germans might have a look at #http://www.spacer.de# ;-> Thanks in advance for any answer I might get. P.S.: A friend of mine also would like to run some kind of comm server but could only get hold on a 16.3c TELES card. Is there any support planed or what is needed to get the card working ? Is it 'only' some PnP mapping stuff or does it use a complete different chipset ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Nov 24 4:38:53 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (Postfix) with ESMTP id C03E414EEF for ; Wed, 24 Nov 1999 04:34:32 -0800 (PST) (envelope-from kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id NAA03933; Wed, 24 Nov 1999 13:32:02 +0100 Received: by casparc.ppp.net (Smail3.1.28.1 #1) id m11qbab-002ZjZC; Wed, 24 Nov 99 13:32 MET Received: from bert.kts.org (bert.kts.org [194.55.156.2]) by ernie.kts.org (Postfix) with ESMTP id BD10652C9F; Wed, 24 Nov 1999 13:09:54 +0100 (CET) Received: by bert.kts.org (Postfix, from userid 100) id 23B02180A; Wed, 24 Nov 1999 13:17:41 +0100 (CET) Subject: Re: TELES 16.3 (no f*** c or PnP) In-Reply-To: from Tobias Seiler at "Nov 24, 1999 1:18:29 am" To: tobi@themaster.de Date: Wed, 24 Nov 1999 13:17:41 +0100 (CET) Cc: Freebsd-isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19991124121741.23B02180A@bert.kts.org> From: hm@kts.org (Hellmuth Michaelis) Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tobias Seiler wrote: > The strange thing is, that I have done all the things to make i4b work on > this machine, the machine boots up fine i4b is probing the card attaching > the devices is setting config doesn't moan about anything and also the > complete IP setup is done as it should be. The only thing is that the > machine doesn't dial out. I copied the config from the other running > machine and applied only slight changes to it (other ip address and similar > things). > Isdntrace simply does nothing and does not recognise when there something > happening on the ISDN chain. It only creates an almost empty file with its > standard header. It seems you have either a kernel configuration error (wrong irq etc) or you have a hardware conflict (io, memory, irq). > P.S.: A friend of mine also would like to run some kind of comm server but > could only get hold on a 16.3c TELES card. Is there any support planed or > what is needed to get the card working ? Is it 'only' some PnP mapping > stuff or does it use a complete different chipset ? It has a different chipset. Someone is working to support this card for FreeBSD but it looks like it will take (quite) some time to finish this. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Nov 24 9:13: 1 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (Postfix) with SMTP id ABD4414BC4 for ; Wed, 24 Nov 1999 09:12:50 -0800 (PST) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (2173 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Wed, 24 Nov 1999 18:12:36 +0100 (CET) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11) Received: by hcswork.hcs.de (Postfix, from userid 200) id 252F938E2; Wed, 24 Nov 1999 18:12:35 +0100 (MET) Subject: 2nd Request For Cards (and last) To: freebsd-isdn@freebsd.org (ISDN Mailinglist) Date: Wed, 24 Nov 1999 18:12:35 +0100 (MET) Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1462 Message-Id: <19991124171235.252F938E2@hcswork.hcs.de> From: hm@hcs.de (Hellmuth Michaelis) Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As announced, feature freeze for FreeBSD 4.0 is on December 15th. In order to port, support and maintain the i4b hardware drivers for FreeBSD 4.x, i still need the following hardware as soon as possible: - Asuscom ISDNlink 128K PnP - Dynalink IS64PH - ITK ix1 Micro < V.3 (non PnP) - ITK ix1 Micro V.3 (PnP) - Teles S0/16.3 PnP (non "c" Version!) - USRobotics Sportster ISDN TA intern (Mail angekommen, Herr Uhl ?) Uwe Laverenz donated an ELSA PCC-16 (is now supported), thanks a lot! In case anyone wants one of the above mentioned cards supported in 4.0 and higher, please donate such a piece of hardware now (drivers will be written/ported in the order they arrive, if any), otherwise your favorite card will not run under 4.0 because the old drivers do no longer work! Please send hardware, not money: although i appreciate such offers very much (Thanks a loooot, Luke!) i have no idea where i can buy those cards (anymore) and i don't have the time to find it out or go through the ordering procedures at distributors i'm not known (i've looked at several places in Hamburg the last days but i could not find them there). hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Nov 25 13:30: 0 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from shrewd.knigma.org (shrewd.demon.co.uk [212.229.151.45]) by hub.freebsd.org (Postfix) with ESMTP id BF73514E04; Thu, 25 Nov 1999 13:29:37 -0800 (PST) (envelope-from markk@knigma.org) Received: from lap.knigma.org (lap.knigma.org [10.128.148.202]) by shrewd.knigma.org (8.9.3/8.9.3) with SMTP id VAA00190; Thu, 25 Nov 1999 21:29:43 GMT (envelope-from markk@knigma.org) Message-ID: Date: Thu, 25 Nov 1999 21:29:29 +0000 To: freebsd-current@freebsd.org, freebsd-isdn@freebsd.org From: Mark Knight Subject: Panic caused by mbuf exhaustion in i4b with AVM PCI MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Repeatable mbuf leak leading to crash in current of Saturday 20th November and all snapshots I've taken prior to that since August (i.e. when I got the ISDN card). Hardware is BT Highway (AVM PCI) passive ISDN card. It's triggered when I call my ISDN number from a PSTN telephone, and use the standard example i4b answer script to play the caller a greeting. If the caller then disconnects BEFORE the outgoing message is complete, repeated use of netstat -m shows that mbufs continue to be allocated until they are all consumed after several minutes. I have reported this before (September), but this time I've got the evidence. Sorry I can't offer a fix, but if someone who knows this code could please take a look... panic: L1 avma1pp_hscx_intr: RPF, cannot allocate new mbuf! #0 boot (howto=256) at ../../kern/kern_shutdown.c:273 273 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:273 #1 0xc015fc04 in poweroff_wait (junk=0xc02724c0, howto=-1070891776) at ../../kern/kern_shutdown.c:523 #2 0xc023cc99 in avma1pp_hscx_intr (h_chan=0, stat=2164391968, sc=0xc02b7d00) at ../../i4b/layer1/i4b_avm_fritz_pci.c:1110 #3 0xc023cefd in avma1pp_hscx_int_handler (sc=0xc02b7d00) at ../../i4b/layer1/i4b_avm_fritz_pci.c:1224 #4 0xc023cfd4 in avma1pp_intr (sc=0xc02b7d00) at ../../i4b/layer1/i4b_avm_fritz_pci.c:1276 #5 0xc0237715 in intr_mux (arg=0xc04d5bc0) at ../../i386/isa/intr_machdep.c:570 =========== isdntrace controller #0 =========== started Thu Nov 25 21:22:22 1999-- NT->TE - unit:0 - frame:000001 - time:25.11 21:22:25.761050 - length:4 ------Dump:000 02 e7 01 07 ....Q921: SAP=0 (Call Control), C, TEI=115, S-Frame: RR N(R) 3 PF 1 -- TE->NT - unit:0 - frame:000002 - time:25.11 21:22:25.761050 - length:4 - -----Dump:000 02 e7 01 05 ....Q921: SAP=0 (Call Control), R, TEI=115, S-Frame: RR N(R) 2 PF 1 -- NT->TE - unit:0 - frame:000003 - time:25.11 21:22:27.601068 - length:29 -----Dump:000 02 ff 03 ...Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 Dump:003 08 01 01 05 a1 04 03 90 90 a3 18 01 89 1e 02 84 ................Dump:019 83 70 07 81 33 31 36 30 35 35 .p..316055Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: [sending complete] [bearer capability: cap=3.1 kHz audio std=CCITT rate=64 kbit/s mode=circuit layer1=G.711 A-law] [channel id: channel=B-1 (exclusive)] [progress ind: Std=CCITT, Loc=Public network serving remote user Description: Origination address is non-ISDN] [called party number: 316055 (type=unknown, plan=ISDN)]-- TE->NT - unit:0 - frame:000004 - time:25.11 21:22:27.601068 - length:8 ------ Dump:000 00 e7 06 04 ....Q921: SAP=0 (Call Control), C, TEI=115, I-Frame: N(S) 3 N(R) 2 P 0 Dump:004 08 01 81 07 ....Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: - - NT->TE - unit:0 - frame:000005 - time:25.11 21:22:27.631080 - length:4 ------Dump:000 00 e7 01 08 ....Q921: SAP=0 (Call Control), R, TEI=115, S-Frame: RR N(R) 4 PF 0 -- NT->TE - unit:0 - frame:000006 - time:25.11 21:22:27.651071 - length:8 - -----Dump:000 02 e7 04 08 ....Q921: SAP=0 (Call Control), C, TEI=115, I-Frame: N(S) 2 N(R) 4 P 0 Dump:004 08 01 01 0f ....Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: -- TE->NT - unit:0 - frame:000007 - time:25.11 21:22:27.651071 - length:4 ------Dump:000 02 e7 01 06 ....Q921: SAP=0 (Call Control), R, TEI=115, S-Frame: RR N(R) 3 PF 0 -- NT->TE - unit:0 - frame:000008 - time:25.11 21:22:29.231086 - length:4 - -----Dump:000 00 fb 01 11 ....Q921: SAP=0 (Call Control), R, TEI=125, S-Frame: RR N(R) 8 PF 1 -- NT->TE - unit:0 - frame:000009 - time:25.11 21:22:30. 31093 - length:4 - -----Dump:000 00 fd 01 29 ...)Q921: SAP=0 (Call Control), R, TEI=126, S-Frame: RR N(R) 20 PF 1 -- NT->TE - unit:0 - frame:000010 - time:25.11 21:22:31.891112 - length:16 -----Dump:000 02 e7 06 08 ....Q921: SAP=0 (Call Control), C, TEI=115, I-Frame: N(S) 3 N(R) 4 P 0 Dump:004 08 01 01 45 08 02 80 90 1e 02 82 88 ...E........Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] [progress ind: Std=CCITT, Loc=Public network serving local user Description: In-band info or appropriate pattern now available]-- TE->NT - unit:0 - frame:000011 - time:25.11 21:22:31.891112 - length:8 ------Dump:000 00 e7 08 08 ....Q921: SAP=0 (Call Control), C, TEI=115, I-Frame: N(S) 4 N(R) 4 P 0 Dump:004 08 01 81 4d ...MQ931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: - - NT->TE - unit:0 - frame:000012 - time:25.11 21:22:31.911119 - length:4 ------Dump:000 00 e7 01 0a ....Q921: SAP=0 (Call Control), R, TEI=115, S-Frame: RR N(R) 5 PF 0 -- NT->TE - unit:0 - frame:000013 - time:25.11 21:22:31.941114 - length:8 - -----Dump:000 02 e7 08 0a ....Q921: SAP=0 (Call Control), C, TEI=115, I-Frame: N(S) 4 N(R) 5 P 0 Dump:004 08 01 01 5a ...ZQ931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: -- TE->NT - unit:0 - frame:000014 - time:25.11 21:22:31.941114 - length:4 ------Dump:000 02 e7 01 0a ....Q921: SAP=0 (Call Control), R, TEI=115, S-Frame: RR N(R) 5 PF 0 -- NT->TE - unit:0 - frame:000015 - time:25.11 21:22:39.231184 - length:4 - -----Dump:000 02 fb 01 11 ....Q921: SAP=0 (Call Control), C, TEI=125, S-Frame: RR N(R) 8 PF 1 -- NT->TE - unit:0 - frame:000016 - time:25.11 21:22:39.311186 - length:4 - -----Dump:000 00 fb 01 11 ....Q921: SAP=0 (Call Control), R, TEI=125, S-Frame: RR N(R) 8 PF 1 -- NT->TE - unit:0 - frame:000017 - time:25.11 21:22:40. 41192 - length:4 - -----Dump:000 02 fd 01 29 ...)Q921: SAP=0 (Call Control), C, TEI=126, S-Frame: RR N(R) 20 PF 1 -- NT->TE - unit:0 - frame:000018 - time:25.11 21:22:40.111194 - length:4 - -----Dump:000 00 fd 01 29 ...)Q921: SAP=0 (Call Control), R, TEI=126, S-Frame: RR N(R) 20 PF 1 -- NT->TE - unit:0 - frame:000019 - time:25.11 21:22:41.971211 - length:4 - -----Dump:000 02 e7 01 0b ....Q921: SAP=0 (Call Control), C, TEI=115, S-Frame: RR N(R) 5 PF 1 -- TE->NT - unit:0 - frame:000020 - time:25.11 21:22:41.971211 - length:4 - -----Dump:000 02 e7 01 0b ....Q921: SAP=0 (Call Control), R, TEI=115, S-Frame: RR N(R) 5 PF 1 machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident SHREWD maxusers 64 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options PANIC_REBOOT_WAIT_TIME=-1 # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs controller isa0 #controller pnp0 # PnP support for ISA #controller eisa0 controller pci0 # Floppy drives controller fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # IDE controller and disks #controller wdc0 at isa? port IO_WD1 irq 14 #device wd0 at wdc0 drive 0 #device wd1 at wdc0 drive 1 #controller wdc1 at isa? port IO_WD2 irq 15 #device wd2 at wdc1 drive 0 #device wd3 at wdc1 drive 1 # ATAPI devices on wdc? #device wcd0 #IDE CD-ROM #device wfd0 #IDE Floppy (e.g. LS-120) #device wst0 #IDE Tape (e.g. Travan) # The 'ATA' driver supports all ATA and ATAPI devices. # It can reuse the majors of wd.c for booting purposes. # You only need one "controller ata0" for it to find all # PCI ATA/ATAPI devices on modern machines. #controller ata0 device atadisk0 # ATA disk drives device atapicd0 # ATAPI CDROM drives #device atapifd0 # ATAPI floppy drives #device atapist0 # ATAPI tape drives #The folliwing options are valid on the ATA driver: # # ATA_STATIC_ID: controller numbering is static (like the old driver) # else the device numbers are dynamically allocated. # ATA_ENABLE_ATAPI_DMA: enable DMA on ATAPI device, since many ATAPI devices # claim to support DMA but doesn't actually work, this # is not enabled as default. # ATA_16BIT_ONLY: for older HW that doesn't support 32bit transfers on # the ATA channels (mostly old ISA boards). #options ATA_STATIC_ID options ATA_ENABLE_ATAPI_DMA #options ATA_16BIT_ONLY # # For older non-PCI systems, this is the lines to use: controller ata0 at isa? port IO_WD1 irq 14 controller ata1 at isa? port IO_WD2 irq 15 # SCSI Controllers # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. #controller ncr0 # NCR/Symbios Logic #controller ahb0 # EISA AHA1742 family controller ahc0 # AHA2940 and onboard AIC7xxx devices #options AHC_ALLOC_MEMIO #controller amd0 # AMD 53C974 (Teckram DC-390(T)) #controller isp0 # Qlogic family #controller dpt0 # DPT Smartcache - See LINT for options! #controller adv0 at isa? port ? irq ? #controller adw0 #controller bt0 at isa? port ? irq ? #controller aha0 at isa? port ? irq ? # SCSI peripherals # Only one of each of these is needed, they are dynamically allocated. controller scbus0 # SCSI bus (required) #device da0 # Direct Access (disks) device sa0 # Sequential Access (tape etc) device cd0 # CD device pass0 # Passthrough device (direct SCSI access) # Proprietary or custom CD-ROM Interfaces #device wt0 at isa? port 0x300 irq 5 drq 1 #device mcd0 at isa? port 0x300 irq 10 #device matcd0 at isa? port 0x230 #device scd0 at isa? port 0x230 # atkbdc0 controls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) #device apm0 at nexus? disable flags 0x31 # Advanced Power Management # PCCARD (PCMCIA) support #controller card0 #device pcic0 at isa? #device pcic1 at isa? # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? port? flags 0x40 irq 7 controller ppbus0 # Parallel port bus (required) device lpt0 # Printer #device plip0 # TCP/IP over parallel device ppi0 # Parallel port interface device #controller vpo0 # Requires scbus and da0 # PCI Ethernet NICs. #device ax0 # ASIX AX88140A #device de0 # DEC/Intel DC21x4x (``Tulip'') #device fxp0 # Intel EtherExpress PRO/100B (82557, 82558) #device pn0 # Lite-On 82c168/82c169 (``PNIC'') #device tx0 # SMC 9432TX (83c170 ``EPIC'') #device vx0 # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. #controller miibus0 # MII bus support #device al0 # ADMtek AL981/AN985 (``Comet''/``Centaur'') #device dm0 # Davicom DM9100/DM9102 #device mx0 # Macronix 98713/98715/98725 (``PMAC'') #device rl0 # RealTek 8129/8139 #device sf0 # Adaptec AIC-6915 (``Starfire'') #device sis0 # Silicon Integrated Systems SiS 900/SiS 7016 #device ste0 # Sundance ST201 (D-Link DFE-550TX) #device tl0 # Texas Instruments ThunderLAN #device vr0 # VIA Rhine, Rhine II #device wb0 # Winbond W89C840F #device xl0 # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. device ed0 at isa? port 0x280 irq 5 iomem 0xd8000 #device ex0 at isa? port? irq? #device ep0 # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device fe0 at isa? port 0x300 irq ? #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 irq ? # requires PCCARD (PCMCIA) support to be activated #device xe0 at isa? port? irq ? # PCCARD NIC drivers. # ze and zp take over the pcic and cannot coexist with generic pccard # support, nor the ed and ep drivers they replace. #device ze0 at isa? port 0x300 irq 10 iomem 0xd8000 #device zp0 at isa? port 0x300 irq 10 iomem 0xd8000 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device gzip # Exec gzipped a.out's # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support #controller uhci0 # UHCI PCI->USB interface #controller ohci0 # OHCI PCI->USB interface #controller usb0 # USB Bus (required) #device ugen0 # Generic #device uhid0 # "Human Interface Devices" #device ukbd0 # Keyboard #device ulpt0 # Printer #controller umass0 # Disks/Mass storage - Requires scbus and da0 #device ums0 # Mouse # ISDN stuff options "AVM_A1_PCI" device isic0 pseudo-device "i4bq921" # i4b layer 2 pseudo-device "i4bq931" # i4b layer 3 pseudo-device "i4b" # i4b layer 4 pseudo-device "i4btrc" 4 # Passive card ISDN tracing pseudo-device "i4bctl" # Main userland i4b controller pseudo-device "i4brbch" 4 # Userland raw B channel access pseudo-device "i4btel" 2 # userland telephony driver pseudo-device "i4bipr" 4 # IP over raw HDLC ISDN options IPR_VJ # VJ for ipr pseudo-device "i4bisppp" 4 # sync PPP over ISDN pseudo-device sppp # Generic Synchronous PPP options NMBCLUSTERS=2048 Best regards, -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Nov 25 14:11:24 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id C06F214DCB; Thu, 25 Nov 1999 14:11:17 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id XAA12659; Thu, 25 Nov 1999 23:10:35 +0100 (CET) Message-Id: <199911252210.XAA12659@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Mark Knight Cc: freebsd-current@FreeBSD.ORG, freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI Reply-To: Gary Jennejohn In-reply-to: Your message of "Thu, 25 Nov 1999 21:29:29 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Nov 1999 23:10:35 +0100 From: Gary Jennejohn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Knight writes: >Repeatable mbuf leak leading to crash in current of Saturday 20th >November and all snapshots I've taken prior to that since August (i.e. >when I got the ISDN card). > Are you using the code in -current or one of the releases ? Makes a difference. Can you a) increase the size of the message buffer in your config file (options MSGBUF_SIZE=81920, for example) b) turn on ALL the trace in the kernel with isdndebug c) cause the panic to happen again and get a crash dump ? It would also be good if you could run isdntrace in parallel so that there's some correlation between the kernel messages and the trace times. With the larger message buffer it's possible to see what was happening around the time of the crash (I used this method to debug a panic caused by a stack overflow). There's a way to read the msgbuf from the crash dump, but I can't remember what it is right now :( If all else fails, gdb should be able to do it. I can only guess, but it looks like the user-land process isn't told about the hangup and keeps sending packets down the line. The packets never go out (no connection), so the mbufs eventually run out. The raw interface evidently doesn't have the safety belts that the other interfaces (like ipr, isppp) have. --- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Nov 25 14:37:37 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from shrewd.knigma.org (shrewd.demon.co.uk [212.229.151.45]) by hub.freebsd.org (Postfix) with ESMTP id 0506214D38 for ; Thu, 25 Nov 1999 14:37:15 -0800 (PST) (envelope-from markk@knigma.org) Received: from lap.knigma.org (lap.knigma.org [10.128.148.202]) by shrewd.knigma.org (8.9.3/8.9.3) with SMTP id WAA00281 for ; Thu, 25 Nov 1999 22:37:22 GMT (envelope-from markk@knigma.org) Message-ID: Date: Thu, 25 Nov 1999 22:36:45 +0000 To: freebsd-isdn@freebsd.org From: Mark Knight Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI References: <199911252210.XAA12659@peedub.muc.de> In-Reply-To: <199911252210.XAA12659@peedub.muc.de> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199911252210.XAA12659@peedub.muc.de>, Gary Jennejohn writes >Are you using the code in -current or one of the releases ? Makes a >difference. cvsup'd current from Saturday morning. >Can you a) increase the size of the message buffer in your config file >(options MSGBUF_SIZE=81920, for example) b) turn on ALL the >trace in the kernel with isdndebug c) cause the panic to happen again >and get a crash dump ? I'll give this a go. >It would also be good if you could run isdntrace in parallel so that >there's some correlation between the kernel messages and the trace times. I did include that in my earlier post - in case you missed it... >I can only guess, but it looks like the user-land process isn't told >about the hangup and keeps sending packets down the line. The packets >never go out (no connection), so the mbufs eventually run out. The >raw interface evidently doesn't have the safety belts that the other >interfaces (like ipr, isppp) have. I've tried killing the user land daemon and the growth continues. Latest finding. Once the run-away has started, another incoming call allowed to complete with FreeBSD performing the clear down results in all mbufs being freed and stability returning. -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Nov 25 14:38:31 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from shrewd.knigma.org (shrewd.demon.co.uk [212.229.151.45]) by hub.freebsd.org (Postfix) with ESMTP id CC34D14D21; Thu, 25 Nov 1999 14:37:15 -0800 (PST) (envelope-from markk@knigma.org) Received: from lap.knigma.org (lap.knigma.org [10.128.148.202]) by shrewd.knigma.org (8.9.3/8.9.3) with SMTP id WAA00280; Thu, 25 Nov 1999 22:37:22 GMT (envelope-from markk@knigma.org) Message-ID: Date: Thu, 25 Nov 1999 22:36:01 +0000 To: freebsd-current@freebsd.org, freebsd-isdn@freebsd.org From: Mark Knight Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI References: <199911252210.XAA12659@peedub.muc.de> In-Reply-To: <199911252210.XAA12659@peedub.muc.de> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199911252210.XAA12659@peedub.muc.de>, Gary Jennejohn writes >Can you a) increase the size of the message buffer in your config file >(options MSGBUF_SIZE=81920, for example) b) turn on ALL the >trace in the kernel with isdndebug c) cause the panic to happen again >and get a crash dump ? And here it is... This represents a single call into i4b, clearing down part way through the outgoing message. I did't leave it to panic but that would have only been a matter of time. Mounting root from ufs:/dev/ad0a i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L3-i4b_decode_q931: Call Ref, len 1, val 1, flag 0 i4b-L4-reserve_cd: found free cd - index=0 cdid=1 i4b-L3-rx SETUP: unit 0, cr = 0x01 i4b-L3-i4b_decode_q931_cs0_ie: IEI_SENDCOMPL i4b-L3-i4b_decode_q931_cs0_ie: IEI_BEARERCAP - Telephony i4b-L3-i4b_decode_q931_cs0_ie: IEI_CHANNELID - channel 1, exclusive = 1 i4b-L3-i4b_decode_q931_cs0_ie: IEI_PROGRESSINDICATOR i4b-L3-i4b_decode_q931_cs0_ie: IEI_CALLED = 316055 i4b-L3-next_l3state: L3 FSM event [EV_SETUP - rxd SETUP]: [ST_U0 - Null => ST_U6 - In Pres] i4b-L3-F_00H: FSM function F_00H executing i4b-L4-T400_start: cr = 1 i4b-L4-cd_by_cdid: found cdid - index=0 cdid=1 cr=1 i4b-L4-T400_stop: cr = 1 i4b-L4-i4bioctl: I4B_CONNECT_RESP max_idle_time set to 5 seconds i4b-L4-cd_by_cdid: found cdid - index=0 cdid=1 cr=1 i4b-L4-T400_stop: cr = 1 i4b-L3-next_l3state: L3 FSM event [EV_SETACRS - L4 accept RSP]: [ST_U6 - In Pres => ST_SUSE - Subroutine sets state] i4b-L3-F_06E: FSM function F_06E executing i4b-L2-DL-ESTABLISH-REQ: unit 0 i4b-L2-i4b_next_l2state: FSM event [EV_DLESTRQ]: [ST_TEI_UNAS/0 => ST_EST_AW_TEI/2] i4b-L2-F_TU01: FSM function F_TU01 executing i4b-L2-MDL-ASSIGN-IND: unit 0 i4b-L2-i4b_tei_assign: tx TEI ID_Request i4b-L2-i4b_T202_start: unit 0 i4b-L1-ph_data_req: ISAC_TX_ACTIVE set i4b-L3-T313_start: cr = 1 i4b-L1-isic_isac_irq: unit 0: ista = 0x10 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L2-i4b_T202_stop: unit 0 i4b-L3-i4b_mdl_status_ind: unit = 0, status = 3, parm = 115 i4b-L3-i4b_mdl_status_ind: STI_TEIASG: unit 0 TEI = 115 = 0x73 i4b: unit 0, assigned TEI = 115 = 0x73 i4b-L2-i4b_tei_rx_frame: TEI ID Assign - TEI = 115 i4b-L2-i4b_next_l2state: FSM event [EV_MDASGRQ]: [ST_EST_AW_TEI/2 => ST_AW_EST/4] i4b-L2-F_TE03: FSM function F_TE03 executing i4b-L2-i4b_tx_sabme: tx SABME, tei = 115 i4b-L1-ph_data_req: ISAC_TX_ACTIVE set i4b-L2-i4b_T200_restart: unit 0 i4b-L1-isic_isac_irq: unit 0: ista = 0x10 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L2-i4b_rxd_u_frame: UA, sapi = 0, tei = 115 i4b-L2-F_AE09: FSM function F_AE09 executing i4b-L3-i4b_mdl_status_ind: unit = 0, status = 2, parm = 1 i4b-L3-i4b_mdl_status_ind: STI_L2STAT: unit 0 layer 2 = up i4b-L2-i4b_T200_stop: unit 0 i4b-L2-i4b_next_l2state: FSM S-event [EV_RXUA]: [ST_AW_EST => ST_MULTIFR] i4b-L2-i4b_next_l2state: FSM executing postfsmfunc! i4b-L2-DL-ESTABLISH-CONF: unit 0 i4b-L3-i4b_dl_establish_cnf: unit=0, index=0 cdid=1 cr=1 i4b-L3-next_l3state: L3 FSM event [EV_DLESTCF - L2 DL_Est_Cnf]: [ST_IWA - In Wait EST-Accept => ST_U8 - In ConReq] i4b-L3-F_DECF2: FSM function F_DECF2 executing i4b-L3-tx CONNECT: unit 0, cr = 0x01 i4b-L1-ph_data_req: ISAC_TX_ACTIVE set i4b-L2-i4b_T200_start: unit 0 i4b-L1-isic_isac_irq: unit 0: ista = 0x10 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 1 i4b-L2-F_MF17: FSM function F_MF17 executing i4b-L2-i4b_T200_stop: unit 0 i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] i4b-L1-isic_isac_irq: unit 0: ista = 0x81 i4b-L1-isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow i4b-L3-i4b_decode_q931: Call Ref, len 1, val 1, flag 0 i4b-L4-cd_by_unitcr: found cd, index=0 cdid=1 cr=1 i4b-L3-rx CONNECT-ACK: unit 0, cr = 0x01 i4b-L3-next_l3state: L3 FSM event [EV_CONACK - rxd CONN ACK]: [ST_U8 - In ConReq => ST_U10 - Active] i4b-L3-F_08R: FSM function F_08R executing i4b-L3-T313_stop: cr = 1 i4b-L4-i4b_l4_connect_active_ind: last_active/connect_time=943568877 i4b-L1-avma1pp_bchannel_setup: unit=0, channel=1, activate i4b-L1-avma1pp_hscx_init: unit=0, channel=1, activate i4b-L1-avma1pp_hscx_init: BPROT_NONE?? i4b-L4-i4b_l4_setup_timeout: 943568877: direction 1, shorthold algorithm 0 i4b-L4-i4b_l4_setup_timeout: 943568877: incoming-call, setup max_idle_time to 5 i4b-L2-i4b_tx_rr_response: tx RR, unit = 0 i4b-L1-ph_data_req: ISAC_TX_ACTIVE set i4b-L2-i4b_T200_stop: unit 0 i4b-L1-isic_isac_irq: unit 0: ista = 0x10 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568877: incoming-call, activity, last_active=943568877, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568878: incoming-call, activity, last_active=943568878, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568878: incoming-call, activity, last_active=943568878, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568879: incoming-call, activity, last_active=943568879, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568879: incoming-call, activity, last_active=943568879, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568880: incoming-call, activity, last_active=943568880, max_idle=5 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568880: incoming-call, activity, last_active=943568880, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568881: incoming-call, activity, last_active=943568881, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568881: incoming-call, activity, last_active=943568881, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568882: incoming-call, activity, last_active=943568882, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L4-i4b_idle_check: 943568882: incoming-call, activity, last_active=943568882, max_idle=5 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L3-i4b_decode_q931: Call Ref, len 1, val 1, flag 0 i4b-L4-cd_by_unitcr: found cd, index=0 cdid=1 cr=1 i4b-L3-rx DISCONNECT: unit 0, cr = 0x01 i4b-L3-i4b_decode_q931_cs0_ie: IEI_CAUSE = 16 i4b-L3-i4b_decode_q931_cs0_ie: IEI_PROGRESSINDICATOR i4b-L3-next_l3state: L3 FSM event [EV_DISCONN - rxd DISC]: [ST_U10 - Active => ST_U12 - Disc Ind] i4b-L3-F_DISC: FSM function F_DISC executing i4b-L3-T303_stop: cr = 1 i4b-L3-T305_stop: cr = 1 i4b-L3-T308_stop: cr = 1 i4b-L3-T309_stop: cr = 1 i4b-L3-T310_stop: cr = 1 i4b-L3-T313_stop: cr = 1 i4b-L3-tx RELEASE: unit 0, cr = 0x01 i4b-L1-ph_data_req: ISAC_TX_ACTIVE set i4b-L2-i4b_T200_start: unit 0 i4b-L3-T308_start: cr = 1 i4b-L1-isic_isac_irq: unit 0: ista = 0x90 i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 2 i4b-L2-F_MF17: FSM function F_MF17 executing i4b-L2-i4b_T200_stop: unit 0 i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L3-i4b_decode_q931: Call Ref, len 1, val 1, flag 0 i4b-L4-cd_by_unitcr: found cd, index=0 cdid=1 cr=1 i4b-L3-rx RELEASE-COMPLETE: unit 0, cr = 0x01 i4b-L3-next_l3state: L3 FSM event [EV_RELCOMP - rxd REL COMPL]: [ST_U12 - Disc Ind => ST_U0 - Null] i4b-L3-F_RELCP: FSM function F_RELCP executing i4b-L3-T303_stop: cr = 1 i4b-L3-T305_stop: cr = 1 i4b-L3-T308_stop: cr = 1 i4b-L3-T309_stop: cr = 1 i4b-L3-T310_stop: cr = 1 i4b-L3-T313_stop: cr = 1 i4b-L1-avma1pp_hscx_init: unit=0, channel=1, deactivate i4b-L1-avma1pp_bchannel_setup: unit=0, channel=1, deactivate i4b-L4-freecd_by_cd: releasing cd - index=0 cdid=1 cr=1 i4b-L2-i4b_tx_rr_response: tx RR, unit = 0 i4b-L1-ph_data_req: ISAC_TX_ACTIVE set i4b-L2-i4b_T200_stop: unit 0 i4b-L1-isic_isac_irq: unit 0: ista = 0x10 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-avma1pp_hscx_intr: receive data overflow i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-isic_isac_irq: unit 0: ista = 0x80 i4b-L1-avma1pp_hscx_intr: receive data overflow -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Nov 25 16:40:33 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 9EE4D14C8F; Thu, 25 Nov 1999 16:40:28 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id TAA01763; Thu, 25 Nov 1999 19:40:18 -0500 (EST) Date: Thu, 25 Nov 1999 19:40:17 -0500 (EST) From: Bosko Milekic To: Gary Jennejohn Cc: Mark Knight , freebsd-current@FreeBSD.ORG, freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI In-Reply-To: <199911252210.XAA12659@peedub.muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Nov 1999, Gary Jennejohn wrote: !>I can only guess, but it looks like the user-land process isn't told !>about the hangup and keeps sending packets down the line. The packets !>never go out (no connection), so the mbufs eventually run out. The !>raw interface evidently doesn't have the safety belts that the other !>interfaces (like ipr, isppp) have. Out of curiosity, is anything regarding the exhaustion of mb_map being logged to /var/log/messages ? If not, chances are that this is not directly related to an mbuf exhaustion -- the panic, that is, because if mb_map hasn't even been exhausted, then you still potentially have space to allocate from (this is the way it presently works) and the panic is unlikely to be related to an mbuf pointer being NULL and mis-treated. -- Bosko Milekic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Nov 26 10:22: 7 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id 9DAD0150B4 for ; Fri, 26 Nov 1999 10:22:02 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id TAA14541; Fri, 26 Nov 1999 19:21:18 +0100 (CET) Message-Id: <199911261821.TAA14541@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Mark Knight Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI Reply-To: Gary Jennejohn In-reply-to: Your message of "Thu, 25 Nov 1999 22:20:12 GMT." <65tPkBAcYbP4EwVg@knigma.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Nov 1999 19:21:18 +0100 From: Gary Jennejohn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [changed -current to -isdn, it's more appropriate] Mark Knight writes: >In article <199911252210.XAA12659@peedub.muc.de>, Gary Jennejohn > writes >>It would also be good if you could run isdntrace in parallel so that >>there's some correlation between the kernel messages and the trace times. > >I did include that in my earlier post - in case you missed it... > yes, but there's no correlation between the gdb output and what was going on in the kernel relative to the isdntrace output. All academic now that you've posted the kernel trace. --- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Nov 26 12:14:34 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id CA2AC15112 for ; Fri, 26 Nov 1999 12:14:00 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id VAA14737; Fri, 26 Nov 1999 21:12:12 +0100 (CET) Message-Id: <199911262012.VAA14737@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Mark Knight Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI Reply-To: Gary Jennejohn In-reply-to: Your message of "Thu, 25 Nov 1999 22:36:01 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Nov 1999 21:12:12 +0100 From: Gary Jennejohn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Knight writes: >And here it is... > >This represents a single call into i4b, clearing down part way through >the outgoing message. > [trace deleted] I don't like all those overflow messages. Hmm, it looks like the HSCX isn't being deactivated. Can you try this patch and report back ? ===================================================================== *** i4b_avm_fritz_pci.c Fri Nov 26 20:51:05 1999 --- i4b_avm_fritz_pci.c.orig Fri Nov 26 20:48:55 1999 *************** *** 1364,1370 **** if (sc->sc_chan[HSCX_CH_A].state != HSCX_IDLE || sc->sc_chan[HSCX_CH_B].state != HSCX_IDLE) { - DBGL1(L1_BCHAN, "avma1pp_hscx_init", "%d NOT deactivated\n", h_chan); return; } sc->avma1pp_cmd = HSCX_CMD_XRS|HSCX_CMD_RRS; --- 1364,1369 ---- *************** *** 1418,1424 **** if(activate == 0) { /* deactivation */ ! chan->state = HSCX_IDLE; avma1pp_hscx_init(sc, h_chan, activate); } --- 1417,1423 ---- if(activate == 0) { /* deactivation */ ! chan->state &= ~HSCX_AVMA1PP_ACTIVE; avma1pp_hscx_init(sc, h_chan, activate); } --- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Nov 26 16: 4: 0 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from shrewd.knigma.org (shrewd.demon.co.uk [212.229.151.45]) by hub.freebsd.org (Postfix) with ESMTP id 3F44A14DBA for ; Fri, 26 Nov 1999 16:03:41 -0800 (PST) (envelope-from markk@knigma.org) Received: from lap.knigma.org (lap.knigma.org [10.128.148.202]) by shrewd.knigma.org (8.9.3/8.9.3) with SMTP id AAA01229 for ; Sat, 27 Nov 1999 00:03:46 GMT (envelope-from markk@knigma.org) Message-ID: Date: Sat, 27 Nov 1999 00:03:18 +0000 To: freebsd-isdn@freebsd.org From: Mark Knight Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI References: <199911262012.VAA14737@peedub.muc.de> In-Reply-To: <199911262012.VAA14737@peedub.muc.de> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199911262012.VAA14737@peedub.muc.de>, Gary Jennejohn writes >Hmm, it looks like the HSCX isn't being deactivated. Can you try this patch >and report back ? > >===================================================================== >*** i4b_avm_fritz_pci.c Fri Nov 26 20:51:05 1999 >--- i4b_avm_fritz_pci.c.orig Fri Nov 26 20:48:55 1999 The buffer overruns in my earlier logs appear to be a function of the logging being enabled and my ageing Pentium 90 struggling to keep up. Apart from the obvious typo preventing your patch from compiling (brackets required around the logging macro), this has definitely improved things! With a single incoming call, with the caller clearing down, netstat -m now shows mbuf usage returning to the original level, and staying there. If BSD clears down this is also fine, as before. In my delight I've now taken the destruction test a stage further: If I make two incoming calls, both of which are answered and receive the outgoing message, even if I allow i4b to clear each call after the outbound message, I get back to a state of run away mbuf allocation and impending panic. This time, it's much harder to restore stability, although this can be done with about 3 or 4 incoming calls in rapid succession. I've tried setting isdndebug to record this new scenario, but my machine just can't service the interrupts quickly enough. Thanks for your patch - a major leap forward in that a single wrong number won't crash my box :) -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Nov 26 19:25:39 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id A24B914C44 for ; Fri, 26 Nov 1999 19:25:35 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id EAA23551; Sat, 27 Nov 1999 04:15:39 +0100 (CET) Message-Id: <199911270315.EAA23551@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Mark Knight Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI Reply-To: Gary Jennejohn In-reply-to: Your message of "Sat, 27 Nov 1999 00:03:18 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Nov 1999 04:15:39 +0100 From: Gary Jennejohn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Knight writes: [partial success] >In my delight I've now taken the destruction test a stage further: > >If I make two incoming calls, both of which are answered and receive the >outgoing message, even if I allow i4b to clear each call after the >outbound message, I get back to a state of run away mbuf allocation and >impending panic. This time, it's much harder to restore stability, >although this can be done with about 3 or 4 incoming calls in rapid >succession. > >I've tried setting isdndebug to record this new scenario, but my machine >just can't service the interrupts quickly enough. > >Thanks for your patch - a major leap forward in that a single wrong >number won't crash my box :) It would be interesting to know whether the new debug message appears in the latter case. The problem with the Fritz!Card is that it doesn't really have independent B-Channels, like the Siemens HSCX, so I can't disable the HSCX if both channels are active. It looks like that's what's happening here. Too bad your machine is too slow. That compunds the problem. Of course, if you limit the trace to _just_ L1_BCHAN (0x04) it might have a chance, and the new message might pop out. --- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 1:11:20 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 128A414D09; Sat, 27 Nov 1999 01:11:16 -0800 (PST) (envelope-from roger@cs.strath.ac.uk) Received: from cs.strath.ac.uk (scary.dmem.strath.ac.uk [130.159.202.5]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id JAA13597 Sat, 27 Nov 1999 09:11:14 GMT Message-ID: <383FA049.79D89520@cs.strath.ac.uk> Date: Sat, 27 Nov 1999 09:11:37 +0000 From: Roger Hardiman Organization: Strathclyde University X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: isdn@freebsd.org, jen@vulture.dmem.strath.ac.uk Cc: roger@freebsd.org Subject: Help - I need a login shell over my ISDN line Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Having cheked the i4b package closely, it seems there is no way to set it up so I can dial up the ISDN line and get the good old ASCII shell and a login prompt. Is this true, or is there something I have missed? I have a setup with my 33.6 analogue modem where I can dial up my FreeBSD box, from a Win98 laptop using HyperTerm, and at the login prompt log on as normal. I need to move over to ISDN. So, On FreeBSD I need some way to have getty (or mgetty) listening to the ISDN, answering the call, starting the login process. On my Win98 laptop it is no problem. I use a GSM Mobile phone which can talk to ISDN or analogue modems. The advantage is the Mobile can connect to ISDN in 2 seconds, but take the usual 30 seconds to connect to the 33.6 modem. In my case, after connecting, I stream data back to the Win98 box. PPP is not suitable for my application. With PPP I get lags in the MS Windows software (typical) making the data appear bursty. This is for a real time system. Any ideas, suggestions? I'm willing and able to hack code at the low level. Cheers Roger -- Roger Hardiman Strathclyde Uni Telepresence Research Group, Glasgow, Scotland. http://www.telepresence.strath.ac.uk 0141 548 2897 roger@cs.strath.ac.uk roger@freebsd.org Maintainer of the FreeBSD Bt848/878 driver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 1:30:56 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from shrewd.knigma.org (shrewd.demon.co.uk [212.229.151.45]) by hub.freebsd.org (Postfix) with ESMTP id 0C4F514D8B for ; Sat, 27 Nov 1999 01:30:51 -0800 (PST) (envelope-from markk@knigma.org) Received: from lap.knigma.org (lap.knigma.org [10.128.148.202]) by shrewd.knigma.org (8.9.3/8.9.3) with SMTP id JAA00199 for ; Sat, 27 Nov 1999 09:30:50 GMT (envelope-from markk@knigma.org) Message-ID: Date: Sat, 27 Nov 1999 09:30:27 +0000 To: freebsd-isdn@freebsd.org From: Mark Knight Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI References: <199911270315.EAA23551@peedub.muc.de> In-Reply-To: <199911270315.EAA23551@peedub.muc.de> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199911270315.EAA23551@peedub.muc.de>, Gary Jennejohn writes >Mark Knight writes: >[partial success] >Too bad your machine is too slow. That compunds the problem. Of course, >if you limit the trace to _just_ L1_BCHAN (0x04) it might have a chance, >and the new message might pop out. Here it is, but I can't see the new message! Two calls in succession, the second answered before the first completed. I allowed i4b to clear them both. netstat -m reports continual growth - and it panic'd before I sorted it out this time :) i4b-L4-reserve_cd: found free cd - index=0 cdid=40 i4b-L4-T400_start: cr = 1 i4b-L4-cd_by_cdid: found cdid - index=0 cdid=40 cr=1 i4b-L4-T400_stop: cr = 1 i4b-L4-i4bioctl: I4B_CONNECT_RESP max_idle_time set to 5 seconds i4b-L4-cd_by_cdid: found cdid - index=0 cdid=40 cr=1 i4b-L4-T400_stop: cr = 1 i4b-L4-cd_by_unitcr: found cd, index=0 cdid=40 cr=1 i4b-L4-i4b_l4_connect_active_ind: last_active/connect_time=943694495 i4b-L4-i4b_l4_setup_timeout: 943694495: direction 1, shorthold algorithm 0 i4b-L4-i4b_l4_setup_timeout: 943694495: incoming-call, setup max_idle_time to 5 i4b-L4-i4b_idle_check: 943694495: incoming-call, activity, last_active=943694495, max_idle=5 i4b-L4-i4b_idle_check: 943694496: incoming-call, activity, last_active=943694496, max_idle=5 i4b-L4-i4b_idle_check: 943694496: incoming-call, activity, last_active=943694496, max_idle=5 i4b-L4-i4b_idle_check: 943694497: incoming-call, activity, last_active=943694497, max_idle=5 i4b-L4-i4b_idle_check: 943694497: incoming-call, activity, last_active=943694497, max_idle=5 i4b-L4-i4b_idle_check: 943694498: incoming-call, activity, last_active=943694498, max_idle=5 i4b-L4-i4b_idle_check: 943694498: incoming-call, activity, last_active=943694498, max_idle=5 i4b-L4-i4b_idle_check: 943694499: incoming-call, activity, last_active=943694499, max_idle=5 i4b-L4-i4b_idle_check: 943694499: incoming-call, activity, last_active=943694499, max_idle=5 i4b-L4-i4b_idle_check: 943694500: incoming-call, activity, last_active=943694500, max_idle=5 i4b-L4-i4b_idle_check: 943694500: incoming-call, activity, last_active=943694500, max_idle=5 i4b-L4-i4b_idle_check: 943694501: incoming-call, activity, last_active=943694501, max_idle=5 i4b-L4-i4b_idle_check: 943694501: incoming-call, activity, last_active=943694501, max_idle=5 i4b-L4-i4b_idle_check: 943694502: incoming-call, activity, last_active=943694502, max_idle=5 i4b-L4-i4b_idle_check: 943694502: incoming-call, activity, last_active=943694502, max_idle=5 i4b-L4-reserve_cd: found free cd - index=1 cdid=41 i4b-L4-T400_start: cr = 2 i4b-L4-cd_by_cdid: found cdid - index=1 cdid=41 cr=2 i4b-L4-T400_stop: cr = 2 i4b-L4-i4bioctl: I4B_CONNECT_RESP max_idle_time set to 5 seconds i4b-L4-cd_by_cdid: found cdid - index=1 cdid=41 cr=2 i4b-L4-T400_stop: cr = 2 i4b-L4-cd_by_unitcr: found cd, index=1 cdid=41 cr=2 i4b-L4-i4b_l4_connect_active_ind: last_active/connect_time=943694503 i4b-L4-i4b_l4_setup_timeout: 943694503: direction 1, shorthold algorithm 0 i4b-L4-i4b_l4_setup_timeout: 943694503: incoming-call, setup max_idle_time to 5 i4b-L4-i4b_idle_check: 943694503: incoming-call, activity, last_active=943694503, max_idle=5 i4b-L4-i4b_idle_check: 943694503: incoming-call, activity, last_active=943694503, max_idle=5 i4b-L4-i4b_idle_check: 943694503: incoming-call, activity, last_active=943694503, max_idle=5 i4b-L4-i4b_idle_check: 943694504: incoming-call, activity, last_active=943694504, max_idle=5 i4b-L4-i4b_idle_check: 943694504: incoming-call, activity, last_active=943694504, max_idle=5 i4b-L4-i4b_idle_check: 943694504: incoming-call, activity, last_active=943694504, max_idle=5 i4b-L4-i4b_idle_check: 943694504: incoming-call, activity, last_active=943694504, max_idle=5 i4b-L4-i4b_idle_check: 943694505: incoming-call, activity, last_active=943694505, max_idle=5 i4b-L4-i4b_idle_check: 943694505: incoming-call, activity, last_active=943694505, max_idle=5 i4b-L4-i4b_idle_check: 943694505: incoming-call, activity, last_active=943694505, max_idle=5 i4b-L4-i4b_idle_check: 943694505: incoming-call, activity, last_active=943694505, max_idle=5 i4b-L4-cd_by_cdid: found cdid - index=0 cdid=40 cr=1 i4b-L4-cd_by_cdid: found cdid - index=0 cdid=40 cr=1 i4b-L4-i4b_idle_check: 943694506: incoming-call, activity, last_active=943694506, max_idle=5 i4b-L4-cd_by_unitcr: found cd, index=0 cdid=40 cr=1 i4b-L4-freecd_by_cd: releasing cd - index=0 cdid=40 cr=1 i4b-L4-i4b_idle_check: 943694506: incoming-call, activity, last_active=943694506, max_idle=5 i4b-L4-i4b_idle_check: 943694507: incoming-call, activity, last_active=943694507, max_idle=5 i4b-L4-i4b_idle_check: 943694507: incoming-call, activity, last_active=943694507, max_idle=5 i4b-L4-i4b_idle_check: 943694508: incoming-call, activity, last_active=943694508, max_idle=5 i4b-L4-i4b_idle_check: 943694508: incoming-call, activity, last_active=943694508, max_idle=5 i4b-L4-i4b_idle_check: 943694509: incoming-call, activity, last_active=943694509, max_idle=5 i4b-L4-i4b_idle_check: 943694509: incoming-call, activity, last_active=943694509, max_idle=5 i4b-L4-i4b_idle_check: 943694510: incoming-call, activity, last_active=943694510, max_idle=5 i4b-L4-i4b_idle_check: 943694510: incoming-call, activity, last_active=943694510, max_idle=5 i4b-L4-i4b_idle_check: 943694511: incoming-call, activity, last_active=943694511, max_idle=5 i4b-L4-i4b_idle_check: 943694511: incoming-call, activity, last_active=943694511, max_idle=5 i4b-L4-i4b_idle_check: 943694512: incoming-call, activity, last_active=943694512, max_idle=5 i4b-L4-i4b_idle_check: 943694512: incoming-call, activity, last_active=943694512, max_idle=5 i4b-L4-i4b_idle_check: 943694513: incoming-call, activity, last_active=943694512, max_idle=5 i4b-L4-i4b_idle_check: 943694513: incoming-call, activity, last_active=943694512, max_idle=5 i4b-L4-cd_by_cdid: found cdid - index=1 cdid=41 cr=2 i4b-L4-cd_by_cdid: found cdid - index=1 cdid=41 cr=2 i4b-L4-cd_by_unitcr: found cd, index=1 cdid=41 cr=2 i4b-L4-freecd_by_cd: releasing cd - index=1 cdid=41 cr=2 -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 2:38:32 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (Postfix) with SMTP id A4AD31517C; Sat, 27 Nov 1999 02:38:26 -0800 (PST) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1899 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Sat, 27 Nov 1999 11:37:54 +0100 (CET) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11) Received: by hcswork.hcs.de (Postfix, from userid 200) id 27A7838E2; Sat, 27 Nov 1999 11:37:54 +0100 (MET) Subject: Re: Help - I need a login shell over my ISDN line In-Reply-To: <383FA049.79D89520@cs.strath.ac.uk> from Roger Hardiman at "Nov 27, 99 09:11:37 am" To: roger@cs.strath.ac.uk (Roger Hardiman) Date: Sat, 27 Nov 1999 11:37:53 +0100 (MET) Cc: isdn@FreeBSD.ORG, roger@FreeBSD.ORG Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1001 Message-Id: <19991127103754.27A7838E2@hcswork.hcs.de> From: hm@hcs.de (Hellmuth Michaelis) Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From the keyboard of Roger Hardiman: > Having cheked the i4b package closely, it seems there is no way > to set it up so I can dial up the ISDN line and get the good old > ASCII shell and a login prompt. > > Is this true, or is there something I have missed? This is true, but you have missed something :-) True is: currently there is no way to connect to i4b using a modem, i4b does not support a modem simulation or V.110 or V.120 (and probably will never). But coming from an ISDN line using i.e. synchronous PPP and dialling into an i4b machine set up to use sync PPP callin will get you - proper setup done - will get you the good old ASCII shell and a login prompt. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 4:16:17 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 8A42A14C9B; Sat, 27 Nov 1999 04:16:13 -0800 (PST) (envelope-from roger@cs.strath.ac.uk) Received: from muir-10 (roger@muir-10.cs.strath.ac.uk [130.159.148.10]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with SMTP id MAA14678 Sat, 27 Nov 1999 12:16:11 GMT Message-ID: <383FCB8A.41C6@cs.strath.ac.uk> Date: Sat, 27 Nov 1999 12:16:10 +0000 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 3.04Gold (X11; I; OSF1 V4.0 alpha) MIME-Version: 1.0 To: hm@hcs.de Cc: isdn@FreeBSD.ORG, roger@FreeBSD.ORG Subject: Re: Help - I need a login shell over my ISDN line References: <19991127103754.27A7838E2@hcswork.hcs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hellmuth Michaelis wrote: > > > Having cheked the i4b package closely, it seems there is no way > > to set it up so I can dial up the ISDN line and get the good old > > ASCII shell and a login prompt. > > > > Is this true, or is there something I have missed? > > This is true, but you have missed something :-) > > True is: currently there is no way to connect to i4b using a modem, > i4b does not support a modem simulation or V.110 or V.120 (and > probably will never). > > But coming from an ISDN line using i.e. synchronous PPP and dialling > into an i4b machine set up to use sync PPP callin will get you - > proper setup done - will get you the good old ASCII shell and a login > prompt. Ok. Thanks. In my case I am making a 'digial' data call from my Mobile Phone and I set the Mobile Phone from "dialing an anlogue modem/fax" to "dialing an ISDN line" mode. Next week I'll get hold of a new GSM Phone (HSCSD) which supports 42kbits speeds. These _only_ talk to ISDN lines as they do not support any audio modulation. Sorry for being ignorant to V.110 and V.120, but are these the protocols for negotiating the connection speeds for a digital connection. Ie would these be used for my Mobile Phone to tell my ISDN hardware that the phone onlu supports 9600 and not the fill 64kbits? Thanks Roger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 11:18:16 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id 9912A14F08 for ; Sat, 27 Nov 1999 11:18:11 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id UAA07365; Sat, 27 Nov 1999 20:16:50 +0100 (CET) Message-Id: <199911271916.UAA07365@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: freebsd-isdn@freebsd.org Cc: markk@knigma.org Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI From: Gary Jennejohn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Nov 1999 20:16:50 +0100 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, I talked to Hellmuth about the problem and it looks like a change to i4b_hscx.c, which handles it, was not back-ported to the Fritz! PCI driver. This patch will hopefully alleviate, or maybe even fix, the problem. This one compiles :) Please test and report back to the list, thanks. Note that my previous patch is also in it. This should be committed to -STABLE !!!! Not necessary for -current since Hellmuth will be replacing the isdn4bsd code shortly and I've sent him the appropriate patch already. ================================ Patch =========================== *** i4b_avm_fritz_pci.c Fri Nov 26 20:48:55 1999 --- i4b_avm_fritz_pci.c_patched Sat Nov 27 19:19:16 1999 *************** *** 1095,1109 **** MPH_Trace_Ind(&hdr, chan->in_mbuf->m_len, chan->in_mbuf->m_data); } /* move rx'd data to rx queue */ ! IF_ENQUEUE(&chan->rx_queue, chan->in_mbuf); ! (*chan->drvr_linktab->bch_rx_data_ready)(chan->drvr_linktab->unit); - if(!(isic_hscx_silence(chan->in_mbuf->m_data, chan->in_mbuf->m_len))) - activity = ACT_RX; - /* alloc new buffer */ if((chan->in_mbuf = i4b_Bgetmbuf(BCH_MAX_DATALEN)) == NULL) --- 1095,1117 ---- MPH_Trace_Ind(&hdr, chan->in_mbuf->m_len, chan->in_mbuf->m_data); } + if(!(isic_hscx_silence(chan->in_mbuf->m_data, chan->in_mbuf->m_len))) + activity = ACT_RX; + /* move rx'd data to rx queue */ ! if (!(IF_QFULL(&chan->rx_queue))) ! { ! IF_ENQUEUE(&chan->rx_queue, chan->in_mbuf); ! } ! else ! { ! i4b_Bfreembuf(chan->in_mbuf); ! } ! ! /* signal upper layer that data are available */ (*chan->drvr_linktab->bch_rx_data_ready)(chan->drvr_linktab->unit); /* alloc new buffer */ if((chan->in_mbuf = i4b_Bgetmbuf(BCH_MAX_DATALEN)) == NULL) *************** *** 1121,1127 **** chan->rxcount += fifo_data_len; } ! else { DBGL1(L1_H_XFRERR, "avma1pp_hscx_intr", ("RAWHDLC rx buffer overflow in RPF, in_len=%d\n", chan->in_len)); chan->in_cbptr = chan->in_mbuf->m_data; --- 1129,1135 ---- chan->rxcount += fifo_data_len; } ! else { DBGL1(L1_H_XFRERR, "avma1pp_hscx_intr", ("RAWHDLC rx buffer overflow in RPF, in_len=%d\n", chan->in_len)); chan->in_cbptr = chan->in_mbuf->m_data; *************** *** 1364,1369 **** --- 1372,1378 ---- if (sc->sc_chan[HSCX_CH_A].state != HSCX_IDLE || sc->sc_chan[HSCX_CH_B].state != HSCX_IDLE) { + DBGL1(L1_BCHAN, "avma1pp_hscx_init", ("%d NOT deactivated\n", h_chan)); return; } sc->avma1pp_cmd = HSCX_CMD_XRS|HSCX_CMD_RRS; *************** *** 1417,1423 **** if(activate == 0) { /* deactivation */ ! chan->state &= ~HSCX_AVMA1PP_ACTIVE; avma1pp_hscx_init(sc, h_chan, activate); } --- 1426,1432 ---- if(activate == 0) { /* deactivation */ ! chan->state = HSCX_IDLE; avma1pp_hscx_init(sc, h_chan, activate); } *************** *** 1656,1662 **** int len; int nextlen; int i; ! int cmd; /* using a scratch buffer simplifies writing to the FIFO */ u_char scrbuf[HSCX_FIFO_LEN]; --- 1665,1671 ---- int len; int nextlen; int i; ! int cmd = 0; /* using a scratch buffer simplifies writing to the FIFO */ u_char scrbuf[HSCX_FIFO_LEN]; -------- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 11:18:33 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id F159A14F08; Sat, 27 Nov 1999 11:18:29 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id UAA07352; Sat, 27 Nov 1999 20:16:16 +0100 (CET) Message-Id: <199911271916.UAA07352@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Roger Hardiman Cc: isdn@freebsd.org, jen@vulture.dmem.strath.ac.uk, roger@freebsd.org Subject: Re: Help - I need a login shell over my ISDN line Reply-To: Gary Jennejohn In-reply-to: Your message of "Sat, 27 Nov 1999 09:11:37 GMT." <383FA049.79D89520@cs.strath.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Nov 1999 20:16:16 +0100 From: Gary Jennejohn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Roger Hardiman writes: [snip] >I need to move over to ISDN. >So, On FreeBSD I need some way to have getty (or mgetty) >listening to the ISDN, answering the call, starting the login process. > [more snip] >Any ideas, suggestions? > >I'm willing and able to hack code at the low level. > You have a basic misunderstanding. The isdn4bsd stuff is a network service. You use the normal network things like telnet, rlogin, ssh, etc. --- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 14:43: 9 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from nets5.rz.rwth-aachen.de (nets5.rz.RWTH-Aachen.DE [137.226.144.13]) by hub.freebsd.org (Postfix) with ESMTP id 55CA614C03 for ; Sat, 27 Nov 1999 14:43:06 -0800 (PST) (envelope-from heinig@hdz-ima.rwth-aachen.de) Received: from hdz-ima.rwth-aachen.de (s4m235.dialup.RWTH-Aachen.DE [137.226.8.235]) by nets5.rz.rwth-aachen.de (8.9.1a/8.9.1/8) with ESMTP id XAA03499; Sat, 27 Nov 1999 23:43:02 +0100 (MET) Message-ID: <38405E35.9F7D1F55@hdz-ima.rwth-aachen.de> Date: Sat, 27 Nov 1999 23:41:57 +0100 From: Gerald Heinig Organization: Institute of Computer Science in Mech. Eng., Aachen Technical University X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Jennejohn Cc: Roger Hardiman , isdn@FreeBSD.ORG Subject: Re: Help - I need a login shell over my ISDN line References: <199911271916.UAA07352@peedub.muc.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gary Jennejohn wrote: > > Roger Hardiman writes: > [snip] > >I need to move over to ISDN. > >So, On FreeBSD I need some way to have getty (or mgetty) > >listening to the ISDN, answering the call, starting the login process. > > > [more snip] > >Any ideas, suggestions? > > > >I'm willing and able to hack code at the low level. > > > > You have a basic misunderstanding. The isdn4bsd stuff is a network service. > You use the normal network things like telnet, rlogin, ssh, etc. I seem to remember Roger saying he didnīt want ppp for some reason. If raw ip isnīt an option either, then it sounds as though heīs looking for something like X.75 Hmmm... cool idea for a project... :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 16: 2:48 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from bitbucket.extern.uniface.nl (nettle.uniface.nl [193.78.88.130]) by hub.freebsd.org (Postfix) with ESMTP id 2520C14E74 for ; Sat, 27 Nov 1999 16:02:36 -0800 (PST) (envelope-from bert_driehuis@nl.compuware.com) Received: (from smtpd@localhost) by bitbucket.extern.uniface.nl (8.7.6/8.7.3r) id BAA19780; Sun, 28 Nov 1999 01:02:29 +0100 (MET) Received: from trashcan.nl.compuware.com(172.16.16.52) via SMTP by recyclebin.nl.compuware.com, id smtpd019670; Sun Nov 28 01:02:20 1999 Received: from c1111.nl.compuware.com (c1111.nl.compuware.com [172.16.16.36]) by trashcan.nl.compuware.com (Postfix) with ESMTP id 4B95A1504E; Sun, 28 Nov 1999 01:02:19 +0100 (CET) Date: Sun, 28 Nov 1999 01:02:19 +0100 (CET) From: Bert Driehuis To: Mark Knight Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Mark, > The buffer overruns in my earlier logs appear to be a function of the > logging being enabled and my ageing Pentium 90 struggling to keep up. Hmmm, my firewall at home runs an ancient version of BISDN on a 386/20 with 8MB of RAM (the slowest that BSD/OS will even boot on). It has no problem whatsoever keeping up with logging (it is, after all, just 16KBps max that it has to process). Just for kicks, I ran Squid on the thing as well for a while to see if it would survive. It did, but it thrashed a bit :-) Granted, my Pentium 450 that I use for ISDN4BSD runs nicer, but I doubt that a Pentium 90 should not be able to keep up if you're not doing compilations or something else that's big at the same time. So I'd be inclined to assume there's a problem in the code if you can't keep up with logging. Cheers, -- Bert -- Bert Driehuis, MIS -- bert_driehuis@nl.compuware.com -- +31-20-3116119 Hi! I'm a signature virus! Copy me to your .signature and help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 17:20:29 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 7A35714E07 for ; Sat, 27 Nov 1999 17:20:15 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: from localhost (arg@localhost) by arg1.demon.co.uk (8.8.8/8.8.8) with ESMTP id BAA05577; Sun, 28 Nov 1999 01:21:00 GMT (envelope-from arg@arg1.demon.co.uk) Date: Sun, 28 Nov 1999 01:20:59 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Roger Hardiman Cc: isdn@freebsd.org Subject: Re: Help - I need a login shell over my ISDN line In-Reply-To: <383FCB8A.41C6@cs.strath.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 27 Nov 1999, Roger Hardiman wrote: > > In my case I am making a 'digial' data call from my Mobile > Phone and I set the Mobile Phone from "dialing an anlogue > modem/fax" to "dialing an ISDN line" mode. > Next week I'll get hold of a new GSM Phone (HSCSD) which > supports 42kbits speeds. These _only_ talk to ISDN lines > as they do not support any audio modulation. Note however that none of this is ever "end-to-end" ISDN. You are always running a GSM protocol over the wireless link, which implements a bytestream (or bitstream if synchronous mode), and then connects to a modem or TA at the MSC. > Sorry for being ignorant to V.110 and V.120, but > are these the protocols for negotiating the connection > speeds for a digital connection. These are 'rate adaption' protocols, for transferring data between RS232 (V.24) ports on the terminal adaptors, in the case where the data rate is not the same as that of the B channel. V.110 simply involves stuffing extra bits into an async data stream to make it come out at the right rate; officially, it only permits low speeds (max 19200 IIRC), but I have seen implementations (not strictly conformant) that use the same scheme up to 38400 bps. V.120 packetizes the data, and transmits it over the B channel in HDLC frames, with packet-level flow control and optional error protection. > Ie would these be used for my Mobile Phone to tell my > ISDN hardware that the phone onlu supports 9600 and not > the fill 64kbits? In effect, yes. These are the protocols used inside the B channel to actually perform the rate adaption; the fact that you are using (say) V.120 rate adaption can be signalled in the call setup protocols on the D channel. From an I4B point of view, the hard part is not implementing the protocols themselves, but the infrastructure to support them: Rec. V.120 itself is only 36 pages, and the code to do HDLC over the B channel already exists for other other purposes in I4B. The major stuff to write is the tty handling, call set-up control etc. In BISDN, there was a skeleton of this, doing all the work in the kernel. However, it occurs to me that you might be able to save a lot of work by doing it as a daemon: you can get all the tty stuff by sitting on the back end of a pty, and you can probably get most of the ISDN interface out of the RBCH stuff that /usr/sbin/ppp has recently started using: it needs to do much the same work (exchanging HDLC frames over the B channel, dialling calls etc.). One thing I am not sure of is whether /usr/sbin/ppp is able to accept incoming ISDN calls (I haven't been following that work too closely). If it does, then all the interfaces you need are there to drop in a V.120 daemon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Nov 27 18:24: 5 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from bitbucket.extern.uniface.nl (nettle.uniface.nl [193.78.88.130]) by hub.freebsd.org (Postfix) with ESMTP id A917214CA4 for ; Sat, 27 Nov 1999 18:24:02 -0800 (PST) (envelope-from bert_driehuis@nl.compuware.com) Received: (from smtpd@localhost) by bitbucket.extern.uniface.nl (8.7.6/8.7.3r) id DAA25326; Sun, 28 Nov 1999 03:24:00 +0100 (MET) Received: from trashcan.nl.compuware.com(172.16.16.52) via SMTP by recyclebin.nl.compuware.com, id smtpd025311; Sun Nov 28 03:23:57 1999 Received: from c1111.nl.compuware.com (c1111.nl.compuware.com [172.16.16.36]) by trashcan.nl.compuware.com (Postfix) with ESMTP id ECEED1504E; Sun, 28 Nov 1999 03:23:56 +0100 (CET) Date: Sun, 28 Nov 1999 03:23:56 +0100 (CET) From: Bert Driehuis To: Andrew Gordon Cc: Roger Hardiman , isdn@FreeBSD.ORG Subject: Re: Help - I need a login shell over my ISDN line In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 28 Nov 1999, Andrew Gordon wrote: > From an I4B point of view, the hard part is not implementing the protocols > themselves, but the infrastructure to support them: Rec. V.120 itself is > only 36 pages, and the code to do HDLC over the B channel already exists > for other other purposes in I4B. The major stuff to write is the tty > handling, call set-up control etc. Errr... I tried doing just that, and found that that something is very different between the B-channel data used for e.g. PPP and for V.120 (that, or all of the V.120 implementations I used for reference don't produce a packet that is formed like the V.120 spec suggests). The data I see when I do a packet dump for an incoming call from a V.120 device doesn't even look like the data format described in recommendation V.120. Maybe I'm overlooking the obvious, though. I tried the rbch driver in one of the attempts (writing a userland driver to access it is, as you say, pretty straightforward). That said, the V.120 protocol is not complicated, so it seems quite appropriate to put it into the kernel and just be another kind of tty, which would make running, say, a getty on the thing trivial. The terminal interface stuff already is in i4b, so all we need is the V.120 glue. > In BISDN, there was a skeleton of this, doing all the work in the > kernel. However, it occurs to me that you might be able to save a lot of > work by doing it as a daemon: you can get all the tty stuff by sitting on > the back end of a pty, and you can probably get most of the ISDN interface > out of the RBCH stuff that /usr/sbin/ppp has recently started using: it > needs to do much the same work (exchanging HDLC frames over the B channel, > dialling calls etc.). I don't recall anything even resembling V.120 in bisdn. There was a terminal thing over the B channel, but that was not V.120 to my recollection. > One thing I am not sure of is whether /usr/sbin/ppp is able to accept > incoming ISDN calls (I haven't been following that work too closely). If > it does, then all the interfaces you need are there to drop in a V.120 > daemon. Well, I hope to be corrected, but I've been staring at packet dumps and the V.120 specs for weeks and sort of found it needs some specific support at the HDLC level. I've been tearing out my hair by the handful over this thing... Cheers, -- Bert Bert Driehuis, MIS -- bert_driehuis@nl.compuware.com -- +31-20-3116119 Hi! I'm a signature virus! Copy me to your .signature and help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message