Re: [PATCH 3/4] Documentation: PCI: pci-error-recovery: drop doubled words

Acked-by: Linas Vepstas for this and the other patches in the series. On Fri, Jul 3, 2020 at 4:22 PM Randy Dunlap wrote: > > Drop the doubled word "the". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Bjorn Hel

Re: [PATCH] pci-error-recovery: doc cleanup

Hi, On Tue, Mar 21, 2017 at 9:24 PM, Cao jin wrote: > Include whitespace shooting; correction; typo fix; superfluous word > dropping. > > diff --git a/Documentation/PCI/pci-error-recovery.txt > b/Documentation/PCI/pci-error-recovery.txt > index da3b217..0b6bb3e 100644

Re: [PATCH] pci-error-recovery: doc cleanup

Hi, On Tue, Mar 21, 2017 at 9:24 PM, Cao jin wrote: > Include whitespace shooting; correction; typo fix; superfluous word > dropping. > > diff --git a/Documentation/PCI/pci-error-recovery.txt > b/Documentation/PCI/pci-error-recovery.txt > index da3b217..0b6bb3e 100644 > ---

Re: [PATCH] pci-error-recover: doc cleanup

On Fri, Dec 9, 2016 at 2:37 PM, Cao jin <caoj.f...@cn.fujitsu.com> wrote: > > > On 12/09/2016 02:24 PM, Linas Vepstas wrote: >> I suppose I'm confused, but I recall that link resets are non-fatal. >> Fatal errors typically require that the the pci adapter be compl

Re: [PATCH] pci-error-recover: doc cleanup

On Fri, Dec 9, 2016 at 2:37 PM, Cao jin wrote: > > > On 12/09/2016 02:24 PM, Linas Vepstas wrote: >> I suppose I'm confused, but I recall that link resets are non-fatal. >> Fatal errors typically require that the the pci adapter be completely >> reset, any adapter f

Re: [PATCH] pci-error-recover: doc cleanup

I suppose I'm confused, but I recall that link resets are non-fatal. Fatal errors typically require that the the pci adapter be completely reset, any adapter firmware to be reloaded from scratch, the device driver has to kill all device state and start from scratch. Its huge. If the fatal error is

Re: [PATCH] pci-error-recover: doc cleanup

I suppose I'm confused, but I recall that link resets are non-fatal. Fatal errors typically require that the the pci adapter be completely reset, any adapter firmware to be reloaded from scratch, the device driver has to kill all device state and start from scratch. Its huge. If the fatal error is

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

Zhang, Bjorn, On 21 May 2013 10:41, Liu, Joseph wrote: > Bjorn, > >>> diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c >>> index ed4d094..7abefd9 100644 >>> --- a/drivers/pci/pcie/portdrv_pci.c >>> +++ b/drivers/pci/pcie/portdrv_pci.c >>> @@ -332,13 +332,11 @@ static

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

Hi, On 21 May 2013 02:49, Yanmin Zhang wrote: > On Mon, 2013-05-20 at 10:37 -0500, Linas Vepstas wrote: >> My impression >> is that maybe the AER driver had been doing not quite the right thing >> for a long time. > Pls. provide evidence/facts. The new patch is to

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

Hi, On 21 May 2013 02:49, Yanmin Zhang yanmin_zh...@linux.intel.com wrote: On Mon, 2013-05-20 at 10:37 -0500, Linas Vepstas wrote: My impression is that maybe the AER driver had been doing not quite the right thing for a long time. Pls. provide evidence/facts. The new patch

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

Zhang, Bjorn, On 21 May 2013 10:41, Liu, Joseph joseph@emulex.com wrote: Bjorn, diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c index ed4d094..7abefd9 100644 --- a/drivers/pci/pcie/portdrv_pci.c +++ b/drivers/pci/pcie/portdrv_pci.c @@ -332,13 +332,11 @@

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

