[PATCHES] 11-pcmciaresource

Thu Mar 25 20:23:36 GMT 2004

On Thu, 25 Mar 2004, Russell King wrote:

> Ok, I've put up the 11-pcmciaresource patch series at the usual
> place (http://pcmcia.arm.linux.org.uk/)  This makes some pretty
> invasive changes into the core PCMCIA code, so it does need some
> thorough testing.

Is my understanding correct that PCMCIA drivers will use resources already
allocated for the bridges (with the exceptions for pcnet_cs and
serial_cs)?  That would be great.

For example, on PowerMAC there is very little I/O space.  It will be very
handy to reuse the I/O space already used by the bridge.

Also, I'll be able to remove the code for setting I/O and memory windows
in plx9052 driver.  Currently it writes directly to the PCI configuration
space, and I don't like it.

I was a bit disappointed when applied the patches, rebooted and found that
the bridge I/O resources are still not reused.  Maybe I don't understand
the goals of the 11-pcmciaresource patches.  Here's my /proc/ioports:

$ cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0100-013f : pcmcia_socket0
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
4000-40ff : PCI CardBus #02
4400-44ff : PCI CardBus #02
4800-48ff : PCI CardBus #06
4c00-4cff : PCI CardBus #06
5000-500f : 0000:00:1f.3
c000-c07f : 0000:01:01.0
c400-c43f : 0000:01:01.0
c800-c83f : 0000:01:07.0
  c800-c83f : e100
d000-d01f : 0000:00:1f.2
  d000-d01f : uhci_hcd
d400-d4ff : 0000:00:1f.5
d800-d83f : 0000:00:1f.5
f000-f00f : 0000:00:1f.1
  f000-f007 : ide0
  f008-f00f : ide1

pcmcia_socket0 resources are not under "PCI CardBus #02" or "PCI CardBus
#06".  The wireless card I'm using can use any starting I/O address (as
long as it's aligned, perhaps).

> The patches are availably separately via the web site, or as
> gzipped or bzipped tarballs:
>
> http://pcmcia.arm.linux.org.uk/patches/11-pcmciaresource.tar.gz
> http://pcmcia.arm.linux.org.uk/patches/11-pcmciaresource.tar.bz2
>
> The patches do have some offset on them, but should otherwise
> apply cleanly.

It would be great of you provided a combined diff.  It's much easier to
check if it applies.  It's also much easier to recover if the patch
doesn't apply.  I think bitkeeper should allow it.  Alternatively, you
could use combinediff from GNU diffutils
(http://www.gnu.org/software/diffutils/).

I created combined diff and put it here:
http://www.red-bean.com/~proski/pcmcia/11-pcmciaresource.diff

The patch introduces a warning:

drivers/pcmcia/rsrc_mgr.c: In function `find_io_region':
drivers/pcmcia/rsrc_mgr.c:603: warning: large integer implicitly truncated
to unsigned type

align has type ioaddr_t, which is 16-bit on all platforms except ARM.  You
cannot assign 0x10000UL to it.

On the machine with Ricoh 476, yenta_socket driver compiled as module:

orinoco_cs - OK
pcnet_cs - OK
ide_cs - kernel panic, possibly unrelated to the patch:

Trying to free nonexistent resource <00000030-0000003f>
hde: , ATA DISK drive
ide2 at 0x030-0x037,0x03e on irq 12
hde: max request size: 128KiB
hde: 0 sectors (0 MB), CHS=0/0/0
hde: INVALID GEOMETRY: 0 PHYSICAL HEADS?
ide-default: hde: Failed to register the driver with ide.c
Kernel panic: ide: default attach failed

serial_cs kernel panic, likely related to the patch:

cs: memory probe 0x0c0000-0x0fffff:
divide error: 0000 [#1]
PREEMPT SMP DEBUG_PAGEALLOC
CPU:    0
EIP:    0060:[<c011962a>]    Not tainted
EFLAGS: 00000202   (2.6.5-rc2-bk5)
EIP is at kernel_map_pages+0x3a/0x48
eax: 000006c0   ebx: 00000001   ecx: 0d1b4000   edx: 00000640
esi: cfeef788   edi: ccbc9000   ebp: cd219bb0   esp: cd219bb0
ds: 007b   es: 007b   ss: 0068
Process cardmgr (pid: 721, threadinfo=cd218000 task=cd062a30)
Stack: cd219bdc c0149312 cd55dc2c 0000cbc9 d0988197 ccbc9000 d0988135 000000d0
       00000015 cd510db8 cd5e5f38 cd219c14 d0988135 ccf0edf8 00000002 cd5e5f20
       00000000 00000000 00000000 ccf00000 d0988219 000000d0 cd5e5f38 cd510db8
Call Trace:
 [<c0149312>] kmem_cache_alloc+0x1b2/0x1f0
 [<d0988197>] read_tuple+0x87/0xa0 [pcmcia_core]
 [<d0988135>] read_tuple+0x25/0xa0 [pcmcia_core]
 [<d0988135>] read_tuple+0x25/0xa0 [pcmcia_core]
 [<d0988219>] pcmcia_validate_cis+0x69/0x1e0 [pcmcia_core]
 [<d098833c>] pcmcia_validate_cis+0x18c/0x1e0 [pcmcia_core]
 [<d098862e>] readable+0x3e/0x80 [pcmcia_core]
 [<d0988797>] cis_readable+0x77/0xb0 [pcmcia_core]
 [<d0988a2e>] do_mem_probe+0x1ae/0x1d0 [pcmcia_core]
 [<c01a1ebf>] ext3_get_inode_loc+0x4f/0x250
 [<d0988ac8>] validate_mem+0x78/0xa0 [pcmcia_core]
 [<d08ca05b>] ds_ioctl+0x26b/0x5c0 [ds]
 [<c01aba3d>] journal_stop+0x25d/0x420
 [<c01aba3d>] journal_stop+0x25d/0x420
 [<c01a2aa0>] ext3_dirty_inode+0x60/0x80
 [<c01a6367>] __ext3_journal_stop+0x27/0x50
 [<c014bfa2>] __pagevec_lru_add+0x132/0x1b0
 [<c01417ed>] generic_file_aio_write_nolock+0x62d/0xbe0
 [<c0119606>] kernel_map_pages+0x16/0x48
 [<c014bae8>] __page_cache_release+0xd8/0x130
 [<c015052e>] zap_pte_range+0x1ae/0x1f0
 [<c019df7d>] ext3_file_write+0x2d/0xc0
 [<c01505b4>] zap_pmd_range+0x44/0x60
 [<c0176870>] do_select+0x1b0/0x2f0
 [<d08c9c5b>] ds_read+0x9b/0x130 [ds]
 [<c0175d88>] sys_ioctl+0x148/0x2e0
 [<c0161a15>] sys_read+0x35/0x60
 [<c01076bf>] syscall_call+0x7/0xb

On a machine with Vadem VG-469, driver i82365:

hostap_cs is OK.
inserting a card supported by pcnet_cs caused several messages like this
in the kernel log:

cs: unable to map card memory!

After that, even hostap_cs fails with the same messages.  Restarting
cardmgr doesn't help.

I'll give more information when I have time.  Some problems may be
unrelated to the patch, so I'll need to separate regressions from the
existing bugs.

-- 
Regards,
Pavel Roskin