From owner-freebsd-drivers@FreeBSD.ORG Mon Feb 10 08:36:13 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 689E6770 for ; Mon, 10 Feb 2014 08:36:13 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CEAA312B0 for ; Mon, 10 Feb 2014 08:36:12 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so4457221lbi.39 for ; Mon, 10 Feb 2014 00:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4NQkRo6KCT6stxzgndcGQ1hLvOREdQRqT2LspF5cj+w=; b=b0OiVtDl7ZZOzyl/GXDBOqRVS/g0KYBqte8lfVYCVrn/8GHqJR2scf8K1BqLGP/NVW aBkGI/MWx78XfIQlQ6vMlCxwaYfI/YhLwWH72gZgKs9PVZnLvNEF6U+wn4dC+YvTcTlU h8qbMtgNAqA+014bSg6RuCIwPRwt3a7+PIkzQ6dUhdu6xrpJkW8GrLZUt3pkOhDI+oKx KF+aZqxCIMXXkrtoCBPp+jb5awX+ZqvtUPH6wbnq8R187CllbiB3g1JaEWpOii1XFXmR reVSn9wn7OICPZ/7SezORGGHwx2FH4f544G8IgC+JDW2cDwoPA6DS+5v6AkM1O4HZdGx 1btw== MIME-Version: 1.0 X-Received: by 10.152.42.196 with SMTP id q4mr304402lal.52.1392021370776; Mon, 10 Feb 2014 00:36:10 -0800 (PST) Received: by 10.112.134.195 with HTTP; Mon, 10 Feb 2014 00:36:10 -0800 (PST) In-Reply-To: <20140207164122.GE89104@funkthat.com> References: <52F49D36.8000103@gmail.com> <20140207164122.GE89104@funkthat.com> Date: Mon, 10 Feb 2014 10:36:10 +0200 Message-ID: Subject: Re: Receiving jumbo frames From: Viktor Penkoff To: Viktor , freebsd-drivers@freebsd.org Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 08:36:13 -0000 The line that the panic happens is in a standard invoking receive interrupt function. Packet data is stored in memory buffers, with any single packet spanning multiple buffers if necessary. The buffers are allocated by the CPU and are managed through chained descriptor lists. When I'm sending jumbo packets, e.g. 8008 bytes in size each, due to live debugging with jtag and kgdb, I've got the following information for the mbuf: % ping -I eth0 -c 1 -s 8000 -M dont A.B.C.D -v -p ff {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xc3d41800 "", mh_len =3D 2048, mh_flags =3D 3, mh_type =3D 1, pad =3D "\000"}, M_dat = =3D { MH =3D {MH_pkthdr =3D {rcvif =3D 0x0, header =3D 0x0, len =3D 2048, flo= wid =3D 0, csum_flags =3D 0, csum_data =3D 0, tso_segsz =3D 0, PH_vt =3D { vt_vtag =3D 0, vt_nrecs =3D 0}, tags =3D {slh_first =3D 0x0}, dsa_tag =3D {0, 0}}, MH_dat =3D {MH_ext =3D {ext_buf =3D 0xc3d41800= "", ext_free =3D 0, ext_arg1 =3D 0x0, ext_arg2 =3D 0x0, ext_size =3D = 2048, ref_cnt =3D 0xc3d3f244, ext_type =3D 6}, In this case, the given mbuf must occupy ~4 descriptors, IMO. Following the next pointer in the descriptor list, the next one shows that the CPU has an ownership. Nevertheless, =F2he byte count of the received frame shows th= at 8056 bytes are received. More interesting is the fact that an echo reply is given back. But after a constant count of received packets, the kernel hangs. 2014-02-07 18:41 GMT+02:00 John-Mark Gurney : > Viktor wrote this message on Fri, Feb 07, 2014 at 10:45 +0200: > > Hi, folks! I'm writing an extension functionality to not-yet published > > network driver. > > I'm receiving the typical ethernet frames without problems. Considering > > the datasheet of the device, > > I'm capable of receiving jumbo frames. When I try to do that, e.g. to > > send jumbo frame of 8000 bytes, I'm receiving only a limited count of > > them - 105, then the kernel crashes with the following message: > > "panic: vm_fault: fault on nofault entry, addr: cfcec000". > > This happens when you access an address in kmem (kernel space) that > no longer has a page mapped... This is probably due to a pointer > that was previously valid, but then you aren't suppose to have and the > kernel unmapped the page because the subsystem free'd it... > > > I have inspected a kernel dump with kgdb and the problem occurs at the > > function bus_dmamap_sync. > > What part of this? It could be that you are trying to _sync a buffer > that doesn't belong to you anymore... > > Are you making sure that you allocate new frames to replace them in the > receive buffer? > > > Some background information: > > To enable the jumbo frame, one must set the appropriate register. > > At the software level, a ring buffer with the descriptors is implemente= d. > > The device, under which the driver runs, is arm-based. > > The freebsd version is 8.0. The device uses SerialDMA queues for > > transmitting and receiving. > > To receive packets, the CPU must perform the following: > > 1. Prepare a linked list of descriptors > > 2. Configure a given queue with the address of the first descriptor > > in the list, > > 3. enable SerialDMA; > > > > With the transmission - I don't have any problems. The logic is the sam= e > > as by the reception of packets - ring buffer with descriptors. > > > > Any ideas what can cause this type of crashes? > > With out better idea of what the driver is doing, or a line on which > the panic happens, the above is about all I can think of... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." >