On 3/29/07, Ed Sweetman <[EMAIL PROTECTED]> wrote:
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35
PST 2006
PCI: Setting latency timer of device :01:00.0 to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35
PST 2006
**WARNING**
On 3/29/07, Ed Sweetman [EMAIL PROTECTED] wrote:
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35
PST 2006
PCI: Setting latency timer of device :01:00.0 to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35
PST 2006
**WARNING** I2C
On Wed, 28 Mar 2007 03:26:35 +0200,
Eric Rannaud <[EMAIL PROTECTED]> wrote:
> The reason for that original patch was that it is actually possible for the
> uevent functions to return -ENOMEM, the uevent buffer being statically
> allocated to BUFFER_SIZE (2048).
So maybe -ENOMEM should still be
On Wed, 28 Mar 2007 03:26:35 +0200,
Eric Rannaud [EMAIL PROTECTED] wrote:
The reason for that original patch was that it is actually possible for the
uevent functions to return -ENOMEM, the uevent buffer being statically
allocated to BUFFER_SIZE (2048).
So maybe -ENOMEM should still be
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 11:25:57 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > Checking the uevent return value, will not prevent any malfunction,
> > usually this kind of "error handling" just prevents bringing up a
> > whole
On Tue, 27 Mar 2007 11:25:57 +0200,
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> I don't see any point in deregistering a kernel device, if the event
> to userspace goes wrong, or a subsytem returns a non-zero value in the
> filter.
But if we filter the event, we just return 0?
> Checking the
On Wed, Mar 21, 2007 at 10:54:36AM +0100, [EMAIL PROTECTED] wrote:
> This last patch is an adaptation of the sys_futex64 syscall provided in -rt
> patch (originally written by Ingo Molnar). It allows the use of 64-bit futex.
>
> I have re-worked most of the code to avoid the duplication of the
On 3/26/07, Eric Rannaud <[EMAIL PROTECTED]> wrote:
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
> On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > > If so, do you think I should labour on with
> > >
On 3/26/07, Eric Rannaud [EMAIL PROTECTED] wrote:
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote:
If so, do you think I should labour on with
uevent-improve-error-checking-and-handling.patch plus your
On Wed, Mar 21, 2007 at 10:54:36AM +0100, [EMAIL PROTECTED] wrote:
This last patch is an adaptation of the sys_futex64 syscall provided in -rt
patch (originally written by Ingo Molnar). It allows the use of 64-bit futex.
I have re-worked most of the code to avoid the duplication of the code.
On Tue, 27 Mar 2007 11:25:57 +0200,
Kay Sievers [EMAIL PROTECTED] wrote:
I don't see any point in deregistering a kernel device, if the event
to userspace goes wrong, or a subsytem returns a non-zero value in the
filter.
But if we filter the event, we just return 0?
Checking the uevent
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote:
On Tue, 27 Mar 2007 11:25:57 +0200,
Kay Sievers [EMAIL PROTECTED] wrote:
Checking the uevent return value, will not prevent any malfunction,
usually this kind of error handling just prevents bringing up a
whole subsystem, or
Badari Pulavarty writes:
> Patch causing the problem in -mm:
> ibmebus-uevent-support.patch
>
> I don't see where $,1rx(Bof_device_uevent$,1ry(B is defined :(
That patch depends on another one from Sylvain Munaut that I haven't
yet managed to get Ben H. to express an opinion on, and
On Mon, Mar 26, 2007 at 09:35:48PM +0200, Jean Delvare wrote:
>
> Greg, please update your copy with this version of the patch. The only
> change is that sound/ppc/beep.c is removed from the patch.
Done.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
ysfs file: block/hda/range
> > CPU 3
> > Modules linked in:
> > Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1
> > RIP: 0010:[] [] __sched_text_start
>
> This is a very popular oops, caused by the rsdl scheduler. I don't _think_
> we yet know exactly why it is happeni
On Mon, 26 Mar 2007 13:57:57 -0800
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
> >
> > Will appear later at
> &g
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
>
Panics my x
On Fri, 23 Mar 2007 00:27:09 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm
On Mon, 26 Mar 2007 20:01:52 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> J.A. Magallón wrote:
> > Libata seems to misdetect my cable.
> > I have double-checked and the cable is 80 pin...
>
> Does the following patch fix your problem?
>
> http://article.gmane.org/gmane.linux.ide/17444
>
>
Hi Badari,
On Mon, 26 Mar 2007 12:05:56 -0800, Badari Pulavarty wrote:
> On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
> >
> > Will appear later at
> >
> >
>
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
# make -j8 modules
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
>
CC ar
On Wed, 21 Mar 2007 10:54:36 +0100 [EMAIL PROTECTED] wrote:
> It does not provide the functionality for all architectures (only for x64 for
> now).
Well that scuppers our chances of getting -mm kernels tested on ia64, s390
and sparc64. Which is a problem - people do test s390 and ia64 and so
J.A. Magallón wrote:
> Libata seems to misdetect my cable.
> I have double-checked and the cable is 80 pin...
Does the following patch fix your problem?
http://article.gmane.org/gmane.linux.ide/17444
(You can get the raw message by appending /raw to the URL).
--
tejun
-
To unsubscribe from
On Mon, 26 Mar 2007 12:34:33 +0200 Eric Rannaud <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
> > On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > > > If so, do you think I should labour on with
> > > >
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
> On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > > If so, do you think I should labour on with
> > > uevent-improve-error-checking-and-handling.patch plus your fix, or should
> > > I
> > > drop the
On Wed, 21 Mar 2007 10:54:34 +0100 [EMAIL PROTECTED] wrote:
> This patch modifies futex_wait() to use an hrtimer + schedule() in place of
> schedule_timeout().
>
> schedule_timeout() is tick based, therefore the timeout granularity is
> the tick (1 ms, 4 ms or 10 ms depending on HZ). By using
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Mar 2007 21:06:18 -0800,
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Would I be right in guessing that this was all triggered by
> > uevent-improve-error-checking-and-handling.patch?
>
> Looks like it,
On Fri, 23 Mar 2007 21:06:18 -0800,
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Would I be right in guessing that this was all triggered by
> uevent-improve-error-checking-and-handling.patch?
Looks like it, since it passed the uevent failures to the upper layer.
> If so, do you think I should
On Fri, 23 Mar 2007 21:06:18 -0800,
Andrew Morton [EMAIL PROTECTED] wrote:
Would I be right in guessing that this was all triggered by
uevent-improve-error-checking-and-handling.patch?
Looks like it, since it passed the uevent failures to the upper layer.
If so, do you think I should labour
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007 21:06:18 -0800,
Andrew Morton [EMAIL PROTECTED] wrote:
Would I be right in guessing that this was all triggered by
uevent-improve-error-checking-and-handling.patch?
Looks like it, since it
On Wed, 21 Mar 2007 10:54:34 +0100 [EMAIL PROTECTED] wrote:
This patch modifies futex_wait() to use an hrtimer + schedule() in place of
schedule_timeout().
schedule_timeout() is tick based, therefore the timeout granularity is
the tick (1 ms, 4 ms or 10 ms depending on HZ). By using a
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote:
If so, do you think I should labour on with
uevent-improve-error-checking-and-handling.patch plus your fix, or should
I
drop the lot? (I'm
On Mon, 26 Mar 2007 12:34:33 +0200 Eric Rannaud [EMAIL PROTECTED] wrote:
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote:
If so, do you think I should labour on with
On Wed, 21 Mar 2007 10:54:36 +0100 [EMAIL PROTECTED] wrote:
It does not provide the functionality for all architectures (only for x64 for
now).
Well that scuppers our chances of getting -mm kernels tested on ia64, s390
and sparc64. Which is a problem - people do test s390 and ia64 and so
J.A. Magallón wrote:
Libata seems to misdetect my cable.
I have double-checked and the cable is 80 pin...
Does the following patch fix your problem?
http://article.gmane.org/gmane.linux.ide/17444
(You can get the raw message by appending /raw to the URL).
--
tejun
-
To unsubscribe from
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
CC arch/powerpc/kernel/ibmebus.o
arch
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
# make -j8 modules
CHK include/linux
Hi Badari,
On Mon, 26 Mar 2007 12:05:56 -0800, Badari Pulavarty wrote:
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6
On Fri, 23 Mar 2007 00:27:09 +0100, J.A. Magallón [EMAIL PROTECTED] wrote:
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
Panics my x86-64 box. 2.6.21-rc4 works fine
On Mon, 26 Mar 2007 20:01:52 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
J.A. Magallón wrote:
Libata seems to misdetect my cable.
I have double-checked and the cable is 80 pin...
Does the following patch fix your problem?
http://article.gmane.org/gmane.linux.ide/17444
(You can get
On Mon, 26 Mar 2007 13:57:57 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm
Modules linked in:
Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1
RIP: 0010:[804ec090] [804ec090] __sched_text_start
This is a very popular oops, caused by the rsdl scheduler. I don't _think_
we yet know exactly why it is happening. Con, did you get to the bottom
On Mon, Mar 26, 2007 at 09:35:48PM +0200, Jean Delvare wrote:
Greg, please update your copy with this version of the patch. The only
change is that sound/ppc/beep.c is removed from the patch.
Done.
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Badari Pulavarty writes:
Patch causing the problem in -mm:
ibmebus-uevent-support.patch
I don't see where $,1rx(Bof_device_uevent$,1ry(B is defined :(
That patch depends on another one from Sylvain Munaut that I haven't
yet managed to get Ben H. to express an opinion on, and which
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>
Libata seems to misdetect my cable.
I have double-checked and the cable is 80 pin...
ata1 is PATA ICH5 bus 1 with DV
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Libata seems to misdetect my cable.
I have double-checked and the cable is 80 pin...
ata1 is PATA ICH5 bus 1 with DVD-RW + ZIP and 40 pin cable
: Unable to load firmware: -2
> > Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network
> > device
>
> The firmware loading bug is caused by
> driver-core-handles-kobject_uevent-failure-while-device_add.patch
>
> I've uploaded a revert patch to
network
device
The firmware loading bug is caused by
driver-core-handles-kobject_uevent-failure-while-device_add.patch
I've uploaded a revert patch to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/
For the record, with the following patches
On Fri, 23 Mar 2007 11:10:29 +0100 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 22 Mar 2007 13:55:51 -0500,
> Larry Finger <[EMAIL PROTECTED]> wrote:
>
> > Cornelia Huck wrote:
> > > On Thu, 22 Mar 2007 07:23:06 -0500,
> > >
> > > This would indicate that dev_uevent had been called. But
Zan Lynx wrote:
>
> It may have partly been a problem of having half of softmac and half
> devicescape. I'm not entirely sure what udev did.
>
> I tried a patch for the Sonic Silicon that was posted and I turned off
> all the configuration for the softmac driver.
>
> It isn't crashing right
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Con Kolivas wrote:
> >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> >>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
> >>> 2.6
On Wed, 2007-03-21 at 15:12 +0100, Marcel Holtmann wrote:
> Hi Andrew,
>
> > > * Freezes immediately if I allow Bluetooth to configure.
> >
> > cc bluez-devel
>
> is the -mm specific or does this also happens with 2.6.21-rc4?
Bluetooth works now, so it isn't entirely -mm's fault.
I
On Wed, 2007-03-21 at 11:13 -0500, Larry Finger wrote:
> Andrew Morton wrote:
> > On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote:
> >> First impressions:
> >> Several of the same bugs as rc3-mm*:
> >> * Freezes immediately if I touch the wlan0 device after loading
> >>
On Fri, Mar 23, 2007 at 09:54:29PM +0900, Yasunori Goto wrote:
> Hello.
>
> > > WARNING: mm/built-in.o - Section mismatch: reference to
> > > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at
> > > offset 0x15c8f) and '__section_nr'
> > I took a look at this one.
> > You have
>
> Andy Whitcroft wrote:
> > Con Kolivas wrote:
> >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> >>> Ok, I have yet a third x86_64 machine is is blowing up with the
> >>> latest
> >>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but
Cornelia Huck wrote:
> On Thu, 22 Mar 2007 13:55:51 -0500,
> Larry Finger <[EMAIL PROTECTED]> wrote:
>> I applied the debug patch, but I don't see any error codes being returned.
>> This time I also got the
>> General Protection Faults. An excerpt of the log is attached.
>
> Hm, I think I have
Hello.
> > WARNING: mm/built-in.o - Section mismatch: reference to
> > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at
> > offset 0x15c8f) and '__section_nr'
> I took a look at this one.
> You have SPARSEMEM enabled in your config.
> And then I see that in sparse.c we call
Andy Whitcroft wrote:
> Con Kolivas wrote:
>> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
>>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
>>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
>>> 2.6.21-rc4-mm1+hotfixes-RSD
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Thu, 22 Mar 2007 07:23:06 -0500,
> >
> > This would indicate that dev_uevent had been called. But how could
> > kobject_uevent then return an error without moaning about an uevent()
> >
Con Kolivas wrote:
> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix lev
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
so I have just fired off
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger [EMAIL PROTECTED] wrote:
Cornelia Huck wrote:
On Thu, 22 Mar 2007 07:23:06 -0500,
This would indicate that dev_uevent had been called. But how could
kobject_uevent then return an error without moaning about an uevent()
error code? Maybe
Andy Whitcroft wrote:
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
so I
Hello.
WARNING: mm/built-in.o - Section mismatch: reference to
.init.text:__alloc_bootmem_node from .text between 'sparse_init' (at
offset 0x15c8f) and '__section_nr'
I took a look at this one.
You have SPARSEMEM enabled in your config.
And then I see that in sparse.c we call
Cornelia Huck wrote:
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger [EMAIL PROTECTED] wrote:
I applied the debug patch, but I don't see any error codes being returned.
This time I also got the
General Protection Faults. An excerpt of the log is attached.
Hm, I think I have an idea about
Andy Whitcroft wrote:
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the
latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix
On Fri, Mar 23, 2007 at 09:54:29PM +0900, Yasunori Goto wrote:
Hello.
WARNING: mm/built-in.o - Section mismatch: reference to
.init.text:__alloc_bootmem_node from .text between 'sparse_init' (at
offset 0x15c8f) and '__section_nr'
I took a look at this one.
You have SPARSEMEM
On Wed, 2007-03-21 at 11:13 -0500, Larry Finger wrote:
Andrew Morton wrote:
On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx [EMAIL PROTECTED] wrote:
First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading
the new
On Wed, 2007-03-21 at 15:12 +0100, Marcel Holtmann wrote:
Hi Andrew,
* Freezes immediately if I allow Bluetooth to configure.
cc bluez-devel
is the -mm specific or does this also happens with 2.6.21-rc4?
Bluetooth works now, so it isn't entirely -mm's fault.
I applied a
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1
Zan Lynx wrote:
It may have partly been a problem of having half of softmac and half
devicescape. I'm not entirely sure what udev did.
I tried a patch for the Sonic Silicon that was posted and I turned off
all the configuration for the softmac driver.
It isn't crashing right now but
On Fri, 23 Mar 2007 11:10:29 +0100 Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger [EMAIL PROTECTED] wrote:
Cornelia Huck wrote:
On Thu, 22 Mar 2007 07:23:06 -0500,
This would indicate that dev_uevent had been called. But how could
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> Ok, I have yet a third x86_64 machine is is blowing up with the latest
> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
> so I have just fired off a
Please always do reply-to-all.
On Fri, 23 Mar 2007 00:27:09 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > Temporarily at
> >
> > http://userweb.k
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-r
Morton wrote:
> >>>>>> Temporarily at
> >>>>>>
> >>>>>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
> >>>>>>
> >>>>>> Will appear later at
> >>>>>>
> >>
firmware_class ieee80211softmac ieee80211
ieee80211_crypt ext3 mbcache jbd edd sg fan sata_nv libata amd74xx thermal
processor sd_mod scsi_mod ide_disk ide_core
Mar 22 13:02:10 larrylap2 kernel: Pid: 4178, comm: cat Not tainted
2.6.21-rc4-mm1-mm1 #14
Mar 22 13:02:10 larrylap2 kernel: RIP: 0010:[]
[] modul
Andy Whitcroft wrote:
> Con Kolivas wrote:
>> On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
>>> Andy Whitcroft wrote:
>>>> Andy Whitcroft wrote:
>>>>> Andrew Morton wrote:
>>>>>> Temporarily at
>>>>>>
>>
Con Kolivas wrote:
> On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
>> Andy Whitcroft wrote:
>>> Andy Whitcroft wrote:
>>>> Andrew Morton wrote:
>>>>> Temporarily at
>>>>>
>>>>> http://userweb.kernel.org/~ak
On Thu, 22 Mar 2007 07:23:06 -0500,
Larry Finger <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Wed, 21 Mar 2007 23:39:17 -0800,
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
> >>
> >>> With the latest
On Thu, Mar 22, 2007 at 04:25:53PM +, David Woodhouse wrote:
> On Thu, 2007-03-22 at 12:41 +0100, Sam Ravnborg wrote:
> > Yep - realized this when I took a closer look.
> > One thing striked my mind. It is correct that new things gets added
> > to i386 first these days?
>
> Personally I tend
On Thu, 2007-03-22 at 12:41 +0100, Sam Ravnborg wrote:
> Yep - realized this when I took a closer look.
> One thing striked my mind. It is correct that new things gets added
> to i386 first these days?
Personally I tend to do PowerPC first, but most others seem to do i386,
yes. There are still
I cannot reproduce the BUG with your ml.bz2 patch applied.
I am seeing this with both 2.6.21-rc4-mm1 + hotfixes, and with
2.6.21-rc4 + ml.bz2:
Mar 22 09:10:35 FractalPath kernel: ACPI: CPU0 (power states: C1[C1]
C2[C2] C3[C3])
Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside
On Thu, Mar 22, 2007 at 09:17:00AM +, David Woodhouse wrote:
> On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote:
> > I will give it a shot tonight.
>
> Thanks. I'll delete the syscalls-2.6.git tree now that you have it.
>
> > One issue I have with current approach is that the ARCH
On Wed, 21 Mar 2007 23:39:17 -0800,
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > With the latest -mm, I'm now getting this:
> >
> > Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
> > 2200BG
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Andy Whitcroft wrote:
> >> Andrew Morton wrote:
> >>> Temporarily at
> >>>
> >>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
> >>>
> >&g
Andy Whitcroft wrote:
> Andy Whitcroft wrote:
>> Andrew Morton wrote:
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>>>
>>> Will appear later at
>>>
>>>
>>> ftp://
el_agp agpgart evdev ex
> t3 jbd mbcache sg sr_mod cdrom sd_mod pata_acpi ata_piix ohci1394
> ieee1394 8139too mii libata scsi_mod ehci_hcd uhci_h
> cd usbcore thermal processor fan
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010202 (2.6.21-rc4-mm1 #5)
> EIP
On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote:
> I will give it a shot tonight.
Thanks. I'll delete the syscalls-2.6.git tree now that you have it.
> One issue I have with current approach is that the ARCH specific
> things are in a single .h file.
Que? There aren't really any
Cook <[EMAIL PROTECTED]> wrote:
> > >
> > > > I can't
> > > > get 2.6.21-rc4-mm1 to compile (with or without this fix):
> > > >
> > > > GEN .version
> > > > init/.missing_syscalls.h.cmd:2: *** missing separator. Stop
Andy Whitcroft wrote:
> Andrew Morton wrote:
>> Temporarily at
>>
>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
>>
>> Will appear later at
>>
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
On Thu, Mar 22, 2007 at 09:14:45AM +0100, Eric Dumazet wrote:
> Also, do we really need to proxy via proc_reg_file_ops files that are not
> provided by a module ?
>
> I think not.
>
> Could you please add in proc_get_inode() a check against de->proc_fops->owner
> ?
Let's _not_. Bugs that
Hi Alexey,
It seems you are fix-rmmod-read-write-races-in-proc-entries.patch author ?
/proc/kcore is no longer seekable (or mappable)
Also, do we really need to proxy via proc_reg_file_ops files that are not
provided by a module ?
I think not.
Could you please add in proc_get_inode() a check
ta_piix ohci1394 ieee1394
> 8139too mii libata scsi_mod ehci_hcd uhci_hcd usbcore thermal
> processor fan
> CPU: 0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010202 (2.6.21-rc4-mm1 #4)
> EIP is at module_put+0x7/0x1f
> eax: 6b6b6b6b ebx: c34bea98 ecx: c01618d2
mware loading bug is caused by
driver-core-handles-kobject_uevent-failure-while-device_add.patch
I've uploaded a revert patch to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/
-
To unsubscribe from this list: send the line "unsubscribe l
(2.6.21-rc4-mm1 #4)
EIP is at module_put+0x7/0x1f
eax: 6b6b6b6b ebx: c34bea98 ecx: c01618d2 edx: 0001
esi: c358 edi: c34ba2fc ebp: c3597f38 esp: c3597f38
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process firmware_helper (pid: 1895, ti=c3596000 task=c35a40b0 task.ti=c3596000
-kobject_uevent-failure-while-device_add.patch
I've uploaded a revert patch to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
thermal
processor fan
CPU:0
EIP:0060:[c0137c22]Not tainted VLI
EFLAGS: 00010202 (2.6.21-rc4-mm1 #4)
EIP is at module_put+0x7/0x1f
eax: 6b6b6b6b ebx: c34bea98 ecx: c01618d2 edx: 0001
esi: c358 edi: c34ba2fc ebp: c3597f38 esp: c3597f38
ds: 007b es: 007b fs
1 - 100 of 282 matches
Mail list logo