I'm using ide=reverse, and my root is on hde5. 2.6.0-test1-mm2 finds my
root fs fine using the init/do_mounts.c patch posted recently.
2.6.0-test2-mm1 (in which said patch seems to have been included),
however, fails on all of the following root= options:
* 2105
* /dev/ide/host2/bus0/target0/lun0/part5
* /dev/hde5
I don't know what to try next. Can someone enlighten me as to what has
been happening lately?
Shawn <[email protected]> wrote:
>
> I'm using ide=reverse, and my root is on hde5. 2.6.0-test1-mm2 finds my
> root fs fine using the init/do_mounts.c patch posted recently.
>
> 2.6.0-test2-mm1 (in which said patch seems to have been included),
> however, fails on all of the following root= options:
> * 2105
> * /dev/ide/host2/bus0/target0/lun0/part5
> * /dev/hde5
>
> I don't know what to try next. Can someone enlighten me as to what has
> been happening lately?
Beats me. Tried "/dev/hde/5" and "21:05"?
Can you see what this says?
25-akpm/init/do_mounts.c | 1 +
1 files changed, 1 insertion(+)
diff -puN init/do_mounts.c~a init/do_mounts.c
--- 25/init/do_mounts.c~a Mon Jul 28 14:44:37 2003
+++ 25-akpm/init/do_mounts.c Mon Jul 28 14:44:53 2003
@@ -74,6 +74,7 @@ static dev_t __init try_name(char *name,
/*
* The format of dev is now %u:%u -- see print_dev_t()
*/
+ printk("scanning `%s'\n", buf);
if (sscanf(buf, "%u:%u", &maj, &min) == 2)
res = MKDEV(maj, min);
else
_
Also take a close look at the dmesg output, make sure that all the devices
and partitions are appearing in the expected places.
Thank you, I didn't look very closely at the patch (really at all).
The one thing making me think I had it right with "2105" was that the
kernel did seem to grok it as (33,5).
On Mon, 2003-07-28 at 16:47, Andrew Morton wrote:
> Shawn <[email protected]> wrote:
> >
> > I'm using ide=reverse, and my root is on hde5. 2.6.0-test1-mm2 finds my
> > root fs fine using the init/do_mounts.c patch posted recently.
> >
> > 2.6.0-test2-mm1 (in which said patch seems to have been included),
> > however, fails on all of the following root= options:
> > * 2105
> > * /dev/ide/host2/bus0/target0/lun0/part5
> > * /dev/hde5
> >
> > I don't know what to try next. Can someone enlighten me as to what has
> > been happening lately?
>
> Beats me. Tried "/dev/hde/5" and "21:05"?
>
> Can you see what this says?
>
> 25-akpm/init/do_mounts.c | 1 +
> 1 files changed, 1 insertion(+)
>
> diff -puN init/do_mounts.c~a init/do_mounts.c
> --- 25/init/do_mounts.c~a Mon Jul 28 14:44:37 2003
> +++ 25-akpm/init/do_mounts.c Mon Jul 28 14:44:53 2003
> @@ -74,6 +74,7 @@ static dev_t __init try_name(char *name,
> /*
> * The format of dev is now %u:%u -- see print_dev_t()
> */
> + printk("scanning `%s'\n", buf);
> if (sscanf(buf, "%u:%u", &maj, &min) == 2)
> res = MKDEV(maj, min);
> else
>
> _
>
> Also take a close look at the dmesg output, make sure that all the devices
> and partitions are appearing in the expected places.
>
>
Shawn <[email protected]> wrote:
>
> Thank you, I didn't look very closely at the patch (really at all).
>
> The one thing making me think I had it right with "2105" was that the
> kernel did seem to grok it as (33,5).
I don't understand. Are you saying that you now have it working?
If so, how?
Sorry, I see now I was quite vague, and was still a little caffiene
deprived. To clarify what I meant by sentence #1:
I should have seen that I ought to use 21:05 from the
do_mounts.c patch I applied to -test1-mm2
As far as sentence #2, the boot messages seem to indicate that the
kernel understood "root=2105" as referring to (33,5), but still did not
mount root. This got me really confused.
As far as having it working, I'm waiting to get home to try your
suggestions.
The only other though thing I was trying to convey is that I don't
understand why -test1-mm2 with patch works while -test2-mm1 does not.
On Mon, 2003-07-28 at 17:02, Andrew Morton wrote:
> Shawn <[email protected]> wrote:
> >
> > Thank you, I didn't look very closely at the patch (really at all).
> >
> > The one thing making me think I had it right with "2105" was that the
> > kernel did seem to grok it as (33,5).
>
> I don't understand. Are you saying that you now have it working?
> If so, how?
OK, mucho more info (no wonder root=/dev/hde5 no worky):
VP_IDE: (ide_setup_pci_device:) Could not enable device
Found out my on board via pci ide was not getting initialized under
-test2-mm1, so I went looking for driver/ide/pci/via82cxxx in the diffs.
I found this in the -test2 diff:
- (((u >> i) & 7) < 8))) {
+ (((u >> i) & 7) < 6))) {
...and reversing it did not change anything.
The only other diff I could think might matter to
drivers/ide/setup-pci.c
-static unsigned long __init ide_get_or_set_dma_base (ide_hwif_t *hwif)
+static unsigned long ide_get_or_set_dma_base (ide_hwif_t *hwif)
...which does not look like it should kill my via ide...
I am now totally at my wit's end. Can I be helped now that I got off my
fat arse?
Info about my system:
http://www.enodev.com/lspci.txt
http://www.enodev.com/dmesg
http://www.enodev.com/proc-ioports
http://www.enodev.com/proc-interrupts
http://www.enodev.com/proc-iomem
http://www.enodev.com/proc_sex.html
On Mon, 2003-07-28 at 17:02, Andrew Morton wrote:
> Shawn <[email protected]> wrote:
> >
> > Thank you, I didn't look very closely at the patch (really at all).
> >
> > The one thing making me think I had it right with "2105" was that the
> > kernel did seem to grok it as (33,5).
>
> I don't understand. Are you saying that you now have it working?
> If so, how?
Shawn <[email protected]> wrote:
>
> OK, mucho more info (no wonder root=/dev/hde5 no worky):
> VP_IDE: (ide_setup_pci_device:) Could not enable device
>
> Found out my on board via pci ide was not getting initialized under
> -test2-mm1, so I went looking for driver/ide/pci/via82cxxx in the diffs.
> I found this in the -test2 diff:
> - (((u >> i) & 7) < 8))) {
> + (((u >> i) & 7) < 6))) {
> ...and reversing it did not change anything.
>
> The only other diff I could think might matter to
> drivers/ide/setup-pci.c
> -static unsigned long __init ide_get_or_set_dma_base (ide_hwif_t *hwif)
> +static unsigned long ide_get_or_set_dma_base (ide_hwif_t *hwif)
> ...which does not look like it should kill my via ide...
>
OK, looks like breakage at the PCI level: pci_enable_device_bars() is
failing; something below pcibios_enable_device().
What was the most recent kernel which works?
-test1-mm2. Hadn't tried any -bk? in between.
Won't have time to do much tonight or tomorrow before evening, but I'll
test what I can.
On Mon, 2003-07-28 at 21:36, Andrew Morton wrote:
> Shawn <[email protected]> wrote:
> >
> > OK, mucho more info (no wonder root=/dev/hde5 no worky):
> > VP_IDE: (ide_setup_pci_device:) Could not enable device
> >
> > Found out my on board via pci ide was not getting initialized under
> > -test2-mm1, so I went looking for driver/ide/pci/via82cxxx in the diffs.
> > I found this in the -test2 diff:
> > - (((u >> i) & 7) < 8))) {
> > + (((u >> i) & 7) < 6))) {
> > ...and reversing it did not change anything.
> >
> > The only other diff I could think might matter to
> > drivers/ide/setup-pci.c
> > -static unsigned long __init ide_get_or_set_dma_base (ide_hwif_t *hwif)
> > +static unsigned long ide_get_or_set_dma_base (ide_hwif_t *hwif)
> > ...which does not look like it should kill my via ide...
> >
>
> OK, looks like breakage at the PCI level: pci_enable_device_bars() is
> failing; something below pcibios_enable_device().
>
> What was the most recent kernel which works?
On Mon, 2003-07-28 at 21:36, Andrew Morton wrote:
> Shawn <[email protected]> wrote:
> >
> > OK, mucho more info (no wonder root=/dev/hde5 no worky):
> > VP_IDE: (ide_setup_pci_device:) Could not enable device
> OK, looks like breakage at the PCI level: pci_enable_device_bars() is
> failing; something below pcibios_enable_device().
>
> What was the most recent kernel which works?
Looks like vanilla -test2 passes muster. Boots, etc.
Trying to find pci related snippets in -test2-mm1 patch... io_apic_* in
io_}apic.c & mpparse.c, some acpi stuff, drivers/pci/probe.c but that
looks like nothing...
I give up... Yet again... My technical depth seems easily tested in this
arena.
Shawn <[email protected]> wrote:
>
> > What was the most recent kernel which works?
>
> Looks like vanilla -test2 passes muster. Boots, etc.
drat, so I have a dud patch.
The simplest but boringest way to find it is a binary search through the
patches. The `series' file holds the patching order. it'd be painful
without using the scripts though.
You could try randomly reverting nforce2-acpi-fixes.patch.
I fingered the same, but I'll nary have the time till tomorrow eve.
patchectomy, here we come...
On Tue, 2003-07-29 at 00:47, Andrew Morton wrote:
> Shawn <[email protected]> wrote:
> >
> > > What was the most recent kernel which works?
> >
> > Looks like vanilla -test2 passes muster. Boots, etc.
>
> drat, so I have a dud patch.
>
> The simplest but boringest way to find it is a binary search through the
> patches. The `series' file holds the patching order. it'd be painful
> without using the scripts though.
>
> You could try randomly reverting nforce2-acpi-fixes.patch.