From: Kay Sievers <kay.sievers@vrfy.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Bob Tracy <rct@frus.com>,
Andrew Morton <akpm@linux-foundation.org>,
mcree@orcon.net.nz, linux-kernel@vger.kernel.org, rjw@sisk.pl,
rth@twiddle.net, ink@jurassic.park.msu.ru,
linux-scsi@vger.kernel.org, greg@kroah.com
Subject: Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Date: Fri, 07 Dec 2007 19:19:32 +0100 [thread overview]
Message-ID: <1197051572.3599.10.camel@lov.site> (raw)
In-Reply-To: <20071207180615.GC19173@elte.hu>
On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote:
> * 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 ...
Could we get the output of:
ls -l /sys/block/sda/
and:
grep . /sys/block/sda/*/dev
?
Kay
next prev parent reply other threads:[~2007-12-07 18:20 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-18 5:20 [BUG] 2.6.23-rc3 can't see sd partitions on Alpha Bob Tracy
2007-11-25 6:38 ` Andrew Morton
2007-11-25 12:15 ` Rafael J. Wysocki
2007-11-26 13:48 ` Bob Tracy
2007-11-30 22:30 ` Michael Cree
2007-11-30 22:42 ` Andrew Morton
2007-11-30 23:26 ` Rafael J. Wysocki
2007-12-02 20:53 ` Michael Cree
2007-12-03 1:17 ` Bob Tracy
2007-12-04 12:16 ` Ingo Molnar
2007-12-04 15:36 ` Bob Tracy
2007-12-05 17:30 ` Bob Tracy
2007-12-07 0:16 ` Bob Tracy
2007-12-07 0:33 ` Andrew Morton
2007-12-07 5:07 ` Bob Tracy
2007-12-07 10:26 ` Andrew Morton
2007-12-07 11:37 ` Ingo Molnar
2007-12-07 13:39 ` Bob Tracy
2007-12-07 14:55 ` Bob Tracy
2007-12-07 15:05 ` Ingo Molnar
2007-12-07 16:59 ` Bob Tracy
2007-12-07 18:06 ` Ingo Molnar
2007-12-07 18:19 ` Kay Sievers [this message]
2007-12-07 19:36 ` Bob Tracy
2007-12-07 20:43 ` Michael Cree
2007-12-07 21:19 ` Kay Sievers
2007-12-07 22:39 ` Bob Tracy
2007-12-08 4:53 ` Bob Tracy
2007-12-08 5:05 ` Bob Tracy
2007-12-08 15:48 ` Kay Sievers
2007-12-09 0:51 ` Michael Cree
2007-12-09 4:19 ` Bob Tracy
2007-12-09 18:07 ` Ivan Kokshaysky
2007-12-10 15:08 ` Bob Tracy
2007-12-10 23:12 ` Ivan Kokshaysky
2007-12-10 15:05 ` Bob Tracy
2007-12-07 11:40 ` Ingo Molnar
2007-12-07 5:42 ` Bob Tracy
2007-12-07 9:33 ` Ingo Molnar
2007-12-07 0:44 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1197051572.3599.10.camel@lov.site \
--to=kay.sievers@vrfy.org \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mcree@orcon.net.nz \
--cc=mingo@elte.hu \
--cc=rct@frus.com \
--cc=rjw@sisk.pl \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).