On 20 May 2013 12:21, Bjorn Helgaas wrote: > On Fri, May 17, 2013 at 5:56 PM, Rafael J. Wysocki wrote: >> On Friday, May 17, 2013 05:43:33 PM Bjorn Helgaas wrote: >>> On Fri, Apr 26, 2013 at 12:28 AM, Zhang, LongX >>> wrote: > >>> > + /* restore cfg space for possible link reset at

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

_reset() is being called, both the platform and the device driver are expecting smooth sailing ahead. So, looking at the original patch, it seems reasonable. My impression is that maybe the AER driver had been doing not quite the right thing for a long time. -- Linas Vepstas On 20 May 2013 0

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

called, both the platform and the device driver are expecting smooth sailing ahead. So, looking at the original patch, it seems reasonable. My impression is that maybe the AER driver had been doing not quite the right thing for a long time. -- Linas Vepstas On 20 May 2013 09:38, Liu, Joseph joseph

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

On 20 May 2013 12:21, Bjorn Helgaas bhelg...@google.com wrote: On Fri, May 17, 2013 at 5:56 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Friday, May 17, 2013 05:43:33 PM Bjorn Helgaas wrote: On Fri, Apr 26, 2013 at 12:28 AM, Zhang, LongX longx.zh...@intel.com wrote: + /* restore cfg

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

didn't see my earlier reply because I forgot to hit 'plain text reply' On 2 May 2013 22:13, Yanmin Zhang wrote: > > On Thu, 2013-05-02 at 19:00 -0700, Greg Kroah-Hartman wrote: > > On Fri, May 03, 2013 at 08:33:00AM +0800, Yanmin Zhang wrote: > > > On Wed, 2013-05-01 at 2

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

=91%) Linas Vepstas linasveps...@gmail.com (commit_signer:2/8=25%) Yijing Wang wangyij...@huawei.com (commit_signer:2/8=25%,commit_signer:2/11=18%) Jiang Liu jiang@huawei.com (commit_signer:2/8=25%,commit_signer:2/11=18%) Stephen Hemminger shemmin...@vyatta.com (commit_signer:1/8=12

Re: [PATCH 4/6] Hexagon: check to if we will overflow the signal stack

On 3 April 2013 19:02, Richard Kuo wrote: > + /* check if we would overflow the alt stack */ > + if (on_sig_stack(sp) && !likely(on_sig_stack(sp - frame_size))) > + return (void __user __force *)-1UL; I found the !likely construction confusing, as its doing both a

Re: [PATCH 4/6] Hexagon: check to if we will overflow the signal stack

On 3 April 2013 19:02, Richard Kuo r...@codeaurora.org wrote: + /* check if we would overflow the alt stack */ + if (on_sig_stack(sp) !likely(on_sig_stack(sp - frame_size))) + return (void __user __force *)-1UL; I found the !likely construction confusing, as its

Re: [ PATCH RESEND ] PCI-AER: Do not report successful error recovery for devices with AER-unaware drivers

Yes, what you describe appears to be the correct semantics; this would then be the more correct patch. Read-the-email-but-didn't-try-to-test-by: Linas Vepstas gmail.com> -- Linas On 14 November 2012 18:51, Bjorn Helgaas wrote: > > [+cc Lance, Huang, Hidetoshi, Andrew, Zhang] > &

Re: [ PATCH RESEND ] PCI-AER: Do not report successful error recovery for devices with AER-unaware drivers

Yes, what you describe appears to be the correct semantics; this would then be the more correct patch. Read-the-email-but-didn't-try-to-test-by: Linas Vepstas linasvepstas at gmail.com -- Linas On 14 November 2012 18:51, Bjorn Helgaas bhelg...@google.com wrote: [+cc Lance, Huang, Hidetoshi

Re: [PATCH] ehea: Add kdump support

Hi, On Mon, Nov 26, 2007 at 01:41:37PM -0200, Luke Browning wrote: > On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote: > > > For kdump we have to assume that the kernel is fundamentally broken, If I may so humbly suggest: since ehea is a power6 thing only, we should refocus our

Re: [PATCH] ehea: Add kdump support

Hi, On Mon, Nov 26, 2007 at 01:41:37PM -0200, Luke Browning wrote: On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote: For kdump we have to assume that the kernel is fundamentally broken, If I may so humbly suggest: since ehea is a power6 thing only, we should refocus our energies

[PATCH v2] pci hotplug: fix rpaphp directory naming

Fix presentation of the slot number in the /sys/bus/pci/slots directory to match that used in the majority of other drivers. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> -- On Tue, Nov 13, 2007 at 07:26:07PM -0800, Greg KH wrote: > We need a signed-off-by: to be able

[PATCH v2] pci hotplug: fix rpaphp directory naming

Fix presentation of the slot number in the /sys/bus/pci/slots directory to match that used in the majority of other drivers. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] -- On Tue, Nov 13, 2007 at 07:26:07PM -0800, Greg KH wrote: We need a signed-off-by: to be able to apply

[PATCH] pci hotplug: fix rpaphp directory naming

Fix presentation of the slot number in the /sys/bus/pci/slots directory to match that used in the majority of other drivers. -- On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote: > On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote: > > /sys/bus/pci/slots

Re: [PATCH 0/5][RFC] Physical PCI slot objects

On Tue, Nov 13, 2007 at 01:59:39PM -0700, Alex Chiang wrote: > > > On pseries systems, I deal with something called the > > "partitionable endpoint", which I think probably usually > > corresponds to physical slots, but I don't really know. > > > > So, naively, the physical slot concept doesn't

Re: [PATCH 0/5][RFC] Physical PCI slot objects

On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote: > > Also, some companies already provide userspace tools to get all of this > information about the different slots in a system and what is where, > from userspace, no kernel changes are needed. So, why add all this > extra complexity to

Re: [PATCH 3/5, RFC] Introduce pci_slot

On Mon, Nov 12, 2007 at 05:14:47PM -0700, Alex Chiang wrote: > +/* pci_slot represents a physical slot */ > +struct pci_slot { > + struct pci_bus *bus;/* The bus this slot is on */ > + struct pci_slot *next; /* Next slot on this bus */ > + struct hotplug_slot

Re: [PATCH 2/5] Construct one fakephp slot per pci slot

On Mon, Nov 12, 2007 at 05:13:36PM -0700, Alex Chiang wrote: > + slot->name = kmalloc(8, GFP_KERNEL); > + sprintf(slot->name, "fake%d", count++); Please use snprintf to avoid buffer overruns! --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: [PATCH 2/5] Construct one fakephp slot per pci slot

On Mon, Nov 12, 2007 at 05:13:36PM -0700, Alex Chiang wrote: + slot-name = kmalloc(8, GFP_KERNEL); + sprintf(slot-name, fake%d, count++); Please use snprintf to avoid buffer overruns! --linas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

Re: [PATCH 3/5, RFC] Introduce pci_slot

On Mon, Nov 12, 2007 at 05:14:47PM -0700, Alex Chiang wrote: +/* pci_slot represents a physical slot */ +struct pci_slot { + struct pci_bus *bus;/* The bus this slot is on */ + struct pci_slot *next; /* Next slot on this bus */ + struct hotplug_slot *hotplug;

Re: [PATCH 0/5][RFC] Physical PCI slot objects

On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote: Also, some companies already provide userspace tools to get all of this information about the different slots in a system and what is where, from userspace, no kernel changes are needed. So, why add all this extra complexity to the

Re: [PATCH 0/5][RFC] Physical PCI slot objects

On Tue, Nov 13, 2007 at 01:59:39PM -0700, Alex Chiang wrote: On pseries systems, I deal with something called the partitionable endpoint, which I think probably usually corresponds to physical slots, but I don't really know. So, naively, the physical slot concept doesn't really map

[PATCH] pci hotplug: fix rpaphp directory naming

Fix presentation of the slot number in the /sys/bus/pci/slots directory to match that used in the majority of other drivers. -- On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote: On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote: /sys/bus/pci/slots /sys/bus

Re: [PATCH] Align PCI memory regions to page size (4K) - Fix

On Sun, Oct 28, 2007 at 11:52:16PM -0600, Grant Grundler wrote: > > On Sun, Oct 28, 2007 at 03:53:20PM -0400, Barak Fargoun wrote: > ... > > > About your question: today, some of the hypervisors are using linux > > > kernel as their domain-0 (e.g. Xen). In order to implement direct > > > hardware

Re: [PATCH] Align PCI memory regions to page size (4K) - Fix

On Sun, Oct 28, 2007 at 11:52:16PM -0600, Grant Grundler wrote: On Sun, Oct 28, 2007 at 03:53:20PM -0400, Barak Fargoun wrote: ... About your question: today, some of the hypervisors are using linux kernel as their domain-0 (e.g. Xen). In order to implement direct hardware access for

Re: [patch] PCI: disable MSI on more ATI NorthBridges

On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: > Since we have little experience on PCI and MSI here, we had to try to As someone else pointed out, AMD should have *lots* of people with pci and msi experience on the payroll. (Folks here buy AMD-designed pci chips ...) > ONLY >

Re: [patch] PCI: disable MSI on more ATI NorthBridges

On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: Since we have little experience on PCI and MSI here, we had to try to As someone else pointed out, AMD should have *lots* of people with pci and msi experience on the payroll. (Folks here buy AMD-designed pci chips ...) ONLY

Re: [PATCH] pci: implement "pci=noaer"

On Fri, Oct 05, 2007 at 01:17:58PM -0700, Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > For cases in which CONFIG_PCIEAER=y (such as distro kernels), allow users > to disable PCIE Advanced Error Reporting by using "pci=noaer" on the > kernel command line. Looks reasonable to

Re: [PATCH] pci: implement pci=noaer

On Fri, Oct 05, 2007 at 01:17:58PM -0700, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] For cases in which CONFIG_PCIEAER=y (such as distro kernels), allow users to disable PCIE Advanced Error Reporting by using pci=noaer on the kernel command line. Looks reasonable to me.

Re: [PATCH] Simplify yenta code

On Sat, Oct 06, 2007 at 01:26:01PM +0900, Komuro wrote: > Hello, > > Unfortunately, your patch is wrong, > and does not results in the same run-time behaviour. Yes, I thought I'd withdrawn it, as a monday-morning error. If that wasn't clear .. NAK to my own patch. --linas - To unsubscribe from

Re: [PATCH] Simplify yenta code

On Sat, Oct 06, 2007 at 01:26:01PM +0900, Komuro wrote: Hello, Unfortunately, your patch is wrong, and does not results in the same run-time behaviour. Yes, I thought I'd withdrawn it, as a monday-morning error. If that wasn't clear .. NAK to my own patch. --linas - To unsubscribe from this

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote: > On 10/2/07, Tony Breeds <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote: > > > > > I realise it'll make the patch bigger, but this doesn't seem like a > > > particularly good name for

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote: On 10/2/07, Tony Breeds [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote: I realise it'll make the patch bigger, but this doesn't seem like a particularly good name for the variable

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote: > > The thing to remember is that sym2 is in transition from being a dual > BSD/Linux driver to being a purely Linux driver. I was wondering about that; couldn't tell if the split in the code was historical, or being intentionally

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote: The thing to remember is that sym2 is in transition from being a dual BSD/Linux driver to being a purely Linux driver. I was wondering about that; couldn't tell if the split in the code was historical, or being intentionally

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Wed, Oct 03, 2007 at 02:09:46PM +1000, Michael Ellerman wrote: > > Until we initialise what exactly? Until we allocate the error log buffer. The original crash was for a null-pointer deref of the unallocated buffer. I just sent out a patch to fix this; its a bit simpler than the below. In

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Wed, Oct 03, 2007 at 02:09:46PM +1000, Michael Ellerman wrote: Until we initialise what exactly? Until we allocate the error log buffer. The original crash was for a null-pointer deref of the unallocated buffer. I just sent out a patch to fix this; its a bit simpler than the below. In

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote: > Seeing the following from an older power LPAR, pretty sure we had > this in the previous -mm also: I haven't forgetten about this ... and am looking at it now. Seems that whenever I go to reserve the machine pSeries-102, someone

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote: > > Fine by me. Do you have the ability to produce failures on a whim on > your platforms? Yes, although it is very platform specific -- there are actually transistors in the pci bridge chip, which actually short out lines, and

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote: Fine by me. Do you have the ability to produce failures on a whim on your platforms? Yes, although it is very platform specific -- there are actually transistors in the pci bridge chip, which actually short out lines, and so,

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote: Seeing the following from an older power LPAR, pretty sure we had this in the previous -mm also: I haven't forgetten about this ... and am looking at it now. Seems that whenever I go to reserve the machine pSeries-102, someone else

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote: > > I think the fundamental problem is that completions aren't really > supposed to be used like this. Here's one attempt at using completions > perhaps a little more the way they're supposed to be used, Yes, that looks very good

Re: [PATCH] Simplify yenta code

On Mon, Oct 01, 2007 at 12:56:55PM -0600, Matthew Wilcox wrote: > > Are BRIDGE_IO_MAX and BRIDGE_MEM_MAX guaranteed to be the same? @#$%^&*. Red-faced, I withdraw the patch. Must be cross-eyed on a Monday morning. Sorry. --linas - To unsubscribe from this list: send the line "unsubscribe

[PATCH] Simplify yenta code

Simplify some of the resource detection logic in yenta_socket. This patch results in the same run-time behaviour as the current code, but does so with fewer lines of code. This makes the logical flow of the code a bit easier to understand. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]&

[PATCH] Simplify yenta code

Simplify some of the resource detection logic in yenta_socket. This patch results in the same run-time behaviour as the current code, but does so with fewer lines of code. This makes the logical flow of the code a bit easier to understand. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc

Re: [PATCH] Simplify yenta code

On Mon, Oct 01, 2007 at 12:56:55PM -0600, Matthew Wilcox wrote: Are BRIDGE_IO_MAX and BRIDGE_MEM_MAX guaranteed to be the same? @#$%^*. Red-faced, I withdraw the patch. Must be cross-eyed on a Monday morning. Sorry. --linas - To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote: I think the fundamental problem is that completions aren't really supposed to be used like this. Here's one attempt at using completions perhaps a little more the way they're supposed to be used, Yes, that looks very good to

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Thu, Sep 27, 2007 at 04:10:31PM -0600, Matthew Wilcox wrote: > In the error handler, we wait_for_completion(io_reset_wait). > In sym2_io_error_detected, we init_completion(io_reset_wait). > Isn't it possible that we hit the error handler before we hit the > io_error_detected path, and thus the

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote: > On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote: > > Implement the so-called "first failure data capture" (FFDC) for the > > symbios PCI error recovery. After a PCI error event is reported

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote: On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote: Implement the so-called first failure data capture (FFDC) for the symbios PCI error recovery. After a PCI error event is reported, the driver requests that MMIO

Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure

On Thu, Sep 27, 2007 at 04:10:31PM -0600, Matthew Wilcox wrote: In the error handler, we wait_for_completion(io_reset_wait). In sym2_io_error_detected, we init_completion(io_reset_wait). Isn't it possible that we hit the error handler before we hit the io_error_detected path, and thus the

Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions

On Thu, Aug 30, 2007 at 04:00:56PM +0200, Joachim Fenkes wrote: > > Plus, I rather like using > the full_name since it also contains a descriptive name as opposed to > being just nondescript numbers, helping the layman (ie user) to make sense > out of a dev_id. Yes, well, but no. The location

Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions

On Thu, Aug 30, 2007 at 04:00:56PM +0200, Joachim Fenkes wrote: Plus, I rather like using the full_name since it also contains a descriptive name as opposed to being just nondescript numbers, helping the layman (ie user) to make sense out of a dev_id. Yes, well, but no. The location code

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 02:44:36PM -0700, David Miller wrote: > From: David Stevens <[EMAIL PROTECTED]> > Date: Fri, 24 Aug 2007 09:50:58 -0700 > > > Problem is if it increases rapidly, you may drop packets > > before you notice that the ring is full in the current estimated > > interval.

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 11:11:56PM +0200, Jan-Bernd Themann wrote: > (when they are available for > POWER in our case). hrtimer worked fine on the powerpc cell arch last summer. I assume they work on p5 and p6 too, no ?? > I tried to implement something with "normal" timers, but the result >

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote: > Linas Vepstas <[EMAIL PROTECTED]> wrote: > > On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote: > >> 3) On modern systems the incoming packets are processed very fast. > >> Especiall

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 08:52:03AM -0700, Stephen Hemminger wrote: > > You need hardware support for deferred interrupts. Most devices have it > (e1000, sky2, tg3) > and it interacts well with NAPI. It is not a generic thing you want done by > the stack, > you want the hardware to hold off

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote: > 3) On modern systems the incoming packets are processed very fast. Especially >    on SMP systems when we use multiple queues we process only a few packets >    per napi poll cycle. So NAPI does not work very well here and the >

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote: 3) On modern systems the incoming packets are processed very fast. Especially    on SMP systems when we use multiple queues we process only a few packets    per napi poll cycle. So NAPI does not work very well here and the

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 08:52:03AM -0700, Stephen Hemminger wrote: You need hardware support for deferred interrupts. Most devices have it (e1000, sky2, tg3) and it interacts well with NAPI. It is not a generic thing you want done by the stack, you want the hardware to hold off interrupts

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote: Linas Vepstas [EMAIL PROTECTED] wrote: On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote: 3) On modern systems the incoming packets are processed very fast. Especially on SMP systems when we use multiple queues

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 11:11:56PM +0200, Jan-Bernd Themann wrote: (when they are available for POWER in our case). hrtimer worked fine on the powerpc cell arch last summer. I assume they work on p5 and p6 too, no ?? I tried to implement something with normal timers, but the result was

