* Bob Tracy <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >
> > * Bob Tracy <[EMAIL PROTECTED]> wrote:
> >
> > > > Current state of the source tree is the 6f37ac... version, so I'll
> > > > start backing out the above diffs in related groups and continue
> > > > until I've got a working kernel. For lack of an obvious target,
> > > > I'll start with the seemingly innocuous change to sysctl_check.c.
> > > > I'll report back when I've got something.
> > >
> > > That was quick :-). Backing out the sysctl_check.c diff gives me a
> > > working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
> > >
> > > Michael Cree: could you try backing out the diff below from your
> > > 2.6.24-rc3 tree and see if things are now working for you?
> > >
> > > Here's "uname -a", just to confirm (maybe) I'm running on what I say
> > > works:
> > >
> > > Linux smirkin 2.6.24-rc2-g6f37ac79-dirty #2 Fri Dec 7 08:03:12 CST 2007
> > > alpha
> > >
> > > Here's the diff I backed out (patch -R). It's short...
> > >
> > > diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
> > > index 5a2f2b2..4abc6d2 100644
> > > --- a/kernel/sysctl_check.c
> > > +++ b/kernel/sysctl_check.c
> > > @@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
> > > { NET_ROSE, "rose", trans_net_rose_table },
> > > { NET_IPV6, "ipv6", trans_net_ipv6_table },
> > > { NET_X25, "x25", trans_net_x25_table },
> > > - { NET_TR, "tr", trans_net_tr_table },
> > > + { NET_TR, "token-ring", trans_net_tr_table },
> > > { NET_DECNET, "decnet", trans_net_decnet_table },
> > > /* NET_ECONET not used */
> > > { NET_SCTP, "sctp", trans_net_sctp_table },
> >
> > reverting this makes the kernel image shorter by 8 bytes - so
> > perhaps some alignment issue somewhere? Or something gets overflown?
> > Does any of this get actually used by your bootup?
>
> Dunno... The dmesg output is not terribly useful here, because most
> of the "interesting" stuff concerning udev startup that appears on the
> console never makes it into a log. Note that, for the bad cases, I
> don't see the same console output that Michael reported, although the
> net effect is the same: the partitions don't get found, so I'm offered
> the chance to enter my root password and do some poking around, and
> when I do, none of the block devices are present under /dev.
>
> I'm open to suggestions on how to take this analysis further. Michael
> indicated he's running a conference this week, so I don't know when
> he'll be able to come up for air.
i'm not sure how to do direct debugging on udev, so i can only guess
about what effect on the kernel side could have caused this. One bad
hack would be to "probe" udevd's behavior by changing the NET_TR entry
in various ways:
"tr" -> "token-ring" # breaks
"tr" -> "tr" # works
"tr" -> "token-rin0" # ? (1)
"tr" -> "TR" # ? (2)
the question is, does tweak (1) and tweak (2) work or break?
but it would be a lot more effective i guess to get some udevd expert's
attention on this ...
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
