Re: [POLLING] strange interrupt/system load
--- On Sat, 9/12/09, rihad wrote: > From: rihad > Subject: [POLLING] strange interrupt/system load > To: freebsd-net@freebsd.org > Date: Saturday, September 12, 2009, 3:27 AM > The box experiences ~230 mbit/s > traffic flow through it. I've doubled some sysctls after > reading polling(4): > kern.polling.each_burst=10 # was: 5 > kern.polling.burst_max=350 # was: 150 > > FreeBSD 7.2-RELEASE-p3 amd64 > HZ=1000 > > Now for the fun part. > > With kern.polling.idle_poll = 1 top shows: > CPU: 0.0% user, 0.0% nice, 26.9% system, > 3.1% interrupt, 70.0% idle > ~8000 interrupts/s total according to systat -vmstat: > 1999 cpu0: time > 2000 cpu1: time > 1999 cpu2: time > 1999 cpu3: time > > With kern.polling.idle_poll = 0 top shows: > CPU: 0.0% user, 0.0% nice, 0.0% system, > 13.9% interrupt, 86.0% idle > Still the same ~8000 clock interrupts/s. > > Under both scenarios polling is enabled on both em0 and em1 > through ifconfig. > > > 1) Why is the interrupt load relatively high with polling > enabled? > 2) How come 13.9% interrupts are not also in the first > scenario if their total rate is the same (~8000)? > > Thanks. The more important questions are: 1) Why are you polling with a NIC that can be precisely set to interrupt as often or as little as you like? 2) Why do so many people run systems with high network load with AMD64 builds when its significantly slower to do so? Do you have google sized databases so you need 64-bit pointers? As to why you get interrupt load, how do you think that polling is implemented? By Magic? You are merely shifting the interrupt load from the em driver to the software interrupts. Running em drivers with AIM is essentially the same as polling without the associated system overhead that polling introduces. Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em driver input errors
--- On Fri, 9/11/09, Jack Vogel wrote: > From: Jack Vogel > Subject: Re: em driver input errors > To: "Mike Tancsa" > Cc: "Barney Cordoba" , freebsd-net@freebsd.org > Date: Friday, September 11, 2009, 12:38 PM > Glad to hear this. > > Jack > > > On Fri, Sep 11, 2009 at 4:46 AM, > Mike Tancsa > wrote: > > At 11:28 AM 9/9/2009, Mike Tancsa wrote: > > > At 11:17 AM 9/9/2009, Mike Tancsa wrote: > > > The board is an intel > > > > http://www.intel.com/support/motherboards/server/s3000ah/ > > > > Not sure if its wired as PCI-X or just a 32bit bus. I am > just popping in an em pcie nic to see if that makes a > difference. I have an igb as well as bge I can try later. > > > > > OK, now there is > > > > e...@pci0:5:0:0: class=0x02 card=0xa01f8086 > chip=0x10d38086 rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current > D0 > > cap 05[d0] = MSI supports 1 message, 64 bit > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) > link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > enabled > > > > > > > > > > > OK, much better. Two nights in a row without errors, and > Friday AM has a lot of level0 dumps. Perhaps as you > speculated, the onboard NICs were wired to a slower bus... > The pcie 1x hasnt shown any errors yet. > > > > Sep 11 00:01:00 backup3 kernel: em0: Excessive collisions = > 0 > > Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Receive No Buffers = > 0 > > Sep 11 00:01:00 backup3 kernel: em0: Receive Length Errors > = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Receive errors = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Alignment errors = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Collision/Carrier > extension errors = 0 > > Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0 > > Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts = 0 > > Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = 50004846 > TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1 > > Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0 > > Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0 > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0 > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0 > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd = > 73064815 > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd = > 52479296 > > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd = 0 > > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Failed = > 0 > > > > > > Name Mtu Network Address > Ipkts Ierrs Opkts Oerrs Coll > > em0 1500 00:1b:21:3f:62:72 > 193269942 0 133269168 0 0 > > em0 1500 10.45.129.132 10.45.129.133 > 0 - 0 - - > > em1 1500 00:15:17:57:31:8a > 0 0 0 0 0 > > em1 1500 10.45.129.128 10.45.129.129 > 0 - 0 - - > > em2* 1500 00:15:17:57:31:8b > 0 0 0 0 > 0 > > > > ---Mike > Intel really shouldn't let MB manufacturers market dual gigabit systems with 32bit controllers. The NICs aren't intended to be used that way, and it makes them look bad, when its really the fault of the MB manufacturer for cheaping out on the design. Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em driver input errors
--- On Sun, 9/13/09, Barney Cordoba wrote: > From: Barney Cordoba > Subject: Re: em driver input errors > To: "Mike Tancsa" , "Jack Vogel" > Cc: freebsd-net@freebsd.org > Date: Sunday, September 13, 2009, 8:30 AM > > > --- On Fri, 9/11/09, Jack Vogel > wrote: > > > From: Jack Vogel > > Subject: Re: em driver input errors > > To: "Mike Tancsa" > > Cc: "Barney Cordoba" , > freebsd-net@freebsd.org > > Date: Friday, September 11, 2009, 12:38 PM > > Glad to hear this. > > > > Jack > > > > > > On Fri, Sep 11, 2009 at 4:46 AM, > > Mike Tancsa > > wrote: > > > > At 11:28 AM 9/9/2009, Mike Tancsa wrote: > > > > > > At 11:17 AM 9/9/2009, Mike Tancsa wrote: > > > > > > The board is an intel > > > > > > > > http://www.intel.com/support/motherboards/server/s3000ah/ > > > > > > > > Not sure if its wired as PCI-X or just a 32bit bus. > I am > > just popping in an em pcie nic to see if that makes a > > difference. I have an igb as well as bge I can try > later. > > > > > > > > > > OK, now there is > > > > > > > > e...@pci0:5:0:0: class=0x02 card=0xa01f8086 > > chip=0x10d38086 rev=0x00 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > class = network > > > > subclass = ethernet > > > > cap 01[c8] = powerspec 2 supports D0 D3 > current > > D0 > > > > cap 05[d0] = MSI supports 1 message, 64 > bit > > > > cap 10[e0] = PCI-Express 1 endpoint max > data 128(256) > > link x1(x1) > > > > cap 11[a0] = MSI-X supports 5 messages in > map 0x1c > > enabled > > > > > > > > > > > > > > > > > > > > > > OK, much better. Two nights in a row without errors, > and > > Friday AM has a lot of level0 dumps. Perhaps as you > > speculated, the onboard NICs were wired to a slower > bus... > > The pcie 1x hasnt shown any errors yet. > > > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Excessive > collisions = > > 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = > 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = > 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Receive No > Buffers = > > 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Receive Length > Errors > > = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Receive errors = > 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Alignment errors > = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: > Collision/Carrier > > extension errors = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts > = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = > 50004846 > > TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1 > > > > Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd > = > > 73064815 > > > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd > = > > 52479296 > > > > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd > = 0 > > > > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts > Failed = > > 0 > > > > > > > > > > > > Name Mtu Network Address > > > Ipkts Ierrs Opkts Oerrs Coll > > > > em0 1500 > 00:1b:21:3f:62:72 > > 193269942 0 133269168 0 0 > > > > em0 1500 10.45.129.132 10.45.129.133 > > > 0 - 0 - - > > > > em1 1500 00:15:17:57:31:8a > > > 0 0 0 0 0 > > > > em1 1500 10.45.129.128 10.45.129.129 > > > 0 - 0 - - > > > > em2* 1500 00:15:17:57:31:8b > > > 0 0 0 0 > > 0 > > > > > > > > ---Mike > > > > Intel really shouldn't let MB manufacturers market dual > gigabit > systems with 32bit controllers. The NICs aren't intended to > be > used that way, and it makes them look bad, when its really > the fault > of the MB manufacturer for cheaping out on the design. > > Barney > I take that back. I see now that Intel is the MB manufacturer, which is really outrageous and irresponsible. Jack, feel free to pass that on. Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em driver input errors
--- On Sun, 9/13/09, Barney Cordoba wrote: > From: Barney Cordoba > Subject: Re: em driver input errors > To: "Mike Tancsa" , "Jack Vogel" > Cc: freebsd-net@freebsd.org > Date: Sunday, September 13, 2009, 8:40 AM > > > --- On Sun, 9/13/09, Barney Cordoba > wrote: > > > From: Barney Cordoba > > Subject: Re: em driver input errors > > To: "Mike Tancsa" , > "Jack Vogel" > > Cc: freebsd-net@freebsd.org > > Date: Sunday, September 13, 2009, 8:30 AM > > > > > > --- On Fri, 9/11/09, Jack Vogel > > wrote: > > > > > From: Jack Vogel > > > Subject: Re: em driver input errors > > > To: "Mike Tancsa" > > > Cc: "Barney Cordoba" , > > freebsd-net@freebsd.org > > > Date: Friday, September 11, 2009, 12:38 PM > > > Glad to hear this. > > > > > > Jack > > > > > > > > > On Fri, Sep 11, 2009 at 4:46 AM, > > > Mike Tancsa > > > wrote: > > > > > > At 11:28 AM 9/9/2009, Mike Tancsa wrote: > > > > > > > > > At 11:17 AM 9/9/2009, Mike Tancsa wrote: > > > > > > > > > The board is an intel > > > > > > > > > > > > http://www.intel..com/support/motherboards/server/s3000ah/ > > > > > > > > > > > > Not sure if its wired as PCI-X or just a 32bit > bus. > > I am > > > just popping in an em pcie nic to see if that > makes a > > > difference. I have an igb as well as bge I can > try > > later. > > > > > > > > > > > > > > > OK, now there is > > > > > > > > > > > > e...@pci0:5:0:0: class=0x02 card=0xa01f8086 > > > chip=0x10d38086 rev=0x00 hdr=0x00 > > > > > > vendor = 'Intel Corporation' > > > > > > class = network > > > > > > subclass = ethernet > > > > > > cap 01[c8] = powerspec 2 supports D0 D3 > > current > > > D0 > > > > > > cap 05[d0] = MSI supports 1 message, 64 > > bit > > > > > > cap 10[e0] = PCI-Express 1 endpoint max > > data 128(256) > > > link x1(x1) > > > > > > cap 11[a0] = MSI-X supports 5 messages in > > map 0x1c > > > enabled > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > OK, much better. Two nights in a row without > errors, > > and > > > Friday AM has a lot of level0 dumps. Perhaps as > you > > > speculated, the onboard NICs were wired to a > slower > > bus... > > > The pcie 1x hasnt shown any errors yet. > > > > > > > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Excessive > > collisions = > > > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Sequence > errors = > > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Defer count > = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Missed > Packets = > > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Receive No > > Buffers = > > > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Receive > Length > > Errors > > > = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Receive > errors = > > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Crc errors = > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Alignment > errors > > = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: > > Collision/Carrier > > > extension errors = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: RX overruns > = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: watchdog > timeouts > > = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ > = > > 50004846 > > > TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = > 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets > Rcvd > > = > > > 73064815 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets > Xmtd > > = > > > 52479296 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts > Xmtd > > = 0 > > > > > > Sep 11 00:01:00 backup3 kernel: em0: TSO > Contexts > > Failed = > > > 0 > > > > > > > > > > > > > > > > > > Name Mtu Network Address > > > > > > Ipkts Ierrs Opkts Oerrs Coll > > > > > > em0 1500 > > 00:1b:21:3f:62:72 > > > 193269942 0 133269168 0 0 > > > > > > em0 1500 10.45.129.132 10.45.129.133 > > > > > > 0 - 0 - - > > > > > > em1 1500 > 00:15:17:57:31:8a > > > > > 0 0 0 0 0 > > > > > > em1 1500 10.45.129.128 10.45.129.129 > > > > > > 0 - 0 - - > > > > > > em2* 1500 > 00:15:17:57:31:8b > > > > > 0 0 0 0 > > > 0 > > > > > > > > > > > > ---Mike > > > > > > > Intel really shouldn't let MB manufacturers market > dual > > gigabit > > systems with 32bit controllers. The NICs aren't > intended to > > be > > used that way, and it makes them look bad, when its > really > > the fault > > of the MB manufacturer for cheaping out on the > design. > > > > Barney > > > > I take that back. I see now that Intel is the MB > m
Re: [POLLING] strange interrupt/system load
Barney Cordoba wrote: 1) Why are you polling with a NIC that can be precisely set to interrupt as often or as little as you like? How? 2) Why do so many people run systems with high network load with AMD64 builds when its significantly slower to do so? Do you have google sized databases so you need 64-bit pointers? What's wrong with 64 bits? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [POLLING] strange interrupt/system load
--- On Sun, 9/13/09, rihad wrote: > From: rihad > Subject: Re: [POLLING] strange interrupt/system load > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Sunday, September 13, 2009, 9:11 AM > Barney Cordoba wrote: > > > 1) Why are you polling with a NIC that can be > precisely set to > > interrupt as often or as little as you like? > How? > > > 2) Why do so many people run systems with high network > load with > > AMD64 builds when its significantly slower to do so? > Do you have > > google sized databases so you need 64-bit pointers? > What's wrong with 64 bits? I haven't spent a large portion of my life trying to figure it out exactly, but I'd guess that the larger size of the structures and code results in fewer cache hits. It certainly makes sense to try both with your workload, as the notion that 64bits must be faster than 32bits is patently misguided. My rule of thumb is that if I don't need 64bits for something, I avoid it. Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [POLLING] strange interrupt/system load
Barney Cordoba wrote: --- On Sun, 9/13/09, rihad wrote: What's wrong with 64 bits? I haven't spent a large portion of my life trying to figure it out exactly, but I'd guess that the larger size of the structures and code results in fewer cache hits. Then what's wrong with also doubling cache sizes? Besides, apart from other benefits, 64-bit makes every-day big number arithmetic a single CPU instruction as opposed to several instructions required on 32-bit CPUs through bignum emulation. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [POLLING] strange interrupt/system load
On Sun, Sep 13, 2009 at 07:33:06PM +0500, rihad wrote: > Barney Cordoba wrote: > > > > --- On Sun, 9/13/09, rihad wrote: > >> What's wrong with 64 bits? > > > > I haven't spent a large portion of my life trying to figure > > it out exactly, but I'd guess that the larger size of the > > structures and code results in fewer cache hits. > > Then what's wrong with also doubling cache sizes? Increasing the size of the CPU cache not only makes it more expensive to manufacture, but also makes it slightly slower to access. > Besides, apart from other benefits, 64-bit makes every-day big number > arithmetic a single CPU instruction as opposed to several instructions > required on 32-bit CPUs through bignum emulation. True, and if you need to perform a lot of 64-bit arithmetic then the extra register width can indeed be a major win. Most people, on most systems, have very limited need of 64-bit arithmetic. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: host(1) coredumps
On 09/13/09 06:27, Eugene Grosbein wrote:
> Hi!
>
> For 8.0-BETA3:
>
> % host -l grosbein.pp.ru. ns2.rucable.net.
> ; Transfer failed.
> /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
> REQUIREsock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic
> == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')) failed.
> zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net.
>
> Shoud I send PR?
>
> Eugene Grosbein
Eugene,
the attached patch works around the error for me. As this is contributed
code, it should be fixed upstream (no need to file a PR).
Volker
--- contrib/bind9/bin/dig/dighost.c.orig2009-09-13 14:24:13.0
+
+++ contrib/bind9/bin/dig/dighost.c 2009-09-13 14:31:52.0 +
@@ -2604,11 +2604,13 @@
if (sevent->result == ISC_R_CANCELED) {
debug("in cancel handler");
- isc_socket_detach(&query->sock);
- sockcount--;
- INSIST(sockcount >= 0);
- debug("sockcount=%d", sockcount);
- query->waiting_connect = ISC_FALSE;
+ if (query->sock != NULL) {
+ isc_socket_detach(&query->sock);
+ sockcount--;
+ INSIST(sockcount >= 0);
+ debug("sockcount=%d", sockcount);
+ query->waiting_connect = ISC_FALSE;
+ }
isc_event_free(&event);
l = query->lookup;
clear_query(query);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: host(1) coredumps
On Sun, Sep 13, 2009 at 05:41:50PM +0200, vol...@vwsoft.com wrote:
> > % host -l grosbein.pp.ru. ns2.rucable.net.
> > ; Transfer failed.
> > /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
> > REQUIREsock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic
> > == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')) failed.
> > zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net.
> >
> > Shoud I send PR?
> Eugene,
>
> the attached patch works around the error for me. As this is contributed
> code, it should be fixed upstream (no need to file a PR).
>
> Volker
>
> --- contrib/bind9/bin/dig/dighost.c.orig 2009-09-13 14:24:13.0
> +
> +++ contrib/bind9/bin/dig/dighost.c 2009-09-13 14:31:52.0 +
Indeed, the patch helps. Thank you.
Eugene
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304
Old Synopsis: [panic] sbflush_internal New Synopsis: [panic] sbflush_internal: cc 0 || mb 0xff004127b000 || mbcnt 2304 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Sep 13 20:41:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). Not sure if there's enough info here at the moment, but the submitter has a core. To submitter: Can you run crashinfo(8) on the kernel core file and provide the complete output please? http://www.freebsd.org/cgi/query-pr.cgi?pr=138782 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
