ys of indirect communication!)
--linas
This patch adds PCI Error recovery support to the
Emulex Lightpulse Fibrechannel (lpfc) SCSI device driver.
Lightly tested at this point, works.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Signed-off-by: [EMAIL PROTECTED]
Cc: James Smart <[E
On Thu, Jan 18, 2007 at 11:46:21AM -0800, Allexio Ju wrote:
> Hi,
>
> I've got some questions on supporting PCI Express AER in Linux HBA drivers.
> BTW, I'm developing SCSI HBA driver.
[...]
> What else does SCSI LLD driver need to changed?
There are several scsi controllers that handle pci erro
ee the bug.
Signed-off by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Axboe <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
block/elevator.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux
Hi,
On Thu, Jan 11, 2007 at 04:22:52PM -0500, [EMAIL PROTECTED] wrote:
> This patch is present in upstream and is also present
> in 2.6.20. So this is a new issue.
What was the patch last time around?
It seems I'm seeing this more often than expected. The first time,
the system spewed the soft
On Thu, Dec 21, 2006 at 03:41:39PM +0100, Ingo Molnar wrote:
> On Wed, 2006-12-20 at 19:03 -0600, Linas Vepstas wrote:
> > Same kernel runs fine on power5. Although it does have patches
> > applied, those very same patches boot fine when applied to a slightly
> > older ke
On Thu, Dec 21, 2006 at 11:36:59AM +1100, Anton Blanchard wrote:
>
> On Wed, Dec 20, 2006 at 05:46:47PM -0600, Linas Vepstas wrote:
>
> > System assert at: file: rtas_io_config.c -- line: 195
> > rio_hub_num: 10
> > drawer_num: 6
> > phb_num: 3
> > bu
On Thu, Dec 21, 2006 at 10:09:55AM +1100, Benjamin Herrenschmidt wrote:
>
> > This also doesn't explain the bizarre form of the failure on
> > power4 ... does power4 mishandle twi somehow? Will investigate
> > next.
>
> Or you hit it before you have a console ?
Ahh... I was about to claim I hav
On Thu, Dec 21, 2006 at 08:28:54AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2006-12-20 at 15:19 -0600, Linas Vepstas wrote:
> > On Tue, Dec 19, 2006 at 07:46:50PM -0600, Peter Bergner wrote:
> >
> > I'm trying to figure out how to try a different compiler,
> &g
Use newly minted routine to access the PCI channel state.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/e1000/e1000_main.c |2 +-
drivers/net/ixgb/ixgb_main.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.19-git7/drivers/net
e pci channel error state.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
include/linux/pci.h |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6.19-git7/include/linux/pci.h
===
--- linux-2.6.19-git7.orig/include/
On Tue, Dec 12, 2006 at 12:35:43PM -0800, Greg KH wrote:
> On Tue, Dec 12, 2006 at 01:55:24PM -0600, Linas Vepstas wrote:
> >
> > Subject: [PATCH 1/2]: Renumber PCI error enums to start at zero
> >
> > Renumber the PCI error enums to start at zero for "no
Use newly minted routine to access the PCI channel state.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/e1000/e1000_main.c |2 +-
drivers/net/ixgb/ixgb_main.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.19-git7/drivers/net
ate (which defaults to zero)
to be interpreted as "normal". Add very simple routine to check
state, just in case this ever has to be fiddled with again.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
include/linux/pci.h | 11 ---
1 file changed, 8 insertions
, then one discovers that the
recovery sequence implemented on powerpc is not quite right.
This patch fixes this up.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/eeh.c|1 +
arch/powerpc/platforms/pseries/eeh_driver.c | 13 ++
patch hacks around the 32-device limitation for
the number of evdev drivers. Not clear to me if this
this is the best solution.
Not-even-compile-tested.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/input/input.c | 16 ++--
1 file changed, 10 insertio
<[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |2 +-
drivers/net/spider_net.h |8
2 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.19-rc4-git3/drivers/net/
On Fri, Nov 17, 2006 at 09:35:36AM +1100, Michael Ellerman wrote:
>
> Thanks, new patches look good.
Any clue who I should send these to? I think akpm took the earlier
one, I'm not clear if that means it will slosh into Linus' tree
eventually.
--linas
-
To unsubscribe from this list: send the l
with attribute warn_unused_result
This is done primarily by restructuring the module_init error
handling code.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Ryan S. Arnold <[EMAIL PROTECTED]>
drivers/char/hvcs.c | 95
n pair
of irritating compiler warnings. The first part moves a block
of code from the bottom of the file to the top, which is needed
to enable the cleanup.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Ryan S. Arnold <[EMAIL PROTECTED]>
driv
On Thu, Nov 16, 2006 at 11:03:07AM +1100, Michael Ellerman wrote:
> On Wed, 2006-11-15 at 15:26 -0600, Linas Vepstas wrote:
> >
> > This is a non-urgent patch.
> >
> > I can't figure out who the upstream maintainer for char drivers
> > is sup
On Mon, Aug 29, 2005 at 04:40:20PM +1000, Paul Mackerras was heard to remark:
> Linas Vepstas writes:
>
> > Actually, no. There are three issues:
> > 1) hotplug routines are called from within kernel. GregKH has stated on
> >multiple occasions that doing this is wrong
On Fri, Aug 26, 2005 at 09:37:36AM +1000, Benjamin Herrenschmidt was heard to
remark:
> On Fri, 2005-08-26 at 09:18 +1000, Paul Mackerras wrote:
> > Benjamin Herrenschmidt writes:
> >
> > > Ok, so what is the problem then ? Why do we have to wait at all ? Why
> > > not just unplug/replug right aw
On Fri, Aug 26, 2005 at 07:43:57AM +1000, Benjamin Herrenschmidt was heard to
remark:
> On Thu, 2005-08-25 at 11:21 -0500, Linas Vepstas wrote:
> > On Thu, Aug 25, 2005 at 10:49:03AM +1000, Benjamin Herrenschmidt was heard
> > to remark:
> > >
> > > Of cou
On Thu, Aug 25, 2005 at 10:49:03AM +1000, Benjamin Herrenschmidt was heard to
remark:
>
> Of course, we'll possibly end up with a different ethX or whatever, but
Yep, but that's not an issue, since all the various device-naming
schemes are supposed to be fixing this. Its a distinct problem;
it n
On Thu, Aug 25, 2005 at 10:10:45AM +1000, Paul Mackerras was heard to remark:
> Linas Vepstas writes:
>
> > The meta-issue that I'd like to reach consensus on first is whether
> > there should be any hot-plug recovery attempted at all. Removing
> > hot-plug-recovery
On Wed, Aug 24, 2005 at 10:45:31AM -0500, John Rose was heard to remark:
> > +++ linux-2.6.13-rc6-git9/arch/ppc64/kernel/eeh_driver.c2005-08-23
> > 14:34:44.0 -0500
> > +/*
> > + * PCI Hot Plug Controller Driver for RPA-compliant PPC64 platform.
>
> This probably isn't the right heade
Various PCI bus errors can be signaled by newer PCI controllers. The
core error recovery routines are architecture dependent. This patch adds
a recovery infrastructure for the PPC64 pSeries systems.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/ppc64/kernel/Makefile
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ethernet e100
device driver. The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/ppc64/c
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ten-gigabit
ethernet ixgb device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/ppc64/c
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit
ethernet e1000 device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/ppc64/c
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the Symbios SCSI device driver.
The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/ppc64/configs/pSeries_def
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the IPR SCSI device driver.
The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/ppc64/configs/pSeries_defconfig
notify device
drivers of the various stages of recovery.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
include/linux/pci.h | 39 +++
1 files changed, 39 insertions(+)
Index: linux-2.6.13-rc6-git9/include/linux
What follows is a set of patches to implement a PCI error recovery
system. Some (newer) PCI controllers are able to detect and report
PCI errors, these patches enable this hardware function.
-- the first patch adds documentation, explaining what this is and how
it works.
-- the next patch a
Hi,
On Thu, Aug 18, 2005 at 02:58:28PM +1000, Benjamin Herrenschmidt was heard to
remark:
> On Thu, 2005-08-18 at 14:33 +1000, Paul Mackerras wrote:
> > This patch adds a
> > function to the PCI core that traverses all the PCI devices on a PCI
> > bus and under any PCI-PCI bridges on that bus (an
Hi,
Yes, but ...
On Wed, Jul 13, 2005 at 10:18:57AM +1000, Benjamin Herrenschmidt was heard to
remark:
>
> > Are you assuming that a device driver will use an iochk_read() for
> > every DMA operation? for every MMIO to the card?
> >
> > For high performance devices, it seems to me that this
On Wed, Jul 06, 2005 at 02:18:53PM +0900, Hidetoshi Seto was heard to remark:
> +static int pci_error_recovery(peidx_table_t *peidx)
Minor comment:
Maybe a different name for this routine would be good;
this potentially conflicts with generic pci routines.
--linas
-
To unsubscribe from this list
On Wed, Jul 06, 2005 at 02:17:21PM +0900, Hidetoshi Seto was heard to remark:
>
> Touching poisoned data become a MCA, so now it directly means
Several questions:
Is MCA an exception or fault of some sort, so at some point,
the kernel would catch a fault?
So when you say "Touching poisoned da
Hi,
Sorry for the late response ...
I'm reading the patch, and I'm wondering what about performance and
overhead. Here's the code that concerns me:
On Wed, Jul 06, 2005 at 02:04:14PM +0900, Hidetoshi Seto was heard to remark:
> [This is 3 of 10 patches, "iochk-03-register.patch"]
>
> - Impl
On Tue, Apr 19, 2005 at 11:01:25AM +1000, Benjamin Herrenschmidt was heard to
remark:
> On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
> >
> > Hi,
> >
> > The patch below appears to fix a problem where a number of dead processes
> > linger on the s
On Tue, Apr 19, 2005 at 11:07:01AM +1000, Benjamin Herrenschmidt was heard to
remark:
> On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
> >
> > Hi,
> >
> > The patch below appears to fix a problem where a number of dead processes
> > linger on the s
struct() called on them.
This patch fixes this.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--- arch/ppc64/kernel/process.c.orig2005-04-18 14:26:42.0 -0500
+++ arch/ppc64/kernel/process.c 2005-04-18 14:27:54.0 -0500
@@ -204,7 +204,7 @@ struct task_struct *__swit
On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to
remark:
>
> Additionally, in "real life", very few errors are cause by known errata.
> If the drivers know about the errata, they usually already work around
> them. Afaik, most of the errors are caused by transcient co
Hi,
On Fri, Mar 11, 2005 at 04:12:18PM -0800, long was heard to remark:
> +void hw_aer_unregister(void)
> +{
> + struct pci_dev *dev = (struct pci_dev*)host->dev;
> + unsigned short id;
> +
> + id = (dev->bus->number << 8) | dev->devfn;
> +
> + /* Unregister with AER Root dri
On Wed, Mar 16, 2005 at 02:53:39AM +1100, Stephen Rothwell was heard to remark:
> On Tue, 15 Mar 2005 08:32:27 -0600 Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> >
> > Why not use a byte instead of a full int (reordering the members for
> > alignment)?
>
> Because "classical" boleans are ints.
On Fri, Mar 04, 2005 at 11:03:29AM +0900, Hidetoshi Seto was heard to remark:
> >p.s. I would like to have iochk_read() take struct pci_dev * as an
> >argument. (I could store a pointer to pci_dev in the "cookie" but
> >that seems odd).
>
> I'd like to store the pointer and handle all only with t
On Thu, Mar 03, 2005 at 09:41:43AM +1100, Benjamin Herrenschmidt was heard to
remark:
> On Wed, 2005-03-02 at 12:22 -0600, Linas Vepstas wrote:
> > On Tue, Mar 01, 2005 at 08:49:45AM -0800, Linus Torvalds was heard to
> > remark:
> > >
> > > The new API is w
On Thu, Mar 03, 2005 at 09:46:12AM +1100, Benjamin Herrenschmidt was heard to
remark:
> On Wed, 2005-03-02 at 14:02 -0600, Linas Vepstas wrote:
> > On Wed, Mar 02, 2005 at 09:27:27AM +1100, Benjamin Herrenschmidt was heard
> > to remark:
>
> > That's a style issue.
On Wed, Mar 02, 2005 at 09:27:27AM +1100, Benjamin Herrenschmidt was heard to
remark:
> On Tue, 2005-03-01 at 12:33 -0600, Linas Vepstas wrote:
>
> > The current proposal (and prototype) has a "master recovery thread"
> > to handle the coordinated reset of the
On Wed, Mar 02, 2005 at 10:41:06AM -0800, Jesse Barnes was heard to remark:
> On Wednesday, March 2, 2005 10:22 am, Linas Vepstas wrote:
> > On Tue, Mar 01, 2005 at 08:49:45AM -0800, Linus Torvalds was heard to
> remark:
> > > The new API is what _allows_ a driver to care.
On Wed, Mar 02, 2005 at 03:13:05PM +0900, Hidetoshi Seto was heard to remark:
[ .. iochk_clear() and iochk_read() ...]
> And then, I don't think it need to have "pci" ... limitation of this
> API's target. It would not be match if there are a recoverable device
> over some PCI to XXX bridge, or i
On Tue, Mar 01, 2005 at 08:49:45AM -0800, Linus Torvalds was heard to remark:
>
> The new API is what _allows_ a driver to care. It doesn't handle DMA, but
> I think that's because nobody knows how to handle it (ie it's probably
> hw-dependent and all existign implementations would thus be
> drive
On Wed, Mar 02, 2005 at 11:28:01AM +0900, Hidetoshi Seto was heard to remark:
>
> Note that here is a difficulty: the MCA handler on some arch would run on
> special context - MCA environment. In other words, since some MCA handler
> would be called by non-maskable interrupt(e.g. NMI), so it's dif
On Tue, Mar 01, 2005 at 02:42:11PM +, Matthew Wilcox was heard to remark:
> On Tue, Mar 01, 2005 at 05:33:48PM +0900, Hidetoshi Seto wrote:
> > Today's patch is 3rd one - iochk_clear/read() interface.
> > - This also adds pair-interface, but not to sandwich only readX().
> > Depends on platfo
On Tue, Mar 01, 2005 at 11:37:24AM -0500, Jeff Garzik was heard to remark:
>
> A new API handles none of this.
Seto is propsing an API that solves a different problem than what
you are thinking about.
In my case, the hardware (pci controller) will shut down a pci
slot(s) in the case of a pci err
On Tue, Mar 01, 2005 at 10:08:48AM -0800, Linus Torvalds was heard to remark:
>
> On Tue, 1 Mar 2005, Andi Kleen wrote:
> >
> > But what would the default handling be? It would be nice if there
> > was a simple way for a driver to say "just shut me down on an error"
> > without adding iochk_* to
On Tue, Mar 01, 2005 at 09:10:29AM -0800, Jesse Barnes was heard to remark:
> On Tuesday, March 1, 2005 8:59 am, Matthew Wilcox wrote:
> > The MCA handler has to go and figure out what the hell just happened
> > (was it a DIMM error, PCI bus error, etc).
I assume "MCA" stands for machine check a
On Tue, Feb 15, 2005 at 12:43:29AM +0100, Diego Calleja was heard to remark:
>
> Also, it analyzes all those io "logs" and defragments
I dislike hearing/reading about what XP does, since its probably patented,
and I don't want that shadow hanging over Linux.
I assume that the following simple i
On Wed, Jan 19, 2005 at 05:06:05PM +1100, Paul Mackerras was heard to remark:
> Linas Vepstas writes:
>
> > p.s. It was not clear to me if the EEH patch previously sent
> > (6 January 2005, same subject line) will be wending its way into
> > the main Torvalds kernel
On Wed, Jan 19, 2005 at 05:06:05PM +1100, Paul Mackerras was heard to remark:
> Linas Vepstas writes:
>
> > p.s. It was not clear to me if the EEH patch previously sent
> > (6 January 2005, same subject line) will be wending its way into
> > the main Torvalds kernel
Andrew,
The attached file describes PCI bus EEH "Extended Error Handling"
concepts and operation; could you drop this into the kernel
documentation tree, at
linux-2.6/Documentation/powerpc/eeh-pci-error-recovery.txt ?
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--linas
resending another lost message
- Forwarded message from Linas Vepstas <[EMAIL PROTECTED]>, [EMAIL PROTECTED] -
Subject: Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!
In-Reply-To: <[EMAIL PROTECTED]> "from Gunther Mayer at Apr 8, 2001
10:23:0
Resending ...
- Forwarded message from Linas Vepstas <[EMAIL PROTECTED]>, [EMAIL PROTECTED] -
Subject: Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!
In-Reply-To: <[EMAIL PROTECTED]> "from Gunther Mayer at Apr 8, 2001
10:23:09 pm"
To: Gun
Hi,
another zinger that I am sending to LKML because I don't know where else to send it ...
I've discovered a deadly combination of kernel & lilo (and raid). This may be a pure
lilo bug, but I assume that the kernel+raid aids & abets the problem...:
I am running kernel-2.4.x. Two ide hard d
Hi,
I want to report a trio of raid-related problems. The third one is
very serious, and effectively prevents 2.4.3 from being usable (by me).
First problem: In kernel-2.4.2 and earlier, if the machine is not cleanly
shut down, then upon reboot, RAID reconstruction is automatically started.
(
101 - 165 of 165 matches
Mail list logo
