On Sat, 28 Apr 2007, Adrian Bunk wrote:
>
> We are already quite good at ignoring bug reports that come through
> linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more
> than 1600 open bugs because this tells how bad we are at handling bugs.
No, it just shows that bugzilla
On Sun, Apr 29, 2007 at 08:11:30AM +1000, Neil Brown wrote:
> On Saturday April 28, [EMAIL PROTECTED] wrote:
>...
> > As Andrew has pointed out before though - even though he forwards
> > the bugs, nobody does anything with it. The sad truth seems to be
> > that people have very little interest in
On Sat, Apr 28, 2007 at 09:50:00AM +1000, Peter Williams wrote:
> Neil Horman wrote:
> >On Sat, Apr 28, 2007 at 12:28:28AM +1000, Peter Williams wrote:
> >>Neil Horman wrote:
> >>>On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
> >
> >Damn, This is what happens when I try to do thin
On Saturday April 28, [EMAIL PROTECTED] wrote:
>
> Yes, human involvement from someone with half a brain would be better.
> Andrew does a lot of that. Not a particularly good use of talent really.
> but still.
I think more than half a brain is needed to do this well. You need a
reasonable unders
Russell King wrote:
> On Sat, Apr 28, 2007 at 09:53:20PM +0200, Adrian Bunk wrote:
>> We are already quite good at ignoring bug reports that come through
>> linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more
>> than 1600 open bugs because this tells how bad we are at handlin
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
Adrian Bunk wrote:
I do hereby promise you to manually ask the submitters of all 1600 open
bugs in the kernel Bugzilla within one month whether their problem is
still present with 2.6.21 and forwarding all bugs if the answer was
"yes" to whoever is the right recipient if you promise me that al
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
Michael Tokarev <[EMAIL PROTECTED]> writes:
> For how long you plan to maintain 2.6.x.y -stable series for each
> 2.6.x release? The thing is that tehere will probably be NO
> .123 "revision"
Actually I meant .1, .2 and maybe even .3 :-)
--
Krzysztof Halasa
-
To unsubscribe from this list: send
On Sat, Apr 28, 2007 at 09:53:20PM +0200, Adrian Bunk wrote:
> We are already quite good at ignoring bug reports that come through
> linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more
> than 1600 open bugs because this tells how bad we are at handling bugs.
> How many thousa
On Thu, Apr 26, 2007 at 02:13:08PM -0700, Linus Torvalds wrote:
>...
> (I've said this before, but I'll say it again: one thing that would
> already make bugzilla better is to just always drop any bug reports that
> are more than a week old and haven't been touched. It wouldn't need *much*
> tou
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
The thing is, these reports MUST NOT go to "everybody". If they do, that
is actually *worse* than nothing, because people will just ignore them
entirely, since they aren't "directed".
The emails need to be directed to the appropriate parties, not go to
everybody. There is nobody who is interes
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
On 4/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote:
> On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote:
> > "no regressions" is definitely not feasible.
> >
> > 14 known regressions, some of them not yet debugged at all, are
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
Neil Horman wrote:
On Sat, Apr 28, 2007 at 12:28:28AM +1000, Peter Williams wrote:
Neil Horman wrote:
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Damn, This is what happens when I try to do things too quickly. I missed one
spot in my last patch where I replaced skb with r
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 Thu, 26 Apr 2007, Adrian Bunk wrote:
> Linus said 2.6.20 was a stable kernel. My impression was that at least
> two of the regressions from my 2.6.20 regressions list should have been
> fixed before 2.6.20.
>
> They have both been fixed through -stable, but I also remember a quite
> experie
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
Stephen Clark wrote:
If hardware worked in the previous version of the kernel can't users expect
the same hardware to work in this kernel?
Failure of that assumption is the heart of the whole "regression"
discussion. It's not limited to hardware, kernel security might be an
issue, some networ
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
Adrian Bunk wrote:
Life has taught me that sometimes I'm right, sometimes I'm wrong, and
sometimes both sides have a possible solution. We might agree to
disagree, and you are the one who's opinion counts. I can only say that
I am not happy with the result, and that I do therefore not spend my
Linus Torvalds wrote:
On Thu, 26 Apr 2007, Bill Davidsen wrote:
If the result is fixing things which then don't get fixed in mainline, as
Adrian notes
That whole premise is flawed. The *rule* for the stable tree is that
things don't get merged into the stable tree unless they are fixed in
m
Adrian Bunk wrote:
On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote:
On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote:
"no regressions" is definitely not feasible.
14 known regressions, some of them not yet debugged at all, are
different from your "some small r
On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote:
> On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote:
> > "no regressions" is definitely not feasible.
> >
> > 14 known regressions, some of them not yet debugged at all, are
> > different from your "some small regression".
>
Michael Tokarev wrote:
[...]
> there will be just no stable
> kernels *at all*. because when the next 2.6.x will start looking
> more or less useful due to 2.6.x.y series, there will be new 2.6.x+1,
> and work with 2.6.x stops...
>
> It's not the case currently, but this way ("let's fix the bugs
>
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
Linus Torvalds wrote:
Jeff, I'm going to assume I get all these through your normal network
driver tree.
Yep.
Today, I'm sending you and Andrew fixes like the e1000 stuff just sent,
and Neil's fixes. Then after the merging dust settles, I'll push
jgarzik/netdev-2.6.git#upstream, which is th
On Fri, 27 Apr 2007, Neil Horman wrote:
>
> Damn, This is what happens when I try to do things too quickly. I missed one
> spot in my last patch where I replaced skb with rx_skb [...]
Jeff, I'm going to assume I get all these through your normal network
driver tree.
So this is just a note to
Krzysztof Halasa wrote:
[]
> We've got stable series.
> With KNOWN_PROBLEMS information, sysadmins can decide if they can
> safely upgrade to .0 or if they have to wait for .123. Pressing
> the responsible people to fix the problems in .123 (would) help
> it greatly.
For how long you plan to maint
On Sat, Apr 28, 2007 at 12:28:28AM +1000, Peter Williams wrote:
> Neil Horman wrote:
> >On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Damn, This is what happens when I try to do things too quickly. I missed one
spot in my last patch where I replaced skb with rx_skb. Its not cri
On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote:
> "no regressions" is definitely not feasible.
>
> 14 known regressions, some of them not yet debugged at all, are
> different from your "some small regression".
Yes, but when were some of these regressions reported? Past a certain
po
On Fri, 27 Apr 2007 20:01:37 +0530 Sunil Naidu wrote:
> On 4/26/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> > >
> > > Don't you need to increase CONFIG_LOG_BUF_SHIFT ?
>
> Yep, I need to. But, have to enable the Kernel Debug (DEBUG_KERNEL) to
> increase the value from default 14 value
On Friday 27 April 2007 15:31:37 Sunil Naidu wrote:
> On 4/26/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> > > Don't you need to increase CONFIG_LOG_BUF_SHIFT ?
>
> Yep, I need to. But, have to enable the Kernel Debug (DEBUG_KERNEL) to
> increase the value from default 14 value to 15/16.
Stephen Clark wrote:
Jeff Garzik wrote:
Stephen Clark wrote:
It is laptop that does not have a serial port and I could not couldn't
get the
kernel to boot using a usb serial port so I couldn't get a screen
capture of
the intermittant panic.
If you can write it down wit
On Thu, Apr 26, 2007 at 09:50:15PM +0100, Alan Cox wrote:
> > They get frustrated because they focussed on developing new features
> > instead of fixing regressions, and now it takes longer until their new
> > features get merged because noone fixed the regressions...
>
> I would disagree: They
On 4/26/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote:
>
> Don't you need to increase CONFIG_LOG_BUF_SHIFT ?
Yep, I need to. But, have to enable the Kernel Debug (DEBUG_KERNEL) to
increase the value from default 14 value to 15/16. I feel that this
might increase the kernel size?
Ummm, i
Neil Horman wrote:
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various
daemons
are being started (not always the same daemon unfortunately).
This
On Fri, Apr 27, 2007 at 08:26:55AM -0400, Jeff Garzik wrote:
> Neil Horman wrote:
> >This was reported to me last night, and I've posted a patch to fix it, its
> >available here:
> >http://marc.info/?l=linux-netdev&m=117761259222165&w=2
> >
> >It applies on top of the previous patch, and should fix
Neil Horman wrote:
This was reported to me last night, and I've posted a patch to fix it, its
available here:
http://marc.info/?l=linux-netdev&m=117761259222165&w=2
It applies on top of the previous patch, and should fix your problem.
Here's a copy of the patch
Thanks & Regards
Neil
diff --g
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
> Linus Torvalds wrote:
> >
> >On Fri, 27 Apr 2007, Peter Williams wrote:
> >>The 2.6.21 kernel is hanging during the post boot phase where various
> >>daemons
> >>are being started (not always the same daemon unfortunately).
> >>
> >
On Fri, 27 Apr 2007 07:13:08 Linus Torvalds wrote:
> I think it could be more interesting if part of the job was doing the
> tools. Tools *are* important. Most of my actual _development_ for the last
> couple of years has been on "git", not the kernel, but I think I was more
> productive that way,
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 Fri, 27 Apr 2007 09:56:03 +0900 "l l" <[EMAIL PROTECTED]> wrote:
> Here is another compilation failure.
>
> make
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CHK include/linux/compile.h
> CC [M] drivers/w1/w1.o
> drivers/w1/w1.c: In function 'w1_slave_r
On Thu, 26 Apr 2007 17:54:20 -0700, Andrew Morton wrote:
> On Fri, 27 Apr 2007 00:00:15 + (GMT) William Heimbigner <[EMAIL
> PROTECTED]> wrote:
>
> > Output leading up to the error:
> >
> >CC drivers/macintosh/macio-adb.o
> >LD drivers/macintosh/built-in.o
> >CC [M] dr
On Apr 26 2007 12:23, Marat Buharov wrote:
>
> [Offtopic]
> Today, April, 26, 21 year has been passed since Chernobyl Nuclear
> Power Plant disaster, and Linus announced *drum roll* 2.6.21
> !!! What a mysterious coincidence...
And 2.6.26 will be released on April 01 2008.
Jan
--
-
T
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various daemons
are being started (not always the same daemon unfortunately).
This problem was not present in 2.6.21-rc7 and there is no oops or other
unusual output i
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various daemons
are being started (not always the same daemon unfortunately).
This problem was not present in 2.6.21-rc7 and there is no oops or other
unusual output i
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
On Thu, 2007-04-26 at 21:02 +0200, Willy Tarreau wrote:
> On Thu, Apr 26, 2007 at 09:40:26AM -0700, Linus Torvalds wrote:
>
> > So we should have somebody like Christoph running -mm, and when things
> > break, we'll just sic Christoph on whoever broke it, and teach people
> > proper fear and res
On Fri, 27 Apr 2007, Peter Williams wrote:
>
> The 2.6.21 kernel is hanging during the post boot phase where various daemons
> are being started (not always the same daemon unfortunately).
>
> This problem was not present in 2.6.21-rc7 and there is no oops or other
> unusual output in the system
On Thu, 26 Apr 2007 17:54:20 -0700 Andrew Morton wrote:
> On Fri, 27 Apr 2007 00:00:15 + (GMT) William Heimbigner <[EMAIL
> PROTECTED]> wrote:
>
> > Output leading up to the error:
> >
> >CC drivers/macintosh/macio-adb.o
> >LD drivers/macintosh/built-in.o
> >CC [M] dr
take address of bit-field 'family'
drivers/w1/w1.c:118: error: cannot take address of bit-field 'family'
make[2]: *** [drivers/w1/w1.o] Error 1
make[1]: *** [drivers/w1] Error 2
make: *** [drivers] Error 2
I don't, i think i have to go back to gcc-4.2.0 which was fine wi
On Fri, 27 Apr 2007 00:00:15 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
> Output leading up to the error:
>
>CC drivers/macintosh/macio-adb.o
>LD drivers/macintosh/built-in.o
>CC [M] drivers/macintosh/apm_emu.o
>CC [M] drivers/macintosh/therm_windtunnel
Hi,
Sorry for the late, i was in my bed.
I assume this is a plain 2.6.21 from ftp.kernel.org?
Yes.
Can you reproduce this with gcc 4.1?
If yes, please send your .config .
I don't, i think i have to go back to gcc-4.2.0 which was fine with
linux-2.6.21-rc7.
It will be same to 2.6.21.
On Fri, 27 Apr 2007, Thomas Gleixner wrote:
>
> Maybe we need to coordinate changes better. 2.6.21 got three big updates
> which affected suspend/resume - one of them is my fault. But fiddling
> out which one of those - we had nested problems as well - makes it quite
> hard to grok them in time,
Output leading up to the error:
CC drivers/macintosh/macio-adb.o
LD drivers/macintosh/built-in.o
CC [M] drivers/macintosh/apm_emu.o
CC [M] drivers/macintosh/therm_windtunnel.o
drivers/macintosh/therm_windtunnel.c: In function 'therm_of_remove':
drivers/macintosh/therm_windtunn
Adrian,
On Thu, 2007-04-26 at 14:58 +0200, Adrian Bunk wrote:
> I am aware that my work had some effect, and I am aware that my work
> gets appreciated - there's no need for everyone to repeat this.
Nevertheless, thanks for your efforts and time spent. You did a great
job and I hope you can conv
On (26/04/07 09:40), Linus Torvalds didst pronounce:
>
>
> On Thu, 26 Apr 2007, Jan Engelhardt wrote:
> >
> > I really appreciate the lot of -rcs, especially if there are so many
> > intrusive changes/regressions. Like Andrew, I have a feeling that it
> > gets buggier, but at least, it seems to
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
On (26/04/07 20:45), Adrian Bunk didst pronounce:
> On Thu, Apr 26, 2007 at 08:37:14PM +0200, Krzysztof Halasa wrote:
> >...
> > With KNOWN_PROBLEMS information, sysadmins can decide if they can
> > safely upgrade to .0 or if they have to wait for .123.
> >...
>
> Listing regressions like the foll
On Thu, 26 Apr 2007, Diego Calleja wrote:
>
> Bugzilla sucks quite a lot at email, but you can answer emails and they get
> into the bugzilla database; and there're two mailing lists (listed in
> Documentation/HOWTO) that send notifications about every new bug
> added/modified- I know it's not t
On Thursday 26 April 2007, Stephen Clark wrote:
>Jeff Garzik wrote:
>>IMO, the closer you look, the more warts you find. Before you starting
>>doing your work with kernel regressions, no one was really tracking it.
>> I bet you have helped cut down on the regressions, but I have no good
>>way to
On Thursday 26 April 2007, Stephen Clark wrote:
>Jeff Garzik wrote:
>>IMO, the closer you look, the more warts you find. Before you starting
>>doing your work with kernel regressions, no one was really tracking it.
>> I bet you have helped cut down on the regressions, but I have no good
>>way to
> They get frustrated because they focussed on developing new features
> instead of fixing regressions, and now it takes longer until their new
> features get merged because noone fixed the regressions...
I would disagree: They get frustrated because they are blocked on some
small regression whi
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
El Thu, 26 Apr 2007 11:42:22 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
escribió:
> I bet that's true even of a lot of people who are more "web oriented" than
> I am. They may look at webpages, but getting notified by email is still
> the wakeup call. There's a difference between "active a
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
On Thu, 26 Apr 2007 19:55:26 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 27, 2007 at 12:24:32AM +0900, l l wrote:
> > Hi,
> >
> > How to link libgcc.a with linux-2.6.21?
> >
> > LD .tmp_vmlinux1
> > kernel/built-in.o: In function
On Apr 26 2007 09:40, Linus Torvalds wrote:
>On Thu, 26 Apr 2007, Jan Engelhardt wrote:
>>
>For example, I can certainly say that after 2.6.21, I'm likely to be very
>unhappy merging something that isn't "obviously safe". I knew the timer
>changes were potentially painful, I just hadn't realized
Adrian Bunk <[EMAIL PROTECTED]> writes:
> Listing regressions like the following will most likely be zero help for
> them when deciding whether to upgrade now or later (and BTW, the latter
> might imply running a kernel with known security issues):
>
> Subject: acpi_pm clocksource loses time
Francois Romieu wrote:
Jeff Garzik <[EMAIL PROTECTED]> :
Francois Romieu wrote:
Pointer for the rtl8139 regression please ?
I'm guessing it's this one:
Subject: boot failure: rtl8139: exception in interrupt routine
References : http://lkml.org/lkml/20
Jeff Garzik <[EMAIL PROTECTED]> :
> Francois Romieu wrote:
> >Pointer for the rtl8139 regression please ?
>
> I'm guessing it's this one:
>
> > Subject: boot failure: rtl8139: exception in interrupt routine
> > References : http://lkml.org/lkml/2007/3/31/160
> > Submitter : Steph
Jeff Garzik wrote:
Stephen Clark wrote:
It is laptop that does not have a serial port and I could not couldn't
get the
kernel to boot using a usb serial port so I couldn't get a screen
capture of
the intermittant panic.
If you can write it down with a pen and paper, or manually co
Jeff Garzik wrote:
Francois Romieu wrote:
Pointer for the rtl8139 regression please ?
I'm guessing it's this one:
Subject: boot failure: rtl8139: exception in interrupt routine
References : http://lkml.org/lkml/2007/3/31/160
Submitter : Stephen Clark
Stephen Clark wrote:
If hardware worked in the previous version of the kernel can't users expect
the same hardware to work in this kernel?
In general, yes.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
On Thu, Apr 26, 2007 at 03:13:15PM -0400, Jeff Garzik wrote:
> Francois Romieu wrote:
>> Pointer for the rtl8139 regression please ?
>
> I'm guessing it's this one:
>
>> Subject: boot failure: rtl8139: exception in interrupt routine
>> References : http://lkml.org/lkml/2007/3/31/160
>
Jeff Garzik wrote:
IMO, the closer you look, the more warts you find. Before you starting
doing your work with kernel regressions, no one was really tracking it.
I bet you have helped cut down on the regressions, but I have no good
way to quantify my gut feeling.
Additional comments on dev
On Thu, Apr 26, 2007 at 08:58:51PM +0200, Francois Romieu wrote:
> Adrian Bunk <[EMAIL PROTECTED]> :
> [...]
> > And how to order the rtl8139 netdriver regression reported one month ago
> > against the snd_hda_intel regression reported one month ago?
>
> Pointer for the rtl8139 regression please
Francois Romieu wrote:
Pointer for the rtl8139 regression please ?
I'm guessing it's this one:
Subject: boot failure: rtl8139: exception in interrupt routine
References : http://lkml.org/lkml/2007/3/31/160
Submitter : Stephen Clark <[EMAIL PROTECTED]>
Stat
Krzysztof Halasa wrote:
Adrian Bunk <[EMAIL PROTECTED]> writes:
Look at the facts:
8 out of 14 regressions in my current list were reported in March or earlier.
And for many regressions fixed it took several weeks until debugging
by a kernel developer was started.
We do not lack testers
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
Adrian Bunk <[EMAIL PROTECTED]> :
[...]
> And how to order the rtl8139 netdriver regression reported one month ago
> against the snd_hda_intel regression reported one month ago?
Pointer for the rtl8139 regression please ?
--
Ueimor
Anybody got a battery for my Ultra 10 ?
-
To unsubscribe from
On Thu, Apr 26, 2007 at 09:40:26AM -0700, Linus Torvalds wrote:
> So we should have somebody like Christoph running -mm, and when things
> break, we'll just sic Christoph on whoever broke it, and teach people
> proper fear and respect!
And with Al Viro doing random code review and fill in the c
On Thu, Apr 26, 2007 at 08:37:14PM +0200, Krzysztof Halasa wrote:
>...
> With KNOWN_PROBLEMS information, sysadmins can decide if they can
> safely upgrade to .0 or if they have to wait for .123.
>...
Listing regressions like the following will most likely be zero help for
them when deciding whet
On Thu, 26 Apr 2007, Diego Calleja wrote:
>
> From my humble POV, it's a problem that all this discussion was generated
> on what Adrian does or stop doing. Apparently, unless Adrian posts his
> list of know regressions, most of the people doesn't look at the bugzilla
> at all. Maybe it'd be use
Adrian Bunk <[EMAIL PROTECTED]> writes:
> Look at the facts:
> 8 out of 14 regressions in my current list were reported in March or earlier.
> And for many regressions fixed it took several weeks until debugging
> by a kernel developer was started.
>
> We do not lack testers for getting bug repor
On Thu, Apr 26, 2007 at 02:04:56PM -0400, Jeff Garzik wrote:
> IMO, the closer you look, the more warts you find. Before you starting
> doing your work with kernel regressions, no one was really tracking it. I
> bet you have helped cut down on the regressions, but I have no good way to
> quant
El Thu, 26 Apr 2007 13:02:28 -0400, Chuck Ebbert <[EMAIL PROTECTED]> escribió:
> Problem is, not enough developers pay attention to the -stable
> series. Adrian, maybe you could shift your attention there and
> stop trying to track the bleeding edge?
>From my humble POV, it's a problem that all t
IMO, the closer you look, the more warts you find. Before you starting
doing your work with kernel regressions, no one was really tracking it.
I bet you have helped cut down on the regressions, but I have no good
way to quantify my gut feeling.
Additional comments on developers and fixing re
On Fri, Apr 27, 2007 at 12:24:32AM +0900, l l wrote:
> Hi,
>
> How to link libgcc.a with linux-2.6.21?
>
> LD .tmp_vmlinux1
> kernel/built-in.o: In function `timespec_add_ns':
> /usr/src/linux-2.6.21/kernel/timer.c:828: undefined reference to
> `__udivdi3&#x
On Thu, Apr 26, 2007 at 10:20:46AM -0700, Linus Torvalds wrote:
> On Thu, 26 Apr 2007, Adrian Bunk wrote:
>...
> > But I am not happy with the current state of released kernels.
>
> So you're going to help exactly how? By stopping to help? Or kvetching
> about developers that can't figure out why
On Thu, 26 Apr 2007, Bill Davidsen wrote:
>
> If the result is fixing things which then don't get fixed in mainline, as
> Adrian notes
That whole premise is flawed. The *rule* for the stable tree is that
things don't get merged into the stable tree unless they are fixed in
mainline already.
Linus Torvalds wrote:
In other words, there's a _reason_ we have staggered development. We have
the "crazy development trees" (aka -mm and various other trees), we have
the "development tree" (aka Linus' tree), and we have the -stable tree. If
the stable tree has a dozen known issues that they
Adrian Bunk wrote:
On Wed, Apr 25, 2007 at 08:29:28PM -0700, Linus Torvalds wrote:
...
So it's been over two and a half months, and while it's certainly not the
longest release cycle ever, it still dragged out a bit longer than I'd
have hoped for and it should have. As usual, I'd like to thank
On Thu, 26 Apr 2007, Adrian Bunk wrote:
>
> They get frustrated because they focussed on developing new features
> instead of fixing regressions, and now it takes longer until their new
> features get merged because noone fixed the regressions...
I agree. That's part of it. But part of it is
On Thu, Apr 26, 2007 at 08:47:26AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 26 Apr 2007, Adrian Bunk wrote:
> >
> > There is a conflict between Linus trying to release kernels every
> > 2 months and releasing with few regressions.
>
> No.
>
> Regressions _increase_ with longer release cycle
201 - 300 of 539 matches
Mail list logo
