I know that there is no hardware problem because the laptop is dual
boot and on Windoze 2000 side, it says new hardware found when I
insert any card. Also the power light comes on for WPC54G (does not
happen for linux).
If I look at dmesg, it looks like it detected the Cardbus bridge:
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
Intel PCIC probe: not found.
Yenta: CardBus bridge found at 0000:00:08.0 [1584:3000]
Yenta: ISA IRQ list 0000, PCI irq17
Socket status: 4d41b401
cs: IO port probe 0x0c00-0x0cff: excluding 0xc00-0xc1f
cs: IO port probe 0x0800-0x08ff: excluding 0x800-0x837 0x840-0x87f
0x898-0x89f
cs: IO port probe 0x0100-0x04ff: excluding 0x3c0-0x3df 0x480-0x48f
0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
The relevant lspci output is:
00:08.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
Subsystem: Uniwill Computer Corp: Unknown device 3000
Flags: bus master, stepping, slow devsel, latency 168, IRQ 17
Memory at 3fff0000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 40000000-403ff000 (prefetchable)
Memory window 1: 40400000-407ff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
Please help!
Amit
> I have a linux certified LC 2420 laptop running linux from scratch (LFS)
> 5.0 and I recently moved to 2.6.0 kernel. I wanted to try a Linksys
> WPC54G on linux to enable wireless networking but I ran into a problem.
> PCMCIA does not seem to work.
Did you compile PCMCIA support into the kernel?
Did you compile/add wireless support?
Did you install the modules-init-tools as needed for the new kernel?
ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/
Get the latest version and read the README, I ran(from non 2.6 kernel);
./configure --prefix=/
make moveold
make
make install
Now translate your old /etc/modules.conf into /etc/modprobe.conf with the
./generate-modprobe.conf script that comes with module-init-tools:
./generate-modprobe.conf /etc/modprobe.conf
I also had to edit the /etc/modprobe.conf file USB aliases to;
alias usb-controller ehci-hcd
alias usb-controller1 uhci-hcd
--
SCO + RICO Act = Justice
Hi! I'm a .sig virus! Copy me to your .sig!
It might be worth trying with a 2.4.23 kernel to see if it behaves the
same. PCMCIA in 2.6.0 is somewhat unstable.
> Yenta: CardBus bridge found at 0000:00:08.0 [1584:3000]
> Yenta: ISA IRQ list 0000, PCI irq17
> Socket status: 4d41b401
This status value is bogus.
> The relevant lspci output is:
> 00:08.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
> Subsystem: Uniwill Computer Corp: Unknown device 3000
> Flags: bus master, stepping, slow devsel, latency 168, IRQ 17
> Memory at 3fff0000 (32-bit, non-prefetchable) [size=4K]
> Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
> Memory window 0: 40000000-403ff000 (prefetchable)
> Memory window 1: 40400000-407ff000
> I/O window 0: 00004000-000040ff
> I/O window 1: 00004400-000044ff
> 16-bit legacy interface ports at 0001
How much memory is in this laptop?
-- Dave
yes
>
> Did you compile/add wireless support?
>
yes even though it is not needed since wpc54g work using windoze
drivers with ndiswrapper only
> Did you install the modules-init-tools as needed for the new kernel?
>
absolutely!
> ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/
>
> Get the latest version and read the README, I ran(from non 2.6 kernel);
>
> ./configure --prefix=/
> make moveold
> make
> make install
>
> Now translate your old /etc/modules.conf into /etc/modprobe.conf with the
> ./generate-modprobe.conf script that comes with module-init-tools:
>
> ./generate-modprobe.conf /etc/modprobe.conf
yes!
will do tomorrow and let you know if 2.6.1 is not out by that time :)
>
> > Yenta: CardBus bridge found at 0000:00:08.0 [1584:3000]
> > Yenta: ISA IRQ list 0000, PCI irq17
> > Socket status: 4d41b401
>
> This status value is bogus.
I suspected so. BTW what is the relevance of the PCIC error?
>
> > The relevant lspci output is:
> > 00:08.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
> > Subsystem: Uniwill Computer Corp: Unknown device 3000
> > Flags: bus master, stepping, slow devsel, latency 168, IRQ 17
> > Memory at 3fff0000 (32-bit, non-prefetchable) [size=4K]
> > Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
> > Memory window 0: 40000000-403ff000 (prefetchable)
> > Memory window 1: 40400000-407ff000
> > I/O window 0: 00004000-000040ff
> > I/O window 1: 00004400-000044ff
> > 16-bit legacy interface ports at 0001
>
> How much memory is in this laptop?
>
1GB. I have highmem of 4G enabled in the kernel.
> I suspected so. BTW what is the relevance of the PCIC error?
None whatsoever: it means you do not have an ISA-PCMCIA bridge.
>> > 00:08.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
>> > Subsystem: Uniwill Computer Corp: Unknown device 3000
>> > Flags: bus master, stepping, slow devsel, latency 168, IRQ 17
>> > Memory at 3fff0000 (32-bit, non-prefetchable) [size=4K]
>> How much memory is in this laptop?
> 1GB. I have highmem of 4G enabled in the kernel.
Bingo. Note the memory address here of 0x3fff000: for some reason,
your bridge's registers were mapped to overlay the top 4K of system
memory.
I remember this sort of problem coming up before and I'd thought it
had been fixed. Aparently not. It is sometimes caused by the BIOS
erroneously reporting a memory size a bit too small; you might check
the memory map information reported in your boot logs.
I don't know enough about the appropriate parts of the kernel to
suggest a fix, unfortunately. You should report the bug to the
linux-kernel mailing list. It is a bug in PCI resource allocation.
-- Dave
> I remember this sort of problem coming up before and I'd thought it
> had been fixed. Aparently not. It is sometimes caused by the BIOS
> erroneously reporting a memory size a bit too small; you might check
> the memory map information reported in your boot logs.
I checked on this and both 2.4.23 and 2.6.0 contain code to prevent
this from happening. Can you double check that you are actually
running the kernel you think you're running (use 'uname -a')?
-- Dave
Just did it. I tried 2.4.23 and it also did not work. BTW the output
of cat /proc/iomem is below. According to it system RAM ends at
3ffeffff and yenta_socket begins at 3fff0000, i.e., no overlap?
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-3ffeffff : System RAM
00100000-002c7c00 : Kernel code
002c7c01-00389dff : Kernel data
3fff0000-3fff0fff : 0000:00:08.0
3fff0000-3fff0fff : yenta_socket
40000000-403fffff : PCI CardBus #02
40400000-407fffff : PCI CardBus #02
c5b00000-d5cfffff : PCI Bus #01
c8000000-cfffffff : 0000:01:00.0
d5c80000-d5cfffff : 0000:01:00.0
d5e00000-d7efffff : PCI Bus #01
d6000000-d6ffffff : 0000:01:00.0
dbffa000-dbffafff : 0000:00:04.0
dbffa000-dbffafff : sis900
dbffb000-dbffbfff : 0000:00:03.0
dbffc000-dbffcfff : 0000:00:03.1
dbffd000-dbffdfff : 0000:00:03.2
dbffe000-dbffefff : 0000:00:03.3
dbfff000-dbffffff : 0000:00:02.3
dc000000-dfffffff : 0000:00:00.0
> Just did it. I tried 2.4.23 and it also did not work. BTW the output
> of cat /proc/iomem is below. According to it system RAM ends at
> 3ffeffff and yenta_socket begins at 3fff0000, i.e., no overlap?
Well right, that is where the kernel thinks your system RAM ends. Do
you think you actually bought a "1 GB minus 4K" system?
I'm not sure why the kernel is not bumping up the yenta driver memory
to the next 1 MB boundary like it is supposed to: that's the way this
problem was supposed to have been fixed.
You should probably report this on the linux-kernel mailing list.
Maybe someone else will have a good idea. Post your /proc/iomem map
as well as the memory map shown at the start of your boot messages; it
will look something like this:
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
> BIOS-e820: 000000000bff0000 - 000000000bffec00 (ACPI data)
> BIOS-e820: 000000000bffec00 - 000000000c000000 (ACPI NVS)
> BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
I suppose it is possible that your BIOS is actually misconfiguring the
device; in that case the kernel won't notice the problem and will
assume the BIOS did something reasonable.
-- Dave
I just now posted this to link-kernel mailing list. It has the
complete dmesg output. The relevant portions are:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffee0000 - 00000000fff0ffff (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
user-defined physical RAM map:
user: 0000000000000000 - 000000000009fc00 (usable)
user: 000000000009fc00 - 00000000000a0000 (reserved)
user: 00000000000f0000 - 0000000000100000 (reserved)
user: 0000000000100000 - 000000003fff0000 (usable)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000fba70
hm, page 000fb000 reserved twice.
hm, page 000fc000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 262128
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:16
HighMem zone: 32752 pages, LIFO batch:7
DMI 2.3 present.
<snip>
Kernel command line: root=/dev/hda5 ro mem=1048512K
Initializing CPU#0
PID hash table entries: 4096 (order 12: 32768 bytes)
Detected 2390.695 MHz processor.
Console: colour VGA+ 80x25
Memory: 1034492k/1048512k available (1589k kernel code, 13080k
reserved, 717k data, 136k init, 131008k highmem)
> I just now posted this to link-kernel mailing list. It has the
> complete dmesg output. The relevant portions are:
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
> BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
> BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffee0000 - 00000000fff0ffff (reserved)
> BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
> user-defined physical RAM map:
> user: 0000000000000000 - 000000000009fc00 (usable)
> user: 000000000009fc00 - 00000000000a0000 (reserved)
> user: 00000000000f0000 - 0000000000100000 (reserved)
> user: 0000000000100000 - 000000003fff0000 (usable)
?!?!?
> Kernel command line: root=/dev/hda5 ro mem=1048512K
Err. Can you tell me why you are booting with an option that says
that you have 1 GB minus 4K of memory? This mem= option is the cause
of your problem.
-- Dave
This is what Russell King pointed to on the linux kernel mailing list.
I was using grub as the boot loader and grub automatically determines
the RAM size and sticks it in the boot option of the kernel. It so
happens that it invariably gets the memory size wrong and one needs to
compile grub with --disable-auto-linux-mem-opt to stop this
imbecility. Now things work. I got Adaptec 1480A recognized and am
trying to get the linksys wpc54g to work :)
Thanks,
Amit
> This is what Russell King pointed to on the linux kernel mailing list.
> I was using grub as the boot loader and grub automatically determines
> the RAM size and sticks it in the boot option of the kernel. It so
> happens that it invariably gets the memory size wrong and one needs to
> compile grub with --disable-auto-linux-mem-opt to stop this
> imbecility.
Argh!! Someone needs to tell them that it is unacceptable to
automatically override the kernel unless you know what you're
doing is correct!
-- Dave