ToPIC and 2.6.13

Ryan Underwood nemesis-lists at icequake.net
Mon Sep 5 22:08:04 EDT 2005


Hello,

Since 2.6.13 did not include the ToPIC95 patch, I patched it myself.  I
also included the following patches:
-rw-------  1 nemesis nemesis  723 2005-06-12 17:04 topic.h.diff
Changes to topic97_override().

-rw-------  1 nemesis nemesis  738 2005-06-15 17:09 yenta_socket.diff
Changes to yenta_get_socket_capabilities().

-rw-------  1 nemesis nemesis 6806 2005-06-25 20:57 topic.diff
ToPIC95 ExCA workaround for 16-bit cards.

-rw-------  1 nemesis nemesis 4074 2005-07-24 15:19 yenta_resume.diff
[PATCH 10/11] yenta: free_irq() on suspend.

-rw-------  1 nemesis nemesis 3879 2005-08-17 15:52 multifunc.diff
[PATCH] fix pcmcia_request_irq() for multifunction card

-rw-------  1 nemesis nemesis 4336 2005-08-17 16:06 pci_posting.diff
[PATCH] pcmcia/yenta: avoid PCI write posting problem

-rw-------  1 nemesis nemesis 6477 2005-08-24 05:45 yenta_bridge_control.diff
[RFC, PATCH] pcmcia/yenta: don't mess with bridge control register

Well, the good news is that all of the patches seem to not create any
additional problems.  The bad news is that all of the problems on my
system (Tecra 500CDT, ToPIC95B, Linux 2.6.13) remain ;)

The card is IBM Home & Away 16-bit multifunction modem/eth0 card.  I
only have a VIA USB2 card to test with otherwise, and it has its own
problems at the moment.  (I also have RT2500 wireless card, but no bug
mails are acknowledged if its driver is loaded...)

- nobody cared irq11 still shows when pcmcia-cs is loaded with the card
  inserted.  I dont have the new pcmciautils yet, could this fix the
  problem?  Booting with irqpoll changes nothing except for adding about
  a 15-second system hang immediately before the nobody cared message
  shows up.

  It appears that the IRQ happens while pcnet is being configured and
  thus before the handler is installed?

[__report_bad_irq+49/115] __report_bad_irq+0x31/0x73
[note_interrupt+123/158] note_interrupt+0x7b/0x9e
[__do_IRQ+133/177] __do_IRQ+0x85/0xb1 [do_IRQ+25/36] do_IRQ+0x19/0x24
[common_interrupt+26/32] common_interrupt+0x1a/0x20
[__do_softirq+44/125] __do_softirq+0x2c/0x7d
[do_softirq+34/38] do_softirq+0x22/0x26
[do_IRQ+30/36] do_IRQ+0x1e/0x24
[common_interrupt+26/32] common_interrupt+0x1a/0x20
[pci_bus_write_config_word+49/57] pci_bus_write_config_word+0x31/0x39
[pg0+165938639/1070052352] yenta_set_socket+0x192/0x1b7 [yenta_socket]
[pg0+166530469/1070052352] pcmcia_request_configuration+0xe0/0x309 [pcmcia]
[pg0+166815629/1070052352] pcnet_config+0x2cb/0x5fb [pcnet_cs]
[__getblk+40/84] __getblk+0x28/0x54
[pg0+164780432/1070052352] do_get_write_access+0x361/0x385 [jbd]
[pg0+164995330/1070052352] __ext3_get_inode_loc+0x54/0x204 [ext3]
[pg0+164997307/1070052352] ext3_do_update_inode+0x29e/0x338 [ext3]
[pg0+164998159/1070052352] ext3_mark_iloc_dirty+0x18/0x22 [ext3]
[pg0+164998344/1070052352] ext3_mark_inode_dirty+0x2c/0x36 [ext3]
[pg0+164987577/1070052352] ext3_splice_branch+0x72/0xf2 [ext3]
[pg0+164988173/1070052352] ext3_get_block_handle+0x1d4/0x292 [ext3]
[__find_get_block+139/169] __find_get_block+0x8b/0xa9
[pg0+165861712/1070052352] follow_link+0xa4/0x173 [pcmcia_core]
[pg0+165939355/1070052352] yenta_set_mem_map+0x18b/0x1ca [yenta_socket]
[pg0+165859786/1070052352] set_cis_map+0x88/0xd5 [pcmcia_core]
[pg0+165860123/1070052352] pcmcia_read_cis_mem+0x104/0x16d [pcmcia_core]
[pg0+165862524/1070052352] pccard_get_tuple_data+0x56/0x5f [pcmcia_core]
[pg0+165866779/1070052352] pccard_read_tuple+0x50/0x8b [pcmcia_core]
[pg0+166816678/1070052352] pcnet_event+0x95/0x14f [pcnet_cs]
[pg0+166526986/1070052352] pcmcia_register_client+0x1c8/0x1e7 [pcmcia]
[alloc_netdev+110/124] alloc_netdev+0x6e/0x7c
[pg0+166813838/1070052352] pcnet_attach+0x8e/0xb1 [pcnet_cs]
[kobject_get+18/23] kobject_get+0x12/0x17
[pg0+166523641/1070052352] pcmcia_device_probe+0x40/0x9e [pcmcia]
[driver_probe_device+50/130] driver_probe_device+0x32/0x82
[__device_attach+0/5] __device_attach+0x0/0x5
[bus_for_each_drv+70/108] bus_for_each_drv+0x46/0x6c
[device_attach+71/89] device_attach+0x47/0x59
[__device_attach+0/5] __device_attach+0x0/0x5
[bus_add_device+34/120] bus_add_device+0x22/0x78
[device_add+129/222] device_add+0x81/0xde
[pg0+166524350/1070052352] pcmcia_device_add+0xe7/0x142 [pcmcia]
[pg0+166532653/1070052352] bind_request+0xb3/0x151 [pcmcia]
[pg0+166534926/1070052352] ds_ioctl+0x466/0x544 [pcmcia]
[do_ioctl+73/86] do_ioctl+0x49/0x56
[vfs_ioctl+348/363] vfs_ioctl+0x15c/0x16b
[sys_ioctl+70/99] sys_ioctl+0x46/0x63
[syscall_call+7/11] syscall_call+0x7/0xb


- apm suspend/resume still gives a nonfunctional eth0. I found that
  the modem still works after suspend/resume, so perhaps this is a
  problem with pcnet_cs instead of yenta.

- cardctl status shows:
5V 16-bit PC Card
function 0: [ready], [bat dead], [bat low]
function 1: [busy], [bat dead], [bat low], [req attn]

- I got a new strange message when inserting the card:
"2.6. kernels use pcmciamtd instead of memory_cs.c and do not require
special MTD handling any more."
But this card doesn't have anything to do with memory_cs or MTD.

One problem I had was solved: unresponsive system after removing a card,
I found the cause of it.  I noticed that I was able to scroll up/down in
the console while the system was unresponsive.  So the kernel was not
blocked.  I ran a shell at high priority to watch things, and it turned
out udev/hotplug had about 10 processes awaking at once after the card
was removed, and all are running at -2 (hotplug) or -4 (udev) priority.
That would account for the lag from a normal priority program.  I'm not
sure how to fix this but at least it isn't a bug in the kernel.

Anyway, the card (and sockets) are working fine for the moment and the
mentioned patches check out okay, it just appears that some little bugs
are remaining.  I'm in the process of trying to debug the VIA card
problem, so maybe there will be some more data later from using that
card.

-- 
Ryan Underwood, <nemesis at icequake.net>



More information about the linux-pcmcia mailing list