On Thu, Nov 29, 2018 at 4:33 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 04, 2018 at 03:13:56PM -0500, Mitch Harder wrote:
> > On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
> > wrote:
> > > 4.14-stable review patch. If anyone has any objections
On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric Dumazet
>
> commit bffa72cf7f9df842f0016ba03586039296b4caaf upstream
>
> skb->rbnode shares space with skb->next, skb->pr
ACK
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Alex Williamson
> Sent: Monday, July 27, 2015 4:19 PM
> To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Su
ACK
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Alex Williamson
> Sent: Monday, July 27, 2015 4:19 PM
> To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Su
On Tue, Aug 20, 2013 at 9:51 AM, Mitch Harder
wrote:
> On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim wrote:
>> Hello,
>>
>> On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote:
>>> Hi, Mitch
>>>
>>> On 08/17/2013 10:01 PM, Mitch Harder w
On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim wrote:
> Hello,
>
> On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote:
>> Hi, Mitch
>>
>> On 08/17/2013 10:01 PM, Mitch Harder wrote:
>> > I'm encountering a BUG while using a ZRAM Swap device.
>
I'm encountering a BUG while using a ZRAM Swap device.
The call trace seems to involve the changes recently added to 3.10.6
by the patch:
zram: use zram->lock to protect zram_free_page() in swap free notify path
The hardware is a x86 single CPU AMD Athlon XP system with 1GB RAM.
I'm implementing
On 1/18/2013 4:35 PM, H. Peter Anvin wrote:
> On 01/18/2013 05:05 PM, Mitch Bradley wrote:
>>
>>
>> On 1/18/2013 2:42 PM, H. Peter Anvin wrote:
>>> On 01/18/2013 04:40 PM, Andres Salomon wrote:
>>>> Bad news on this patch; I've been told that it
On 1/18/2013 2:42 PM, H. Peter Anvin wrote:
> On 01/18/2013 04:40 PM, Andres Salomon wrote:
>> Bad news on this patch; I've been told that it breaks booting on an
>> XO-1.5. Does anyone from OLPC know why yet?
>
> What are the settings of CR0 and CR4 on kernel entry on XO-1.5?
CR0 is 0x80
On Wed, Dec 19, 2012 at 11:21 AM, Nitin Gupta wrote:
> On 12/19/2012 08:17 AM, Greg KH wrote:
>> On Wed, Dec 19, 2012 at 07:53:36AM -0800, Nitin Gupta wrote:
>>> On 12/19/2012 07:08 AM, Greg KH wrote:
On Tue, Dec 18, 2012 at 11:21:28PM -0800, Nitin Gupta wrote:
> On 12/18/2012 07:49 PM, G
On 12/17/2012 12:04 PM, Stephen Warren wrote:
> On 12/17/2012 02:58 PM, Mitch Bradley wrote:
>> On 12/17/2012 11:36 AM, Stephen Warren wrote:
>>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>>>> Nvidia's Tegra has multiple uart controller which supports:
&
On 12/17/2012 11:36 AM, Stephen Warren wrote:
> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>> Nvidia's Tegra has multiple uart controller which supports:
>> - APB dma based controller fifo read/write.
>> - End Of Data interrupt in incoming data to know whether end
>> of frame achieve or not.
On 11/13/2012 8:29 AM, Stephen Warren wrote:
> On 11/13/2012 11:10 AM, Mitch Bradley wrote:
>> It seems to me that this capebus discussion is missing an important
>> point. The name capebus suggests that it is a bus, so there should be a
>> parent node to represent that b
s.
If something about the design of capebus makes that impossible, I
respectfully suggest that its design should be reviewed, taking into
account the many years of industry experience about modularity.
Mitch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On 11/8/2012 3:28 AM, Koen Kooi wrote:
>
> Op 7 nov. 2012, om 23:35 heeft Ryan Mallon het volgende
> geschreven:
>
>> On 06/11/12 08:40, Tabi Timur-B04825 wrote:
>>> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely
>>> wrote:
>>>
Jane is building custom BeagleBone expansion boards called 'ca
On 11/6/2012 12:37 PM, Stephen Warren wrote:
> On 11/05/2012 01:40 PM, Grant Likely wrote:
>> Hey folks,
>>
>> As promised, here is my early draft to try and capture what device
>> tree overlays need to do and how to get there. Comments and
>> suggestions greatly appreciated.
>
> Interesting. This
On 10/23/2012 1:15 PM, Jon Hunter wrote:
> Hi Mitch,
>
> On 10/23/2012 11:55 AM, Mitch Bradley wrote:
>> On 10/23/2012 4:49 AM, Jon Hunter wrote:
>>
>>> Therefore, I believe it will improve search time and hence, boot time if
>>> we have interrupt-parent
ot;.
Now I see that you meant that the driver should explicitly call
abstracted functions.
On 10/23/2012 7:20 AM, Felipe Balbi wrote:
> HI,
>
> On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
>> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
>>> Hi,
>>&g
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> Hi,
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when y
On 10/23/2012 4:49 AM, Jon Hunter wrote:
> Therefore, I believe it will improve search time and hence, boot time if
> we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be com
On 10/10/2012 1:16 PM, David Gibson wrote:
> On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
>> On 10/10/2012 10:16 AM, Stephen Warren wrote:
>>> On 10/10/2012 01:24 AM, David Gibson wrote:
On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> On Oct 9, 2012, at 6:04
On 10/10/2012 8:45 AM, Stephen Warren wrote:
> On 10/10/2012 12:23 PM, Mitch Bradley wrote:
>> On 10/10/2012 7:09 AM, Rob Herring wrote:
>>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>>>>
>&g
On 10/10/2012 8:40 AM, Stephen Warren wrote:
> On 10/10/2012 11:09 AM, Rob Herring wrote:
>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>
> What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit
On 10/10/2012 7:09 AM, Rob Herring wrote:
> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
>>>
>>> How not to abuse the ever-loving shit out of it? :-)
>>
>> Perhaps we can just handle this
On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I think
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen wrote:
> On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
>> looks like ARM results are inconclusive from a lot of folks without
>> bandwidth to do a write-up, what about just plain STAGING status for ARM so
>> the android tweakers can bea
On 8/16/2012 8:38 AM, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
>> Some device drivers (panel backlights especially) need to follow precise
>> sequences for powering on and off, involving gpios, regulators, PWMs
>> with a precise powering order and delays to respect b
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote:
> On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote:
>> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote:
>>
>>> I can't comment on the sysfs-vs-dev interface location, but I don't
>>> think it addresses Johannes' issue; finding out w
On 8/1/2012 9:47 AM, Alex Courbot wrote:
> On 07/31/2012 09:55 PM, Mitch Bradley wrote:
>> On 7/31/2012 8:38 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>>>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>>>
On 7/31/2012 8:38 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>>>> On 07/31/2012 07:45 AM, Stephen Warren
On 7/31/2012 6:56 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>> I wonder if using the same structure/array as input and output would
>>> simplify the API; the platform data would fill in the fields ment
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba wrote:
> On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote:
>> I was testing the lz4(hc) patches, and I found the the compression
>> INCOMPAT flags are not being updated using the method in this patch.
>>
>> The
On Thu, Jun 28, 2012 at 10:40 AM, David Sterba wrote:
> On Tue, Jun 26, 2012 at 08:48:37AM +0200, Arnd Hannemann wrote:
>> How show should we proceed to get above mentioned patch
>> (or the similar patch from Andrei Popa) merged?
>
> Josef picked the patch into btrfs-next, I see not problem to inc
s to trigger it ever so often if there is other
activity also going on.
M
Original Message
Subject: Re: ext3 SMP bug ? PANIC in __d_find_alias
Date: Wed, 12 Dec 2007 20:36:40 +0100
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
To: Mitch <[EMAIL PROTECTED]>
CC: l
fact that this is tainted (due to nvidia) is a red herring i
think because both my machines (the SMP and UP one) are using the same
nvidia module and the panic is in ext3 code.
Help
Mitch
Dec 10 03:02:43 home kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address
l Message
Subject: ext3_ordered_writepage panic on shiny new 2.6.22
Date: Sat, 14 Jul 2007 18:18:14 +0400
From: Mitch <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Hi
Light load on my system and encoding a home video to the disk using
mencoder and i get this...
BUG: unable to handle kernel NUL
Hi
Light load on my system and encoding a home video to the disk using
mencoder and i get this...
BUG: unable to handle kernel NULL pointer dereference at virtual address
0004
printing eip:
c01a478e
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: nls_iso8859_1 nls_cp437
n find it here:
http://bugzilla.kernel.org/show_bug.cgi?id=7988
And if you haven't already (and your problem occurs with a stock
kernel), you might want to log this as a bug like I did.
Hope this helps.
Mitch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Acked-by: Mitch Williams <[EMAIL PROTECTED]>
>This is a simplified and actually more comprehensive form of a bug
>fix from Mitch Williams <[EMAIL PROTECTED]>.
[snip]
>Then if people do have a kernel message stating "No irq for vector" we
>will know it is ye
ric is seeing bug reports related to "no vector for IRQ" in the
wild, then I have to change my stance and agree that this should be
pushed to -stable. Every one of those messages indicates that we
hit the race condition.
-Mitch
-
To unsubscribe from this list: send the line "un
Greg KH wrote:
>
>> Perhaps we should put this into 2.6.22 then backport it to
>2.6.21.x once it
>> seems safe to do so. If we decide to go this way, we'll
>need to ask Mitch
>> to remind us to do the backport at the appropriate time,
>else we'll sure
,
no additional flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.2
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with
a proper subject line.
-Mitch
-
To unsubscribe
,
no additional flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks t
ld yet.
So the answer to your question is, "probably not".
-Mitch
-
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/
Eric W. Biederman wrote:
>Do we still need the flush the set affinity routines?
>Shouldn't flush in mask and unmask should now be enough?
Yeah, I think you're right. I've removed that call, and
we're running some basic validation on the change. I'll
post a new
with input from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc5/arch/i386/kernel/io_apic.c
--- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28
10:05:22.0 -0700
gt;MSI is disabled before we unregister it, we don't know of any
>MSI implementation problems that will result in a screaming IRQ.
>I would say set enable/disable to the mask/unmask methods.
>
OK, that's easy. I'll whip up a patch today, test it overnight,
and post it tomo
Eric W. Biederman wrote:
>> However the mask function is called at EVERY interrupt,
>> so this change would be VERY expensive.
>
>If true I think that would be bad. However I don't see it.
>Where in handle_edge_irq do we mask the interrupt?
>The only place I see us calling ->mask is from move_nat
is change would be VERY expensive.
If the driver really needs to disable the interrupt, then it can call
irq_disable(). Otherwise, mask (as-is) should be fine -- it masks
the interrupt at the APIC, and the device's interrupt moderation
should take care of keeping it from generating interrup
Grant Grundler wrote:
>Why wouldn't MSI have the same problems as MSI-X?
>
Because enabling and disabling the MSI interrupt is done through
config space, and config space writes are not posted. So we won't
see the problem that we do with MSI-X.
-Mitch
-
To unsubscribe from thi
2.6.21-rc5.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc4/arch/i386/kernel/io_apic.c
--- linux-2.6.21-rc4-clean/arch/i386/kernel/io_apic.c 2007-03-19
16:16:30.0 -0700
+++ linux-2.6.21-rc4/
Auke's suggestion and repost this Monday and cc linux-pci and
a slew of other people.
-Mitch
-
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 a read-flush is not necessary for
mask/unmask operations.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.20.3-clean/arch/i386/kernel/io_apic.c
linux-2.6.20.3/arch/i386/
so a read-flush is not necessary for
mask/unmask operations.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc4/arch/i386/
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy always is more efficient.
The patch that I posted creates a
David Miller wrote:
We don't generally export binary representation
files out of /proc or /sys, in fact this rule I believe is layed
our precisely somewhere at least in the sysfs case.
pci-sysfs exports PCI config space in binary.
-
To unsubscribe from this list: send the line "unsubscr
I made all the changes Pekka suggested, except:
+ security = strncmp(propname, "security-", 9) == 0;
+ len = 0;
Redundant assignment, no?
+ if (!security)
+ (void)callofw("getproplen", 2, 1, node,
propname, &len);
That assig
David Miller wrote:
...
Can we please not have N different interfaces to the open-firmware
calls so that perhaps powerpc and Sparc have a chance of using this
code too?
The base interface function is callofw(), which is effectively identical
to call_prom_ret() in arch/powerpc/kernel/prom_in
://dev.laptop.org/olpc-2.6 . (commit
5b9429be6056864b938ff6f39e5df3cecbbfcf4b).
Please cc me (Mitch Bradley <[EMAIL PROTECTED]>) on comments.
OLPC users will need to upgrade their firmware to
http://wiki.laptop.org/go/OLPC_Firmware_Q2B14 to use this.
diff --git a/.config b/.config
index 6087ae7..f
Hi,
I'm getting a 100% reproduceable panic (stack attached) when testing out
vmware bridged net module on 2.6.12, 2.6.12.[12]. Reverting back to
2.6.11.12 (or 2.6.11) works fine.
M
Jul 4 21:59:32 localhost kernel: vmmon: module license 'unspecified' taints
kernel.
Jul 4 21:59:32 localhost
This patch generated from 2.6.11-rc1.
Now with tabs.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-clean/fs/sysfs/file.c 2004-12-24 13:33:50.0 -0800
+++ linux-2.6.11/fs/s
dd any new functionality and probably shrinks
the running kernel by a good three bytes.
And I'll quit trying to be sneaky.
Thanks again for your help and patience on this stuff.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
>On Tue, Feb 01, 2005 at 12:38:00AM -0800, Greg KH wrote:
>Ick, no. Pulled back out, as it doesn't even compile :(
>
Agreed. Ick. Not necessary at all, so please drop this one on the
floor.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
This patch returns an error code if the caller attempts to open a sysfs
file for appending.
Generated from 2.6.11-rc2.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-clean/fs
key maybe?), I can live without write buffering
right now.
But at the very least, we still need to handle this failure case. I've
tested the following patch and it does resolve the issue. However, it now
limits the size of sysfs writes to the size of the c library's buffer.
----
lost.
Resubmittal will commence in a few minutes.
-Mitch
-
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/
This patch causes an error return if the user attempts to seek on a sysfs
file.
The patch was generated from 2.6.11-rc1.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-clean/fs
This patch causes an error to be returned if the caller attempts to open a
sysfs file in append mode.
This patch applies cleanly to 2.6.11-rc1.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
---
On Sat, 22 Jan 2005, Greg KH wrote:
>
> On Fri, Jan 21, 2005 at 02:52:29PM -0800, Mitch Williams wrote:
> > This patch buffers writes to sysfs files and flushes them to the
> kobject
> > owner when the file is closed.
>
> Why? This breaks the way things work tod
On Sat, 22 Jan 2005, Greg KH wrote:
>
> On Fri, Jan 21, 2005 at 02:49:39PM -0800, Mitch Williams wrote:
> > This patch causes sysfs to return errors if the caller attempts to
> append
> > to or seek on a sysfs file.
>
> And what happens to it today if you do eithe
My apologies -- I appear to have sent the patches out in reverse order.
Please apply patch 3 before the other two.
This is the first time I've used our automated tools to make small patches
out of big ones, but I think I have it figured out now.
Thanks for your patience.
-Mitch Williams
This patch reverses the semantics of the read fill flag, getting rid of an
extra assignment at allocation time.
Generated from 2.6.11-rc1.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-
This patch buffers writes to sysfs files and flushes them to the kobject
owner when the file is closed.
Generated from 2.6.11-rc1.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-cl
This patch causes sysfs to return errors if the caller attempts to append
to or seek on a sysfs file.
Generated from 2.6.11-rc1.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-cl
a big patch, but if you'd like it whacked up into smaller ones,
I'll
be glad to do so.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-clean/fs/sysfs/file.c 2004-12-24 13:
> Adding memory probably isn't going to be too hard... but taking
> existing memory off line is tricky. You have to find some way of
> finding all the pages that are in use and then dealing with them
> appropriately, and when some are locked or contain kernel data this
> would be extremely difficu
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx: at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx: warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx: NCR53c810 at memory 0xfa101000, io 0x200
> 2.2.19pre3
[snip]
> o Optimise kernel compiler detect, kgcc before(Peter Samuelson)
> gcc272 also
I get an endless stream of this:
kgcc:gcc272:cc:gcc: not found
kgcc:gcc272:cc:gcc: not found
/bin/sh: -D__KERNEL__: command not found
/bin/sh: -D__KERNEL__: command not found
/bin/sh
> > Which is a bunch of bullsh*t. i have an Adaptec 39160 and it works
> > beautifully. With regards to the docs, i found this under the
> > "Supported cards/chipsets" section around line 42 of
> > drivers/scsi/README.aic7xxx (in both 2.4.0 and 2.2.17):
> >
> > AHA-29160M
>
> k
Compile bombs out in bridging:
br.c: In function `brg_probe':
br.c:2458: `loops_per_sec' undeclared (first use in this function)
br.c:2458: (Each undeclared identifier is reported only once
br.c:2458: for each function it appears in.)
br.c:2442: warning: `bogomips' might be used uninitialized in
83 matches
Mail list logo