Re: RFC: issues concerning the next NAPI interface

On Fri, Aug 24, 2007 at 02:44:36PM -0700, David Miller wrote: From: David Stevens [EMAIL PROTECTED] Date: Fri, 24 Aug 2007 09:50:58 -0700 Problem is if it increases rapidly, you may drop packets before you notice that the ring is full in the current estimated interval. This is

Re: [PATCH] PCI AER: fix warnings when PCIEAER=n

statement with no effect > drivers/scsi/arcmsr/arcmsr_hba.c:352: warning: statement with no effect > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Acked-by: Linas Vepstas <[EMAIL PROTECTED]> --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel&q

Re: [PATCH] PCI AER: fix warnings when PCIEAER=n

/arcmsr/arcmsr_hba.c:352: warning: statement with no effect Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Acked-by: Linas Vepstas [EMAIL PROTECTED] --linas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info

Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq

On Wed, Aug 22, 2007 at 07:44:41PM +1000, Paul Mackerras wrote: > Fernando Luis Vázquez Cao writes: > > > amiga_request_irq and mach_request_irq are never used, so delete them. > > OK, but is there a particular reason you want to do this? > > The whole of arch/ppc is going away eventually, so I

Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq

On Wed, Aug 22, 2007 at 07:44:41PM +1000, Paul Mackerras wrote: Fernando Luis Vázquez Cao writes: amiga_request_irq and mach_request_irq are never used, so delete them. OK, but is there a particular reason you want to do this? The whole of arch/ppc is going away eventually, so I don't

