Date: Sun, 3 Jun 2007 15:39:56 +0200 (CEST) From: Arne H Juul <arnej@yahoo-inc.com> To: current@freebsd.org Subject: panic in tulip_rx_intr after recent changes Message-ID: <Pine.BSO.4.64.0706031537040.19155@murphy.trondheim.corp.yahoo.com>
next in thread | raw e-mail | index | archive | help
(this mail didn't make it to the list from my private
address, so I'm resending it from work instead; my
apologies if it suddenly appears multiple times)
I'm getting a kernel panic during network startup with the
"de" driver. Here's the messages from the crash dump:
<118>Mounting local file systems:
<118>.
<118>Setting hostname: bluebox.trondheim.corp.yahoo.com.
<118>net.inet6.ip6.auto_linklocal:
<118>1
<118> ->
<118>0
<118>
de0: unable to load rx map, error = 27
panic: tulip_rx_intr
cpuid = 0
KDB: enter: panic
Uptime: 13s
I think this must have been introduced during the last week
or so on -CURRENT; my old kernel works OK:
arnej@bluebox:~ $ uname -a
FreeBSD bluebox 7.0-CURRENT FreeBSD 7.0-CURRENT #13: Tue May 29 08:02:41 CEST
2007 root@bluebox:/usr/obj/home/src.cur/sys/GENERIC amd64
as you can see this is on amd64 platform.
it crashes here (in if_de.c):
3557 error = bus_dmamap_load_mbuf(ri->ri_data_tag,
*nextout->di_map, ms,
3558 tulip_dma_map_rxbuf, nextout->di_desc,
BUS_DMA_NOWAIT);
3559 if (error) {
3560 device_printf(sc->tulip_dev,
3561 "unable to load rx map, error = %d\n",
error);
3562 panic("tulip_rx_intr"); /* XXX */
3563 }
errno 27 is EFBIG, and indeed the mbuf is MCLBYTES:
(kgdb) print ms[0].M_dat.MH.MH_pkthdr.len
$22 = 2048
while the tag has a lower limit:
(kgdb) print ri->ri_data_tag[0].maxsegsz
$21 = 2032
it looks like this is the triggering change:
RCS file: /usr/cvs/src/sys/amd64/amd64/busdma_machdep.c,v
----------------------------
revision 1.81
date: 2007/05/29 06:30:25; author: yongari; state: Exp; lines: +2 -0
Honor maxsegsz of less than a page size in a DMA tag. Previously it
used to return PAGE_SIZE without respect to restrictions of a DMA tag.
This affected all of the busdma load functions that use
_bus_dmamap_loader_buffer() as their back-end.
so the questions are...
Is the above change wrong?
or is the "de" driver buggy?
or should bus_dmamap_load_mbuf handle this somehow?
and does it cause problems other places too?
- Arne H. J.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.64.0706031537040.19155>