Bugzilla Bug 192658

When trying to install Gentoo from the minimal CD it is impossible to use the
sky2 driver to get the Marvell Yukon 88E8039 NIC working. After using ``lspci``
it turns out that the vendor ID is not ``11ab`` (as it should be) but ``0001``.
Same thing goes for the Atheros AR5007EG, the verdor ID is not ``168c`` but
again ``0001``.

Reproducible: Always

Steps to Reproduce:
1. Get recent 2.6 kernel (tested with 2.6.19-gentoo-r5 as well as 2.6.22-ARCH)
2. Try to load sky2 (or sk98lin, or skge) kernel driver
3. Wonder why no NICs are detected

Actual Results:  
Nothing happened. The modules did not write any output and no network
interfaces were generated. No output on syslog.

Expected Results:  
Creation of something like eth0.

Strangely enough, when I use the normal Windows VIsta that is installed on that
computer, the PCI product IDs are the same and the vendor IDs are correct. So I
don't think that this is a hardware issue, it has to do something with how the
Linux kernel threatens the devices.

I'll attach the output of ``lcpci``.

Created an attachment (id=131032) [details]
The output of ``lspci``

This is the output of ``lspci`` obtained by the Gentoo minimal install CD.
Running ``lspci`` on the Arch Linux FTP install CD yields the same results.

probably not a userspace problem (certainly not a pciutils problem)

pciutils merely outputs what the kernel tells it

Yes, I agree - this seems to be a kernel probelm. Just tried the Ubuntu 7.04
alternate CD which runs kernel 2.4.20 and that displays the proper vendor IDs.
The product IDs are still unknown but by replacing the ``pci.ids.gz`` file with
an up to date database this is easily solved.
So, networking on Ubuntu 7.04 works out-of-the-box with this card. Question is,
how they did it and how to apply this to Gentoo.

Further testing shows that neither Debian Etch (kernel 2.6.18) nor Debian Lenny
(kernel 2.6.21) have a kernel that detects my vendor IDs correctly. So this is
not likely to be fixed in vanilla kernels.

Trying boot options I found out that booting with ``acpi=off`` works and the
vendor IDs are recognized correctly and the ``sky2`` driver is working. But
disabling ACPI is definitely not an option on a laptop.

I tried also ``pci=noacpi`` which did not change anything as well as disabling
HPET or APIC (tried to disable APIC to circumvent ``MP-BIOS bug 8254 timer not
connected to IO APIX`` error). No improvements with these.

I have found the file <http://www.columbia.edu/~ariel/acpi/acpi_howto.txt>
which lists ACPI related boot options but it could takea long time trying them
all. There is also the x86_64 Documentation about boot options
<http://www.mjmwired.net/kernel/Documentation/x86_64/boot-options.txt> but I
don'tknow how these apply to plain x86.

Created an attachment (id=131059) [details]
dmesg output on normal boot

This is the dmesg output if I boot the system normally from the CD. The NICs do
not work.

Created an attachment (id=131061) [details]
dmesg output on boot with acpi=off

This ist the dmesg output when booting with ACPI disabled. The PCP vendor IDs
are both correct and the sky2 driver loads fine.

