* [PATCH,v2] Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Frans Pop @ 2009-08-21 6:48 UTC (permalink / raw)
To: Danny Feng; +Cc: Netdev, linux-kernel, Jeff Kirsher, David Miller
In-Reply-To: <4A8E3FC1.50201@redhat.com>
On Friday 21 August 2009, Danny Feng wrote:
> You may also need to silence pci_disable_pcie_error_reporting,
> otherwise rmmod/shutdown, you will get
>
> e1000e 0000:00:19.0: pci_disable_pcie_error_reporting failed
Yes, thanks. Exactly the same thing there. Updated patch below.
From: Frans Pop <elendil@planet.nl>
Subject: net: Don't report an error if devices don't support AER
The only error returned by pci_{en,dis}able_pcie_error_reporting() is
-EIO which simply means that Advanced Error Reporting is not supported.
There is no need to report that, so remove the error check from e1001e,
igb and ixgbe.
Signed-off-by: Frans Pop <elendil@planet.nl>
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index fa92a68..d67798f 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4983,12 +4983,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
goto err_pci_reg;
/* AER (Advanced Error Reporting) hooks */
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
+ pci_enable_pcie_error_reporting(pdev);
pci_set_master(pdev);
/* PCI config space info */
@@ -5301,9 +5296,6 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
/* AER disable */
err = pci_disable_pcie_error_reporting(pdev);
- if (err)
- dev_err(&pdev->dev,
- "pci_disable_pcie_error_reporting failed 0x%x\n", err);
pci_disable_device(pdev);
}
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index adb09d3..1533d6f 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1232,12 +1232,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
if (err)
goto err_pci_reg;
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
+ pci_enable_pcie_error_reporting(pdev);
pci_set_master(pdev);
pci_save_state(pdev);
@@ -1668,9 +1663,6 @@ static void __devexit igb_remove(struct pci_dev *pdev)
free_netdev(netdev);
err = pci_disable_pcie_error_reporting(pdev);
- if (err)
- dev_err(&pdev->dev,
- "pci_disable_pcie_error_reporting failed 0x%x\n", err);
pci_disable_device(pdev);
}
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 77b0381..777556d 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -5430,12 +5430,7 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
goto err_pci_reg;
}
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
+ pci_enable_pcie_error_reporting(pdev);
pci_set_master(pdev);
pci_save_state(pdev);
@@ -5795,9 +5790,6 @@ static void __devexit ixgbe_remove(struct pci_dev *pdev)
free_netdev(netdev);
err = pci_disable_pcie_error_reporting(pdev);
- if (err)
- dev_err(&pdev->dev,
- "pci_disable_pcie_error_reporting failed 0x%x\n", err);
pci_disable_device(pdev);
}
^ permalink raw reply related
* Re: [PATCH] Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Danny Feng @ 2009-08-21 6:33 UTC (permalink / raw)
To: Frans Pop; +Cc: Netdev, linux-kernel, Jeff Kirsher, David Miller
In-Reply-To: <200908210829.10471.elendil@planet.nl>
On 08/21/2009 02:29 PM, Frans Pop wrote:
> On Friday 21 August 2009, Danny Feng wrote:
>> On 08/20/2009 11:14 PM, Frans Pop wrote:
>>> e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed
>>
>> I think this messages comes from hardware does not support pcie aer.
>> In fact the messages is not fatal and can be ignored. Some drivers
>> is silence with pci_enable_pcie_error_reporting ....
>
> Right. The only error returned by the function is -EIO, which looks to be
> "not supported". That's really not an issue to shout about in dmesg...
>
>> My patch is just to fix the logic of pcie aer usage ...
>>
>>> - as the error is non-fatal, should it maybe be changed from dev_err
>>> to dev_info, so that at least it does not show up during a boot
>>> with 'quiet'?
>>
>> I agree with this.... Maybe some of other drivers needs this too
>> (igb,ixgbe)...
>
> Here's a patch that simply drops the message.
> Note: the two scsi drivers that call the function (arcmsr and qla2xxx)
> also don't check the return code.
>
> Alternatives would be:
> - change the message to something like "device does not support advanced
> error reporting (AER)" and make it dev_debug
> - suppress the error in case of -EIO, but I'm not sure that makes sense
> as -EIO is the only error returned and you might not want to ignore other
> errors
>
> If you'd prefer the alternatives, let me know and I'll modify the patch.
You may also need to silence pci_disable_pcie_error_reporting, otherwise
rmmod/shutdown, you will get
e1000e 0000:00:19.0: pci_disable_pcie_error_reporting failed
>
> Cheers,
> FJP
>
>
> From: Frans Pop<elendil@planet.nl>
> Subject: net: Don't report an error if devices don't support AER
>
> The only error returned by pci_enable_pcie_error_reporting() is -EIO
> which simply means that Advanced Error Reporting is not supported.
> There is no need to report that, so remove the error check from e1001e,
> igb and ixgbe.
>
> Signed-off-by: Frans Pop<elendil@planet.nl>
> ---
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index fa92a68..42ac8f1 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -4983,12 +4983,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
> goto err_pci_reg;
>
> /* AER (Advanced Error Reporting) hooks */
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> + pci_enable_pcie_error_reporting(pdev);
>
> pci_set_master(pdev);
> /* PCI config space info */
> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
> index adb09d3..8e80859 100644
> --- a/drivers/net/igb/igb_main.c
> +++ b/drivers/net/igb/igb_main.c
> @@ -1232,12 +1232,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
> if (err)
> goto err_pci_reg;
>
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> + pci_enable_pcie_error_reporting(pdev);
>
> pci_set_master(pdev);
> pci_save_state(pdev);
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index 77b0381..4e0b523 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -5430,12 +5430,7 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
> goto err_pci_reg;
> }
>
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> + pci_enable_pcie_error_reporting(pdev);
>
> pci_set_master(pdev);
> pci_save_state(pdev);
>
^ permalink raw reply
* [PATCH] Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Frans Pop @ 2009-08-21 6:29 UTC (permalink / raw)
To: Danny Feng; +Cc: Netdev, linux-kernel, Jeff Kirsher, David Miller
In-Reply-To: <4A8E01AE.5070900@redhat.com>
On Friday 21 August 2009, Danny Feng wrote:
> On 08/20/2009 11:14 PM, Frans Pop wrote:
> > e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed
>
> I think this messages comes from hardware does not support pcie aer.
> In fact the messages is not fatal and can be ignored. Some drivers
> is silence with pci_enable_pcie_error_reporting ....
Right. The only error returned by the function is -EIO, which looks to be
"not supported". That's really not an issue to shout about in dmesg...
> My patch is just to fix the logic of pcie aer usage ...
>
> > - as the error is non-fatal, should it maybe be changed from dev_err
> > to dev_info, so that at least it does not show up during a boot
> > with 'quiet'?
>
> I agree with this.... Maybe some of other drivers needs this too
> (igb,ixgbe)...
Here's a patch that simply drops the message.
Note: the two scsi drivers that call the function (arcmsr and qla2xxx)
also don't check the return code.
Alternatives would be:
- change the message to something like "device does not support advanced
error reporting (AER)" and make it dev_debug
- suppress the error in case of -EIO, but I'm not sure that makes sense
as -EIO is the only error returned and you might not want to ignore other
errors
If you'd prefer the alternatives, let me know and I'll modify the patch.
Cheers,
FJP
From: Frans Pop <elendil@planet.nl>
Subject: net: Don't report an error if devices don't support AER
The only error returned by pci_enable_pcie_error_reporting() is -EIO
which simply means that Advanced Error Reporting is not supported.
There is no need to report that, so remove the error check from e1001e,
igb and ixgbe.
Signed-off-by: Frans Pop <elendil@planet.nl>
---
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index fa92a68..42ac8f1 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4983,12 +4983,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
goto err_pci_reg;
/* AER (Advanced Error Reporting) hooks */
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
+ pci_enable_pcie_error_reporting(pdev);
pci_set_master(pdev);
/* PCI config space info */
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index adb09d3..8e80859 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1232,12 +1232,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
if (err)
goto err_pci_reg;
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
+ pci_enable_pcie_error_reporting(pdev);
pci_set_master(pdev);
pci_save_state(pdev);
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 77b0381..4e0b523 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -5430,12 +5430,7 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
goto err_pci_reg;
}
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
+ pci_enable_pcie_error_reporting(pdev);
pci_set_master(pdev);
pci_save_state(pdev);
^ permalink raw reply related
* Abour linux driver supports BCM4325
From: feng tian @ 2009-08-21 6:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <f42a38140908202319y5c352aa3s37fec67e5cb8d7a3@mail.gmail.com>
Dear All,
We are working on a project which supports the BCM4325 linux wireless
driver. The interface between the BCM chip and SOC(pxa310) is SDIO.
I did some searches online and found that there is no available driver
for this chip. Do I have to implement this myself? Is there anyone can
provide us some related materials? Thanks very much.
BR
Feng
^ permalink raw reply
* Re: configfs/sysfs
From: Avi Kivity @ 2009-08-21 4:14 UTC (permalink / raw)
To: Nicholas A. Bellinger, Ingo Molnar, Anthony Liguori, kvm,
alacrityvm-devel, linu
In-Reply-To: <20090820224828.GC10558@mail.oracle.com>
On 08/21/2009 01:48 AM, Joel Becker wrote:
> On Thu, Aug 20, 2009 at 09:09:21AM +0300, Avi Kivity wrote:
>
>> On 08/20/2009 01:16 AM, Joel Becker wrote:
>>
>>> With an ioctl() that isn't (well) documented, you have to go
>>> read the structure and probably even read the code that uses the
>>> structure to be sure what you are doing.
>>>
>> An ioctl structure and a configfs/sysfs readdir provide similar
>> information (the structure also provides the types of fields and
>> isn't able to hide some of these fields).
>>
> With an ioctl structure, I can't take a look at what the values
> look like unless I read the code or write up a C program. With a
> configfs file, I can just cat the thing.
>
Unless it's system dependent like many sysfs files. If you're coding
something that's supposed to run on several boxes, coding by example is
not a good idea. Look up the documentation to find out what the values
look like (unfortunately often there is no documentation).
Looking at the value on your box does not indicate the range of values
on other boxes or even if the value will be present on other boxes (due
to having older kernels or different configurations).
>
>
>> "Looking at the values" is what I meant by discouraging
>> documentation. That implies looking at a self-documenting live
>> system. But that tells you nothing about which fields were added in
>> which versions, or fields which are hidden because your hardware
>> doesn't support them or because you didn't echo 1> somewhere.
>>
> Most ioctls don't tell you that either. It certainly won't let
> you know that field foo_arg1 is ignored unless foo_arg2 is set to 2, or
> things like that.
>
Correct. What I mean is that discoverability is great for a sysadmin or
kernel developers exploring the system, but pretty useless for a
programmer writing code that will run on other systems. The majority of
lkml users will find *fs easy to use and useful, but that's not the
majority of our users.
> The problem of versioning requires discipline either way. It's
> not obvious from many ioctls. Conversely, you can create versioned
> configfs items via attributes or directories (same for sysfs, etc).
>
Sure.
>> The maintainer of the subsystem should provide a library that talks
>> to the binary interface and a CLI program that talks to the library.
>> Boring nonkernely work. Alternatively a fuse filesystem to talk to
>> the library, or an IDL can replace the library.
>>
> Again, that helps the user nothing. I don't know it exists. I
> don't have it installed. Unless it ships with the kernel, I have no
> idea about it.
>
That's true for the lkml reader downloading a kernel from kernel.org
(use git already) and run it on a random system. But again the majority
of users will run a distro which is supposed to integrate the kernel and
userspace. The short term gratification of early adopters harms the
integration that more mainstream users expect.
>> Many things start oriented at people and then, if they're useful,
>> cross the lines to machines. You can convert a machine interface to
>> a human interface at the cost of some work, but it's difficult to
>> undo the deficiencies of a human oriented interface so it can be
>> used by a program.
>>
> It's work to convert either way. Outside of fast-path things,
> the time it takes to strtoll() is unimportant. Don't use configfs/sysfs
> for fast-path things.
>
Infrastructure must be careful not to code itself into a corner.
Already udev takes quite a bit of time to run and I have some memories
of problems on thousand-disk configurations. What works reasonably well
with one disk may not work as well with 1000.
No doubt some of the problem is with udev, but I'm sure sysfs
contributes. As a software development exercise reading a table of 1000
objects each with a couple dozen attributes should take less that a
millisecond.
>> I disagree. If it's useful for a human, it's useful for a machine.
>>
> And if it's useful for a machine, a human might want to peek at
> it by hand someday to debug it.
>
We have strace and wireshark to decode binary syscall and wire streams.
>> Moreover, *fs+bash is a user interface. It happens that bash is
>> good at processing files, and filesystems are easily discoverable,
>> so we code to that. But we make it more difficult to provide other
>> interfaces to the same controls.
>>
> Not really. Writing a sane CLI to a binary interface takes
> about as much work as writing a sane API library to a text interface.
> The hard part is not the conversion, in either direction. The hard part
> is defining the interface.
>
A *fs interface limits what you can do, so it makes writing the API
library harder. I'm talking about the issues with atomicity and
notifications.
>>> Configfs, as its name implies,
>>> really does exist for that second case. It turns out that it's quite
>>> nice to use for the first case too, but if folks wanted to go the
>>> syscall route, no worries.
>>>
>> Eventually everything is used in the first case. For example in the
>> virtualization space it is common to have a zillion nodes running
>> virtual machine that are only accessed by a management node.
>>
> Everything is eventually used in the second case, and admin or a
> developer debugging why the daemon is going wrong. Much easier from a
> shell or other generic accessor. Much faster than having to download
> your library's source, learn how to build it, add some printfs, discover
> you have the wrong printfs...
>
As a kernel/user interface, any syscall replacement for *fs is exposed
via strace. It's true that debugging C code is harder than a bit of bash.
>> __u64 says everything about the type and space requirements of a
>> field. It doesn't describe everything (like the name of the field
>> or what it means) but it does provide a bunch of boring information
>> that people rarely document in other ways.
>>
>> If my program reads a *fs field into a u32 and it later turns out
>> the field was a u64, I'll get an overflow. It's a lot harder to get
>> that wrong with a typed interface.
>>
> And if you send the wrong thing to configfs or sysfs you'll get
> an EINVAL or the like.
> It doesn't look like configfs and sysfs will work for you.
> Don't use 'em! Write your interfaces with ioctls and syscalls. Write
> your libraries and CLIs. In the end, you're the one who has to maintain
> them. I don't ever want anyone thinking I want to force configfs on
> them. I wrote it because it solves its class of problem well, and many
> people find it fits them too. So I'll use configfs, you'll use ioctl,
> and our users will be happy either way because we make it work!
>
No, I have to use *fs (at least sysfs) since that's the current blessed
interface. Fragmenting the kernel/userspace is the wrong thing to do, I
value a consistent interface more than fixing the *fs problems (which
are all fixable or tolerable).
This is not a call to deprecate *fs and switch over to a yet another new
thing. Users (and programmers) need some ABI stability. It just arose
because I remarked that I'm not in love with *fs interfaces in an
unrelated flamewar and someone asked me why.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Bill Fink @ 2009-08-21 4:14 UTC (permalink / raw)
To: Neil Horman; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090820201919.GA20750@localhost.localdomain>
On Thu, 20 Aug 2009, Neil Horman wrote:
> On Thu, Aug 20, 2009 at 03:50:44AM -0400, Bill Fink wrote:
>
> > When I tried an actual nuttcp performance test, even when rate limiting
> > to just 1 Mbps, I immediately got a kernel oops. I tried to get a
> > crashdump via kexec/kdump, but the kexec kernel, instead of just
> > generating a crashdump, fully booted the new kernel, which was
> > extremely sluggish until I rebooted it through a BIOS re-init,
> > and never produced a crashdump. I tried this several times and
> > an immediate kernel oops was always the result (with either a TCP
> > or UDP test). A ping test of 1000 9000-byte packets with an interval
> > of 0.001 seconds (which is 72 Mbps for 1 second) on the other hand
> > worked just fine.
>
> The sluggishness is expected, since the kdump kernel operates out of such
> limited memory. don't know why you booted to a full system rather than did a
> crash recovery. Don't suppose you got a backtrace did you?
There was a backtrace on the screen but I didn't have a chance to
record it. BTW did anyone ever think to print the backtrace in
reverse (first to some reserved memory and then output to the display)
so the more interesting parts wouldn't have scrolled off the top of
the screen?
-Bill
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Bill Fink @ 2009-08-21 4:00 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Aviv Greenberg, Andrew Gallatin, netdev
In-Reply-To: <1250774056.16001.157.camel@localhost>
On Thu, 20 Aug 2009, Ben Hutchings wrote:
> On Thu, 2009-08-20 at 03:26 -0400, Bill Fink wrote:
> > On Sat, 15 Aug 2009, Aviv Greenberg wrote:
> >
> > > > There may be something in the chipset
> > >
> > > shooting in the dark: when you lspci -vvv and check the MaxPayload and
> > > MaxReadReq values for the myri devices - what are the values and are
> > > they equal? Are they the same on all your platforms?
> >
> > IIRC, under DevCap they indicated MaxPayload 4096 bytes, and under
> > DevCtl they indicated MaxPayload 128 bytes and MaxReadReq 4096 bytes,
> > and was the same on both the Asus and SuperMicro systems. I will
> > doublecheck tomorrow at work. I am not clear on the meanings of
> > the different parameters. And is DevCtl for PCI control messages
> > and DevCap for actual data transfers or something else?
>
> DevCap is the capability register, which is read-only; DevCtl is the
> control register which holds the actual settings.
>
> MaxPayload is the MTU and MRU for PCIe packets. Each sub-tree of
> devices connected to a single PCIe root port needs to have MaxPayload
> set consistently. MaxReadReq is the maximum size of any DMA read
> request. It is a per-device setting (or possibly per-function; I
> forget). It can be much larger than MaxPayload since read completions
> can be fragmented.
Thanks for the explanation. I saw a BIOS setting that allowed
increasing the MaxPayload from 128 bytes to 256 bytes, and then
verified that an "lspci -vvv" then showed the DevCtl MaxPayload
to be 256 bytes. But unfortunately it didn't help improve the
read side performance any.
-Bill
^ permalink raw reply
* Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Danny Feng @ 2009-08-21 2:08 UTC (permalink / raw)
To: Frans Pop; +Cc: Netdev, linux-kernel, Jeff Kirsher
In-Reply-To: <200908201714.30638.elendil@planet.nl>
On 08/20/2009 11:14 PM, Frans Pop wrote:
> With the current kernel I suddenly get the following error displayed
> during boot:
> e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> ! e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
> e1000e 0000:00:19.0: setting latency timer to 64
> e1000e 0000:00:19.0: irq 26 for MSI/MSI-X
>
> This looks to be the consequence of:
> commit 68eac4602b9104cdaa6c18b3edd914cececa6a1e
> Author: Xiaotian Feng<dfeng@redhat.com>
> Date: Fri Aug 14 14:35:52 2009 +0000
> e1000e: fix use of pci_enable_pcie_error_reporting
>
> Looking at the change it seems logical that this error, that I previously
> only saw during resumes from suppend to RAM, now also shows up during
> system boot. So I don't think it can be qualified as a regression, but it
> is certainly rather annoying.
>
> Questions:
> - is it possible that the error occurs due to a kernel bug, or is this
> certain to be due to broken hardware?
I think this messages comes from hardware does not support pcie aer.
In fact the messages is not fatal and can be ignored. Some drivers
is silence with pci_enable_pcie_error_reporting ....
My patch is just to fix the logic of pcie aer usage ...
> - as the error is non-fatal, should it maybe be changed from dev_err
> to dev_info, so that at least it does not show up during a boot
> with 'quiet'?
I agree with this.... Maybe some of other drivers needs this too
(igb,ixgbe)...
> - if broken hardware is common, should the kernel complain at all,
> or at least maybe show a slightly "friendlier" message?
>
> System: hp2510p (ICH8, Core2 Duo) running x86_64, Debian stable ("Lenny")
>
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82566MM
> Gigabit Network Connection [8086:1049] (rev 03)
> Subsystem: Hewlett-Packard Company Device 30c9
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 26
> Region 0: Memory at e0620000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at e0640000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at 2060 [size=32]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
> Address: 00000000fee0300c Data: 41b1
> Kernel driver in use: e1000e
> Kernel modules: e1000e
>
> I can provide full dmesg and kernel config if desired.
>
> Cheers,
> FJP
>
^ permalink raw reply
* (unknown),
From: Charles Russell Q.. @ 2009-08-21 1:14 UTC (permalink / raw)
I wish to notify you that the late Sir John. Paul Getty Jr. made you one of the beneficiaries to his WILL. You are entitiled to 11% of his total funds of GBP88,260,443.00.
For more information, contact me at: barrcharlesrussell110@gala.net
Yours in services,
Barr. Charles Russell
^ permalink raw reply
* Re: IPV6_RTHDR with a type-0 routing header
From: Shan Wei @ 2009-08-21 1:09 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: brian.haley, davem, netdev
In-Reply-To: <20090820111152.GA20295@uio.no>
Steinar H. Gunderson wrote, at 08/20/2009 07:11 PM:
> Hi,
>
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not type-2;
> should that really be right? I found the following commit:
>
> http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
>
> However, it only seems to change EPERM into EINVAL. I don't see any
About the cause of changing EPERM into EINVAL, can refer to
http://marc.info/?l=linux-netdev&m=122046709502496&w=3.
--
Best Regards
Shan Wei
> reasonable explanation why it should not be simply success; in fact, RFC 3452
> only seems to talk about using type-0 headers with this option.
>
> Any ideas?
>
> /* Steinar */
^ permalink raw reply
* (no subject)
From: Wy @ 2009-08-21 0:08 UTC (permalink / raw)
I have a business deal of $6.8million for you,if interested please contact
me with your required info to email:wynewilliams@9.cn
^ permalink raw reply
* Re: [PATCH] iproute2 flush: handle larger tables and deleted entries
From: Gautam Kachroo @ 2009-08-21 0:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, netdev
In-Reply-To: <4e0db5bc0907151504i28ed3a00l85e6767e9ef59921@mail.gmail.com>
On Wed, Jul 15, 2009 at 3:04 PM, Gautam Kachroo<gk@aristanetworks.com> wrote:
> On Wed, Jul 15, 2009 at 12:19 PM, Stephen
> Hemminger<shemminger@vyatta.com> wrote:
>> On Wed, 15 Jul 2009 10:50:57 -0700
>> Gautam Kachroo <gk@aristanetworks.com> wrote:
>>
>>> On Wed, Jul 15, 2009 at 8:19 AM, Patrick McHardy<kaber@trash.net> wrote:
>>> > Gautam Kachroo wrote:
>>> >> On Tue, Jul 14, 2009 at 2:38 AM, Patrick McHardy<kaber@trash.net> wrote:
>>> >>> Gautam Kachroo wrote:
>>> >>>> use a new netlink socket when sending flush messages to avoid reading
>>> >>>> any pending data on the existing netlink socket.
>>> >>>>
>>> >>>> read all of the response from the netlink request -- this response can
>>> >>>> be split over multiple recv calls, pretty much one per netlink request
>>> >>>> message. ENOENT errors, which correspond to attempts to delete an
>>> >>>> already deleted entry, are ignored. Other errors are not ignored.
>>> >>>
>>> >>> In which case would there be any pending data? From what I can see,
>>> >>> this can only happen when using batching, but in that case the
>>> >>> previous command should continue reading until it has received all
>>> >>> responses (which the netlink functions appear to be doing properly).
>>> >>
>>> >> What is the "previous command"?
>>> >
>>> > The last command before the one executing when using batching.
>>>
>>> This is independent of batching (I assume you're referring to the
>>> -batch option to the ip command).
>>> It happens when running a command like "ip neigh flush to 0.0.0.0/0"
>>> if there are many neighbor entries.
>>>
>>> The implementation of flush commands, e.g. ip neigh flush, sends a
>>> dump request, e.g. RTM_GETNEIGH, and then sends requests, e.g.
>>> RTM_DELNEIGH, *while* there can be unread data from the dump request.
>>> There would be unread data if the response to the dump request was
>>> split over multiple calls to recvmsg.
>>>
>>> >> Are you referring to rtnl_dump_filter? If rtnl_send_check comes across
>>> >> a failure, rtnl_dump_filter will not continue reading.
>>> >>
>>> >> Here's the situation that I'm referring to:
>>> >>
>>> >> If rtnl_send_check detects an error, it returns -1. rtnl_send_check is
>>> >> called from flush_update. The multiple implementations of flush_update
>>> >> (e.g. in ipneigh.c, ipaddress.c) propagate this return value to their
>>> >> caller, e.g. print_neigh or print_addrinfo.
>>> >>
>>> >> print_neigh, print_addrinfo, etc. are called from rtnl_dump_filter.
>>> >> rtnl_dump_filter sits in a loop calling recvmsg on the netlink socket.
>>> >> However, it returns the error value if the filter function (e.g.
>>> >> print_neigh) returns an error. In this case, rtnl_dump_filter can
>>> >> return before it's read all the responses.
>>> >> The error return from rtnl_dump_filter causes the program to exit.
>>> >
>>> > Yes, and I agree with your patch so far. My question is why you
>>> > need another socket.
>>> >
>>> >> use a new netlink socket when sending flush messages to avoid reading
>>> >> any pending data on the existing netlink socket.
>>> >
>>> > Under what circumstances would there be pending data when
>>> > performing a new iproute operation?
>>>
>>> As above, it's not that there is pending data when performing a new
>>> iproute operation, it's that there can be pending data while
>>> performing a single iproute operation, namely ip <object> flush.
>>> The benefit of a new socket is that it won't have any data from the
>>> dump request waiting for it.
>>
>> I posted a better fix (using MSG_PEEK).
>
> Where did you post the fix? I didn't see it on netdev or in the iproute2 git...
> I had considered using MSG_PEEK in rtnl_send_check, but I don't think
> that notices errors with the requests in the "buf" argument of
> rtnl_send_check if there is already pending data -- the recv will peek
> the next chunk of the dump response. The error response will be
> waiting in the queue after the dump response.
> Of course, an error, e.g. EPERM, will eventually be noticed, just not
> as early...
I saw commit 2d8240f8d95dfdc276dcf447623129fb5ccedcd6.
Using MSG_PEEK will prevent pending data from being removed during the
check for errors, but re-using the same socket means that errors won't
be detected until all the pending data has been read.
rtnl_send_check still treats ENOENT as an error. It seems better for
flush to ignore ENOENT. That way a flush will not be disrupted by an
entry being removed since that's not really an error for a flush
operation.
thanks,
-gk
> thanks,
> -gk
>
^ permalink raw reply
* RFC: OFFLINE NAPI FIREWALL and Linux current implementation
From: raz ben yehuda @ 2009-08-21 0:00 UTC (permalink / raw)
To: lkml, netdev, SELinux; +Cc: wiseman
Hello
OFFSCHED stands for the OFFLINE SCHEDULER. OFFLINE SCHEDULER is a technique to remove a processor from the operating
system and assign it a dedicated assignment(s). In this case I assigned my dropped SMT processor to do NAPI and remove
packets by an OFFSCHED firewall rule.
The firewall is offloaded and it is ***not part*** of the operating system. The firewall runs in an offlet
context (see Documentation). The motivation of the offlet firewall is to protect the operating system kernel from
outsider attack, something your system may lack.
Configuration:
#1 Reference test. just generate traffic
---------------------
| |
---------------------- | Linux |
| Traffic Generator | pkts------> | NAPI |
------ --------------- |---------------------|
#2 OFFSCHED test.
-----------------------
| Linux Kernel |
---------------------- |-----------------------|
| Traffic Generator | pkts------> | Offlet NAPI firewall |
------ --------------- |-----------------------|
Machine: Receing host: Supermicro PDMSi, hyper-threading enabled.
Receiving interface: Intel 1Gbps 82546EB. e1000.
Kernel: 2.6.30
I have used pktgen as the traffic generator. pktgen uses port 9 ( discard port ).
I assume that the packet processing consumes processor resources like any other packet that needs to be dropped by the Linux native firewall.
OFFSCHED firewall was set with a firewall rule that drops UDP packets of port 9.
#1 Reference test. Linux napi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 65.3%id, 0.0%wa, 5.0%hi, 29.7%si, 0.0%st
Mem: 1025452k total, 153536k used, 871916k free, 5084k buffers
Swap: 0k total, 0k used, 0k free, 75568k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 10312 668 556 S 0 0.1 0:00.36 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#2 OFFLET FIREWALL. SMT CPU1 is dropped and running OFFSCHED.
Tasks: 58 total, 1 running, 57 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.4%us, 0.4%sy, 0.0%ni, 92.9%id, 0.0%wa, 6.3%hi, 0.0%si, 0.0%st
Mem: 1025452k total, 194256k used, 831196k free, 22528k buffers
Swap: 0k total, 0k used, 0k free, 92808k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 10312 668 556 S 0.0 0.1 0:00.36 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Results
In #2 Hardware interrupts happen because I haven't disabled receiving interrupts entirely (though it is possible).
In the reference test CPU1 is consumed by 35%, while cpu0 is mostly idle. In OFFSCHED kernel CPU0 is 7% busy due
to hardware interrupts. The Intel network Interface was loaded with 1Gbps of incoming traffic.
Analysis
In terms of pure processor consumption, 107/200 is the CPU usage in and "offlet kernel" while 35/200 is the processor
consumption in a non OFFSCHED kernel. So, one may wonder, Aren't we wasting a processor ?
Yes, we do. But what we do earn is an operating system running undisturbed. If i were to load
this machine with more traffic then the operating system at some point, will be too loaded to be even
accessed. In OFFSCHED kernel this will not happen. This is because, a denied packet processing in confined to the
offloaded processor.
Also, I have implemented a minimal server in OFFSCHED. The reason for that is that you can access
an **attacked machine** through the offlet server and apply a firewall rule, something you may not be able to do in Linux
as it is now.
The OFFSCHED project can be found at:
http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/
Thank you
Raz
^ permalink raw reply
* (unknown)
From: wilson @ 2009-08-20 23:18 UTC (permalink / raw)
DO YOU NEED LOAN TO PAY YOUR BILLS? SO CONTACT bishoploancompany@gmail.com for your loan now.
^ permalink raw reply
* Re: configfs/sysfs
From: Joel Becker @ 2009-08-20 22:48 UTC (permalink / raw)
To: Avi Kivity
Cc: Nicholas A. Bellinger, Ingo Molnar, Anthony Liguori, kvm,
alacrityvm-devel, linux-kernel, netdev, Michael S. Tsirkin,
Ira W. Snyder
In-Reply-To: <4A8CE891.2010502@redhat.com>
On Thu, Aug 20, 2009 at 09:09:21AM +0300, Avi Kivity wrote:
> On 08/20/2009 01:16 AM, Joel Becker wrote:
> > With an ioctl() that isn't (well) documented, you have to go
> >read the structure and probably even read the code that uses the
> >structure to be sure what you are doing.
>
> An ioctl structure and a configfs/sysfs readdir provide similar
> information (the structure also provides the types of fields and
> isn't able to hide some of these fields).
With an ioctl structure, I can't take a look at what the values
look like unless I read the code or write up a C program. With a
configfs file, I can just cat the thing.
> "Looking at the values" is what I meant by discouraging
> documentation. That implies looking at a self-documenting live
> system. But that tells you nothing about which fields were added in
> which versions, or fields which are hidden because your hardware
> doesn't support them or because you didn't echo 1 > somewhere.
Most ioctls don't tell you that either. It certainly won't let
you know that field foo_arg1 is ignored unless foo_arg2 is set to 2, or
things like that.
The problem of versioning requires discipline either way. It's
not obvious from many ioctls. Conversely, you can create versioned
configfs items via attributes or directories (same for sysfs, etc).
> The maintainer of the subsystem should provide a library that talks
> to the binary interface and a CLI program that talks to the library.
> Boring nonkernely work. Alternatively a fuse filesystem to talk to
> the library, or an IDL can replace the library.
Again, that helps the user nothing. I don't know it exists. I
don't have it installed. Unless it ships with the kernel, I have no
idea about it.
> Many things start oriented at people and then, if they're useful,
> cross the lines to machines. You can convert a machine interface to
> a human interface at the cost of some work, but it's difficult to
> undo the deficiencies of a human oriented interface so it can be
> used by a program.
It's work to convert either way. Outside of fast-path things,
the time it takes to strtoll() is unimportant. Don't use configfs/sysfs
for fast-path things.
> I disagree. If it's useful for a human, it's useful for a machine.
And if it's useful for a machine, a human might want to peek at
it by hand someday to debug it.
> Moreover, *fs+bash is a user interface. It happens that bash is
> good at processing files, and filesystems are easily discoverable,
> so we code to that. But we make it more difficult to provide other
> interfaces to the same controls.
Not really. Writing a sane CLI to a binary interface takes
about as much work as writing a sane API library to a text interface.
The hard part is not the conversion, in either direction. The hard part
is defining the interface.
> >Configfs, as its name implies,
> >really does exist for that second case. It turns out that it's quite
> >nice to use for the first case too, but if folks wanted to go the
> >syscall route, no worries.
>
> Eventually everything is used in the first case. For example in the
> virtualization space it is common to have a zillion nodes running
> virtual machine that are only accessed by a management node.
Everything is eventually used in the second case, and admin or a
developer debugging why the daemon is going wrong. Much easier from a
shell or other generic accessor. Much faster than having to download
your library's source, learn how to build it, add some printfs, discover
you have the wrong printfs...
> __u64 says everything about the type and space requirements of a
> field. It doesn't describe everything (like the name of the field
> or what it means) but it does provide a bunch of boring information
> that people rarely document in other ways.
>
> If my program reads a *fs field into a u32 and it later turns out
> the field was a u64, I'll get an overflow. It's a lot harder to get
> that wrong with a typed interface.
And if you send the wrong thing to configfs or sysfs you'll get
an EINVAL or the like.
It doesn't look like configfs and sysfs will work for you.
Don't use 'em! Write your interfaces with ioctls and syscalls. Write
your libraries and CLIs. In the end, you're the one who has to maintain
them. I don't ever want anyone thinking I want to force configfs on
them. I wrote it because it solves its class of problem well, and many
people find it fits them too. So I'll use configfs, you'll use ioctl,
and our users will be happy either way because we make it work!
Joel
--
Life's Little Instruction Book #396
"Never give anyone a fruitcake."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Ben Hutchings @ 2009-08-20 13:14 UTC (permalink / raw)
To: Bill Fink; +Cc: Aviv Greenberg, Andrew Gallatin, netdev
In-Reply-To: <20090820032601.03a628cf.billfink@mindspring.com>
On Thu, 2009-08-20 at 03:26 -0400, Bill Fink wrote:
> On Sat, 15 Aug 2009, Aviv Greenberg wrote:
>
> > > There may be something in the chipset
> >
> > shooting in the dark: when you lspci -vvv and check the MaxPayload and
> > MaxReadReq values for the myri devices - what are the values and are
> > they equal? Are they the same on all your platforms?
>
> IIRC, under DevCap they indicated MaxPayload 4096 bytes, and under
> DevCtl they indicated MaxPayload 128 bytes and MaxReadReq 4096 bytes,
> and was the same on both the Asus and SuperMicro systems. I will
> doublecheck tomorrow at work. I am not clear on the meanings of
> the different parameters. And is DevCtl for PCI control messages
> and DevCap for actual data transfers or something else?
DevCap is the capability register, which is read-only; DevCtl is the
control register which holds the actual settings.
MaxPayload is the MTU and MRU for PCIe packets. Each sub-tree of
devices connected to a single PCIe root port needs to have MaxPayload
set consistently. MaxReadReq is the maximum size of any DMA read
request. It is a per-device setting (or possibly per-function; I
forget). It can be much larger than MaxPayload since read completions
can be fragmented.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Strange network timeouts w/ 2.6.30.5
From: Walt Holman @ 2009-08-20 22:21 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <m3skfmk39q.fsf@intrepid.localdomain>
----- "Krzysztof Halasa" <khc@pm.waw.pl> wrote:
> Walt Holman <walt@holmansrus.com> writes:
>
> > dmesg is attached. This box does have >2GB Ram (6GB total). The
> dmesg
> > will show e100 init'd 3 times since the first is the stock
> modprobe,
> > 2nd was forced with use_io and the 3rd modprobe was after reverting
> > the patch.
>
> You most probably can't test without swiotlb (RAM has to be limited
> to
> 2 GB or so), can you? That would (dis)prove my theory. Alternatively
> (or
> better), a test on IOMMU-equipped system would do.
Would something like passing a mem=xx cmdline on x86_64 be sufficient to test this?
-Walt
>
> Since swiotlb is x86-only thing (though other 64-bit archs may have
> something similar), I think the correct work around is to enable the
> "for_device" handoff on !X86.
>
> Something like maybe:
>
> Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index 014dfb6..b610088 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1762,9 +1762,12 @@ static int e100_rx_indicate(struct nic *nic,
> struct rx *rx,
>
> if (ioread8(&nic->csr->scb.status) & rus_no_res)
> nic->ru_running = RU_SUSPENDED;
> +#ifndef CONFIG_X86
> + /* FIXME interferes with swiotlb. */
> pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
> sizeof(struct rfd),
> PCI_DMA_BIDIRECTIONAL);
> +#endif
> return -ENODATA;
> }
>
> --
> Krzysztof Halasa
^ permalink raw reply
* Re: [Bugme-new] [Bug 14007] New: iproute2: socket lookup after policy-based local route returns "connect: Invalid argument"
From: Andrew Morton @ 2009-08-20 21:36 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, markus
In-Reply-To: <bug-14007-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 19 Aug 2009 08:55:44 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14007
>
> Summary: iproute2: socket lookup after policy-based local route
> returns "connect: Invalid argument"
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.31
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: markus@selfnet.de
> Regression: No
>
>
> I want to add policy based routes to my local machine similar to the iptables
> redirect command. With this it is possible to redirect connections without
> losing the destination ip.
> So i tried to add an route of type local to another routing table then table
> local:
>
> sudo ip route add local 192.168.33.0/24 dev eth0 table local
> ping 192.168.33.1 -c 1
> #working
>
> sudo ip route add local 192.168.34.0/24 dev eth0 table main
> ping 192.168.34.1 -c 1
> #connect: Invalid argument
>
> The first one is working, the secound one not. The only difference is another
> routing table. icmp is only an example, tcp and udp doesnt work neither.
>
> I guess somewhere in the socketlookup linux checks the destination ip with the
> local routes only in the local table. perhaps the other tables are missed.
>
> btw: i tried it on every linux with iproute2 i found. with no succeed
>
^ permalink raw reply
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-20 21:28 UTC (permalink / raw)
To: John Dykstra
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <1250801571.7176.10.camel@Maple>
On Thursday 20 August 2009, John Dykstra wrote:
> On Wed, 2009-08-19 at 22:20 +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14002
> > Subject : WARNING: at net/ipv4/af_inet.c:154
> > inet_sock_destruct+0x164/0x1c0()
> > Submitter : Ralf Hildebrandt <ralf.hildebrandt@charite.de>
> > Date : 2009-08-18 12:37 (2 days old)
>
> That looks similar to the WARNING discussed in [1].
>
> There was no resolution to that thread. However, [2] points out
> possible other occurrences of the problem in 2.6.27, 28 and 29.
>
> -- John
>
> [1] http://www.spinics.net/lists/netdev/msg103267.html
> [2] http://www.spinics.net/lists/netdev/msg104120.html
Thanks for the information.
So I'll drop this from the list, since it most probably is not a recent thing.
Best,
Rafael
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Caitlin Bestler @ 2009-08-20 20:58 UTC (permalink / raw)
To: Avi Kivity
Cc: Gregory Haskins, Ingo Molnar, kvm, alacrityvm-devel, linux-kernel,
netdev, Michael S. Tsirkin, Patrick Mullaney
In-Reply-To: <4A8C627C.70001@redhat.com>
On Wed, Aug 19, 2009 at 1:37 PM, Avi Kivity<avi@redhat.com> wrote:
>
> Well I'm not an Infiniband expert. But from what I understand VMM bypass
> means avoiding the call to the VMM entirely by exposing hardware registers
> directly to the guest.
>
It enables clients to talk directly to the hardware. Whether or not
that involves
registers would be model specific. But frequently the queues being written
were in the client's memory, and only a "doorbell ring" involved actual device
resources.
But whatever the mechanism, it enables the client to provide buffer addresses
directly to the hardware in a manner that cannot damage another client. The two
key requirements are a) client cannot enable access to pages that it does
not already have access to, and b) client can delegate that authority to the
Adapter without needing to invoke OS or Hypervisor on a per message
basis.
Traditionally that meant that memory maps ("Regions") were created on the
privileged path to enable fast/non-privileged references by the client.
^ permalink raw reply
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: John Dykstra @ 2009-08-20 20:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <jCYznkTxcLB.A.EPH.eNIjKB@chimera>
On Wed, 2009-08-19 at 22:20 +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14002
> Subject : WARNING: at net/ipv4/af_inet.c:154
> inet_sock_destruct+0x164/0x1c0()
> Submitter : Ralf Hildebrandt <ralf.hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
> Date : 2009-08-18 12:37 (2 days old)
That looks similar to the WARNING discussed in [1].
There was no resolution to that thread. However, [2] points out
possible other occurrences of the problem in 2.6.27, 28 and 29.
-- John
[1] http://www.spinics.net/lists/netdev/msg103267.html
[2] http://www.spinics.net/lists/netdev/msg104120.html
^ permalink raw reply
* Re: sd8686 linux system hang: not always
From: Benoît Vaillant @ 2009-08-20 20:40 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
In-Reply-To: <1250710797.5351.89.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1215 bytes --]
On Wed, Aug 19, 2009 at 02:39:57PM -0500, Dan Williams wrote:
> On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote:
> > /*
> > Just a bit of context information:
> > I'm using an MID (quite close to an Aigo, although bios differs,
> > probably some hardware too, yet I've not checked much on that). I'm
> > trying to use my Marvell card to get wifi access on a debian
> > installation. The other OS installed (midinux) successfully gets a
> > connection using the 8686_v9 mobilin driver, so I'd not go for any
> > hardware issue. This driver failing to compile 'out of the box' on
> > fresh kernels, I thought getting the libertas module working would be
> > a better way to get through.
> > */
> > <snip>
>
> Just for context, what SDIO controller are you using on this platform?
Sure, i can provide that!
lspci claims i's an:
00:e1.0 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06)
00:e1.1 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06)
Complete `lspci -vvv` is attached.
Could this lead to anything already known which i have might missed?
Thanks,
--
Benoît
[-- Attachment #1.2: lspci-vvv.txt --]
[-- Type: text/plain, Size: 7933 bytes --]
00:00.0 Host bridge: Intel Corporation Device 8101 (rev 06)
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:02.0 VGA compatible controller: Intel Corporation Device 8109 (rev 06) (prog-if 00 [VGA controller])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 7
Region 0: Memory at c8080000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at 1800 [size=8]
Region 2: Memory at d0000000 (32-bit, non-prefetchable) [size=128M]
Region 3: Memory at c8000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at <unassigned> [disabled]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Vendor Specific Information <?>
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
00:1a.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB Client Controller (rev 06) (prog-if 80 [Unspecified])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 255
Region 0: Memory at c8020000 (32-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:1b.0 Audio device: Intel Corporation System Controller Hub (SCH Poulsbo) HD Audio Controller (rev 06)
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 255
Region 0: Memory at c8024000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s Enabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Virtual Channel <?>
Capabilities: [130] Root Complex Link <?>
00:1d.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #1 (rev 06) (prog-if 00 [UHCI])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at 1820 [size=32]
Kernel driver in use: uhci_hcd
00:1d.1 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #2 (rev 06) (prog-if 00 [UHCI])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at 1840 [size=32]
Kernel driver in use: uhci_hcd
00:1d.2 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #3 (rev 06) (prog-if 00 [UHCI])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at 1860 [size=32]
Kernel driver in use: uhci_hcd
00:1d.7 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB EHCI #1 (rev 06) (prog-if 20 [EHCI])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 21
Region 0: Memory at c8021000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Kernel driver in use: ehci_hcd
00:1e.0 SD Host controller: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06) (prog-if 01)
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 22
Region 0: Memory at c8021400 (32-bit, non-prefetchable) [size=256]
Kernel driver in use: sdhci-pci
00:1e.1 SD Host controller: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06) (prog-if 01)
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 20
Region 0: Memory at c8021800 (32-bit, non-prefetchable) [size=256]
Kernel driver in use: sdhci-pci
00:1f.0 ISA bridge: Intel Corporation System Controller Hub (SCH Poulsbo) LPC Bridge (rev 06)
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Kernel driver in use: isch_smbus
00:1f.1 IDE interface: Intel Corporation System Controller Hub (SCH Poulsbo) IDE Controller (rev 06) (prog-if 80 [Master])
Subsystem: COMPAL Electronics Inc Device 002e
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
Region 4: I/O ports at 1810 [size=16]
Kernel driver in use: pata_sch
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-20 20:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Mike McCormack, netdev, Richard Leitner
In-Reply-To: <20090819174629.649f837f@nehalam>
[-- Attachment #1: Type: Text/Plain, Size: 2580 bytes --]
Hi Stephen,
Am Donnerstag, 20. August 2009 02:46:29 schrieb Stephen Hemminger:
> On Thu, 20 Aug 2009 07:05:03 +0900
>
> Mike McCormack <mikem@ring3k.org> wrote:
> > 2009/8/20 Rene Mayrhofer <rene.mayrhofer@gibraltar.at>:
> > > Pulling the latest sky2.c and sky2.h from net-next-2.6 and applying the
> > > patch rids me of the oops - it is unreproducible right now. However, a
> > > networking restart (i.e. all interfaces attached to sky2) leaves the
> > > devices in a state where they no longer receive any network packets (at
> > > least nothing visible in tcpdump). In this state, rmmod sky2 / modprobe
> > > sky2 gives:
> >
> > After you've got it into that state, does "rmmod sky2; modprobe sky2"
> > change anything?
Nope, tried it multiple times.
I've also tried the net-next-2.6 version of sky2.[ch] as of yesterday without
Mike's "bandaid" patches. With that version (the last one in branch
gibraltar-3.0 at https://www.gibraltar.at/git/linux-2.6-gibraltar.git), I
managed to successfully do a networking restart (with "light" traffic on one
interface), leaving the interfaces functional after the restart. This worked
even twice in a row, so mabye we are onto something here. This is certainly an
improvement over the version with Mike's last patch (from yesterday) applied,
which left the interfaces broken after a restart (and with the quoted errors
on a rmmod/modprobe sky2).
However, after doing a ping -f on one of the (GBit) interfaces to another host
on the same switch for a few seconds and then executing networking restart,
the result was an immediate reboot of the box without any oops being printed
to the (serial) console beforehand.
The same thing happened without particularly heavy traffic after executing
networking restart twice and then just letting the box sit idle (with some
traffic on the interfaces) for a few minutes.
> Please send (I forget) the hardware info (lspci) and the register values
> from ethtool -d ethX.
Attached (lspci -v).
> Some part of the power control doesn't work on Rene's system, so
> device falls off the bus. Probably no auxilary +5 supplied, the register
> values will tell whether driver is at fault (turning on aux when not
> available), or hardware is lying about vaux.
Is it possible to disable (kernel-level) power control for particular PCI
devices to check if this is indeed the issue? Or do you suspect hardware-level
power-off when the chip state goes down?
best regards,
Rene
--
-------------------------------------------------
Gibraltar firewall http://www.gibraltar.at/
[-- Attachment #2: lspci.out.gz --]
[-- Type: application/x-gzip, Size: 1600 bytes --]
[-- Attachment #3: ethtool.out.gz --]
[-- Type: application/x-gzip, Size: 1425 bytes --]
^ permalink raw reply
* Re: Strange network timeouts w/ 2.6.30.5
From: Krzysztof Halasa @ 2009-08-20 20:28 UTC (permalink / raw)
To: David Miller; +Cc: walt, linux-kernel, netdev
In-Reply-To: <20090820.122850.37712606.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> swiotlb emulates what hardware does, so if it can go wrong with
> swiotlb it can go wrong with hardware to.
>
> Figure out what the exact bug is.
I think I already have.
The exact bug is using streaming allocations for the descriptor.
It can't work consistently on all platforms, period. Streaming
allocation can only have one owner (either CPU or device) at a time, and
e100 driver wants access (for examining desc status) simultaneously with
the hardware (which may alter desc status at any time).
On ARM with the previous patch applied it can work because the CPU cache
has the "dirty" bits (e100 driver only reads from the descriptors).
On x86 without swiotlb it can work because streaming allocations are
already coherent.
On x86 with swiotlb it can't really work reliably (and if does, it does
by pure luck) because (I guess) swiotlb has no "dirty" flag and can't
know when it doesn't need to flush.
There is no other fix than to convert the desc rings to coherent
allocs. I'm going to do precisely that in few days, but we're stuck with
the existing code in 2.6.31 (and 2.6.30.x etc).
--
Krzysztof Halasa
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Neil Horman @ 2009-08-20 20:19 UTC (permalink / raw)
To: Bill Fink; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090820035044.9b70fca6.billfink@mindspring.com>
On Thu, Aug 20, 2009 at 03:50:44AM -0400, Bill Fink wrote:
> On Fri, 14 Aug 2009, Neil Horman wrote:
>
> > On Fri, Aug 14, 2009 at 04:44:12PM -0400, Bill Fink wrote:
> > > On Fri, 7 Aug 2009, Neil Horman wrote:
> > >
> > > > On Fri, Aug 07, 2009 at 08:54:42PM -0400, Bill Fink wrote:
> > > > > On Fri, 7 Aug 2009, Neil Horman wrote:
> > > > >
> > > > > > You're timing is impeccable! I just posted a patch for an ftrace module to help
> > > > > > detect just these kind of conditions:
> > > > > > http://marc.info/?l=linux-netdev&m=124967650218846&w=2
> > > > > >
> > > > > > Hope that helps you out
> > > > > > Neil
> > > > >
> > > > > Thanks! It could be helpful. Do you have a pointer to documentation
> > > > > on how to use it? And does it require the latest GIT kernel or could
> > > > > it possibly be used with a 2.6.29.6 kernel?
> > > > >
> > > > > -Bill
> > > >
> > > > It should apply to 2.6.29.6 no problem (might take a little massaging, but not
> > > > much).
> > >
> > > It doesn't look like I can apply your patches to my 2.6.29.6 kernel.
> > >
> > > For starters, there's no include/trace/events directory, so there's
> > > no include/trace/events/skb.h. There is an include/trace/skb.h file,
> > > but there's no TRACE_EVENT defined anywhere in the kernel.
> > >
> > > I don't suppose it's as simple as defining (from include/linux/tracepoint.h
> > > from Linus's GIT tree):
> > >
> > > #define PARAMS(args...) args
> > >
> > > #define TRACE_EVENT(name, proto, args, struct, assign, print) \
> > > DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
> > >
> > > So do you still think it's reasonable to try applying your patches
> > > to my 2.6.29.6 kernel, or should I get a newer kernel like 2.6.30.4
> > > or 2.6.31-rc6?
> > >
> > > -Thanks
> > >
> > > -Bill
> > >
> > >
> > >
> > I thought the trace stuff went it around 2.6.29 but I might be mistaken.
> > Easiest thing to do likely would be find where in the tree those were introduced
> > and just apply them prior to my patches, or move to the latest kernel if you
> > can (at least for the purposes of testing)
>
> I finally got a 2.6.31-rc6 kernel built and had some limited success
> with your ftrace patches. Doing some simple ping tests I was able to
> verify that everything was mostly as expected regarding CPU and NUMA
> memory affinity, with one weird exception. eth2 through eth7, which
> all connect to the 5520 I/O Hub that connects to NUMA node 1, all
> correctly showed their allocations and consumptions on NUMA node 1.
> eth8 through eth13 are all connected to the 5520 I/O Hub that connects
> to NUMA node 0, and eth9 through eth13 all correctly reflected that
> on the ping ftrace tests. But eth8 showed its allocations being
> done on NUMA node 1 instead of the expected NUMA node 0, which just
> doesn't make sense since eth8 and eth9 are part of a dual-port 10-GigE
> Myricom NIC (and I doublechecked that all the IRQ assignments were
> correct).
>
Hmm, memory pressure on node zero causing netdev_alloc_skb to allocate on a
remote node perhaps?
> When I tried an actual nuttcp performance test, even when rate limiting
> to just 1 Mbps, I immediately got a kernel oops. I tried to get a
> crashdump via kexec/kdump, but the kexec kernel, instead of just
> generating a crashdump, fully booted the new kernel, which was
> extremely sluggish until I rebooted it through a BIOS re-init,
> and never produced a crashdump. I tried this several times and
> an immediate kernel oops was always the result (with either a TCP
> or UDP test). A ping test of 1000 9000-byte packets with an interval
> of 0.001 seconds (which is 72 Mbps for 1 second) on the other hand
> worked just fine.
>
The sluggishness is expected, since the kdump kernel operates out of such
limited memory. don't know why you booted to a full system rather than did a
crash recovery. Don't suppose you got a backtrace did you?
Neil
> -Thanks
>
> -Bill
>
^ 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