[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071207165902.3686FDBA2@gherkin.frus.com>
Date: Fri, 7 Dec 2007 10:59:02 -0600 (CST)
From: rct@...s.com (Bob Tracy)
To: Ingo Molnar <mingo@...e.hu>
CC: Bob Tracy <rct@...s.com>,
Andrew Morton <akpm@...ux-foundation.org>, mcree@...on.net.nz,
linux-kernel@...r.kernel.org, rjw@...k.pl, rth@...ddle.net,
ink@...assic.park.msu.ru, linux-scsi@...r.kernel.org,
kay.sievers@...y.org, greg@...ah.com
Subject: Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Ingo Molnar wrote:
>
> * Bob Tracy <rct@...s.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.
--
------------------------------------------------------------------------
Bob Tracy | "They couldn't hit an elephant at this dist- "
rct@...s.com | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists