From owner-freebsd-mobile Tue Jun 26 9:39: 3 2001 Delivered-To: freebsd-mobile@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BF92F37B40A; Tue, 26 Jun 2001 09:38:56 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Jun 2001 17:38:56 +0100 (BST) To: imp@freebsd.org Cc: freebsd-mobile@freebsd.org Subject: Pccard hangs in -stable (new problem in pcic.c r1.89.2.6) Date: Tue, 26 Jun 2001 17:38:55 +0100 From: Ian Dowse Message-ID: <200106261738.aa33495@salmon.maths.tcd.ie> Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Warner, Since updating my laptop to a recent -stable from one of the 4.3 RCs, I'm seeing quite a few interrupt storm hangs, even though the pcic is configured with an IRQ: pcic-pci0: at device 12.0 on pci0 pcic0: at port 0x3e0 iomem 0xd0000 irq 7 on isa0 pcic0: management irq 7 pcic0: Polling mode (*) pccard0: on pcic0 (*) I have a local change that enables polling even when in IRQ mode. I finally got around to investigating one of these hangs today. I was able to break into DDB and manually acknowledge the interrupt to bring the machine back to life: call outb(0x3e0, 4) call inb(0x3e1) I then checked the controller registers, and I found that the PCIC_STAT_INT register (0x05) had been reset to 0x0f which means that something had configured it back to IRQ 0, the setting that causes interrupt storms on these controllers. If I changed this register back to 0x7f (IRQ 7), it would be reset to 0x0f almost immediately when a card was next inserted. Diffing the outputs of "pccardc rdreg", I found that the PCIC_CDGC register had been set to 0x02 (PCIC_CNFG_RST_EN, configuration reset enable). Setting this back to zero solved the problem. It looks as if revision 1.89.2.6 of pcic.c introduced a bug that can cause this; it includes the change: @@ -613,6 +664,7 @@ case PCIC_RF5C396: case PCIC_VLSI: case PCIC_IBM_KING: + case PCIC_I82365: switch(slt->pwr.vpp) { default: return(EINVAL); @@ -641,9 +693,9 @@ (sp->controller == PCIC_VG469) || (sp->controller == PCIC_VG465) || (sp->controller == PCIC_VG365)) - setb(sp, 0x2f, 0x03) ; + setb(sp, PCIC_CVSR, PCIC_CVSR_VS); else - setb(sp, 0x16, 0x02); + setb(sp, PCIC_MISC1, PCIC_MISC1_VCC_33); break; case 50: if (sp->controller == PCIC_IBM_KING) { The addition of "case PCIC_I82365" causes the PCIC_I82365 controller case to result in an setb(sp, PCIC_MISC1, PCIC_MISC1_VCC_33); since PCIC_I82365 is not amonge the list of controllers that get to the PCIC_CVSR setb. However, the PCIC_MISC1 register does not exist on the i82365, so this results in setb(sb, 0x16, 0x02); which resets the configuration to the broken polling mode. It looks like this has already been fixed in -current as part of some code reorganisation there. The following patch should avoid the problem: Ian Index: pcic.c =================================================================== RCS file: /home/iedowse/CVS/src/sys/pccard/pcic.c,v retrieving revision 1.89.2.9 diff -u -r1.89.2.9 pcic.c --- pcic.c 2001/05/09 07:29:06 1.89.2.9 +++ pcic.c 2001/06/26 16:29:45 @@ -696,7 +696,8 @@ if ((sp->controller == PCIC_VG468) || (sp->controller == PCIC_VG469) || (sp->controller == PCIC_VG465) || - (sp->controller == PCIC_VG365)) + (sp->controller == PCIC_VG365) || + (sp->controller == PCIC_I82365)) setb(sp, PCIC_CVSR, PCIC_CVSR_VS); else setb(sp, PCIC_MISC1, PCIC_MISC1_VCC_33); @@ -710,7 +711,8 @@ if ((sp->controller == PCIC_VG468) || (sp->controller == PCIC_VG469) || (sp->controller == PCIC_VG465) || - (sp->controller == PCIC_VG365)) + (sp->controller == PCIC_VG365) || + (sp->controller == PCIC_I82365)) clrb(sp, PCIC_CVSR, PCIC_CVSR_VS); else clrb(sp, PCIC_MISC1, PCIC_MISC1_VCC_33); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message