kern/76207: [xl] [patch] Null pointer dereference in xl_detach()
Gleb Smirnoff
glebius at freebsd.org
Tue Dec 27 04:30:34 PST 2005
The following reply was made to PR kern/76207; it has been noted by GNATS.
From: Gleb Smirnoff <glebius at freebsd.org>
To: Gene Stark <gene at starkhome.cs.sunysb.edu>
Cc: bug-followup at freebsd.org
Subject: Re: kern/76207: [xl] [patch] Null pointer dereference in xl_detach()
Date: Tue, 27 Dec 2005 15:22:34 +0300
Gene,
On Tue, Dec 27, 2005 at 07:13:25AM -0500, Gene Stark wrote:
G> > On Tue, Dec 27, 2005 at 05:46:47AM -0500, Gene Stark wrote:
G> > G> I'm not prepared at this time to replace the existing system on
G> > G> my laptop with 6.0-RELEASE, so I'm afraid I won't be able to provide the
G> > G> requested feedback.
G> >
G> > Is this a temporary or not? If it is, then the PR will remain in its
G> > current state, waiting for you to reply in future. If you don't have
G> > the hardware or can't check this for any other reason, then the PR
G> > should be closed. So, what should I do with the PR?
G>
G> Was any modification ever made to *any* branch as a result of this PR?
G>
G> Look, I spent time on debugging this particular problem because it
G> was important to me (it was crashing my laptop at extremely
G> inopportune times, like when I was about to give a presentation or
G> something). I sent in the PR which contained workarounds, which I
G> have been using since then, at least on the referenced FreeBSD version
G> and maybe through a system update.
G>
G> My hopes in sending in these PRs was to get somebody authoritative
G> (like the author or maintainer of the driver) to look at the problem
G> and hopefully make a suitable change. My personal assessment after
G> working on this particular problem was that the attach/detach
G> sequence for this driver was very crufty in terms of keeping track
G> of what had been initialized and what hadn't, and what needed to be
G> freed and then reallocated. Anybody knowledgeable who reads my PR
G> and studies the driver code a little can see what I am talking about.
G> I didn't have time to rewrite the driver and even if I did, I don't have
G> the energy to argue with the maintainers about what would be the "proper"
G> fix, coding conventions, etc., etc. That's one reason why I didn't commit
G> much when I was a committer.
G>
G> Basically what I'm saying is: I sent the PR because the code needed
G> to be looked at and rewritten. If somebody has done that on or before
G> 6.0-RELEASE, well OK, I'll face up to it when and if I update my
G> laptop to that version. Hopefully it will "just work" at that point.
G> If the same problem is still there, then I'll just be upset that
G> nobody bothered to look at it and I'll be less likely to send in
G> future PRs.
As far as I know no commits were made, that reference your PR. However, the
we had some general problems with detaching interfaces, and many of them
were addressed before 6.0-RELEASE. This touched quite a lot of drivers,
including xl(4).
I'm now working on another xl(4) related PRs and I have acquired a 3Com
PC card to work on them. Meanwhile, I decided to go thru other xl(4) PRs.
And found yours. I see that on my notebook, on FreeBSD 7.0-CURRENT
the card I have now, detaches and attaches without panic:
cardbus1: Resource not specified in CIS: id=18, size=80
xl0: <3Com 3c575C Fast Etherlink XL> port 0x1080-0x10ff mem 0x88000000-0x8800007f,0x88001000-0x8800107f irq 11 at device 0.0 on cardbus1
miibus1: <MII bus> on xl0
tdkphy0: <TDK 78Q2120 media interface> on miibus1
tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:00:86:3d:b2:d9
Trying to mount root from ufs:/dev/ad0s1a
arp: 81.19.64.118 moved from 00:04:76:3b:6d:df to 00:90:27:85:b8:b9 on fxp0
xl0: reset didn't complete
xl0: command never completed!
xl0: command never completed!
xl0: command never completed!
tdkphy0: detached
miibus1: detached
xl0: detached
cardbus1: Resource not specified in CIS: id=14, size=80
cardbus1: Resource not specified in CIS: id=18, size=80
xl0: <3Com 3c575C Fast Etherlink XL> port 0x1080-0x10ff mem 0x88000000-0x8800007f,0x88001000-0x8800107f irq 11 at device 0.0 on cardbus1
miibus1: <MII bus> on xl0
tdkphy0: <TDK 78Q2120 media interface> on miibus1
tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:00:86:3d:b2:d9
xl0: link state changed to DOWN
Here I have just ejected it and pushed back.
I'm interested whether your particular card with your particular notebook
still has problem or not. I do not urge you to do this right now, you can
do it whenever you want and can. But the correct state for this PR is
"feedback" since there is a high probability that the problem is not
existent in modern FreeBSD, and we need confirmation or refuse of this
fact to decide what to do with this PR.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
More information about the freebsd-bugs
mailing list