upkhy ed driver problem
Hi, I've problem with upkhy at ed - my pcmcia card don't work. I'm using FreeBSD 8.0-CURRENT-200801 but I noticed issue in 5, 6 and 7 branch. My dmesg: Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT-200801 #1: Sat Jan 26 18:24:09 UTC 2008 root@:/usr/src/sys/i386/compile/TEST WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (747.70-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 335462400 (319 MB) avail memory = 314515456 (299 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 26 2008 16:08:15) acpi0: on motherboard acpi0: [ITHREAD] acpi0: reservation of 0, 9fc00 (3) failed acpi0: reservation of 10, 13ef (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xec00-0xecff mem 0xfd00-0xfdff,0xfcfff000-0xfcff irq 11 at device 0.0 on pci1 acpi_video0: on vgapci0 drm0: on vgapci0 info: [drm] AGP at 0xf400 64MB info: [drm] Initialized mach64 1.0.0 20020904 cbb0: at device 3.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] cbb1: at device 3.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [ITHREAD] isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x860-0x86f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 8.0 (no driver attached) acpi_tz0: on acpi0 acpi_dock0: on acpi0 acpi_dock0: _EJ0 failed atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc-0xc pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 747704647 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. pccard0: chip_socket_enable pccard0: read_cis cis mem map 0xce95a000 (resource: 0x8800) pccard0: CIS tuple chain: CISTPL_DEVICE type=funcspec speed=100ns 01 03 d4 0a ff CISTPL_DEVICE_A type=eeprom speed=250ns 17 03 41 00 ff CISTPL_MANFID 20 04 49 01 ab c1 CISTPL_VERS_1 15 2c 04 01 46 61 73 74 20 45 74 68 65 72 6e 65 74 00 31 36 2d 62 69 74 20 50 43 20 43 61 72 64 00 33 2e 30 00 41 58 38 38 31 39 30 00 ff CISTPL_CONFIG 1a 05 01 fd c0 03 01 CISTPL_CFTABLE_ENTRY 1b 07 fd 81 18 45 30 fc be CISTPL_CFTABLE_ENTRY 1b 07 05 08 ca 60 00 03 1f CISTPL_CFTABLE_ENTRY 1b 07 0d 08 ca 60 20 03 1f CISTPL_CFTABLE_ENTRY 1b 07 15 08 ca 60 40 03 1f CISTPL_CFTABLE_ENTRY 1b 07 1d 08 ca 60 80 03 1f CISTPL_CFTABLE_ENTRY 1b 07 25 08 ca 60 00 02 1f CISTPL_CFTABLE_ENTRY 1b 07 2d 08 ca 60 20 02 1f CISTPL_CFTABLE_ENTRY 1b 07 35 08 ca 60 40 02 1f CISTPL_FUNCID 21 02 06 00 unhandled CISTPL 14 CISTPL_NO_LINK 14 00 CISTPL_END ff pccard0: check_cis_quirks pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Fast Ethernet, 16-bit PC Card, 3.0, AX88190 pccard0: Manufacturer code 0x149, product 0xc1ab pccard0: function 0: network adapter, ccr addr 3c0 mask 1 pccard0: function 0, config table entry 61: I/O card; irq mask befc; iomask 5, iospace 0-1f; mwait_required io16 irqle
Re: upkhy ed driver problem
looks like somebody took out my bogus filter for mii addresses. Grump. Will track this down. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ieee80211 ms and tu convert macros
I happened to be looking in net80211/ieee80211_var.h and examined the macros IEEE80211_MS_TO_TU and IEEE80211_TU_TO_MS. The conversions seem backward to me. The macros are: #define IEEE80211_MS_TO_TU(x) (((x) * 1000) / 1024) #define IEEE80211_TU_TO_MS(x) (((x) * 1024) / 1000) If I take the values: 1 second = 1000 milliseconds (ms) = 1024 timer units (tu) When I convert 1000 ms, I should get 1024 tu but when I use the macro IEEE80211_MS_TO_TU(1000), I get 976. The current definition yields (1000 * 1000) / 1024 = 976. The macro should be: #define IEEE80211_MS_TO_TU(x) (((x) * 1024) / 1000) This yields IEEE80211_MS_TO_TU(1000) = (1000 * 1024) / 1000 = 1024 The other macro needs a similar change. Am I missing something, interpreting something incorrectly? Please let me know. Paul ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPV6_TCLASS missing from ip6(4)
I just noticed that whilst the socket code appears to support IPV6_TCLASS, we don't document it. I haven't raised a PR for this issue yet nor have I written a patch. This came up when I started hacking support for setting IP_TOS into something else. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple default routes on multihome host
Wes Peters wrote: I see a number of people have replied to this message offering solutions of how to accomplish your migration, using a variety of tools available to you in FreeBSD. I've always found this community very supportive in this fashion, and I'm glad they've jumped in to help you in your transition as well. Please note that the variety of solutions presented recognize that your transition period is just that, a temporary situation, and that "multiple default routes" is not the solution. The thing is, in a peer-to-peer or ad-hoc mesh network, not having access to a single next-hop serving as the gateway of last resort has a much higher probability of occurring than in a fully converged network with more deterministic layer 3 behaviour. So we're largely arguing apples vs oranges here. Fact of the matter is, we can't tell people how to run their networks, or which protocols to run. People want IP everywhere and they want it now. (Infinite demand for free goods is another story.) The argument that functionality "should not" be present because people "should not" run their networks that way carries no water -- particularly so when issues of wireless presence and ad-hoc networks blow the old assumptions out of the water. later BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: traceroute AS path patch
On Feb 19, 2008, at 10:13 PM, Rui Paulo wrote: On Feb 18, 2008, at 10:41 AM, John Hay wrote: Hi Rui, On Sun, Feb 17, 2008 at 09:30:44PM +, Rui Paulo wrote: Hi, The attached patch ports a traceroute functionality from FreeBSD called AS path. The concept is simple. On each hop we query a whois server to find the corresponding hop AS number. I think it doesn't hurt if we have this functionality. An example output: traceroute to freebsd.org (69.147.83.40), 64 hops max, 72 byte packets ... 7 [AS6453] if-2-1.core1.PV9-Lisbon.teleglobe.net (195.219.187.21) 35.105 ms 34.008 ms 35.334 ms 8 [AS6453] 195.219.144.5 (195.219.144.5) 63.880 ms 60.448 ms 60.809 ms 9 [AS6453] 195.219.144.10 (195.219.144.10) 138.593 ms 193.709 ms 173.415 ms 10 [AS7199] if-2-0.core1.NJY-Newark.teleglobe.net (216.6.63.10) 133.912 ms 134.393 ms 144.071 ms 11 [AS9557] if-3-1.mcore3.NJY-Newark.teleglobe.net (216.6.57.1) 135.600 ms 144.979 ms 168.247 ms 12 [AS9557] if-12-0-0-741.core4.AEQ-Ashburn.teleglobe.net (216.6.57.70) 180.346 ms 138.718 ms 138.927 ms 13 [AS6453] 64.86.85.38 (64.86.85.38) 142.745 ms 143.163 ms 143.358 ms 14 [AS26085] so-0-0-0.pat2.pao.yahoo.com (216.115.101.130) 252.417 ms 213.377 ms 212.859 ms 15 [AS26085] ge-0-1-0-p301.pat1.sjc.yahoo.com (216.115.106.147) 214.709 ms 213.198 ms 235.253 ms 16 [AS26085] g-1-0-0-p160.msr1.sp1.yahoo.com (216.115.107.61) 219.091 ms [AS26085] g-0-0-0-p170.msr2.sp1.yahoo.com (216.115.107.81) 217.650 ms [AS26085] g-1-0-0-p160.msr1.sp1.yahoo.com (216.115.107.61) 286.376 ms 17 [AS36752] ge-1-45.bas-b2.sp1.yahoo.com (209.131.32.49) 213.747 ms [AS36752] ge-1-41.bas-b2.sp1.yahoo.com (209.131.32.33) 274.140 ms [AS36752] ge-1-45.bas-b2.sp1.yahoo.com (209.131.32.49) 213.341 ms 18 [AS36752] freebsd.org (69.147.83.40) 214.386 ms 223.515 ms 212.548 ms What do you think? Would it be difficult to add it to traceroute6 too? It would be great if we can keep features in sync. I will try to do it after committing this patch. Just FYI, committed. -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0 & Link-Local Addresses
In 6.2-Rp7: 6.2-Rp7# uname -srm FreeBSD 6.2-RELEASE-p7 i386 6.2-Rp7# ifconfig lo1 create 6.2-Rp7# ifconfig lo1 inet 169.254.1.1 netmask 255.255.0.0 6.2-Rp7# ping -c1 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes 64 bytes from 169.254.1.1: icmp_seq=0 ttl=64 time=0.065 ms --- 169.254.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.065/0.065/0.065/0.000 ms 6.2-Rp7# But in 7.0-RC2: 7.0-RC2# uname -srm FreeBSD 7.0-RC2 amd64 7.0-RC2# ifconfig lo1 create 7.0-RC2# ifconfig lo1 169.254.1.1 netmask 255.255.0.0 7.0-RC2# ping -c1 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes --- 169.254.1.1 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss 7.0-RC2# I'm trying to use link-local for the cross-over interface between a pair of FreeBSD boxes running pf, pfsync, and CARP. These firewalls will need to be able to route for the whole of RFC1918, and carving off a piece of that address space isn't an option. This seemed to be a perfect scenario for link-local addresses until I ran into the above problem. RFC 3927 states, in section 1.6 (Alternate Use Prohibition): "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually" So I'm not sure if this is a bug or just RFC compliance. -Snow ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 & Link-Local Addresses
James Snow wrote: I'm trying to use link-local for the cross-over interface between a pair of FreeBSD boxes running pf, pfsync, and CARP. These firewalls will need to be able to route for the whole of RFC1918, and carving off a piece of that address space isn't an option. This seemed to be a perfect scenario for link-local addresses until I ran into the above problem. RFC 3927 states, in section 1.6 (Alternate Use Prohibition): "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually" So I'm not sure if this is a bug or just RFC compliance. I can't see why you're seeing datagrams to 169.254.1.1 being dropped based on the information you provide. I did introduce some checks into the mainline code which will prohibit the use of link-local addresses for forwarding, these should not affect reception as an endpoint. However, you should be just fine manually configuring 169.254/16 addresses for the time being. Whilst it isn't in accordance with the letter of the RFC as you correctly point out, there are situations where it's useful. The stack does NOT currently support source address selection policies. These were introduced to NetBSD. Currently in FreeBSD, source address selection is based solely on destination address. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPV6_TCLASS missing from ip6(4)
At Wed, 20 Feb 2008 18:25:05 +, Bruce M Simpson wrote: > > I just noticed that whilst the socket code appears to support > IPV6_TCLASS, we don't document it. > > I haven't raised a PR for this issue yet nor have I written a patch. > Please do both :-) Thanks, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
