Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >Vincent ETIENNE wrote:
> >> Hi,
> >>
> >> Summary :
> >>Got this trace when one network interface come down or up in a 2
> >>interfaces bonding. So far, system seems to surviv
Le Sunday 29 April 2007 13:18:31 Jiri Kosina, vous avez écrit :
>
> Hi Vincent,
Hi Jiri,
>
> yes, the device is messed up, but it shouldn't have any consequences for
> you - the HID driver is able to correctly handle that, so as soon as we
> don't need to add any extra quirks for such dev
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > No, it isn't a problem in the USB core. The device itself is messed up;
> > it really does report idVendor and idProduct both equal to 0.
> So is it just a scary trace but without consequence that i could ignored
> ? May i ask you what is the devic
Le Saturday 28 April 2007 00:32:37 Andrew Morton, vous avez écrit :
> On Fri, 27 Apr 2007 22:05:28 +0200
>
> because we thought we'd fixed the rtnl_lock() problems in 2.6.21-rc7-mm2.
> Are you sure that log is from 2.6.21-rc7-mm2?
Yes. I have retested it another time ( for adding the small usb d
Le Saturday 28 April 2007 21:50:30 Alan Stern, vous avez écrit :
> No, it isn't a problem in the USB core. The device itself is messed up;
> it really does report idVendor and idProduct both equal to 0.
>
> Jiri, don't worry about all those other devices in the listing that also
> have idVendor an
On Sat, 28 Apr 2007, Jiri Kosina wrote:
> On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
>
> > > I now don't immediately see how this could happen - the vendor ID
> > > seems to be propagated properly from hid_probe() (nothing has been
> > > changed in this codepath), so this would mean that hid_p
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > I now don't immediately see how this could happen - the vendor ID
> > seems to be propagated properly from hid_probe() (nothing has been
> > changed in this codepath), so this would mean that hid_probe() has
> > been passed usb_interface for which
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
With your patch it seems like idVendor passed is 0. You could see it there ;
http://mail1.vetienne.net/linux/dmesg.2.6.21-rc7-mm2+patch-usbhid
I could confirm that the keyboard is working ( yesterday i was just behind the
box due to test on the netwo
Le Saturday 28 April 2007 00:42:45 Jiri Kosina, vous avez écrit :
> On Fri, 27 Apr 2007, Greg KH wrote:
> > > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
>
> [ .. stacktraces stripped .. ]
>
> > Jiri, any thoughts about this? This looks like it comes from your tree
> > as 2
Hi Jiri,
On Sat, 28 Apr 2007, Jiri Kosina wrote:
Paul, do you have any idea? In fact, what was your reason for putting this
WARN_ON() there?
The static quirk list uses idVendor == 0 to mark the end of
hid_blacklist[], so we don't expect any device to have idVendor == 0. If
a device is corr
On Sat, 28 Apr 2007, Jiri Kosina wrote:
> This BUG (it's in fact a warning) is this one:
>WARN_ON(idVendor == 0);
> I now don't immediately see how this could happen - the vendor ID seems
> to be propagated properly from hid_probe() (nothing has been changed in
> this codepath), so this
On Fri, 27 Apr 2007, Greg KH wrote:
> > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
[ .. stacktraces stripped .. ]
> Jiri, any thoughts about this? This looks like it comes from your tree
> as 2.6.21 doesn't have the drivers/hid/usbhid/ directory...
Paul (author of the co
On Fri, Apr 27, 2007 at 11:25:46AM +0200, VE (HOME) wrote:
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > This was due to locking bustage in the net tree. It should be fixed
> > in 2.6.21-rc7-mm2.
>
> I have tried this ve
On Fri, 27 Apr 2007 11:25:46 +0200 "VE \(HOME\)" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > This was due to locking bustage in the net tree. It should be fixed
> > in 2.6.21-rc7-mm2.
>
> I ha
Andrew Morton wrote:
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
wrote:
This was due to locking bustage in the net tree. It should be fixed
in 2.6.21-rc7-mm2.
I have tried this version. Same problem ( see
http://mail1.vetienne.net/linux/dmesg-2.6.21-rc7-mm2.log )
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]> wrote:
> Apr 26 11:09:34 jupiter2 RTNL: assertion failed at
> net/ipv4/devinet.c
> (1055) Apr 26 11:09:34 jupiter2
> Apr 26 11:09:34 jupiter2 Call Trace:
> Apr 26 11:09:3
Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >Vincent ETIENNE wrote:
> >> Hi,
> >>
> >> Summary :
> >>Got this trace when one network interface come down or up in a 2
> >>interfaces bonding. So far, system seems to surviv
Chris Snook <[EMAIL PROTECTED]> wrote:
>Vincent ETIENNE wrote:
>> Hi,
>>
>> Summary :
>> Got this trace when one network interface come down or up in a 2
>> interfaces bonding. So far, system seems to survive to this problem
>> and works fine.
>
>I'm investigating a similar/p
Vincent ETIENNE wrote:
Hi,
Summary :
Got this trace when one network interface come down or up in a 2
interfaces bonding. So far, system seems to survive to this problem
and works fine.
I'm investigating a similar/possibly identical bug. Do you experience
packe
Hi,
Summary :
Got this trace when one network interface come down or up in a 2
interfaces bonding. So far, system seems to survive to this problem
and works fine.
Full description
During testing of bonding of 2 interfaces, i have seen this from
tim
Rafael J. Wysocki wrote:
> On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > > > On Sunday 15 Ap
On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki w
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrot
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 11:05:53 +1000
> I wrote:
>
> > So this doesn't change process_input_packet(), which treats the case
> > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> > 0x03 (PPP_UI) as indicating a packet with a PPP protoc
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>>
>> So this doesn't change process_input_packet(), which treats the case
>> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
>> 0x03 (PPP_UI) as indicating a packet with a PPP protocol numbe
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
I tested Paul's patch for last few days and I think everything seems
ok. The system is stable.
Regards
Bartek
-
To
Hi Paul:
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong s
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
> David Miller writes:
>
>> Here is Patrick McHardy's patch:
>
> So this d
Bartek wrote:
> 2007/4/14, David Miller <[EMAIL PROTECTED]>:
>
>> From: Patrick McHardy <[EMAIL PROTECTED]>
>> Date: Thu, 12 Apr 2007 07:43:39 +0200
>>
>> > It seems we fail to reserve enough headroom for the case
>> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>> >
>> > Can you try this patc
On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > >
> > > > > > > > Yes, it's
urious about is exactly why the patch matters. What ACPI
> > magic is being invoked to confuse, or unconfuse, those controllers?
>
> I think the patch helps, because it makes the ACPI magic be done while the
> i8042's .resume() is being executed.
>
> Which makes me thi
resuming
> [ 43.925054] processor ACPI0007:00: resuming
> [ 43.925161] processor ACPI0007:01: resuming
> [ 43.925268] acpi device:00: resuming
[--snip--]
Hmm, it looks like i8042 is the last thing on the dpm_off_irq list. Still,
if the ACPI resume fails, the next messages may
On Sunday 15 April 2007 9:37 am, Rafael J. Wysocki wrote:
>
> Which makes me think the following patch might help:
>
> drivers/input/serio/i8042.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-rc6/driver
t; little
> > point in using 'platform' on desktop systems anyway.
> >
> > Frankly, I don't know what to do about it. If we move platform_finish()
> > after
> > device_resume(), some systems may be broken ...
>
> What
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote:
> On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> >
> > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
> > > > that the second suspend hangs at "i8042
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > single core CPU.
And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
would be
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
>
> > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
> > > that the second suspend hangs at "i8042 i8042: EARLY resume".
> > > This is kinda interesting because I'm
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > > > > Rafael J. Wysoc
2007/4/14, David Miller <[EMAIL PROTECTED]>:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> It seems we fail to reserve enough headroom for the case
> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>
> Can you try this patch please?
Any confirmation of this f
Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > > > Rafael J. Wysocki wrote:
> > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > > > > On Sat, Apr 14,
I wrote:
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
I meant "the second byte is NOT 0x03", of course.
Paul.
-
To unsubscribe fr
David Miller writes:
> Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since
t; Tobias, I'm unable to reproduce the problem with your .config, but my
> > > > hardware
> > > > is certainly different. Which suspend mode do you use? If that's
> > > > "
.
> > > >
> > > > But it's quite possible that you are running into a different issue
> > > > exposed by this commit.
> > >
> > > Yes, it's likely.
> > >
> > > Tobias, I'm unable to reproduce the problem with your
On Saturday, 14 April 2007 22:25, Adrian Bunk wrote:
> On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote:
> >...
> > Also, would that be feasible for you to use 'shutdown' as a workaround in
> > case
> > the source of the problem is difficult to find and/or fix?
>
> One person rep
On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote:
>...
> Also, would that be feasible for you to use 'shutdown' as a workaround in case
> the source of the problem is difficult to find and/or fix?
One person reporting a regression against a -rc kernel can mean
houndreds or thousan
>
> > > But it's quite possible that you are running into a different issue
> > > exposed by this commit.
> >
> > Yes, it's likely.
> >
> > Tobias, I'm unable to reproduce the problem with your .config, but my
>
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > Tobias Diedrich wrote:
> > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > > commit ed746e3b18f4df18afa3763155972c583
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > Tobias Diedrich wrote:
> > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > > Author: Rafael J. W
David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Sun, 15 Apr 2007 02:49:28 +1000
>
>
>>I didn't see the patch (the message that this is a reply to is the
>>first one that I have seen in this thread), so I can't comment on it.
>
>
> Here is Patrick McHardy's patch:
>
> [..
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 02:49:28 +1000
> I didn't see the patch (the message that this is a reply to is the
> first one that I have seen in this thread), so I can't comment on it.
Here is Patrick McHardy's patch:
diff --git a/drivers/net/ppp_async.c b/driv
David Miller writes:
> > It seems we fail to reserve enough headroom for the case
> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
> >
> > Can you try this patch please?
>
> Any confirmation of this fix yet?
Indeed, ppp_async doesn't handle that case correctly.
RFC 1662 says:
The Con
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> Tobias Diedrich wrote:
> > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > Date: Sat Feb 10 01:43:32 20
Tobias Diedrich wrote:
> > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > Date: Sat Feb 10 01:43:32 2007 -0800
> >
> > [PATCH] swsusp: Change code ordering in disk.c
> >
On Sat, Apr 14, 2007 at 10:16:19AM +0200, Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > Linus Torvalds wrote:
> > >
> > > > We should be getting close to a 2.6.21 release, so please update any
> > > > regression reports you'
Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > Linus Torvalds wrote:
> > >
> > > > We should be getting close to a 2.6.21 release, so please update any
> > > > regression reports you've done,
> > >
> > > For me, suspend to d
Adrian Bunk wrote:
> On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > Linus Torvalds wrote:
> >
> > > We should be getting close to a 2.6.21 release, so please update any
> > > regression reports you've done,
> >
> > For me, suspend to disk works only once (has been the case
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote:
> > Adrian Bunk wrote:
> > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > > Linus Torvalds wrote:
> > > >
> > > > > We should be getting close to a 2.6.21 release, so please update any
>
On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > Linus Torvalds wrote:
> > >
> > > > We should be getting close to a 2.6.21 release, so please update any
> > > > regression reports you've done,
Adrian Bunk wrote:
> On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > Linus Torvalds wrote:
> >
> > > We should be getting close to a 2.6.21 release, so please update any
> > > regression reports you've done,
> >
> > For me, suspend to disk works only once (has been the case
Adrian Bunk wrote:
> Does CONFIG_HPET_TIMER=n make any difference?
Unfortunately not.
> Does the latest -git work?
Coming up next :)
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsub
David Miller <[EMAIL PROTECTED]> wrote:
>
>> It seems we fail to reserve enough headroom for the case
>> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>>
>> Can you try this patch please?
>
> Any confirmation of this fix yet?
FWIW the fix definitely looks correct (the bug has been there for
ye
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> Linus Torvalds wrote:
>
> > We should be getting close to a 2.6.21 release, so please update any
> > regression reports you've done,
>
> For me, suspend to disk works only once (has been the case for all
> .21-rcs IIRC, but I did
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> Bartek wrote:
> > Hopefully, this time it my bug report should be ok :):
> >
> > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a
Linus Torvalds wrote:
> We should be getting close to a 2.6.21 release, so please update any
> regression reports you've done,
For me, suspend to disk works only once (has been the case for all
.21-rcs IIRC, but I didn't get around to report it so far).
There are some threads about an issue like
On Thu, Apr 12, 2007 at 09:26:44PM +0300, Maxim Levitsky wrote:
> On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote:
> > On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote:
> > ...
> > > Maxim Levitsky (1):
> > > Add suspend/resume for HPET
> >
> > This one breaks resume fo
On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote:
> On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote:
> ...
> > Maxim Levitsky (1):
> > Add suspend/resume for HPET
>
> This one breaks resume for me (from STR) on a vaio SZ. Reverting this
> commit allows resuming again bu
On Thu, Apr 12, 2007 at 05:14:02PM +0200, Mattia Dongili wrote:
> On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote:
> ...
> > Maxim Levitsky (1):
> > Add suspend/resume for HPET
>
> This one breaks resume for me (from STR) on a vaio SZ. Reverting this
> commit allows resuming a
On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote:
...
> Maxim Levitsky (1):
> Add suspend/resume for HPET
This one breaks resume for me (from STR) on a vaio SZ. Reverting this
commit allows resuming again but leaves me with some periodic and unpleasant:
[ 155.232000] BUG: sof
Bartek wrote:
> Hopefully, this time it my bug report should be ok :):
>
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
> bf 44 cc ac 3b ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protoco
It is not enough to unload proprietary modules. As long as they have
ever been loaded at all the kernel is tainted.
You need to ensure that the proprietary modules never get loaded at
all. I guess you probably already worked that out, just wanted to
point it out just in case :-)
Hopefully, this
On 4/10/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 10 Apr 2007, Jeff Chua wrote:
> I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried
> set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked.
Do you think you could busect it? You'd have to apply maxim's patch by
* Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch
> >
> > It sounded this was specific to Ingo.
>
> I'm not sure, it sounds a bit like somethin
On Tue, 10 Apr 2007, Jeff Chua wrote:
> On 4/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > We should be getting close to a 2.6.21 release, so please update any
> > regression reports you've done,
>
> I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried
> set/unset CONFIG_
On 4/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
We should be getting close to a 2.6.21 release, so please update any
regression reports you've done,
I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried
set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked.
With rc5 a
On 10/04/07, Bartek <[EMAIL PROTECTED]> wrote:
> Apr 8 21:47:22 localhost kernel: EIP:0060:[]
> Tainted: P VLI
Someone in private took me a noticed of a still tainted kernel. I
didn't noticed that, I am sorry for that. I was sure that unloaded
proprietary modules should resolve the p
Apr 8 21:47:22 localhost kernel: EIP:0060:[]
Tainted: P VLI
Someone in private took me a noticed of a still tainted kernel. I
didn't noticed that, I am sorry for that. I was sure that unloaded
proprietary modules should resolve the problem. My fault. I will try
to reproduce the crash
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch
>
> It sounded this was specific to Ingo.
I'm not sure, it sounds a bit like so
On Sunday 08 April 2007 19:09, Andrew Morton wrote:
> driver core:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch
>
We should not encourage using platform_device_register_simple as we want
Andrew Morton wrote:
netdev:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch
It sounded this was specific to Ingo. I haven't heard anybody else
complain, and AFAIK Ayaz and Ingo were sti
On Sun, Apr 08, 2007 at 04:09:54PM -0700, Andrew Morton wrote:
>
> I'm sitting on five patches which look like 2.6.21 material, but which
> would normally go through subsystem maintainers:
>
> driver core:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm
On Thu, 5 Apr 2007 19:50:11 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> Ok,
> I don't think there really is anything very interesting here, but we're
> hopefully whittling down the list of regressions, and fixing various
> random other small issues while at it.
>
> Some smallis
Please reproduce and provide a new crash dump without the nvidia
binary-only module loaded.
Hi again,
Here is a new crash dump (I also removed vmnet and vmmon properitary
modules), this time I also included a lspci output:
Apr 8 21:47:21 localhost pppd[2114]: rcvd [proto=0xfc3b] bc d4 80 eb
4
On Fri, 2007-04-06 at 16:04 -0700, Linus Torvalds wrote:
[HPET issues resolved]
> > 3) Subject: SATA breakage on resume
> > References : http://lkml.org/lkml/2007/3/7/233
> > Submitter : Thomas Gleixner <[EMAIL PROTECTED]>
> > Soeren Sonnenburg <[EMAIL PROTECTED]>
> > Status
From: Bartek <[EMAIL PROTECTED]>
Date: Sat, 7 Apr 2007 20:11:13 +0200
> I have problem with a Linux kernel oops. It mostly appears when I
> download files using bittorrent or other large file. I have a phone
> modem based Internet access using Home Internet Solution
> (http://en.wikipedia.org/wiki
On Thursday 05 April 2007, Linus Torvalds wrote:
>Ok,
> I don't think there really is anything very interesting here, but we're
>hopefully whittling down the list of regressions, and fixing various
>random other small issues while at it.
>
>Some smallish MIPS updates, networking (and network driver
On Sat, 7 Apr 2007, Linus Torvalds wrote:
>
>
> On Sat, 7 Apr 2007, Randy Dunlap wrote:
> >
> > Is it too late to get a v2.6.21-rc6 tag ?
>
> It's definitely there, I can see it in gitweb..
>
> Do you have some really ancient git that didn't fetch the tags
> automatically?
Oh, my bad. I'd
On Sat, 7 Apr 2007 11:46:13 -0700 (PDT) Linus Torvalds wrote:
>
>
> On Sat, 7 Apr 2007, Randy Dunlap wrote:
> >
> > Is it too late to get a v2.6.21-rc6 tag ?
>
> It's definitely there, I can see it in gitweb..
>
> Do you have some really ancient git that didn't fetch the tags
> automatically
On Sat, 7 Apr 2007, Randy Dunlap wrote:
>
> Is it too late to get a v2.6.21-rc6 tag ?
It's definitely there, I can see it in gitweb..
Do you have some really ancient git that didn't fetch the tags
automatically?
Linus
-
To unsubscribe from this list: send the line "unsubscrib
On Thu, 5 Apr 2007 19:50:11 -0700 (PDT) Linus Torvalds wrote:
>
> Ok,
> I don't think there really is anything very interesting here, but we're
> hopefully whittling down the list of regressions, and fixing various
> random other small issues while at it.
>
> Some smallish MIPS updates, netwo
Hallo
I have problem with a Linux kernel oops. It mostly appears when I
download files using bittorrent or other large file. I have a phone
modem based Internet access using Home Internet Solution
(http://en.wikipedia.org/wiki/Home_internet_Solution). I use Debian
testing, Linux vanilla version:
Hi all,
This looks like a lockdep problem.
2.6.21-rc6
+ hrtimers_debug.patch (from Ingo)
- skge_wol_support (commit a504e64ab42bcc27074ea37405d06833ed6e0820) dropped
due to
swsusp problems
[14016.726946] BUG: at /mnt/md0/devel/linux-git/kernel/lockdep.c:2427
check_flags()
[14016.734331] [] sho
[ Added some people to the cc.. Len, Thomas, Ingo - look for the exact
report on linux-kernel, but basically it's a "irq 9: nobody cared" issue
with acpi_irq on irq9 ]
On Sat, 7 Apr 2007, Soeren Sonnenburg wrote:
>
> regression update for 21-rc6:
>
> 1) all s2ram and NO_HZ related things
On Thu, 2007-04-05 at 19:50 -0700, Linus Torvalds wrote:
> Ok,
> I don't think there really is anything very interesting here, but we're
> hopefully whittling down the list of regressions, and fixing various
> random other small issues while at it.
>
> Some smallish MIPS updates, networking (an
On Fri, 2007-04-06 at 14:40 -0700, Nishanth Aravamudan wrote:
> 2.6.21-rc5 is ok. 2.6.21-rc6 results in
>
> [ 14.241665] Unable to handle kernel NULL pointer dereference (address
> )
Sorry, I think this should fix it:
[TG3]: Fix crash during tg3_init_one().
The driver will c
On 05.04.2007 [19:50:11 -0700], Linus Torvalds wrote:
>
> Ok,
> I don't think there really is anything very interesting here, but we're
> hopefully whittling down the list of regressions, and fixing various
> random other small issues while at it.
>
> Some smallish MIPS updates, networking (an
ee during PCI error failure
Linsys Contractor Adhiraj Joshi (1):
NetXen: Fix hardware access for ppc architecture.
Linus Torvalds (2):
driver core: do not wait unnecessarily in driver_unregister()
Linux 2.6.21-rc6
Maciej Zenczykowski (1):
ia64: desc_empty thinko/typo fix
Mark
98 matches
Mail list logo
