malloc(M_WAITOK) of "g_bio", forcing M_NOWAIT with non-sleepable locks held:
Hi, I found this in logs of 6.1 box that I admin this morning. The machine keeps running after that. -- wilx +malloc(M_WAITOK) of "g_bio", forcing M_NOWAIT with the following non-sleepable locks held: +exclusive sleep mutex inp (tcpinp) r = 0 (0xc50c5d38) locked @ /usr/src/sys/netinet/tcp_usrreq.c:1029 +KDB: stack backtrace: +kdb_backtrace(c08eef84,e78be89c,1,c45752c0,c1035380) at kdb_backtrace+0x2f +witness_warn(5,0,c0819ce0,c07fc905,c05eaca1) at witness_warn+0x1ac +uma_zalloc_arg(c1035380,0,102,e78be8e4,c07562a1) at uma_zalloc_arg+0x3d +g_alloc_bio(8,c0819777,c4575400,c45752c0,d367aac8) at g_alloc_bio+0x23 +swapgeom_strategy(d367aac8,c45752c0,c0819777,271) at swapgeom_strategy+0x3a +swp_pager_strategy(d367aac8,0,c0819777,437,c0760ee7) at swp_pager_strategy+0x88 +swap_pager_getpages(c728e948,e78be9ec,1,0,e78be9b0) at swap_pager_getpages+0x382 +vm_fault(c4f9b128,806b000,1,0,c4c0b300) at vm_fault+0xb13 +trap_pfault(e78beaa8,0,806b2c0,c08a9c60,806b2c0) at trap_pfault+0xf4 +trap(c088,28,c4c00028,e78beb28,806b2c0) at trap+0x33e +calltrap() at calltrap+0x5 +--- trap 0xc, eip = 0xc07b9b16, esp = 0xe78beae8, ebp = 0xe78beb08 --- +generic_copyin(e78bec84,e78beb28,4,4,c50c5ca8) at generic_copyin+0x32 +tcp_ctloutput(c4d1dc84,e78bec84,0,c589b400,e78bec68) at tcp_ctloutput+0x182 +sosetopt(c4d1dc84,e78bec84,e78bec80,c08eef80,c4bd15a0) at sosetopt+0x38 +kern_setsockopt(c4c0b300,7,6,1,806b2c0) at kern_setsockopt+0xd6 +setsockopt(c4c0b300,e78bed04,14,28279000,5) at setsockopt+0x3e +syscall(3b,2808003b,bfbf003b,1,806b2c0) at syscall+0x295 +Xint0x80_syscall() at Xint0x80_syscall+0x1f +--- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x2827959b, esp = 0xbf9fea3c, ebp = 0xbf9fea68 --- +Sleeping on "swread" with the following non-sleepable locks held: +exclusive sleep mutex inp (tcpinp) r = 0 (0xc50c5d38) locked @ /usr/src/sys/netinet/tcp_usrreq.c:1029 +KDB: stack backtrace: +kdb_backtrace(c08eef84,e78be8e0,1,1,0) at kdb_backtrace+0x2f +witness_warn(5,c08fe2a0,c0802eb1,c0819833,c08fe2a0) at witness_warn+0x1ac +msleep(c1bb6fe8,c08fe2a0,40,c0819833,4e20) at msleep+0x58 +swap_pager_getpages(c728e948,e78be9ec,1,0,e78be9b0) at swap_pager_getpages+0x400 +vm_fault(c4f9b128,806b000,1,0,c4c0b300) at vm_fault+0xb13 +trap_pfault(e78beaa8,0,806b2c0,c08a9c60,806b2c0) at trap_pfault+0xf4 +trap(c088,28,c4c00028,e78beb28,806b2c0) at trap+0x33e +calltrap() at calltrap+0x5 +--- trap 0xc, eip = 0xc07b9b16, esp = 0xe78beae8, ebp = 0xe78beb08 --- +generic_copyin(e78bec84,e78beb28,4,4,c50c5ca8) at generic_copyin+0x32 +tcp_ctloutput(c4d1dc84,e78bec84,0,c589b400,e78bec68) at tcp_ctloutput+0x182 +sosetopt(c4d1dc84,e78bec84,e78bec80,c08eef80,c4bd15a0) at sosetopt+0x38 +kern_setsockopt(c4c0b300,7,6,1,806b2c0) at kern_setsockopt+0xd6 +setsockopt(c4c0b300,e78bed04,14,28279000,5) at setsockopt+0x3e +syscall(3b,2808003b,bfbf003b,1,806b2c0) at syscall+0x295 +Xint0x80_syscall() at Xint0x80_syscall+0x1f +--- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x2827959b, esp = 0xbf9fea3c, ebp = 0xbf9fea68 --- signature.asc Description: OpenPGP digital signature
Re: 6.2 ETA
It may be a bit early but I switched to RELENG_6 fot that reason. After I switched, it seems the number of interrupts increased a lot. When I do 'dump -0 -f - -L /somewhere | restore -r -f', I see hight interrupt rates which I don't remember seeing in 6.1-RELEASE. Is it too early to report incidents? Hiro On Wed, 30 Aug 2006 07:36:51 -0700 Colin Percival <[EMAIL PROTECTED]> wrote: > Bryan Fullerton wrote: > > So... the releng web page indicates that RELENG_6 is frozen as of > > August 25th pending a 6.2R release on October 9th. > > > > I'm guessing, since there seem to still be lots of commits and there's > > no /releases/6.2R/ doc tree on the FreeBSD site, that these dates are > > no longer accurate. > > > > What is a valid ETA for starting the 6.2R releng process? > > I'm not part of the release engineering team, but I'm not aware of anything > which they're waiting for before starting the freeze. I'd be surprised if > RELENG_6 isn't frozen by this time next week. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Pyun YongHyeon wrote: On Wed, Aug 30, 2006 at 12:52:49PM +0400, Gleb Smirnoff wrote: > On Wed, Aug 30, 2006 at 05:22:23PM +0900, Ganbold wrote: > G> >On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote: > G> >G> Thanks a lot for your patch. Your patch fixes panic, however I still see > G> >G> bge0: firmware handshake timed out > G> >G> bge0: link state changed to DOWN > G> >G> messages. > G> > > G> >And yesterday delphij@ have sent me patch against "firmware handshake > G> >timed out". > G> >It is attached. Can you please test it? > G> > > G> > G> Applied delphij@'s patch and now "bge0: firmware handshake timed out" > G> message is gone. Previously there was applied Pyun's brgphy(4) patch. > > Good. We probably need to commit them both soon. > If there is no objections, I'll commit brgphy(4) patch tomorrow. I can also confirm, that the mentioned panic goes away when the 5752 does not attach to ukphy but brgphy. I had a local patch for this some time now (See current@). I'm happy to test the fix for "firmware handshake timeout" tommorrow. This is on Dell Latitude D620 and a Broadcom 5752 A2. -- Patrick Hurrelmann | "Programming today is a race between software Mannheim, Germany| engineers striving to build bigger and better | idiot-proof programs, and the Universe trying [EMAIL PROTECTED] | to produce bigger and better idiots. So far, www.bytephobia.de| the Universe is winning." - Rich Cook /"\ \ /ASCII Ribbon Campaign X against HTML email & vCards / \ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel trap 12 with interrupts disabled
Just got this panic on my amd64 smp system running stable:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer = 0x8:0x80286611
stack pointer = 0x10:0xb1921b70
frame pointer = 0x10:0x4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 14 (swi4: clock)
trap number = 12
panic: page fault
cpuid = 0
(kgdb) list *0x80286611
0x80286611 is in softclock (/usr/src/sys/kern/kern_timeout.c:220).
215 curticks = softticks;
216 bucket = &callwheel[curticks & callwheelmask];
217 c = TAILQ_FIRST(bucket);
218 while (c) {
219 depth++;
220 if (c->c_time != curticks) {
221 c = TAILQ_NEXT(c, c_links.tqe);
222 ++steps;
223 if (steps >= MAX_SOFTCLOCK_STEPS) {
224 nextsoftcheck = c;
(kgdb) backtrace
#0 doadump () at pcpu.h:172
#1 0x0037 in ?? ()
#2 0x80276e97 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x80277611 in panic (fmt=0xff007ba5ebe0 "\200\026\221{") at
/usr/src/sys/kern/kern_shutdown.c:565
#4 0x80390e5f in trap_fatal (frame=0xff007ba5ebe0,
eva=18446742976271029888)
at /usr/src/sys/amd64/amd64/trap.c:660
#5 0x80391386 in trap (frame=
{tf_rdi = -2141705632, tf_rsi = 10548215, tf_rdx = 16, tf_rcx =
-1619509088, tf_r8 = -1097437156384, tf_r9 = -1619509256, tf_rax = 1, tf_rbx =
1, tf_rbp = 4, tf_r10 = 30689, tf_r11 = -1097437156384, tf_r12 = 16, tf_r13 =
4, tf_r14 = 0, tf_r15 = -2144279856, tf_trapno = 12, tf_addr = 32, tf_flags =
0, tf_err = 0, tf_rip = -2144836079, tf_cs = 8, tf_rflags = 65542, tf_rsp =
-1315824768, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:238
#6 0x8037cd6b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x80286611 in softclock (dummy=0x80582a60) at
/usr/src/sys/kern/kern_timeout.c:220
#8 0x8025d959 in ithread_loop (arg=0xff048680) at
/usr/src/sys/kern/kern_intr.c:682
#9 0x8025c0f7 in fork_exit (callout=0x8025d810 ,
arg=0xff048680,
frame=0xb1921c50) at /usr/src/sys/kern/kern_fork.c:805
#10 0x8037d0ce in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:394
#11 0x in ?? ()
Any hints?
--
Markus
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp/udp performance
On 8/30/06, Danny Braniss <[EMAIL PROTECTED]> wrote: ever since 6.1 I've seen fluctuations in the performance of the em (Intel(R) PRO/1000 Gigabit Ethernet). motherboard OBN (On Board NIC) -- 1- Intel SE7501WV2S Intel 82546EB::2.1 2- Intel SE7320VP2D2INTEL 82541 3- Sun Fire X4100 ServerIntel(R) PRO/1000 test 1: writing to a NetApp filer via NFS/UDP FreeBSD Linux MegaBytes/sec 1- Average: 18.48 32.61 2- Average: 15.69 35.72 3- Average: 16.61 29.69 (interstingly, doing NFS/TCP instead of NFS/UDP shows an increase in speed of around 60% on FreeBSD but none on Linux) test2: iperf using 1 as server: FreeBSD(*) Linux Mbits/sec 1- 926 905 (this machine was busy) 2- 545 798 3- 910 912 *: did a 'sysctl net.inet.tcp.sendspace=65536' So, it seems to me something is not that good in the UDP department, but I can't find what to tweek. Any help? danny Have discussed this some internally, the best idea I've heard is that UDP is not giving us the interrupt rate that TCP would, so we end up not cleaning up as often, and thus descriptors might not be as quickly available.. Its just speculation at this point. Try this: the default is only to have 256 descriptors, try going for the MAX which is 4K. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp/udp performance
Hi, 1) Have you made sure there are no NFS rexmits reported by nfsstat -c ? 2) I haven't run thruput tests lately, but when I tested NFS/UDP thruput a few months ago, I routinely got over 70MB/s sequential read thruput and over 80MB/s sequential write thruput (against filers). I used 32KB blocksizes. -current improves upon this significantly, by about 25%-30%. Send me private e-mail and we can discuss NFS client tunings. mohan --- Danny Braniss <[EMAIL PROTECTED]> wrote: > > ever since 6.1 I've seen fluctuations in the performance of > the em (Intel(R) PRO/1000 Gigabit Ethernet). > > motherboard OBN (On Board NIC) > -- > 1- Intel SE7501WV2S Intel 82546EB::2.1 > 2- Intel SE7320VP2D2INTEL 82541 > 3- Sun Fire X4100 ServerIntel(R) PRO/1000 > > test 1: writing to a NetApp filer via NFS/UDP > FreeBSD Linux > MegaBytes/sec > 1- Average: 18.48 32.61 > 2- Average: 15.69 35.72 > 3- Average: 16.61 29.69 > (interstingly, doing NFS/TCP instead of NFS/UDP shows an increase in speed of > around 60% on FreeBSD but none on Linux) > > test2: iperf using 1 as server: > FreeBSD(*) Linux >Mbits/sec > 1- 926 905 (this machine was busy) > 2- 545 798 > 3- 910 912 > *: did a 'sysctl net.inet.tcp.sendspace=65536' > > > So, it seems to me something is not that good in the UDP department, but > I can't find what to tweek. > > Any help? > > danny > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 ETA
Bryan Fullerton wrote: > So... the releng web page indicates that RELENG_6 is frozen as of > August 25th pending a 6.2R release on October 9th. > > I'm guessing, since there seem to still be lots of commits and there's > no /releases/6.2R/ doc tree on the FreeBSD site, that these dates are > no longer accurate. > > What is a valid ETA for starting the 6.2R releng process? I'm not part of the release engineering team, but I'm not aware of anything which they're waiting for before starting the freeze. I'd be surprised if RELENG_6 isn't frozen by this time next week. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.2 ETA
So... the releng web page indicates that RELENG_6 is frozen as of August 25th pending a 6.2R release on October 9th. I'm guessing, since there seem to still be lots of commits and there's no /releases/6.2R/ doc tree on the FreeBSD site, that these dates are no longer accurate. What is a valid ETA for starting the 6.2R releng process? Thanks, Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 11:50:12AM +0400, Gleb Smirnoff wrote:
> Pyun,
>
> On Wed, Aug 30, 2006 at 04:30:25PM +0900, Pyun YongHyeon wrote:
> P> ===
> P> RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
> P> retrieving revision 1.91.2.16
> P> diff -u -r1.91.2.16 if_bge.c
> P> --- if_bge.c 10 Aug 2006 11:02:14 - 1.91.2.16
> P> +++ if_bge.c 30 Aug 2006 07:20:43 -
> P> @@ -1007,9 +1007,26 @@
> P> /* Set up the PCI DMA control register. */
> P> if (sc->bge_pcie) {
> P> /* PCI Express bus */
> P> - dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
> P> - (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
> P> - (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
> P> + uint32_t device_ctl;
> P> +
> P> + /* alternative from Linux driver */
> P> +#define DMA_CTRL_WRITE_PCIE_H20MARK_128 0x0018
> P> +#define DMA_CTRL_WRITE_PCIE_H20MARK_256 0x0038
> P> +
> P> + dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
> P> + device_ctl = pci_read_config(sc->bge_dev,
> P> + BGE_PCI_CONF_DEV_CTRL, 4);
> P> + if ((device_ctl & 0x00e0) && 0) {
> P> + /*
> P> + * This clause is exactly what the Broadcom-supplied
> P> + * Linux does; but given overall register programming
> P> + * by bge(4), this larger DMA-write watermark
> P> + * value causes BCM5721 chips to totally wedge.
> P> + */
> P> + dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
> P> + } else {
> P> + dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
> P> + }
> P> } else if (sc->bge_pcix) {
>
> My small penny into the discussion. I was working on reviewing the
> difference in initializing the PCI DMA control register in Linux tg3.c
> and in bge(4).
>
> I was quite lost in this stuff, and so I asked for help from David
> Christensen (davidch@). He has explained me all the differencies
> in this register between chips and I have prepared the attached patch.
>
> Since I have very small collection of bge(4) cards, I avoid to commit
> it. May be I will commit it after 6.2-RELEASE if several people test it
> on their cards and all is OK. And it will live unmerged in HEAD until
> 6.3-RELEASE.
>
Ok, I don't have BCM5752 documentation for the details. Since you've
got all the secret of the magic I'd like to see the fix from you. :-)
--
Regards,
Pyun YongHyeon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 12:52:49PM +0400, Gleb Smirnoff wrote: > On Wed, Aug 30, 2006 at 05:22:23PM +0900, Ganbold wrote: > G> >On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote: > G> >G> Thanks a lot for your patch. Your patch fixes panic, however I still > see > G> >G> bge0: firmware handshake timed out > G> >G> bge0: link state changed to DOWN > G> >G> messages. > G> > > G> >And yesterday delphij@ have sent me patch against "firmware handshake > G> >timed out". > G> >It is attached. Can you please test it? > G> > > G> > G> Applied delphij@'s patch and now "bge0: firmware handshake timed out" > G> message is gone. Previously there was applied Pyun's brgphy(4) patch. > > Good. We probably need to commit them both soon. > If there is no objections, I'll commit brgphy(4) patch tomorrow. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp/udp performance
test 1: writing to a NetApp filer via NFS/UDP FreeBSD Linux MegaBytes/sec 1- Average: 18.48 32.61 2- Average: 15.69 35.72 3- Average: 16.61 29.69 (interstingly, doing NFS/TCP instead of NFS/UDP shows an increase in speed of around 60% on FreeBSD but none on Linux) I've always used tcp when doing nfs between my (former) FreeBSD 5.3 fileserver and my FreeBSD 6.x webservers. I increased the read- and write-packetsize to 32768 and achieved the best performance using this packetsize and tcp. Using udp sometimes gave me the "server not responding", but never appeared using tcp. So stick to tcp. regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Gleb Smirnoff wrote:
On Wed, Aug 30, 2006 at 05:26:07PM +0900, Ganbold wrote:
G> Gleb, Pyun,
G>
G> I'm a kind of bit confused here whose patch to choose.
G> Can you guys enlighten me in this regard?
Can you please merge them? You should take all the stuff that
prepares the dma_rw_ctl variable from my patch, and all the other
stuff from Pyun's patch.
Ok, here it is. Let me know if I did something wrong.
It also includes delphij@'s patch. Pyun's brgphy(4) patch is included too.
Ganbold
--- if_bge.c Thu Aug 10 20:02:14 2006
+++ /home/tsgan/bge/new/if_bge.c Wed Aug 30 18:41:39 2006
@@ -1005,36 +1005,48 @@
BGE_MEMWIN_WRITE(sc, i, 0);
/* Set up the PCI DMA control register. */
+ dma_rw_ctl = BGE_PCIDMARWCTL_READ_CMD | BGE_PCIDMARWCTL_WRITE_CMD;
+
+ /* Bits 23, 22. */
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5701 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5714)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE |
+ BGE_PCIDMARWCTL_USE_MRM;
+
+ /* DMA watermarks: bits 21 - 19, 18 - 16. */
if (sc->bge_pcie) {
- /* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ /*
+ * DMA read watermark not used on PCI-E.
+ * DMA write watermark set to 128 bytes.
+ */
+ dma_rw_ctl |= (3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
} else if (sc->bge_pcix) {
- /* PCI-X bus */
- if (BGE_IS_5714_FAMILY(sc)) {
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD;
- dma_rw_ctl &= ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */
- /* XXX magic values, Broadcom-supplied Linux driver */
- if (sc->bge_asicrev == BGE_ASICREV_BCM5780)
-dma_rw_ctl |= (1 << 20) | (1 << 18) |
-BGE_PCIDMARWCTL_ONEDMA_ATONCE;
- else
-dma_rw_ctl |= (1 << 20) | (1 << 18) | (1 << 15);
-
- } else if (sc->bge_asicrev == BGE_ASICREV_BCM5704)
+ switch (sc->bge_asicrev) {
+ case BGE_ASICREV_BCM5780:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 << 20) | (1 << 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+ break;
+ case BGE_ASICREV_BCM5714:
+ case BGE_ASICREV_BCM5714_A0:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 << 20) | (1 << 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE_LOCAL;
+ break;
+ case BGE_ASICREV_BCM5704:
/*
* The 5704 uses a different encoding of read/write
- * watermarks.
+ * watermarks: 384 bytes for write and 1536 for read.
*/
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0x7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
- else
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0x3 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT) |
- (0x0F);
+ dma_rw_ctl |= (7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
+ (3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ break;
+ default:
+ /* All other chips: 384 for write and read. */
+ dma_rw_ctl |= (3 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
+ (3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ }
/*
* 5703 and 5704 need ONEDMA_AT_ONCE as a workaround
@@ -1047,18 +1059,20 @@
tmp = CSR_READ_4(sc, BGE_PCI_CLKCTL) & 0x1f;
if (tmp == 0x6 || tmp == 0x7)
dma_rw_ctl |= BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+
+ /* Set bit 23 to enable PCIX hw bug fix. */
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE;
}
} else
- /* Conventional PCI bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0x7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x7 << BGE_PCIDMARWCTL_WR_WAT_SHIFT) |
- (0x0F);
-
- if (sc->bge_asicrev == BGE_ASICREV_BCM5703 ||
- sc->bge_asicrev == BGE_ASICREV_BCM5704 ||
- sc->bge_asicrev == BGE_ASICREV_BCM5705)
- dma_rw_ctl &= ~BGE_PCIDMARWCTL_MINDMA;
+ /* Conventional PCI bus: 1024 bytes for read and write. */
+ dma_rw_ctl |= (7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
+ (7 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+
+ /* Set minimum DMA only for 5700 and 5701. */
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5701)
+ dma_rw_ctl |= 0xf;
+
pci_write_config(sc->bge_dev, BGE_PCI_DMA_RW_CTL, dma_rw_ctl, 4);
/*
@@ -1148,22 +1162,20 @@
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10);
/* Enable buffer manager */
- if (!(BGE_IS_5705_OR_BEYOND(sc))) {
- CSR_WRITE_4(sc, BGE_BMAN_MODE,
- BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
+ CSR_WRITE_4(sc, BGE_BMAN_MODE,
+ BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
- /* Poll for buffer manager start indication */
- for (i = 0; i < BGE_TIMEOUT; i++) {
- if (CSR_READ_4(sc, BGE_BMAN_MODE) & BGE_BMANMODE_ENABLE)
-break;
- DELAY(10);
- }
+ /* Poll for buffer manager start indication */
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ if (CSR_READ_4(sc, BGE_BMAN_MODE) & BGE_BMANMODE_ENABLE)
+ break;
+ DELAY(10);
+ }
- if (i == BGE_TIMEOUT) {
- device_printf(sc->bge_dev,
- "buffer manager failed to start\n");
- return
tcp/udp performance
ever since 6.1 I've seen fluctuations in the performance of the em (Intel(R) PRO/1000 Gigabit Ethernet). motherboard OBN (On Board NIC) -- 1- Intel SE7501WV2S Intel 82546EB::2.1 2- Intel SE7320VP2D2INTEL 82541 3- Sun Fire X4100 ServerIntel(R) PRO/1000 test 1: writing to a NetApp filer via NFS/UDP FreeBSD Linux MegaBytes/sec 1- Average: 18.48 32.61 2- Average: 15.69 35.72 3- Average: 16.61 29.69 (interstingly, doing NFS/TCP instead of NFS/UDP shows an increase in speed of around 60% on FreeBSD but none on Linux) test2: iperf using 1 as server: FreeBSD(*) Linux Mbits/sec 1- 926 905 (this machine was busy) 2- 545 798 3- 910 912 *: did a 'sysctl net.inet.tcp.sendspace=65536' So, it seems to me something is not that good in the UDP department, but I can't find what to tweek. Any help? danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 05:26:07PM +0900, Ganbold wrote: G> Gleb, Pyun, G> G> I'm a kind of bit confused here whose patch to choose. G> Can you guys enlighten me in this regard? Can you please merge them? You should take all the stuff that prepares the dma_rw_ctl variable from my patch, and all the other stuff from Pyun's patch. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 05:22:23PM +0900, Ganbold wrote: G> >On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote: G> >G> Thanks a lot for your patch. Your patch fixes panic, however I still see G> >G> bge0: firmware handshake timed out G> >G> bge0: link state changed to DOWN G> >G> messages. G> > G> >And yesterday delphij@ have sent me patch against "firmware handshake G> >timed out". G> >It is attached. Can you please test it? G> > G> G> Applied delphij@'s patch and now "bge0: firmware handshake timed out" G> message is gone. Previously there was applied Pyun's brgphy(4) patch. Good. We probably need to commit them both soon. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Gleb, Pyun,
I'm a kind of bit confused here whose patch to choose.
Can you guys enlighten me in this regard?
thanks,
Ganbold
Gleb Smirnoff wrote:
Pyun,
On Wed, Aug 30, 2006 at 04:30:25PM +0900, Pyun YongHyeon wrote:
P> ===
P> RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
P> retrieving revision 1.91.2.16
P> diff -u -r1.91.2.16 if_bge.c
P> --- if_bge.c 10 Aug 2006 11:02:14 - 1.91.2.16
P> +++ if_bge.c 30 Aug 2006 07:20:43 -
P> @@ -1007,9 +1007,26 @@
P> /* Set up the PCI DMA control register. */
P> if (sc->bge_pcie) {
P> /* PCI Express bus */
P> - dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
P> - (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
P> - (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
P> + uint32_t device_ctl;
P> +
P> + /* alternative from Linux driver */
P> +#define DMA_CTRL_WRITE_PCIE_H20MARK_128 0x0018
P> +#define DMA_CTRL_WRITE_PCIE_H20MARK_256 0x0038
P> +
P> + dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
P> + device_ctl = pci_read_config(sc->bge_dev,
P> + BGE_PCI_CONF_DEV_CTRL, 4);
P> + if ((device_ctl & 0x00e0) && 0) {
P> + /*
P> + * This clause is exactly what the Broadcom-supplied
P> + * Linux does; but given overall register programming
P> + * by bge(4), this larger DMA-write watermark
P> + * value causes BCM5721 chips to totally wedge.
P> + */
P> + dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
P> + } else {
P> + dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
P> + }
P> } else if (sc->bge_pcix) {
My small penny into the discussion. I was working on reviewing the
difference in initializing the PCI DMA control register in Linux tg3.c
and in bge(4).
I was quite lost in this stuff, and so I asked for help from David
Christensen (davidch@). He has explained me all the differencies
in this register between chips and I have prepared the attached patch.
Since I have very small collection of bge(4) cards, I avoid to commit
it. May be I will commit it after 6.2-RELEASE if several people test it
on their cards and all is OK. And it will live unmerged in HEAD until
6.3-RELEASE.
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.139
diff -u -p -r1.139 if_bge.c
--- if_bge.c23 Aug 2006 11:32:54 - 1.139
+++ if_bge.c23 Aug 2006 15:18:22 -
@@ -1005,36 +1005,48 @@ bge_chipinit(struct bge_softc *sc)
BGE_MEMWIN_WRITE(sc, i, 0);
/* Set up the PCI DMA control register. */
+ dma_rw_ctl = BGE_PCIDMARWCTL_READ_CMD | BGE_PCIDMARWCTL_WRITE_CMD;
+
+ /* Bits 23, 22. */
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5701 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5714)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE |
+ BGE_PCIDMARWCTL_USE_MRM;
+
+ /* DMA watermarks: bits 21 - 19, 18 - 16. */
if (sc->bge_flags & BGE_FLAG_PCIE) {
- /* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ /*
+* DMA read watermark not used on PCI-E.
+* DMA write watermark set to 128 bytes.
+*/
+ dma_rw_ctl |= (3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
} else if (sc->bge_flags & BGE_FLAG_PCIX) {
- /* PCI-X bus */
- if (BGE_IS_5714_FAMILY(sc)) {
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD;
- dma_rw_ctl &= ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */
- /* XXX magic values, Broadcom-supplied Linux driver */
- if (sc->bge_asicrev == BGE_ASICREV_BCM5780)
-dma_rw_ctl |= (1 << 20) | (1 << 18) |
-BGE_PCIDMARWCTL_ONEDMA_ATONCE;
- else
- dma_rw_ctl |= (1 << 20) | (1 << 18) | (1 << 15);
-
- } else if (sc->bge_asicrev == BGE_ASICREV_BCM5704)
+ switch (sc->bge_asicrev) {
+ case BGE_ASICREV_BCM5780:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 << 20) | (1 << 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+ break;
+ case BGE_ASICREV_BCM5714:
+ case BGE_ASICREV_BCM5714_A0:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 << 20) | (1 << 18) |
+
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Gleb, Pyun,
Gleb Smirnoff wrote:
Ganbold,
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
G> Thanks a lot for your patch. Your patch fixes panic, however I still see
G> bge0: firmware handshake timed out
G> bge0: link state changed to DOWN
G> messages.
And yesterday delphij@ have sent me patch against "firmware handshake timed
out".
It is attached. Can you please test it?
Applied delphij@'s patch and now "bge0: firmware handshake timed out"
message is gone. Previously there was applied Pyun's brgphy(4) patch.
Ganbold
Subject:
[PATCH FOR REVIEW] Broadcom BCM 5752 A02 "firmware handshake timeout"
From:
LI Xin <[EMAIL PROTECTED]>
Date:
Tue, 29 Aug 2006 14:39:31 +0800
To:
[EMAIL PROTECTED], [EMAIL PROTECTED]
To:
[EMAIL PROTECTED], [EMAIL PROTECTED]
Hi,
A colleague of mine has found that BCM 5752 A02 would get "firmware
handshake timeout" problem during the ifconfig stage. After some
investigation and comparing to the Linux driver I have the attached
patch make the problem disappear. Unfortunately I do not have
specification documentation from Broadcom so I can not say if that is a
"real fix" :-(
The patch was tested on Dell Latitude D820. The only problem remains is
that the -CURRENT kernel crashes if I did not explicitly set the media
and do a "ifconfig bge0 up", with "panic: invalid ife->ifm_data (0xa) in
mii_phy_setmedia". Backtrace is available upon request.
Cheers,
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.140
diff -u -r1.140 if_bge.c
--- if_bge.c24 Aug 2006 14:41:16 - 1.140
+++ if_bge.c29 Aug 2006 06:20:44 -
@@ -2313,6 +2313,13 @@
BGE_PCIMISCCTL_INDIRECT_ACCESS|BGE_PCIMISCCTL_MASK_PCI_INTR|
BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_PCISTATE_RW, 4);
+ /* XXX: Broadcom Linux driver. */
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5752 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5755 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5787) {
+ CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0);
+ }
+
reset = BGE_MISCCFG_RESET_CORE_CLOCKS|(65<<1);
/* XXX: Broadcom Linux driver. */
Index: if_bgereg.h
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.52
diff -u -r1.52 if_bgereg.h
--- if_bgereg.h 23 Aug 2006 11:32:54 - 1.52
+++ if_bgereg.h 29 Aug 2006 06:32:31 -
@@ -1656,6 +1656,7 @@
#define BGE_EE_CTL 0x6840
#define BGE_MDI_CTL0x6844
#define BGE_EE_DELAY 0x6848
+#define BGE_FASTBOOT_PC0x6894
/* Mode control register */
#define BGE_MODECTL_INT_SNDCOAL_ONLY 0x0001
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Ganbold,
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
G> Thanks a lot for your patch. Your patch fixes panic, however I still see
G> bge0: firmware handshake timed out
G> bge0: link state changed to DOWN
G> messages.
And yesterday delphij@ have sent me patch against "firmware handshake timed
out".
It is attached. Can you please test it?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
--- Begin Message ---
Hi,
A colleague of mine has found that BCM 5752 A02 would get "firmware
handshake timeout" problem during the ifconfig stage. After some
investigation and comparing to the Linux driver I have the attached
patch make the problem disappear. Unfortunately I do not have
specification documentation from Broadcom so I can not say if that is a
"real fix" :-(
The patch was tested on Dell Latitude D820. The only problem remains is
that the -CURRENT kernel crashes if I did not explicitly set the media
and do a "ifconfig bge0 up", with "panic: invalid ife->ifm_data (0xa) in
mii_phy_setmedia". Backtrace is available upon request.
Cheers,
--
Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/
FreeBSD - The Power to Serve!
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.140
diff -u -r1.140 if_bge.c
--- if_bge.c24 Aug 2006 14:41:16 - 1.140
+++ if_bge.c29 Aug 2006 06:20:44 -
@@ -2313,6 +2313,13 @@
BGE_PCIMISCCTL_INDIRECT_ACCESS|BGE_PCIMISCCTL_MASK_PCI_INTR|
BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_PCISTATE_RW, 4);
+ /* XXX: Broadcom Linux driver. */
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5752 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5755 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5787) {
+ CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0);
+ }
+
reset = BGE_MISCCFG_RESET_CORE_CLOCKS|(65<<1);
/* XXX: Broadcom Linux driver. */
Index: if_bgereg.h
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.52
diff -u -r1.52 if_bgereg.h
--- if_bgereg.h 23 Aug 2006 11:32:54 - 1.52
+++ if_bgereg.h 29 Aug 2006 06:32:31 -
@@ -1656,6 +1656,7 @@
#define BGE_EE_CTL 0x6840
#define BGE_MDI_CTL0x6844
#define BGE_EE_DELAY 0x6848
+#define BGE_FASTBOOT_PC0x6894
/* Mode control register */
#define BGE_MODECTL_INT_SNDCOAL_ONLY 0x0001
signature.asc
Description: OpenPGP digital signature
--- End Message ---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Pyun,
On Wed, Aug 30, 2006 at 04:30:25PM +0900, Pyun YongHyeon wrote:
P> ===
P> RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
P> retrieving revision 1.91.2.16
P> diff -u -r1.91.2.16 if_bge.c
P> --- if_bge.c 10 Aug 2006 11:02:14 - 1.91.2.16
P> +++ if_bge.c 30 Aug 2006 07:20:43 -
P> @@ -1007,9 +1007,26 @@
P> /* Set up the PCI DMA control register. */
P> if (sc->bge_pcie) {
P> /* PCI Express bus */
P> -dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
P> -(0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
P> -(0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
P> +uint32_t device_ctl;
P> +
P> +/* alternative from Linux driver */
P> +#define DMA_CTRL_WRITE_PCIE_H20MARK_128 0x0018
P> +#define DMA_CTRL_WRITE_PCIE_H20MARK_256 0x0038
P> +
P> +dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
P> +device_ctl = pci_read_config(sc->bge_dev,
P> +BGE_PCI_CONF_DEV_CTRL, 4);
P> +if ((device_ctl & 0x00e0) && 0) {
P> +/*
P> + * This clause is exactly what the Broadcom-supplied
P> + * Linux does; but given overall register programming
P> + * by bge(4), this larger DMA-write watermark
P> + * value causes BCM5721 chips to totally wedge.
P> + */
P> +dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
P> +} else {
P> +dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
P> +}
P> } else if (sc->bge_pcix) {
My small penny into the discussion. I was working on reviewing the
difference in initializing the PCI DMA control register in Linux tg3.c
and in bge(4).
I was quite lost in this stuff, and so I asked for help from David
Christensen (davidch@). He has explained me all the differencies
in this register between chips and I have prepared the attached patch.
Since I have very small collection of bge(4) cards, I avoid to commit
it. May be I will commit it after 6.2-RELEASE if several people test it
on their cards and all is OK. And it will live unmerged in HEAD until
6.3-RELEASE.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.139
diff -u -p -r1.139 if_bge.c
--- if_bge.c23 Aug 2006 11:32:54 - 1.139
+++ if_bge.c23 Aug 2006 15:18:22 -
@@ -1005,36 +1005,48 @@ bge_chipinit(struct bge_softc *sc)
BGE_MEMWIN_WRITE(sc, i, 0);
/* Set up the PCI DMA control register. */
+ dma_rw_ctl = BGE_PCIDMARWCTL_READ_CMD | BGE_PCIDMARWCTL_WRITE_CMD;
+
+ /* Bits 23, 22. */
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5701 ||
+ sc->bge_asicrev == BGE_ASICREV_BCM5714)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE |
+ BGE_PCIDMARWCTL_USE_MRM;
+
+ /* DMA watermarks: bits 21 - 19, 18 - 16. */
if (sc->bge_flags & BGE_FLAG_PCIE) {
- /* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ /*
+* DMA read watermark not used on PCI-E.
+* DMA write watermark set to 128 bytes.
+*/
+ dma_rw_ctl |= (3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
} else if (sc->bge_flags & BGE_FLAG_PCIX) {
- /* PCI-X bus */
- if (BGE_IS_5714_FAMILY(sc)) {
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD;
- dma_rw_ctl &= ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */
- /* XXX magic values, Broadcom-supplied Linux driver */
- if (sc->bge_asicrev == BGE_ASICREV_BCM5780)
- dma_rw_ctl |= (1 << 20) | (1 << 18) |
- BGE_PCIDMARWCTL_ONEDMA_ATONCE;
- else
- dma_rw_ctl |= (1 << 20) | (1 << 18) | (1 << 15);
-
- } else if (sc->bge_asicrev == BGE_ASICREV_BCM5704)
+ switch (sc->bge_asicrev) {
+ case BGE_ASICREV_BCM5780:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 << 20) | (1 << 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+ break;
+ case BGE_ASICREV_BCM5714:
+ case BGE_ASICREV_BCM5714_A0:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 << 20) | (1 << 18) |
+ BG
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Pyun YongHyeon wrote:
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
> Hi,
>
> Thanks a lot for your patch. Your patch fixes panic, however I still see
> bge0: firmware handshake timed out
> bge0: link state changed to DOWN
> messages.
>
> When I tried to use Oleg's if_bge.c, rev. 1.140 in STABLE buildkernel stops:
>
> mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I-
> -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include
> -I/usr/include -I/usr/obj/usr/src/sys/DEVIL
> /usr/src/sys/modules/bge/../../dev/bge/if_bge.c
> /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2570:35: macro
> "VLAN_INPUT_TAG" requires 4 arguments, but only 3 given
> mkdep: compile failed
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> mkdep: compile failed
> *** Error code 1
> 2 errors
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
>
> I see VLAN_INPUT_TAG is defined as VLAN_INPUT_TAG(_ifp, _m, _t,
> _errcase) in if_vlan_var.h, rev v 1.21.2.2 with 4 arguments, however
> new if_bge.c, rev. 1.140 uses 3 arguments.
> Is it safe to use if_vlan_var.h, rev 1.24 and if_vlan.c, rev 1.114 only?
> What other patches should I use?
> When all these changes MFC to STABLE?
>
You should use VLAN_INPUT_TAG_NEW macro in RELENG_6.
Anyway, here is guess work for BCM5752(obtained from OpenBSD).
Because I don't have 5752 hardware I don't know whether it works or
not. The patch is for RELENG_6(You need brgphy(4) patch too).
Where can I get brgphy(4) patch for RELENG_6?
thanks,
Ganbold
> thanks,
>
> Ganbold
>
> Pyun YongHyeon wrote:
> >I think your PHY was not recognized by brgphy(4). But I don't know it
> >fixes "firmware handshake timed out" issue you've seen.
> >Recently oleg fixed a long standing bug in bge(4). So you may also want
> >to merge the change.(See if_bge.c, rev. 1.140)
> >Patch generated against RELENG_6(compile tested only).
> >
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.16
diff -u -r1.91.2.16 if_bge.c
--- if_bge.c10 Aug 2006 11:02:14 - 1.91.2.16
+++ if_bge.c30 Aug 2006 07:20:43 -
@@ -1007,9 +1007,26 @@
/* Set up the PCI DMA control register. */
if (sc->bge_pcie) {
/* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ uint32_t device_ctl;
+
+ /* alternative from Linux driver */
+#define DMA_CTRL_WRITE_PCIE_H20MARK_1280x0018
+#define DMA_CTRL_WRITE_PCIE_H20MARK_2560x0038
+
+ dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
+ device_ctl = pci_read_config(sc->bge_dev,
+ BGE_PCI_CONF_DEV_CTRL, 4);
+ if ((device_ctl & 0x00e0) && 0) {
+ /*
+* This clause is exactly what the Broadcom-supplied
+* Linux does; but given overall register programming
+* by bge(4), this larger DMA-write watermark
+* value causes BCM5721 chips to totally wedge.
+*/
+ dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
+ } else {
+ dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
+ }
} else if (sc->bge_pcix) {
/* PCI-X bus */
if (BGE_IS_5714_FAMILY(sc)) {
@@ -1148,22 +1165,20 @@
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10);
/* Enable buffer manager */
- if (!(BGE_IS_5705_OR_BEYOND(sc))) {
- CSR_WRITE_4(sc, BGE_BMAN_MODE,
- BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
+ CSR_WRITE_4(sc, BGE_BMAN_MODE,
+ BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
- /* Poll for buffer manager start indication */
- for (i = 0; i < BGE_TIMEOUT; i++) {
- if (CSR_READ_4(sc, BGE_BMAN_MODE) & BGE_BMANMODE_ENABLE)
- break;
- DELAY(10);
- }
+ /* Poll for buffer manager start indication */
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ if (CSR_READ_4(sc, BGE_BMAN_MODE) & BGE_BMANMODE_ENABLE)
+ break;
+ DELAY(10);
+ }
- if (i == BGE_TIMEOUT) {
- device_printf(sc->bge_dev,
- "buffer manager failed to start\n");
- return (ENXIO);
- }
+ if (i == BGE_TIMEOUT) {
+ device_printf(sc->bge_dev,
+ "buffer manager failed
Re: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
> Hi,
>
> Thanks a lot for your patch. Your patch fixes panic, however I still see
> bge0: firmware handshake timed out
> bge0: link state changed to DOWN
> messages.
>
> When I tried to use Oleg's if_bge.c, rev. 1.140 in STABLE buildkernel stops:
>
> mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I-
> -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include
> -I/usr/include -I/usr/obj/usr/src/sys/DEVIL
> /usr/src/sys/modules/bge/../../dev/bge/if_bge.c
> /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2570:35: macro
> "VLAN_INPUT_TAG" requires 4 arguments, but only 3 given
> mkdep: compile failed
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> mkdep: compile failed
> *** Error code 1
> 2 errors
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
>
> I see VLAN_INPUT_TAG is defined as VLAN_INPUT_TAG(_ifp, _m, _t,
> _errcase) in if_vlan_var.h, rev v 1.21.2.2 with 4 arguments, however
> new if_bge.c, rev. 1.140 uses 3 arguments.
> Is it safe to use if_vlan_var.h, rev 1.24 and if_vlan.c, rev 1.114 only?
> What other patches should I use?
> When all these changes MFC to STABLE?
>
You should use VLAN_INPUT_TAG_NEW macro in RELENG_6.
Anyway, here is guess work for BCM5752(obtained from OpenBSD).
Because I don't have 5752 hardware I don't know whether it works or
not. The patch is for RELENG_6(You need brgphy(4) patch too).
> thanks,
>
> Ganbold
>
> Pyun YongHyeon wrote:
> >I think your PHY was not recognized by brgphy(4). But I don't know it
> >fixes "firmware handshake timed out" issue you've seen.
> >Recently oleg fixed a long standing bug in bge(4). So you may also want
> >to merge the change.(See if_bge.c, rev. 1.140)
> >Patch generated against RELENG_6(compile tested only).
> >
--
Regards,
Pyun YongHyeon
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.16
diff -u -r1.91.2.16 if_bge.c
--- if_bge.c10 Aug 2006 11:02:14 - 1.91.2.16
+++ if_bge.c30 Aug 2006 07:20:43 -
@@ -1007,9 +1007,26 @@
/* Set up the PCI DMA control register. */
if (sc->bge_pcie) {
/* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ uint32_t device_ctl;
+
+ /* alternative from Linux driver */
+#define DMA_CTRL_WRITE_PCIE_H20MARK_1280x0018
+#define DMA_CTRL_WRITE_PCIE_H20MARK_2560x0038
+
+ dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
+ device_ctl = pci_read_config(sc->bge_dev,
+ BGE_PCI_CONF_DEV_CTRL, 4);
+ if ((device_ctl & 0x00e0) && 0) {
+ /*
+* This clause is exactly what the Broadcom-supplied
+* Linux does; but given overall register programming
+* by bge(4), this larger DMA-write watermark
+* value causes BCM5721 chips to totally wedge.
+*/
+ dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
+ } else {
+ dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
+ }
} else if (sc->bge_pcix) {
/* PCI-X bus */
if (BGE_IS_5714_FAMILY(sc)) {
@@ -1148,22 +1165,20 @@
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10);
/* Enable buffer manager */
- if (!(BGE_IS_5705_OR_BEYOND(sc))) {
- CSR_WRITE_4(sc, BGE_BMAN_MODE,
- BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
+ CSR_WRITE_4(sc, BGE_BMAN_MODE,
+ BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
- /* Poll for buffer manager start indication */
- for (i = 0; i < BGE_TIMEOUT; i++) {
- if (CSR_READ_4(sc, BGE_BMAN_MODE) & BGE_BMANMODE_ENABLE)
- break;
- DELAY(10);
- }
+ /* Poll for buffer manager start indication */
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ if (CSR_READ_4(sc, BGE_BMAN_MODE) & BGE_BMANMODE_ENABLE)
+ break;
+ DELAY(10);
+ }
- if (i == BGE_TIMEOUT) {
- device_printf(sc->bge_dev,
- "buffer manager failed to start\n");
- return (ENXIO);
- }
+ if (i == BGE_TIMEOUT) {
+ device_printf(sc->bge_dev,
+ "buffer manager failed to start\n");
+ return (ENXIO);
}
/* Enable flow-through queues */
Index: if_bgereg.h
===
