* Re: [PATH][RFC] acxsm: Make acx mdoular again
From: John W. Linville @ 2006-02-28 1:34 UTC (permalink / raw)
To: Carlos Martín
Cc: Denis Vlasenko, netdev, acx100-devel, Christoph Hellwig
In-Reply-To: <200602271144.39346.carlos@cmartin.tk>
On Mon, Feb 27, 2006 at 11:44:38AM +0100, Carlos Martín wrote:
> On Monday 27 February 2006 11:20, Denis Vlasenko wrote:
> > > Comments are welcome and I'll split the patch if needed.
Denis are you applying this patch to your tree? If so, I'll rely on
you to push it to me when you are ready.
If not, then I will need Carlos to generate the diffs so that they
can be applied to the top of the tree with -p1.
http://linux.yyz.us/patch-format.html
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
^ permalink raw reply
* Re: [PATCH] e1000: Support e1000 OEMed onto Aculab cards
From: John Ronciak @ 2006-02-28 0:31 UTC (permalink / raw)
To: cramerj, john.ronciak, netdev, linux-kernel, broonie
In-Reply-To: <20060227220517.GA8611@sirena.org.uk>
Please don't apply this patch. We have taken this offline at the
moment to work this out with the OEM, Aculab. They have made
modification to how the Intel controller operates which may make it
have problems with the normal e1000 driver. We are in contact with
both Mark and Aculab about this offline. The last thing Aculab talked
to us about was to make sure that the normal Intel e1000 drivers did
_not_ work with their hardware, hence the device ID change. We'll
continue this on this thread if this turns out not to be the case. We
(Intel) also don't know exactly how they changed the behavior of the
hardware which is another topic for us to talk about.
Thanks.
--
Cheers,
John
^ permalink raw reply
* [patch 04/39] [PATCH] [BRIDGE]: netfilter missing symbol has_bridge_parent
From: Chris Wright @ 2006-02-27 22:32 UTC (permalink / raw)
To: linux-kernel, stable, Bernard Pidoux
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, torvalds, akpm, alan, Horms, wensong,
netdev, ja, David S. Miller, Stephen Hemminger,
Greg Kroah-Hartman
In-Reply-To: <20060227223200.865548000@sorel.sous-sol.org>
[-- Attachment #1: netfilter-missing-symbol.patch --]
[-- Type: text/plain, Size: 1204 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
5dce971acf2ae20c80d5e9d1f6bbf17376870911 in Linus' tree,
otherwise known as bridge-netfilter-races-on-device-removal.patch in
2.5.15.4 removed has_bridge_parent, however this symbol is still
called with NETFILTER_DEBUG is enabled.
This patch uses the already seeded realoutdev value to detect if a parent
exists, and if so, the value of the parent.
Signed-Off-By: Horms <horms@verge.net.au>
Acked-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/bridge/br_netfilter.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.15.4.orig/net/bridge/br_netfilter.c
+++ linux-2.6.15.4/net/bridge/br_netfilter.c
@@ -794,8 +794,8 @@ static unsigned int br_nf_post_routing(u
print_error:
if (skb->dev != NULL) {
printk("[%s]", skb->dev->name);
- if (has_bridge_parent(skb->dev))
- printk("[%s]", bridge_parent(skb->dev)->name);
+ if (realoutdev)
+ printk("[%s]", realoutdev->name);
}
printk(" head:%p, raw:%p, data:%p\n", skb->head, skb->mac.raw,
skb->data);
--
^ permalink raw reply
* Pull request for 'for-jeff' branch
From: Francois Romieu @ 2006-02-27 22:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, netdev, Pierre Ossman, John Zielinski
In-Reply-To: <4403472F.2090808@pobox.com>
Please pull from branch 'for-jeff' to get the changes below:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
Shortlog
--------
$ git rev-list --pretty master..HEAD | git shortlog
Francois Romieu:
via-velocity: fix memory corruption when changing the mtu
8139cp: fix broken suspend/resume
Patch
-----
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index f822cd3..dd41049 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -1118,13 +1118,18 @@ err_out:
return -ENOMEM;
}
+static void cp_init_rings_index (struct cp_private *cp)
+{
+ cp->rx_tail = 0;
+ cp->tx_head = cp->tx_tail = 0;
+}
+
static int cp_init_rings (struct cp_private *cp)
{
memset(cp->tx_ring, 0, sizeof(struct cp_desc) * CP_TX_RING_SIZE);
cp->tx_ring[CP_TX_RING_SIZE - 1].opts1 = cpu_to_le32(RingEnd);
- cp->rx_tail = 0;
- cp->tx_head = cp->tx_tail = 0;
+ cp_init_rings_index(cp);
return cp_refill_rx (cp);
}
@@ -1886,30 +1891,30 @@ static int cp_suspend (struct pci_dev *p
spin_unlock_irqrestore (&cp->lock, flags);
- if (cp->pdev && cp->wol_enabled) {
- pci_save_state (cp->pdev);
- cp_set_d3_state (cp);
- }
+ pci_save_state(pdev);
+ pci_enable_wake(pdev, pci_choose_state(pdev, state), cp->wol_enabled);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
}
static int cp_resume (struct pci_dev *pdev)
{
- struct net_device *dev;
- struct cp_private *cp;
+ struct net_device *dev = pci_get_drvdata (pdev);
+ struct cp_private *cp = netdev_priv(dev);
unsigned long flags;
- dev = pci_get_drvdata (pdev);
- cp = netdev_priv(dev);
+ if (!netif_running(dev))
+ return 0;
netif_device_attach (dev);
-
- if (cp->pdev && cp->wol_enabled) {
- pci_set_power_state (cp->pdev, PCI_D0);
- pci_restore_state (cp->pdev);
- }
-
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_wake(pdev, PCI_D0, 0);
+
+ /* FIXME: sh*t may happen if the Rx ring buffer is depleted */
+ cp_init_rings_index (cp);
cp_init_hw (cp);
netif_start_queue (dev);
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index c2d5907..ed1f837 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -1106,6 +1106,9 @@ static void velocity_free_rd_ring(struct
for (i = 0; i < vptr->options.numrx; i++) {
struct velocity_rd_info *rd_info = &(vptr->rd_info[i]);
+ struct rx_desc *rd = vptr->rd_ring + i;
+
+ memset(rd, 0, sizeof(*rd));
if (!rd_info->skb)
continue;
^ permalink raw reply related
* [PATCH] e1000: Support e1000 OEMed onto Aculab cards
From: Mark Brown @ 2006-02-27 22:05 UTC (permalink / raw)
To: cramerj, john.ronciak, ganesh.venkatesan; +Cc: netdev, linux-kernel
Add PCI IDs for chips OEMed onto some Aculab cards to the e1000 driver.
Signed-Off-By: Mark Brown <broonie@sirena.org.uk>
Index: e1000-queue/drivers/net/e1000/e1000.h
===================================================================
--- e1000-queue.orig/drivers/net/e1000/e1000.h 2006-02-25 12:50:12.000000000 +0000
+++ e1000-queue/drivers/net/e1000/e1000.h 2006-02-25 13:01:10.000000000 +0000
@@ -84,6 +84,9 @@
#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
+#define ACULAB_E1000_ETHERNET_DEVICE(device_id) {\
+ PCI_DEVICE(PCI_VENDOR_ID_ACULAB, device_id)}
+
struct e1000_adapter;
#include "e1000_hw.h"
Index: e1000-queue/drivers/net/e1000/e1000_main.c
===================================================================
--- e1000-queue.orig/drivers/net/e1000/e1000_main.c 2006-02-25 12:50:12.000000000 +0000
+++ e1000-queue/drivers/net/e1000/e1000_main.c 2006-02-25 13:01:10.000000000 +0000
@@ -98,6 +98,7 @@ static struct pci_device_id e1000_pci_tb
INTEL_E1000_ETHERNET_DEVICE(0x108B),
INTEL_E1000_ETHERNET_DEVICE(0x108C),
INTEL_E1000_ETHERNET_DEVICE(0x109A),
+ ACULAB_E1000_ETHERNET_DEVICE(0x1078),
/* required last entry */
{0,}
};
Index: e1000-queue/include/linux/pci_ids.h
===================================================================
--- e1000-queue.orig/include/linux/pci_ids.h 2006-02-25 12:50:12.000000000 +0000
+++ e1000-queue/include/linux/pci_ids.h 2006-02-25 12:51:51.000000000 +0000
@@ -1572,6 +1572,8 @@
#define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2
#define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018
+#define PCI_VENDOR_ID_ACULAB 0x12d9
+
#define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0
#define PCI_SUBDEVICE_ID_CHASE_PCIFAST4 0x0031
#define PCI_SUBDEVICE_ID_CHASE_PCIFAST8 0x0021
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Jesse Brandeburg @ 2006-02-27 19:26 UTC (permalink / raw)
To: Paul Rolland, Jeff Garzik
Cc: Jesper Juhl, linux-kernel, netdev, cramerj, john.ronciak
In-Reply-To: <01e101c63ae7$1b417990$2001a8c0@cortex>
On 2/26/06, Paul Rolland <rol@witbe.net> wrote:
> Hello,
>
> > Ok, great, I was just wondering since I would have made one if you had
> > no plans to do so.
>
> Well, I was just waiting to make sure it was interesting for someone ;)
>
> Here is it, verified with tab and not spaces... but attached as my mailer
> is likely to cripple anything I try to inline...
>
> Signed-off-by: Paul Rolland <rol@as2917.net>
I've got an issue with this, as the same function is called in
e1000_ethtool.c. I think the correct fix is to fix the caller in the
mii-tool case, but I am working on verifiying my assumptions.
In the meantime can you send the exact command you were having the problem with?
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Carl-Daniel Hailfinger @ 2006-02-27 18:50 UTC (permalink / raw)
To: pomac
Cc: Arjan van de Ven, woho, Stephen Hemminger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <1141001028.23375.14.camel@localhost>
Ian Kumlien schrieb:
> On Sun, 2006-02-26 at 23:38 +0100, Carl-Daniel Hailfinger wrote:
>
>>Ian Kumlien schrieb:
>>
>>>I also saw some oddities... portage stopped working, i dunno if this can
>>>be MSI related or so, else something is trashing memory in a very
>>>special way =P
>>
>>Yes, 0.15 causes memory corruption even if MSI is disabled.
>
>
> So if i run with iommu=forced or what the hell the option is called i
> should be able to catch these trashings?
>
> I also found it odd that it was only python that suffered... Starting
> large and long running C apps worked just fine.
For me, it was usually timer list corruption during boot (50% probability)
or unidentified lockups (probably also timer list corruption) after a few
minutes of operation (40% probability).
Sample Oops message:
Unable to handle kernel NULL pointer dereference at 00000008
rip: run_timer_softirq+322
process udev
Call trace:
__do_softirq+68
call_softirq+30
do_softirq+46
do_IRQ+61
ret_from_intr+0
EOI
Regards,
Carl-Daniel
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Jeff Garzik @ 2006-02-27 18:38 UTC (permalink / raw)
To: pomac
Cc: Stephen Hemminger, woho, Carl-Daniel Hailfinger, Jeff Garzik,
netdev, Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <1141064841.23375.36.camel@localhost>
Ian Kumlien wrote:
> On Mon, 2006-02-27 at 09:18 -0800, Stephen Hemminger wrote:
>
>>On Mon, 27 Feb 2006 17:38:38 +0100
>>Wolfgang Hoffmann <woho@woho.de> wrote:
>>
>>>On Monday 27 February 2006 17:00, Stephen Hemminger wrote:
>>>2.6.16-rc5 with disable_msi=1 works for me, no hangs seen so far. I rsynced 80
>>>GB of data, thats about 5-10 times more than I typically need to reproduce a
>>>hang, so it seems to be solid. For the record: 2.6.16-rc5 with disable_msi=0
>>>does hang.
>>>
>>>I have not seen the memory trashing others reported, with no version I tested
>>>so far. Maybe my scenario is not likely to trigger this, so I can't tell.
>>>
>>>Unless a fix for msi is at hand, may I suggest for 2.6.16 to revert the msi
>>>commit or switch the default to disable_msi=1?
>>>
>>>I've updated bugzilla #6084 accordingly.
>>
>>Okay, then what I need is lspci -v of all systems that have the problem, I'll make
>>a blacklist (or update PCI quirks). I suspect that MSI doesn't work for any devices
>>on these systems, or MSI changes the timing enough to expose existing races.
>
>
> Am i just tired from trying to make XSLT to do something unnatural or is
> there something odd going on in msi.c?
>
> static void msi_set_mask_bit(unsigned int vector, int flag)
> {
> struct msi_desc *entry;
>
> entry = (struct msi_desc *)msi_desc[vector];
> if (!entry || !entry->dev || !entry->mask_base)
> return;
> switch (entry->msi_attrib.type) {
> case PCI_CAP_ID_MSI:
> {
> int pos; <==
> u32 mask_bits;
>
> pos = (long)entry->mask_base; <==
> ...
Just from the casting it seems a bit bogus, yes...
Jeff
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-27 18:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: woho, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <20060227091837.3c214435@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
On Mon, 2006-02-27 at 09:18 -0800, Stephen Hemminger wrote:
> On Mon, 27 Feb 2006 17:38:38 +0100
> Wolfgang Hoffmann <woho@woho.de> wrote:
> > On Monday 27 February 2006 17:00, Stephen Hemminger wrote:
> > 2.6.16-rc5 with disable_msi=1 works for me, no hangs seen so far. I rsynced 80
> > GB of data, thats about 5-10 times more than I typically need to reproduce a
> > hang, so it seems to be solid. For the record: 2.6.16-rc5 with disable_msi=0
> > does hang.
> >
> > I have not seen the memory trashing others reported, with no version I tested
> > so far. Maybe my scenario is not likely to trigger this, so I can't tell.
> >
> > Unless a fix for msi is at hand, may I suggest for 2.6.16 to revert the msi
> > commit or switch the default to disable_msi=1?
> >
> > I've updated bugzilla #6084 accordingly.
>
> Okay, then what I need is lspci -v of all systems that have the problem, I'll make
> a blacklist (or update PCI quirks). I suspect that MSI doesn't work for any devices
> on these systems, or MSI changes the timing enough to expose existing races.
Am i just tired from trying to make XSLT to do something unnatural or is
there something odd going on in msi.c?
static void msi_set_mask_bit(unsigned int vector, int flag)
{
struct msi_desc *entry;
entry = (struct msi_desc *)msi_desc[vector];
if (!entry || !entry->dev || !entry->mask_base)
return;
switch (entry->msi_attrib.type) {
case PCI_CAP_ID_MSI:
{
int pos; <==
u32 mask_bits;
pos = (long)entry->mask_base; <==
...
Doesn't that mean that we, a: read 64 bit from memory. b: save it in a
32 bit area?
(esp since it seems to be a address pointer, which could also be using
higher memory areas... but then i dunno what a void __iomem * is, but i
assume that it will be 64 bits here =))
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Wolfgang Hoffmann @ 2006-02-27 17:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pomac, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <20060227091837.3c214435@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
On Monday 27 February 2006 18:18, Stephen Hemminger wrote:
> Okay, then what I need is lspci -v of all systems that have the problem,
> I'll make a blacklist (or update PCI quirks). I suspect that MSI doesn't
> work for any devices on these systems, or MSI changes the timing enough to
> expose existing races.
lspci -v attached
[-- Attachment #2: lspci.txt --]
[-- Type: text/plain, Size: 9470 bytes --]
0000:00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
Subsystem: AOPEN Inc.: Unknown device 2580
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] #09 [2109]
0000:00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: da200000-da2fffff
Prefetchable memory behind bridge: d0000000-d7ffffff
Capabilities: [88] #0d [0000]
Capabilities: [80] Power Management version 2
Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [a0] #10 [0141]
0000:00:1b.0 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04)
Subsystem: AOPEN Inc.: Unknown device 0560
Flags: bus master, fast devsel, latency 0, IRQ 169
Memory at da300000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Capabilities: [70] #10 [0091]
0000:00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
0000:00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: da000000-da0fffff
Prefetchable memory behind bridge: 0000000088000000-0000000088000000
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
0000:00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 04) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: da100000-da1fffff
Prefetchable memory behind bridge: 0000000088100000-0000000088100000
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
0000:00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 04) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
0000:00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI])
Subsystem: AOPEN Inc.: Unknown device 2658
Flags: bus master, medium devsel, latency 0, IRQ 58
I/O ports at e000 [size=32]
0000:00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI])
Subsystem: AOPEN Inc.: Unknown device 2659
Flags: bus master, medium devsel, latency 0, IRQ 193
I/O ports at e100 [size=32]
0000:00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) (prog-if 00 [UHCI])
Subsystem: AOPEN Inc.: Unknown device 265a
Flags: bus master, medium devsel, latency 0, IRQ 185
I/O ports at e200 [size=32]
0000:00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) (prog-if 00 [UHCI])
Subsystem: AOPEN Inc.: Unknown device 265b
Flags: bus master, medium devsel, latency 0, IRQ 169
I/O ports at e300 [size=32]
0000:00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) (prog-if 20 [EHCI])
Subsystem: AOPEN Inc.: Unknown device 0553
Flags: bus master, medium devsel, latency 0, IRQ 58
Memory at da304000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) (prog-if 01 [Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=06, subordinate=06, sec-latency=32
Memory behind bridge: d8000000-d9ffffff
Capabilities: [50] #0d [0000]
0000:00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
Subsystem: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge
Flags: bus master, medium devsel, latency 0
0000:00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04) (prog-if 8a [Master SecP PriP])
Subsystem: AOPEN Inc.: Unknown device 266f
Flags: bus master, medium devsel, latency 0, IRQ 185
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at f000 [size=16]
0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: AOPEN Inc.: Unknown device 052f
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 193
I/O ports at e400 [size=8]
I/O ports at e500 [size=4]
I/O ports at e600 [size=8]
I/O ports at e700 [size=4]
I/O ports at e800 [size=16]
Memory at da305000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] Power Management version 2
0000:00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04)
Subsystem: AOPEN Inc.: Unknown device 266a
Flags: medium devsel, IRQ 11
I/O ports at 5000 [size=32]
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] (prog-if 00 [VGA])
Subsystem: PC Partner Limited: Unknown device 0450
Flags: bus master, fast devsel, latency 0, IRQ 5
Memory at d0000000 (32-bit, prefetchable) [size=128M]
I/O ports at b000 [size=256]
Memory at da230000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at da200000 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #10 [0001]
Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
0000:01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
Subsystem: PC Partner Limited: Unknown device 0451
Flags: bus master, fast devsel, latency 0
Memory at da220000 (32-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #10 [0001]
0000:03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 19)
Subsystem: AOPEN Inc. Marvell 88E8053 Gigabit Ethernet Controller (Aopen)
Flags: bus master, fast devsel, latency 0, IRQ 177
Memory at da020000 (64-bit, non-prefetchable) [size=16K]
I/O ports at c000 [size=256]
Expansion ROM at 88000000 [disabled] [size=128K]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
Capabilities: [e0] #10 [0011]
0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 19)
Subsystem: AOPEN Inc. Marvell 88E8053 Gigabit Ethernet Controller (Aopen)
Flags: bus master, fast devsel, latency 0, IRQ 185
Memory at da120000 (64-bit, non-prefetchable) [size=16K]
I/O ports at d000 [size=256]
Expansion ROM at 88100000 [disabled] [size=128K]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
Capabilities: [e0] #10 [0011]
0000:06:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) (prog-if 10 [OHCI])
Subsystem: AOPEN Inc.: Unknown device 030a
Flags: bus master, medium devsel, latency 32, IRQ 66
Memory at d9000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
0000:06:05.0 Multimedia audio controller: Xilinx Corporation RME Digi96/8 Pad (rev 04)
Flags: slow devsel, IRQ 177
Memory at d8000000 (32-bit, non-prefetchable) [size=16M]
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Stephen Hemminger @ 2006-02-27 17:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alan Cox, Christoph Hellwig, James Ketrenos, NetDev, linux-kernel,
okir
In-Reply-To: <20060227171029.GA763@infradead.org>
On Mon, 27 Feb 2006 17:10:29 +0000
Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, Feb 26, 2006 at 12:58:02AM +0000, Alan Cox wrote:
> > On Sad, 2006-02-25 at 08:41 +0000, Christoph Hellwig wrote:
> > > the regualatory problems are not true.
> >
> > They are although the binary interpretation isn't AFAIK from law but
> > from lawyers. The same is actually true in much of the EU. The actual
> > requirement is that the transmitting device must be reasonably
> > tamperproof. Some of the lawyers have decided that for a software radio
> > tamperproof means "binary".
>
> Exactly. There's no strong requirement, it's just over-zealous corporate
> lawyers. That's why we need to push Intel strongly here.
It is not Intel, but the regulators that need a stronger clue. Vendors
don't have any incentive to force change on this. They just want to sell
as much hardware as possible.
Does anyone know who the actual FCC administrators in charge of this are?
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Stephen Hemminger @ 2006-02-27 17:18 UTC (permalink / raw)
To: woho
Cc: pomac, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <200602271738.38675.woho@woho.de>
On Mon, 27 Feb 2006 17:38:38 +0100
Wolfgang Hoffmann <woho@woho.de> wrote:
> On Monday 27 February 2006 17:00, Stephen Hemminger wrote:
> > On Mon, 27 Feb 2006 00:03:45 +0100
> >
> > Wolfgang Hoffmann <woho@woho.de> wrote:
> > > > Bisect done:
> > > >
> > > > 4d52b48b43d0d1d5959fa722ee0046e3542e5e1b is first bad commit
> > > > [PATCH] sky2: support msi interrupt (revised)
> > > >
> > > > Reverting this commit in git head seems to work, at least the driver
> > > > builds and loads. Is that sane?
> > > >
> > > Ok, no hangs yet.
> > >
> > > Looking at the reverted commit, I wonder if modprobing sky2 with
> > > disable_msi=1 is equivalent to reverting the commit?
> >
> > Could you try the current code with the disable_msi option?
> > modprobe sky2 disable_msi=1
> >
> > That will run existing code without MSI.
>
> 2.6.16-rc5 with disable_msi=1 works for me, no hangs seen so far. I rsynced 80
> GB of data, thats about 5-10 times more than I typically need to reproduce a
> hang, so it seems to be solid. For the record: 2.6.16-rc5 with disable_msi=0
> does hang.
>
> I have not seen the memory trashing others reported, with no version I tested
> so far. Maybe my scenario is not likely to trigger this, so I can't tell.
>
> Unless a fix for msi is at hand, may I suggest for 2.6.16 to revert the msi
> commit or switch the default to disable_msi=1?
>
> I've updated bugzilla #6084 accordingly.
Okay, then what I need is lspci -v of all systems that have the problem, I'll make
a blacklist (or update PCI quirks). I suspect that MSI doesn't work for any devices
on these systems, or MSI changes the timing enough to expose existing races.
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Christoph Hellwig @ 2006-02-27 17:10 UTC (permalink / raw)
To: Alan Cox; +Cc: Christoph Hellwig, James Ketrenos, NetDev, linux-kernel, okir
In-Reply-To: <1140915482.23286.6.camel@localhost.localdomain>
On Sun, Feb 26, 2006 at 12:58:02AM +0000, Alan Cox wrote:
> On Sad, 2006-02-25 at 08:41 +0000, Christoph Hellwig wrote:
> > the regualatory problems are not true.
>
> They are although the binary interpretation isn't AFAIK from law but
> from lawyers. The same is actually true in much of the EU. The actual
> requirement is that the transmitting device must be reasonably
> tamperproof. Some of the lawyers have decided that for a software radio
> tamperproof means "binary".
Exactly. There's no strong requirement, it's just over-zealous corporate
lawyers. That's why we need to push Intel strongly here.
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Wolfgang Hoffmann @ 2006-02-27 16:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pomac, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <20060227080042.0cf3f05d@localhost.localdomain>
On Monday 27 February 2006 17:00, Stephen Hemminger wrote:
> On Mon, 27 Feb 2006 00:03:45 +0100
>
> Wolfgang Hoffmann <woho@woho.de> wrote:
> > > Bisect done:
> > >
> > > 4d52b48b43d0d1d5959fa722ee0046e3542e5e1b is first bad commit
> > > [PATCH] sky2: support msi interrupt (revised)
> > >
> > > Reverting this commit in git head seems to work, at least the driver
> > > builds and loads. Is that sane?
> > >
> > Ok, no hangs yet.
> >
> > Looking at the reverted commit, I wonder if modprobing sky2 with
> > disable_msi=1 is equivalent to reverting the commit?
>
> Could you try the current code with the disable_msi option?
> modprobe sky2 disable_msi=1
>
> That will run existing code without MSI.
2.6.16-rc5 with disable_msi=1 works for me, no hangs seen so far. I rsynced 80
GB of data, thats about 5-10 times more than I typically need to reproduce a
hang, so it seems to be solid. For the record: 2.6.16-rc5 with disable_msi=0
does hang.
I have not seen the memory trashing others reported, with no version I tested
so far. Maybe my scenario is not likely to trigger this, so I can't tell.
Unless a fix for msi is at hand, may I suggest for 2.6.16 to revert the msi
commit or switch the default to disable_msi=1?
I've updated bugzilla #6084 accordingly.
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Stephen Hemminger @ 2006-02-27 16:00 UTC (permalink / raw)
To: woho
Cc: pomac, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <200602270003.46353.woho@woho.de>
On Mon, 27 Feb 2006 00:03:45 +0100
Wolfgang Hoffmann <woho@woho.de> wrote:
> On Sunday 26 February 2006 23:31, Wolfgang Hoffmann wrote:
> > On Sunday 26 February 2006 19:13, Wolfgang Hoffmann wrote:
> > > Ok, I did some reading and just started a git bisect. I didn't find hints
> > > on how to bisect if I'm only interested in changes to sky2.[ch], so I'm
> > > taking the full kernel tree and skip testing those bisect steps that
> > > didn't change sky2.[ch].
> > >
> > > Looking at Carl-Daniels 0.13a and Stephens patch against 0.15 in this
> > > thread, I'll patch each bisect step such that sky2_poll() has
> > >
> > > sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
> > > if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
> > > sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
> > > sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
> > > }
> > >
> > > after exit_loop. Is that ok?
> > >
> > > I'll report as soon as I have results.
> >
> > Bisect done:
> >
> > 4d52b48b43d0d1d5959fa722ee0046e3542e5e1b is first bad commit
> > [PATCH] sky2: support msi interrupt (revised)
> >
> > Reverting this commit in git head seems to work, at least the driver builds
> > and loads. Is that sane?
> >
> > I'm currently testing this (without any further modifications), let's see
> > if it hangs or not.
>
> Ok, no hangs yet.
>
> This version passed a test scenario only 0.13a has survived so far. I'll
> continue to use this to give it more testing tomorrow.
>
> Looking at the reverted commit, I wonder if modprobing sky2 with disable_msi=1
> is equivalent to reverting the commit?
>
Could you try the current code with the disable_msi option?
modprobe sky2 disable_msi=1
That will run existing code without MSI.
^ permalink raw reply
* Re: [PATH][RFC] acxsm: Make acx mdoular again
From: Carlos Martín @ 2006-02-27 10:44 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: netdev, acx100-devel, Christoph Hellwig
In-Reply-To: <200602271220.14853.vda@ilport.com.ua>
On Monday 27 February 2006 11:20, Denis Vlasenko wrote:
> > Comments are welcome and I'll split the patch if needed.
>
> usb.c
> =====
> #define BOGUS_SAFETY_PADDING 0x40
>
> int
> acxusb_s_issue_cmd_timeo(
> acx_device_t *adev,
> unsigned cmd,
> void *buffer,
> unsigned buflen,
> unsigned timeout)
> {
> #if ACX_DEBUG
> return acx_s_issue_cmd_timeo_debug(adev, cmd, buffer, buflen,
timeout, __stringify(cmd));
> #else
> return acx_s_issue_cmd_timeo_debug(adev, cmd, buffer, buflen,
timeout);
> #endif
> }
>
> stringify what? We want symbolic command name, not it's numeric value.
> stringifying must occur in .h file.
Missed that. The problem is that right now we need to reference the function.
There's no real need for it, so I'll change it.
>
>
> acx_func.h
> ==========
> #if ACX_DEBUG
>
> /* We want to log cmd names */
> int acxpci_s_issue_cmd_timeo_debug(acx_device_t *adev, unsigned cmd, void
*param, unsigned len, unsigned timeout, const char* cmdstr);
> int acxusb_s_issue_cmd_timeo_debug(acx_device_t *adev, unsigned cmd, void
*param, unsigned len, unsigned timeout, const char* cmdstr);
> static inline int
> acx_s_issue_cmd_timeo_debug(acx_device_t *adev, unsigned cmd, void *param,
unsigned len, unsigned timeout, const char* cmdstr)
> {
> if (IS_PCI(adev))
> return acxpci_s_issue_cmd_timeo_debug(adev, cmd, param, len,
timeout, cmdstr);
> return acxusb_s_issue_cmd_timeo_debug(adev, cmd, param, len,
timeout, cmdstr);
> }
> int acx_s_issue_cmd(acx_device_t *adev, unsigned cmd, void *param, unsigned
len);
>
> It will recurse: acx_s_issue_cmd_timeo_debug ->
acxusb_s_issue_cmd_timeo_debug -> acx_s_issue_cmd_timeo_debug ->....
I forgot to remove that function. In acxusb_s_issue_timeo, it should call
acxusb_s_issue_cmd_timeo_{debug,nodebug}, not the generic function.
> Why do you need if (IS_PCI(adev)) at all?
>
> Please apply the attached style fixes on top of your patches.
Will do.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
^ permalink raw reply
* Re: [PATH][RFC] acxsm: Make acx mdoular again
From: Denis Vlasenko @ 2006-02-27 10:20 UTC (permalink / raw)
To: Carlos Martín; +Cc: netdev, acx100-devel, Christoph Hellwig
In-Reply-To: <200602261710.33923.carlos@cmartin.tk>
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Sunday 26 February 2006 18:10, Carlos Martín wrote:
> Hi,
>
> Well, here it is. I've not been able to run-test it yet, but it at least
> compiles and loads without problems. This is on x86_64 compiled against
> Linville's wireless-2.6 git tree. (I don't have any x86 boxes running Linux
> right now, but it should be alright).
>
> I've added a struct acx_ops with function pointers and deleted the functions
> that just call the PCI/USB version depending on what we're using at the
> moment. A few functions I've just made empty to simplify and not having to
> check every time wether we do have it or not. These are only called on
> load/unload and error conditions. Normal operation shouldn't suffer any speed
> decrease it may be faster at times because we dereference a few pointers
> instead of calling a couple of functions (just guessing, though).
>
> The patch is 38K uncompressed. I've compressed and attached it and uploaded to
> http://www.cmartin.tk/acx/acxsm-modularise.patch
>
> text data bss dec hex filename
> 55491 588 4 56083 db13 acx-common.ko
> 33523 1040 4 34567 8707 acx-pci.ko
> 17109 1008 0 18117 46c5 acx-usb.ko
>
> Comments are welcome and I'll split the patch if needed.
usb.c
=====
#define BOGUS_SAFETY_PADDING 0x40
int
acxusb_s_issue_cmd_timeo(
acx_device_t *adev,
unsigned cmd,
void *buffer,
unsigned buflen,
unsigned timeout)
{
#if ACX_DEBUG
return acx_s_issue_cmd_timeo_debug(adev, cmd, buffer, buflen, timeout, __stringify(cmd));
#else
return acx_s_issue_cmd_timeo_debug(adev, cmd, buffer, buflen, timeout);
#endif
}
stringify what? We want symbolic command name, not it's numeric value.
stringifying must occur in .h file.
acx_func.h
==========
#if ACX_DEBUG
/* We want to log cmd names */
int acxpci_s_issue_cmd_timeo_debug(acx_device_t *adev, unsigned cmd, void *param, unsigned len, unsigned timeout, const char* cmdstr);
int acxusb_s_issue_cmd_timeo_debug(acx_device_t *adev, unsigned cmd, void *param, unsigned len, unsigned timeout, const char* cmdstr);
static inline int
acx_s_issue_cmd_timeo_debug(acx_device_t *adev, unsigned cmd, void *param, unsigned len, unsigned timeout, const char* cmdstr)
{
if (IS_PCI(adev))
return acxpci_s_issue_cmd_timeo_debug(adev, cmd, param, len, timeout, cmdstr);
return acxusb_s_issue_cmd_timeo_debug(adev, cmd, param, len, timeout, cmdstr);
}
int acx_s_issue_cmd(acx_device_t *adev, unsigned cmd, void *param, unsigned len);
It will recurse: acx_s_issue_cmd_timeo_debug -> acxusb_s_issue_cmd_timeo_debug -> acx_s_issue_cmd_timeo_debug ->....
Why do you need if (IS_PCI(adev)) at all?
Please apply the attached style fixes on top of your patches.
Patch is not applied. Sorry.
--
vda
[-- Attachment #2: acxsm-modularise2.patch --]
[-- Type: text/x-diff, Size: 2161 bytes --]
diff -urpN current_sm.1/acx_func.h current_sm.2/acx_func.h
--- current_sm.1/acx_func.h Mon Feb 27 12:13:27 2006
+++ current_sm.2/acx_func.h Mon Feb 27 12:10:32 2006
@@ -444,7 +444,7 @@ int acx_s_interrogate_debug(acx_device_t
#else
-/* We can't make this a #define or inline because we need to referece it. */
+/* We can't make this a #define or inline because we need to reference it. */
int acx_s_issue_cmd(acx_device_t *adev, unsigned cmd, void *param, unsigned len);
int acxpci_s_issue_cmd_timeo(acx_device_t *adev, unsigned cmd, void *param, unsigned len, unsigned timeout);
diff -urpN current_sm.1/common.c current_sm.2/common.c
--- current_sm.1/common.c Mon Feb 27 12:13:28 2006
+++ current_sm.2/common.c Mon Feb 27 12:06:33 2006
@@ -331,10 +331,11 @@ acx_log_fn_exit_v(const char *funcname,
EXPORT_SYMBOL_GPL(acx_log_fn_exit_v);
#endif /* ACX_DEBUG > 1 */
-int acx_s_issue_cmd(acx_device_t *adev, unsigned cmd, void *param, unsigned len)
+int
+acx_s_issue_cmd(acx_device_t *adev, unsigned cmd, void *param, unsigned len)
{
- return adev->ops.issue_cmd_timeo(adev, cmd, param, len,
- ACX_CMD_TIMEOUT_DEFAULT);
+ return adev->ops.issue_cmd_timeo(adev, cmd, param, len,
+ ACX_CMD_TIMEOUT_DEFAULT);
}
EXPORT_SYMBOL_GPL(acx_s_issue_cmd);
@@ -1940,7 +1941,7 @@ acx_s_scan_chan(acx_device_t *adev)
FN_EXIT0;
}
- EXPORT_SYMBOL_GPL(acx_s_scan_chan);
+EXPORT_SYMBOL_GPL(acx_s_scan_chan);
void
acx_s_cmd_start_scan(acx_device_t *adev)
@@ -2059,7 +2060,7 @@ acx111_s_feature_set(acx_device_t *adev,
/***********************************************************************
** acx100_s_init_memory_pools
*/
-int
+static int
acx100_s_init_memory_pools(acx_device_t *adev, const acx_ie_memmap_t *mmt)
{
acx100_ie_memblocksize_t MemoryBlockSize;
diff -urpN current_sm.1/pci.c current_sm.2/pci.c
--- current_sm.1/pci.c Mon Feb 27 12:13:28 2006
+++ current_sm.2/pci.c Mon Feb 27 12:08:30 2006
@@ -3089,7 +3089,11 @@ end:
return (tx_t*)txdesc;
}
-void acxpci_l_dealloc_tx(tx_t *tx_opaque){}
+void
+acxpci_l_dealloc_tx(tx_t *tx_opaque)
+{
+}
+
/***********************************************************************
*/
^ permalink raw reply
* [Patch 7/7] Generic netlink interface (delay accounting)
From: Shailabh Nagar @ 2006-02-27 8:31 UTC (permalink / raw)
To: linux-kernel; +Cc: lse-tech, netdev
In-Reply-To: <1141026996.5785.38.camel@elinux04.optonline.net>
delayacct-genetlink.patch
Create a generic netlink interface (NETLINK_GENERIC family),
called "taskstats", for getting delay and cpu statistics of
tasks and thread groups during their lifetime and when they exit.
The cpu stats are available only if CONFIG_SCHEDSTATS is enabled.
When a task is alive, userspace can get its stats by sending a
command containing its pid. Sending a tgid returns the sum of stats
of the tasks belonging to that tgid (where such a sum makes sense).
Together, the command interface allows stats for a large number of
tasks to be collected more efficiently than would be possible
through /proc or any per-pid interface.
The netlink interface also sends the stats for each task to userspace
when the task is exiting. This permits fine-grain accounting for
short-lived tasks, which is important if userspace is doing its own
aggregation of statistics based on some grouping of tasks
(e.g. CSA jobs, ELSA banks or CKRM classes).
If the exiting task belongs to a thread group (with more members than itself)
, the latters delay stats are also sent out on the task's exit. This allows
userspace to get accurate data at a per-tgid level while the tid's of a tgid
are exiting one by one.
The interface has been deliberately kept distinct from the delay
accounting code since it is potentially usable by other kernel components
that need to export per-pid/tgid data. The format of data returned to
userspace is versioned and the command interface easily extensible to
facilitate reuse.
If reuse is not deemed useful enough, the naming, placement of functions
and config options will be modified to make this an interface for delay
accounting alone.
Signed-off-by: Shailabh Nagar <nagar@watson.ibm.com>
Signed-off-by: Balbir Singh <balbir@in.ibm.com>
include/linux/delayacct.h | 2
include/linux/taskstats.h | 125 +++++++++++++++++++++
init/Kconfig | 16 ++
kernel/Makefile | 1
kernel/delayacct.c | 49 ++++++++
kernel/taskstats.c | 266 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 456 insertions(+), 3 deletions(-)
Index: linux-2.6.16-rc4/include/linux/delayacct.h
===================================================================
--- linux-2.6.16-rc4.orig/include/linux/delayacct.h 2006-02-27 01:53:01.000000000 -0500
+++ linux-2.6.16-rc4/include/linux/delayacct.h 2006-02-27 01:53:03.000000000 -0500
@@ -16,6 +16,7 @@
#include <linux/sched.h>
#include <linux/sysctl.h>
+#include <linux/taskstats.h>
#ifdef CONFIG_TASK_DELAY_ACCT
extern int delayacct_on; /* Delay accounting turned on/off */
@@ -27,6 +28,7 @@ extern void __delayacct_tsk_init(struct
extern void __delayacct_tsk_exit(struct task_struct *);
extern void __delayacct_blkio(void);
extern void __delayacct_swapin(void);
+extern int delayacct_add_tsk(struct taskstats_reply *, struct task_struct *);
static inline void delayacct_tsk_early_init(struct task_struct *tsk)
{
Index: linux-2.6.16-rc4/include/linux/taskstats.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.16-rc4/include/linux/taskstats.h 2006-02-27 01:53:03.000000000 -0500
@@ -0,0 +1,125 @@
+/* taskstats.h - exporting per-task statistics
+ *
+ * Copyright (C) Shailabh Nagar, IBM Corp. 2006
+ * (C) Balbir Singh, IBM Corp. 2006
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#ifndef _LINUX_TASKSTATS_H
+#define _LINUX_TASKSTATS_H
+
+/* Format for per-task data returned to userland when
+ * - a task exits
+ * - listener requests stats for a task
+ *
+ * The struct is versioned. Newer versions should only add fields to
+ * the bottom of the struct to maintain backward compatibility.
+ *
+ * To create the next version, bump up the taskstats_version variable
+ * and delineate the start of newly added fields with a comment indicating
+ * the version number.
+ */
+
+#define TASKSTATS_VERSION 1
+
+struct taskstats {
+
+ /* Version 1 */
+#define TASKSTATS_NOPID -1
+ pid_t pid;
+ pid_t tgid;
+
+ /* XXX_count is number of delay values recorded.
+ * XXX_total is corresponding cumulative delay in nanoseconds
+ */
+
+#define TASKSTATS_NOCPUSTATS 1
+ __u64 cpu_count;
+ __u64 cpu_delay_total; /* wait, while runnable, for cpu */
+ __u64 blkio_count;
+ __u64 blkio_delay_total; /* sync,block io completion wait*/
+ __u64 swapin_count;
+ __u64 swapin_delay_total; /* swapin page fault wait*/
+
+ __u64 cpu_run_total; /* cpu running time
+ * no count available/provided */
+};
+
+
+#define TASKSTATS_LISTEN_GROUP 0x1
+
+/*
+ * Commands sent from userspace
+ * Not versioned. New commands should only be inserted at the enum's end
+ */
+
+enum {
+ TASKSTATS_CMD_UNSPEC, /* Reserved */
+ TASKSTATS_CMD_NONE, /* Not a valid cmd to send
+ * Marks data sent on task/tgid exit */
+ TASKSTATS_CMD_LISTEN, /* Start listening */
+ TASKSTATS_CMD_IGNORE, /* Stop listening */
+ TASKSTATS_CMD_PID, /* Send stats for a pid */
+ TASKSTATS_CMD_TGID, /* Send stats for a tgid */
+};
+
+/* Parameters for commands
+ * New parameters should only be inserted at the struct's end
+ */
+
+struct taskstats_cmd_param {
+ union {
+ pid_t pid;
+ pid_t tgid;
+ } id;
+};
+
+/*
+ * Reply sent from kernel
+ * Version number affects size/format of struct taskstats only
+ */
+
+struct taskstats_reply {
+ enum outtype {
+ TASKSTATS_REPLY_NONE = 1, /* Control cmd response */
+ TASKSTATS_REPLY_PID, /* per-pid data cmd response*/
+ TASKSTATS_REPLY_TGID, /* per-tgid data cmd response*/
+ TASKSTATS_REPLY_EXIT_PID, /* Exiting task's stats */
+ TASKSTATS_REPLY_EXIT_TGID, /* Exiting tgid's stats
+ * (sent on each tid's exit) */
+ } outtype;
+ __u32 version;
+ __u32 err;
+ struct taskstats stats; /* Invalid if err != 0 */
+};
+
+/* NETLINK_GENERIC related info */
+
+#define TASKSTATS_GENL_NAME "TASKSTATS"
+#define TASKSTATS_GENL_VERSION 0x1
+/* Following must be > NLMSG_MIN_TYPE */
+#define TASKSTATS_GENL_ID 0x123
+
+#define TASKSTATS_HDRLEN (NLMSG_SPACE(GENL_HDRLEN))
+#define TASKSTATS_BODYLEN (sizeof(struct taskstats_reply))
+
+#ifdef __KERNEL__
+
+#include <linux/sched.h>
+
+#ifdef CONFIG_TASKSTATS
+extern void taskstats_exit_pid(struct task_struct *);
+#else
+static inline void taskstats_exit_pid(struct task_struct *tsk)
+{}
+#endif
+
+#endif /* __KERNEL__ */
+#endif /* _LINUX_TASKSTATS_H */
Index: linux-2.6.16-rc4/kernel/Makefile
===================================================================
--- linux-2.6.16-rc4.orig/kernel/Makefile 2006-02-27 01:52:54.000000000 -0500
+++ linux-2.6.16-rc4/kernel/Makefile 2006-02-27 01:53:03.000000000 -0500
@@ -35,6 +35,7 @@ obj-$(CONFIG_GENERIC_HARDIRQS) += irq/
obj-$(CONFIG_SECCOMP) += seccomp.o
obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
+obj-$(CONFIG_TASKSTATS) += taskstats.o
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
Index: linux-2.6.16-rc4/kernel/taskstats.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.16-rc4/kernel/taskstats.c 2006-02-27 01:53:03.000000000 -0500
@@ -0,0 +1,266 @@
+/*
+ * taskstats.c - Export per-task statistics to userland
+ *
+ * Copyright (C) Shailabh Nagar, IBM Corp. 2006
+ * (C) Balbir Singh, IBM Corp. 2006
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/taskstats.h>
+#include <linux/delayacct.h>
+#include <net/genetlink.h>
+#include <asm/atomic.h>
+
+const int taskstats_version = TASKSTATS_VERSION;
+static atomic_t taskstats_group_listeners = ATOMIC_INIT(0);
+static DEFINE_PER_CPU(__u32, taskstats_seqnum) = { 0 };
+
+static struct genl_family family = {
+// .id = GENL_ID_GENERATE,
+ .id = TASKSTATS_GENL_ID,
+ .name = TASKSTATS_GENL_NAME,
+ .version = TASKSTATS_GENL_VERSION,
+ .hdrsize = 0,
+ .maxattr = 0,
+};
+
+#define genlmsg_data(genlhdr) ((char *)genlhdr + GENL_HDRLEN)
+
+/* Taskstat specific functions */
+
+static int taskstats_listen(struct sk_buff *skb, struct genl_info *info)
+{
+ atomic_inc(&taskstats_group_listeners);
+ return 0;
+}
+
+static int taskstats_ignore(struct sk_buff *skb, struct genl_info *info)
+{
+ atomic_dec(&taskstats_group_listeners);
+ return 0;
+}
+
+static int prepare_reply(struct genl_info *info, u8 cmd,
+ struct sk_buff **skbp, struct taskstats_reply **replyp)
+{
+ struct sk_buff *skb;
+ struct taskstats_reply *reply;
+
+ skb = nlmsg_new(TASKSTATS_HDRLEN + TASKSTATS_BODYLEN);
+ if (!skb)
+ return -ENOMEM;
+
+ if (!info) {
+ int seq = get_cpu_var(taskstats_seqnum)++;
+ put_cpu_var(taskstats_seqnum);
+
+ reply = genlmsg_put(skb, 0, seq,
+ family.id, 0, NLM_F_REQUEST,
+ cmd, family.version);
+ } else
+ reply = genlmsg_put(skb, info->snd_pid, info->snd_seq,
+ family.id, 0, info->nlhdr->nlmsg_flags,
+ info->genlhdr->cmd, family.version);
+ if (reply == NULL) {
+ nlmsg_free(skb);
+ return -EINVAL;
+ }
+ skb_put(skb, TASKSTATS_BODYLEN);
+
+ memset(reply, 0, sizeof(*reply));
+ reply->version = taskstats_version;
+ reply->err = 0;
+
+ *skbp = skb;
+ *replyp = reply;
+ return 0;
+}
+
+static int send_reply(struct sk_buff *skb, int replytype)
+{
+ struct genlmsghdr *genlhdr = nlmsg_data((struct nlmsghdr *)skb->data);
+ struct taskstats_reply *reply;
+
+ reply = (struct taskstats_reply *)genlmsg_data(genlhdr);
+ reply->outtype = replytype;
+
+ genlmsg_end(skb, genlhdr);
+ return genlmsg_multicast(skb, 0, TASKSTATS_LISTEN_GROUP);
+}
+
+static inline void fill_pid(struct taskstats_reply *reply, pid_t pid, struct task_struct *pidtsk)
+{
+ int rc;
+ struct task_struct *tsk = pidtsk;
+
+ if (!pidtsk) {
+ read_lock(&tasklist_lock);
+ tsk = find_task_by_pid(pid);
+ if (!tsk) {
+ read_unlock(&tasklist_lock);
+ reply->err = EINVAL;
+ return;
+ }
+ get_task_struct(tsk);
+ read_unlock(&tasklist_lock);
+ } else
+ get_task_struct(tsk);
+
+ rc = delayacct_add_tsk(reply, tsk);
+ if (!rc) {
+ reply->stats.pid = tsk->pid;
+ reply->stats.tgid = tsk->tgid;
+ } else
+ reply->err = (rc < 0) ? -rc : rc ;
+
+ put_task_struct(tsk);
+}
+
+static int taskstats_send_pid(struct sk_buff *skb, struct genl_info *info)
+{
+ int rc;
+ struct sk_buff *rep_skb;
+ struct taskstats_reply *reply;
+ struct taskstats_cmd_param *param= info->userhdr;
+
+ if (atomic_read(&taskstats_group_listeners) < 1)
+ return -EINVAL;
+
+ rc = prepare_reply(info, info->genlhdr->cmd, &rep_skb, &reply);
+ if (rc)
+ return rc;
+ fill_pid(reply, param->id.pid, NULL);
+ return send_reply(rep_skb, TASKSTATS_REPLY_PID);
+}
+
+static inline void fill_tgid(struct taskstats_reply *reply, pid_t tgid, struct task_struct *tgidtsk)
+{
+ int rc;
+ struct task_struct *tsk, *first;
+
+ first = tgidtsk;
+ read_lock(&tasklist_lock);
+ if (!first) {
+ first = find_task_by_pid(tgid);
+ if (!first) {
+ read_unlock(&tasklist_lock);
+ reply->err = EINVAL;
+ return;
+ }
+ }
+ tsk = first;
+ do {
+ rc = delayacct_add_tsk(reply, tsk);
+ if (rc)
+ break;
+ } while_each_thread(first, tsk);
+ read_unlock(&tasklist_lock);
+
+ if (!rc) {
+ reply->stats.pid = TASKSTATS_NOPID;
+ reply->stats.tgid = tgid;
+ } else
+ reply->err = (rc < 0) ? -rc : rc ;
+}
+
+static int taskstats_send_tgid(struct sk_buff *skb, struct genl_info *info)
+{
+ int rc;
+ struct sk_buff *rep_skb;
+ struct taskstats_reply *reply;
+ struct taskstats_cmd_param *param= info->userhdr;
+
+ if (atomic_read(&taskstats_group_listeners) < 1)
+ return -EINVAL;
+
+ rc = prepare_reply(info, info->genlhdr->cmd, &rep_skb, &reply);
+ if (rc)
+ return rc;
+ fill_tgid(reply, param->id.tgid, NULL);
+ return send_reply(rep_skb, TASKSTATS_REPLY_TGID);
+}
+
+/* Send pid data out on exit */
+void taskstats_exit_pid(struct task_struct *tsk)
+{
+ int rc;
+ struct sk_buff *rep_skb;
+ struct taskstats_reply *reply;
+
+ if (atomic_read(&taskstats_group_listeners) < 1)
+ return;
+
+ rc = prepare_reply(NULL, TASKSTATS_CMD_NONE, &rep_skb, &reply);
+ if (rc)
+ return;
+ fill_pid(reply, tsk->pid, tsk);
+ rc = send_reply(rep_skb, TASKSTATS_REPLY_EXIT_PID);
+
+ if (rc || thread_group_empty(tsk))
+ return;
+
+ /* Send tgid data too */
+ rc = prepare_reply(NULL, TASKSTATS_CMD_NONE, &rep_skb, &reply);
+ if (rc)
+ return;
+ fill_tgid(reply, tsk->tgid, tsk);
+ send_reply(rep_skb, TASKSTATS_REPLY_EXIT_TGID);
+}
+
+static struct genl_ops listen_ops = {
+ .cmd = TASKSTATS_CMD_LISTEN,
+ .doit = taskstats_listen,
+};
+
+static struct genl_ops ignore_ops = {
+ .cmd = TASKSTATS_CMD_IGNORE,
+ .doit = taskstats_ignore,
+};
+
+static struct genl_ops pid_ops = {
+ .cmd = TASKSTATS_CMD_PID,
+ .doit = taskstats_send_pid,
+};
+
+static struct genl_ops tgid_ops = {
+ .cmd = TASKSTATS_CMD_TGID,
+ .doit = taskstats_send_tgid,
+};
+
+static int family_registered = 0;
+
+static int __init taskstats_init(void)
+{
+ if (genl_register_family(&family))
+ return -EFAULT;
+ family_registered = 1;
+
+ if (genl_register_ops(&family, &listen_ops))
+ goto err;
+ if (genl_register_ops(&family, &ignore_ops))
+ goto err;
+ if (genl_register_ops(&family, &pid_ops))
+ goto err;
+ if (genl_register_ops(&family, &tgid_ops))
+ goto err;
+
+ return 0;
+err:
+ genl_unregister_family(&family);
+ family_registered = 0;
+ return -EFAULT;
+}
+
+late_initcall(taskstats_init);
+
Index: linux-2.6.16-rc4/init/Kconfig
===================================================================
--- linux-2.6.16-rc4.orig/init/Kconfig 2006-02-27 01:52:54.000000000 -0500
+++ linux-2.6.16-rc4/init/Kconfig 2006-02-27 01:53:03.000000000 -0500
@@ -158,11 +158,21 @@ config TASK_DELAY_ACCT
in pages. Such statistics can help in setting a task's priorities
relative to other tasks for cpu, io, rss limits etc.
- Unlike BSD process accounting, this information is available
- continuously during the lifetime of a task.
-
Say N if unsure.
+config TASKSTATS
+ bool "Export task/process statistics through netlink (EXPERIMENTAL)"
+ depends on TASK_DELAY_ACCT
+ default y
+ help
+ Export selected statistics for tasks/processes through the
+ generic netlink interface. Unlike BSD process accounting, the
+ statistics are available during the lifetime of tasks/processes as
+ responses to commands. Like BSD accounting, they are sent to user
+ space on task exit.
+
+ Say Y if unsure.
+
config SYSCTL
bool "Sysctl support"
---help---
Index: linux-2.6.16-rc4/kernel/delayacct.c
===================================================================
--- linux-2.6.16-rc4.orig/kernel/delayacct.c 2006-02-27 01:53:01.000000000 -0500
+++ linux-2.6.16-rc4/kernel/delayacct.c 2006-02-27 01:53:03.000000000 -0500
@@ -17,6 +17,7 @@
#include <linux/time.h>
#include <linux/sysctl.h>
#include <linux/delayacct.h>
+#include <linux/taskstats.h>
int delayacct_on = 0; /* Delay accounting turned on/off */
kmem_cache_t *delayacct_cache;
@@ -61,6 +62,7 @@ void __delayacct_tsk_init(struct task_st
void __delayacct_tsk_exit(struct task_struct *tsk)
{
+ taskstats_exit_pid(tsk);
task_lock(tsk);
if (tsk->delays) {
kmem_cache_free(delayacct_cache, tsk->delays);
@@ -209,3 +211,50 @@ int delayacct_sysctl_handler(ctl_table *
delayacct_on = prev;
return ret;
}
+
+#ifdef CONFIG_TASKSTATS
+
+int delayacct_add_tsk(struct taskstats_reply *reply, struct task_struct *tsk)
+{
+ struct taskstats *d = &reply->stats;
+ nsec_t tmp;
+ struct timespec ts;
+ unsigned long t1,t2;
+
+ if (!tsk->delays || !delayacct_on)
+ return -EINVAL;
+
+ /* zero XXX_total,non-zero XXX_count implies XXX stat overflowed */
+#ifdef CONFIG_SCHEDSTATS
+
+ tmp = (nsec_t)d->cpu_run_total ;
+ tmp += (u64)(tsk->utime+tsk->stime)*TICK_NSEC;
+ d->cpu_run_total = (tmp < (nsec_t)d->cpu_run_total)? 0:tmp;
+
+ /* No locking available for sched_info. Take snapshot first. */
+ t1 = tsk->sched_info.pcnt;
+ t2 = tsk->sched_info.run_delay;
+
+ d->cpu_count += t1;
+
+ jiffies_to_timespec(t2, &ts);
+ tmp = (nsec_t)d->cpu_delay_total + timespec_to_ns(&ts);
+ d->cpu_delay_total = (tmp < (nsec_t)d->cpu_delay_total)? 0:tmp;
+#else
+ /* Non-zero XXX_total,zero XXX_count implies XXX stat unavailable */
+ d->cpu_count = 0;
+ d->cpu_run_total = d->cpu_delay_total = TASKSTATS_NOCPUSTATS;
+#endif
+ spin_lock(&tsk->delays->lock);
+ tmp = d->blkio_delay_total + tsk->delays->blkio_delay;
+ d->blkio_delay_total = (tmp < d->blkio_delay_total)? 0:tmp;
+ tmp = d->swapin_delay_total + tsk->delays->swapin_delay;
+ d->swapin_delay_total = (tmp < d->swapin_delay_total)? 0:tmp;
+ d->blkio_count += tsk->delays->blkio_count;
+ d->swapin_count += tsk->delays->swapin_count;
+ spin_unlock(&tsk->delays->lock);
+
+ return 0;
+}
+
+#endif /* CONFIG_TASKSTATS */
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-27 0:43 UTC (permalink / raw)
To: Carl-Daniel Hailfinger
Cc: Arjan van de Ven, woho, Stephen Hemminger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <44022DEC.1070601@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Sun, 2006-02-26 at 23:38 +0100, Carl-Daniel Hailfinger wrote:
> Ian Kumlien schrieb:
> > I also saw some oddities... portage stopped working, i dunno if this can
> > be MSI related or so, else something is trashing memory in a very
> > special way =P
>
> Yes, 0.15 causes memory corruption even if MSI is disabled.
So if i run with iommu=forced or what the hell the option is called i
should be able to catch these trashings?
I also found it odd that it was only python that suffered... Starting
large and long running C apps worked just fine.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Wolfgang Hoffmann @ 2006-02-26 23:03 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pomac, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <200602262331.47750.woho@woho.de>
On Sunday 26 February 2006 23:31, Wolfgang Hoffmann wrote:
> On Sunday 26 February 2006 19:13, Wolfgang Hoffmann wrote:
> > Ok, I did some reading and just started a git bisect. I didn't find hints
> > on how to bisect if I'm only interested in changes to sky2.[ch], so I'm
> > taking the full kernel tree and skip testing those bisect steps that
> > didn't change sky2.[ch].
> >
> > Looking at Carl-Daniels 0.13a and Stephens patch against 0.15 in this
> > thread, I'll patch each bisect step such that sky2_poll() has
> >
> > sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
> > if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
> > sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
> > sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
> > }
> >
> > after exit_loop. Is that ok?
> >
> > I'll report as soon as I have results.
>
> Bisect done:
>
> 4d52b48b43d0d1d5959fa722ee0046e3542e5e1b is first bad commit
> [PATCH] sky2: support msi interrupt (revised)
>
> Reverting this commit in git head seems to work, at least the driver builds
> and loads. Is that sane?
>
> I'm currently testing this (without any further modifications), let's see
> if it hangs or not.
Ok, no hangs yet.
This version passed a test scenario only 0.13a has survived so far. I'll
continue to use this to give it more testing tomorrow.
Looking at the reverted commit, I wonder if modprobing sky2 with disable_msi=1
is equivalent to reverting the commit?
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Carl-Daniel Hailfinger @ 2006-02-26 22:38 UTC (permalink / raw)
To: pomac
Cc: Arjan van de Ven, woho, Stephen Hemminger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <1140970427.23375.11.camel@localhost>
Ian Kumlien schrieb:
> On Sun, 2006-02-26 at 16:47 +0100, Arjan van de Ven wrote:
>
>>On Sun, 2006-02-26 at 16:00 +0100, Ian Kumlien wrote:
>>
>>>On Sun, 2006-02-26 at 09:57 +0100, Wolfgang Hoffmann wrote:
>>>
>>>>On Sunday 26 February 2006 03:03, Stephen Hemminger wrote:
>>>>
>>>>>Instead of whining, try this.
>>>>
>>>>I tried and still see the hang.
>>>
>>>I'm at a record 12 hours with that patch.
>>
>>shhh don't jinx it ;)
>
>
> Well it died 33 mins later... =)
>
> I also saw some oddities... portage stopped working, i dunno if this can
> be MSI related or so, else something is trashing memory in a very
> special way =P
Yes, 0.15 causes memory corruption even if MSI is disabled.
Regards,
Carl-Daniel
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Wolfgang Hoffmann @ 2006-02-26 22:31 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pomac, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <200602261913.36308.woho@woho.de>
On Sunday 26 February 2006 19:13, Wolfgang Hoffmann wrote:
> Ok, I did some reading and just started a git bisect. I didn't find hints
> on how to bisect if I'm only interested in changes to sky2.[ch], so I'm
> taking the full kernel tree and skip testing those bisect steps that didn't
> change sky2.[ch].
>
> Looking at Carl-Daniels 0.13a and Stephens patch against 0.15 in this
> thread, I'll patch each bisect step such that sky2_poll() has
>
> sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
> if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
> sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
> sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
> }
>
> after exit_loop. Is that ok?
>
> I'll report as soon as I have results.
Bisect done:
4d52b48b43d0d1d5959fa722ee0046e3542e5e1b is first bad commit
[PATCH] sky2: support msi interrupt (revised)
Reverting this commit in git head seems to work, at least the driver builds
and loads. Is that sane?
I'm currently testing this (without any further modifications), let's see if
it hangs or not.
^ permalink raw reply
* Re: RTL 8139 stops RX after receiving a jumbo frame
From: John Zielinski @ 2006-02-26 21:13 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, netdev
In-Reply-To: <20060226144424.GA26879@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 88 bytes --]
Francois Romieu wrote:
> Can you send lspci -vx, dmesg and lsmod after the hang ?
>
[-- Attachment #2: lspci --]
[-- Type: text/plain, Size: 4726 bytes --]
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
Subsystem: Asustek Computer, Inc.: Unknown device 80e7
Flags: bus master, medium devsel, latency 0
Memory at fc000000 (32-bit, prefetchable) [size=32M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00: 06 11 91 06 06 00 10 22 c4 00 00 06 00 00 00 00
10: 08 00 00 fc 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 80
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: f6000000-f75fffff
Prefetchable memory behind bridge: f7700000-fbffffff
Capabilities: [80] Power Management version 2
00: 06 11 98 85 07 00 30 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00
20: 00 f6 50 f7 70 f7 f0 fb 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00
0000:00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: Asustek Computer, Inc.: Unknown device 80e7
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management version 2
00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 80
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
0000:00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Flags: bus master, stepping, medium devsel, latency 32
I/O ports at d800 [size=16]
Capabilities: [c0] Power Management version 2
00: 06 11 71 05 87 00 90 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
0000:00:04.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 1a 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d4 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00
0000:00:04.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at d000 [size=32]
Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 1a 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00
0000:00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Flags: medium devsel, IRQ 9
Capabilities: [68] Power Management version 2
00: 06 11 57 30 00 00 90 02 40 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00
0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at b800 [size=128]
Memory at f5800000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at 20000000 [disabled] [size=64K]
00: ec 10 39 81 07 00 00 02 10 00 00 02 00 20 00 00
10: 01 b8 00 00 00 00 80 f5 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 20 40
0000:01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3] (rev a3) (prog-if 00 [VGA])
Subsystem: VISIONTEK: Unknown device 001b
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
Memory at f8000000 (32-bit, prefetchable) [size=64M]
Memory at f7800000 (32-bit, prefetchable) [size=512K]
Expansion ROM at f77f0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 2.0
00: de 10 00 02 07 00 b0 02 a3 00 00 03 00 40 00 00
10: 00 00 00 f6 08 00 00 f8 08 00 80 f7 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 45 15 1b 00
30: 00 00 7f f7 60 00 00 00 00 00 00 00 0a 01 05 01
[-- Attachment #3: dmesg --]
[-- Type: text/plain, Size: 10037 bytes --]
Linux version 2.6.15.4 (root@test) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 PREEMPT Sun Feb 26 14:01:26 EST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000017fec000 (usable)
BIOS-e820: 0000000017fec000 - 0000000017fef000 (ACPI data)
BIOS-e820: 0000000017fef000 - 0000000017fff000 (reserved)
BIOS-e820: 0000000017fff000 - 0000000018000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
383MB LOWMEM available.
On node 0 totalpages: 98284
DMA zone: 4096 pages, LIFO batch:0
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 94188 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:0
DMI 2.3 present.
ACPI: RSDP (v000 ASUS ) @ 0x000f7360
ACPI: RSDT (v001 ASUS TUV4X 0x30303031 MSFT 0x31313031) @ 0x17fec000
ACPI: FADT (v001 ASUS TUV4X 0x30303031 MSFT 0x31313031) @ 0x17fec080
ACPI: BOOT (v001 ASUS TUV4X 0x30303031 MSFT 0x31313031) @ 0x17fec040
ACPI: DSDT (v001 ASUS TUV4X 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 20000000 (gap: 18000000:e7ff0000)
Built 1 zonelists
Kernel command line: root=/dev/hda1 vga=0xa
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01301000)
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 805.786 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 132x60
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 386492k/393136k available (1736k kernel code, 6136k reserved, 555k data, 152k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1613.23 BogoMIPS (lpj=3226475)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel Celeron (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0c00)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0d20, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI: Scanning bus 0000:00
PCI: Found 0000:00:00.0 [1106/0691] 000600 00
PCI: Calling quirk c01dff40 for 0000:00:00.0
PCI: Calling quirk c0257a10 for 0000:00:00.0
PCI: Calling quirk c0257de0 for 0000:00:00.0
PCI: Found 0000:00:01.0 [1106/8598] 000604 01
PCI: Calling quirk c01dff40 for 0000:00:01.0
PCI: Calling quirk c0257a10 for 0000:00:01.0
PCI: Calling quirk c0257de0 for 0000:00:01.0
PCI: Found 0000:00:04.0 [1106/0686] 000601 00
PCI: Calling quirk c01dff40 for 0000:00:04.0
PCI: Calling quirk c0257a10 for 0000:00:04.0
PCI: Calling quirk c0257de0 for 0000:00:04.0
PCI: Found 0000:00:04.1 [1106/0571] 000101 00
PCI: Calling quirk c01dff40 for 0000:00:04.1
PCI: Calling quirk c0257a10 for 0000:00:04.1
PCI: Calling quirk c0257de0 for 0000:00:04.1
PCI: Found 0000:00:04.2 [1106/3038] 000c03 00
PCI: Calling quirk c01dff40 for 0000:00:04.2
PCI: Calling quirk c0257a10 for 0000:00:04.2
PCI: Calling quirk c0257de0 for 0000:00:04.2
PCI: Found 0000:00:04.3 [1106/3038] 000c03 00
PCI: Calling quirk c01dff40 for 0000:00:04.3
PCI: Calling quirk c0257a10 for 0000:00:04.3
PCI: Calling quirk c0257de0 for 0000:00:04.3
PCI: Found 0000:00:04.4 [1106/3057] 000600 00
PCI: Calling quirk c01df9b0 for 0000:00:04.4
PCI quirk: region e800-e80f claimed by vt82c686 SMB
PCI: Calling quirk c01dfc90 for 0000:00:04.4
PCI: Calling quirk c01dff40 for 0000:00:04.4
PCI: Calling quirk c0257a10 for 0000:00:04.4
PCI: Calling quirk c0257de0 for 0000:00:04.4
PCI: Found 0000:00:0a.0 [10ec/8139] 000200 00
PCI: Calling quirk c01dff40 for 0000:00:0a.0
PCI: Calling quirk c0257a10 for 0000:00:0a.0
PCI: Calling quirk c0257de0 for 0000:00:0a.0
PCI: Fixups for bus 0000:00
PCI: Scanning behind PCI bridge 0000:00:01.0, config 010100, pass 0
PCI: Scanning bus 0000:01
PCI: Found 0000:01:00.0 [10de/0200] 000300 00
PCI: Calling quirk c01dff40 for 0000:01:00.0
PCI: Calling quirk c0257a10 for 0000:01:00.0
PCI: Calling quirk c0257de0 for 0000:01:00.0
Boot video device is 0000:01:00.0
PCI: Fixups for bus 0000:01
PCI: Bus scan for 0000:01 returning with max=01
PCI: Scanning behind PCI bridge 0000:00:01.0, config 010100, pass 1
PCI: Bus scan for 0000:00 returning with max=01
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
got res [20000000:2000ffff] bus [20000000:2000ffff] flags 7200 for BAR 6 of 0000:00:0a.0
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: f6000000-f75fffff
PREFETCH window: f7700000-fbffffff
PCI: Calling quirk c01dfcf0 for 0000:00:01.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
Simple Boot Flag at 0x3a set to 0x1
Machine check exception polling timer started.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
PCI: Calling quirk c01dfdf0 for 0000:00:00.0
PCI: Calling quirk c024bea0 for 0000:00:00.0
PCI: Calling quirk c01dfdf0 for 0000:00:01.0
PCI: Calling quirk c024bea0 for 0000:00:01.0
PCI: Calling quirk c01dfb50 for 0000:00:04.0
PCI: Disabling Via external APIC routing
PCI: Calling quirk c01dfdf0 for 0000:00:04.0
PCI: Calling quirk c024bea0 for 0000:00:04.0
PCI: Calling quirk c01dfdf0 for 0000:00:04.1
PCI: Calling quirk c024bea0 for 0000:00:04.1
PCI: Calling quirk c01dfdf0 for 0000:00:04.2
PCI: Calling quirk c024bea0 for 0000:00:04.2
PCI: Calling quirk c01dfdf0 for 0000:00:04.3
PCI: Calling quirk c024bea0 for 0000:00:04.3
PCI: Calling quirk c01dfdf0 for 0000:00:04.4
PCI: Calling quirk c024bea0 for 0000:00:04.4
PCI: Calling quirk c01dfdf0 for 0000:00:0a.0
PCI: Calling quirk c024bea0 for 0000:00:0a.0
PCI: Calling quirk c01dfdf0 for 0000:01:00.0
PCI: Calling quirk c024bea0 for 0000:01:00.0
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:04.1
PCI: Calling quirk c01dfcf0 for 0000:00:04.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: Maxtor 91728D8, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: BENQ DVD DUAL DW1610, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 33750864 sectors (17280 MB) w/512KiB Cache, CHS=33483/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2
hdc: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard as /class/input/input0
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
logips2pp: Detected unknown logitech mouse model 72
input: PS/2 Logitech Mouse as /class/input/input1
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 152k freed
Adding 979924k swap on /dev/hda2. Priority:-1 extents:1 across:979924k
8139too Fast Ethernet driver 0.9.27
PCI: Enabling device 0000:00:0a.0 (0004 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
eth0: RealTek RTL8139 at 0xd8932000, 00:4f:4e:00:5d:fd, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139 rev K'
eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[-- Attachment #4: lsmod --]
[-- Type: text/plain, Size: 71 bytes --]
Module Size Used by
8139too 27136 0
^ permalink raw reply
* Re: RTL 8139 stops RX after receiving a jumbo frame
From: John Zielinski @ 2006-02-26 21:12 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, netdev
In-Reply-To: <1140957965.23286.9.camel@localhost.localdomain>
Alan Cox wrote:
> Should drop the packet, but it may be triggering a driver path with a
> bug. Is this repeatable and with multiple 8139 cards
>
I took the card out of my firewall and put it into my test box. The
test procedure was to ping a third machine from the text box and then
start pinging the test box from the second machine using large packets.
The rev K card would always stop receiving permanently until a
ifdown/ifup was done.
I tried three other cards and they only showed heavy packet loss from
the ping running on the test box. The packet loss went away when the
second machine stopped pinging it with the large packets.
Here's the list of cards:
Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
eth0: Identified 8139 chip type 'RTL-8139 rev K'
Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10)
Subsystem: Accton Technology Corporation EN-1207D Fast Ethernet Adapter
eth0: Identified 8139 chip type 'RTL-8139B'
Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
Subsystem: D-Link System Inc DFE-538TX 10/100 Ethernet Adapter
eth0: Identified 8139 chip type 'RTL-8139C'
Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
eth0: Identified 8139 chip type 'RTL-8139C'
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Alejandro Bonilla @ 2006-02-26 20:20 UTC (permalink / raw)
To: John Stoffel; +Cc: Matthieu CASTET, linux-kernel, netdev
In-Reply-To: <17408.55266.948833.168988@smtp.charter.net>
On Sat, 2006-02-25 at 17:19 -0500, John Stoffel wrote:
> >>>>> "Matthieu" == Matthieu CASTET <castet.matthieu@free.fr> writes:
>
> Matthieu> I will say, why not put the restriction of the firmware
> Matthieu> binary blob ? It run on the device so it will be difficult
> Matthieu> for people to analyse it.
>
> So what do I do when I take my US laptop and fly to country X, which
> has comletely different rules for these radios? Do I have to re-flash
> my firmware to make it work properly?
Intel has got the obligation to make sure they are not letting you use
not allowed channels. If you as a manufacturer allow with a certain
change to let people use the channels they want, you are actually
encouraging people to use those channels. Letting the option available
makes Intel liable to get sued. If you buy an US PC, you stick to the US
channels. If you are a world traveler, buy the PC in japan or in Europe.
Then, you will be able to use the US and ROW(Rest of World) channels.
This is just the way it works, else you are liable. Believe me, and not
only me. Intel does not do things to give you a hard time, it is because
of a reason and they have the best lawyers at it.
It is just the Law and the FCC's.
.Alejandro
>
> The big problem is the lack of global unity, but that will slowly get
> fixes as more countries realize it's a problem. The big issue will be
> military/govt radio spectrum users, they won't want to move if they
> can help it.
>
> John
^ 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