Re: HEADS UP: fxp breakage
Daniel C. Sobral wrote: Maxime Henrion wrote: Hi all, I was finally able to reproduce the problems people have been reporting. That is, the fxp(4) card works but there are many odd "unknown: DMA timeout" and "unknown: device timeout" messages. This was due to a bug in fxp(4) which was harmless unless you used DEVICE_POLLING. These problems go away when using the 1.156 revision of if_fxp.c. Please note that other people have been reporting different symptoms, ie the card sees no traffic at all. I'm not sure the latest sources fix these cases too, but I'm fairly confident they do, because one person who has been reporting me such symptoms was using DEVICE_POLLING too. Mm. Now that I think of it, I am too. On this particular machine. I had forgotten I had configured DEVICE_POLLING in this host alone... :-( Sorry about that. Could have speeded up things some. I'm trying a new kernel now. Ok, this fixes it for me. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Spellng is overated anywy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: fxp breakage
Maxime Henrion wrote: Hi all, I was finally able to reproduce the problems people have been reporting. That is, the fxp(4) card works but there are many odd "unknown: DMA timeout" and "unknown: device timeout" messages. This was due to a bug in fxp(4) which was harmless unless you used DEVICE_POLLING. These problems go away when using the 1.156 revision of if_fxp.c. Please note that other people have been reporting different symptoms, ie the card sees no traffic at all. I'm not sure the latest sources fix these cases too, but I'm fairly confident they do, because one person who has been reporting me such symptoms was using DEVICE_POLLING too. Mm. Now that I think of it, I am too. On this particular machine. I had forgotten I had configured DEVICE_POLLING in this host alone... :-( Sorry about that. Could have speeded up things some. I'm trying a new kernel now. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Spellng is overated anywy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: fxp breakage
Hi all, I was finally able to reproduce the problems people have been reporting. That is, the fxp(4) card works but there are many odd "unknown: DMA timeout" and "unknown: device timeout" messages. This was due to a bug in fxp(4) which was harmless unless you used DEVICE_POLLING. These problems go away when using the 1.156 revision of if_fxp.c. Please note that other people have been reporting different symptoms, ie the card sees no traffic at all. I'm not sure the latest sources fix these cases too, but I'm fairly confident they do, because one person who has been reporting me such symptoms was using DEVICE_POLLING too. Of course, if it's still broken for you, please let me know. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: HEADS UP: fxp breakage
Ok. Here's the information requested. This is taken from the boxes running a working, older kernel (otherwise wouldn't be able to get to them remotely). I can get the same info with the broken kernel come Monday should that be necessary. Hope this helps! 1) dell poweredge 4350 fxp0: flags=18843 mtu 1500 inet 10.10.10.253 netmask 0x broadcast 10.10.255.255 ether 00:90:27:5a:22:7b media: Ethernet autoselect (100baseTX ) status: active [EMAIL PROTECTED]:12:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet fxp0: port 0xdcc0-0xdcff mem 0xfe00-0xfe0f,0xfe10-0xfe100fff irq 14 at device 12.0 on pci0 2) asus kg7 fxp0: flags=18843 mtu 1500 inet 10.10.10.201 netmask 0x broadcast 10.10.255.255 ether 00:90:27:66:62:1a media: Ethernet autoselect (100baseTX ) status: active [EMAIL PROTECTED]:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet fxp0: port 0xe000-0xe03f mem 0xf900-0xf90f,0xf9101000-0xf9101fff irq 10 at device 11.0 on pci0 both machines are running the following kernel config: options INCLUDE_CONFIG_FILE machine i386 cpu I686_CPU ident "fbsd5-uni" makeoptions DEBUG=-g options KTRACE options DDB options DDB_UNATTENDED options ALT_BREAK_TO_DEBUGGER #optionsSCHED_4BSD options SCHED_ULE options COMPAT_43 options COMPAT_FREEBSD4 options INET options TCP_DROP_SYNFIN options RANDOM_IP_ID options FFS options SOFTUPDATES options UFS_DIRHASH #optionsGEOM_APPLE #optionsUFS_EXTATTR #optionsUFS_EXTATTR_AUTOSTART #optionsUFS_ACL options SYSVSHM options SYSVMSG options SYSVSEM #optionsP1003_1B_SEMAPHORES options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV device isa device pci device agp device fdc device npx device atkbdc device atkbd device psm device vga device sc options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_RED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) device sio options CONSPEED=19200 device ppc device ppbus device lpt device plip device ppi device vpo # SCSI / RAID options SCSI_DELAY=5000 device ahc device amr device scbus device ch device da device sa device cd device pt device targ device targbh device pass device ses options SES_ENABLE_PASSTHROUGH # ATAPI device ata device atadisk device atapicd device atapifd device atapist device atapicam options ATA_STATIC_ID # NICs device miibus device fxp options DEVICE_POLLING options HZ=1000 # Pseudo devices device random device loop device ether device tun device pty device gif device bpf Robin P. Blanchard wrote: > Following sources still yield unresponsive fxp interface. The same behavious > occurs on both of my test boxes (dell 4350 and home-grown athlon xp), each > having identical Intel Pro 100+M nics with v4.1.0.9 intel PXE rom. > > # fgrep -h \*\ \$FreeBSD /usr/src/sys/dev/fxp/* > > * $FreeBSD: src/sys/dev/fxp/if_fxp.c,v 1.154 2003/04/03 20:39:43 mux Exp $ > * $FreeBSD: src/sys/dev/fxp/if_fxpreg.h,v 1.30 2003/04/03 18:39:48 mux Exp $ > * $FreeBSD: src/sys/dev/fxp/if_fxpvar.h,v 1.24 2003/04/02 16:47:16 mux Exp $ > * $FreeBSD: src/sys/dev/fxp/rcvbundl.h,v 1.1 2001/10/25 05:23:31 jlemon Exp > $ Could everyone which has problems with the fxp(4) driver mail me some informations ? I'd need the exact symptoms, the output of ifconfig on the interface, the part of pciconf -lv relevant to your fxp card, your kernel configuration file and the output of dmesg. That would be help me a lot to understand what's going on, since I can't reproduce these problems on any of my fxp(4) cards. Since this is a commonly used driver in the FreeBSD community, I've put a kernel module for fxp online, built with the sources prior to the busdma commit. It's at http://people.freebsd.org/~mux/if_fxp.ko.gz. > Reverting back to kernel sources from 11 April yield functional interface. 11 April ? Did you make a typo ?
HEADS UP: fxp breakage
Hi all, Robin P. Blanchard wrote: > Following sources still yield unresponsive fxp interface. The same behavious > occurs on both of my test boxes (dell 4350 and home-grown athlon xp), each > having identical Intel Pro 100+M nics with v4.1.0.9 intel PXE rom. > > # fgrep -h \*\ \$FreeBSD /usr/src/sys/dev/fxp/* > > * $FreeBSD: src/sys/dev/fxp/if_fxp.c,v 1.154 2003/04/03 20:39:43 mux Exp $ > * $FreeBSD: src/sys/dev/fxp/if_fxpreg.h,v 1.30 2003/04/03 18:39:48 mux Exp $ > * $FreeBSD: src/sys/dev/fxp/if_fxpvar.h,v 1.24 2003/04/02 16:47:16 mux Exp $ > * $FreeBSD: src/sys/dev/fxp/rcvbundl.h,v 1.1 2001/10/25 05:23:31 jlemon Exp > $ Could everyone which has problems with the fxp(4) driver mail me some informations ? I'd need the exact symptoms, the output of ifconfig on the interface, the part of pciconf -lv relevant to your fxp card, your kernel configuration file and the output of dmesg. That would be help me a lot to understand what's going on, since I can't reproduce these problems on any of my fxp(4) cards. Since this is a commonly used driver in the FreeBSD community, I've put a kernel module for fxp online, built with the sources prior to the busdma commit. It's at http://people.freebsd.org/~mux/if_fxp.ko.gz. > Reverting back to kernel sources from 11 April yield functional interface. 11 April ? Did you make a typo ? Thanks, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fxp breakage (still)
Following sources still yield unresponsive fxp interface. The same behavious occurs on both of my test boxes (dell 4350 and home-grown athlon xp), each having identical Intel Pro 100+M nics with v4.1.0.9 intel PXE rom. # fgrep -h \*\ \$FreeBSD /usr/src/sys/dev/fxp/* * $FreeBSD: src/sys/dev/fxp/if_fxp.c,v 1.154 2003/04/03 20:39:43 mux Exp $ * $FreeBSD: src/sys/dev/fxp/if_fxpreg.h,v 1.30 2003/04/03 18:39:48 mux Exp $ * $FreeBSD: src/sys/dev/fxp/if_fxpvar.h,v 1.24 2003/04/02 16:47:16 mux Exp $ * $FreeBSD: src/sys/dev/fxp/rcvbundl.h,v 1.1 2001/10/25 05:23:31 jlemon Exp $ Reverting back to kernel sources from 11 April yield functional interface. Robin P. Blanchard Systems Integration Specialist Georgia Center for Continuing Education fon: 706.542.2404 <|> fax: 706.542.6546 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fxp breakage
Ok. Hopefully some useful information hereUsing a kernel built against the below fxp sources, the interface simply does not pass or see any traffic. Reverting back to kernel from 01 April permits the intrace to function properly. fxp0: flags=18843 mtu 1500 inet 10.10.10.201 netmask 0x broadcast 10.10.255.255 ether 00:90:27:66:62:1a media: Ethernet autoselect (100baseTX ) status: active fxp0: port 0xe000-0xe03f mem 0xf900-0xf90f,0xf9101000-0xf9101fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:90:27:66:62:1a [EMAIL PROTECTED]:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet * $FreeBSD: src/sys/dev/fxp/if_fxpreg.h,v 1.30 2003/04/03 18:39:48 mux Exp $ # ls -ltr /usr/src/sys/dev/fxp/ total 116 -rw-r--r-- 1 root wheel 21318 Oct 25 2001 rcvbundl.h -rw-r--r-- 1 root wheel 8190 Apr 2 13:00 if_fxpvar.h -rw-r--r-- 1 root wheel 73326 Apr 3 11:46 if_fxp.c -rw-r--r-- 1 root wheel 12975 Apr 3 15:14 if_fxpreg.h Robin P. Blanchard Systems Integration Specialist Georgia Center for Continuing Education fon: 706.542.2404 <|> fax: 706.542.6546 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FXP breakage
--- Pete Carah <[EMAIL PROTECTED]> wrote: > This may be just my infamous vaio acting up again, > but since the > recent commit to fxp driver (Monday?) I get a panic > on device probe > (page fault in kernel mode). > > That and the way the pccbb act up (always return 0 > for event and > status register reads, and don't reset pending > interrupt on event reg > write) make me think that something is awry with the > way acpi/pci > allocate memory for the device windows. > > I know there is something funny with the aml/asl > since almost everything > ends up on irq 9 also... > > I also sometimes see the lock order problem with pcm > but mostly just missing > interrupts (choppy sound that comes out slow but in > the right order). > PCM is responding to display interrupts... > > -- Pete I wondered what that crash was on boot-up. Sometimes it does boot though! Anyway... I also have almost everything on IRQ9. I'm not sure its FreeBSD - I think its the Vaio :( Just checked Windows 2000 and it lists USB, video, network, firewire, audio _ALL_ on IRQ9. Perhaps your pcm problems come from the interrupt not being delivered at all - try moving a USB mouse while your audio is playing. I have a hacky-hack to make my vaio's audio play normally. I noticed that since the audio and usb share an interrupt, moving a USB mouse gets the pcm interrupt handler called - which results in normal sound. Sorry, I don't have my own web page address handy - I never go there ;) I'll send it privately. Chuck McCrobie [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FXP breakage
Pete Carah wrote: > This may be just my infamous vaio acting up again, but since the > recent commit to fxp driver (Monday?) I get a panic on device probe > (page fault in kernel mode). This should be fixed in revision 1.30 of if_fxpreg.h that I committed some time ago. Sorry for the inconvenience. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FXP breakage
This may be just my infamous vaio acting up again, but since the recent commit to fxp driver (Monday?) I get a panic on device probe (page fault in kernel mode). That and the way the pccbb act up (always return 0 for event and status register reads, and don't reset pending interrupt on event reg write) make me think that something is awry with the way acpi/pci allocate memory for the device windows. I know there is something funny with the aml/asl since almost everything ends up on irq 9 also... I also sometimes see the lock order problem with pcm but mostly just missing interrupts (choppy sound that comes out slow but in the right order). PCM is responding to display interrupts... -- Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
