Skip site navigation (1)Skip section navigation (2)
Date:      26 Jan 2000 16:45:25 +0000
From:      Chris Webb <chris@arachsys.com>
To:        Will Andrews <andrews@technologist.com>
Cc:        Warner Losh <imp@village.org>, Ken Seggerman <suleyman@echonyc.com>, freebsd-mobile@FreeBSD.ORG
Subject:   Re: Will 3Com 3CCFE574BT work in 4.0 Release?
Message-ID:  <87k8kwok7u.fsf@miranda.arachsys.com>
In-Reply-To: Will Andrews's message of "Wed, 26 Jan 2000 09:58:58 -0500"
References:  <Pine.GSO.4.21.0001221359140.13833-100000@echonyc.com> <200001230347.UAA27217@harmony.village.org> <87wvoxniug.fsf@miranda.arachsys.com> <20000126095858.A413@argon.blackdawn.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Will Andrews <andrews@technologist.com> writes:

> Your problem is probably caused by the fact that in the GENERIC kernel
> (and others), pcic1 likes to use IRQ 11.

I hoped that pcic11 wasn't compiled in to this kernel at all: I
commented it out as the relevant hardware isn't present in the machine.

  [...]
  device          card0
  device          pcic0   at isa? irq 10 port 0x3e0 iomem 0xd0000
  #device         pcic1   at isa? irq 11 port 0x3e2 iomem 0xd4000 disable
  options         PCIC_RESUME_RESET
  [...]

> Even if you disable some IRQs, it seems that it is still used up in the
> kernel. So you have to pick an IRQ that is definitely not used for anything
> at all. For me, on my Dell Inspiron 7000, IRQ 9 works best for the
> 3CCFE574BT. Be sure to test all the IRQs until you get one that works for
> you.

Just been through each of the ostensibly free IRQs (11, 13, 15; there's
a USB controller on IRQ 9) and even tried shifting pcic0 onto IRQ 11 and
putting the 574B on IRQ 10. In each case, I see the same strange
behaviour from ep0. It works absolutely fine up until I do a zzz, but
after resuming, no interrupts get through at all.

> Classic IRQ conflict symptom.

Indeed. I saw the same behaviour at bootup when I accidentally put the
pccard on the same IRQ as the internal soundcard. What's puzzling me is
why this should only start happening after an apm suspend/resume
cycle:

  # ping 192.168.64.2
  PING 192.168.64.2 (192.168.64.2): 56 data bytes
  64 bytes from 192.168.64.2: icmp_seq=0 ttl=255 time=0.502 ms
  64 bytes from 192.168.64.2: icmp_seq=0 ttl=255 time=0.433 ms
  ^C
  --- 192.168.64.2 ping statistics ---
  2 packets transmitted, 2 packets received, 0% packet loss
  round-trip min/avg/max/stddev = 0.433/0.468/0.502/0.034 ms
  # zzz
  #
  ep0: unload
  pccard: card disabled, slot 0
  pccard: card inserted, slot 0
  ata0: resetting devices .. done
  ep0: <3Com 3C574B [...]> at port 0x240-0x25f irq 15 slot 0 on pccard0
  ep0: Ethernet address 00:50:04:fd:94:c9

  # ping 192.168.64.2
  PING 192.168.64.2 (192.168.64.2): 56 data bytes
  [...5s pause...]
  ^C
  --- 192.168.64.2 ping statistics ---
  5 packets transmitted, 0 packets received, 100% packet loss
  #

> > in this machine, nor another available laptop in which to test the 374B.
> You do mean the 574B, right?

Yes; just can't type straight. :-)

Regards,

Chris.
-- 
Chris Webb <chris@arachsys.com>              Tel: +44 1299 404075
Arachsys Internet Services Ltd            Mobile: +44 7801 090045


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87k8kwok7u.fsf>