BGE VLAN stranges
Hello! I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and FreeBSD 5.1R installed. There are no problems if I use bge as usual network card, but when I try to use 802.1Q vlans, I can't receive (only receive, sending is ok) packets more then 1456 bytes! What is the problem? BGE driver, VLAN driver or my network configuration? Best wishes, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: dvd+rw-format -force problem]
Original Message Subject: dvd+rw-format -force problem Date: Thu, 31 Jul 2003 21:30:00 +0200 From: Melvyn Sopacua [EMAIL PROTECTED] Organization: WebTeckies.org To: [EMAIL PROTECTED] I haven't felt the need to fully blank a DVD+RW for a while untill today. Formally speaking blanking is not appicable to DVD+RW. dvd+rw-format -force merely zeros bitmap which describes which ECC blocks were de-iced/written to and nullifies few blocks in the beginning of the media. It's not what one would normally consider as [full] blanking. If you want to nullify the media, e.g. for privacy reasons, 'dvd+rw-format -force /dev/cd0c' won't do the tick, 'growisofs -Z /dev/cd0c=/dev/zero' would. The problem is the following: When issuing: dvd+rw-format -force /dev/cd0c it fails, with 'unable to unmount' error. I see the problem now. Fortunately I'm preparing new update addressing performance problems with Pioneer DVR-x06 and will incorporate proper solution even for this problem:-) A little tracing in the source, shows that the following patch, will work - The proposed solution is not appropriate from security viewpoint, but as already mentioned, proper solution will be provided in the upcoming update, which will be released shortly. Meanwhile just write over the old recording in exact same way it was originally performed, namely with 'growisofs -Z /dev/cd0c ...'. Can anybody tell wether the author's expectation is wrong, Yes, my expectations were wrong, it's a bug and well be fixed. Cheers. A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: BGE VLAN stranges
-Original Message- From: Boris Kovalenko [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 AM To: [EMAIL PROTECTED] Subject: BGE VLAN stranges Hello! I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and FreeBSD 5.1R installed. There are no problems if I use bge as usual network card, but when I try to use 802.1Q vlans, I can't receive (only receive, sending is ok) packets more then 1456 bytes! What is the problem? BGE driver, VLAN driver or my network configuration? Boris, This sounds normal - your vlan probably has a max MTU of 1464 bytes (one of the ethernet standards uses this instead of 1500 I think). If you want to transmit larger frames, you have to up the MTU on your adapter and on the switch somehow. I think this is referred to as 'jumbo frames.' If you set the adapter MTU to 1464 you should not have problems sending and receiving, your packets will just get fragmented. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BGE VLAN stranges
Will Saxon wrote: Hello! Have checked both MTU on Catalyst 2950 and BGE interface. Both are 1500. Also, I have no problems with 1500 MTU on FreeBSD 4.8R and FXP driver. Yours truly, Boris -Original Message- From: Boris Kovalenko [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 AM To: [EMAIL PROTECTED] Subject: BGE VLAN stranges Hello! I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and FreeBSD 5.1R installed. There are no problems if I use bge as usual network card, but when I try to use 802.1Q vlans, I can't receive (only receive, sending is ok) packets more then 1456 bytes! What is the problem? BGE driver, VLAN driver or my network configuration? Boris, This sounds normal - your vlan probably has a max MTU of 1464 bytes (one of the ethernet standards uses this instead of 1500 I think). If you want to transmit larger frames, you have to up the MTU on your adapter and on the switch somehow. I think this is referred to as 'jumbo frames.' If you set the adapter MTU to 1464 you should not have problems sending and receiving, your packets will just get fragmented. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with dc-nics 10,11
Hi, I have a little problem with dc10, dc11. I use three quad dc cards, so far from dc0 up to dc8 with no problems. All (dc0 to dc11) are displayed correctly with pciconf and with ifconfig. The trouble is with dc10 and dc11 that they don't send any data out and also don't react to arp requests etc. - at least using tcpdump won't show anything coming in or going out. Monitoring from an external system, this is the same. According to the blinkinglights on the switch in between (also tried a hub), pings from the other machine (or arp-requests if I don't use a permanent entry) etc are send to the correct cable. As everything works from dc0 up to dc9, I'd suspect some sort of internal name mismatching (like counting devices hexadecimal (dca) versus decimal (dc10)). This is on an older system (4.6-STABLE). If someone had a similar problem and it is now fixed in 4.8-STABLE, please let me know. Couldn't find a PR for this... Regards, Holger Kipp -- Holger Kipp, Dipl.-Math., Systemadministrator | alogis AG Fon: +49 (0)30 / 43 65 8 - 114 | Berliner Strasse 26 Fax: +49 (0)30 / 43 65 8 - 214 | D-13507 Berlin Tegel email: [EMAIL PROTECTED] | http://www.alogis.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gdb coredumps
Hi, After kernel panic I couldn't get gdb work properly. msi$ uname -sr FreeBSD 4.7-RELEASE msi$ gdb -k /usr/src/sys/compile/MSINW/kernel.debug vmcore.0 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutil s/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf IdlePTD at phsyical address 0x65746e49 initial pcb at physical address 0x002cff20 panic messages: --- dmesg: cannot read PTD --- #0 0x0 in ?? () (kgdb) where #0 0x0 in ?? () Segmentation fault (core dumped) -Kirill Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-RELEASE #0: Thu Mar 6 12:27:11 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MSINW Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(TM) XP 2400+ (2000.08-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 1073725440 (1048560K bytes) avail memory = 1041793024 (1017376K bytes) Preloaded elf kernel kernel at 0xc034a000. Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f1bf0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: PCI to PCI bridge (vendor=1106 device=b099) at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: ATI model 5446 graphics accelerator at 0.0 irq 11 pci0: unknown card (vendor=0x14e4, dev=0x4401) at 9.0 irq 12 twe0: 3ware Storage Controller port 0xb800-0xb80f mem 0xf180-0xf1ff,0xf200-0xf20f irq 15 at device 11.0 on pci0 twe0: 8 ports, Firmware FE7X 1.05.00.036, BIOS BE7X 1.08.00.044 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb400-0xb43f mem 0xf080-0xf08f,0xf100-0xf1000fff irq 11 at device 13.0 on pci0 fxp0: Ethernet address 00:02:b3:4c:0b:66 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel Pro 10/100B/100+ Ethernet port 0xb000-0xb03f mem 0xef80-0xef81,0xf000-0xffff irq 10 at device 14.0 on pci0 fxp1: Ethernet address 00:02:b3:4c:32:12 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec 19160B Ultra160 SCSI adapter port 0xa800-0xa8ff mem 0xef00-0xef000fff irq 12 at device 15.0 on pci0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs uhci0: VIA 83C572 USB controller port 0xa400-0xa41f irq 14 at device 16.0 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xa000-0xa01f irq 14 at device 16.1 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0x9800-0x981f irq 14 at device 16.2 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: USB controller at 16.3 irq 14 isab0: PCI to ISA bridge (vendor=1106 device=3177) at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8235 ATA133 controller at device 17.1 on pci0 atapci0: ATA channel disabled by BIOS orm0: Option ROMs at iomem 0xc-0xc,0xd-0xd17ff,0xd4000-0xd4fff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on
Re: Problem with dc-nics 10,11
Holger Kipp writes: | I have a little problem with dc10, dc11. I use three quad dc cards, | so far from dc0 up to dc8 with no problems. | | All (dc0 to dc11) are displayed correctly with pciconf and with ifconfig. | The trouble is with dc10 and dc11 that they don't send any data out and | also don't react to arp requests etc. - at least using tcpdump won't show | anything coming in or going out. | Monitoring from an external system, this is the same. According to the | blinkinglights on the switch in between (also tried a hub), pings from | the other machine (or arp-requests if I don't use a permanent entry) etc | are send to the correct cable. | | As everything works from dc0 up to dc9, I'd suspect some sort of internal | name mismatching (like counting devices hexadecimal (dca) versus decimal | (dc10)). | | This is on an older system (4.6-STABLE). If someone had a similar problem | and it is now fixed in 4.8-STABLE, please let me know. Couldn't find a PR | for this... Considering that I've had 4*4 cards in prior 4.X systems my experience is that you have a BIOS that is not allocating resources to the cards after a while. I run into that before in which the BIOS stop setting up PCI devices after a certain number or not traversing all bridges. Doing a dmesg and looking IRQ allocation is a good starting point. It's probably bad. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel deadlock
On Tue, 29 Jul 2003, Don Bowman wrote: From: Don Bowman [mailto:[EMAIL PROTECTED] From: Robert Watson [mailto:[EMAIL PROTECTED] On Tue, 29 Jul 2003, Dave Dolson wrote: To follow up, I've discovered that the system has exhausted its FFS node malloc type. ... Some problems with this have turned up in -CURRENT on large-memory machines where some of the scaling factors have been off. In We currently have kern.maxvnodes=70354 set (automatically scaled). This is a 1GB box. I will try re-running the test with less. when it hits kern.maxvnodes, what will it do? After applying the fixes from RELENG_4 for kern/52425, I can still easily reproduce this hang without low memory. Further debugging shows that vnlru process is waiting on vlrup. This line is shown below. ie vnlru_nowhere is being incremented ever 3 seconds. So what is happening here is that vnlru wakes up, runs through, and there is nothing to free, so it goes back to sleep having freed nothing. The caller doesn't wake up. There's no vnodes to free, and everything in the system locks up. One possible solution is to make vnlru more aggressive, so that before giving up, it tries to free pages that have many references etc (which it currently skips). Another option is to have it simply bump the kern.maxvnodes number and wake up the process which called it. Suggestions? --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-stable Digest, Vol 19, Issue 5 (Vacation)
I will be gone and out of contact from 8/1 to 8/18 on a camping trip. I will return to work Tuesday, 8/19. Please use the helpdesk system at https://sbv.techteam.com/ for assistance, and your message will be routed to an available technician. Those outside of SI wishing to contact me should use their regular SBV/SIMag/ASMag contact person and they will take appropriate action. Others trying to reach me should contact my manager Lee Hausman ([EMAIL PROTECTED]). [EMAIL PROTECTED] 08/01/03 15:01 Send freebsd-stable mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-stable or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of freebsd-stable digest... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel deadlock
On Fri, 1 Aug 2003, Don Bowman wrote: On Tue, 29 Jul 2003, Don Bowman wrote: From: Don Bowman [mailto:[EMAIL PROTECTED] From: Robert Watson [mailto:[EMAIL PROTECTED] On Tue, 29 Jul 2003, Dave Dolson wrote: To follow up, I've discovered that the system has exhausted its FFS node malloc type. ... Some problems with this have turned up in -CURRENT on large-memory machines where some of the scaling factors have been off. In We currently have kern.maxvnodes=70354 set (automatically scaled). This is a 1GB box. I will try re-running the test with less. when it hits kern.maxvnodes, what will it do? After applying the fixes from RELENG_4 for kern/52425, I can still easily reproduce this hang without low memory. Further debugging shows that vnlru process is waiting on vlrup. This line is shown below. ie vnlru_nowhere is being incremented ever 3 seconds. So what is happening here is that vnlru wakes up, runs through, and there is nothing to free, so it goes back to sleep having freed nothing. The caller doesn't wake up. There's no vnodes to free, and everything in the system locks up. One possible solution is to make vnlru more aggressive, so that before giving up, it tries to free pages that have many references etc (which it currently skips). Another option is to have it simply bump the kern.maxvnodes number and wake up the process which called it. Suggestions? check out 4.8-STABLE, which Tor.Egge(sp?) made modifications to the vnlru process that sound exactly what you are proposing ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel deadlock
From: The Hermit Hacker [mailto:[EMAIL PROTECTED] One possible solution is to make vnlru more aggressive, so that before giving up, it tries to free pages that have many references etc (which it currently skips). Another option is to have it simply bump the kern.maxvnodes number and wake up the process which called it. Suggestions? check out 4.8-STABLE, which Tor.Egge(sp?) made modifications to the vnlru process that sound exactly what you are proposing ... Actually that makes the problem worse in an other area, and doesn't fix this one. The 'fix' there is to do 10% of the noes on a free operation, rather than 10 at a time. Now the system will hang up for longer when its freeing them. However the root cause is still that it decides there are no freeable nodes in this case, so vnlru goes back to sleep having freed none, the caller stays asleep, and anyone else wanting a vnode goes to sleep too. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ethereal-0.9.13: make install fails
The make install of the latest ethereal port fails. I'm running FreeBSD 4.6.2-RELEASE-p10. Any ideas? -- Scott (cd doc ; make ../tethereal.1 ) ../tethereal -G fields | /usr/bin/perl ./dfilter2pod.pl ./tethereal.pod.template tethereal.pod /usr/bin/pod2man --center=The Ethereal Network Analyzer --release=0.9.13 tethereal.pod ../tethereal.1 /bin/sh ./mkinstalldirs /usr/X11R6/bin sed: 1: s,^.*/,,;;s/$//: invalid command code ; *** Error code 1 Stop in /usr/ports/net/ethereal/work/ethereal-0.9.13. *** Error code 1 Stop in /usr/ports/net/ethereal/work/ethereal-0.9.13. *** Error code 1 Stop in /usr/ports/net/ethereal/work/ethereal-0.9.13. *** Error code 1 Stop in /usr/ports/net/ethereal. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[BUG REPORT] Off by one error in initializing unit number forPCCARD NICs in both recent 4.8-STABLE and 5.1-RELEASE
Because of the nature of this bug, I have no network access on my FreeBSD machine and so I'm filing this off my wife's laptop. I can't send-pr in any other manner. Would someone please post this SYSTEM IBM 380XD Thinkpad Laptop running either a recent (post-May) 4.8-STABLE or 5.1-RELEASE (off the ISO images off ftp.freebsd.org). The 5.1 kernel was recompiled with OLDCARD support since NEWCARD fails in other ways. Using Compaq Netelligent 10/100 PCCARD Nic or NetGear Wireless (xe and wi respectively) SYMPTOMS Boot and detect occur normally. However, as the PCCARD device is being brought up, the PCCARD subsystem is starting with a unit number of -1 instead of 0. Hence, I get messages indicating attempts to start xe-1 which always fail. Prior to May, STABLE was fine. When I recompiled STABLE and found myself without network access. I decided to install a clean install of 5.1-RELEASE. To my chagrin, the same problem exists on 5.1-RELEASE too. WORKAROUND None known. jmc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
