Re: network freeze with nforce-A939 integrated rhine card
On Thu, 11 May 2006, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB or so of data off of the box to my new server it will run for a while (as little as 1G, as much as 45G) and then the network card will shut down. following up with earlier kernels, this problem persists back as far as 2.6.13. I'll do more testing tomorrow. David Lang - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial benchmarks of some VJ ideas [mmap memcpy vs copy_to_user].
On Thu, May 11, 2006 at 11:54:09AM -0700, David S. Miller ([EMAIL PROTECTED]) wrote: > BTW you make another massively critical error in your analysis of TCP > profiles. > > You mention that "tcp_v4_rcv()" shows up in your profiles and not > __inet_lookup(). This __inet_lookup() is inlined, and thus it's cost > shows up as "tcp_v4_rcv()". I find such oversight amazing for someone > as careful about details as you are :-) Ugh, my fault. But tcp_v4_rcv() also does a lot of other things which more likely pushes this function in profile statistics :) > I would suggest to look at instruction level profile hits, it makes > such mistakes in analysis almost impossible :-) It is much more challenging than running oprofile, so it will be postponed for a while :) -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ethtool always report port is TP on tg3
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
---
drivers/net/tg3.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
5ed8e79c778ee803e44a325a1e15c0cb3f52d0ff
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index beeb612..0b5bc93 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7653,21 +7653,23 @@ static int tg3_get_settings(struct net_d
cmd->supported |= (SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full);
- if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES))
+ if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES)) {
cmd->supported |= (SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_MII);
- else
+ cmd->port = PORT_TP;
+ } else {
cmd->supported |= SUPPORTED_FIBRE;
+ cmd->port = PORT_FIBRE;
+ }
cmd->advertising = tp->link_config.advertising;
if (netif_running(dev)) {
cmd->speed = tp->link_config.active_speed;
cmd->duplex = tp->link_config.active_duplex;
}
- cmd->port = 0;
cmd->phy_address = PHY_ADDR;
cmd->transceiver = 0;
cmd->autoneg = tp->link_config.autoneg;
--
Karsten Keil
SuSE Labs
ISDN development
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux v2.6.17-rc4
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote: > Ok, I've let the release time between -rc's slide a bit too much again, > but -rc4 is out there, and this is the time to hunker down for 2.6.17. > > If you know of any regressions, please holler now, so that we don't miss > them. I got assertion failures in the bcm43xx driver: bcm43xx: Chip ID 0x4318, rev 0x2 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 3, Type 2, Revision 7 bcm43xx: Detected Radio: ID: 8205017f (Manuf: 17f Ver: 2050 Rev: 8) bcm43xx: Radio turned off bcm43xx: Radio turned off bcm43xx: PHY connected bcm43xx: Radio turned on bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair() bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair() bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair() bcm43xx: Chip initialized bcm43xx: DMA initialized bcm43xx: 80211 cores initialized bcm43xx: Keys cleared ADDRCONF(NETDEV_UP): eth2: link is not ready bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair() ieee80211_crypt: registered algorithm 'WEP' Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux v2.6.17-rc4
On Friday 12 May 2006 12:24, you wrote: > On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote: > > Ok, I've let the release time between -rc's slide a bit too much again, > > but -rc4 is out there, and this is the time to hunker down for 2.6.17. > > > > If you know of any regressions, please holler now, so that we don't miss > > them. > > I got assertion failures in the bcm43xx driver: > > bcm43xx: Chip ID 0x4318, rev 0x2 That is expected an non-fatal. It is no regression. We are working on it, but there won't be any fix for 2.6.17, as very intrusive changes are needed to fix this. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Wed, 10 May 2006 13:31:39 -0400, Michael Wu wrote: > I think this is overkill to fix a hack. IMHO, scan_skip_11b shouldn't exist > in > the first place. One alternative would be to modify 802.11g drivers to not > set IEEE80211_CHAN_W_SCAN on 802.11b channels when there are equivalent > 802.11g channels. This won't work when 11g is administratively disabled. We can surely add another flags; but I'm not sure if it is really desirable to require drivers to be aware of this when it is easily determinable by the stack. > It seems like hw_modes is more useful for saying > what modes shouldn't be used than saying what modes are supported by the > hardware and should be used. This is exactly the purpose of hw_modes. This also means you don't need any validation. Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [EMAIL PROTECTED]: Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.]
> This subthread in the Xen patch thread has now digressed onto discussions > about entropy and security. Perhaps you guys could add some points. Well, I can try. I don't think this answers any questions, but perhaps it informs the discussion. Apologies if the Cc: list is getting a bit bloated. > On 11 May 2006, at 01:33, Herbert Xu wrote: >>> But if sampling virtual events for randomness is really unsafe (is it >>> really?) then native guests in Xen would also get bad random numbers >>> and this would need to be somehow addressed. >> >> Good point. I wonder what VMWare does in this situation. > > Well, there's not much they can do except maybe jitter interrupt > delivery. I doubt they do that though. There are two aspects which are often confused. It doesn't sound like people are confused here, but I'll say it explicitly just to make sure: One is the concern that by feeding malicious data into the /dev/random pool, you can control its output. This can't happen; the input mixing is safe against that, which is why /dev/random is globally writeable. Whatever data you feed into the pool, you can't increase your level of knowledge about the state of it. So there is no need whatsoever to stop potentially bad data from being fed into the pool. The worst it can do is nothing. The second, which CAN happen, is an entropy estimation failure. The /dev/random system tries to guess by how much a given piece of input DECREASES an attacker's knowledge about the state of the pool. If it guesses wrong, it can produce output (which gives away information) beyond the limits of the unicity distance and then an attacker with unbounded computational power can figure out the state of the pool and thereby predict future output. Underestimating the entropy is always safe, so adding suspect data is fine as long as you give it a zero entropy score. But you need to find some entropy somewhere or you'll never make any progress. That's where it gets tricky. It's not what seed material you use (use it all), but what seed material do you TRUST? Also, for this second kind of problem, an attacker only has to KNOW what the data being introduced into the pool is (or, to be even more specific, know more about it than the entropy estimate thinks is possible), not control it in any way. Thus, there is no possible test of the input data itself which can prove an attacker's ignorance of it; some assumptions about its origin must be made. /dev/random's main entropy source is interrupt timing, based on the assumption that the real-world I/O devices are driven by sources at least partly uncorrelated with the processor clock. But if the interrupts are virtualized and come from hypervisor software, how unknown to an attacker are they? > The original complaint in our case was that we take entropy from > interrupts caused by other local VMs, as well as external sources. > There was a feeling that the former was more predictable and could form > the basis of an attack. I have to say I'm unconvinced: I don't really > see that it's significantly easier to inject precisely-timed interrupts > into a local VM. Certainly not to better than +/- a few microseconds. > As long as you add cycle-counter info to the entropy pool, the least > significant bits of that will always be noise. It's not a matter if injecting *controlled* interrupts, just *known* interrupts. If the duration of cross-VM interrupt delivery is predictable, an attacker reading the timestamp counter before sending a packet could predict the timestamp on arrival and figure out what's going into the pool. If that's the main source of entropy going in to the target domain and the attacker has a way to read the vast majority of the output of /dev/random there, an attacker has a chance to guess the fraction of /dev/random output they don't see. > The alternatives are unattractive: > 1. We have no good way to distinguish interrupts caused by packets > from local VMs versus packets from remote hosts. Both get muxed on the > same virtual interface. Doesn't the source MAC address offer a clue? > 2. An entropy front/back is tricky -- how do we decide how much > entropy to pull from domain0? How much should domain0 be prepared to > give other domains? How easy is it to DoS domain0 by draining its > entropy pool? Yuk. THAT, at least, is not terribly hard. It's exactly the same sort of fair CPU scheduling problem as has been solved many times before. As entropy comes in, credit it round-robin to various child domains. There's a pool in domain0 which can buffer a certain about of credit for child domains even if they don't want it yet. When that buffered credit reaches the limit that domain0 can store, it spills over and is allocated to other domains with non-full accounts. So after an initial accumulation period to fill up the buffers, the available entropy is divided evenly among all the domains that want it. I don't know how Xen works at all, whether it's
Re: Linux v2.6.17-rc4
On Fri, May 12, Michael Buesch wrote: > On Friday 12 May 2006 12:24, you wrote: > > On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote: > > > Ok, I've let the release time between -rc's slide a bit too much again, > > > but -rc4 is out there, and this is the time to hunker down for 2.6.17. > > > > > > If you know of any regressions, please holler now, so that we don't miss > > > them. > > > > I got assertion failures in the bcm43xx driver: > > > > bcm43xx: Chip ID 0x4318, rev 0x2 > > That is expected an non-fatal. Is this one in the same category? [ 79.087115] bcm43xx: WARNING: Writing invalid LOpair (low: 46, high: 104, index: 123) [0.00] Using PowerMac machine description [0.00] Total memory = 768MB; using 2048kB for hash table (at cfe0) [0.00] Linux version 2.6.17-rc4-airport ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) #3 Fri May 12 13:12:42 CEST 2006 [0.00] Found initrd at 0xc410:0xc445d000 [0.00] Found UniNorth memory controller & host bridge @ 0xf800 revision: 0xd2 [0.00] Mapped at 0xfdfc [0.00] Found a Intrepid mac-io controller, rev: 0, mapped at 0xfdf4 [0.00] Processor NAP mode on idle enabled. [0.00] PowerMac motherboard: iBook G4 [0.00] via-pmu: Server Mode is disabled [0.00] PMU driver v2 initialized for Core99, firmware: 0c [0.00] Found UniNorth PCI host bridge at 0xf000. Firmware bus number: 0->0 [0.00] Found UniNorth PCI host bridge at 0xf200. Firmware bus number: 0->0 [0.00] Found UniNorth PCI host bridge at 0xf400. Firmware bus number: 0->0 [0.00] Top of RAM: 0x3000, Total RAM: 0x3000 [0.00] Memory hole size: 0MB [0.00] On node 0 totalpages: 196608 [0.00] DMA zone: 196608 pages, LIFO batch:31 [0.00] Built 1 zonelists [0.00] Kernel command line: root=/dev/hda2 quiet time sysrq=1 [0.00] mpic: Setting up MPIC " MPIC 1 " version 1.2 at 8004, max 4 CPUs [0.00] mpic: ISU size: 64, shift: 6, mask: 3f [0.00] mpic: Initializing for 64 sources [0.00] PID hash table entries: 4096 (order: 12, 16384 bytes) [0.00] time_init: decrementer frequency = 18.432000 MHz [0.00] time_init: processor frequency = 1333.30 MHz [ 23.809911] Console: colour dummy device 80x25 [ 23.810822] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 23.812165] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 23.854228] Memory: 767232k/786432k available (3160k kernel code, 18664k reserved, 448k data, 2177k bss, 160k init) [ 23.854480] Calibrating delay loop... 36.76 BogoMIPS (lpj=183808) [ 24.039729] Mount-cache hash table entries: 512 [ 24.040130] device-tree: Duplicate name in /cpus/PowerPC,[EMAIL PROTECTED], renamed to "l2-cache#1" [ 24.043262] checking if image is initramfs... it is [ 24.734182] Freeing initrd memory: 3444k freed [ 24.735401] NET: Registered protocol family 16 [ 24.736061] KeyWest i2c @0xf8001003 irq 42 /[EMAIL PROTECTED]/[EMAIL PROTECTED] [ 24.736074] channel 1 bus /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] [ 24.736123] KeyWest i2c @0x80018000 irq 26 /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] [ 24.736134] channel 0 bus /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] [ 24.736161] PMU i2c /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/pmu-i2c [ 24.736169] channel 1 bus [ 24.736176] channel 2 bus [ 24.736706] PCI: Probing PCI hardware [ 24.739527] PCI: Cannot allocate resource region 0 of device 0001:10:18.0 [ 24.739549] PCI: Cannot allocate resource region 0 of device 0001:10:19.0 [ 24.739583] Apple USB OHCI 0001:10:18.0 disabled by firmware [ 24.739596] Apple USB OHCI 0001:10:19.0 disabled by firmware [ 24.740556] usbcore: registered new driver usbfs [ 24.740655] usbcore: registered new driver hub [ 24.740917] TC classifier action (bugs to netdev@vger.kernel.org cc [EMAIL PROTECTED]) [ 24.741608] NET: Registered protocol family 2 [ 24.829781] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 24.830282] TCP established hash table entries: 131072 (order: 9, 2097152 bytes) [ 24.839978] TCP bind hash table entries: 65536 (order: 8, 1310720 bytes) [ 24.846243] TCP: Hash tables configured (established 131072 bind 65536) [ 24.846253] TCP reno registered [ 24.846361] Thermal assist unit not available [ 24.848508] VFS: Disk quotas dquot_6.5.1 [ 24.848561] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 24.848760] Initializing Cryptographic API [ 24.848777] io scheduler noop registered [ 24.848792] io scheduler anticipatory registered [ 24.848806] io scheduler deadline registered [ 24.848833] io scheduler cfq registered (default) [ 24.849393] PCI: Enabling device :00:10.0 (0006 -> 0007) [ 25.045487] rad
Re: Linux v2.6.17-rc4
On Fri, May 12, 2006 at 12:44:22PM +0200, Michael Buesch wrote: > On Friday 12 May 2006 12:24, you wrote: > > On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote: > > > Ok, I've let the release time between -rc's slide a bit too much again, > > > but -rc4 is out there, and this is the time to hunker down for 2.6.17. > > > > > > If you know of any regressions, please holler now, so that we don't miss > > > them. > > > > I got assertion failures in the bcm43xx driver: > > > > bcm43xx: Chip ID 0x4318, rev 0x2 > > That is expected an non-fatal. Assertion failed sounds rather fatal to me. > It is no regression. It is, I didn't see it in 2.6.17-rc3. > We are working on it, but there won't be any fix for 2.6.17, as > very intrusive changes are needed to fix this. If it's non-fatal, could you remove the assertion, or make it print something that sounds less fatal? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110
This time I checked more carefully my changeset and split it into
smaller parts. Few of my patches was tested by OpenZaurus users, some
are waiting for testing.
We switched to pcmciautils when moved to 2.6.16 and many users complain
that their WiFi CompactFlash cards are driven by orinoco instead of
hostap.
BTW - how to force using of hostap_cs when both hostap_cs and orinoco_cs
has card in device table?
All patches require 24_hostap_cs_id.diff from Pavel Roskin.
I'm subscribed to netdev mailing list now.
---
Here's another card that would benefit from a hostap driver: ASUS WL-110
Platform: HP Ipaq hx4700 running 2.6.16-hh
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "ASUS", "802_11B_CF_CARD_25", "Version 01.00", ""
manfid: 0x02aa, 0x0002
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0C:6E:F0:DA:CD
inet addr:172.20.0.3 Bcast:172.20.255.255 Mask:255.255.0.0
inet6 addr: 2001:610:600:93:20c:6eff:fef0:dacd/64 Scope:Global
inet6 addr: fe80::20c:6eff:fef0:dacd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:158 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17978 (17.5 KiB) TX bytes:11424 (11.1 KiB)
Interrupt:92
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/orinoco_cs.c
===
--- linux.orig/drivers/net/wireless/orinoco_cs.c2006-05-12
15:02:13.0 +0200
+++ linux/drivers/net/wireless/orinoco_cs.c 2006-05-12 15:03:31.0
+0200
@@ -533,7 +533,6 @@
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613), /* Linksys WPC11 Version 3 */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002), /* Compaq HNW-100 11 Mbps
Wireless Adapter */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless
CompactFlash Card */
- PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002), /* ASUS SpaceLink WL-100 */
PCMCIA_DEVICE_MANF_CARD(0x02ac, 0x0002), /* SpeedStream SS1021 Wireless
Adapter */
PCMCIA_DEVICE_MANF_CARD(0x14ea, 0xb001), /* PLANEX RoadLannerWave
GW-NS11H */
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300), /* Airvast WN-100 */
@@ -548,8 +547,6 @@
PCMCIA_DEVICE_PROD_ID12("Addtron", "AWP-100 Wireless PCMCIA",
0xe6ec52ce, 0x08649af2),
PCMCIA_DEVICE_PROD_ID123("AIRVAST", "IEEE 802.11b Wireless PCMCIA
Card", "HFA3863", 0xea569531, 0x4bcb9645, 0x355cb092),
PCMCIA_DEVICE_PROD_ID12("Allied Telesyn", "AT-WCL452 Wireless PCMCIA
Radio", 0x5cd01705, 0x4271660f),
- PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25", 0x78fc06ee,
0xdb9aa842),
- PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25", 0x78fc06ee,
0x45a50c1e),
PCMCIA_DEVICE_PROD_ID12("Avaya Communication", "Avaya Wireless PC
Card", 0xd8a43b78, 0x0d341169),
PCMCIA_DEVICE_PROD_ID12("BENQ", "AWL100 PCMCIA ADAPTER", 0x35dadc74,
0x01f7fedb),
PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-PCM-L11G", 0x2decece3,
0xf57ca4b3),
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:02:51.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:06:26.0 +0200
@@ -935,6 +935,8 @@
PCMCIA_DEVICE_PROD_ID123(
"U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02",
0xc7b8df9d, 0x1700d087, 0x4b74baa0),
+ PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version
01.00", ""
+ 0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25",
0x78fc06ee, 0xdb9aa842),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25",
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
So when I die, the first thing I will see in Heaven is a hi-score list?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110 (FIXED)
This time I checked more carefully my changeset and split it into
smaller parts. Few of my patches was tested by OpenZaurus users, some
are waiting for testing.
We switched to pcmciautils when moved to 2.6.16 and many users complain
that their WiFi CompactFlash cards are driven by orinoco instead of
hostap.
BTW - how to force using of hostap_cs when both hostap_cs and orinoco_cs
has card in device table?
All patches require 24_hostap_cs_id.diff from Pavel Roskin.
I'm subscribed to netdev mailing list now.
---
Here's another card that would benefit from a hostap driver: ASUS WL-110
Platform: HP Ipaq hx4700 running 2.6.16-hh
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "ASUS", "802_11B_CF_CARD_25", "Version 01.00", ""
manfid: 0x02aa, 0x0002
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0C:6E:F0:DA:CD
inet addr:172.20.0.3 Bcast:172.20.255.255 Mask:255.255.0.0
inet6 addr: 2001:610:600:93:20c:6eff:fef0:dacd/64 Scope:Global
inet6 addr: fe80::20c:6eff:fef0:dacd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:158 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17978 (17.5 KiB) TX bytes:11424 (11.1 KiB)
Interrupt:92
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/orinoco_cs.c
===
--- linux.orig/drivers/net/wireless/orinoco_cs.c2006-05-12
15:02:13.0 +0200
+++ linux/drivers/net/wireless/orinoco_cs.c 2006-05-12 15:03:31.0
+0200
@@ -533,7 +533,6 @@
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613), /* Linksys WPC11 Version 3 */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002), /* Compaq HNW-100 11 Mbps
Wireless Adapter */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless
CompactFlash Card */
- PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002), /* ASUS SpaceLink WL-100 */
PCMCIA_DEVICE_MANF_CARD(0x02ac, 0x0002), /* SpeedStream SS1021 Wireless
Adapter */
PCMCIA_DEVICE_MANF_CARD(0x14ea, 0xb001), /* PLANEX RoadLannerWave
GW-NS11H */
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300), /* Airvast WN-100 */
@@ -548,8 +547,6 @@
PCMCIA_DEVICE_PROD_ID12("Addtron", "AWP-100 Wireless PCMCIA",
0xe6ec52ce,
0x08649af2),
PCMCIA_DEVICE_PROD_ID123("AIRVAST", "IEEE 802.11b Wireless PCMCIA
Card", "HFA3863", 0xea569531, 0x4bcb9645, 0x355cb092),
PCMCIA_DEVICE_PROD_ID12("Allied Telesyn", "AT-WCL452 Wireless PCMCIA
Radio", 0x5cd01705, 0x4271660f),
- PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25", 0x78fc06ee,
0xdb9aa842),
- PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25", 0x78fc06ee,
0x45a50c1e),
PCMCIA_DEVICE_PROD_ID12("Avaya Communication", "Avaya Wireless PC
Card",
0xd8a43b78, 0x0d341169),
PCMCIA_DEVICE_PROD_ID12("BENQ", "AWL100 PCMCIA ADAPTER", 0x35dadc74,
0x01f7fedb),
PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-PCM-L11G", 0x2decece3,
0xf57ca4b3),
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:02:51.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:06:26.0 +0200
@@ -935,6 +935,8 @@
PCMCIA_DEVICE_PROD_ID123(
"U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02",
0xc7b8df9d, 0x1700d087, 0x4b74baa0),
+ PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version
01.00", "",
+ 0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25",
0x78fc06ee, 0xdb9aa842),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25",
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
So when I die, the first thing I will see in Heaven is a hi-score list?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] new pcmcia IDs for hostap - Linksys WCF12
Not sure about removing this card from orinoco driver and should I add
PCMCIA_DEVICE_MANF_CARD or does PCMCIA_DEVICE_PROD_ID* is enough.
---
Here's another card that would benefit from a hostap driver:
Platform: Sharp Zaurus SL-C3100 running 2.6.16 + pcmciautils 013
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "HITACHI", "microdrive", "", ""
manfid: 0x0319, 0x
function: 4 (fixed disk)
Socket 1:
product info: "Linksys", "Wireless CompactFlash Card", "", ""
manfid: 0x028a, 0x0673
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0C:41:15:BB:0F
inet addr:192.168.0.225 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:41ff:fe15:bb0f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:242 errors:0 dropped:0 overruns:0 frame:0
TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22627 (22.0 KiB) TX bytes:28096 (27.4 KiB)
Interrupt:137
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:34:25.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:34:59.0 +0200
@@ -884,6 +884,7 @@
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1612),
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613),
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless
CompactFlash Card */
PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002),
PCMCIA_DEVICE_MANF_CARD(0x02d2, 0x0001),
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x0001),
@@ -971,6 +972,8 @@
PCMCIA_DEVICE_PROD_ID12(
"ZoomAir 11Mbps High", "Rate wireless Networking",
0x273fe3db, 0x32a1eaee),
+ PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card",
+ 0x0733cc81, 0x0c52f395),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
Index: linux/drivers/net/wireless/orinoco_cs.c
===
--- linux.orig/drivers/net/wireless/orinoco_cs.c2006-05-12
15:03:31.0 +0200
+++ linux/drivers/net/wireless/orinoco_cs.c 2006-05-12 15:34:49.0
+0200
@@ -532,7 +532,6 @@
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1612), /* Linksys WPC11 Version 2.5 */
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613), /* Linksys WPC11 Version 3 */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002), /* Compaq HNW-100 11 Mbps
Wireless Adapter */
- PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless
CompactFlash Card */
PCMCIA_DEVICE_MANF_CARD(0x02ac, 0x0002), /* SpeedStream SS1021 Wireless
Adapter */
PCMCIA_DEVICE_MANF_CARD(0x14ea, 0xb001), /* PLANEX RoadLannerWave
GW-NS11H */
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300), /* Airvast WN-100 */
@@ -570,7 +569,6 @@
PCMCIA_DEVICE_PROD_ID12("Intersil", "PRISM 2_5 PCMCIA ADAPTER",
0x4b801a17, 0x6345a0bf),
PCMCIA_DEVICE_PROD_ID123("Intersil", "PRISM Freedom PCMCIA Adapter",
"ISL37100P", 0x4b801a17, 0xf222ec2d, 0x630d52b2),
PCMCIA_DEVICE_PROD_ID12("LeArtery", "SYNCBYAIR 11Mbps Wireless LAN PC
Card", 0x7e3b326a, 0x49893e92),
- PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card",
0x0733cc81, 0x0c52f395),
PCMCIA_DEVICE_PROD_ID12("Lucent Technologies", "WaveLAN/IEEE",
0x23eb9949, 0xc562e72a),
PCMCIA_DEVICE_PROD_ID12("MELCO", "WLI-PCM-L11", 0x481e0094, 0x7360e410),
PCMCIA_DEVICE_PROD_ID12("MELCO", "WLI-PCM-L11G", 0x481e0094,
0xf57ca4b3),
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
Real programmers don't document.
If it was hard to write, it should be hard to understand.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] new pcmcia IDs for hostap - D-Link DCF-660W
I use D-Link DCF-660W card with WPA protected network. By default
orinoco_cs was loaded for my card so I was not able to connect. This patch
make my card working with hostap_cs (like it was when I used pcmcia-cs).
Card was used with hostap_cs during last year in two Zaurus models (2.4.18
on one and 2.6.11 - 2.6.16 on another).
I do not know does removing card from orinoco_cs is correct way.
Platform: Sharp Zaurus C760 running 2.6.16 and pcmciautils 013.
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "D-Link", "DCF-660W", "", ""
manfid: 0xd601, 0x0005
function: 6 (network)
[EMAIL PROTECTED]:~# iwconfig wlan0
wlan0 IEEE 802.11b ESSID:"test"
Mode:Master Frequency:2.422 GHz Access Point: 00:80:C8:2C:09:3F
Bit Rate:11 Mb/s Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:36:08.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:43:36.0 +0200
@@ -974,6 +974,8 @@
0x273fe3db, 0x32a1eaee),
PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card",
0x0733cc81, 0x0c52f395),
+ PCMCIA_DEVICE_PROD_ID12("D-Link", "DCF-660W",
+ 0x1a424a1c, 0xe78b6dcc),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
Index: linux/drivers/net/wireless/orinoco_cs.c
===
--- linux.orig/drivers/net/wireless/orinoco_cs.c2006-05-12
15:34:49.0 +0200
+++ linux/drivers/net/wireless/orinoco_cs.c 2006-05-12 15:42:32.0
+0200
@@ -539,7 +539,6 @@
PCMCIA_DEVICE_MANF_CARD(0xc001, 0x0008), /* CONTEC
FLEXSCAN/FX-DDS110-PCC */
PCMCIA_DEVICE_MANF_CARD(0xc250, 0x0002), /* Conceptronic CON11Cpro,
EMTAC A2424i */
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0002), /* Safeway 802.11b, ZCOMAX
AirRunner/XI-300 */
- PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0005), /* D-Link DCF660, Sandisk
Connect SDWCFB-000 */
PCMCIA_DEVICE_PROD_ID12(" ", "IEEE 802.11 Wireless LAN/PC Card",
0x3b6e20c8, 0xefccafe9),
PCMCIA_DEVICE_PROD_ID12("3Com", "3CRWE737A AirConnect Wireless LAN PC
Card", 0x41240e5b, 0x56010af3),
PCMCIA_DEVICE_PROD_ID12("ACTIONTEC", "PRISM Wireless LAN PC Card",
0x393089da, 0xa71e69d5),
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
Fear leads to anger, anger leads to hate, hate... leads to suffering.
-- Yoda
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] new pcmcia IDs for hostap - Netgear MA701
One more Prism2 card which works with HostAP.
Platform: Sharp Zaurus SL-5500 running 2.4.18 + hostap_cs 0.4.7
[EMAIL PROTECTED]:~# cardctl ident
Socket 0:
product info: "NETGEAR", "MA701 Wireless CF Card", ""
manfid: 0xd601, 0x0002
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0F:B5:DE:41:CE
inet addr:135.82.8.139 Bcast:135.82.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7449 (7.2 KiB) TX bytes:7250 (7.0 KiB)
Interrupt:35
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:43:36.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:46:35.0 +0200
@@ -976,6 +976,8 @@
0x0733cc81, 0x0c52f395),
PCMCIA_DEVICE_PROD_ID12("D-Link", "DCF-660W",
0x1a424a1c, 0xe78b6dcc),
+ PCMCIA_DEVICE_PROD_ID12("NETGEAR", "MA701 Wireless CF Card",
+ 0x9aa79dc3, 0xd9ec98e),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
Monday is a hard way to spend one-seventh of your life.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] new pcmcia IDs for hostap - Planex GW-CF11X
Platform: Sharp Zaurus SL-C3100 running 2.6.16 + pcmciautils 013
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "HITACHI", "microdrive", "", ""
manfid: 0x0319, 0x
function: 4 (fixed disk)
Socket 1:
product info:"PLANEX COMMUNICATION INC","PLANEX GW-CF11X Wireless CF Card",
"", ""
manfid: 0xd601, 0x0010
function: 6 ( network )
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:46:35.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:48:54.0 +0200
@@ -967,6 +967,9 @@
0x4ac44287, 0x235a6bed),
PCMCIA_DEVICE_PROD_ID12("PLANEX", "GeoWave/GW-CF110",
0x209f40ab, 0xd9715264),
+ PCMCIA_DEVICE_PROD_ID12("PLANEX COMMUNICATION INC",
+ "PLANEX GW-CF11X Wireless CF Card",
+ 0x4703cf68, 0xfad7318d),
PCMCIA_DEVICE_PROD_ID12("PLANEX", "GeoWave/GW-NS110",
0x209f40ab, 0x46263178),
PCMCIA_DEVICE_PROD_ID12(
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
That must be wonderful! I don understand it at all.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge driver oops
On Fri, 12 May 2006 11:36:24 +1000 "David Arnold" <[EMAIL PROTECTED]> wrote: > i've been getting semi-regular lockups on my machine over 2.6.16 > series. I recently attached a serial console in an attempt to capture > an OOPS. > > i got one yesterday. it's copied manually from the console, but > hopefully the values are all accurate. there was more that had scrolled > off screen above this too (sorry). > > oops, lspci, uname -a, .config and dmesg below. > > any suggestions for further debugging would be great, > > thanks, Could you retest with the v1.5 version that is 2.6.17-rc3? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool always report port is TP on tg3
On Fri, 2006-05-12 at 12:05 +0200, Karsten Keil wrote: > Even with fiber cards ethtool reports that the connected port is TP, > the patch fix this. ACK. Thanks. Please add sign-off line and send to DaveM. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110
Marcin Juszkiewicz wrote :
>
> This time I checked more carefully my changeset and split it into
> smaller parts. Few of my patches was tested by OpenZaurus users, some
> are waiting for testing.
I'm sorry, but I will have again to veto part of your patch.
You are removing IDs from the Orinoco driver. Please don't do
that, those card work perfectly with the orinoco driver, and some of
us run them with the orinoco driver (orinoco is one third the
footprint of hostap).
> We switched to pcmciautils when moved to 2.6.16 and many users complain
> that their WiFi CompactFlash cards are driven by orinoco instead of
> hostap.
>
> BTW - how to force using of hostap_cs when both hostap_cs and orinoco_cs
> has card in device table?
The overall architecture of hotplug/udev module loading is
broken as it does not allow user override. I have explained in details
the problem to the concerned people, but it seems that they don't
really care. The standard answer is "blacklist the orinoco
module". Let's not even mention libusual.
> --- linux.orig/drivers/net/wireless/orinoco_cs.c 2006-05-12
> 15:02:13.0 +0200
> +++ linux/drivers/net/wireless/orinoco_cs.c 2006-05-12 15:03:31.0
> +0200
> @@ -533,7 +533,6 @@
> PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613), /* Linksys WPC11 Version 3 */
> PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002), /* Compaq HNW-100 11 Mbps
> Wireless Adapter \
> */ PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless
> CompactFlash \
> Card */
> - PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002), /* ASUS SpaceLink WL-100 */
> PCMCIA_DEVICE_MANF_CARD(0x02ac, 0x0002), /* SpeedStream SS1021 Wireless
> Adapter */
> PCMCIA_DEVICE_MANF_CARD(0x14ea, 0xb001), /* PLANEX RoadLannerWave
> GW-NS11H */
> PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300), /* Airvast WN-100 */
> @@ -548,8 +547,6 @@
> PCMCIA_DEVICE_PROD_ID12("Addtron", "AWP-100 Wireless PCMCIA",
> 0xe6ec52ce, \
> 0x08649af2), PCMCIA_DEVICE_PROD_ID123("AIRVAST", "IEEE 802.11b Wireless
> PCMCIA \
> Card", "HFA3863", 0xea569531, 0x4bcb9645, 0x355cb092), \
> PCMCIA_DEVICE_PROD_ID12("Allied Telesyn", "AT-WCL452 Wireless PCMCIA Radio", \
> 0x5cd01705, 0x4271660f),
> - PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25", 0x78fc06ee,
> 0xdb9aa842),
> - PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25", 0x78fc06ee,
> 0x45a50c1e),
> PCMCIA_DEVICE_PROD_ID12("Avaya Communication", "Avaya Wireless PC
> Card", \
> 0xd8a43b78, 0x0d341169), PCMCIA_DEVICE_PROD_ID12("BENQ", "AWL100 PCMCIA
> ADAPTER", \
> 0x35dadc74, 0x01f7fedb), PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-PCM-L11G", \
> 0x2decece3, 0xf57ca4b3),
Please do *NOT* remove those IDs from the Orinoco driver. The
Orinoco driver do support those devices properly.
Regards,
Jean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] new pcmcia IDs for hostap - Linksys WCF12
Dnia piątek, 12 maja 2006 15:40, Marcin Juszkiewicz napisał:
> Not sure about removing this card from orinoco driver and should I add
> PCMCIA_DEVICE_MANF_CARD or does PCMCIA_DEVICE_PROD_ID* is enough.
Updated to not touch orinoco_cs driver.
---
Here's another card that would benefit from a hostap driver:
Platform: Sharp Zaurus SL-C3100 running 2.6.16 + pcmciautils 013
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "HITACHI", "microdrive", "", ""
manfid: 0x0319, 0x
function: 4 (fixed disk)
Socket 1:
product info: "Linksys", "Wireless CompactFlash Card", "", ""
manfid: 0x028a, 0x0673
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0C:41:15:BB:0F
inet addr:192.168.0.225 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:41ff:fe15:bb0f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:242 errors:0 dropped:0 overruns:0 frame:0
TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22627 (22.0 KiB) TX bytes:28096 (27.4 KiB)
Interrupt:137
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:34:25.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:34:59.0 +0200
@@ -884,6 +884,7 @@
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1612),
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613),
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless
CompactFlash Card */
PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002),
PCMCIA_DEVICE_MANF_CARD(0x02d2, 0x0001),
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x0001),
@@ -971,6 +972,8 @@
PCMCIA_DEVICE_PROD_ID12(
"ZoomAir 11Mbps High", "Rate wireless Networking",
0x273fe3db, 0x32a1eaee),
+ PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card",
+ 0x0733cc81, 0x0c52f395),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Palmtop: Sharp Zaurus C760
OpenEmbedded/OpenZaurus developer
Reality is for people who cannot cope with science fiction.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110
Dnia piątek, 12 maja 2006 18:57, Jean Tourrilhes napisał:
> Marcin Juszkiewicz wrote :
> I'm sorry, but I will have again to veto part of your patch.
> You are removing IDs from the Orinoco driver. Please don't do
> that, those card work perfectly with the orinoco driver, and some of
> us run them with the orinoco driver (orinoco is one third the
> footprint of hostap).
Ok - I will update all patches to not doing this.
Thx for answers.
--
Here's another card that would benefit from a hostap driver:
Platform: HP Ipaq hx4700 running 2.6.16-hh
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "ASUS", "802_11B_CF_CARD_25", "Version 01.00", ""
manfid: 0x02aa, 0x0002
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0C:6E:F0:DA:CD
inet addr:172.20.0.3 Bcast:172.20.255.255 Mask:255.255.0.0
inet6 addr: 2001:610:600:93:20c:6eff:fef0:dacd/64 Scope:Global
inet6 addr: fe80::20c:6eff:fef0:dacd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:158 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17978 (17.5 KiB) TX bytes:11424 (11.1 KiB)
Interrupt:92
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:02:51.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:31:07.0 +0200
@@ -935,6 +935,8 @@
PCMCIA_DEVICE_PROD_ID123(
"U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02",
0xc7b8df9d, 0x1700d087, 0x4b74baa0),
+ PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version
01.00", "",
+ 0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25",
0x78fc06ee, 0xdb9aa842),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25",
--
JID: hrw-jabber.org
Palmtop: Sharp Zaurus C760
OpenEmbedded/OpenZaurus developer
We are the Knights who say: MOVE.L USP,A1
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] new pcmcia IDs for hostap - D-Link DCF-660W
Updated to not touch orinoco_cs driver.
---
I use D-Link DCF-660W card with WPA protected network. By default
orinoco_cs was loaded for my card so I was not able to connect. This patch
make my card working with hostap_cs (like it was when I used pcmcia-cs).
Card was used with hostap_cs during last year in two Zaurus models (2.4.18
on one and 2.6.11 - 2.6.16 on another).
I do not know does removing card from orinoco_cs is correct way.
Platform: Sharp Zaurus C760 running 2.6.16 and pcmciautils 013.
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: "D-Link", "DCF-660W", "", ""
manfid: 0xd601, 0x0005
function: 6 (network)
[EMAIL PROTECTED]:~# iwconfig wlan0
wlan0 IEEE 802.11b ESSID:"test"
Mode:Master Frequency:2.422 GHz Access Point: 00:80:C8:2C:09:3F
Bit Rate:11 Mb/s Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:36:08.0 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-12
15:43:36.0 +0200
@@ -974,6 +974,8 @@
0x273fe3db, 0x32a1eaee),
PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card",
0x0733cc81, 0x0c52f395),
+ PCMCIA_DEVICE_PROD_ID12("D-Link", "DCF-660W",
+ 0x1a424a1c, 0xe78b6dcc),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Palmtop: Sharp Zaurus C760
OpenEmbedded/OpenZaurus developer
Woda, której dotykasz w rzekach, jest ostatkiem tej, która przeszła
i początkiem tej, która przyjdzie: tak samo teraźniejszość.
-- Leonardo da Vinci
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool always report port is TP on tg3
On Fri, May 12, 2006 at 07:59:54AM -0700, Michael Chan wrote:
>
> ACK. Thanks. Please add sign-off line and send to DaveM.
This time with Signed-off line.
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
Signed-off-by: Karsten Keil <[EMAIL PROTECTED]>
---
drivers/net/tg3.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
5ed8e79c778ee803e44a325a1e15c0cb3f52d0ff
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index beeb612..0b5bc93 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7653,21 +7653,23 @@ static int tg3_get_settings(struct net_d
cmd->supported |= (SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full);
- if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES))
+ if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES)) {
cmd->supported |= (SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_MII);
- else
+ cmd->port = PORT_TP;
+ } else {
cmd->supported |= SUPPORTED_FIBRE;
+ cmd->port = PORT_FIBRE;
+ }
cmd->advertising = tp->link_config.advertising;
if (netif_running(dev)) {
cmd->speed = tp->link_config.active_speed;
cmd->duplex = tp->link_config.active_duplex;
}
- cmd->port = 0;
cmd->phy_address = PHY_ADDR;
cmd->transceiver = 0;
cmd->autoneg = tp->link_config.autoneg;
--
Karsten Keil
SuSE Labs
ISDN development
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] myri10ge - First half of the driver
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Fri, 12 May 2006 10:47:11 +0400 > On Fri, May 12, 2006 at 01:53:44AM +0200, Brice Goglin ([EMAIL PROTECTED]) > wrote: > > > Imho you will want to work directly with pages shortly. > > > > > > > We had thought about doing this, but were a little nervous since we did > > not know of any other drivers that worked directly with pages. If this > > is an official direction to work directly with pages, we will. > > s2io does. e1000 does it with skb frags. > If your hardware allows header split and driver can put headers into > skb->data and real data into frag_list, that allows to create various > interesting things like receiving zero-copy support and netchannels > support. It is work in progress, not official direction currently, > but this definitely will help your driver to support future high > performance extensions. The most important impact is not having to use order 1 pages for jumbo MTU frames, which are more likely to fail allocations thant order 0 pages under heavy load. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool always report port is TP on tg3
From: Karsten Keil <[EMAIL PROTECTED]> Date: Fri, 12 May 2006 19:46:23 +0200 > Even with fiber cards ethtool reports that the connected port is TP, > the patch fix this. > > Signed-off-by: Karsten Keil <[EMAIL PROTECTED]> Applied, thanks a lot Karsten. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] expose simplified skb_checksum_recalc
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 11 May 2006 11:28:43 -0700 > Many users of skb_checksum_help() are just using it to recalculate > outbound checksum, so why not expose the interface in a more useful > way. Suggested by Ingo Oeser. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Since you will be adding the first users of skb_checksum_recalc(), feel free to push this change in via your net driver tree whenever you feel it is appropriate Stephen. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: add missing operstates.txt
On Sun, 7 May 2006 12:18:59 +0200 Stefan Rompf wrote: > Hi, > > seems documentation got lost when the RFC2863-patch was applied. Having > documentation is good, so I resend it ;-) I have a few comments/questions about this. > --- /dev/null 2005-03-19 20:36:14.0 +0100 > +++ linux-2.6.17-rc3/Documentation/networking/operstates.txt 2006-04-27 > 22:15:23.0 +0200 > @@ -0,0 +1,161 @@ > + > +1. Introduction > + > +Linux distinguishes between administrative and operational state of an > +interface. Admininstrative state is the result of "ip link set dev > + up or down" and reflects whether the administrator wants to use > +the device for traffic. > + > +However, an interface is not usable just because the admin enabled it Put hyphen/dash at end of previous line, not on next line. > +- ethernet requires to be plugged into the switch and, depending on 2 small items here, one grammar and the other is that 'switch' isn't always the link partner device. so maybe: ethernet requires a physical link partner and, depending on > +a site's networking policy and configuration, an 802.1X authentication > +to be performed before user data can be transferred. Operational state > +shows the ability of an interface to transmit this user data. > + > +Thanks to 802.1X, userspace must be granted the possibility to > +influence operational state. To accommodate this, operational state is > +split into two parts: Two flags that can be set by the driver only, and > +a RFC2863 compatible state that is derived from these flags, a policy, > +and changeable from userspace under certain rules. > + > + > +2. Querying from userspace > + > +Both admin and operational state can be queried via the netlink > +operation RTM_GETLINK. It is also possible to subscribe to RTMGRP_LINK > +to be notified of updates. This is important for setting from userspace. > + > +These values contain interface state: > + > +ifinfomsg::if_flags & IFF_UP: > + Interface is admin up > +ifinfomsg::if_flags & IFF_RUNNING: > + Interface is in RFC2863 operational state UP or UNKNOWN. This is for > + backward compatibility, routing daemons, dhcp clients can use this > + flag to determine whether they should use the interface. > +ifinfomsg::if_flags & IFF_LOWER_UP: > + Driver has signaled netif_carrier_on() > +ifinfomsg::if_flags & IFF_DORMANT: > + Driver has signaled netif_dormant_on() Could above list have more spacing added for readability? > +These interface flags can also be queried without netlink using the > +SIOCGIFFLAGS ioctl. > + > +TLV IFLA_OPERSTATE > + > +contains RFC2863 state of the interface in numeric representation: > + > +IF_OPER_UNKNOWN (0): > + Interface is in unknown state, neither driver nor userspace has set > + operational state. Interface must be considered for user data as > + setting operational state has not been implemented in every driver. > +IF_OPER_NOTPRESENT (1): > + Unused in current kernel (notpresent interfaces normally disappear), > + just a numerical placeholder. > +IF_OPER_DOWN (2): > + Interface is unable to transfer data on L1, f.e. ethernet is not > + plugged or interface is ADMIN down. maybe: ethernet is not plugged in or ethernet is not connected or ethernet is not physically connected Also, is "f.e." well known to mean "for example"? I think that I see "e.g." more often than "f.e." and I prefer "e.g.". > +IF_OPER_LOWERLAYERDOWN (3): > + Interfaces stacked on an interface that is IF_OPER_DOWN show this > + state (f.e. VLAN). > +IF_OPER_TESTING (4): > + Unused in current kernel. > +IF_OPER_DORMANT (5): > + Interface is L1 up, but waiting for an external event, f.e. for a > + protocol to establish. (802.1X) > +IF_OPER_UP (6): > + Interface is operational up and can be used. > + > +This TLV can also be queried via sysfs. What is "TLV"? > +TLV IFLA_LINKMODE > + > +contains link policy. This is needed for userspace interaction > +described below. > + > +This TLV can also be queried via sysfs. > + > + > +3. Kernel driver API > + > +Kernel drivers have access to two flags that map to IFF_LOWER_UP and > +IFF_DORMANT. These flags can be set from everywhere, even from > +interrupts. It is guaranteed that only the driver has write access, > +however, if different layers of the driver manipulate the same flag, > +the driver has to provide the synchronisation needed. > + > +__LINK_STATE_NOCARRIER, maps to !IFF_LOWER_UP: > + > +The driver uses netif_carrier_on() to clear and netif_carrier_off() to > +set this flag. On netif_carrier_off(), the scheduler stops sending > +packets. The name 'carrier' and the inversion are historical, think of > +it as lower layer. > + > +netif_carrier_ok() can be used to query that bit. > + > +__LINK_STATE_DORMANT, maps to IFF_DORMANT: > + > +Set by the driver to express that the device cannot yet be used > +because some driver controlled protocol establishment has to > +complete. Corresponding functions are netif_dormant_on() to set the > +flag, netif_dormant_off() to clear it and
OOPS in forcedeth
Hi, I just saw this last night when my desktop was shutting down. Not all the OOPS was outputted, but I've found where it happens. in forcedeth.c:1583 we see: pci_unmap_single(np->pci_dev, np->rx_dma[i], np->rx_skbuff[i]->end-np->rx_skbuff[i]->data, PCI_DMA_FROMDEVICE); The assembler output is: movslq %r12d,%rcx # i, i xorl%edi, %edi # tmp226 movq320(%rbp,%rcx,8), %rax # .rx_skbuff, D.20431 movq1344(%rbp,%rcx,8), %rsi # .rx_dma, addr OOPS--->movq216(%rax), %rdx # .end, .end subq200(%rax), %rdx # .data, .end movq256(%rbp), %rax # .pci_dev, hwdev testq %rax, %rax # hwdev leaq112(%rax), %rcx #, tmp225 movqdma_ops(%rip), %rax # dma_ops, dma_ops cmovne %rcx, %rdi # tmp225,, tmp226 movl$2, %ecx#, call*40(%rax) # .unmap_single Which I think comes from dereferencing np->rx_skbuff[i]. I've not found a reproducible way of doing this, and I've at times come back to my room to find out that this computer has been forcibly shut down. I'm not familiar with this code. I hope someone here understands how this can happen. I'll try to find a way to reproduce this meanwhile. cmn -- Carlos Martín Nieto| http://www.cmartin.tk Hobbyist programmer| pgpMMBpqErsZd.pgp Description: PGP signature
Re: [PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110
On Fri, 2006-05-12 at 09:57 -0700, Jean Tourrilhes wrote: > Marcin Juszkiewicz wrote : > > > > This time I checked more carefully my changeset and split it into > > smaller parts. Few of my patches was tested by OpenZaurus users, some > > are waiting for testing. > > I'm sorry, but I will have again to veto part of your patch. > You are removing IDs from the Orinoco driver. Please don't do > that, those card work perfectly with the orinoco driver, and some of > us run them with the orinoco driver (orinoco is one third the > footprint of hostap). Once again, I really appreciate your vigilance, Jean :-) I strongly believe that every driver should list all devices it can support. In case of multiple drivers supporting one device, the choice should be done in userspace. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC] net: au1000_eth: PHY framework conversion
convert au1000_eth driver to use PHY framework
Signed-off-by: Herbert Valerio Riedel <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1
drivers/net/au1000_eth.c | 1602 +++---
drivers/net/au1000_eth.h | 134
3 files changed, 380 insertions(+), 1357 deletions(-)
Index: b/drivers/net/Kconfig
===
--- a/drivers/net/Kconfig 2006-05-12 21:18:36.0 +0200
+++ b/drivers/net/Kconfig 2006-05-12 21:37:42.0 +0200
@@ -455,6 +455,7 @@
config MIPS_AU1X00_ENET
bool "MIPS AU1000 Ethernet support"
depends on NET_ETHERNET && SOC_AU1X00
+ select PHYLIB
select CRC32
help
If you have an Alchemy Semi AU1X00 based system
Index: b/drivers/net/au1000_eth.c
===
--- a/drivers/net/au1000_eth.c 2006-05-12 21:18:36.0 +0200
+++ b/drivers/net/au1000_eth.c 2006-05-12 22:05:25.0 +0200
@@ -9,6 +9,9 @@
* Update: 2004 Bjoern Riemer, [EMAIL PROTECTED]
* or [EMAIL PROTECTED]: fixed the link beat detection with
* ioctls (SIOCGMIIPHY)
+ * Copyright 2006 Herbert Valerio Riedel <[EMAIL PROTECTED]>
+ * converted to use linux-2.6.x's PHY framework
+ *
* Author: MontaVista Software, Inc.
* [EMAIL PROTECTED] or [EMAIL PROTECTED]
*
@@ -53,6 +56,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -88,17 +92,15 @@
static int au1000_rx(struct net_device *);
static irqreturn_t au1000_interrupt(int, void *, struct pt_regs *);
static void au1000_tx_timeout(struct net_device *);
-static int au1000_set_config(struct net_device *dev, struct ifmap *map);
static void set_rx_mode(struct net_device *);
static struct net_device_stats *au1000_get_stats(struct net_device *);
-static void au1000_timer(unsigned long);
static int au1000_ioctl(struct net_device *, struct ifreq *, int);
static int mdio_read(struct net_device *, int, int);
static void mdio_write(struct net_device *, int, int, u16);
-static void dump_mii(struct net_device *dev, int phy_id);
+static void au1000_adjust_link(struct net_device *);
+static void enable_mac(struct net_device *, int);
// externs
-extern void ack_rise_edge_irq(unsigned int);
extern int get_ethernet_addr(char *ethernet_addr);
extern void str2eaddr(unsigned char *ea, unsigned char *str);
extern char * __init prom_getcmdline(void);
@@ -126,705 +128,83 @@
0x00, 0x50, 0xc2, 0x0c, 0x30, 0x00
};
-#define nibswap(x) x) >> 4) & 0x0f) | (((x) << 4) & 0xf0))
-#define RUN_AT(x) (jiffies + (x))
-
-// For reading/writing 32-bit words from/to DMA memory
-#define cpu_to_dma32 cpu_to_be32
-#define dma32_to_cpu be32_to_cpu
-
struct au1000_private *au_macs[NUM_ETH_INTERFACES];
-/* FIXME
- * All of the PHY code really should be detached from the MAC
- * code.
+/*
+ * board-specific configurations
+ *
+ * PHY detection algorithm
+ *
+ * If AU1XXX_PHY_STATIC_CONFIG is undefined, the PHY setup is
+ * autodetected:
+ *
+ * mii_probe() first searches the current MAC's MII bus for a PHY,
+ * selecting the first (or last, if AU1XXX_PHY_SEARCH_HIGHEST_ADDR is
+ * defined) PHY address not already claimed by another netdev.
+ *
+ * If nothing was found that way when searching for the 2nd ethernet
+ * controller's PHY and AU1XXX_PHY1_SEARCH_ON_MAC0 is defined, then
+ * the first MII bus is searched as well for an unclaimed PHY; this is
+ * needed in case of a dual-PHY accessible only through the MAC0's MII
+ * bus.
+ *
+ * Finally, if no PHY is found, then the corresponding ethernet
+ * controller is not registered to the network subsystem.
*/
-/* Default advertise */
-#define GENMII_DEFAULT_ADVERTISE \
- ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | \
- ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full | \
- ADVERTISED_Autoneg
-
-#define GENMII_DEFAULT_FEATURES \
- SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | \
- SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \
- SUPPORTED_Autoneg
-
-int bcm_5201_init(struct net_device *dev, int phy_addr)
-{
- s16 data;
-
- /* Stop auto-negotiation */
- data = mdio_read(dev, phy_addr, MII_CONTROL);
- mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO);
-
- /* Set advertisement to 10/100 and Half/Full duplex
-* (full capabilities) */
- data = mdio_read(dev, phy_addr, MII_ANADV);
- data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T;
- mdio_write(dev, phy_addr, MII_ANADV, data);
-
- /* Restart auto-negotiation */
- data = mdio_read(dev, phy_addr, MII_CONTROL);
- data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO;
- mdio_write(dev, phy_addr, MII_CONTROL, data);
-
- if (au1000_debug > 4)
- dump_mii(dev, phy_addr);
- return 0;
-}
-
-int bcm_5201_reset(struct net_device *dev, int
Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Friday 12 May 2006 06:47, you wrote:
> > It seems like hw_modes is more useful for saying
> > what modes shouldn't be used than saying what modes are supported by the
> > hardware and should be used.
>
> This is exactly the purpose of hw_modes. This also means you don't need
> any validation.
>
Hm, so why not add something that will tell you what modes are supported by
the hardware?
Only problem with this patch is if the hardware adds any modes after
registration, they will be disabled initially. Hopefully, no drivers will
actually need to do that.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index ffb7985..e110237 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -3999,19 +3999,24 @@ void ieee80211_if_setup(struct net_devic
}
-static void ieee80211_precalc_rates(struct ieee80211_hw *hw)
+static void ieee80211_precalc_modes(struct ieee80211_hw *hw,
+ struct ieee80211_local *local)
{
struct ieee80211_hw_modes *mode;
struct ieee80211_rate *rate;
int m, r;
+ local->valid_hw_modes = 0;
for (m = 0; m < hw->num_modes; m++) {
mode = &hw->modes[m];
+ local->valid_hw_modes |= 1 << mode->mode;
for (r = 0; r < mode->num_rates; r++) {
rate = &mode->rates[r];
rate->rate_inv = CHAN_UTIL_RATE_LCM / rate->rate;
}
}
+
+ local->hw_modes &= local->valid_hw_modes;
}
@@ -4257,7 +4262,7 @@ int ieee80211_update_hw(struct net_devic
!hw->modes->num_channels || !hw->modes->num_rates)
return -1;
- ieee80211_precalc_rates(hw);
+ ieee80211_precalc_modes(hw, local);
local->conf.phymode = hw->modes[0].mode;
local->curr_rates = hw->modes[0].rates;
local->num_curr_rates = hw->modes[0].num_rates;
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ee0b399..6f33a75 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -409,7 +409,6 @@ #define IEEE80211_IRQSAFE_QUEUE_LIMIT 12
int scan_oper_antenna_max;
u8 scan_ssid[IEEE80211_MAX_SSID_LEN];
size_t scan_ssid_len;
- int scan_skip_11b;
struct list_head sta_bss_list;
struct ieee80211_sta_bss *sta_bss_hash[STA_HASH_SIZE];
spinlock_t sta_bss_lock;
@@ -500,6 +499,8 @@ #endif /* CONFIG_D80211_DEBUG_COUNTERS *
int wifi_wme_noack_test;
unsigned int wmm_acm; /* bit field of ACM bits (BIT(802.1D tag)) */
+ unsigned int valid_hw_modes; /* bitfield of supported hardware modes;
+ * (1 << MODE_*) */
unsigned int hw_modes; /* bitfield of allowed hardware modes;
* (1 << MODE_*) */
};
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 5d31a8f..89db144 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -2447,7 +2447,7 @@ static int ieee80211_ioctl_prism2_param(
break;
case PRISM2_PARAM_HW_MODES:
- local->hw_modes = value;
+ local->hw_modes = value & local->valid_hw_modes;
break;
case PRISM2_PARAM_CREATE_IBSS:
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 2720f1d..7955767 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2468,7 +2468,7 @@ static void ieee80211_sta_scan_timer(uns
(sdata->type == IEEE80211_IF_TYPE_IBSS &&
!(chan->flag & IEEE80211_CHAN_W_IBSS)) ||
(local->hw_modes & (1 << MODE_IEEE80211G) &&
-mode->mode == MODE_IEEE80211B && local->scan_skip_11b))
+mode->mode == MODE_IEEE80211B))
skip = 1;
if (!skip) {
@@ -2566,7 +2566,6 @@ int ieee80211_sta_req_scan(struct net_de
memcpy(local->scan_ssid, ssid, ssid_len);
} else
local->scan_ssid_len = 0;
- local->scan_skip_11b = 1; /* FIX: clear this is 11g is not supported */
local->scan_state = SCAN_SET_CHANNEL;
local->scan_hw_mode_idx = 0;
local->scan_channel_idx = 0;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patches from Marcin Juszkiewicz
Hello! As a co-maintainer of Orinoco driver, I'd like to ask the netdev team not to apply any patch from Marcin Juszkiewicz touching the Orinoco driver without my or David's explicit approval. I'm fine with patches that change e.g. all PCMCIA or PCI drivers across the board, but not with patches that remove IDs for compatible cards that were carefully collected over the years. Any patches for Orinoco drivers that don't come from kernel subsystem maintainers should be sent to the driver mailing list at [EMAIL PROTECTED] -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110
On Fri, 2006-05-12 at 15:21 +0200, Marcin Juszkiewicz wrote: > All patches require 24_hostap_cs_id.diff from Pavel Roskin. This patch was never submitted. Please ignore the series. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux v2.6.17-rc4
On Friday 12 May 2006 13:23, you wrote: > > > I got assertion failures in the bcm43xx driver: > > > > > > bcm43xx: Chip ID 0x4318, rev 0x2 > > > > That is expected an non-fatal. > > Is this one in the same category? > [ 79.087115] bcm43xx: WARNING: Writing invalid LOpair (low: 46, high: 104, > index: 123) > [ 47.361435] bcm43xx: Chip ID 0x4318, rev 0x2 ^^ Yes, same problem. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux v2.6.17-rc4
On Friday 12 May 2006 13:47, you wrote: > On Fri, May 12, 2006 at 12:44:22PM +0200, Michael Buesch wrote: > > On Friday 12 May 2006 12:24, you wrote: > > > On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote: > > > > Ok, I've let the release time between -rc's slide a bit too much again, > > > > but -rc4 is out there, and this is the time to hunker down for 2.6.17. > > > > > > > > If you know of any regressions, please holler now, so that we don't > > > > miss > > > > them. > > > > > > I got assertion failures in the bcm43xx driver: > > > > > > bcm43xx: Chip ID 0x4318, rev 0x2 > > > > That is expected an non-fatal. > > Assertion failed sounds rather fatal to me. But it is not fatal. Trust me. I am the author of most of the code. The worst thing that can happen is that the card does not work. The best thing that can happen is that it works with some luck. > > It is no regression. > > It is, I didn't see it in 2.6.17-rc3. You did not look close enough. > > We are working on it, but there won't be any fix for 2.6.17, as > > very intrusive changes are needed to fix this. > > If it's non-fatal, could you remove the assertion, or make it print > something that sounds less fatal? Well, the backtrace could be removed. But I am for not removing the assertions completely, because this way people don't see what is going on, if the device does not work. It is non-fatal in the sense that it does not crash the machine. It _may_ be fatal, that the device does not work. The driver is CONFIG_EXPERIMENTAL for some reason. To say it again: The 4318 is not completely supported, yet. It may work with some luck, but it is not guaranteed and only lower bitrates are supported. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.16.13 e1000 reports incorrect PCI-X bus speed?
I'm running a slightly modified 2.6.16.13 kernel on FC5-amd64. The motherboard is SuperMicro H8SSL dual-core AMD system. According to super-micro web site, the PCI-X slot is 133Mhz. I'm using a 4-port pro/1000 NIC. dmesg shows a listing of 120Mhz: Intel(R) PRO/1000 Network Driver - version 6.3.9-k4-NAPI Copyright (c) 1999-2005 Intel Corporation. GSI 18 sharing vector 0xB9 and IRQ 18 ACPI: PCI Interrupt :03:04.0[A] -> GSI 20 (level, low) -> IRQ 18 e1000: :03:04.0: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bc e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 19 sharing vector 0xC1 and IRQ 19 ACPI: PCI Interrupt :03:04.1[B] -> GSI 21 (level, low) -> IRQ 19 e1000: :03:04.1: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bd e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 20 sharing vector 0xC9 and IRQ 20 ACPI: PCI Interrupt :03:06.0[A] -> GSI 22 (level, low) -> IRQ 20 e1000: :03:06.0: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:be e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 21 sharing vector 0xD1 and IRQ 21 ACPI: PCI Interrupt :03:06.1[B] -> GSI 23 (level, low) -> IRQ 21 e1000: :03:06.1: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bf e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection ethtool -d eth3 shows 66Mhz: 0x8: STATUS (Device status register) 0x3B87 Duplex:full Link up: link config TBI mode: disabled Link speed:1000Mb/s Bus type: PCI-X Bus speed: 66MHz Bus width: 64-bit Any idea why I see the slower bus speed reported? More info available as needed. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16.13 e1000 reports incorrect PCI-X bus speed?
Ben Greear wrote: I'm running a slightly modified 2.6.16.13 kernel on FC5-amd64. The motherboard is SuperMicro H8SSL dual-core AMD system. According to super-micro web site, the PCI-X slot is 133Mhz. I'm using a 4-port pro/1000 NIC. dmesg shows a listing of 120Mhz: Intel(R) PRO/1000 Network Driver - version 6.3.9-k4-NAPI Copyright (c) 1999-2005 Intel Corporation. GSI 18 sharing vector 0xB9 and IRQ 18 ACPI: PCI Interrupt :03:04.0[A] -> GSI 20 (level, low) -> IRQ 18 e1000: :03:04.0: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bc e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 19 sharing vector 0xC1 and IRQ 19 ACPI: PCI Interrupt :03:04.1[B] -> GSI 21 (level, low) -> IRQ 19 e1000: :03:04.1: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bd e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 20 sharing vector 0xC9 and IRQ 20 ACPI: PCI Interrupt :03:06.0[A] -> GSI 22 (level, low) -> IRQ 20 e1000: :03:06.0: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:be e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 21 sharing vector 0xD1 and IRQ 21 ACPI: PCI Interrupt :03:06.1[B] -> GSI 23 (level, low) -> IRQ 21 e1000: :03:06.1: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bf e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection ethtool -d eth3 shows 66Mhz: 0x8: STATUS (Device status register) 0x3B87 Duplex:full Link up: link config TBI mode: disabled Link speed:1000Mb/s Bus type: PCI-X Bus speed: 66MHz Bus width: 64-bit Any idea why I see the slower bus speed reported? ethtool currently doesn't know about some bus speeds, and will report a wrong speed. Here's what ethtool currently uses: (ethtool-3/e1000.c) 327 (reg & E1000_STATUS_PCIX_MODE) ? 328 ((reg & E1000_STATUS_PCIX_SPEED_133) ? "133MHz" : 329 (reg & E1000_STATUS_PCIX_SPEED_100) ? "100MHz" : 330 "66MHz")> : obviously 120 is missing, but PCI-E speeds are also missing (2500gbps). The output of the e1000 module is correct. Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux v2.6.17-rc4
On Friday 12 May 2006 00:44, Linus Torvalds wrote: > Ok, I've let the release time between -rc's slide a bit too much again, > but -rc4 is out there, and this is the time to hunker down for 2.6.17. > > If you know of any regressions, please holler now, so that we don't miss > them. > > -rc4 itself is mainly random driver fixes (sound, infiniband, scsi, > network drivers), but some splice fixes too and some arch (arm, powerpc, > mips) updates. Shortlog follows, Linus, I've got an oops in the forcedeth driver on shutdown. Sorry for the crappy camera phone pictures, this board doesn't have RS232 ports: http://devzero.co.uk/~alistair/oops-20060512/ It was initially difficult to reproduce, but I found I could do so reliably if I ssh'ed into the box and halted it remotely, then it would always oops on shutdown. I assume this is because the driver is still active when something happens to it during halt. There's been just a single commit since -rc3: forcedeth: fix multi irq issues ebf34c9b6fcd22338ef764b039b3ac55ed0e297b However, it could have just been hidden since before -rc3, so I'll try to work backwards if nobody has any immediate ideas.. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network freeze with nforce-A939 integrated rhine card
On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: > I haven't had time to go back and find where is started (my prior kernel > was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a > problem where when transfering large amounts of data (trying to ftp a TB "where is started" sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? > when I say shut down I mean that it looses link and requires powering down > the box (hard power down, not just power off from the front panel), > disabling the network card in the BIOS, booting (as far as lilo is > enough), powering down again, enabling the card and booting again. So there are two problem areas: 1) the chip hangs itself without the driver noticing and 2) the BIOS fails to bring the chip back to life afterwards. > there is no indication of trouble before the halt (it's transfering at > full speed), the only think in the log is > May 11 22:23:57 david kernel: eth0: link down > May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa > 0xCDE1 > May 11 22:24:22 david kernel: eth0: link down > > if I don't do the disable/enable in the bios cycle and just power cycle > the system the card does not initialize properly (ethtool reports > autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I > try to enable the card) Any difference in the kernel log when booting with (or ethtooling) a comatose chip? > [EMAIL PROTECTED]:~$ /sbin/lspci > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 > 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 > 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 > 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 > 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 > 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] > 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) > 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) > 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) > 00:0f.0 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) > 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] > (rev 81) > 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] > (rev 81) > 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] > (rev 81) > 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] > (rev 81) > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. > VT8233/A/8235/8237 AC97 Audio Controller (rev 60) > 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge > 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 > SE] (rev 01) Odd. This doesn't look at all like the list I'd expect from an nforce-A939. I thought Nvidia devices featured rather prominently in the device lists of nforce-based boards!? Roger - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16.13 e1000 reports incorrect PCI-X bus speed?
Ben Greear wrote: I'm running a slightly modified 2.6.16.13 kernel on FC5-amd64. The motherboard is SuperMicro H8SSL dual-core AMD system. According to super-micro web site, the PCI-X slot is 133Mhz. I'm using a 4-port pro/1000 NIC. dmesg shows a listing of 120Mhz: IIRC there is a bridge chip on those four-port cards. Perhaps the "north" side of the bridge is at 133 MHz, but the south side (since it is more than one load) is only 120? Intel(R) PRO/1000 Network Driver - version 6.3.9-k4-NAPI Copyright (c) 1999-2005 Intel Corporation. GSI 18 sharing vector 0xB9 and IRQ 18 ACPI: PCI Interrupt :03:04.0[A] -> GSI 20 (level, low) -> IRQ 18 e1000: :03:04.0: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bc e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 19 sharing vector 0xC1 and IRQ 19 ACPI: PCI Interrupt :03:04.1[B] -> GSI 21 (level, low) -> IRQ 19 e1000: :03:04.1: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bd e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 20 sharing vector 0xC9 and IRQ 20 ACPI: PCI Interrupt :03:06.0[A] -> GSI 22 (level, low) -> IRQ 20 e1000: :03:06.0: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:be e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection GSI 21 sharing vector 0xD1 and IRQ 21 ACPI: PCI Interrupt :03:06.1[B] -> GSI 23 (level, low) -> IRQ 21 e1000: :03:06.1: e1000_probe: (PCI-X:120MHz:64-bit) 00:04:23:ad:41:bf e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection ethtool -d eth3 shows 66Mhz: 0x8: STATUS (Device status register) 0x3B87 Duplex:full Link up: link config TBI mode: disabled Link speed:1000Mb/s Bus type: PCI-X Bus speed: 66MHz Bus width: 64-bit Any idea why I see the slower bus speed reported? That one though escapes me. rick jones More info available as needed. Thanks, Ben - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix IP-over-ATM and ARP interaction - formatting fixed.
From: Simon Kelley <[EMAIL PROTECTED]> Date: Sat, 06 May 2006 18:02:00 +0100 > This patch adds a new function, neigh_table_init_no_netlink() which > does everything the neigh_table_init() does, except add the table to > the netlink all-arp-tables chain. In addition neigh_table_init() has a > check that all tables on the chain have a distinct address family. > The init call in clip.c is changed to call neigh_table_init_no_netlink(). > > Since ATM ARP tables are rather more complicated than can currently be > handled by the available rtattrs in the netlink protocol, no > functionality is lost by this patch, and non-ATM ARP manipulation via > netlink is rescued. A more complete solution would involve a rtattr for > ATM ARP entries and some way for the netlink code to give neigh_add > and friends more information than just address family with which to find > the correct ARP table. > > Signed-off-by: Simon Kelley <[EMAIL PROTECTED]> This is an OK solution to this problem for now. So I will apply this. I made a minor change to your patch, I changed the assertion added to neigh_table_init(). It's not so nice to BUG_ON() with critical locks held just to get a log of who tried to do the double-registry. It could cause the machine to deadlock and subsequently the debugging log we need to analyze such cases is less likely to get reported. Longer term we should make neigh_table_init() return some kind of error code to handle cases like this, but that's too large a change for so close to 2.6.17-final. Thanks again Simon. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16.13 e1000 reports incorrect PCI-X bus speed?
Auke Kok wrote: obviously 120 is missing, but PCI-E speeds are also missing (2500gbps). The output of the e1000 module is correct. Any idea why 120Mhz is used instead of 133? It doesn't seem to matter in my performance tests, but I am curious... Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network freeze with nforce-A939 integrated rhine card
On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB "where is started" sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I posted this origionally I thought it was new in 2.6.17-rc, however since my testing with older kernels hasn't found me a working one yet I suspect that other factors have been involved with makeing it work. these failures have been on multi-gig files ftp'd from the raid array on my machine to the raid array on the replacement machine. In the past I've sucessfully transfered similar sized files to/from my tivo (slow network), my laptop (slow drive), and smaller sets of files to single drives on other systems (7200rpm drives, but not to arrays). as I type this I'm starting a test going from a single drive on this machine to the raid array on the remote machine to transfer ~84G of data. My suspicion is that this is going to work. when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. So there are two problem areas: 1) the chip hangs itself without the driver noticing and 2) the BIOS fails to bring the chip back to life afterwards. yes there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) Any difference in the kernel log when booting with (or ethtooling) a comatose chip? I haven't checked the boot logs, I'll do that. ethtool hasn't generated any logs that I've seen. after the current transfer finishes I'll trigger the bug and test this. [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) Odd. This doesn't look at all like the list I'd expect from an nforce-A939. I thought Nvidia devices featured rather prominently in the device lists of nforce-based boards!? you're right, it's the new server that has the nforce board. I'll have to check the motherboard version when I reboot it. David Lang - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6530] New: MAINLINE
Andrew Morton writes: > xeb (who forgot to do reply-to-all) tells me that pptpd uses ptys. I tried to replicate this using pppd running on a pty, with a "charshunt" process on the master side of the pty transferring characters between it and a socket. I didn't see any freezeups in either direction. So - precise details on how to replicate this would be appreciated. Paul. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
