Re: Multiple cardbus devices? (RFI)

> : xl0: <3Com 3c575B Fast Etherlink XL> port 0x1000-0x107f mem
> : 0x88000000-0x8800007f,0x88000080-0x880000ff irq 11 at device 0.0 on
> : cardbus0
> 
> That's not 4k! :-(

Ok, if I'm reading this right:
rman_reserve_resource: <I/O memory addresses> request: [0x88000080,
0x880000ff],
 length 0x80, flags 12288, device xl0
considering [0x54000000, 0xffffffff]
truncated region: [0x88001000, 0x88001080]; size 0x81 (requested 0x80)
candidate region: [0x88001080, 0x88001000], size 0x81
splitting region in three parts: [0x54000000, 0x88000fff]; [0x88001000,
0x880010
7f]; [0x88001080, 0xffffffff]
xl0: using memory mapped I/O
rman_reserve_resource: <I/O memory addresses> request: [0x88000000,
0x8800007f],
 length 0x80, flags 12288, device xl0
considering [0x54000000, 0x88000fff]
truncated region: [0x88000000, 0x88000080]; size 0x81 (requested 0x80)
candidate region: [0x88000080, 0x88000000], size 0x81
splitting region in three parts: [0x54000000, 0x87ffffff]; [0x88000000,
0x880000
7f]; [0x88000080, 0x88000fff]

It looks like the patch is indeed working and changing the alignment of
stuff, but xl0 is getting handed 88001000-88001080 for the second memory
range but lying about it in dmesg (and doesn't appreciate having its
memory split up).

I tried moving the alignment flags thing to cardbus_alloc_resources() in
cardbus_cis.c.  That gave me pretty much the same results as my
previous hack -- each separate device starts out on a 4k boundary
(though the sizes are correct now).  It works fine for a while but
eventually both devices just stop working.  Putting heavy load on the
NIC seems to make it happen much sooner.  So far I haven't managed to
find any clues as to why it behaves that way.

Forcing xl0 to use the I/O port range instead of memory mapped I/O
seems to make it last longer before it dies, but it still eventually
gives up and starts timing out.

Craig