Re: [PATCH 1/2] Add scaled time to taskstats based process accounting

On Fri, Aug 17, 2007 at 08:22:40AM +1000, Paul Mackerras wrote: > Linas Vepstas writes: > > > My gut impression (maybe wrong?) is that the scaled time is, > > in a certain sense, "more accurate" than the unscaled time. > > The "unscaled" time is just t

Re: [PATCH 1/2] Add scaled time to taskstats based process accounting

On Fri, Aug 17, 2007 at 08:22:40AM +1000, Paul Mackerras wrote: Linas Vepstas writes: My gut impression (maybe wrong?) is that the scaled time is, in a certain sense, more accurate than the unscaled time. The unscaled time is just time, as in how many seconds did this task spend

Re: [PATCH 1/2] Add scaled time to taskstats based process accounting

On Thu, Aug 16, 2007 at 05:09:22PM +1000, Michael Neuling wrote: > This adds two items to the taststats struct to account for user and > system time based on scaling the CPU frequency and instruction issue > rates. > > Adds account_(user|system)_time_scaled callbacks which architectures > can use

Re: [PATCH 1/2] Add scaled time to taskstats based process accounting

On Thu, Aug 16, 2007 at 05:09:22PM +1000, Michael Neuling wrote: This adds two items to the taststats struct to account for user and system time based on scaling the CPU frequency and instruction issue rates. Adds account_(user|system)_time_scaled callbacks which architectures can use to

Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL

