On Sun, Oct 09, 2005 at 05:47:05PM -0400, Joey Hess wrote:
> Grant Grundler wrote:
> > Can you post the entire console boot log someplace?
>
> Here you go. Also, see my other mail to the bug report for some fairly
> damning /proc/ioports stuff.
I looked through the additional /proc/ioport output and I'm not
clear why the change. My own 2.6.14-rc2 kernel on my a500 says:
gsyprf11:~# cat /proc/ioports
00000000-0000ffff : PCI00 Ports
00000040-0000007f : 0000:00:04.1
00000080-000000ff : 0000:00:00.0
00000080-000000ff : tulip
00000100-000001ff : 0000:00:01.0
00000100-000001ff : sym53c8xx
00000200-000002ff : 0000:00:01.1
00000200-000002ff : sym53c8xx
00000300-000003ff : 0000:00:02.0
00000300-000003ff : sym53c8xx
00000400-000004ff : 0000:00:02.1
00000400-000004ff : sym53c8xx
00010000-0001ffff : PCI10 Ports
00020000-0002ffff : PCI20 Ports
00020000-000200ff : 0000:20:00.0
00020100-000201ff : 0000:20:00.0
00030000-0003ffff : PCI30 Ports
00030000-000300ff : 0000:30:02.0
00030000-000300ff : sym53c8xx
00030100-000301ff : 0000:30:02.1
00030100-000301ff : sym53c8xx
Looks very similar to 2.6.8 output. So the 2.6.12 output from
the debian kernel is just wierd. (Maybe compiler/toolchain bug?)
I realize now that the 2.6.12 "cat /proc/ioports" output in this
bug (332962) doesn't list sym53c8xx driver.
Is there maybe something fundemental wrong with module loading?
ie can sym53c8xx driver be loaded?
> http://dilab.debian.net:800/~joey/d-i/logs/hppa/bison-dns-server-d-i-26.log
Unfortunately, this console log isn't that useful. The interesting
stuff wasn't directed to the console (modprobe tulip output) and
much of the boot output was obscured by the bloody "Virtual Front
Panel" (VFP). Can you add "pdcchassis=0" to the kernel boot
command line and try again?
Or capture "dmesg" output once the 2.6.12 Install ISO can get to
a shell prompt. The goal here is to capture any messages spewed
by PCI subsystem during initialization and verify that the
tulip driver only spews driver version and never finds
any devices.
I think the IO Port address is irrelevant to the problem of tulip
driver not finding devices that the PCI subsystem clearly knows about.
IO resource allocation failure seems to be the only case that might
cause tulip_init_one() to silently exit. But then /proc/ioports
doesn't indicate any conflicts.
I have to wonder if willy is on the right track with
PCIBIOS_MIN_IO not being honored. Will look into this
after we get a full console log.
thanks,
grant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
