Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

[Ingo Molnar <mingo@elte.hu>]

* Bob Tracy <rct@frus.com> wrote:

> Ingo Molnar wrote:
> > 
> > * Bob Tracy <rct@frus.com> 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 #$%@! 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/