On Mon, Aug 13, 2007 at 10:07:25AM -0700, Joe Perches wrote: > On Mon, 2007-08-13 at 10:45 -0500, Linas Vepstas wrote: > > Note quite right. spider-pic is not part of spider_net. > > SPIDERNET NETWORK DRIVER for CELL > P:Linas Vepstas > M:[EMAIL PROTECTED] > L:

Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL

On Mon, Aug 13, 2007 at 10:07:25AM -0700, Joe Perches wrote: On Mon, 2007-08-13 at 10:45 -0500, Linas Vepstas wrote: Note quite right. spider-pic is not part of spider_net. SPIDERNET NETWORK DRIVER for CELL P:Linas Vepstas M:[EMAIL PROTECTED] L:[EMAIL PROTECTED] S

Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL

INTAINERS > @@ -4377,6 +4377,9 @@ P: Linas Vepstas > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Supported > +F: Documentation/networking/spider_net.txt > +F: arch/powerpc/platforms/cell/spider-pic.c > +F: drivers/net/spider_net* Note quite right. spide

Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL

: Linas Vepstas M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Supported +F: Documentation/networking/spider_net.txt +F: arch/powerpc/platforms/cell/spider-pic.c +F: drivers/net/spider_net* Note quite right. spider-pic is not part of spider_net. The rest loks fine. --linas

Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver

