* Hugh Dickins <[EMAIL PROTECTED]> [2006-12-16 18:20]:
> Very disturbing. I'm not aware of any problem with them, and we
> surely wouldn't have released 2.6.19 with any known-corrupting patches
> in. There's some doubts about 2.6.19 itself in the links below: were
> it not for those, I'd suspect
On Sat, 16 Dec 2006, Martin Michlmayr wrote:
> * Hugh Dickins <[EMAIL PROTECTED]> [2006-12-16 18:20]:
> > Very disturbing. I'm not aware of any problem with them, and we
> > surely wouldn't have released 2.6.19 with any known-corrupting patches
> > in. There's some doubts about 2.6.19 itself in
On Sat, 2006-12-16 at 16:50 +0100, Martin Michlmayr wrote:
> Debian recently applied a number of mm changes that went into 2.6.19
> to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
> before). Since then, some filesystem corruption has been observed
> which can be traced back to
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-16 21:55]:
> What is not clear from all these reports is what architectures this is
> seen on. I suspect some of them are i686, which together with the
> explicit mention of ARM make it a cross platform issue.
Problems have been seen at least on x86,
Convert the bay driver to be a platform driver, so that we can have sysfs
entries.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
drivers/acpi/bay.c | 87 +
1 file changed, 75 insertions(+), 12 deletions(-)
---
Hi Len,
Here's a set of patches for changing the removable drive bay driver
(drivers/acpi/bay) from using the old proc interface to using a sysfs
interface instead. I made the bay driver a platform driver, and
so it's entries will now be located in /sys/devices/platform/bay.X.
There are still 2
Remove the procfs related code from the bay driver.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
drivers/acpi/bay.c | 152 -
1 file changed, 2 insertions(+), 150 deletions(-)
--- kristen-2.6.orig/drivers/acpi/bay.c
+++
On Fri, Dec 15, 2006 at 09:14:35PM +, Russell King wrote:
> > > > Is there a way we can have this done by default on the n2100? I guess
> > > > that since it's a PCI device, there isn't much hope for that..?
> > >
> > > Do you mean an automagically tuned default value based on CONFIG_ARM ?
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On top of
> signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch
>
> - Factor out sending PIDTYPE_PGID wide signals.
>
> - Use is_init(p) instead of "p->pid > 1". We don't hash idle threads anymore,
> no need to worry about p->pid
On Sat, 16 Dec 2006, Peter Zijlstra wrote:
> Moving the cleaning of the page out from under the private_lock opened
> up a window where newly attached buffer might still see the page dirty
> status and were thus marked (incorrectly) dirty themselves; resulting in
> filesystem data corruption.
I'm
Lennert Buytenhek <[EMAIL PROTECTED]> :
[...]
> Sounds good. How about something like the patch below plus the
> corresponding r8169 diff?
Go wild.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>
> With commit b0268726 backed out, 2.6.20-rc1 boots fine.
Ok. It's sad, because that thing really did clean stuff up, and seemed
like a nice and robust approach.
Your dmesg is kind of interesting:
..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0
Hi Ingo,
On 16/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
fixes below when applying it ontop of 2.6.19-rt15.
Do you need these fixes to avoid a compiler error? If yes, this is
caused by a bug in gcc-4.x. The kmemleak
On Sun, Dec 17, 2006 at 12:31:34AM +0100, Francois Romieu wrote:
> > Sounds good. How about something like the patch below plus the
> > corresponding r8169 diff?
>
> Go wild.
Martin/Riku, I'm pretty busy with other stuff at the moment, can you
give this (on top of 2.6.20-rc1) a spin?
On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>
> No such luck, it still panics and the APIC error is also unchanged.
Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
tree in the hopes that Andi and/or Eric can see what's wrong and solve it.
If we don't find a solution,
Hello,
I had filesystem data corruption with rtorrent with 2.6.19.
I tried recent git with Peter Zijlstra patch
http://lkml.org/lkml/2006/12/16/144 and it seems that the problem is
fixed.
Please CC as I am not subscribed to lkml.
Andrei
-
To unsubscribe from this list: send the line
On Saturday 16 December 2006 22:01, Linus Torvalds wrote:
> On Sat, 16 Dec 2006, Ricardo Galli wrote:
> > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never
> > tried to change or restrict "fair use". GPL[23] covers only to
> > "distibution" of the covered program. The freedom
On 12/16, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On top of
> > signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch
> >
> > - Factor out sending PIDTYPE_PGID wide signals.
> >
> > - Use is_init(p) instead of "p->pid > 1". We don't hash idle
Schedule drivers/input/tsdev.c for removal, nobody should be using
this anymore. See the patch for details.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Documentation/feature-removal-schedule.txt | 14 ++
1 file changed, 14 insertions(+)
Index:
Hi,
kernel-rt-14 rocks but wiht kernel-rt-15 I got kernel: NETDEV WATCHDOG:
eth1: transmit timed out, I downgrade to kernel-rt-14 and that got this
problem anymore.
I not use my on-board via-rhine II Ethernet.
This tests has been made with one external Ethernet card, one Realtek
Semiconductor
On 11/30/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
but there are a few other
cases which still contain compound preprocessor directives such as:
#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
having never worked with unifdef before, i guess i was being overly
On Sat Dec 16, 2006 at 01:42:11PM -0500, Mike Frysinger wrote:
> On 11/30/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> >but there are a few other
> >cases which still contain compound preprocessor directives such as:
> >
> > #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
>
Hello.
I am pleased to announce new release of the acrypto for 2.6.19 kernel -
first asynchronous crypto layer for Linux kernel 2.6.
Acrypto allows to handle crypto requests asynchronously in hardware.
Acrypto supports following features:
* multiple asynchronous crypto device queues
* crypto
Hi,
On Dec 13 2006 21:40, Divy Le Ray wrote:
>
> A corresponding monolithic patch is posted at the following URL:
> http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
I was unable to compile this on 2.6.20-rc1, because:
CC [M] drivers/net/cxgb3/cxgb3_offload.o
> I resubmit the patch supporting the latest Chelsio T3 adapter.
> It incorporates the last feedbacks for code cleanup.
> It is built gainst Linus'tree.
>
> We think the driver is now ready to be merged.
> Can you please advise on the next steps for inclusion in 2.6.20 ?
>
> A corresponding
> A corresponding monolithic patch is posted at the following URL:
> http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
Stylistic stuff that was mentioned. (TYPE * a -> TYPE *a)
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc1/drivers/net/cxgb3/common.h
Jan Engelhardt wrote:
On Dec 16 2006 08:45, Pavel Machek wrote:
Two escapes works now. :-)
Actually could we fix our consoles, somehow, to make esc usable?
Having important key like esc unusable on consoles is quite ugly.
It's something between a misdesign and a
On Sat, 16 Dec 2006 10:38:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:
>
> > By this, we'll not access mem_section[] in usual ops.
>
> Why do we need mem_section? We have a page table that fulfills the same
> role.
>
Basically, we
I'm CC'ing the containers list these namespaces are what it is setup
to talk about.
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 12/16, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>>
>> > On top of
>> >
On Sat, Dec 16, 2006 at 01:33:01PM -0500, Dave Jones wrote:
> On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:
>
> > Anything else, you have to make some really scary decisions. Can a judge
> > decide that a binary module is a derived work even though you didn't
> > actually
On Sun, Dec 17, 2006 at 02:56:09AM +0100, Adrian Bunk wrote:
>...
> Otherwise, it seems to be highly unlikely that anyone will want to sue a
> company that is often located in a different country, and the only
> possible legal action will be cease and desist letters against people
> who are
Hello,
On kernel 2.6.20-rc1, ftp (get or put) stops
during file-transfer.
Client: ftp-0.17-33.fc6 (192.168.1.1)
Server: vsftpd-2.0.5-8 (192.168.1.3)
This problem does _not_ happen on kernel-2.6.19.
is it caused by network-subsystem change on 2.6.20-rc1??
Best Regards
Komuro
-
To
On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
>
> Hello,
>
> On kernel 2.6.20-rc1, ftp (get or put) stops
> during file-transfer.
>
> Client: ftp-0.17-33.fc6 (192.168.1.1)
> Server: vsftpd-2.0.5-8 (192.168.1.3)
>
> This problem does _not_ happen on kernel-2.6.19.
> is it caused by
On Sun, Dec 17, 2006 at 01:22:12AM +0100, Ricardo Galli wrote:
> OK, let assume your perspective of the history is the valid and real one,
> then, ¿where are all lawsits against other big GPL only projects? For example
> libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold
On 12/13/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
On 12/12/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
> I think that PTEs set up by vmalloc are marked cacheable and via the
> above nopage end up as cacheable. I'm not doing DMA. So the accesses
> are through the cache so I don't think cache
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>>
>> No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
> tree in the hopes that Andi and/or Eric can see what's
On Sun, 17 Dec 2006 04:02:22 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> >
> > Hello,
> >
> > On kernel 2.6.20-rc1, ftp (get or put) stops
> > during file-transfer.
> >
> > Client: ftp-0.17-33.fc6 (192.168.1.1)
> > Server:
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>>
>> No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
> tree in the hopes that Andi and/or Eric can see what's
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 16 Dec 2006 09:18:28 -0500, Dave Jones wrote:
> > That's strange. Remove_files called sysfs_hash_and_remove()
> > with dir==0xfff3 (-13 decimal.)
>
> Hmm, That's -EACCESS. Something not checking a return code at a lower
> level maybe ?
In
301 - 339 of 339 matches
Mail list logo