lkml.org 
[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Trying to run 2.6.0-test3
From
Date
On Fri, 2003-08-15 at 12:00, Norman Diamond wrote:

> > Have you upgraded to latest modutils package? Modules are implemented
> > quite differently in 2.6.
>
> "seems to be a result of compiling the new modules packages manually at a
> time when I could not persuade the rpm --rebuild command to target the
> correct cpu." Yes, "the new modules packages" meant the new modules
> packages. I did have to ask about this at the beginning of -test1 days. (I
> never had time to try testing a 2.5 kernel but the appearance of 2.6.0-test1
> made it look like testing would become valuable.)

I can't understand why manually compiling modules (make modules) could
cause you problems that "rpm --rebuild" couldn't.

> > > Kernel command line: acpi=off apm=on root=/dev/hda8
> >
> > I suggest you to recompile your kernel with ACPI support to see if it
> > works correctly. Else, recompile it disabling ACPI support and enabling
> > APM support.
>
> Guess why I compiled it without ACPI support and with APM support. Guess
> why my kernel command line has acpi=off apm=on. (Although the command line
> options are redundant with the self-compiled kernel configuration, they are
> necessary when booting a generic kernel. Yes I know that the machine has
> just enough ACPI hooks to cause problems when anyone other than Windows 98
> tries to use ACPI. It's not even recommended to force ACPI on when
> installing Windows 98 on this machine. Windows 2000 blue screens if ACPI is
> forced on. Linux doesn't panic when its default ACPI takes over, but it
> does prevent APM from working.)

If you turn ACPI on, you won't need APM support. Well, ACPI has still
some broken functionality, like S3 states, but usually, you can do
pretty well with ACPI. There was a long time ago since I used APM for
the very last time.

> Fine, but I didn't think I had to worry about that, since it looked like
> Linux already properly detected the fact.
>
> > > PCI: IRQ 0 for device 0000:00:01.2 doesn't match PIRQ mask - try pci=usepirqmask
> > > PCI: IRQ 0 for device 0000:00:0a.0 doesn't match PIRQ mask - try pci=usepirqmask
> > > PCI: IRQ 0 for device 0000:00:0a.1 doesn't match PIRQ mask - try pci=usepirqmask
> >
> > Please, add "pci=usepirqmask" to your kernel command line in GRUB/Lilo.
>
> Oh, that could be it, I just noticed that the second and third occurences
> relate to the PCMCIA slots. May I ask though, what PIRQ mask is it, that is
> failing to be matched? It seems to me that it might be more useful for
> 2.6.0 to do as good a job as 2.4.19 did in figuring out the IRQs, and I
> would like to continue testing this. (Probably I can only spend about one
> day a week on it though.)

To be sincere, I don't know exactly why "pci=usepirqmask" needs to be
used. I'm no hardware expert. But I know that I needed it when I wasn't
using ACPI.

Probably, if you disable APM support and enable ACPI, you won't need to
boot using "pci=usepirqmask".

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.106 / U:7.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site