On Thu, Jul 05, 2007 at 12:54:06PM -0600, Matthew Wilcox wrote: > On Thu, Jul 05, 2007 at 11:28:38AM -0700, Andrew Morton wrote: > > Well you've sent it a couple of times, and I've sent it in five more times > > over the past year. Once we were told "awaiting maintainer ack". > > > > This

Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver

On Thu, Jul 05, 2007 at 12:54:06PM -0600, Matthew Wilcox wrote: On Thu, Jul 05, 2007 at 11:28:38AM -0700, Andrew Morton wrote: Well you've sent it a couple of times, and I've sent it in five more times over the past year. Once we were told awaiting maintainer ack. This situation is

Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic

On Mon, Jul 30, 2007 at 05:24:33PM +0200, Jan-Bernd Themann wrote: > > Changes to http://www.spinics.net/lists/netdev/msg36912.html > > 1) A new field called "features" has been added to the net_lro_mgr struct. >It is set by the driver to indicate: >- LRO_F_NAPI:Use NAPI /

Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic

On Mon, Jul 30, 2007 at 05:24:33PM +0200, Jan-Bernd Themann wrote: Changes to http://www.spinics.net/lists/netdev/msg36912.html 1) A new field called features has been added to the net_lro_mgr struct. It is set by the driver to indicate: - LRO_F_NAPI:Use NAPI / netif_rx

Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()

On Fri, Jul 13, 2007 at 03:47:02PM -0700, David Miller wrote: > From: [EMAIL PROTECTED] (Linas Vepstas) > Date: Fri, 13 Jul 2007 15:05:15 -0500 > > > > > This is a patch (& bug report) for a crash in sysctl_set_parent() > > in 2.6.22-git2. > > > >

Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()

On Fri, Jul 13, 2007 at 07:06:56PM -0600, Eric W. Biederman wrote: > > .data = _devconf.loop, > > .maxlen = sizeof(int), > > .mode = 0644, > > + .child = 0x0, > >

Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()

On Fri, Jul 13, 2007 at 07:06:56PM -0600, Eric W. Biederman wrote: .data = ipv4_devconf.loop, .maxlen = sizeof(int), .mode = 0644, + .child = 0x0, .proc_handler

Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()

On Fri, Jul 13, 2007 at 03:47:02PM -0700, David Miller wrote: From: [EMAIL PROTECTED] (Linas Vepstas) Date: Fri, 13 Jul 2007 15:05:15 -0500 This is a patch ( bug report) for a crash in sysctl_set_parent() in 2.6.22-git2. Problem: 2.6.22-git2 crashes with a stack trace

[PATCH] crash in 2.6.22-git2 sysctl_set_parent()

e line: + ctl_table devinet_root_dir[3]; Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> I tried to audit some of the code to see where else there might be similar badly-formed static declarations. This is hard, as there's a lot of code. Most seems fine. net/core/neighbour.c |4 n

[PATCH] crash in 2.6.22-git2 sysctl_set_parent()

[3]; Signed-off-by: Linas Vepstas [EMAIL PROTECTED] I tried to audit some of the code to see where else there might be similar badly-formed static declarations. This is hard, as there's a lot of code. Most seems fine. net/core/neighbour.c |4 net/ipv4/devinet.c |7

Re: [PATCH 1/2] [ide] mmio ide support

On Sun, Jul 08, 2007 at 03:15:41PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > on the argument that drivers/ide/ is going away soon. Most > > current distros have already moved over to using libata > > exclusively. > > The in-kernel default for PATA systems is still IDE subsystem. In part

Re: [PATCH 1/2] [ide] mmio ide support

On Sun, Jul 08, 2007 at 03:15:41PM +0200, Bartlomiej Zolnierkiewicz wrote: on the argument that drivers/ide/ is going away soon. Most current distros have already moved over to using libata exclusively. The in-kernel default for PATA systems is still IDE subsystem. In part because

Re: [PATCH pata-2.6 fix] hpt366: use correct enablebits for HPT36x

Hi, On Sat, Jun 30, 2007 at 12:04:22AM +0400, Sergei Shtylyov wrote: > The HPT36x chips finally turned out to have the channel enable bits -- > however, > badly implemented. Make use of them despite it's probably only going to > burden > the driver's code -- assuming both channels are always

  1   2   3   4   >