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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 133411 [details] Configuration for 2.6.23-rc9
Created attachment 133413 [details] lspci on 2.6.23-rc9 without workaround options
Created attachment 133414 [details] lspci on 2.6.23-rc9 with pci=conf1 workaround
Created attachment 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 attachment 142116 [details, diff] 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
