? Seto, would
this be useful to you?
--linas
===
Header file:
/**
* EEH Notifier event flags.
* Freeze -- pci slot is frozen, no i/o is possible
*/
#define EEH_NOTIFY_FREEZE 1
/** EEH event -- structure holding pci slot data that describes
the guys over here because my hack-ish code
is hackish, and isn't arch-generic, and Paul Mackerras doesn't like it,
which is why Benh is threatening to re-write it, and etc. ...
which is why Seto is involved, and we're having this conversation ...
--linas
-
To unsubscribe from this list: send
() would
check a flag and maybe call firmware, but would not otherwise have to
fiddle with interrupts).
--linas
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).
-
To unsubscribe from this list: send
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. It doesn't handle DMA
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 pci controller. This master
recovery
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. Propose an API, I'll code it. We
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 what _allows_ a driver to care. It doesn't handle
around IO accesses.
> I think defaulting these to disable and restore interrupts is a very bad idea.
> They should probably be no-ops in the generic case.
Yes, they should be no-ops. save/resotre interrupts would be a bad idea.
--linas
-
To unsubscribe from this list: send the line "unsubscribe li
rivers while the
pci controller is being reset.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
i slot is "isolated"
all i/o is blocked, including dma.
The current prototype code tells the device driver that the pci slot is
hung, then it resets the slot, then it tells the device driver that the
pci slot is good-to-go again.
My goal is to negotiate a standard set of interfa
mented in struct pci_driver. It can recover
from pci errors on ethernet cards, and I have one scsi driver that
successfully recovers with above API, and am working on adding recovery
to the symbios driver.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
recovery
to the symbios driver.
--linas
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the device driver that the
pci slot is good-to-go again.
My goal is to negotiate a standard set of interfaces in struct pci_driver
to do the above. (see other email).
--linas
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
while the
pci controller is being reset.
--linas
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
/resotre interrupts would be a bad idea.
--linas
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
r whatever whiz-bang technique someone is into.
Just keep it running in the background, low priority, constantly...
This would give you the best "time weighted" disk access performance,
although it would potentially hurt boot times, since most users spend
most of thier time doing disk access othe
in the background, low priority, constantly...
This would give you the best time weighted disk access performance,
although it would potentially hurt boot times, since most users spend
most of thier time doing disk access other than booting ...
--linas
-
To unsubscribe from this list: send the line
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
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 tree, or not. I hadn't really
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 tree, or not. I hadn't really
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]&g
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
p.s
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
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: Gunther Mayer [EMAIL PROTE
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:09 pm"
To: Gunther Ma
s reporting the physical
location
of the kernel image on the disk; but since the numbers bounce around, that can't be
right.
Or is this just weird bios head/cyl/sect math flakiness?)
--linas
PGP signature
click from the
drive).
On 2.4.2 kernels, the disk activity light is constantly on... and the
fsck proceeds apace.
Whatever it is that changed in 2.4.3, it makes unclean reboots
impossible ...
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
click from the
drive).
On 2.4.2 kernels, the disk activity light is constantly on... and the
fsck proceeds apace.
Whatever it is that changed in 2.4.3, it makes unclean reboots
impossible ...
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
of the kernel image on the disk; but since the numbers bounce around, that can't be
right.
Or is this just weird bios head/cyl/sect math flakiness?)
--linas
PGP signature
el 2.5? Umm, given that a stable linux 2.6/3.0 might be
years away ... and this seems 'minor', wouldn't it be better to
submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x
patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this
cant be more than a few hundred lines of cod
driver as a 2.4.x
patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this
cant be more than a few hundred lines of code? Requireing no other
changes to the kernel?
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
into xf86? should I pester someone over there about it? should I assume
that 'everything will be OK', if I wait long enough?
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
is mouse seems to set every fourth byte to zero, which should allow
syncing ...
I'm still investigating to see if the kernel buffer is overflowing ...
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
...
I'm still investigating to see if the kernel buffer is overflowing ...
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
that 'everything will be OK', if I wait long enough?
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
so I assume its OK ... Besides, the
symptoms don't point at the connector.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
ches are unfruitful) and that
the only place to hunt is in the kernel.
---
So: any advice, comments, suggestions before I embark on a long and
possibly fruitless hunt? Any recommendations for best tools/proceedures
to catch it 'in the act'?
--linas
p.s. direct replies to [EMAIL PROTE
are unfruitful) and that
the only place to hunt is in the kernel.
---
So: any advice, comments, suggestions before I embark on a long and
possibly fruitless hunt? Any recommendations for best tools/proceedures
to catch it 'in the act'?
--linas
p.s. direct replies to [EMAIL PROTECTED
OK ... Besides, the
symptoms don't point at the connector.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://w
301 - 341 of 341 matches
Mail list logo
