Luigi,
Unless you have a completely different cause I believe the patches I
just posted will fix the issue. If you can test and confirm this that
would be great.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> the message appeared just once, but no crash.
> anyway the load average was really abnormal.
Good. You tested it and it worked!
High load average is interesting, because it has similar causes
as the "No irq handler for vector", but technically they
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> I tested the patch, but I could not really stress the HW.
> anyway no crash, but load average is somehow abnormal, higher than it should
> be.
Thanks. Did you get any nasty messages about "No irq handler for vector?"
If not then you never even hit
Luigi Genoni [EMAIL PROTECTED] writes:
I tested the patch, but I could not really stress the HW.
anyway no crash, but load average is somehow abnormal, higher than it should
be.
Thanks. Did you get any nasty messages about No irq handler for vector?
If not then you never even hit the
Luigi Genoni [EMAIL PROTECTED] writes:
the message appeared just once, but no crash.
anyway the load average was really abnormal.
Good. You tested it and it worked!
High load average is interesting, because it has similar causes
as the No irq handler for vector, but technically they are
Luigi,
Unless you have a completely different cause I believe the patches I
just posted will fix the issue. If you can test and confirm this that
would be great.
Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
> Ok. I've finally figured out what is going on. The code is race free but the
> programmer was an
> idiot.
Hi,
Could this IRQ problem account for this bug as well, please? Or is yours
strictly a 2.6.19.x
issue?
http://bugzilla.kernel.org/show_bug.cgi?id=7847
I have a dual P4 Xeon box (HT
Ok. I've finally figured out what is going on. The code is race free but the
programmer was an
idiot.
Hi,
Could this IRQ problem account for this bug as well, please? Or is yours
strictly a 2.6.19.x
issue?
http://bugzilla.kernel.org/show_bug.cgi?id=7847
I have a dual P4 Xeon box (HT
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> OK,
> willing to test any patch.
Ok. I've finally figured out what is going on. The code is
race free but the programmer was an idiot.
In the local apic there are two relevant registers.
ISR (in service register) describing all of the
interrupts
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> OK,
> willing to test any patch.
Sure. After I get things working on this end I will copy you,
on any fixes so you can confirm they work for you.
I am still root causing this but I have found a small fix that should
keep the system from going down
<[EMAIL PROTECTED]> writes:
> I have in interesting update, at less I suppose I have.
It was, at least as another data point.
> I do not know very well what happens with irq stuff migrating shared irq, but
> I
> suppose this has something to do with this crash.
The fact the irq was shared
[EMAIL PROTECTED] writes:
I have in interesting update, at less I suppose I have.
It was, at least as another data point.
I do not know very well what happens with irq stuff migrating shared irq, but
I
suppose this has something to do with this crash.
The fact the irq was shared should
Luigi Genoni [EMAIL PROTECTED] writes:
OK,
willing to test any patch.
Sure. After I get things working on this end I will copy you,
on any fixes so you can confirm they work for you.
I am still root causing this but I have found a small fix that should
keep the system from going down when
Luigi Genoni [EMAIL PROTECTED] writes:
OK,
willing to test any patch.
Ok. I've finally figured out what is going on. The code is
race free but the programmer was an idiot.
In the local apic there are two relevant registers.
ISR (in service register) describing all of the
interrupts that the
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> reproduced.
> it took more or less one hour to reproduce it. I could reproduce it olny
> running also irqbalance 0.55 and commenting out the sleep 1. The message in
> syslog is the same and then, after a few seconds I think, KABOM! system crash
>
d up.
If you had an oops it may have meant the above message was a secondary
symptom. Groan. If it stayed up long enough to give an OOPS then
there is a chance the above message appearing only once had nothing
to do with the actual crash.
How long had the system been up?
> As I said sistem i
was a secondary
symptom. Groan. If it stayed up long enough to give an OOPS then
there is a chance the above message appearing only once had nothing
to do with the actual crash.
How long had the system been up?
As I said sistem is running linux 2.6.19 compiled with gcc 4.1.1 for
AMD
Opteron
Luigi Genoni [EMAIL PROTECTED] writes:
reproduced.
it took more or less one hour to reproduce it. I could reproduce it olny
running also irqbalance 0.55 and commenting out the sleep 1. The message in
syslog is the same and then, after a few seconds I think, KABOM! system crash
and
d up.
If you had an oops it may have meant the above message was a secondary
symptom. Groan. If it stayed up long enough to give an OOPS then
there is a chance the above message appearing only once had nothing
to do with the actual crash.
How long had the system been up?
> As I said sistem i
message was a secondary
symptom. Groan. If it stayed up long enough to give an OOPS then
there is a chance the above message appearing only once had nothing
to do with the actual crash.
How long had the system been up?
As I said sistem is running linux 2.6.19 compiled with gcc 4.1.1 for AMD
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote:
On Wednesday 17 January 2007 05:34, you wrote:
> On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
> > I just tried the firmwarekit, and here are the results, attached.
> > TYVM, thats a very useful tool.
>
> I do suspect ACPI issues on my
On 1/19/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote:
> I guess I'm losing my mind, because when I read this code,
> there are only two ways out of the while(retry) loop.
> Either return with success, or retry is 0.
> So how the heck is retry
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote:
I guess I'm losing my mind, because when I read this code,
there are only two ways out of the while(retry) loop.
Either return with success, or retry is 0.
So how the heck is retry printed as 142?!
did you notice any delay between the last two
On Wednesday 17 January 2007 16:10, Matheus Izvekov wrote:
> On 1/17/07, Len Brown <[EMAIL PROTECTED]> wrote:
> > The code that enables ACPI mode hasn't really changed since before 2.6.12 --
> > unless udelay() has changed beneath us...
> > So if you are going to test an old version of Linux, you
On Wednesday 17 January 2007 16:10, Matheus Izvekov wrote:
On 1/17/07, Len Brown [EMAIL PROTECTED] wrote:
The code that enables ACPI mode hasn't really changed since before 2.6.12 --
unless udelay() has changed beneath us...
So if you are going to test an old version of Linux, you should
On 1/19/07, Len Brown [EMAIL PROTECTED] wrote:
I guess I'm losing my mind, because when I read this code,
there are only two ways out of the while(retry) loop.
Either return with success, or retry is 0.
So how the heck is retry printed as 142?!
did you notice any delay between the last two
On 1/19/07, Matheus Izvekov [EMAIL PROTECTED] wrote:
On 1/19/07, Len Brown [EMAIL PROTECTED] wrote:
I guess I'm losing my mind, because when I read this code,
there are only two ways out of the while(retry) loop.
Either return with success, or retry is 0.
So how the heck is retry printed as
On 1/19/07, Len Brown [EMAIL PROTECTED] wrote:
On Wednesday 17 January 2007 05:34, you wrote:
On 1/17/07, Matheus Izvekov [EMAIL PROTECTED] wrote:
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
I do suspect ACPI issues on my new DG965WH
On 1/17/07, Len Brown <[EMAIL PROTECTED]> wrote:
The code that enables ACPI mode hasn't really changed since before 2.6.12 --
unless udelay() has changed beneath us...
So if you are going to test an old version of Linux, you should start before
then.
Perhaps you can try this debug patch on top
On 1/17/07, Sunil Naidu <[EMAIL PROTECTED]> wrote:
On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
> I just tried the firmwarekit, and here are the results, attached.
> TYVM, thats a very useful tool.
I do suspect ACPI issues on my new DG965WH MOBO:-
On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
I do suspect ACPI issues on my new DG965WH MOBO:-
http://www.intel.com/products/motherboard/DG965WH/index.htm
Tried with Linux-2.6.19.2.
The code that enables ACPI mode hasn't really changed since before 2.6.12 --
unless udelay() has changed beneath us...
So if you are going to test an old version of Linux, you should start before
then.
Perhaps you can try this debug patch on top of 2.6.19 and send along the dmesg?
(also, please
The code that enables ACPI mode hasn't really changed since before 2.6.12 --
unless udelay() has changed beneath us...
So if you are going to test an old version of Linux, you should start before
then.
Perhaps you can try this debug patch on top of 2.6.19 and send along the dmesg?
(also, please
On 1/17/07, Matheus Izvekov [EMAIL PROTECTED] wrote:
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
I do suspect ACPI issues on my new DG965WH MOBO:-
http://www.intel.com/products/motherboard/DG965WH/index.htm
Tried with Linux-2.6.19.2.
On 1/17/07, Sunil Naidu [EMAIL PROTECTED] wrote:
On 1/17/07, Matheus Izvekov [EMAIL PROTECTED] wrote:
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
I do suspect ACPI issues on my new DG965WH MOBO:-
On 1/17/07, Len Brown [EMAIL PROTECTED] wrote:
The code that enables ACPI mode hasn't really changed since before 2.6.12 --
unless udelay() has changed beneath us...
So if you are going to test an old version of Linux, you should start before
then.
Perhaps you can try this debug patch on top
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
apicedge
(experimental) APIC Edge/Level check
4
This test checks if legacy interrupts are edge and PCI interrupts are level
Non-Legacy interrupt 0 is incorrectly level triggered
4
On 1/17/07, Luming Yu <[EMAIL PROTECTED]> wrote:
On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
> It used to support power button events, dont know what else. Is there
> anything I can do to check how good the acpi support is?
Did you check BIOS setting? Is there any ACPI related
On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
On 1/17/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> > Just tried linux for the first time on this old machine, and i got
> > this problem. dmesg below:
>
>
> did this machine
On 1/17/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> Just tried linux for the first time on this old machine, and i got
> this problem. dmesg below:
did this machine EVER support acpi ?
It used to support power button events,
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> Just tried linux for the first time on this old machine, and i got
> this problem. dmesg below:
did this machine EVER support acpi ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:
Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo
4.1.1-r3)) #10 PREEMPT Sun Dec 10 17:35:24 BRST 2006
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00
Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:
Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo
4.1.1-r3)) #10 PREEMPT Sun Dec 10 17:35:24 BRST 2006
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:
did this machine EVER support acpi ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 1/17/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:
did this machine EVER support acpi ?
It used to support power button events, dont
On 1/17/07, Matheus Izvekov [EMAIL PROTECTED] wrote:
On 1/17/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:
did this machine EVER support
On 1/17/07, Luming Yu [EMAIL PROTECTED] wrote:
On 1/17/07, Matheus Izvekov [EMAIL PROTECTED] wrote:
It used to support power button events, dont know what else. Is there
anything I can do to check how good the acpi support is?
Did you check BIOS setting? Is there any ACPI related menuitems?
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
?xml version=1.0 encoding=UTF-8?
?xml-stylesheet href=results.css type=text/css?
results
test
idapicedge/id
name(experimental) APIC Edge/Level check/name
result4/result
descriptionThis test
Hi,
On Mon, Dec 11, 2006 at 03:47:58PM +0100, Romano Giannetti wrote:
> On Wed, 2006-11-29 at 14:21 -0800, Linus Torvalds wrote:
>
> > You could send me and the kernel mailing list a note about it anyway, of
> > course. (And perhaps pictures, if your dachshund is involved. Not that
> > we'd be
On Wed, 2006-11-29 at 14:21 -0800, Linus Torvalds wrote:
> You could send me and the kernel mailing list a note about it anyway, of
> course. (And perhaps pictures, if your dachshund is involved. Not that
> we'd be interested, of course. No. Just so that we'd know to avoid it next
> time).
On Wed, 2006-11-29 at 14:21 -0800, Linus Torvalds wrote:
You could send me and the kernel mailing list a note about it anyway, of
course. (And perhaps pictures, if your dachshund is involved. Not that
we'd be interested, of course. No. Just so that we'd know to avoid it next
time).
Hi
Hi,
On Mon, Dec 11, 2006 at 03:47:58PM +0100, Romano Giannetti wrote:
On Wed, 2006-11-29 at 14:21 -0800, Linus Torvalds wrote:
You could send me and the kernel mailing list a note about it anyway, of
course. (And perhaps pictures, if your dachshund is involved. Not that
we'd be
Toralf Förster wrote:
> Hello,
>
> the build with the attached .config failed, make ends with:
> ...
> CC lib/rwsem.o
> CC lib/semaphore-sleepers.o
> CC lib/sha1.o
> CC lib/string.o
> CC lib/vsprintf.o
> AR lib/lib.a
> LD arch/i386/lib/built-in.o
>
Hello,
the build with the attached .config failed, make ends with:
...
CC lib/rwsem.o
CC lib/semaphore-sleepers.o
CC lib/sha1.o
CC lib/string.o
CC lib/vsprintf.o
AR lib/lib.a
LD arch/i386/lib/built-in.o
CC arch/i386/lib/bitops.o
AS
Hello,
the build with the attached .config failed, make ends with:
...
CC lib/rwsem.o
CC lib/semaphore-sleepers.o
CC lib/sha1.o
CC lib/string.o
CC lib/vsprintf.o
AR lib/lib.a
LD arch/i386/lib/built-in.o
CC arch/i386/lib/bitops.o
AS
Toralf Förster wrote:
Hello,
the build with the attached .config failed, make ends with:
...
CC lib/rwsem.o
CC lib/semaphore-sleepers.o
CC lib/sha1.o
CC lib/string.o
CC lib/vsprintf.o
AR lib/lib.a
LD arch/i386/lib/built-in.o
CC
On Mon, 2006-12-04 at 08:35 +0100, Andreas Jellinghaus wrote:
> or I can send you the kernel patch as file and the xen hypervisor:
> -rw-r--r-- 1 root root 244694 2006-04-19 12:14 /boot/xen-3.0.2-2.gz
> -rw-r--r-- 1 root root 604942 2006-04-19 12:14
>
On Mon, 2006-12-04 at 08:35 +0100, Andreas Jellinghaus wrote:
or I can send you the kernel patch as file and the xen hypervisor:
-rw-r--r-- 1 root root 244694 2006-04-19 12:14 /boot/xen-3.0.2-2.gz
-rw-r--r-- 1 root root 604942 2006-04-19 12:14
Sergio Monteiro Basto wrote:
Hi,
1st you should put this information on http://bugzilla.kernel.org/
ok, thanks.
your bug kept me the attention because on bad interrupts you have :
21: 10 IO-APIC-fasteoi ohci1394
Exactly oops on 10 interrupts, I had seen this before .
I
Hi,
1st you should put this information on http://bugzilla.kernel.org/
(choose enter a new bug, may choose Category ACPI with component
config-interrupts ) for better organization, instead make your own bug
documentation.
The documentation is very good you should attach the same information
on
On Sat, 2 Dec 2006 23:06:57 -0500 Chuck Ebbert wrote:
>
>> In-Reply-To: <[EMAIL PROTECTED]>
>>
>> On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
>>
>> > make modules gives me these warnings in modpost and then errors out:
>> > WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
>>
>>
On Sat, 2 Dec 2006 23:06:57 -0500 Chuck Ebbert wrote:
In-Reply-To: [EMAIL PROTECTED]
On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
make modules gives me these warnings in modpost and then errors out:
WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
Message is from
Hi,
1st you should put this information on http://bugzilla.kernel.org/
(choose enter a new bug, may choose Category ACPI with component
config-interrupts ) for better organization, instead make your own bug
documentation.
The documentation is very good you should attach the same information
on
Sergio Monteiro Basto wrote:
Hi,
1st you should put this information on http://bugzilla.kernel.org/
ok, thanks.
your bug kept me the attention because on bad interrupts you have :
21: 10 IO-APIC-fasteoi ohci1394
Exactly oops on 10 interrupts, I had seen this before .
I
On Sat, 2 Dec 2006 23:06:57 -0500 Chuck Ebbert wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
>
> On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
>
> > make modules gives me these warnings in modpost and then errors out:
> > WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
>
>
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
> make modules gives me these warnings in modpost and then errors out:
> WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
Message is from scripts/file2alias.c::do_pci_entry():
if
n to MAINTAINERS
>
> Kyle McMartin (1):
> [PATCH] Fix incorrent type of flags in
>
> Lachlan McIlroy (1):
> [XFS] Fix uninitialized br_state and br_startoff in
>
> Laurent Pinchart (1):
> USB: Fixed outdated usb_get_device_descriptor() docume
my msi s270 laptop. but all vanilla kernel I ever tried do
that, also the debian and ubuntu kernel are instable too.
But: xen 3.0.2 plus xen'ified linux 2.6.16.31 are rock solid.
any idea what the issue could be? I'm running 64bit kernel,
64bit userland (plus some 32bit apps), and the cpu is a
On Thursday 30 November 2006 21:30, Malte Schröder wrote:
> I also encountered this bug (wasn't there in -rc6). The patch also fixes it
> for me.
Ok, I have to make a correction here: It doesn't crash anymore but now ipv6
doesn't work at all. To be more precise, I see adresses on the network
> Il giorno gio, 30/11/2006 alle 14.46 -0700, Eric W. Biederman ha
> scritto:
> [EMAIL PROTECTED] writes:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=7505
>
> > one. I think this was a better bisection and I got this
>
> > Bisecting: 1 revisions left to test after this
> >
Il giorno gio, 30/11/2006 alle 14.46 -0700, Eric W. Biederman ha
scritto:
[EMAIL PROTECTED] writes:
http://bugzilla.kernel.org/show_bug.cgi?id=7505
one. I think this was a better bisection and I got this
Bisecting: 1 revisions left to test after this
On Thursday 30 November 2006 21:30, Malte Schröder wrote:
I also encountered this bug (wasn't there in -rc6). The patch also fixes it
for me.
Ok, I have to make a correction here: It doesn't crash anymore but now ipv6
doesn't work at all. To be more precise, I see adresses on the network
my msi s270 laptop. but all vanilla kernel I ever tried do
that, also the debian and ubuntu kernel are instable too.
But: xen 3.0.2 plus xen'ified linux 2.6.16.31 are rock solid.
any idea what the issue could be? I'm running 64bit kernel,
64bit userland (plus some 32bit apps), and the cpu is a
by default
Revert [PATCH] Enforce unsigned long flags; when spinlocking
Fix 'ALIGN()' macro, take 2
Linux 2.6.19
Luca Risolia (1):
V4L/DVB (4865): Fix: Slot 0 not NULL on disconnecting SN9C10x PC Camera
Luck, Tony (1):
[IA64] a fix towards allmodconfig build
In-Reply-To: [EMAIL PROTECTED]
On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
make modules gives me these warnings in modpost and then errors out:
WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
Message is from scripts/file2alias.c::do_pci_entry():
if
On Sat, 2 Dec 2006 23:06:57 -0500 Chuck Ebbert wrote:
In-Reply-To: [EMAIL PROTECTED]
On Sat, 02 Dec 2006 20:54:38 +0100, Matthijs wrote:
make modules gives me these warnings in modpost and then errors out:
WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
Message is from
On Friday 01 December 2006 22:32, Herbert Poetzl wrote:
> On Fri, Dec 01, 2006 at 01:33:03PM +0300, Kirill Korotaev wrote:
> > OpenVZ has been using them for more than a month already ;-)
>
> great for you, here some details:
>
> - 2.6.19 was released 29th Nov 2006
> - OpenVZ page shows
On Fri, Dec 01, 2006 at 01:33:03PM +0300, Kirill Korotaev wrote:
> OpenVZ has been using them for more than a month already ;-)
great for you, here some details:
- 2.6.19 was released 29th Nov 2006
- OpenVZ page shows 2.6.9-023, 2.6.16 and the
2.6.18 development
- Linux-VServer has
Hi All,
An update of the uClinux (MMU-less) code against 2.6.19.
I have quite a few things outstanding here to push up.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.19-uc0.patch.gz
Change log:
. m68knommu Kconfig cleanupsGreg Ungerer
. m68knommu printk
Great !
I'm dreaming that the next patchsets will not require as much
debate. nah, stop dreaming Cedric :)
Thanks to Andrew and Linus who made it happen.
C.
Kirill Korotaev wrote:
> OpenVZ has been using them for more than a month already ;-)
>
> Kirill
>
>> Ladies and Gentlemen!
>>
>>
OpenVZ has been using them for more than a month already ;-)
Kirill
> Ladies and Gentlemen!
>
> here is the first Linux-VServer version (testing)
> with support for the *spaces (uts, ipc and vfs)
> introduced in 2.6.19 ...
>
>
OpenVZ has been using them for more than a month already ;-)
Kirill
Ladies and Gentlemen!
here is the first Linux-VServer version (testing)
with support for the *spaces (uts, ipc and vfs)
introduced in 2.6.19 ...
http://vserver.13thfloor.at/Experimental/patch-2.6.19-vs2.1.x-t1.diff
Great !
I'm dreaming that the next patchsets will not require as much
debate. nah, stop dreaming Cedric :)
Thanks to Andrew and Linus who made it happen.
C.
Kirill Korotaev wrote:
OpenVZ has been using them for more than a month already ;-)
Kirill
Ladies and Gentlemen!
here is the
Hi All,
An update of the uClinux (MMU-less) code against 2.6.19.
I have quite a few things outstanding here to push up.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.19-uc0.patch.gz
Change log:
. m68knommu Kconfig cleanupsGreg Ungerer
. m68knommu printk
On Fri, Dec 01, 2006 at 01:33:03PM +0300, Kirill Korotaev wrote:
OpenVZ has been using them for more than a month already ;-)
great for you, here some details:
- 2.6.19 was released 29th Nov 2006
- OpenVZ page shows 2.6.9-023, 2.6.16 and the
2.6.18 development
- Linux-VServer has
On Friday 01 December 2006 22:32, Herbert Poetzl wrote:
On Fri, Dec 01, 2006 at 01:33:03PM +0300, Kirill Korotaev wrote:
OpenVZ has been using them for more than a month already ;-)
great for you, here some details:
- 2.6.19 was released 29th Nov 2006
- OpenVZ page shows 2.6.9-023,
On Thu, 30 Nov 2006 14:46:48 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Let's try and discussing this someplace where people are watching. Bugzilla
> seems to be a horrible medium for tracking down bugs.
You can certainly do that, but please cc [EMAIL PROTECTED]
as well, so bugzilla
Ladies and Gentlemen!
here is the first Linux-VServer version (testing)
with support for the *spaces (uts, ipc and vfs)
introduced in 2.6.19 ...
http://vserver.13thfloor.at/Experimental/patch-2.6.19-vs2.1.x-t1.diff
it might not be as perfect as the kernel itself *G*
but it does work fine here,
On Thu, Nov 30, 2006 at 11:32:59PM +0100, Udo A. Steinberg wrote:
>
> I didn't and that turned out to be the culprit. With CONFIG_CRYPTO_CBC enabled
> everything works fine. Thanks, Herbert!
>
> Shouldn't cryptoloop automatically select CONFIG_CRYPTO_CBC if it depends on
> it?
Yes I'll make it
On Fri, 01 Dec 2006 08:15:12 +1100 Herbert Xu (HX) wrote:
HX> Udo A. Steinberg <[EMAIL PROTECTED]> wrote:
HX> >
HX> > Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to
HX> > cooperate. An strace of "losetup -e aes /dev/loop0 /dev/hda7" without all
HX> > the terminal
[EMAIL PROTECTED] writes:
> http://bugzilla.kernel.org/show_bug.cgi?id=7505
> one. I think this was a better bisection and I got this
> Bisecting: 1 revisions left to test after this
> [d71374dafbba7ec3f67371d3b7e9f6310a588808] PCI: fix race with pci_walk_bus and
> pci_destroy_dev
>
Udo A. Steinberg <[EMAIL PROTECTED]> wrote:
>
> Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to
> cooperate. An strace of "losetup -e aes /dev/loop0 /dev/hda7" without all the
> terminal interaction shows:
Did you enable CONFIG_CRYPTO_CBC?
Cheers,
--
Visit Openswan
Needed the VIA PATA patch to be able to boot:
http://lkml.org/lkml/2006/6/18/165
Also, atakbd.c produced lots of "Spurious ACK" messages on kernel panic
when I misspecified the root fs, which made the real problem a little
more difficult to find.
--
Jindrich Makovicka
-
To unsubscribe from
Needed the VIA PATA patch to be able to boot:
http://lkml.org/lkml/2006/6/18/165
Also, atakbd.c produced lots of Spurious ACK messages on kernel panic
when I misspecified the root fs, which made the real problem a little
more difficult to find.
--
Jindrich Makovicka
-
To unsubscribe from this
Udo A. Steinberg [EMAIL PROTECTED] wrote:
Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to
cooperate. An strace of losetup -e aes /dev/loop0 /dev/hda7 without all the
terminal interaction shows:
Did you enable CONFIG_CRYPTO_CBC?
Cheers,
--
Visit Openswan at
[EMAIL PROTECTED] writes:
http://bugzilla.kernel.org/show_bug.cgi?id=7505
one. I think this was a better bisection and I got this
Bisecting: 1 revisions left to test after this
[d71374dafbba7ec3f67371d3b7e9f6310a588808] PCI: fix race with pci_walk_bus and
pci_destroy_dev
On Fri, 01 Dec 2006 08:15:12 +1100 Herbert Xu (HX) wrote:
HX Udo A. Steinberg [EMAIL PROTECTED] wrote:
HX
HX Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to
HX cooperate. An strace of losetup -e aes /dev/loop0 /dev/hda7 without all
HX the terminal interaction
On Thu, Nov 30, 2006 at 11:32:59PM +0100, Udo A. Steinberg wrote:
I didn't and that turned out to be the culprit. With CONFIG_CRYPTO_CBC enabled
everything works fine. Thanks, Herbert!
Shouldn't cryptoloop automatically select CONFIG_CRYPTO_CBC if it depends on
it?
Yes I'll make it
Ladies and Gentlemen!
here is the first Linux-VServer version (testing)
with support for the *spaces (uts, ipc and vfs)
introduced in 2.6.19 ...
http://vserver.13thfloor.at/Experimental/patch-2.6.19-vs2.1.x-t1.diff
it might not be as perfect as the kernel itself *G*
but it does work fine here,
On Thu, 30 Nov 2006 14:46:48 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Let's try and discussing this someplace where people are watching. Bugzilla
seems to be a horrible medium for tracking down bugs.
You can certainly do that, but please cc [EMAIL PROTECTED]
as well, so bugzilla
1 - 100 of 135 matches
Mail list logo
