* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-07 10:09 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Ingo Molnar, Marcin Ślusarz, Thomas Gleixner, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <46B75DD4.5080709@redhat.com>
On Mon, Aug 06, 2007 at 01:43:48PM -0400, Chuck Ebbert wrote:
> On 08/06/2007 03:03 AM, Ingo Molnar wrote:
> >
> > But, since level types don't need this retriggers too much I think
> > this "don't mask interrupts by default" idea should be rethinked:
> > is there enough gain to risk such hard to diagnose errors?
> >
> >
>
> I reverted those masking changes in Fedora and the baffling problem
> with 3Com 3C905 network adapters went away.
>
> Before, they would print:
>
> eth0: transmit timed out, tx_status 00 status e601.
> diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
> eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
> Flags; bus-master 1, dirty 295757(13) current 295757(13)
> Transmit list 00000000 vs. f7150a20.
> 0: @f7150200 length 80000070 status 0c010070
> 1: @f71502a0 length 80000070 status 0c010070
> 2: @f7150340 length 8000005c status 0c01005c
>
> Now they just work, apparently...
>
> So why not just revert the change?
>
Ingo has written about such possibility. But, it would be good
to know which precisely place is to blame, as well. Since this
diagnosing takes time, I think Chuck is right, and maybe at least
this temporary patch for resend.c without this warning, should
be recomended for stables (2.6.21 and 2.6.22)?
Jarek P.
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-07 9:52 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Ingo Molnar, Thomas Gleixner, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <4bacf17f0708070237w19d184b3p7f74b53612edb9a6@mail.gmail.com>
On Tue, Aug 07, 2007 at 11:37:01AM +0200, Marcin Ślusarz wrote:
> 2007/8/7, Jarek Poplawski <jarkao2@o2.pl>:
> > On Tue, Aug 07, 2007 at 09:46:36AM +0200, Marcin Ślusarz wrote:
> > > Network card still locks up (tested on 2.6.22.1). I had to upload more
> > > data than usual (~350 MB vs ~1-100 MB) to trigger that bug but it
> > > might be a coincidence...
> >
> > Thanks! It's a good news after all - it would be really strange why
> > this place doesn't hit more people (it seems there is some safety
> > elsewhere for this).
> >
> > BTW: I hope, this previous Thomas' patch with Ingo's warning to resend.c
> > (with a warning), had no problems with a similar load?
> I always tested on 500-600 MB "dataset"
>
> > PS: Marcin, if you need a break in this testing let us know!
> No, i don't need a break. I'll have more time in next weeks.
Great! So, I'll try to send a patch with _SW_RESEND in a few hours,
if Ingo doesn't prepare something for you.
Thanks,
Jarek P.
^ permalink raw reply
* [RFC] allow device to stop packet mirror behaviour
From: Johannes Berg @ 2007-08-07 8:25 UTC (permalink / raw)
To: netdev; +Cc: Andy Green, David Miller, linux-wireless
In the wireless code, we have special 802.11+radiotap framed virtual
interfaces, mostly used to monitor traffic on the air. They also show
outgoing packets from other virtual interfaces associated with the same
PHY because you can't receive packets while sending. Due to the design
of the virtual interfaces, the packets don't pass through those
802.11+radiotap framed interfaces.
This whole setup has the additional advantage that we are able to
indicate the transmission status parameters via radiotap as well,
meaning that we can tell (in userspace) by looking at the radiotap
header whether a packet was acknowledged by the receiver, whether
RTS/CTS was used etc. This is required for implementing more things in
userspace which we plan to do in order to not have the high-complexity
MLME in the kernel.
Now, however, we run into the situation that somebody is actually
sending frames down the 802.11+radiotap framed interface. This could be
the userspace MLME implementation, for example, sending association
requests or whatever. These will now show up twice on the monitoring
interface that the userspace MLME is using, once via
dev_queue_xmit_nit() because they were sent on that interface and once
via our own mirror mechanism that also shows the transmission status
indication.
Andy has written a patch that suppresses our own mirror mechanism from
becoming effective for packets that were already mirrored out by
dev_queue_xmit_nit(), however this is not very desirable because it
makes such packets special, their transmission status information will
not be available; however, in some circumstances this information is
required (for example when implementing an MLME using 802.11+radiotap
framed interfaces.) [Also, the current implementation means that on yet
another monitor interface you don't see those frames at all.]
The only way to solve this problem therefore seems to be to suppress the
mirroring out of the packet by dev_queue_xmit_nit(). The patch below
does that by way of adding a new netdev flag.
Comments welcome.
johannes
---
Tested with three monitor interfaces and a trivial injection program on
bcm43xx-mac80211. I'll send the mac80211 patch I used as a follow-up.
include/linux/if.h | 2 ++
net/core/dev.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--- wireless-dev.orig/include/linux/if.h 2007-08-06 21:02:55.868164177 +0200
+++ wireless-dev/include/linux/if.h 2007-08-06 21:03:05.458164177 +0200
@@ -50,6 +50,8 @@
#define IFF_LOWER_UP 0x10000 /* driver signals L1 up */
#define IFF_DORMANT 0x20000 /* driver signals dormant */
+#define IFF_NO_MIRROR 0x40000 /* driver will mirror packets */
+
#define IFF_VOLATILE (IFF_LOOPBACK|IFF_POINTOPOINT|IFF_BROADCAST|\
IFF_MASTER|IFF_SLAVE|IFF_RUNNING|IFF_LOWER_UP|IFF_DORMANT)
--- wireless-dev.orig/net/core/dev.c 2007-08-06 21:02:55.898164177 +0200
+++ wireless-dev/net/core/dev.c 2007-08-06 21:04:58.218164177 +0200
@@ -1417,7 +1417,7 @@ static int dev_gso_segment(struct sk_buf
int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
if (likely(!skb->next)) {
- if (!list_empty(&ptype_all))
+ if (!list_empty(&ptype_all) && !(dev->flags & IFF_NO_MIRROR))
dev_queue_xmit_nit(skb, dev);
if (netif_needs_gso(dev, skb)) {
@@ -2829,7 +2829,7 @@ int dev_change_flags(struct net_device *
IFF_DYNAMIC | IFF_MULTICAST | IFF_PORTSEL |
IFF_AUTOMEDIA)) |
(dev->flags & (IFF_UP | IFF_VOLATILE | IFF_PROMISC |
- IFF_ALLMULTI));
+ IFF_ALLMULTI | IFF_NO_MIRROR));
/*
* Load in the correct multicast list now the flags have changed.
^ permalink raw reply
* [PATCH] net/core/utils: fix sparse warning
From: Johannes Berg @ 2007-08-06 16:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
net_msg_warn is not defined because it is in net/sock.h which isn't
included.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/core/utils.c | 1 +
1 file changed, 1 insertion(+)
--- wireless-dev.orig/net/core/utils.c 2007-08-06 18:35:29.197838489 +0200
+++ wireless-dev/net/core/utils.c 2007-08-06 18:35:52.227838489 +0200
@@ -25,6 +25,7 @@
#include <linux/random.h>
#include <linux/percpu.h>
#include <linux/init.h>
+#include <net/sock.h>
#include <asm/byteorder.h>
#include <asm/system.h>
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-07 9:44 UTC (permalink / raw)
To: Jean-Baptiste Vignaud
Cc: cebbert, mingo, marcin.slusarz, tglx, torvalds, linux-kernel,
shemminger, linux-net, netdev, akpm, alan
In-Reply-To: <JMECN8$607C5E77E84D2F80DCAAB4CFEB5A6346@xandmail.com>
On Tue, Aug 07, 2007 at 11:21:07AM +0200, Jean-Baptiste Vignaud wrote:
>
> > > * interrupts (i use irqbalance, but problem was the same without)
> >
> > I wonder if you tried without SMP too?
>
> No i did not. Do you think that this can be a problem ?
> To test with no SMP, do i need to recompile kernel or is there a kernel parameter ?
It's always better to exclude any complications if it's possible.
Yes, there is the kernel parameter for this: nosmp. So, if you
have some time to spare I think 2.6.23-rc2 with this nosmp
could be an interesting option.
> ....
>
> > BTW, Jean-Baptiste and Chuck - it seems, unless you have too much
> > time, there is no use for testing my "genirq: fix simple and fasteoi
> > irq handlers" patch.
>
> Well i just tested 2.6.23-rc1 with your patch and copied (using smbclient) big files :
>
> Aug 7 11:11:53 loki kernel: NETDEV WATCHDOG: eth2: transmit timed out
> Aug 7 11:11:53 loki kernel: eth2: transmit timed out, tx_status 00 status e601.
> Aug 7 11:11:53 loki kernel: diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
> Aug 7 11:11:53 loki kernel: eth2: Interrupt posted but not delivered -- IRQ blocked by another device?
> Aug 7 11:11:53 loki kernel: Flags; bus-master 1, dirty 93481(9) current 93481(9)
> Aug 7 11:11:53 loki kernel: Transmit list 00000000 vs. ffff81007be977a0.
> Aug 7 11:11:53 loki kernel: 0: @ffff81007be97200 length 8000005f status 0001005f
...
Thanks,
Jarek P.
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jean-Baptiste Vignaud @ 2007-08-07 9:21 UTC (permalink / raw)
To: jarkao2
Cc: cebbert, mingo, marcin.slusarz, tglx, torvalds, linux-kernel,
shemminger, linux-net, netdev, akpm, alan
> > * interrupts (i use irqbalance, but problem was the same without)
>
> I wonder if you tried without SMP too?
No i did not. Do you think that this can be a problem ?
To test with no SMP, do i need to recompile kernel or is there a kernel parameter ?
....
> BTW, Jean-Baptiste and Chuck - it seems, unless you have too much
> time, there is no use for testing my "genirq: fix simple and fasteoi
> irq handlers" patch.
Well i just tested 2.6.23-rc1 with your patch and copied (using smbclient) big files :
Aug 7 11:11:53 loki kernel: NETDEV WATCHDOG: eth2: transmit timed out
Aug 7 11:11:53 loki kernel: eth2: transmit timed out, tx_status 00 status e601.
Aug 7 11:11:53 loki kernel: diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
Aug 7 11:11:53 loki kernel: eth2: Interrupt posted but not delivered -- IRQ blocked by another device?
Aug 7 11:11:53 loki kernel: Flags; bus-master 1, dirty 93481(9) current 93481(9)
Aug 7 11:11:53 loki kernel: Transmit list 00000000 vs. ffff81007be977a0.
Aug 7 11:11:53 loki kernel: 0: @ffff81007be97200 length 8000005f status 0001005f
Aug 7 11:11:53 loki kernel: 1: @ffff81007be972a0 length 8000005f status 0001005f
Aug 7 11:11:53 loki kernel: 2: @ffff81007be97340 length 8000005f status 0001005f
Aug 7 11:11:53 loki kernel: 3: @ffff81007be973e0 length 8000005f status 0001005f
Aug 7 11:11:53 loki kernel: 4: @ffff81007be97480 length 8000003c status 0001003c
Aug 7 11:11:53 loki kernel: 5: @ffff81007be97520 length 8000003c status 0001003c
Aug 7 11:11:53 loki kernel: 6: @ffff81007be975c0 length 8000003c status 0001003c
Aug 7 11:11:53 loki kernel: 7: @ffff81007be97660 length 8000003c status 8001003c
Aug 7 11:11:53 loki kernel: 8: @ffff81007be97700 length 8000003c status 8001003c
Aug 7 11:11:53 loki kernel: 9: @ffff81007be977a0 length 8000002a status 0001002a
Aug 7 11:11:53 loki kernel: 10: @ffff81007be97840 length 8000003a status 0001003a
Aug 7 11:11:53 loki kernel: 11: @ffff81007be978e0 length 8000005f status 0001005f
Aug 7 11:11:53 loki kernel: 12: @ffff81007be97980 length 800000be status 0c0100be
Aug 7 11:11:53 loki kernel: 13: @ffff81007be97a20 length 800000be status 0c0100be
Aug 7 11:11:53 loki kernel: 14: @ffff81007be97ac0 length 8000005f status 0001005f
Aug 7 11:11:53 loki kernel: 15: @ffff81007be97b60 length 8000005f status 0001005f
Thanks;
Jb
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-07 9:05 UTC (permalink / raw)
To: Jean-Baptiste Vignaud
Cc: cebbert, mingo, marcin.slusarz, tglx, torvalds, linux-kernel,
shemminger, linux-net, netdev, akpm, alan
In-Reply-To: <JME9DM$ADEFA900BA9A4E6A40FE3AEF8CADB888@xandmail.com>
On Tue, Aug 07, 2007 at 10:10:34AM +0200, Jean-Baptiste Vignaud wrote:
>
> > BTW: Jean-Babtiste, could you send or point to you current configs?
Oops! I'm very sorry for misspelling!
> > I mean at least proc/interrupts, but with dmesg and .config it would
> > be even better. (I assume this last report was about the revert patch
> > mentioned by Chuck, not the one below your message?)
>
> Sure.
>
> Last reports are with the 2.6.22.1-41.fc7 kernel, which has in changelog :
>
> * Sat Jul 28 2007 Chuck Ebbert <cebbert@redhat.com>
> - revert upstream "genirq: do not mask interrupts by default"
>
>
> * interrupts (i use irqbalance, but problem was the same without)
I wonder if you tried without SMP too?
>
> [root@loki ~]# cat /proc/interrupts
> CPU0 CPU1
...
> 16: 72625 96 IO-APIC-fasteoi eth1
> 17: 4667 128 IO-APIC-fasteoi eth2
> 20: 4156 39870 IO-APIC-fasteoi sata_nv
> 21: 34794 9177 IO-APIC-fasteoi sata_nv
> 22: 0 0 IO-APIC-fasteoi ehci_hcd:usb2
> 23: 6005 1565 IO-APIC-fasteoi ohci_hcd:usb1, sata_nv
> 2297: 3 492180 PCI-MSI-edge eth0
> NMI: 0 0
> LOC: 4915345 4915282
> ERR: 0
So, here it's not about irq sharing...
>
> problems are with eth1 and eth2 here. never had any problems with the onboard (eth0).
...
>
> * .config
>
> i dont have it, it was the standard fedora one.
>
> i'm not sure that the problem is related to 3com, because i replaced those cards by old card i had in spare :
>
> 01:06.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42)
> 01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
>
> and i had the exact same problem.
>
> Those 3com cards were working 24/24 before i went to fedora 7 (and kernel 2.6.21 then).
It seems from 2.6.21 the problems are mainly about 'older' network
chips on x86_64. This reverted patch should mean only for those
using disable_irq, but I see forcedeth could use this too so it's
not clear yet, and btw. there where other changes around irqs and
pci, so everybody could have something a bit different with similar
time outs logs...
BTW, Jean-Baptiste and Chuck - it seems, unless you have too much
time, there is no use for testing my "genirq: fix simple and fasteoi
irq handlers" patch.
Thanks,
Jarek P.
^ permalink raw reply
* Re: [RFC] allow device to stop packet mirror behaviour
From: Johannes Berg @ 2007-08-07 8:27 UTC (permalink / raw)
To: netdev; +Cc: Andy Green, David Miller, linux-wireless
In-Reply-To: <1186475155.4067.17.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
This is the corresponding patch to mac80211.
It marks all monitor type interfaces with IFF_NO_MIRROR the reasons for
which I explained in the previous mail; it also marks the master device
with IFF_NO_MIRROR so you don't see *any* packets on the master device
(right now you see outgoing frames with 802.11 header.) We want to get
rid of it anyway so making it a bit more useless yet seems like a good
idea.
johannes
---
net/mac80211/ieee80211.c | 1 +
net/mac80211/ieee80211_iface.c | 2 ++
2 files changed, 3 insertions(+)
--- wireless-dev.orig/net/mac80211/ieee80211_iface.c 2007-08-06 21:14:37.398164177 +0200
+++ wireless-dev/net/mac80211/ieee80211_iface.c 2007-08-06 21:15:02.078164177 +0200
@@ -158,6 +158,7 @@ void ieee80211_if_set_type(struct net_de
int oldtype = sdata->type;
dev->hard_start_xmit = ieee80211_subif_start_xmit;
+ dev->flags &= ~IFF_NO_MIRROR;
sdata->type = type;
switch (type) {
@@ -216,6 +217,7 @@ void ieee80211_if_set_type(struct net_de
case IEEE80211_IF_TYPE_MNTR:
dev->type = ARPHRD_IEEE80211_RADIOTAP;
dev->hard_start_xmit = ieee80211_monitor_start_xmit;
+ dev->flags |= IFF_NO_MIRROR;
break;
default:
printk(KERN_WARNING "%s: %s: Unknown interface type 0x%x",
--- wireless-dev.orig/net/mac80211/ieee80211.c 2007-08-06 21:15:01.898164177 +0200
+++ wireless-dev/net/mac80211/ieee80211.c 2007-08-06 21:15:02.088164177 +0200
@@ -5138,6 +5138,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(
mdev->stop = ieee80211_master_stop;
mdev->type = ARPHRD_IEEE80211;
mdev->hard_header_parse = header_parse_80211;
+ mdev->flags |= IFF_NO_MIRROR;
sdata->type = IEEE80211_IF_TYPE_AP;
sdata->dev = mdev;
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-07 8:23 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Ingo Molnar, Thomas Gleixner, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <4bacf17f0708070046o14403089v8376a4544f72fec3@mail.gmail.com>
On Tue, Aug 07, 2007 at 09:46:36AM +0200, Marcin Ślusarz wrote:
> 2007/8/6, Ingo Molnar <mingo@elte.hu>:
> > (..)
> > please try Jarek's second patch too - there was a missing unmask.
> >
> > Ingo
> >
> > -------------->
> > Subject: genirq: fix simple and fasteoi irq handlers
> > From: Jarek Poplawski <jarkao2@o2.pl>
...
> Network card still locks up (tested on 2.6.22.1). I had to upload more
> data than usual (~350 MB vs ~1-100 MB) to trigger that bug but it
> might be a coincidence...
Thanks! It's a good news after all - it would be really strange why
this place doesn't hit more people (it seems there is some safety
elsewhere for this).
BTW: I hope, this previous Thomas' patch with Ingo's warning to resend.c
(with a warning), had no problems with a similar load?
So, once more, I would suspect hw retrigger code. Ingo, IMHO, this
patch for testing HARDIRQS_SW_RESEND could be reworked, so that
desc->chip->retrigger() is done only for eadges and the tasklet only
for levels. BTW, I think this current warning in the "temporary" is
is too early - we don't know if after this the ->retrigger() will
take place.
Regards,
Jarek P.
PS: Marcin, if you need a break in this testing let us know!
I think the main idea of this bug is known enough.
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jean-Baptiste Vignaud @ 2007-08-07 8:10 UTC (permalink / raw)
To: jarkao2
Cc: cebbert, mingo, marcin.slusarz, tglx, torvalds, linux-kernel,
shemminger, linux-net, netdev, akpm, alan
> BTW: Jean-Babtiste, could you send or point to you current configs?
> I mean at least proc/interrupts, but with dmesg and .config it would
> be even better. (I assume this last report was about the revert patch
> mentioned by Chuck, not the one below your message?)
Sure.
Last reports are with the 2.6.22.1-41.fc7 kernel, which has in changelog :
* Sat Jul 28 2007 Chuck Ebbert <cebbert@redhat.com>
- revert upstream "genirq: do not mask interrupts by default"
* interrupts (i use irqbalance, but problem was the same without)
[root@loki ~]# cat /proc/interrupts
CPU0 CPU1
0: 4487 4910668 IO-APIC-edge timer
1: 241 58 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 2 139 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge libata
15: 0 0 IO-APIC-edge libata
16: 72625 96 IO-APIC-fasteoi eth1
17: 4667 128 IO-APIC-fasteoi eth2
20: 4156 39870 IO-APIC-fasteoi sata_nv
21: 34794 9177 IO-APIC-fasteoi sata_nv
22: 0 0 IO-APIC-fasteoi ehci_hcd:usb2
23: 6005 1565 IO-APIC-fasteoi ohci_hcd:usb1, sata_nv
2297: 3 492180 PCI-MSI-edge eth0
NMI: 0 0
LOC: 4915345 4915282
ERR: 0
problems are with eth1 and eth2 here. never had any problems with the onboard (eth0).
* pci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
01:07.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
07:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 LE] (rev a1)
* dmesg (from a reboot this morning)
Linux version 2.6.22.1-41.fc7 (kojibuilder@xenbuilder1.fedora.redhat.com) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Fri Jul 27 18:21:43 EDT 2007
Command line: ro root=/dev/all/root
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fee0000 (usable)
BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS)
BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data)
BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved)
BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F7620, 0024 (r2 Nvidia)
ACPI: XSDT 7FEE30C0, 0044 (r1 Nvidia ASUSACPI 42302E31 AWRD 0)
ACPI: FACP 7FEEC400, 00F4 (r3 Nvidia ASUSACPI 42302E31 AWRD 0)
ACPI: DSDT 7FEE3240, 9164 (r1 NVIDIA AWRDACPI 1000 MSFT 3000000)
ACPI: FACS 7FEE0000, 0040
ACPI: HPET 7FEEC600, 0038 (r1 Nvidia ASUSACPI 42302E31 AWRD 98)
ACPI: MCFG 7FEEC680, 003C (r1 Nvidia ASUSACPI 42302E31 AWRD 0)
ACPI: APIC 7FEEC540, 007C (r1 Nvidia ASUSACPI 42302E31 AWRD 0)
Scanning NUMA topology in Northbridge 24
No NUMA configuration found
Faking a node at 0000000000000000-000000007fee0000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
Bootmem setup node 0 0000000000000000-000000007fee0000
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
early_node_map[2] active PFN ranges
0: 0 -> 159
0: 256 -> 524000
On node 0 totalpages: 523903
DMA zone: 56 pages used for memmap
DMA zone: 1300 pages reserved
DMA zone: 2643 pages, LIFO batch:0
DMA32 zone: 7108 pages used for memmap
DMA32 zone: 512796 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfefff000
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f0000
swsusp: Registered nosave memory region: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 80000000 (gap: 7ff00000:70100000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 40968 bytes of per cpu data
Built 1 zonelists. Total pages: 515439
Kernel command line: ro root=/dev/all/root
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Extended CMOS year: 2000
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 2009.257 MHz processor.
Console: colour VGA+ 80x25
Checking aperture...
CPU 0: aperture @ 64000000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 2057524k/2096000k available (2362k kernel code, 38088k reserved, 1401k data, 312k init)
SLUB: Genslabs=23, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1
Calibrating delay using timer specific routine.. 4020.98 BogoMIPS (lpj=2010494)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
Using local APIC timer interrupts.
result 12557855
Detected 12.557 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4018.58 BogoMIPS (lpj=2009293)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Brought up 2 CPUs
sizeof(vma)=176 bytes
sizeof(page)=56 bytes
sizeof(inode)=560 bytes
sizeof(dentry)=208 bytes
sizeof(ext3inode)=760 bytes
sizeof(buffer_head)=104 bytes
sizeof(skbuff)=232 bytes
sizeof(task_struct)=2048 bytes
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG at f0000000 - f3ffffff
PCI: No mmconfig possible on device 00:18
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:06.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 5 7 9 10 *11 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 5 *7 9 10 11 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK5] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK6] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [LNK7] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK8] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LP2P] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LMAC] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [LAZA] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LPMU] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUB2] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 5 7 9 10 *11 14 15)
ACPI: PCI Interrupt Link [LFID] (IRQs *5 7 9 10 11 14 15)
ACPI: PCI Interrupt Link [LSA2] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC6] (IRQs 16) *0
ACPI: PCI Interrupt Link [APC7] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC8] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [APMU] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [AAZA] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [ASA2] (IRQs 20 21 22 23) *0
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31
hpet0: 3 32-bit timers, 25000000 Hz
ACPI: RTC can wake from S4
pnp: 00:01: ioport range 0x1000-0x107f has been reserved
pnp: 00:01: ioport range 0x1080-0x10ff has been reserved
pnp: 00:01: ioport range 0x1400-0x147f has been reserved
Time: hpet clocksource has been installed.
pnp: 00:01: ioport range 0x1480-0x14ff has been reserved
pnp: 00:01: ioport range 0x1800-0x187f has been reserved
pnp: 00:01: ioport range 0x1880-0x18ff has been reserved
pnp: 00:0a: iomem range 0xf0000000-0xf3ffffff could not be reserved
pnp: 00:0b: iomem range 0xd1800-0xd3fff has been reserved
pnp: 00:0b: iomem range 0xf0000-0xf7fff could not be reserved
pnp: 00:0b: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0b: iomem range 0xfc000-0xfffff could not be reserved
PCI: Bridge: 0000:00:06.0
IO window: a000-afff
MEM window: fde00000-fdefffff
PREFETCH window: 80000000-800fffff
PCI: Bridge: 0000:00:0a.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0f.0
IO window: disabled.
MEM window: fa000000-fcffffff
PREFETCH window: e0000000-efffffff
PCI: Setting latency timer of device 0000:00:06.0 to 64
PCI: Setting latency timer of device 0000:00:0a.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
PCI: Setting latency timer of device 0000:00:0f.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 6291456 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 3938k freed
audit: initializing netlink socket (disabled)
audit(1186467404.666:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
ksign: Installing public key data
Loading keyring
- Added public key 8321A2A758C22C88
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Boot video device is 0000:07:00.0
PCI: Setting latency timer of device 0000:00:0a.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0a.0:pcie00]
Allocate Port Service[0000:00:0a.0:pcie03]
PCI: Setting latency timer of device 0000:00:0b.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
PCI: Setting latency timer of device 0000:00:0f.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0f.0:pcie00]
Allocate Port Service[0000:00:0f.0:pcie03]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Fan [FAN] (on)
ACPI: Thermal Zone [THRM] (40 C)
hpet_resources: 0xfefff000 is busy
Generic RTC Driver v1.07
Non-volatile memory driver v1.2
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing unused kernel memory: 312k freed
Write protecting the kernel read-only data: 1060k
USB Universal Host Controller Interface driver v3.0
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 23, io mem 0xfe02f000
input: PS2++ Logitech Wheel Mouse as /class/input/input2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:02.1: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: irq 22, io mem 0xfe02e000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
raid5: automatically using best checksumming function: generic_sse
generic_sse: 6160.000 MB/sec
raid5: using function: generic_sse (6160.000 MB/sec)
raid6: int64x1 1738 MB/s
raid6: int64x2 2378 MB/s
raid6: int64x4 1812 MB/s
raid6: int64x8 1800 MB/s
raid6: sse2x1 2773 MB/s
raid6: sse2x2 3714 MB/s
raid6: sse2x4 3898 MB/s
raid6: using algorithm sse2x4 (3898 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
SCSI subsystem initialized
libata version 2.21 loaded.
sata_nv 0000:00:05.0: version 3.4
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [APSI] -> GSI 21 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:05.0 to 64
scsi0 : sata_nv
scsi1 : sata_nv
ata1: SATA max UDMA/133 cmd 0x00000000000109f0 ctl 0x0000000000010bf2 bmdma 0x000000000001dc00 irq 21
ata2: SATA max UDMA/133 cmd 0x0000000000010970 ctl 0x0000000000010b72 bmdma 0x000000000001dc08 irq 21
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: Maxtor 6V320F0, VA111900, max UDMA/133
ata1.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-7: Maxtor 6V320F0, VA111900, max UDMA/133
ata2.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA Maxtor 6V320F0 VA11 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: Direct-Access ATA Maxtor 6V320F0 VA11 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1 sdb2
sd 1:0:0:0: [sdb] Attached SCSI disk
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:05.1[B] -> Link [APSJ] -> GSI 20 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:05.1 to 64
scsi2 : sata_nv
scsi3 : sata_nv
ata3: SATA max UDMA/133 cmd 0x00000000000109e0 ctl 0x0000000000010be2 bmdma 0x000000000001c800 irq 20
ata4: SATA max UDMA/133 cmd 0x0000000000010960 ctl 0x0000000000010b62 bmdma 0x000000000001c808 irq 20
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-7: Maxtor 6V320F0, VA111900, max UDMA/133
ata3.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata3.00: configured for UDMA/133
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: ATA-7: Maxtor 6V320F0, VA111900, max UDMA/133
ata4.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata4.00: configured for UDMA/133
scsi 2:0:0:0: Direct-Access ATA Maxtor 6V320F0 VA11 PQ: 0 ANSI: 5
sd 2:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdc: sdc1 sdc2
sd 2:0:0:0: [sdc] Attached SCSI disk
scsi 3:0:0:0: Direct-Access ATA Maxtor 6V320F0 VA11 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdd] 625142448 512-byte hardware sectors (320073 MB)
sd 3:0:0:0: [sdd] Write Protect is off
sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: [sdd] 625142448 512-byte hardware sectors (320073 MB)
sd 3:0:0:0: [sdd] Write Protect is off
sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdd: sdd1 sdd2
sd 3:0:0:0: [sdd] Attached SCSI disk
ACPI: PCI Interrupt Link [ASA2] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:05.2[C] -> Link [ASA2] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:05.2 to 64
scsi4 : sata_nv
scsi5 : sata_nv
ata5: SATA max UDMA/133 cmd 0x000000000001c400 ctl 0x000000000001c002 bmdma 0x000000000001b400 irq 23
ata6: SATA max UDMA/133 cmd 0x000000000001bc00 ctl 0x000000000001b802 bmdma 0x000000000001b408 irq 23
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: ATAPI: PLEXTOR DVDR PX-760A, 1.03, max UDMA/66
ata5.00: configured for UDMA/66
ata6: SATA link down (SStatus 0 SControl 300)
scsi 4:0:0:0: CD-ROM PLEXTOR DVDR PX-760A 1.03 PQ: 0 ANSI: 5
pata_amd 0000:00:04.0: version 0.3.8
PCI: Setting latency timer of device 0000:00:04.0 to 64
scsi6 : pata_amd
scsi7 : pata_amd
ata7: PATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 0x000000000001f000 irq 14
ata8: PATA max UDMA/133 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 0x000000000001f008 irq 15
ata7: port disabled. ignoring.
ata8: port disabled. ignoring.
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
md: md1 stopped.
md: bind<sdb2>
md: bind<sdc2>
md: bind<sdd2>
md: bind<sda2>
raid5: device sda2 operational as raid disk 0
raid5: device sdd2 operational as raid disk 3
raid5: device sdc2 operational as raid disk 2
raid5: device sdb2 operational as raid disk 1
raid5: allocated 4262kB for md1
raid5: raid level 5 set md1 active with 4 out of 4 devices, algorithm 2
RAID5 conf printout:
--- rd:4 wd:4
disk 0, o:1, dev:sda2
disk 1, o:1, dev:sdb2
disk 2, o:1, dev:sdc2
disk 3, o:1, dev:sdd2
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
audit(1186467414.296:2): enforcing=1 old_enforcing=0 auid=4294967295
security: 3 users, 6 roles, 1829 types, 81 bools, 1 sens, 1024 cats
security: 61 classes, 69524 rules
SELinux: Completing initialization.
SELinux: Setting up existing superblocks.
SELinux: initialized (dev dm-0, type ext3), uses xattr
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev cpuset, type cpuset), uses genfs_contexts
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
audit(1186467414.533:3): policy loaded auid=4294967295
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
sd 3:0:0:0: Attached scsi generic sg3 type 0
scsi 4:0:0:0: Attached scsi generic sg4 type 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 4:0:0:0: Attached scsi CD-ROM sr0
i2c-adapter i2c-0: nForce2 SMBus adapter at 0x1c00
i2c-adapter i2c-1: nForce2 SMBus adapter at 0x1c40
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APCH] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:08.0 to 64
forcedeth: using HIGHDMA
rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, y3k
eth0: forcedeth.c: subsystem: 01043:8239 bound to 0000:00:08.0
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt 0000:01:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
3c59x: Donald Becker and others.
0000:01:06.0: 3Com PCI 3c905C Tornado at ffffc20000330000.
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
0000:01:07.0: 3Com PCI 3c905C Tornado at ffffc2000037a000.
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
loop: module loaded
floppy0: no floppy controllers found
lp: driver loaded but no devices found
No dock devices found.
input: Power Button (FF) as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input4
ACPI: Power Button (CM) [PWRB]
md: md0 stopped.
md: bind<sdb1>
md: bind<sdc1>
md: bind<sdd1>
md: bind<sda1>
md: raid1 personality registered for level 1
raid1: raid set md0 active with 4 out of 4 mirrors
EXT3 FS on dm-0, internal journal
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev dm-2, type ext3), uses xattr
kjournald starting. Commit interval 5 seconds
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev md0, type ext3), uses xattr
Adding 4194296k swap on /dev/all/swap. Priority:-1 extents:1 across:4194296k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (8192 buckets, 65536 max)
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Mobile IPv6
eth1: setting full-duplex.
eth2: setting full-duplex.
eth0: no IPv6 routers present
audit(1186467437.499:4): avc: denied { search } for pid=2244 comm="sm-notify" scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:object_r:sysctl_fs_t:s0 tclass=dir
audit(1186467437.533:5): avc: denied { search } for pid=2243 comm="rpc.statd" scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:object_r:sysctl_fs_t:s0 tclass=dir
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
eth1: no IPv6 routers present
eth2: no IPv6 routers present
* .config
i dont have it, it was the standard fedora one.
i'm not sure that the problem is related to 3com, because i replaced those cards by old card i had in spare :
01:06.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42)
01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
and i had the exact same problem.
Those 3com cards were working 24/24 before i went to fedora 7 (and kernel 2.6.21 then).
jb
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Marcin Ślusarz @ 2007-08-07 7:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jarek Poplawski, Thomas Gleixner, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <20070806070300.GA4509@elte.hu>
2007/8/6, Ingo Molnar <mingo@elte.hu>:
> (..)
> please try Jarek's second patch too - there was a missing unmask.
>
> Ingo
>
> -------------->
> Subject: genirq: fix simple and fasteoi irq handlers
> From: Jarek Poplawski <jarkao2@o2.pl>
>
> After the "genirq: do not mask interrupts by default" patch interrupts
> should be disabled not immediately upon request, but after they happen.
> But, handle_simple_irq() and handle_fasteoi_irq() can skip this once or
> more if an irq is just serviced (IRQ_INPROGRESS), possibly disrupting a
> driver's work.
>
> The main reason of problems here, pointing the broken patch and making
> the first patch which can fix this was done by Marcin Slusarz.
> Additional test patches of Thomas Gleixner and Ingo Molnar tested by
> Marcin Slusarz helped to narrow possible reasons even more. Thanks.
>
> PS: this patch fixes only one evident error here, but there could be
> more places affected by above-mentioned change in irq handling.
>
> PS 2:
> After rethinking, IMHO, there are two most probable scenarios here:
>
> 1. After hw resend there could be a conflict between retriggered
> edge type irq and the next level type one: e.g. if this level type
> irq (io_apic is enabled then) is triggered while retriggered irq is
> serviced (IRQ_INPROGRESS) there is goto out with eoi, and probably
> the next such levels are triggered and looping, so probably kind of
> flood in io_apic until this retriggered edge service has ended.
> 2. There is something wrong with ioapic_retrigger_irq (less probable
> because this should be probably seen with 'normal' edge retriggers,
> but on the other hand, they could be less common).
>
> So, if there is #1, this fixed patch should work.
>
> But, since level types don't need this retriggers too much I think
> this "don't mask interrupts by default" idea should be rethinked:
> is there enough gain to risk such hard to diagnose errors?
>
> So, IMHO, there should be at least possibility to turn this off for
> level types in config (it should be a visible option, so people could
> find & try this before writing for help or changing a network card).
>
>
> Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
>
> ---
>
> diff -Nurp 2.6.23-rc1-/kernel/irq/chip.c 2.6.23-rc1/kernel/irq/chip.c
> --- 2.6.23-rc1-/kernel/irq/chip.c 2007-07-09 01:32:17.000000000 +0200
> +++ 2.6.23-rc1/kernel/irq/chip.c 2007-08-05 21:49:46.000000000 +0200
> @@ -295,12 +295,11 @@ handle_simple_irq(unsigned int irq, stru
>
> spin_lock(&desc->lock);
>
> - if (unlikely(desc->status & IRQ_INPROGRESS))
> - goto out_unlock;
> kstat_cpu(cpu).irqs[irq]++;
>
> action = desc->action;
> - if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
> + if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |
> + IRQ_DISABLED)))) {
> if (desc->chip->mask)
> desc->chip->mask(irq);
> desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
> @@ -318,6 +317,8 @@ handle_simple_irq(unsigned int irq, stru
>
> spin_lock(&desc->lock);
> desc->status &= ~IRQ_INPROGRESS;
> + if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
> + desc->chip->unmask(irq);
> out_unlock:
> spin_unlock(&desc->lock);
> }
> @@ -392,18 +393,16 @@ handle_fasteoi_irq(unsigned int irq, str
>
> spin_lock(&desc->lock);
>
> - if (unlikely(desc->status & IRQ_INPROGRESS))
> - goto out;
> -
> desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
> kstat_cpu(cpu).irqs[irq]++;
>
> /*
> - * If its disabled or no action available
> + * If it's running, disabled or no action available
> * then mask it and get out of here:
> */
> action = desc->action;
> - if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
> + if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |
> + IRQ_DISABLED)))) {
> desc->status |= IRQ_PENDING;
> if (desc->chip->mask)
> desc->chip->mask(irq);
> @@ -420,6 +419,8 @@ handle_fasteoi_irq(unsigned int irq, str
>
> spin_lock(&desc->lock);
> desc->status &= ~IRQ_INPROGRESS;
> + if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
> + desc->chip->unmask(irq);
> out:
> desc->chip->eoi(irq);
>
>
Network card still locks up (tested on 2.6.22.1). I had to upload more
data than usual (~350 MB vs ~1-100 MB) to trigger that bug but it
might be a coincidence...
Marcin
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-07 7:26 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Jean-Baptiste Vignaud, mingo, marcin.slusarz, tglx, torvalds,
linux-kernel, shemminger, linux-net, netdev, akpm, alan
In-Reply-To: <46B79047.4060402@redhat.com>
On Mon, Aug 06, 2007 at 05:19:03PM -0400, Chuck Ebbert wrote:
> On 08/06/2007 04:42 PM, Jean-Baptiste Vignaud wrote:
> > Mmm, bad news, after 4 hours of intensive network stressing, one of the 2 3com card failed with the latest fedora kernel.
> >
> > Aug 6 22:31:09 loki kernel: NETDEV WATCHDOG: eth2: transmit timed out
> > Aug 6 22:31:09 loki kernel: eth2: transmit timed out, tx_status 00 status e601.
> > Aug 6 22:31:09 loki kernel: diagnostics: net 0ccc media 8880 dma 0000003a fifo 8000
> > Aug 6 22:31:09 loki kernel: eth2: Interrupt posted but not delivered -- IRQ blocked by another device?
> > Aug 6 22:31:09 loki kernel: Flags; bus-master 1, dirty 26085000(8) current 26085000(8)
> > Aug 6 22:31:09 loki kernel: Transmit list 00000000 vs. ffff81007c807700.
> >
> > Stressing eth2 by copying large files on a samba on share and eth0 by downloading big files on the internet.
>
> So even the full revert doesn't fix the 3Com driver, it just makes it less
> likely to do that.
>
> The other patch probably won't be any better -- I'd guess there's some
> kind of IRQ handling bug in that driver.
>
I don't know how fast are these 3com chips regarding these 8390
described by Alan, and how are irqs shared on Jean-Baptiste's box,
but I'm surprised they could have worked sharing interrupts and
without such time outs before this change in 2.6.21. It seems some
of those older chips, because of slowness, could have transmit
problems even without irq sharing. So, IMHO, if possible, there
should be never irq sharing enabled between two (or more) drivers
using both disable_irq.
These time out problems were reported long time ago, but I think
it would be nice if this thread could at least remove these new
problems reported only after 2.6.21, which it seems is possible
now, after Marcin's diagnose: by reverting the whole 2.6.21 patch
or by this current temporary patch in 2.6.23-rc2's resend.c.
It would be nice if you could try this patch too.
BTW: Jean-Babtiste, could you send or point to you current configs?
I mean at least proc/interrupts, but with dmesg and .config it would
be even better. (I assume this last report was about the revert patch
mentioned by Chuck, not the one below your message?)
Regards,
Jarek P.
^ permalink raw reply
* IPsec IPv4 over IPv6 Problem: No route to host
From: Toshiyuki Okamoto @ 2007-08-07 6:55 UTC (permalink / raw)
To: netdev
Problem about IPsec IPv4 over IPv6, which is included in kernel 2.6.21.
A IPv6 global address is assigned for eth1 by DHCPv6 IA-PD. This case,
IPsec SA is successfully established but packets cannot been sent to WAN.
I do ping, this error occured:
$ ping: sendmsg: No route to host
Do someone know about this issue ?
Network is figured below:
LAN WAN LAN
|------ GW-1 -------|
| eth1 eth0 |
|------ GW-2 -------|
| eth0 eth1 |
|
・GW-1
eth0 Link encap:Ethernet HWaddr 00:11:43:AC:60:AF
inet6 addr: fe80::211:43ff:feac:60af/64 Scope:Link
eth1 Link encap:Ethernet HWaddr 00:90:CC:DE:8B:EE
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2001:1::290:ccff:fede:8bee/64 Scope:Global
inet6 addr: fe80::290:ccff:fede:8bee/64 Scope:Link
・GW-2
eth0 Link encap:Ethernet HWaddr 00:11:43:AB:00:8A
inet6 addr: fe80::211:43ff:feab:8a/64 Scope:Link
eth1 Link encap:Ethernet HWaddr 00:90:CC:DE:89:F7
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: 2001:2::290:ccff:fede:89f7/64 Scope:Global
inet6 addr: fe80::290:ccff:fede:89f7/64 Scope:Link
After IKE daemon (racoon2) is booted on GW-1/2, I do ping from GW-1:
$ ping -I 192.168.1.1 192.168.2.1
This case, IKE sequence is successfully done, and IPsec SA is registered.
but ping packet isn't been sent with error above.
The case IPv6 global address is assigned to eth0 manually,
IPv4 over IPv6 packet is sent successfully.
ping6 between GW-1 and GW-2 is okay.
I suspect that IPv6 routing table is not loaded or invalid.
I tried that IPv6 global address is assigned to eth0 manually (which
prefix is varied to GW1/eth0 from GW2/eth0 with appropriate routing
set),
IPv4 over IPv6 packet is not sent successfully.
Toshiyuki Okamoto (okamoso at gmail.com)
^ permalink raw reply
* Re: [PATCH] e1000e: New pci-express e1000 driver (currently for ICH9 devices only)
From: Arjan van de Ven @ 2007-08-07 5:37 UTC (permalink / raw)
To: Kok, Auke; +Cc: Andi Kleen, Jeff Garzik, NetDev, Andrew Morton, Ronciak, John
In-Reply-To: <46B7F421.1020509@intel.com>
Kok, Auke wrote:
> Andi Kleen wrote:
>> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>>
>>> All,
>>>
>>> Another update on e1000e. Many thanks to Jeff for helping out and
>>> getting this going forward. The driver is unfortunately still too
>>> large to post, so please use the URL's below to review:
>>
>> Just some things I noticed; no comprehensive review
>
> thanks, quick reply to one of the issues below, others I'll take into
> account and look into deeper.
>
>
>> + mod_timer(&adapter->blink_timer, jiffies + E1000_ID_INTERVAL);
>> Should use round_jiffies to avoid wakeups
>
> actually, not here - we don't want the led to blink unreliably. If the
> timer gets stalled beyond 1/2 a second and is irregular, you'll never be
> able to identify the proper adapter port in you data center.
>
> remember, this is only used once the user invokes 'ethtool -p'
round_jiffies is regular, except for the first time..
(it's a whole-second only though)
^ permalink raw reply
* Re: [PATCH 3/4 -rev1] Initilize and populate age field
From: Varun Chandramohan @ 2007-08-07 4:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Patrick McHardy, Oliver Hartkopp,
Stephen Hemminger
Hi Eric,
Sorry for the late response. I just need few
clarifications.
*age = timeval_to_sec(&tv);
>>>> + NLA_PUT_U32(skb, RTA_AGE, *age);
>>> here, what happens if sizeof(time_t) is not 4 ?
Did you mean that the above should be like this?
NLA_PUT_U32(skb, RTA_AGE, (unsigned int) *age);
return tv->tv_sec + (tv->tv_usec ? 1 : 0);
is much faster
So can we say that "usec" is *always *< 1000000 ?
Regards,
Varun
^ permalink raw reply
* Re: [PATCH] e1000e: New pci-express e1000 driver (currently for ICH9 devices only)
From: Kok, Auke @ 2007-08-07 4:25 UTC (permalink / raw)
To: Andi Kleen
Cc: Kok, Auke, Jeff Garzik, NetDev, Andrew Morton, Arjan van de Ven,
Ronciak, John
In-Reply-To: <p737io8caai.fsf@bingen.suse.de>
Andi Kleen wrote:
> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>
>> All,
>>
>> Another update on e1000e. Many thanks to Jeff for helping out and
>> getting this going forward. The driver is unfortunately still too
>> large to post, so please use the URL's below to review:
>
> Just some things I noticed; no comprehensive review
thanks, quick reply to one of the issues below, others I'll take into account
and look into deeper.
> + mod_timer(&adapter->blink_timer, jiffies + E1000_ID_INTERVAL);
> Should use round_jiffies to avoid wakeups
actually, not here - we don't want the led to blink unreliably. If the timer
gets stalled beyond 1/2 a second and is irregular, you'll never be able to
identify the proper adapter port in you data center.
remember, this is only used once the user invokes 'ethtool -p'
Auke
^ permalink raw reply
* Re: [PATCH] e1000e: New pci-express e1000 driver (currently for ICH9 devices only)
From: Andi Kleen @ 2007-08-07 3:07 UTC (permalink / raw)
To: Kok, Auke
Cc: Jeff Garzik, NetDev, Andrew Morton, Arjan van de Ven,
Ronciak, John
In-Reply-To: <46B79934.8010405@intel.com>
"Kok, Auke" <auke-jan.h.kok@intel.com> writes:
> All,
>
> Another update on e1000e. Many thanks to Jeff for helping out and
> getting this going forward. The driver is unfortunately still too
> large to post, so please use the URL's below to review:
Just some things I noticed; no comprehensive review
+static void e1000_clear_hw_cntrs_82571(struct e1000_hw *hw)
+{
+ u32 temp;
+
+ e1000_clear_hw_cntrs_base(hw);
Would be much nicer with a table and a loop. Same in similar functions.
+ tx_ring->buffer_info[i].dma =
+ pci_map_single(pdev, skb->data, skb->len,
+ PCI_DMA_TODEVICE);
Misses error handling. Multiple occurrences.
+ rx_ring->desc = pci_alloc_consistent(pdev, rx_ring->size,
+ &rx_ring->dma);
If you use dma_alloc_coherent and don't hold a lock (I think you do
not) you could specify GFP_KERNEL and be more reliable. p_a_c()
unfortunately defaults to flakey GFP_ATOMIC for historical reasons
Multiple occurrences.
+ skb = alloc_skb(2048 + NET_IP_ALIGN, GFP_KERNEL);
alloc_skb already aligns to the next cache line, more might be not needed.
The allocation is quite wasteful because you'll get a full 4K page with
most of it unused.
I remember this being discussed some time ago; it's sad even newer e1000
problems still have the same issue
It's unclear why you clear the skbs here.
+ } while (good_cnt < 64 && jiffies < (time + 20));
Doesn't handle jiffies wrap; use time_*
More occurrences all over.
+ mod_timer(&adapter->blink_timer, jiffies + E1000_ID_INTERVAL);
Should use round_jiffies to avoid wakeups
+s32 e1000_get_bus_info_pcie(struct e1000_hw *hw)
A couple of drivers have similar functions. Should be really put
into a generic function into the PCI layer instead of reinventing the wheel.
+ if (ret_val)
+ goto out;
...
+out:
+ return ret_val;
Totally unnecessary goto. Lots of occurrences.
/* Force memory writes to complete before letting h/w
+ * know there are new descriptors to fetch. (Only
+ * applicable for weak-ordered memory model archs,
+ * such as IA-64). */
+ wmb();
That is not what a memory barrier does. It just orders the writes,
but doesn't actually flush them.
+ /* Make buffer alignment 2 beyond a 16 byte boundary
+ * this will result in a 16 byte aligned IP header after
+ * the 14 byte MAC header is removed
+ */
+ skb_reserve(skb, NET_IP_ALIGN);
At least on x86 (or other architectures with cheap unalignment
support) it seems like a bad trade off :- it forces the NIC to
do R-M-W to get these 14 bytes and it doesn't help the CPU
too much.
Have you tried if performance improves if the beginning is just
cache line aligned?
+ /* It must be a TCP or UDP packet with a valid checksum */
You could set skb->protocol then if you know.
If the hw also tells you if the packet was unicast for you then
you could also set skb->pkt_type and avoid an early cache miss.
In general you don't seem to care about PCI posting too much.
I guess it's ok on Intel chipsets, but other chipsets do buffer
a lot.
>E1000_SUCCESS everywhere
It is weird to have an own define for this. How about just 0 as
the rest of the kernel?
+ prefetch(skb->data - NET_IP_ALIGN);
The minus is useless.
+ prefetch(next_rxd);
Should be probably prefetchw
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ memcpy(new_skb->data - NET_IP_ALIGN,
+ skb->data - NET_IP_ALIGN,
+ length + NET_IP_ALIGN);
Lots of effort to copy useless padding.
-Andi
^ permalink raw reply
* Re: e100 (was: eepro100) - Nobody Cares (hardware?)
From: Kok, Auke @ 2007-08-07 0:45 UTC (permalink / raw)
To: ericj; +Cc: Jeff Garzik, NetDev
In-Reply-To: <20070806205908.M61217@ericj.net>
[moving to netdev mailinglist]
ericj wrote:
> On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
>> On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
>>> eepro100 is going to be removed. Please try e100 on 2.6.22 or
>>> 2.6.23-rc2.
>
>> I will give the 2.6.23 a try.
>
> I tried 2.6.23-rc2 and there was no change.
>
> There is now some question from the hardware guys about whether the
> eeproms were properly configured before shipping the boards. Is there
> any documentation of the eeprom on an EE Pro 100 VE (ICH4) so that I can
> figure out if any of the settings in there might be causing the problem?
>
> The only fields I know of for sure are the MAC address at the beginning
> and the checksum at the end. I also see from the driver code that there
> is at least one byte controlling wake-on-lan, which I don't care about -
> unless it's the problem.
>
> Thanks for ethtool, by the way. It's been helpful in looking at this and
> comparing the eeprom to an earlier version of the board that works.
Eric,
please don't forget that an entire team here at Intel is dedicated to supporting
e100 and pro/1000 devices from Intel.
Most of the pro/100 features are documented in the SDM which contains some
references to the eeprom parts. Mostly the device doesn't need much
configuration from the eeprom to work (unlike gigE parts). The SDM can be
downloaded from our sf.net project page:
http://sourceforge.net/project/showfiles.php?group_id=42302&package_id=68544
The issue that you are reporting:
"My system boots fine but when I try to bring up the onboard ethernet (an
EEPro 100 VE) I get a "Nobody Cares" message and the interrupt is disabled."
However has been recently patched. This should have worked regardless of whether
you used e100 or eepro100 (noting that nobody supports eepro100 anymore, you
should really use e100 for all tests).
if you look in drivers/pci/quirks.c you'll find that there is specific code for
e100 devices. If this quirk doesn't work for you then we'll need to dig into
that. For this I'd like you to gather:
- `ethtool -e eth0` output
- `lspci -n` output
this will allow me to check the quirck code and see if it has the right device
ID. I'm suspecting that the device ID is missing somehow, or the workaround fails.
Auke
^ permalink raw reply
* Re: [PATCH] drivers/net/wireless/wl3501_cs.c: remove redundant memset
From: John W. Linville @ 2007-08-07 0:11 UTC (permalink / raw)
To: Mariusz Kozlowski
Cc: acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe, Jeff Garzik,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200708070050.23158.m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org>
Please send wireless patches to linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
and CC me.
Thanks!
John
On Tue, Aug 07, 2007 at 12:50:22AM +0200, Mariusz Kozlowski wrote:
> Hello,
>
> This memset() looks superfluous.
>
> Signed-off-by: Mariusz Kozlowski <m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org>
>
> drivers/net/wireless/wl3501_cs.c | 58885 -> 58858 (-27 bytes)
> drivers/net/wireless/wl3501_cs.o | 200252 -> 200000 (-252 bytes)
>
> drivers/net/wireless/wl3501_cs.c | 1 -
> 1 file changed, 1 deletion(-)
>
> --- linux-2.6.23-rc1-mm2-a/drivers/net/wireless/wl3501_cs.c 2007-08-01 08:43:46.000000000 +0200
> +++ linux-2.6.23-rc1-mm2-b/drivers/net/wireless/wl3501_cs.c 2007-08-07 00:34:36.000000000 +0200
> @@ -1841,7 +1841,6 @@ static int wl3501_get_encode(struct net_
> tocopy = min_t(u8, len_keys, wrqu->encoding.length);
> tocopy = min_t(u8, tocopy, 100);
> wrqu->encoding.length = tocopy;
> - memset(extra, 0, tocopy);
> memcpy(extra, keys, tocopy);
> out:
> return rc;
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* [PATCH] drivers/net/wireless/wl3501_cs.c: remove redundant memset
From: Mariusz Kozlowski @ 2007-08-06 22:50 UTC (permalink / raw)
To: acme, Jeff Garzik; +Cc: netdev, linux-kernel
Hello,
This memset() looks superfluous.
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
drivers/net/wireless/wl3501_cs.c | 58885 -> 58858 (-27 bytes)
drivers/net/wireless/wl3501_cs.o | 200252 -> 200000 (-252 bytes)
drivers/net/wireless/wl3501_cs.c | 1 -
1 file changed, 1 deletion(-)
--- linux-2.6.23-rc1-mm2-a/drivers/net/wireless/wl3501_cs.c 2007-08-01 08:43:46.000000000 +0200
+++ linux-2.6.23-rc1-mm2-b/drivers/net/wireless/wl3501_cs.c 2007-08-07 00:34:36.000000000 +0200
@@ -1841,7 +1841,6 @@ static int wl3501_get_encode(struct net_
tocopy = min_t(u8, len_keys, wrqu->encoding.length);
tocopy = min_t(u8, tocopy, 100);
wrqu->encoding.length = tocopy;
- memset(extra, 0, tocopy);
memcpy(extra, keys, tocopy);
out:
return rc;
^ permalink raw reply
* [PATCH 2/2] r8169: avoid needless NAPI poll scheduling
From: Francois Romieu @ 2007-08-06 22:22 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, akpm, Edward Hsu, Andy Gospodarek
In-Reply-To: <20070806221612.GA23302@electric-eye.fr.zoreil.com>
Theory : though needless, it should not have hurt.
Practice: it does not play nice with DEBUG_SHIRQ + LOCKDEP + UP
(see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242572).
The patch makes sense in itself but I should dig why it has an effect
on #242572 (assuming that NAPI do not change in a near future).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ec4f545..631e55d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2767,14 +2767,16 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
rtl8169_check_link_status(dev, tp, ioaddr);
#ifdef CONFIG_R8169_NAPI
- RTL_W16(IntrMask, tp->intr_event & ~tp->napi_event);
- tp->intr_mask = ~tp->napi_event;
-
- if (likely(netif_rx_schedule_prep(dev)))
- __netif_rx_schedule(dev);
- else if (netif_msg_intr(tp)) {
- printk(KERN_INFO "%s: interrupt %04x taken in poll\n",
- dev->name, status);
+ if (status & tp->napi_event) {
+ RTL_W16(IntrMask, tp->intr_event & ~tp->napi_event);
+ tp->intr_mask = ~tp->napi_event;
+
+ if (likely(netif_rx_schedule_prep(dev)))
+ __netif_rx_schedule(dev);
+ else if (netif_msg_intr(tp)) {
+ printk(KERN_INFO "%s: interrupt %04x in poll\n",
+ dev->name, status);
+ }
}
break;
#else
--
1.4.4.2
^ permalink raw reply related
* [PATCH 1/2] r8169: PHY power-on fix
From: Francois Romieu @ 2007-08-06 22:21 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, akpm, Roger So, Edward Hsu
In-Reply-To: <20070806221612.GA23302@electric-eye.fr.zoreil.com>
Fix extracted from Realtek's driver (8.002.00/20070713) for the PHY
attached to 8111/8168b chipsets.
The check against mac_version is just usual paranoia during the bugfix
period of the kernel cycle. -- FR
Tested on Asus M2A-VM motherboard by Roger So.
No regression on my Asrock 945G DVI either (built-in 8168 + 2x8169).
Signed-off-by: Roger So <roger.so@gmail.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index bb6896a..ec4f545 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -725,6 +725,12 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
+ if (tp->mac_version == RTL_GIGA_MAC_VER_12) {
+ /* Vendor specific (0x1f) and reserved (0x0e) MII registers. */
+ mdio_write(ioaddr, 0x1f, 0x0000);
+ mdio_write(ioaddr, 0x0e, 0x0000);
+ }
+
tp->phy_auto_nego_reg = auto_nego;
tp->phy_1000_ctrl_reg = giga_ctrl;
--
1.4.4.2
^ permalink raw reply related
* [PATCH 0/2] r8169: pull request for 'r8169-for-jeff-20070806' branch
From: Francois Romieu @ 2007-08-06 22:16 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, akpm
Please pull from branch 'r8169-for-jeff-20070806' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git r8169-for-jeff-20070806
to get the changes below.
Distance from 'upstream-fixes' (c196d80f994ef4ffefd5a7c62e3f42bd75d538bc)
-------------------------------------------------------------------------
313b0305b5a1e7e0fb39383befbf79558ce68a9c
2584fbc3a61897de5eddd56b39a4fa9cd074eca2
Diffstat
--------
drivers/net/r8169.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
Shortlog
--------
Francois Romieu (1):
r8169: avoid needless NAPI poll scheduling
Roger So (1):
r8169: PHY power-on fix
Patch
-----
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index bb6896a..631e55d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -725,6 +725,12 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
+ if (tp->mac_version == RTL_GIGA_MAC_VER_12) {
+ /* Vendor specific (0x1f) and reserved (0x0e) MII registers. */
+ mdio_write(ioaddr, 0x1f, 0x0000);
+ mdio_write(ioaddr, 0x0e, 0x0000);
+ }
+
tp->phy_auto_nego_reg = auto_nego;
tp->phy_1000_ctrl_reg = giga_ctrl;
@@ -2761,14 +2767,16 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
rtl8169_check_link_status(dev, tp, ioaddr);
#ifdef CONFIG_R8169_NAPI
- RTL_W16(IntrMask, tp->intr_event & ~tp->napi_event);
- tp->intr_mask = ~tp->napi_event;
-
- if (likely(netif_rx_schedule_prep(dev)))
- __netif_rx_schedule(dev);
- else if (netif_msg_intr(tp)) {
- printk(KERN_INFO "%s: interrupt %04x taken in poll\n",
- dev->name, status);
+ if (status & tp->napi_event) {
+ RTL_W16(IntrMask, tp->intr_event & ~tp->napi_event);
+ tp->intr_mask = ~tp->napi_event;
+
+ if (likely(netif_rx_schedule_prep(dev)))
+ __netif_rx_schedule(dev);
+ else if (netif_msg_intr(tp)) {
+ printk(KERN_INFO "%s: interrupt %04x in poll\n",
+ dev->name, status);
+ }
}
break;
#else
--
Ueimor
^ permalink raw reply related
* Re: Please pull 'libertas-upstream' branch of wireless-2.6
From: Dan Williams @ 2007-08-06 22:10 UTC (permalink / raw)
To: John W. Linville
Cc: jeff-o2qLIJkoznsdnm+yROfE0A,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070806203005.GL6442-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Mon, 2007-08-06 at 16:30 -0400, John W. Linville wrote:
> Got a big patch bomb from the libertas guys. I tried to cherry-pick
> some of the fixes for 2.6.23, but they either were fixes to problems
> in new code or all the code cleanups made them difficult for me to
> intelligently backport.
>
> So, this is intended for 2.6.24...
Sounds fine to me... we did miss the merge window :)
Dan
>
> ---
>
> The following changes since commit d4ac2477fad0f2680e84ec12e387ce67682c5c13:
> Linus Torvalds (1):
> Linux 2.6.23-rc2
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git libertas-upstream
>
> Dan Williams (27):
> libertas: kill ieeetypes_capinfo bitfield, use ieee80211.h types
> libertas: rename WLAN_802_11_KEY to enc_key and clean up usage
> libertas: clean up indentation in libertas_association_worker
> libertas: clean up 802.11 IE post-scan handling
> libertas: remove if_bootcmd.c
> libertas: fix mixed-case abuse in cmd_ds_802_11_scan
> libertas: fix mixed-case abuse in cmd_ds_802_11_ad_hoc_result
> libertas: fix mixed-case abuse in cmd_ds_802_11_ad_hoc_start
> libertas: re-uppercase command defines and other constants
> libertas: fix debug build breakage due to field rename
> libertas: remove thread.h and make kthread usage clearer
> libertas: new mesh control knobs
> libertas: bump version to 322.p1
> libertas: fix more mixed-case abuse
> libertas: move generic firmware reset command to common code
> libertas: wlan_ -> libertas_ function prefix renames for main.c
> libertas: simplify and clean up data rate handling
> libertas: fix WEXT quality reporting
> libertas: send association events on adhoc reassociation
> libertas: push mesh beacon bit to userspace in scan results
> libertas: fix assignment of WEP key type
> libertas: push WEXT scan requests to a work queue
> libertas: fix misspelling in debug message
> libertas: ignore spurious mesh autostart events
> libertas: better descriptions for association errors
> libertas: fix sparse-reported problems
> libertas: bump driver version
>
> Eugene Teo (1):
> drivers/net/wireless/libertas/cmd.c: fix adapter->driver_lock dereference
>
> Holger Schurig (33):
> libertas: remove fw.c
> libertas: fix one more sparse warning
> libertas: make more functions static & remove unused functions
> libertas: uppercase some #defines
> libertas: access mesh_dev more carefully
> libertas: tune hardware info output
> libertas: remove debugmode
> libertas: make the hex dumper nicer
> libertas: remove a hundred CMD_RET_xxx definitions
> libertas: use LBS_DEB_HOST for host-to-card communications
> libertas: use LBS_DEB_HOST for host-to-card communications
> add support for Marvell 8385 CF cards
> libertas: remove unused adapter->prev_XXXX variables
> libertas: remove adapter->{rx,tx}antenna
> libertas: remove adapter->prescan
> libertas: remove adapter->scanprobes
> libertas: remove adapter->pkttxctrl
> libertas: remove adapter->txrate
> libertas: remove adapter->rxpd_rate
> libertas: remove adapter->{data,bcn}_avg_factor
> libertas: remove adapter->nullpktinterval
> libertas: remove adapter->locallisteninterval
> libertas: remove adapter->multipledtim
> libertas: remove adapter->atimwindow
> libertas: remove adapter->regiontableindex
> libertas: remove adapter->listeninterval
> libertas: remove adapter->adhoc_grate_enabled
> libertas: remove adapter->beaconperiod
> libertas: remove adapter->scanmode
> libertas: remove adapter->scantype
> libertas: remove bss_descriptior->networktsf
> libertas: remove bss_descriptor->timestamp
> libertas: fix two debug statements in cmdresp.c
>
> Jean Tourrilhes (1):
> libertas: fix a few wext abuses...
>
> Luis Carlos Cobo (7):
> libertas: specific mesh scan for mshX interface
> Support for mesh autostart deactivation through sysfs
> libertas: Avoid MESH_AUTOSTARTED spam on console
> libertas: revert CAPINFO_MASK to its original value
> libertas: keep mesh autostart enabled while asleep
> libertas: monitor mode support for OLPC firmware
> libertas: pass boot2 version to firmware
>
> drivers/net/wireless/Kconfig | 7 +
> drivers/net/wireless/Makefile | 2 +-
> drivers/net/wireless/libertas/11d.c | 124 ++---
> drivers/net/wireless/libertas/11d.h | 4 -
> drivers/net/wireless/libertas/Makefile | 5 +-
> drivers/net/wireless/libertas/assoc.c | 99 ++--
> drivers/net/wireless/libertas/assoc.h | 2 +-
> drivers/net/wireless/libertas/cmd.c | 664 +++++++++---------
> drivers/net/wireless/libertas/cmdresp.c | 368 +++++------
> drivers/net/wireless/libertas/debugfs.c | 137 ++--
> drivers/net/wireless/libertas/decl.h | 18 +-
> drivers/net/wireless/libertas/defs.h | 157 +++---
> drivers/net/wireless/libertas/dev.h | 77 +--
> drivers/net/wireless/libertas/ethtool.c | 8 +-
> drivers/net/wireless/libertas/fw.c | 349 ----------
> drivers/net/wireless/libertas/host.h | 445 ++++++-------
> drivers/net/wireless/libertas/hostcmd.h | 81 +--
> drivers/net/wireless/libertas/if_bootcmd.c | 40 --
> drivers/net/wireless/libertas/if_cs.c | 1005 ++++++++++++++++++++++++++++
> drivers/net/wireless/libertas/if_usb.c | 209 +++++--
> drivers/net/wireless/libertas/if_usb.h | 4 -
> drivers/net/wireless/libertas/join.c | 474 +++++++------
> drivers/net/wireless/libertas/join.h | 35 +-
> drivers/net/wireless/libertas/main.c | 752 ++++++++++++++++++----
> drivers/net/wireless/libertas/rx.c | 85 +--
> drivers/net/wireless/libertas/scan.c | 585 +++++++----------
> drivers/net/wireless/libertas/scan.h | 36 +-
> drivers/net/wireless/libertas/thread.h | 52 --
> drivers/net/wireless/libertas/tx.c | 41 +-
> drivers/net/wireless/libertas/types.h | 67 +--
> drivers/net/wireless/libertas/wext.c | 391 ++++--------
> drivers/net/wireless/libertas/wext.h | 9 +-
> 32 files changed, 3512 insertions(+), 2820 deletions(-)
> delete mode 100644 drivers/net/wireless/libertas/fw.c
> delete mode 100644 drivers/net/wireless/libertas/if_bootcmd.c
> create mode 100644 drivers/net/wireless/libertas/if_cs.c
> delete mode 100644 drivers/net/wireless/libertas/thread.h
^ permalink raw reply
* [PATCH] e1000e: New pci-express e1000 driver (currently for ICH9 devices only)
From: Kok, Auke @ 2007-08-06 21:57 UTC (permalink / raw)
To: Jeff Garzik, NetDev
Cc: Andrew Morton, Arjan van de Ven, Ronciak, John, Auke Kok
All,
Another update on e1000e. Many thanks to Jeff for helping out and getting this
going forward. The driver is unfortunately still too large to post, so please
use the URL's below to review:
http://foo-projects.org/~sofar/e1000e-20070806.patch [525k]
http://foo-projects.org/~sofar/e1000e-20070806.patch.bz2 [90k]
git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000e-20070806
Please note that the non-ICH9 device IDs are disabled, but this driver will
(once you put them back in) properly work with all the current pci-e adapters
that e1000 supports. Once this driver gets merged we'll move those devices over
one by one.
Cheers,
Auke
---
From: Auke Kok <auke-jan.h.kok@intel.com>
Date: Mon, 6 Aug 2007 14:14:44 -0700
Subject: [PATCH] e1000e: New pci-express e1000 driver (currently for ICH9
devices only)
This driver implements support for the ICH9 on-board LAN ethernet
device. The device is similar to ICH8.
The driver encompasses code to support 82571/2/3, es2lan and ICH8
devices as well, but those device IDs are disabled and will be
"lifted" from the e1000 driver over one at a time once this driver
receives some more live time.
Changes to the last snapshot posted are exclusively in the internal
hardware API organization. Many thanks to Jeff Garzik for jumping in
and getting this organized with a keen eye on the future layout.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/Kconfig | 23 +
drivers/net/Makefile | 1 +
drivers/net/e1000e/82571.c | 1382 +++++++++++++
drivers/net/e1000e/Makefile | 37 +
drivers/net/e1000e/defines.h | 738 +++++++
drivers/net/e1000e/e1000.h | 518 +++++
drivers/net/e1000e/es2lan.c | 1255 ++++++++++++
drivers/net/e1000e/ethtool.c | 1763 +++++++++++++++++
drivers/net/e1000e/hw.h | 862 +++++++++
drivers/net/e1000e/ich8lan.c | 2297 ++++++++++++++++++++++
drivers/net/e1000e/lib.c | 2528 ++++++++++++++++++++++++
drivers/net/e1000e/netdev.c | 4413 ++++++++++++++++++++++++++++++++++++++++++
drivers/net/e1000e/param.c | 382 ++++
drivers/net/e1000e/phy.c | 1821 +++++++++++++++++
14 files changed, 18020 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/e1000e/82571.c
create mode 100644 drivers/net/e1000e/Makefile
create mode 100644 drivers/net/e1000e/defines.h
create mode 100644 drivers/net/e1000e/e1000.h
create mode 100644 drivers/net/e1000e/es2lan.c
create mode 100644 drivers/net/e1000e/ethtool.c
create mode 100644 drivers/net/e1000e/hw.h
create mode 100644 drivers/net/e1000e/ich8lan.c
create mode 100644 drivers/net/e1000e/lib.c
create mode 100644 drivers/net/e1000e/netdev.c
create mode 100644 drivers/net/e1000e/param.c
create mode 100644 drivers/net/e1000e/phy.c
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox