lkml.org 
[lkml]   [2007]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

    * 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


    \
     
     \ /
      Last update: 2007-12-07 19:11    [W:5.608 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site