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
s with the device can immediately 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
ediately 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 <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
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
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
On Thu, Dec
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
On Thu, Dec
f 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
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
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
r 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 flag is
set, or the data is gar
_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
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
is weird: either there's valid data, and the flag is
set, or the data is garbage and the flag isn't set ... how could it be
otherwise?
-- 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
-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.
-- Linas
p.s. you
-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.
-- Linas
p.s. you didn't see my
as 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 unsubsc
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 unsubscribe from
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]
>
&
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
ter 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:
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: send the line unsubscribe linux-kernel
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
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
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
oubt 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/
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: send the line "unsubs
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 "unsubscrib
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
; /* 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 unsubscribe linux-kernel in
the body
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: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
.
--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/
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
odes" 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/
occasional cigarette smoking is known to inevitably lead to
full-fledged heroin addiction, I am pretty sure that 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
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
-
To
.
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
-
To unsubscribe from this list: send
command 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 is, t
.
(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 is, then acked-by me.. )
--linas
-
To unsubscribe from this list: send the line
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 unsu
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
esolves 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
the body of a message to [
really like to nack Tony's patch.
--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/
t, 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 message to
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 message to [EMAIL PROTECTED]
More majordomo info at http
r 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 from this list
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 from this list: send
omeone 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/
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 PROTECTED]
More majord
.
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 PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
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/
ich 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 tempted to go with this patch; but if you prod, I
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]&
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
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 linux
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 tempted to go with this patch; but if you prod, I could attempt
a wait-queue based patch.
--linas
ing, 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 this list: send the line "unsubscribe linux-kern
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
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
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 this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
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.kerne
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.kernel.org/majordomo-info.html
Please read
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
ffy)
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 to [EMAIL P
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 unsubscrib
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
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 this list: send the line unsubscribe linux
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 unsubscribe from this list: send the line unsubscribe
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
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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
.
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 line unsubscribe linux-kernel in
the body of a message to [EMAIL
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
/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
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 info
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 info at http://vger.kernel.org/majordomo-info.html
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
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
cy 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 "unsubscribe linux-kernel
? 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 unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
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:
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
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
: 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
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 instead of doing "real work" :-)
Ra
is fairly stupid. How about we make you the maintainer?
Last time I looked at it, I still wasn't comfortable with it. I'm going
to look at it again.
Please do. Its burning the proverbial hole in my pocket; I'd really
like to get this off my list of things I worry about.
I'm fairly sure Linas
llocation? 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
-
To unsubscr
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
-
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
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.
> >
> >
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.
Sigh. Silly me. Haste makes waste.
--linas
-
To unsubsc
with other uses of that directory. Especially
as things like network devices have user controlled names.
Sigh. Silly me. Haste makes waste.
--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
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
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
[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
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:
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://vger.kernel.org/majordomo-info.html
Please read
nels 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?)
--l
1 - 100 of 341 matches
Mail list logo
