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
mmediately resume right
where it left off. (this can be hard in practice, if the driver/firmware doesn't
know what it was doing when the error occurred. this might be why no one
implements it.) Anyway, the whole point of a link reset is that it is
explicitly
a non-fatal error.
--linas
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 adap
le to deal with
this, but not today)
By contrast, link resets are far more gentle: the device driver might
have to discard some half-full FIFO's, or cancel some in-flight
commands, but can otherwise gracefully recover without telling the
higher layers that there were any problems.
--linas
O
'restoring') the config space would be wrong ... if I recall
correctly, a pci link reset does not whack the config space, and if
the device itself has not been whacked, then all the contents of the
config space (dma mappings, etc) are all still valid, and should not
be changed!
So, the restore of the config space should be conditional, depending
on whether the device has been reset or not.
-- Linas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
-- provoking
another error or maybe just silently corrupting data. The config
that you want to load should be more-or-less the same one that was
there during kernel boot, before the device-driver started touching
things.
The "dirty hack" is weird: either there's valid data, and the f
.slot_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 2
ed-by or anything; the patches are not "obviously correct" by
visual inspection; they may be right, but would require deeper
thinking about what is actually happening than I'm capable of at this
time; I'm a bit rusty with this code base, and might miss something
important.
-- L
its doing both a
'unlikely' (right?) and inverting the argument. It seems clearer,
to idiots like me, to write this as:
if (on_sig_stack(sp) && unlikely(!on_sig_stack(sp - frame_size)))
since where checking for overflow, and its unlikely that the overflow happened.
-- Linas
--
To u
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]
&
the
dump, the mem is returned to general use.
The key point here, for ehea, is "the hypervisor
will reset he device state to something rational".
Preliminary patches are at
http://patchwork.ozlabs.org/linuxppc/patch?id=14884
and following.
--linas
-
To unsubscribe from this list:
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 a
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
not in /sys
I doubt anyone looks at /sys/bus/pci/slots, I think they mostly
look at the open firmware device tree.
--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/
l, one more thing to
get confused about.
To be clear: above remarks are for the PowerPC boxes. I have
no clue about how things work on the IBM Intel-based boxes.
And Greg's original "get IBM to agree" remark is about the
Intel-based boxes.
--linas
-
To unsubscribe from this list: s
ct hotplug_slot *hotplug; /* Hotplug info (migrate over time) */
How much migration do you expect? Some of it? All of it? If the
answer is "all of it", wouldn't it just be easier to rename
struct hotplug_slot, and go from there?
--linas
-
To unsubscribe from this list: send the line
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 l
t the culture of
"cheat codes" among 12-year-olds is going to lead to an epidemic of
hackers in about 10 years. I am atuned to "wannabe hacker culture").
--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/
at's what it sounds like, to me.
> And what is the software solution or workaround?
Not sure. Sounds like the device driver needs a quirk for this part.
The over-worked Jeff Garzik is the maintainer for that driver.
You should probably provide the pci device id for this beast.
--linas
mand line.
Looks reasonable to me.
(sorry for the belated reply... I also saw this in gregkh's patch
series. Since the email was addressed to me, I figure I should
at least say "yes I read it". Dunno if "Yes-I-read-it-by:" is
the same as "Acked by:", if it
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
c64 box, this resolves a similar
> panic for me.
>
> Tested-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
For the reasons explained, I'd really like to nack Tony's patch.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
n fact, that I thought something
had gone wrong.
I reviewed it one more time, it really does look good. A formal
submission and acked by's at earliest convenience would be good.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
error from previous boot.
EPOW Sensor Value: 0002
EPOW warning due to loss of redundancy.
EPOW general power fault.
I've no clue why firmware thought it was OK to report this
during one of the earliest calls to RTAS; I'm still investiigating
that.
--linas
-
To unsubscribe fro
02,
someone else is using it :-)
--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/
pression
they might not sell it anymore; dunno.
One guy in the lab used to brush a grounding strap across
the pins; this usually got a rise out of the audience.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
quot;eh_wait" in the code), which were later converted to
completions (I also vaguely recall thinking that the new code was
more elegant/simpler). I converted my patch to use the completions
likewise, and, as you've clearly shown, did a rather sloppy job in
the conversion.
I'm tempt
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 "un
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]&
etected() will have run.
So, by my reading, I'd say that init_completion() in
sym2_io_error_detected() has to stay (although perhaps
it should be replaced by the INIT_COMPLETION() macro.)
Removing it will prevent correct operation on the second
and subsequent errors.
--Linas
-
To unsubscribe from thi
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
hat, after four years of
staring at them, I still can't reliably do anything useful with.
Location codes are nice.
--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.
rent estimated
> > interval.
>
> This is one of many reasons why hardware interrupt mitigation
> is really needed for this.
When turning off interrupts, don't turn them *all* off.
Leave the queue-full interrupt always on.
--linas
-
To unsubscribe from this list: send the l
00 jiffy)
is 83 packets a jiffy (for big packets, even more for small packets,
and more again for 10 gigabit cards). So polling once per jiffy is a
latency disaster.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
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
ance of the test case. Since the folks who came up with the
test case were adamant, I turned off the defferred interrupts.
While defferred interrupts are an "obvious" solution, I decided that
they weren't a good solution. (And I have no other solution to offer).
--linas
-
To unsub
nking that, if the system is under heavy load, then the interrupt
rate would fall, since (for less pathological network loads) more
packets would queue up before the poll was serviced. But I did not
actually measure the interrupt rate under heavy load ...
--linas
-
To unsubscribe from
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
ng away eventually, so I don't think we
> need to remove it piece by piece.
Its often easier to port/move stuff if you clean it up first.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
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
pu with frequency scaling, then when would
one ever be interested in the non-scaled time? If the answer
is "never", then why not just always use the scaled time,
instead of adding more stuff to the kernel structs?
--linas
-
To unsubscribe from this list: send the line "unsubscri
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:
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
lly
like to get this off my list of things I worry about.
> I'm fairly sure Linas doesn't want to be the sym2 maintainer. It's
> still an ugly pile of junk that needs cleaning up.
Heh. I have no difficulty living with ugly code: its actually a
great excuse to fix things instea
DMA allocation? Does it
improve only a certain type of traffic (large/small packets, etc.)
-- Example code? What's the API? How should my driver use it?
Right now, I can maybe find answers by doing lots of googling. I'd like
to have some quick way of getting a grip on this.
--linas
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.
> >
> >
gt; Actually come to think of it I am concerned that someone added a
> settable entry into /proc/sys/ it should at least be in /proc/sys/net/
> where it won't conflict with other uses of that directory. Especially
> as things like network devices have user controlled names.
Sig
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 ++
ill IDE subsystem.
In part because libata still does not yet work correctly
for at least some (older) ide chipsets (like mine).
--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:
both channels are always enabled by the
> HighPoint
> BIOS anyway...
>
> Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
>
> ---
> Michal, Linas, please verify the patch... :-)
No negative impact for me.
(Am I supposed to acked-by if I do this kind of review/test?
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]>
Hi,
This patch has been bo
ta_port_flush_task: ENTER
ata_port_flush_task: flush #1
ata1: ata_port_flush_task: flush #2
ata_port_flush_task: EXIT
Then a hard hang here.
This was on 2.6.22-rc5-git1
Again, this disk and controller combo work spotlessly when using
the ide drivers.
--linas
-
To unsubscribe from this list: s
mand queue on
the hard drive, to see if the command actually made it across?
--linas
/dev/hda:
multcount= 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 2479
e does. Given that its being sold at a big discount, it
may even be that the sellers know that this is a crappy disk. :-)
All I want is some way of resetting the disk, and continuing on.
I'm stalled in debugging; I'm not sue what I'm looking for.
--linas
-
To unsubscribe from t
ding it low all the time)...
In my case, ctrl-alt-sysrq doesn't work, which makes it hard to debug.
I'm thinking that trying to debug libata is a better idea, rather than
investing time in ide, right? Although at the moment, libata works even
less; see other email.
--linas
-
To unsu
On Mon, Jun 18, 2007 at 04:22:38PM -0500, linas wrote:
> On Mon, Jun 18, 2007 at 10:04:41PM +0100, Alan Cox wrote:
> > please try using the libata
> > driver.
Its worse. I get a hard hang (sysrq doesn't work) during boot,
just when the system goes to read the partition table
case I guess.
Dohh, yes, of course. Completely forgot about that. (I assume you mean
CONFIG_ATA). Will report tommorrow.
--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.ke
ide the point).
I can prepare a patch, but only with a lot of guidance. I can test
& debug, I'm highly motivated just right now ...
--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'm screwed ...
Any suggestions, experiments, experimental patches, data gathering,
etc. is welcome. The sooner, the better...
--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/
On Thu, May 24, 2007 at 12:26:29AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> Linas Vepstas wrote:
> >I've got a rather old x86 box that I'm booting 2.6.21.1 on;
> >this kernel is not finding an ide controller on it.
>
> >The motherboard has 4 ide contr
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using the original 40-pin IDE ribbon cable) and two
"HighPoint HPT366" controllers, taking the 80-pin cabl
On Tue, May 22, 2007 at 08:53:32PM +0900, Tsutomu OWA wrote:
>
> Hi Ingo and Thomas,
>
> To revert spider_net.c to original one as it turns out that the patch
As the spidernet maintainer, I had not forwarded the previous patch
upstream; it should not have been applied.
-
tected, and then the kernel delivers the MSI to device driver.
The if statements should close that gap.
I'll send an updated patch shortly.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Wed, May 09, 2007 at 03:26:21PM -0500, Linas Vepstas wrote:
> Hi Matthew,
>
> I had been hoping these patches might make it into 2.6.22,
> ... this is a nag note; please forward upstream.
... should I repost the patches?
--linas
-
To unsubscribe from this list: send the line
quot;make ip header fresh and clean on skb" call
that should have been made; if so, I don't know what it is.
--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/
nning RT kernel. PREEPT_NONE kernel works just fine as well.
>
> Hrm... sounds a bit weird. I wonder if there's a locking bug in the
> driver in the first place.
>
> Linas, what's your take ?
Heh. I almost deleted the entire email thread cause it
didn't say "spide
make: *** [_all] Error 2
John Rose is working to fix this "real soon now".
--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 failed to cc some of the people on the cc list ... so am resending.
--linas
On Mon, May 14, 2007 at 06:37:30PM -0500, Linas Vepstas wrote:
>
> This patch adds PCI error recovery support to the
> s2io 10-Gigabit ethernet device driver. Third revision,
> blocks interrupts and
s2io cleanup suggestions, per discussion on mailing lists.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/s2io.c |2 --
drivers/net/s2io.h |1 -
2 files changed, 3 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/
This patch adds PCI error recovery support to the
s2io 10-Gigabit ethernet device driver. Third revision,
blocks interrupts and the watchdog.
Tested, seems to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
Cc: Raghave
Hi Matthew,
I had been hoping these patches might make it into 2.6.22,
... this is a nag note; please forward upstream.
--linas
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
) and 'v_mapped_by_bats'
>
> I find these 50 or so warnings so scary that I've not yet tried
> to boot the kernel. Note that this is a non-modular kernel.
I'm getting oodles of these on an older -mm2 tree. The kernels seem to
work fine. Yes, they should be fixed but
tocol". The hvsi should not
have even tried to register anything. The attached patch seems more
to the point.
--linas
The hvsi driver is used whenever the device-tree contains
nodes for serial ports, and those serial ports speak the hvterm
protocol. However, if no such nodes are found, then
aintainable.
For the patch that touched arch/powerpc/platforms/pseries/eeh_event.c,
I ran a variety of tests, and couldn't see/find/evoke any adverse
effects, so ..
Acked-by: Linas Vepstas <[EMAIL PROTECTED]>
> The second question is whether this is the right implementation.
> k
uld be nice to have threads that can be "fired off" from an
interrupt context. That would simplify the EEH code slightly
(removing a few dozen lines of code that do this bounce).
I presume that various device drivers might find this useful as well.
--linas
-
To unsubscribe from
ted), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is "trivial", the thread just exits
after an hour.
Since these are events rare, I've no particular concern about
performance or resource consumption. The current code seems
to
t sequence.
(includes a whitespace fix for bad indentation).
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/scsi/sym53c8xx_2/sym_glue.c | 15 +++
drivers/scsi/sym53c8xx_2/sym_glue.h |1 +
drivers/scsi/sym53c8xx_2/sym_hipd.c | 18 ++
3 f
clear the irq, assuming the system doesn't
deadlock on a screaming irq.
--linas
Here's the formal changelog entry:
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 teste
small collection of affected
systems is high.
The rest of this email is a long description of the nature
of the bug.
--linas
The basic structure of "normal" UDP/IP/Ethernet
frames (that actually work):
- It starts with the Ethernet header (dest MAC, src MAC, etc.)
- The ne
and is widely deployed by most distros
to handle the "sane naming" problem. In particular, "sane naming"
becomes hard if devices can be hotplugged, whether they are usb or pci
(e.g. a usb-to-serial converter).
--linas
-
To unsubscribe from this list: send the line "unsubscribe lin
On Wed, Apr 04, 2007 at 12:34:53PM -0400, David Woodhouse wrote:
> On Wed, 2007-04-04 at 11:22 -0500, Linas Vepstas wrote:
> > The biggest problem would seem to be that the assignment would
> > depend on the detection order; there don't seem to be unique
> > id's th
ique
id's that would help udev consistently assign device names in
consistent order.
--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/
Greg,
A non-urgent and somwhat ugly patch; please review, and if
it seems correct, please apply.
--linas
While fiddling with PCI hotplugging, I noticed the messages
pci 0001:00:02.4: Error creating sysfs bridge symlink, continuing...
pci 0001:00:02.2: Error creating sysfs bridge symlink
rdware, or this driver, that well.
--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/
Bino, James,
Please review, sign-off and forward upstream.
--linas
If a PCI error is detected that cannot be recovered from, there
will be a double call of lpfc_pci_remove_one(), with the second call
resulting in a null-pointer dereference. The first call occurs in
lpfc_io_error_detected
Update driver support contact info.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED]>
MAINTAINERS |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.20
Janitorial patch. Undo long lines, fix typo in err msg.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 13 +++--
drivers/net/spider_net.h |2 +-
Multiple threads performing a transmit can race into
the spidernet tx ring cleanup code. This puts the
relevant check under a lock.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED]>
drivers/net/s
It appears that under certain circumstances, a race will result
in a double-free of an skb. This patch null's out the skb pointer
upon the skb free, avoiding the inadvertent deref of bogus data.
The next patch fixes the actual race.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]&g
This patch separates the hardware descriptor state from the
driver descriptor state, per (old) suggestion from Ben Herrenschmidt.
This compiles and boots and seems to work.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishi
From: Jens Osterkamp <[EMAIL PROTECTED]>
This moves the medium variable into the spidernet card structure.
It renames the GMII_ variables to BCM54XX specific ones.
Signed-off-by: Jens Osterkamp <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
driver
From: Ishizaki Kou <[EMAIL PROTECTED]>
This patches removes logging for SPIDER_NET_GTMFLLINT interrupts.
Since the interrupts are not irregular, and they happen frequently
when using 100Mbps network switches.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vep
From: Kou Ishizaki <[EMAIL PROTECTED]>
This patch adds or changes some HW specific settings for spider_net on
Celleb.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/Kconfig |2 +-
drivers/net/s
From: Kou Ishizaki <[EMAIL PROTECTED]>
This patch moves calling init_firmware() from spider_net_probe() to
spider_net_open() so as to use the driver by built-in.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
driver
From: Kou Ishizaki <[EMAIL PROTECTED]>
Add auto negotiation support for Celleb.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 176 ++-
driver
As of 2.6.20-git4, the spider_net driver does not compile.
This appears to be due to some archaic usage involving kobjects.
It also fixes a nasty double-free during ifdown of the interface.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc:
e genmii_* functions around to avoid foreward declarations.
Signed-off-by: Jens Osterkamp <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/sungem_phy.c | 389 ++---
Jeff,
Please apply and forward upstream this patch series.
This is the followup to the collision of patches that
landed on your doorstep last week. It rolls up the
patches from Jens and Kou.
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Koushik, Raju,
Please review, comment, and if you find this acceptable,
please forward upstream. This patch incorporates all of
fixes resulting from the last set of discussions, circa
November 2006.
--linas
This patch adds PCI error recovery support to the
s2io 10-Gigabit ethernet device
1 - 100 of 171 matches
Mail list logo
