Bug 41104
| Summary: | Stale comment removal from pccardd(8) | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Hiten Pandya <hiten> |
| Component: | Books & Articles | Assignee: | Warner Losh <imp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | hiten |
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
On 29-Jul-2002 Hiten Pandya wrote: > >>Number: 41104 >>Category: docs >>Synopsis: Stale comment removal from pccardd(8) >>Confidential: no >>Severity: non-critical >>Priority: low >>Responsible: freebsd-doc >>State: open >>Quarter: >>Keywords: >>Date-Required: >>Class: doc-bug >>Submitter-Id: current-users >>Arrival-Date: Sun Jul 28 21:40:01 PDT 2002 >>Closed-Date: >>Last-Modified: >>Originator: Hiten Pandya >>Release: FreeBSD 4.6-STABLE i386 >>Organization: >>Environment: > > Not Applicable. > >>Description: > > The pccardd(8) manual page holds a very stale comment, which notes > some (old) facts about how things could mess up with a driver if a > card was removed; such as freeing the private data structures etc. > > This note is pre-{lkm,kld} times, so it nows needs to be removed. > > NOTE: There is still a note in the BUGS section, about how things > can really fry, if system resources have been allocated, for e.g. > Network Mounted Filesystems; I _explicitly_ did not remove this > comment, as I was not sure about this. > > Please do not hesitate to comment on this patch: > hiten@uk.FreeBSD.org > > Thanks. > > -- Hiten > -- http://www.unixdaemons.com/~hiten Unfortunately using KLD's does not fix this problem and it is still an issue. I can't eject my cardbus rl0 card w/o my laptop locking up for exactly this reason. This patch should not be committed unless Warner (imp@, cc'd) approves. >>Fix: > > Apply this patch to pccard(8), from 'src/'. This patch CAN be > MFC'ed as it does apply to -STABLE releases as well. Heck!, it > applies to any release which can do loadable kernel modules. :-) > > Index: usr.sbin/pccard/pccardd/pccardd.8 > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/pccard/pccardd/pccardd.8,v > retrieving revision 1.26 > diff -u -r1.26 pccardd.8 > --- usr.sbin/pccard/pccardd/pccardd.8 2002/07/14 14:44:49 1.26 > +++ usr.sbin/pccard/pccardd/pccardd.8 2002/07/29 04:15:31 > @@ -110,18 +110,6 @@ > Once a card/driver instance is configured, the resources > bound to that instance are remembered, and if the card is removed > and reinserted, the same driver is allocated. > -The primary reason > -is that once a driver is associated with a card, the > -driver's > -.Fn probe > -routine has been called, and this usually causes driver specific > -data areas to be initialized with the I/O ports or memory resources > -allocated to the card. > -Most drivers are not designed to be > -disassociated from the hardware and then reassociated with different > -parameters. > -This will change significantly when loadable kernel > -modules are supported. > .Pp > SIGHUP causes > .Nm -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ In message: <XFMail.20020729081434.jhb@FreeBSD.org> John Baldwin <jhb@FreeBSD.org> writes: : Unfortunately using KLD's does not fix this problem and it is still an : issue. I can't eject my cardbus rl0 card w/o my laptop locking up for : exactly this reason. This patch should not be committed unless Warner : (imp@, cc'd) approves. Yes, the comments in the pccardd man page are correct (eg, that's why things are they way they are). However, once the underlying problems in the kernel were fixed, pccardd wasn't updated to be less smart about the resources a card uses. Likely it should read: The primary reasons are historical. What happens in NEWCARD with a rl card aren't relevant to this discussion :-) The reason that you can't eject the rl0 card has to do with something else (likely an ISR that doesn't properly terminate when the card is gone or a detach routine that's minorly bogus). Warner On 29-Jul-2002 M. Warner Losh wrote: > In message: <XFMail.20020729081434.jhb@FreeBSD.org> > John Baldwin <jhb@FreeBSD.org> writes: >: Unfortunately using KLD's does not fix this problem and it is still an >: issue. I can't eject my cardbus rl0 card w/o my laptop locking up for >: exactly this reason. This patch should not be committed unless Warner >: (imp@, cc'd) approves. > > Yes, the comments in the pccardd man page are correct (eg, that's why > things are they way they are). However, once the underlying problems > in the kernel were fixed, pccardd wasn't updated to be less smart > about the resources a card uses. Likely it should read: > > The primary reasons are historical. Ah, ok. > What happens in NEWCARD with a rl card aren't relevant to this > discussion :-) The reason that you can't eject the rl0 card has to do > with something else (likely an ISR that doesn't properly terminate > when the card is gone or a detach routine that's minorly bogus). Well, it's the same behavior. :-P The rl(4) driver doesn't allow for devices to go away and gets stuck in a loop spinning forever waiting for a card reset to succeed and the reset keeps failing for obvious reasons. Completely hangs the machine. *sigh* > Warner -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ In message: <XFMail.20020729111003.jhb@FreeBSD.org> John Baldwin <jhb@FreeBSD.org> writes: : : On 29-Jul-2002 M. Warner Losh wrote: : > In message: <XFMail.20020729081434.jhb@FreeBSD.org> : > John Baldwin <jhb@FreeBSD.org> writes: : >: Unfortunately using KLD's does not fix this problem and it is still an : >: issue. I can't eject my cardbus rl0 card w/o my laptop locking up for : >: exactly this reason. This patch should not be committed unless Warner : >: (imp@, cc'd) approves. : > : > Yes, the comments in the pccardd man page are correct (eg, that's why : > things are they way they are). However, once the underlying problems : > in the kernel were fixed, pccardd wasn't updated to be less smart : > about the resources a card uses. Likely it should read: : > : > The primary reasons are historical. : : Ah, ok. : : > What happens in NEWCARD with a rl card aren't relevant to this : > discussion :-) The reason that you can't eject the rl0 card has to do : > with something else (likely an ISR that doesn't properly terminate : > when the card is gone or a detach routine that's minorly bogus). : : Well, it's the same behavior. :-P The rl(4) driver doesn't allow for : devices to go away and gets stuck in a loop spinning forever waiting : for a card reset to succeed and the reset keeps failing for obvious : reasons. Completely hangs the machine. *sigh* Yes. I've seen it succeed for me. any chance you can get me a traceback of where it is happening? Warner On Mon, Jul 29, 2002 at 09:03:26AM -0600, M. Warner Losh wrote the words in effect of: > In message: <XFMail.20020729081434.jhb@FreeBSD.org> > John Baldwin <jhb@FreeBSD.org> writes: > : Unfortunately using KLD's does not fix this problem and it is still an > : issue. I can't eject my cardbus rl0 card w/o my laptop locking up for > : exactly this reason. This patch should not be committed unless Warner > : (imp@, cc'd) approves. > > Yes, the comments in the pccardd man page are correct (eg, that's why > things are they way they are). However, once the underlying problems > in the kernel were fixed, pccardd wasn't updated to be less smart > about the resources a card uses. Likely it should read: > > The primary reasons are historical. Ok. When I submitted the PR, and after a while, Greg Lehey, first asked me, "I removed the explanation, but not the claim". Although, we now already have the so-called "loadable kernel modules", so I think, we would need to move the paragraph down, to an "ISSUES" section, and there it can be marked as "historical". Is that permitted? > What happens in NEWCARD with a rl card aren't relevant to this > discussion :-) The reason that you can't eject the rl0 card has to do > with something else (likely an ISR that doesn't properly terminate > when the card is gone or a detach routine that's minorly bogus). Does this issue happen with all NEWCARD (network) devices? -- Hiten Pandya http://www.unixdaemons.com/~hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@xMach.org PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index In message: <20020729121121.A24715@angelica.unixdaemons.com> Hiten Pandya <hiten@angelica.unixdaemons.com> writes: : On Mon, Jul 29, 2002 at 09:03:26AM -0600, M. Warner Losh wrote the words in effect of: : > In message: <XFMail.20020729081434.jhb@FreeBSD.org> : > John Baldwin <jhb@FreeBSD.org> writes: : > : Unfortunately using KLD's does not fix this problem and it is still an : > : issue. I can't eject my cardbus rl0 card w/o my laptop locking up for : > : exactly this reason. This patch should not be committed unless Warner : > : (imp@, cc'd) approves. : > : > Yes, the comments in the pccardd man page are correct (eg, that's why : > things are they way they are). However, once the underlying problems : > in the kernel were fixed, pccardd wasn't updated to be less smart : > about the resources a card uses. Likely it should read: : > : > The primary reasons are historical. : : Ok. When I submitted the PR, and after a while, Greg Lehey, first asked : me, "I removed the explanation, but not the claim". Although, we now : already have the so-called "loadable kernel modules", so I think, we : would need to move the paragraph down, to an "ISSUES" section, and there : it can be marked as "historical". Is that permitted? Maybe. Assign the PR to me and I'll take a look at how to better document things. : > What happens in NEWCARD with a rl card aren't relevant to this : > discussion :-) The reason that you can't eject the rl0 card has to do : > with something else (likely an ISR that doesn't properly terminate : > when the card is gone or a detach routine that's minorly bogus). : : Does this issue happen with all NEWCARD (network) devices? It should happen with none. It does happen with drivers that are imporperly written, or assume that their hardware can never go away. Warner On Mon, Jul 29, 2002 at 10:15:48AM -0600, M. Warner Losh wrote the words in effect of: > : > Yes, the comments in the pccardd man page are correct (eg, that's why > : > things are they way they are). However, once the underlying problems > : > in the kernel were fixed, pccardd wasn't updated to be less smart > : > about the resources a card uses. Likely it should read: > : > > : > The primary reasons are historical. > : > : Ok. When I submitted the PR, and after a while, Greg Lehey, first asked > : me, "I removed the explanation, but not the claim". Although, we now > : already have the so-called "loadable kernel modules", so I think, we > : would need to move the paragraph down, to an "ISSUES" section, and there > : it can be marked as "historical". Is that permitted? > > Maybe. Assign the PR to me and I'll take a look at how to better > document things. Me != Committer. :-) > It should happen with none. It does happen with drivers that are > imporperly written, or assume that their hardware can never go away. Ah. Understood. -- Hiten Pandya http://www.unixdaemons.com/~hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@xMach.org PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Responsible Changed From-To: freebsd-doc->imp imp@ wants this one. State Changed From-To: open->closed Committed. |
The pccardd(8) manual page holds a very stale comment, which notes some (old) facts about how things could mess up with a driver if a card was removed; such as freeing the private data structures etc. This note is pre-{lkm,kld} times, so it nows needs to be removed. NOTE: There is still a note in the BUGS section, about how things can really fry, if system resources have been allocated, for e.g. Network Mounted Filesystems; I _explicitly_ did not remove this comment, as I was not sure about this. Please do not hesitate to comment on this patch: hiten@uk.FreeBSD.org Thanks. -- Hiten -- http://www.unixdaemons.com/~hiten Fix: Apply this patch to pccard(8), from 'src/'. This patch CAN be MFC'ed as it does apply to -STABLE releases as well. Heck!, it applies to any release which can do loadable kernel modules. :-) Index: usr.sbin/pccard/pccardd/pccardd.8 =================================================================== RCS file: /home/ncvs/src/usr.sbin/pccard/pccardd/pccardd.8,v retrieving revision 1.26 diff -u -r1.26 pccardd.8 --- usr.sbin/pccard/pccardd/pccardd.8 2002/07/14 14:44:49 1.26 +++ usr.sbin/pccard/pccardd/pccardd.8 2002/07/29 04:15:31 @@ -110,18 +110,6 @@ Once a card/driver instance is configured, the resources bound to that instance are remembered, and if the card is removed and reinserted, the same driver is allocated. -The primary reason -is that once a driver is associated with a card, the -driver's -.Fn probe -routine has been called, and this usually causes driver specific -data areas to be initialized with the I/O ports or memory resources -allocated to the card. -Most drivers are not designed to be -disassociated from the hardware and then reassociated with different -parameters. -This will change significantly when loadable kernel -modules are supported. .Pp SIGHUP causes .Nm How-To-Repeat: Visit the pccardd(8) man page.