Re: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon [EMAIL PROTECTED] wrote: FYI: Fix committed to HEAD. This happened nearly three weeks ago. When might this fix get into 6-STABLE? I have also problems on my system which might be related to the sk-trouble, so this fix might also help me. Or should I try to compile the new driver on my system (running 6-STABLE)? Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Sun, Jun 04, 2006 at 12:41:12PM +0200, Michael Gerhards wrote: Pyun YongHyeon [EMAIL PROTECTED] wrote: FYI: Fix committed to HEAD. This happened nearly three weeks ago. When might this fix get into 6-STABLE? Unfortunately sk(4) in HEAD has a known issue and I'm working on it. Since I couldn't reproduce the issue on my system and it takes a long time to regenerate the issue on reporter's system(normally one week), it's not easy to commit right fix. The last patch sent to a problem reporter seems to work around the issue so I'll commit it this week. I have also problems on my system which might be related to the sk-trouble, so this fix might also help me. Or should I try to compile the new driver on my system (running 6-STABLE)? Yes. I'd like to hear any issues related with sk(4) in HEAD. -- 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: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote: Pyun, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h I compiled new sk driver on 6.1-RC, however I couldn't get it work. When I load module I get: May 8 12:04:56 proxy kernel: skc0: Marvell Gigabit Ethernet port 0xcc00-0xccff mem 0xfe3fc000-0xfe3f irq 20 at device 3.0 on pci6 May 8 12:04:56 proxy kernel: skc0: unknown media type: 0x31 May 8 12:04:56 proxy kernel: device_attach: skc0 attach returned 6 FYI: Fix committed to HEAD. Thanks a lot. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote: Pyun, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h I compiled new sk driver on 6.1-RC, however I couldn't get it work. When I load module I get: May 8 12:04:56 proxy kernel: skc0: Marvell Gigabit Ethernet port 0xcc00-0xccff mem 0xfe3fc000-0xfe3f irq 20 at device 3.0 on pci6 May 8 12:04:56 proxy kernel: skc0: unknown media type: 0x31 May 8 12:04:56 proxy kernel: device_attach: skc0 attach returned 6 FYI: Fix committed to HEAD. -- 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: new sk driver [was: nve timeout (and down) regression?]
Pyun,
I can not apply the patch cleanly on
http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c
What version of sk driver should I use?
Ganbold
Pyun YongHyeon wrote:
On Mon, May 08, 2006 at 02:25:48PM +0900, Ganbold wrote:
Pyun YongHyeon wrote:
On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote:
Pyun,
...
Is this NIC supported by if_sk driver?
Hmm, It seems that the NIC is SysKonnect V2.0(SK98XX2) which is
supposed to work with sk(4). Did it ever work with sk(4)?
No, it is new server and it came with such additional NIC.
I see there is differences between sk(4) and Linux skge driver
in determining physical media type. It seems OpenBSD also
used Linux skge approach.
I'll try to take a look at linux/openbsd drivers.
How about attached one? It's not tested but it may help your
situation.
Ganbold
thanks,
Ganbold
--- if_sk.c.origThu May 4 10:27:39 2006
+++ if_sk.c Mon May 8 14:48:33 2006
@@ -1604,14 +1604,15 @@
}
} else {
if (sc_if-sk_phytype SK_PHYTYPE_MARV_COPPER
- sc-sk_pmd == IFM_1000_T) {
+ sc-sk_pmd != 'S') {
/* not initialized, punt */
sc_if-sk_phytype = SK_PHYTYPE_MARV_COPPER;
+ sc-sk_coppertype = 1;
}
sc_if-sk_phyaddr = SK_PHYADDR_MARV;
- if (sc-sk_pmd != IFM_1000_T sc-sk_pmd != IFM_1000_CX)
+ if (!(sc-sk_coppertype))
sc_if-sk_phytype = SK_PHYTYPE_MARV_FIBER;
}
@@ -1788,31 +1789,12 @@
}
/* Read and save physical media type */
- switch(sk_win_read_1(sc, SK_PMDTYPE)) {
- case SK_PMD_1000BASESX:
- sc-sk_pmd = IFM_1000_SX;
- break;
- case SK_PMD_1000BASELX:
- sc-sk_pmd = IFM_1000_LX;
- break;
- case SK_PMD_1000BASECX:
- sc-sk_pmd = IFM_1000_CX;
- break;
- case SK_PMD_1000BASETX:
- sc-sk_pmd = IFM_1000_T;
- break;
- default:
- if (SK_YUKON_FAMILY(sc-sk_type) (sk_win_read_1(sc, SK_EPROM1)
- 0xF) SK_PHYTYPE_MARV_COPPER) {
- /* not initialized, punt */
- sc-sk_pmd = IFM_1000_T;
- break;
- }
- device_printf(dev, unknown media type: 0x%x\n,
- sk_win_read_1(sc, SK_PMDTYPE));
- error = ENXIO;
- goto fail;
- }
+sc-sk_pmd = sk_win_read_1(sc, SK_PMDTYPE);
+
+if (sc-sk_pmd == 'T' || sc-sk_pmd == '1')
+sc-sk_coppertype = 1;
+else
+sc-sk_coppertype = 0;
/* Determine whether to name it with VPD PN or just make it up.
* Marvell Yukon VPD PN seems to freqently be bogus. */
@@ -3722,17 +3704,10 @@
phy = SK_GPHY_INT_POL_HI | SK_GPHY_DIS_FC | SK_GPHY_DIS_SLEEP |
SK_GPHY_ENA_XC | SK_GPHY_ANEG_ALL | SK_GPHY_ENA_PAUSE;
- switch(sc_if-sk_softc-sk_pmd) {
- case IFM_1000_SX:
- case IFM_1000_LX:
- phy |= SK_GPHY_FIBER;
- break;
-
- case IFM_1000_CX:
- case IFM_1000_T:
+ if (sc-sk_coppertype)
phy |= SK_GPHY_COPPER;
- break;
- }
+ else
+ phy |= SK_GPHY_FIBER;
SK_IF_WRITE_4(sc_if, 0, SK_GPHY_CTRL, phy | SK_GPHY_RESET_SET);
DELAY(1000);
--- if_skreg.h.orig Tue May 2 11:12:42 2006
+++ if_skreg.h Mon May 8 14:48:33 2006
@@ -1535,6 +1535,7 @@
u_int32_t sk_rboff; /* RAMbuffer offset */
u_int32_t sk_ramsize; /* amount of RAM on NIC */
u_int32_t sk_pmd; /* physical media type */
+ u_int32_t sk_coppertype;
u_int32_t sk_intrmask;
int sk_int_mod;
int sk_int_ticks;
___
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: new sk driver [was: nve timeout (and down) regression?]
On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. Ganbold -- 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: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. thanks, Ganbold Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, May 08, 2006 at 03:51:55PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. Ok, copy the following files to /sys/dev/sk.(You may need to create the directory on 6.x.) From the files in http://people.freebsd.org/~yongari/sk/sk_test2/ if_sk.c -- /sys/dev/sk if_skreg.h -- /sys/dev/sk xmaciireg.h -- /sys/dev/sk yukonreg.h -- /sys/dev/sk And Makefile-- /sys/modules/sk thanks, Ganbold Ganbold -- 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: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:51:55PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. Ok, copy the following files to /sys/dev/sk.(You may need to create the directory on 6.x.) From the files in http://people.freebsd.org/~yongari/sk/sk_test2/ if_sk.c -- /sys/dev/sk if_skreg.h -- /sys/dev/sk xmaciireg.h -- /sys/dev/sk yukonreg.h -- /sys/dev/sk And Makefile-- /sys/modules/sk Still can't compile. cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c In file included from /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:130: @/dev/sk/if_skreg.h:995:15: no newline at end of file /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: (near initialization for `sk_devs[0]') /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: (near initialization for `sk_devs[0]') ... Ganbold thanks, Ganbold Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, May 08, 2006 at 04:53:10PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:51:55PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. Ok, copy the following files to /sys/dev/sk.(You may need to create the directory on 6.x.) From the files in http://people.freebsd.org/~yongari/sk/sk_test2/ if_sk.c -- /sys/dev/sk if_skreg.h -- /sys/dev/sk xmaciireg.h -- /sys/dev/sk yukonreg.h -- /sys/dev/sk And Makefile-- /sys/modules/sk Still can't compile. cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c In file included from /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:130: @/dev/sk/if_skreg.h:995:15: no newline at end of file I can't understand. There *IS* a newline at the end of file. Checking with hd(1) shows a newline character. If it break it should also break HEAD tinderbox too. /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: (near initialization for `sk_devs[0]') /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: (near initialization for `sk_devs[0]') ... Ganbold thanks, Ganbold Ganbold -- 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: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 04:53:10PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:51:55PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. Ok, copy the following files to /sys/dev/sk.(You may need to create the directory on 6.x.) From the files in http://people.freebsd.org/~yongari/sk/sk_test2/ if_sk.c -- /sys/dev/sk if_skreg.h -- /sys/dev/sk xmaciireg.h -- /sys/dev/sk yukonreg.h -- /sys/dev/sk And Makefile-- /sys/modules/sk Still can't compile. cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c In file included from /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:130: @/dev/sk/if_skreg.h:995:15: no newline at end of file I can't understand. There *IS* a newline at the end of file. Checking with hd(1) shows a newline character. If it break it should also break HEAD tinderbox too. I think new line is not a problem. The problematic line says /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type daemon# make Warning: Object directory not changed from original /usr/src/sys/modules/sk cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer ... Ganbold /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: (near initialization for `sk_devs[0]') /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: (near initialization for `sk_devs[0]') ... Ganbold thanks, Ganbold Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h I compiled new sk driver on 6.1-RC, however I couldn't get it work. When I load module I get: May 8 12:04:56 proxy kernel: skc0: Marvell Gigabit Ethernet port 0xcc00-0xccff mem 0xfe3fc000-0xfe3f irq 20 at device 3.0 on pci6 May 8 12:04:56 proxy kernel: skc0: unknown media type: 0x31 May 8 12:04:56 proxy kernel: device_attach: skc0 attach returned 6 Machine: FreeBSD 6.1-RC #1: Mon May 8 11:40:01 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PROXY ACPI APIC Table: DELL PE1800 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1073479680 (1023 MB) avail memory = 1041559552 (993 MB) ... pciconf -lv ... [EMAIL PROTECTED]:3:0: class=0x02 card=0x432011ab chip=0x432011ab rev=0x14 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet ... Is this NIC supported by if_sk driver? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote: Pyun, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h I compiled new sk driver on 6.1-RC, however I couldn't get it work. When I load module I get: May 8 12:04:56 proxy kernel: skc0: Marvell Gigabit Ethernet port 0xcc00-0xccff mem 0xfe3fc000-0xfe3f irq 20 at device 3.0 on pci6 May 8 12:04:56 proxy kernel: skc0: unknown media type: 0x31 May 8 12:04:56 proxy kernel: device_attach: skc0 attach returned 6 Machine: FreeBSD 6.1-RC #1: Mon May 8 11:40:01 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PROXY ACPI APIC Table: DELL PE1800 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1073479680 (1023 MB) avail memory = 1041559552 (993 MB) ... pciconf -lv ... [EMAIL PROTECTED]:3:0: class=0x02 card=0x432011ab chip=0x432011ab rev=0x14 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet ... Is this NIC supported by if_sk driver? Hmm, It seems that the NIC is SysKonnect V2.0(SK98XX2) which is supposed to work with sk(4). Did it ever work with sk(4)? I see there is differences between sk(4) and Linux skge driver in determining physical media type. It seems OpenBSD also used Linux skge approach. thanks, Ganbold -- 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: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote: Pyun, ... Is this NIC supported by if_sk driver? Hmm, It seems that the NIC is SysKonnect V2.0(SK98XX2) which is supposed to work with sk(4). Did it ever work with sk(4)? No, it is new server and it came with such additional NIC. I see there is differences between sk(4) and Linux skge driver in determining physical media type. It seems OpenBSD also used Linux skge approach. I'll try to take a look at linux/openbsd drivers. Ganbold thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, May 08, 2006 at 02:25:48PM +0900, Ganbold wrote:
Pyun YongHyeon wrote:
On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote:
Pyun,
...
Is this NIC supported by if_sk driver?
Hmm, It seems that the NIC is SysKonnect V2.0(SK98XX2) which is
supposed to work with sk(4). Did it ever work with sk(4)?
No, it is new server and it came with such additional NIC.
I see there is differences between sk(4) and Linux skge driver
in determining physical media type. It seems OpenBSD also
used Linux skge approach.
I'll try to take a look at linux/openbsd drivers.
How about attached one? It's not tested but it may help your
situation.
Ganbold
thanks,
Ganbold
--
Regards,
Pyun YongHyeon
--- if_sk.c.origThu May 4 10:27:39 2006
+++ if_sk.c Mon May 8 14:48:33 2006
@@ -1604,14 +1604,15 @@
}
} else {
if (sc_if-sk_phytype SK_PHYTYPE_MARV_COPPER
- sc-sk_pmd == IFM_1000_T) {
+ sc-sk_pmd != 'S') {
/* not initialized, punt */
sc_if-sk_phytype = SK_PHYTYPE_MARV_COPPER;
+ sc-sk_coppertype = 1;
}
sc_if-sk_phyaddr = SK_PHYADDR_MARV;
- if (sc-sk_pmd != IFM_1000_T sc-sk_pmd != IFM_1000_CX)
+ if (!(sc-sk_coppertype))
sc_if-sk_phytype = SK_PHYTYPE_MARV_FIBER;
}
@@ -1788,31 +1789,12 @@
}
/* Read and save physical media type */
- switch(sk_win_read_1(sc, SK_PMDTYPE)) {
- case SK_PMD_1000BASESX:
- sc-sk_pmd = IFM_1000_SX;
- break;
- case SK_PMD_1000BASELX:
- sc-sk_pmd = IFM_1000_LX;
- break;
- case SK_PMD_1000BASECX:
- sc-sk_pmd = IFM_1000_CX;
- break;
- case SK_PMD_1000BASETX:
- sc-sk_pmd = IFM_1000_T;
- break;
- default:
- if (SK_YUKON_FAMILY(sc-sk_type) (sk_win_read_1(sc,
SK_EPROM1)
-0xF) SK_PHYTYPE_MARV_COPPER) {
- /* not initialized, punt */
- sc-sk_pmd = IFM_1000_T;
- break;
- }
- device_printf(dev, unknown media type: 0x%x\n,
- sk_win_read_1(sc, SK_PMDTYPE));
- error = ENXIO;
- goto fail;
- }
+sc-sk_pmd = sk_win_read_1(sc, SK_PMDTYPE);
+
+if (sc-sk_pmd == 'T' || sc-sk_pmd == '1')
+sc-sk_coppertype = 1;
+else
+sc-sk_coppertype = 0;
/* Determine whether to name it with VPD PN or just make it up.
* Marvell Yukon VPD PN seems to freqently be bogus. */
@@ -3722,17 +3704,10 @@
phy = SK_GPHY_INT_POL_HI | SK_GPHY_DIS_FC | SK_GPHY_DIS_SLEEP |
SK_GPHY_ENA_XC | SK_GPHY_ANEG_ALL | SK_GPHY_ENA_PAUSE;
- switch(sc_if-sk_softc-sk_pmd) {
- case IFM_1000_SX:
- case IFM_1000_LX:
- phy |= SK_GPHY_FIBER;
- break;
-
- case IFM_1000_CX:
- case IFM_1000_T:
+ if (sc-sk_coppertype)
phy |= SK_GPHY_COPPER;
- break;
- }
+ else
+ phy |= SK_GPHY_FIBER;
SK_IF_WRITE_4(sc_if, 0, SK_GPHY_CTRL, phy | SK_GPHY_RESET_SET);
DELAY(1000);
--- if_skreg.h.orig Tue May 2 11:12:42 2006
+++ if_skreg.h Mon May 8 14:48:33 2006
@@ -1535,6 +1535,7 @@
u_int32_t sk_rboff; /* RAMbuffer offset */
u_int32_t sk_ramsize; /* amount of RAM on NIC */
u_int32_t sk_pmd; /* physical media type */
+ u_int32_t sk_coppertype;
u_int32_t sk_intrmask;
int sk_int_mod;
int sk_int_ticks;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 20:37, you wrote: On Tuesday 28 March 2006 11:38, Pieter de Goeje wrote: I can't really tell if the performance is impaired by mpsafenet=0, because the box is mostly busy doing userland stuff. Typical traffic looks like this: I'm going to test the new driver to see if I can disable mpsafenet. To be specific on the NIC: [EMAIL PROTECTED]:10:0: class=0x02 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet yes, this is the Asus A8V, same here may be you consider to try Pyun's driver http://people.freebsd.org/~yongari/sk/sk_test/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test/if_skreg.h and run yours without mpsafenet ? I have no clue what a game server requires. I tried anything even generic kernel and no sysctls/loader.conf values set in order to see if something else is wrong. Also I have lots of this machines and any of them same result. João I have the system running for 3 days straight now with the new driver, however the problem described earlier still exists. I still need to use mpsafenet=0. Other than that, the driver seems fine. No timeouts whatsoever. I was thinking, maybe it isn't the network driver but the linux compatibility layer that has problems with SMP. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Saturday 01 April 2006 16:15, Pieter de Goeje wrote: may be you consider to try Pyun's driver http://people.freebsd.org/~yongari/sk/sk_test/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test/if_skreg.h and run yours without mpsafenet ? I have no clue what a game server requires. I tried anything even generic kernel and no sysctls/loader.conf values set in order to see if something else is wrong. Also I have lots of this machines and any of them same result. João I have the system running for 3 days straight now with the new driver, however the problem described earlier still exists. I still need to use mpsafenet=0. Other than that, the driver seems fine. No timeouts whatsoever. I was thinking, maybe it isn't the network driver but the linux compatibility layer that has problems with SMP. Pieter de Goeje great ! the problem you mention is what you wrote in a former msg, right: With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. that is really strange, I do not have such problems at all and it seems we are running basicly the same system, AV8 + X2 + releng_6. so the gameserver needs linux_compat? I haven't it compiled in my kernel but on some parent caches which talk udp between them and some loaded DNS servers I got ocasionally udp errors but I could get around it by setting net.inet.udp.recvspace net.inet.udp.maxdgram to higher values. João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h -- 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: new sk driver [was: nve timeout (and down) regression?]
On Monday 27 March 2006 23:08, Pyun YongHyeon wrote: Jo?o This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. Does it happen on my latest sk(4) driver? I think he talks about the releng_6 driver and not about yours João I don't have amd64 systems but the driver was tested on i386(SMP) and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. How about stock sk(4)? Does it have the same issue too? So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. -- Atenciosamente Infomatik Internet Technology (18)3551.8155 (18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Monday 27 March 2006 21:21, Pieter de Goeje wrote: IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver João This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. probably you do not have the traffic to make the box crash or less then 1/2GB of RAM in use in fact the problem does not happen on UP machines, only some times a device timeout which only ocasionally cause rx/tx to stop The problem is appearing on SMP machines when you have less then 2Gb of RAM the problem ocurres once a day or so and seems to depend on memory use and amount of traffic soon the traffic reaches more than 1Mbit/s the crash is predictable and you can wait to see on 4GB of Ram machines and more traffic the crash is imediatly and worse when the box crashed under load (4-6Mbit/s) and comes back then the high demand strokes it and it crashes in minutes or imediatly soon the network is up so probably mpsafenet may help by not processing concurrent packets but this is a workaround not a solution (for me) last time I checked mpsafenet=0 almost cut 1Mbit/s of traffic and the overall performance/response was bad, higher HZ did not resolved anything and disabling polling made it still worse (I have other NICs installed), the machines are working as GW until january the machines didn't crashed, only timeouts and rx/tx stops I used Pyun's driver and the timeouts went away, thank's again! so then I got confused by some if_sk talks on stable and thought the driver was comitted and the boxes started crashing until I got it last week and reused Pyun's driver again and my sk problems are gone again, the machines are stable for 4/5 days now João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 04:08, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 02:21:28AM +0200, Pieter de Goeje wrote: On Monday 27 March 2006 23:48, JoaoBR wrote: On Monday 27 March 2006 15:51, Mark Linimon wrote: On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. well, ok that is completly understandable basicly but this driver is unusable since dec/jan for me, for others probably longer IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver Jo?o This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. Does it happen on my latest sk(4) driver? I'll give it a try. I don't have amd64 systems but the driver was tested on i386(SMP) and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. How about stock sk(4)? Does it have the same issue too? I am using stock sk(4) now. I'm not seeing any watchdog timeout errors. So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. I did try an old realtek (rl(4)) card, it had the same problems and I could fix the problems with that card too by turning off mpsafenet. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout -- Wilko Bulte [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: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 12:40, you wrote: snip probably you do not have the traffic to make the box crash or less then 1/2GB of RAM in use The box has 1GB RAM. Traffic is approx. 2-3Mbit/s. in fact the problem does not happen on UP machines, only some times a device timeout which only ocasionally cause rx/tx to stop The problem is appearing on SMP machines when you have less then 2Gb of RAM the problem ocurres once a day or so and seems to depend on memory use and amount of traffic soon the traffic reaches more than 1Mbit/s the crash is predictable and you can wait to see The box has actually crashed once, but I am not sure it was because of the NIC. ~ uptime 4:19PM up 3 days, 9:59, 1 user, load averages: 1.38, 1.20, 1.03 on 4GB of Ram machines and more traffic the crash is imediatly and worse when the box crashed under load (4-6Mbit/s) and comes back then the high demand strokes it and it crashes in minutes or imediatly soon the network is up so probably mpsafenet may help by not processing concurrent packets but this is a workaround not a solution (for me) Agreed. last time I checked mpsafenet=0 almost cut 1Mbit/s of traffic and the overall performance/response was bad, higher HZ did not resolved anything and disabling polling made it still worse (I have other NICs installed), the machines are working as GW I can't really tell if the performance is impaired by mpsafenet=0, because the box is mostly busy doing userland stuff. Typical traffic looks like this: ~ netstat -w 1 input(Total) output packets errs bytespackets errs bytes colls 1186 0 97134 1302 0 276430 0 1206 0 97484 1382 0 264315 0 1193 0 97048 1366 0 278901 0 1198 0 98251 1403 0 273428 0 1205 0 99283 1393 0 270364 0 1162 0 94746 1376 0 265909 0 1162 0 93011 1420 0 258514 0 1187 0 94366 1467 0 263162 0 1178 0 93441 1441 0 248875 0 1176 0 93116 1484 0 266285 0 1146 0 91615 1424 0 256180 0 1222 0 96597 1560 0 432862 0 1222 0 93796 1591 0 66 0 This is all UDP. The traffic generates around 2000 interrupts/sec on sk. until january the machines didn't crashed, only timeouts and rx/tx stops I used Pyun's driver and the timeouts went away, thank's again! so then I got confused by some if_sk talks on stable and thought the driver was comitted and the boxes started crashing until I got it last week and reused Pyun's driver again and my sk problems are gone again, the machines are stable for 4/5 days now I'm going to test the new driver to see if I can disable mpsafenet. To be specific on the NIC: [EMAIL PROTECTED]:10:0: class=0x02 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 11:38, Pieter de Goeje wrote: I can't really tell if the performance is impaired by mpsafenet=0, because the box is mostly busy doing userland stuff. Typical traffic looks like this: I'm going to test the new driver to see if I can disable mpsafenet. To be specific on the NIC: [EMAIL PROTECTED]:10:0: class=0x02 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet yes, this is the Asus A8V, same here may be you consider to try Pyun's driver http://people.freebsd.org/~yongari/sk/sk_test/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test/if_skreg.h and run yours without mpsafenet ? I have no clue what a game server requires. I tried anything even generic kernel and no sysctls/loader.conf values set in order to see if something else is wrong. Also I have lots of this machines and any of them same result. João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, 27 Mar 2006, JoaoBR wrote: On Saturday 25 March 2006 08:55, Bjoern A. Zeeb wrote: On Sat, 25 Mar 2006, David Xu wrote: ÿÿ Saturday 25 March 2006 18:04ÿÿJoaoBR ÿÿ It appears to be a point the machines with problem are all SMP, UP do no show the nve timeout or any other problem with it alias, same with SK, on SMP the system crashes and with UP it's ok For sk please try the new driver Pyun is regularly postng and will commit once the 5/6Rs are done. for some reason I thought it was already commited so I reused it and my sk problem is gone, since friday the machines are running fine again why it will be in only after the release? I guess for several reasons: a) more testing b) not confuse users with problem reports from the one or the other during Release testing. c) possible repo-copy to sys/dev/sk d) ... -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Monday 27 March 2006 11:50, Bjoern A. Zeeb wrote: so I reused it and my sk problem is gone, since friday the machines are running fine again why it will be in only after the release? I guess for several reasons: a) more testing b) not confuse users with problem reports from the one or the other during Release testing. c) possible repo-copy to sys/dev/sk d) ... well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Monday 27 March 2006 15:51, Mark Linimon wrote: On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. well, ok that is completly understandable basicly but this driver is unusable since dec/jan for me, for others probably longer IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Monday 27 March 2006 23:48, JoaoBR wrote: On Monday 27 March 2006 15:51, Mark Linimon wrote: On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. well, ok that is completly understandable basicly but this driver is unusable since dec/jan for me, for others probably longer IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver João This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tue, Mar 28, 2006 at 02:21:28AM +0200, Pieter de Goeje wrote: On Monday 27 March 2006 23:48, JoaoBR wrote: On Monday 27 March 2006 15:51, Mark Linimon wrote: On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. well, ok that is completly understandable basicly but this driver is unusable since dec/jan for me, for others probably longer IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver Jo?o This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. Does it happen on my latest sk(4) driver? I don't have amd64 systems but the driver was tested on i386(SMP) and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. How about stock sk(4)? Does it have the same issue too? So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. -- 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: new sk driver [was: nve timeout (and down) regression?]
On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
