[PATCHES] 11-pcmciaresource

[Russell King]

On Thu, Mar 25, 2004 at 08:23:36PM -0500, Pavel Roskin wrote:
> 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.

No.  Not yet at least.

> 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'd rather not - I think providing the patches in 3 forms is already
sufficient.

> 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.

which explains why I didn't find 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

Can you send me the kernel messages for the case where the patch isn't
applied, along with /proc/ioports?

> 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

I don't think this is related to the patch, unless you can positively
reproduce it.

Although it contains PCMCIA symbols, EIP is in kernel_map_pages() which
is fairly low down in the call trace, which means everything above it
are stale entries.

> 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.

/proc/iomem would be useful for each stage of this.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core