kudzu segfault with latest kernel

[Robert P. J. Day]

  i didn't see anything in bugzilla about this but i only noticed this
with the latest kernel:

$ uname -r
2.6.23-0.204.rc8.fc8
$

during the boot process:

...
Sep 27 08:09:15 localhost kernel: kudzu[2555]: segfault at 00000000 eip 4c47d617 esp
bf9e2458 error 4
...

  i can't say if it was happening with earlier kernels.  should i
bugzilla?

rday

p.s.  if i'm running a fully-updated f8t1, would that be classified as
an f8t1 or f8t2 system, for the purposes of bugzilla?

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

[Bill Nottingham]

Robert P. J. Day (rpjday(a)mindspring.com) said: 
>  ...
>  Sep 27 08:09:15 localhost kernel: kudzu[2555]: segfault at 00000000 eip 4c47d617 esp
> bf9e2458 error 4
>  ...
>  
>    i can't say if it was happening with earlier kernels.  should i
>  bugzilla? 
Please do.

Bill

[Robert P. J. Day]

On Thu, 27 Sep 2007, Bill Nottingham wrote:

>  Robert P. J. Day (rpjday(a)mindspring.com) said:
>  > ...
>  > Sep 27 08:09:15 localhost kernel: kudzu[2555]: segfault at 00000000 eip 4c47d617 esp
> bf9e2458 error 4
>  > ...
>  >
>  >   i can't say if it was happening with earlier kernels.  should i
>  > bugzilla?
>
>  Please do. 
crap ... now i can't seem to reproduce it, even after rebooting twice.
i'll bugzilla it, anyway, with a little surrounding context, as in:

...
Sep 27 08:09:15 localhost kernel: EXT3 FS on sda1, internal journal
Sep 27 08:09:15 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 27 08:09:15 localhost kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level,
low) -> IRQ 17
Sep 27 08:09:15 localhost kernel: Adding 1048568k swap on /dev/mapper/f8-swap. 
Priority:-1 extents:1 across:1048568k
Sep 27 08:09:15 localhost kernel: kudzu[2555]: segfault at 00000000 eip 4c47d617 esp
bf9e2458 error 4
Sep 27 08:09:15 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Sep 27 08:09:15 localhost kernel: e100: eth0: e100_watchdog: link up, 100Mbps,
full-duplex
Sep 27 08:09:15 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
...

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

[Chuck Anderson]

On Thu, Sep 27, 2007 at 09:40:27AM -0400, Robert P. J. Day wrote:
>  p.s.  if i'm running a fully-updated f8t1, would that be
> classified as
>  an f8t1 or f8t2 system, for the purposes of bugzilla? 
It is "devel".

[Robert P. J. Day]

On Thu, 27 Sep 2007, Chuck Anderson wrote:

>  On Thu, Sep 27, 2007 at 09:40:27AM -0400, Robert P. J. Day wrote:
>  > p.s.  if i'm running a fully-updated f8t1, would that be classified as
>  > an f8t1 or f8t2 system, for the purposes of bugzilla?
>
>  It is "devel". 
um ... ok, but if that's the case, what is the value of the f8t1 or
f8t2 selections in bugzilla?  those designations might be valid for an
absolutely pristine install but, the instant you update, it becomes
"devel"?

and that would seem to not match the tradition of, no matter how many
times you update an f7 system, you would still file reports under
"f7".

can someone clarify this?

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Bugzilla versioning (was Re: kudzu segfault with latest kernel)

[Will Woods]

On Thu, 2007-09-27 at 10:17 -0400, Robert P. J. Day wrote:
>  On Thu, 27 Sep 2007, Chuck Anderson wrote:
>  
>  > On Thu, Sep 27, 2007 at 09:40:27AM -0400, Robert P. J. Day wrote:
>  > > p.s.  if i'm running a fully-updated f8t1, would that be classified as
>  > > an f8t1 or f8t2 system, for the purposes of bugzilla?
>  >
>  > It is "devel".
>  
>  um ... ok, but if that's the case, what is the value of the f8t1 or
>  f8t2 selections in bugzilla?  those designations might be valid for an
>  absolutely pristine install but, the instant you update, it becomes
>  "devel"?
>  
>  and that would seem to not match the tradition of, no matter how many
>  times you update an f7 system, you would still file reports under
>  "f7".
>  
>  can someone clarify this? 
In the Glorious Future, we will have a version called "rawhide" instead
of "devel". So it'll be a little less confusing there.

As for the value of having the test releases listed... there are
arguments on both sides. Yes, it's less confusing to have all rawhide
bugs go in once place. Unfortunately we now have 5000 rawhide bugs of
varying ages. 

I think my ideal procedure would be something like
1) File rawhide bugs against - surprise - "rawhide".
2) When the final release happens:
2a) move all open *verified* rawhide bugs to the final release version.
2b) all open *unverified* bugs get put in NEEDINFO.
3) After 2 weeks, unverified bugs from rawhide still in NEEDINFO become
CLOSED INSUFFICIENT_DATA.

Obviously, this leaves us with an unanswered question: how do we verify
bugs?

I'd suggest this: any bug you can reproduce should be moved from NEW to
VERIFIED. Except "VERIFIED" is supposed to be used for bugs that have
fixes, and the *fix* has been verified by QA. So maybe we need a
different state for this. GNOME has their new bugs start in UNCONFIRMED,
and they move to NEW once someone has verified them. 

Does anyone have experience with the GNOME bugzilla and how well that
works? And how many bug triagers does this require? How much hardware?
Can we do it with the current group of people we have doing bug
triaging?

It's still up for discussion. Suggestions are welcomed, especially if
you've got facts to back 'em up.

-w