Date: Tue, 27 Dec 2005 12:30:14 GMT From: Gleb Smirnoff <glebius@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/76207: [xl] [patch] Null pointer dereference in xl_detach() Message-ID: <200512271230.jBRCUEgb033223@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/76207; it has been noted by GNATS. From: Gleb Smirnoff <glebius@freebsd.org> To: Gene Stark <gene@starkhome.cs.sunysb.edu> Cc: bug-followup@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512271230.jBRCUEgb033223>