From owner-freebsd-isdn@FreeBSD.ORG Sun Dec 2 09:42:27 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F08FB33 for ; Sun, 2 Dec 2012 09:42:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 916828FC12 for ; Sun, 2 Dec 2012 09:42:25 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 184964467; Sun, 02 Dec 2012 10:42:18 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Sun, 2 Dec 2012 10:43:53 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201211300844.37917.hselasky@c2i.net> <50BA8DB8.1090004@incore.de> In-Reply-To: <50BA8DB8.1090004@incore.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ZLyuQ4VGST/Pd/1" Message-Id: <201212021043.53151.hselasky@c2i.net> Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 09:42:27 -0000 --Boundary-00=_ZLyuQ4VGST/Pd/1 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Sunday 02 December 2012 00:07:36 Andreas Longwitz wrote: > Hi, > > >> First step of analyze is done: I see in the isdntrace that several of > >> > >> the incoming D-channel frames have an extra byte at the end of the frame: > >> 10101110 UNKNOWN single octet IE = 0xae > >> > >> Further I see many single outgoing bytes on L3 level: > >> L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) > > I have to correct myself: Further I see many single incoming (not > outgoing) bytes. In the meantime I am convinced that every incoming L2 > frame from the card has exactly one superfluos byte at the end. > > >> On the other side of the ISDN-line all length are correct. Maybe there > >> is a "one byte length problem" in the D-channel communication between > >> the i4b driver and the card. > > > > Maybe you can read out the chip numbers? Maybe some of the chips used are > > documented. Should not be impossible to get this working! > > Would be fine! The driver working in FreeBSD 6 gives ifpi2-0: ISACSX > PSB3186, but this is hardcoded in the source. On the chip I can read > "AVM PSB 3100 F". > > > Should be easy to compare with the old driver from FreeBSD 6.x. > > In the meantime I was able to do a verbose boot. Sounds strange, but > there was a another problem solved by Andriy Gapon: > lists.freebsd.org/pipermail/freebsd-stable/2012-November/070634.html. > > During verbose boot i4b gives for my AVM Fritz!Card version 2 PCI card: > > i4b-L1 ihfc1: ihfc_pnp_probe_sub: this unit has 6 transmit and > receive channels and 1 sub-controllers > i4b-L1 ihfc1: ihfc_alloc_all_resources: Internal IRQ-address: 0x17 > ihfc1: Reserved 0x20 bytes for rid 0x10 type 3 at 0xfb145000 > i4b-L1 ihfc1: ihfc_fifo_setup_soft: HFC_MAX_FRAMES >= f->fm.h.Fsize > i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x48 > i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x20 > i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00 > i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000014 ista=0x0000, > exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00 > i4b-L1 ihfc1: ihfc_fsm_update: Undefined state: 1!. (p0,a0,c0,u0,d0,i1) > ihfc1: port 0x54c0-0x54df mem > 0xfb145000-0xfb14501f irq 23 at device 7.0 on pci0 > i4b-L1 ihfc1: ihfc_post_setup: Setting up IRQ > ihfc1: [MPSAFE] > ihfc1: [ITHREAD] > ihfc1: Attaching I4B controller 0. > i4b-L1 ihfc1: ihfc_B_get_fifo_translator: > ihfc1: Creating /dev/ihfc0.X. > i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x49 > i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x11 > i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90 > i4b-L1 ihfc1: ihfc_fsm_update: Activate indication (priority=8/9). > (p0,a1,c1,u0,d0,i0) > i4b-L1 ihfc1: fsm_write: Start activation, cmd[0]=0x20 > i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00 > i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00 > i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000010 ista=0x0000, > exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00 > > Maybe the "Undefined state" message in ihfc_fsm_update gives a hint ? > > P.S. > With bootverbose in function ihfc_pnp_probe_sub() the debugbit > L1_HFC_DBG is set producing very very lot of messages and the system > comes to complete congestion, therefore after a few minutes my watchdog > triggers, If you think this not ok, then I can give more details. At the > moment I avoid this problem reliable with "isdndebug -d" as soon as > userland gets control after verbose boot. Hi, The warning can be ignored I think. I see that my driver differs a bit from the origin. That's basically my fault, when I did the porting, I tried to make things simpler. Maybe I have to port more stuff from the working one. Mostly it requires some 32-bit register magic instead of 8-bit register access. I'm using transparent mode only for B- channels, and have optimised away some programming in that regard. http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.19.22.1 Can you try the attached patch? --HPS --Boundary-00=_ZLyuQ4VGST/Pd/1 Content-Type: text/x-patch; charset="iso-8859-1"; name="i4b_avm_pci.h.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="i4b_avm_pci.h.diff" Index: src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h =================================================================== --- src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (revision 2511) +++ src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (working copy) @@ -113,9 +113,19 @@ if(reg & 0x80) { + enum { BUFFER_SIZE = 64 }; + u_int32_t buffer[BUFFER_SIZE]; + IHFC_LEN_T x; + + if (len > BUFFER_SIZE) + len = BUFFER_SIZE; /* should not happen */ + /* ISAC-SX REGISTER */ bus_space_write_4(t, h, REG_ISACSX_INDEX, (reg & 0x7F)); - bus_space_read_multi_1(t, h, REG_ISACSX_DATA, ptr, len); + bus_space_read_multi_4(t, h, REG_ISACSX_DATA, buffer, len); + + for (x = 0; x != len; x++) + ptr[x] = (u_int8_t)buffer[x]; } else { @@ -148,9 +158,19 @@ if(reg & 0x80) { + enum { BUFFER_SIZE = 64 }; + u_int32_t buffer[BUFFER_SIZE]; + IHFC_LEN_T x; + + if (len > BUFFER_SIZE) + len = BUFFER_SIZE; /* should not happen */ + + for (x = 0; x != len; x++) + buffer[x] = ptr[x]; + /* ISAC-SX REGISTER */ bus_space_write_4(t, h, REG_ISACSX_INDEX, (reg & 0x7F)); - bus_space_write_multi_1(t, h, REG_ISACSX_DATA, ptr, len); + bus_space_write_multi_4(t, h, REG_ISACSX_DATA, buffer, len); } else { @@ -215,7 +235,8 @@ { IPAC_BUS_VAR(sc); - u_int8_t buffer[0x40 + 0x10]; /* allocate a buffer on the stack */ + /* allocate a buffer on the stack */ + u_int32_t buffer[(0x40 + 0x10) / 4]; u_int8_t temp; /* read status */ @@ -257,9 +278,9 @@ /* read FIFO */ bus_space_read_multi_4(t, h, offset + HSCX_FIFO, - (void *)&buffer[0], (temp+3)/4); + buffer, (temp + 3) / 4); - (f+receive)->Z_ptr = &buffer[0]; + (f+receive)->Z_ptr = (uint8_t *)buffer; (f+receive)->Z_chip = temp; /* call filter */ @@ -279,7 +300,7 @@ temp = 32; (f+transmit)->i_ista &= ~(I_ISTA_ERR|I_ISTA_XPR); - (f+transmit)->Z_ptr = &buffer[0]; + (f+transmit)->Z_ptr = (uint8_t *)buffer; (f+transmit)->Z_chip = temp; /* call filter */ @@ -299,9 +320,16 @@ /* update state */ (f+transmit)->state &= ~(ST_FRAME_ERROR|ST_FRAME_END); + /* write FIFO length */ + bus_space_write_1(t, h, offset + HSCX_LEN, 0); + + /* write FIFO command */ + bus_space_write_1(t, h, offset + HSCX_STAT, + HSCX_CMD_XME); + /* write FIFO */ bus_space_write_multi_4(t, h, offset + HSCX_FIFO, - (void *)&buffer[0], (temp+3)/4); + buffer, (temp + 3) / 4); } return; } --Boundary-00=_ZLyuQ4VGST/Pd/1-- From owner-freebsd-isdn@FreeBSD.ORG Sun Dec 2 23:54:01 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFB0E4F0 for ; Sun, 2 Dec 2012 23:54:01 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 743CD8FC12 for ; Sun, 2 Dec 2012 23:54:01 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 9BD7F5CFF9; Mon, 3 Dec 2012 00:54:00 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 53EGnDLZbaC8; Mon, 3 Dec 2012 00:53:59 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 43A9D5CFF8; Mon, 3 Dec 2012 00:53:59 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id BA82D5083F; Mon, 3 Dec 2012 00:53:58 +0100 (CET) Message-ID: <50BBEA16.3060004@incore.de> Date: Mon, 03 Dec 2012 00:53:58 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201211300844.37917.hselasky@c2i.net> <50BA8DB8.1090004@incore.de> <201212021043.53151.hselasky@c2i.net> In-Reply-To: <201212021043.53151.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 23:54:01 -0000 Hans Petter Selasky wrote: > I see that my driver differs a bit from the origin. That's basically my fault, > when I did the porting, I tried to make things simpler. Maybe I have to port > more stuff from the working one. Mostly it requires some 32-bit register magic > instead of 8-bit register access. I'm using transparent mode only for B- > channels, and have optimised away some programming in that regard. > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.19.22.1 > > Can you try the attached patch? Yes I did, but was not happy, nothing changed. I have introduced some messages in the source and get this every 10 seconds: i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x80 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xae i4b-L1 ihfc1: avm_pci_fifo_read: len=5 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5 i4b-L1 ihfc1: avm_pci_chip_read: got 0x02d30151ae The corresponding isdndecode looks like this: -- NT->TE - unit:00 frame:000059 - time:03.12 00:07:14.744795 - length:5 ----- L2 00 02 000000-- SAPI = 0 (Call Control) ------1- C/R = Command -------0 Extension Bit = 0 (with extension, octet follows) L2 01 D3 1101001- TEI = 105 = 0x69 (Automatic TEI) -------1 Extension Bit = 1 (no extension, final octet) L2 02 01 00000001 S-Frame: RR (Receiver Ready) L2 03 51 0101000- N(R) = 40 (receive sequence number) -------1 P/F, Poll = Immediate Response Required L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) Dumping Layer3 data, 0 bytes: -- Andreas Longwitz From owner-freebsd-isdn@FreeBSD.ORG Mon Dec 3 11:29:49 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A5603AA for ; Mon, 3 Dec 2012 11:29:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id D5C6E8FC15 for ; Mon, 3 Dec 2012 11:29:48 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 178579366; Mon, 03 Dec 2012 12:24:39 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Mon, 3 Dec 2012 12:26:14 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201212021043.53151.hselasky@c2i.net> <50BBEA16.3060004@incore.de> In-Reply-To: <50BBEA16.3060004@incore.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201212031226.14851.hselasky@c2i.net> Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 11:29:49 -0000 On Monday 03 December 2012 00:53:58 Andreas Longwitz wrote: > Hans Petter Selasky wrote: > > I see that my driver differs a bit from the origin. That's basically my > > fault, when I did the porting, I tried to make things simpler. Maybe I > > have to port more stuff from the working one. Mostly it requires some > > 32-bit register magic instead of 8-bit register access. I'm using > > transparent mode only for B- channels, and have optimised away some > > programming in that regard. > > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.1 > > 9.22.1 > > > > Can you try the attached patch? > > Yes I did, but was not happy, nothing changed. I have introduced some > messages in the source and get this every 10 seconds: > > i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 > i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 > i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 > i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x80 > i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 > i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05 > i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 > i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xae > i4b-L1 ihfc1: avm_pci_fifo_read: len=5 > i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5 > i4b-L1 ihfc1: avm_pci_chip_read: got 0x02d30151ae > > The corresponding isdndecode looks like this: > > -- NT->TE - unit:00 frame:000059 - time:03.12 00:07:14.744795 - > length:5 ----- > L2 00 02 000000-- SAPI = 0 (Call Control) > ------1- C/R = Command > -------0 Extension Bit = 0 (with extension, octet follows) > L2 01 D3 1101001- TEI = 105 = 0x69 (Automatic TEI) > -------1 Extension Bit = 1 (no extension, final octet) > L2 02 01 00000001 S-Frame: RR (Receiver Ready) > L2 03 51 0101000- N(R) = 40 (receive sequence number) > -------1 P/F, Poll = Immediate Response Required > L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) > Dumping Layer3 data, 0 bytes: Hi, Could you show what code you added? I think we are onto something. The rstad=0xae too, so apparently this byte is added to the FIFO. Could you try to send a dummy frame that is greater than 64 bytes? I want to see if len = 0, is used at all. --HPS From owner-freebsd-isdn@FreeBSD.ORG Mon Dec 3 15:45:22 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA7C1987 for ; Mon, 3 Dec 2012 15:45:22 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD2F8FC12 for ; Mon, 3 Dec 2012 15:45:21 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 028E95D052; Mon, 3 Dec 2012 16:45:21 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id om4TmLjpxIxw; Mon, 3 Dec 2012 16:45:19 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 70C4F5D05A; Mon, 3 Dec 2012 16:45:18 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 35C5750879; Mon, 3 Dec 2012 16:45:18 +0100 (CET) Message-ID: <50BCC90E.7080104@incore.de> Date: Mon, 03 Dec 2012 16:45:18 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201212021043.53151.hselasky@c2i.net> <50BBEA16.3060004@incore.de> <201212031226.14851.hselasky@c2i.net> In-Reply-To: <201212031226.14851.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:45:22 -0000 Hans Petter Selasky wrote: > Could you show what code you added? Yes of course: In i4b_avm_pci.h I have applied your last patch and then added some IHFC_ERR messages triggered by debug.bootverbose: --- i4b_avm_pci.h 2012-12-03 15:27:20.000000000 +0100 +++ i4b_avm_pci.h.debug 2012-12-03 00:29:03.000000000 +0100 @@ -111,6 +111,10 @@ { IPAC_BUS_VAR(sc); + if (bootverbose) { + IHFC_ERR("reg=0x%04x, len=%d\n", reg, len); + } + if(reg & 0x80) { enum { BUFFER_SIZE = 64 }; @@ -126,6 +130,12 @@ for (x = 0; x != len; x++) ptr[x] = (u_int8_t)buffer[x]; + if (bootverbose && len == 4) { + IHFC_ERR("got 0x%02x%02x%02x%02x\n", ptr[0],ptr[1],ptr[2],ptr[3]); + } + if (bootverbose && len == 5) { + IHFC_ERR("got 0x%02x%02x%02x%02x%02x\n", ptr[0],ptr[1],ptr[2],ptr[3],ptr[4]); + } } else { @@ -139,6 +149,9 @@ { if(FIFO_NO(f) == d1r) { + if (bootverbose) { + IHFC_ERR("len=%d\n", len); + } avm_pci_chip_read(sc,(f->fm.h.Zdata),ptr,len); } else @@ -209,6 +222,9 @@ /* read CIR0 */ avm_pci_chip_read(sc, REG_isacsx_cir0, &temp, 1); + if (bootverbose) { + IHFC_ERR("cir0=0x%02x\n", temp); + } *ptr = (temp >> 4) & 0xf; @@ -357,23 +373,33 @@ /* read ISTA (ISAC) */ avm_pci_chip_read(sc, REG_isacsx_ista, &ista, 1); - IHFC_MSG("ista=0x%02x\n", ista); + if (bootverbose) { + IHFC_ERR("ista=0x%02x\n", ista); + } if(ista & 0x01 /* ICD */) { /* read ISTAD (ISAC) */ avm_pci_chip_read(sc, REG_isacsx_istad, &ista_d, 1); - IHFC_MSG("ista_d=0x%02x\n", ista_d); + if (bootverbose) { + IHFC_ERR("ista_d=0x%02x\n", ista_d); + } if(ista_d & 0x80 /* RME */) { /* read RBCL (ISAC) */ avm_pci_chip_read(sc, REG_isacsx_rbcld, &temp, 1); + if (bootverbose) { + IHFC_ERR("rbcld=0x%02x\n", temp); + } sc->sc_fifo[d1r].Z_chip = temp; /* read RSTA (ISAC) */ avm_pci_chip_read(sc, REG_isacsx_rstad, &temp, 1); + if (bootverbose) { + IHFC_ERR("rstad=0x%02x\n", temp); + } sc->sc_fifo[d1r].F_chip = temp; } > I think we are onto something. The rstad=0xae too, so apparently this byte is > added to the FIFO. > > Could you try to send a dummy frame that is greater than 64 bytes? I want to > see if len = 0, is used at all. I am sorry, but I don't know how to generate a frame in D-channel with more than 64 bytes. If I activate the extra debug messages with sysctl debug.bootverbose=1 and try a ping to the other side of the isp0 interface, the system crashes after some debugging output: i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00ae, len=1 i4b-L1 ihfc1: avm_pci_fsm_read: cir0=0xc0 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x09 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xab i4b-L1 ihfc1: avm_pci_fifo_read: len=9 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=9 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x04 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xac i4b-L1 ihfc1: avm_pci_fifo_read: len=4 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=4 i4b-L1 ihfc1: avm_pci_chip_read: got 0x009573ac i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xae i4b-L1 ihfc1: avm_pci_fifo_read: len=5 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5 i4b-L1 ihfc1: avm_pci_chip_read: got 0x00950102ac i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x0d i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xac i4b-L1 ihfc1: avm_pci_fifo_read: len=13 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=13 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x80 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xac i4b-L1 ihfc1: avm_pci_fifo_read: len=5 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5 i4b-L1 ihfc1: avm_pci_chip_read: got 0x00950105ac i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01 i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x14 panic: vm_fault: fault on nofault entry, addr: e5158000 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0984233,fb,e514b7a4,c08f2ed3,fb,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c09a2e37,0,c09992fe,e514b80c,0,...) at kdb_backtrace+0x2a panic(c09992fe,e5158000,1,e514b948,e514b938,...) at panic+0x15c vm_fault(c17dc000,e5158000,1,0,4175e6,...) at vm_fault+0x1a4 trap_pfault(c4d332e0,4,c097e974,369,c4d31560,...) at trap_pfault+0x284 trap(e514ba60) at trap+0x3f3 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0bd2338, esp = 0xe514baa0, ebp = 0xe514bbc0 --- avm_pci_chip_write(c50cd000,80,c6334800,0,c50cd000,...) at avm_pci_chip_write+0xa8 filter_tx(c50cddd8,20,e514bc2c,c0bcf372,c50cd000,...) at filter_tx+0x57 tx_hdlc(c50cd000,c50cddd8,c0bfeb4e,c50cd000,c0bfa0ca,...) at tx_hdlc+0x5e i4b_ipac_tx_program(c50cd000,c50cddd8,c4de3b80,e514bc4c,1,...) at i4b_ipac_tx_program+0x62 __ihfc_chip_interrupt(c50cd000,0,c0bfd197,39b,c4f212c0,...) at __ihfc_chip_interrupt+0x171 ihfc_chip_interrupt(c50cd000,c4de38a0,0,109,73e3dd24,...) at ihfc_chip_interrupt+0x38 intr_event_execute_handlers(c4d31560,c4d76b80,c097e974,52c,c4d76bf0,...) at intr_event_execute_handlers+0x13b ithread_loop(c525b040,e514bd28,0,c4d31560,0,...) at ithread_loop+0x6b fork_exit(c06b0290,c525b040,e514bd28) at fork_exit+0x97 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe514bd60, ebp = 0 --- KDB: enter: panic [thread pid 12 tid 100028 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db:0:kdb.enter.panic> watchdog No argument provided, disabling watchdog db:0:kdb.enter.panic> run ddbinfo db:1:ddbinfo> capture on db:1:on> run lockinfo db:2:lockinfo> show lock Giant class: sleep mutex name: Giant flags: {DEF, RECURSE} state: {UNOWNED} db:2:Giant> show lockedvnods Locked vnodes 0xc5d0cb84: tag ufs, type VREG usecount 1, writecount 1, refcount 24 mountedhere 0 flags () v_object 0xc5f3e908 ref 0 pages 88 lock type ufs: EXCL by thread 0xc5be02e0 (pid 858) ino 94218, on dev amrd0p4 db:2:lockedvnods> show lockchain thread 100028 (pid 12, irq23: ihfc1) running on CPU 0 db:2:lockchain> show sleepchain thread 100028 (pid 12, irq23: ihfc1) running on CPU 0 db:1:sleepchain> show pcpu cpuid = 0 dynamic pcpu = 0x61ed80 curthread = 0xc4de38a0: pid 12 "irq23: ihfc1" curpcb = 0xe514bd80 fpcurthread = none idlethread = 0xc4d335c0: tid 100004 "idle: cpu0" APIC ID = 3 currentldt = 0x50 db:1:pcpu> show allpcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0x61ed80 curthread = 0xc4de38a0: pid 12 "irq23: ihfc1" curpcb = 0xe514bd80 fpcurthread = none idlethread = 0xc4d335c0: tid 100004 "idle: cpu0" APIC ID = 3 currentldt = 0x50 cpuid = 1 dynamic pcpu = 0x3fbcd80 curthread = 0xc5be1b80: pid 1104 "isdndecode" curpcb = 0xe7463d80 fpcurthread = none idlethread = 0xc4d338a0: tid 100003 "idle: cpu1" APIC ID = 0 currentldt = 0x50 db:1:allpcpu> bt Tracing pid 12 tid 100028 td 0xc4de38a0 kdb_enter(c098203e,c098203e,c09992fe,e514b80c,0,...) at kdb_enter+0x3a panic(c09992fe,e5158000,1,e514b948,e514b938,...) at panic+0x179 vm_fault(c17dc000,e5158000,1,0,4175e6,...) at vm_fault+0x1a4 trap_pfault(c4d332e0,4,c097e974,369,c4d31560,...) at trap_pfault+0x284 trap(e514ba60) at trap+0x3f3 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0bd2338, esp = 0xe514baa0, ebp = 0xe514bbc0 --- avm_pci_chip_write(c50cd000,80,c6334800,0,c50cd000,...) at avm_pci_chip_write+0xa8 filter_tx(c50cddd8,20,e514bc2c,c0bcf372,c50cd000,...) at filter_tx+0x57 tx_hdlc(c50cd000,c50cddd8,c0bfeb4e,c50cd000,c0bfa0ca,...) at tx_hdlc+0x5e i4b_ipac_tx_program(c50cd000,c50cddd8,c4de3b80,e514bc4c,1,...) at i4b_ipac_tx_program+0x62 __ihfc_chip_interrupt(c50cd000,0,c0bfd197,39b,c4f212c0,...) at __ihfc_chip_interrupt+0x171 ihfc_chip_interrupt(c50cd000,c4de38a0,0,109,73e3dd24,...) at ihfc_chip_interrupt+0x38 intr_event_execute_handlers(c4d31560,c4d76b80,c097e974,52c,c4d76bf0,...) at intr_event_execute_handlers+0x13b ithread_loop(c525b040,e514bd28,0,c4d31560,0,...) at ithread_loop+0x6b fork_exit(c06b0290,c525b040,e514bd28) at fork_exit+0x97 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe514bd60, ebp = 0 --- db:1:bt> ps pid ppid pgrp uid state wmesg wchan cmd 11060 10660 11060 0 S+ select 0xc5f621a4 ping 11010 1151 23 0 S nanslp 0xc0a37984 sleep 10660 10659 10660 0 S+ wait 0xc5b47810 sh ...... 100028 Run CPU 0 [irq23: ihfc1] ...... db:1:ps> show thread Thread 100028 at 0xc4de38a0: proc (pid 12): 0xc4d31560 name: irq23: ihfc1 stack: 0xe514a000-0xe514bfff flags: 0x4 pflags: 0x200500 state: RUNNING (CPU 0) priority: 16 container lock: sched lock 0 (0xc0a3b980) db:1:thread> alltrace Tracing command ping pid 11060 tid 100157 td 0xc64388a0 sched_switch(c64388a0,0,104,3ceeb53c,316c,...) at sched_switch+0x293 mi_switch(104,0,c5f62180,c6490000,e7553a2c,...) at mi_switch+0x12f sleepq_switch(c64388a0,0,c0985116,1a5,c64388a0,...) at sleepq_switch+0xcc sleepq_catch_signals(c5f62180,0,c64388a0,e7553a78,c06910f7,...) at sleepq_catch_signals+0x52 sleepq_timedwait_sig(c5f621a4,0,c0986a0f,101,0,...) at sleepq_timedwait_sig+0x1c _cv_timedwait_sig(c5f621a4,c5f62190,3e9,c8833670,58,...) at _cv_timedwait_sig+0x1b7 seltdwait(e7553c18,e7553c20,c5ced000,c64388a0,e7553ac8,...) at seltdwait+0xc1 kern_select(c64388a0,4,bfbee854,0,0,e7553c60,20,0,f4231) at kern_select+0x571 select(c64388a0,e7553cec,c,c,c,...) at select+0x66 syscall(e7553d28) at syscall+0x342 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (93, FreeBSD ELF32, select), eip = 0x881a5053, esp = 0xbfbee74c, ebp = 0xbfbfec18 --- .... db:1:alltrace> capture off db:0:kdb.enter.panic> call doadump Physical memory: 1011 MB Dumping 168 MB: I get this debug information via a ddb configuration in ddb.conf. Unfortunately the write of the dump hangs, but that is another story. If it is relevant, I can give more stack traces or any other debug information. Andreas Longwitz