(In reply to comment #3)
> Yes, I agree - this seems to be a kernel probelm. Just tried the Ubuntu 7.04
> alternate CD which runs kernel 2.4.20 and that displays the proper vendor IDs.
> The product IDs are still unknown but by replacing the ``pci.ids.gz`` file with
> an up to date database this is easily solved.
> So, networking on Ubuntu 7.04 works out-of-the-box with this card. Question is,
> how they did it and how to apply this to Gentoo.
> 

you meant 2.6.20 right?
doesn the ubuntu livecd boots with acpi=off by default? you can see this with
"cat /proc/cmdline"

I meant 2.6.20 - sorry, too many different kernel versions for me. I don't
think that Ubuntu uses ``acpi=off`` - I can't remember seeing it there.

I was able to find a much nicer option than disabling ACPI altogether. When
using ``pci=bios`` the PCI is probed using some other method (other then
MMCONFIG, which seems to be faulty) thus giving correct results. This solution
is good enough for me, but a non-booting kernel is still a bug (and I think
this report should change status from NEW to ASSIGNED).

I don't know which other ``pci=`` options there are, but ``pci=noacpi`` did not
fix this issue. I suspect it is caused by the MMCONFIG-code, which Ubuntu AFAIR
simply does not use. I saw a boot option called ``pci=nommconf`` which I have
to try at some time.

I just looked into the Ubuntu bug tracker and read that they disabled MMCONFIG
for 7.04 (which is the version that I tried.. I'll take a look at 6.10 to see
whether that works or not). The bug report can be found at
<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/80503>

If it helps I can also provide the output of ``dmidecode``.

Please test this with the latest development kernel, 2.6.23-rc7 as of this
writing. 

You have already found the "pci=bios" boot option to be helpful, can you also
try the "pci=noacpi" option?

Please post your kernel .config and the dmesg output for all three cases: no
pci boot options, with "pci=bios", and with "pci=noacpi".


(BTW, a list of all boot options can be found in
Documentation/kernel-parameters.txt in your kernel source tree).

(In reply to comment #10)
> Please test this with the latest development kernel, 2.6.23-rc7 as of this
> writing. 

I'll do this the week after next week as I'm leaving soon and won't have access
to computers for some days.

> You have already found the "pci=bios" boot option to be helpful, can you also
> try the "pci=noacpi" option?

As I wrote before, the ``pci=noacpi`` (which I tried first) option does not
change anything - the IDs are still wrong.

> (BTW, a list of all boot options can be found in
> Documentation/kernel-parameters.txt in your kernel source tree).

Thanks!

I wasn't able to test 2.6.23-rc7 (or 2.6.23-rc9) yet, but I wanted to give you
an update. I reinstalled my system as amd64 and it did not improve. The problem
is still there. ``pci=bios`` provides a workaround, my computer is currently
runnig with ``pci=conf1`` which is also fine.

Did you get a chance to test with 2.6.23-rc9 yet? Another thing to try, is
upgrade your BIOS to the latest version. Since this occurs for two different
devices, which use different drivers, this may not be a driver/kernel problem.
It seems people on the upstream bug report think so too.

Just downloaded vanilla 2.6.22 + 2.6.23-rc9 patch and compiled it using
genkernel. Will test it in a few moments. Do you have a link to the upstream
bug report?

To the BIOS update thing: Last time I looked on the Samsung web site
(<http://support.samsung.de/modelselect.aspx?modelcode=NP-R60&fileType=FM&language=>),
they were providing only one BIOS file, but since four days there is a new one.
Smart as they are, they packed everything into EXE files.

``file`` output on these:
20070829214344109_WIN_R60P_01YI_00YJ.exe: MS-DOS executable, MZ for MS-DOS
20071003113819625_WIN_R60P_02YI_00YJ.exe: MS-DOS executable, MZ for MS-DOS

This is probably some kind of SFX archive. I guess I'll have to burn a CD with
FreeDOS on it, to unpack and to flash the BIOS. The available versions are
``01YI`` and ``02YI``, I need to check which version my notebook has.

Created an attachment (id=132870) [details]
dmesg of 2.6.23-rc9 without any special workaround options

This is the output of kernel 2.6.23-rc9 running on my laptop. It behaves
exactly as 2.6.22-gentoo-r8: it freezes for about 30 seconds after the line
``ACPI: PCI Root Bridge [PCI0] (0000:00)`` and it does not activate the PIC-E
cards properly. Only improvement is that udev now automatically loads the
ACPI-related modules.

The ``pci=conf1`` workaround works as previously, this is how I am able to post
this comment.

My BIOS version is ``01YI``, so I'll try to figure out how to update to
``02YI`` but I am a little bit concerned because I don't want to damage my new
laptop by a failed update.

Updating could get somewhat tricky, as the remastered FreeDOS 1.0 I created (to
contain the BIOS update file) does not like to start the BIOS update program by
Samsung. Maybe it is no real DOS program, after all. What's the way of updating
a BIOS with no Windows installed, then?

I'll try it with BartPE, but first I have to create a slipstream version of my
XP to update it to SP1 so that BartPE can use it. I hope that'll work
eventually.

After messing around with various XP or Vista based Live-CDs I created my own
based on XP SP2 with BartPE + XPE (hat was the only one with working ACPI
support which is needed for the BIOS update utility by Samsung) and was able to
finally flash my BIOS.

It now runs version ``02YI``, but the problem remains. Both 2.6.22-gentoo-r8
and 2-6-23-rc9 behave the same as before the upgrade (the Fn-special key seems
not to work with all special keys, no idea why it stopped).

The sky2 driver (CONFIG_SKY2) in kernel 2.6.23 should support the Marvell
88E8039 Ethernet Controller. Can you please build a 2.6.23 kernel with that
driver to test and post the .config and the dmesg output? Thanks.

The sky2 driver is already built and running (that is, only with enabled
workarounds) - this comment is send from the Gentoo system running the sky2
driver. But the sky2 driver depends on proper PCI IDs to load. Take a look at
``pci_device_id`` in ``drivers/net/sky2.c``. My Marvell card has the IDs
``11ab:4353`` which corresponds to line 120 in ``sky2.c``:

{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4353) }, /* 88E8039 */

So, the driver runs without problems, once the IDs are correct. I suspect that
if I would hack in the wrong IDs (these that the kernel sets without using
worarounds - ``0001:001c``) the driver would run fine.

But it is not the point of fixing the driver to load when there are broken IDs
but the focus should be getting the kernel to load proper IDs for the devices
without any workarounds.

Ok, just to make sure we're on the same page here: when you've booted into a
2.6.23 kernel, the output of lspci is exactly the same as in your attachment
no.1
(ie. vendor ID is wrong, device ID is correct)? What version of pciutils do you
use?

Created an attachment (id=133411) [details]
Configuration for 2.6.23-rc9

Created an attachment (id=133413) [details]
lspci on 2.6.23-rc9 without workaround options

Created an attachment (id=133414) [details]
lspci on 2.6.23-rc9 with pci=conf1 workaround

Created an attachment (id=133415) [details]
lspci on 2.6.23-rc9 with pci=conf1 workaround (numeric format)

(In reply to comment #20)
> Ok, just to make sure we're on the same page here: when you've booted into a
> 2.6.23 kernel, the output of lspci is exactly the same as in your attachment
> no.1
> (ie. vendor ID is wrong, device ID is correct)? What version of pciutils do you
> use?

Yes, when booting 2.6.23-rc9 the output is exactly the same. I've attached the
output of lspci on 2.6.23-rc9 when booting normally (getting wrong vendor ID)
and when booting with pci=conf1 (getting right vendor ID) in both normal and
numeric formats (so you can see the proper vendor IDs).

I am using pciutils 2.2.4-r3, the newest currently available stable version.

I have the same issues on my hardware.
It is an upstream problem of the kernel, using mmconfig as

I have the same issue here.

It is an upstream change of using mmconfig as the default source for the PCI
configuration. The current workaround is to use pci=conf1.

Marek,

Can you attach the output of lspci -H1

(In reply to comment #28)
> Can you attach the output of lspci -H1

My ``lspci`` from pciutils-2.2.7-r1 does not know any -H1 option. I guess I'll
need to merge an unstable version. I'll try to post the output tomorrow.

I updated to the latest version of pcituils in the Portage tree (currently
2.2.9) and my lspci still does not know any ``-H1`` option. Am I missing
something?

This is being worked on upstream. Can you try booting with pci=nommconf

Options being debated include the blacklisting of this driver for mmconfig.

Can one of you guys please test gentoo-sources-2.6.24

Linus committed a patch that's included in that kernel that may address the
problem:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ad7edfe0490877864dc0312e5f3315ea37fc4b3a

I am happy to report that the gentoo sources 2.6.24 are running fine without
pci=conf1 (thus running with mmconfig) on my system. But since I am the
original tester of this patch that might not be enough for closing this bug.

Thanks for testing, Kai.

If anyone wants to test the above specific patch against 2.6.23, we will
happily backport it after a single success report.

Created an attachment (id=142116) [details]
Patch from kernel 2.6.24 to fix MMCONFIG behaviour

I used this patch and applied it to the gentoo-sources-2.6.23-r6, which made my
PCI-E devices work without the ``pci=conf1`` workaround. So, this is the
success message :)

Thanks for testing, reopening bug for 2.6.23-rx inclusion.

I also tested the patch in the gentoo sources 2.6.23 before it went into
2.6.24.

Fixed in gentoo-sources-2.6.23-r7 (genpatches-2.6.23-8), thanks for testing