Re: your mail
Please use subject lines. Thanks. On Mon, 29 Sep 2003, Tomi Vainio - Sun Finland wrote: Dag-Erling Smørgrav writes: An NMI almost certainly indicates a hardware failure. Lucas James writes: It could be a power supply on the way out. I had an old dual P-166 that rebooted misterously until I took out two CD-ROM drives I wanted for another machine. (replaced the power supply, and refitted the CDROMS, and every thing worked ok.) We're already running this system with two power supplys. All old stuff is using old power and 4 new disks were attached to new one. Well this might be the source of problems. I've expressed caution at doing this sorrt of thing before since getting the grounds equallized can be tricky. If the ground levels become unequalized, or worse you get some sort of ground loop going, you could damage your hardware, or cause Wierd Untraceable Problems. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: your mail
In message [EMAIL PROTECTED], Doug White writes: Well this might be the source of problems. I've expressed caution at doing this sorrt of thing before since getting the grounds equallized can be tricky. If the ground levels become unequalized, or worse you get some sort of ground loop going, you could damage your hardware, or cause Wierd Untraceable Problems. ... not to mention escape of magic smoke, and in truly worst case: permanent tax-exemption. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: your mail
Did you look at M. Warner Losh's commits in cbb framework? They seem to be relevant to me. Having a look at it now, seems that yes pccbb.c has been updated and could be the cause of my problems, unfortunately my c is abysmal so bar rolling back to the previous version of this file I'll just have to sit patiently. Thanks for the pointer. Warner, if you're reading this any ideas ? Cheers, -- Mark Sergeant [EMAIL PROTECTED] LookSmart International ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: your mail
Hi, Argh, sorry about loosing the subject. Unfortunately messages from my normal ISP are't getting through to freebsd.org mailng lists (I've contacted them about it) and I'm having to use a crappy uni web mail system) which I'm not used to, so forgot the subject --- reply If you have a second box and a null modem cable, you can set up FreeBSD to use a serial console by unplugging the keyboard. You can then capture the boot output on the second machine and e-mail that out. If it doesn't automatically use the serial console w/o a keyboard, you can do: snip Thanks for the reply. Sadly this isn't going to be possible since my laptop doesn't have a serial port :( I'll have to try the verbose boot, that may give more information. Cheers, Chris Howells To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: your mail
On Wed, 20 Nov 2002, Chris Howells wrote: Hi, On Wednesday 20 November 2002 5:08 pm, Robert Watson wrote: dmesg is a command that dumps the kernel message buffer. You can redirect the output to a file: dmesg fileofchoice Sure. This bit is sufficiently similar to Linux for me to know it :) Problem is, I haven't got 4.7 installed. I want to install 5.0DP2. I can't install 5.0DP2 due to the reboot, and therefore I can't get to a command prompt in order to run dmesg Bit of a chicken egg situation -- if I could install 5.0Dp2 successfully, then I wouldn't need to be sending you the output of dmesg here ;) If you have a second box and a null modem cable, you can set up FreeBSD to use a serial console by unplugging the keyboard. You can then capture the boot output on the second machine and e-mail that out. If it doesn't automatically use the serial console w/o a keyboard, you can do: set console=console in the loader. By default, it uses 9660bps on com1. This is typically how we capture console debug output such as stack traces, debugger stuff, etc, since it doesn't rely on the system remaining up, and doesn't require you to type a lot of stuff in :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: your mail
On Mon, 29 Jul 2002, Tzouris,M wrote: ?? can read questions fine, but won't allow me to answer any of them Bob Many thanks to everybody that send their feedback on this matter. I have now uploaded a text based questionnaire that can be found at: http://www.geocities.com/tzmnlaos/oss/txtquestionnaire.txt there is also a link to it from the web based one (http://www.lse-students.ac.uk/tzouris/oss/). If you prefer, you can feel in this questionnaire and email it or mail it to me instead. Thank you all again, Menelaos. ASCII Ribbon CampaignaccessBob NO HTML/PDF/RTF in e-mail [EMAIL PROTECTED] NO MSWord docs in e-mailAccess Systems, engineers NO attachments in e-mail, *LINUX powered* access is a civil right *#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*# THIS message and any attachments are CONFIDENTIAL and may be privileged. They are intended ONLY for the individual or entity named above. If you are not the intended recipient, Please notify the sender as soon as possible. Please DO NOT READ, COPY, USE, or DISCLOSE this communication to others and DELETE it from your computer systems. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: your mail
On 18:24+0300, May 3, 2002, Radoslav Vasilev wrote: unsuscribe freebsd-current use [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: your mail
On Wed, Nov 29, 2000 at 07:41:14PM -0600, Mike Meyer wrote: Hmm - what's the stupidity? I have a test machine running both -current and -stable Do you have the two FreeBSD installations on the same disk? If so, I'd love to hear how you did it. I spoke with others and they also had problems when trying it sysinstall. I finally did 1 normal install and then booted that and created the 2nd slice, lable, BSD partitions, etc.. by hand and then untared the 2nd installation bits. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
David O'Brien [EMAIL PROTECTED] types: On Wed, Nov 29, 2000 at 07:41:14PM -0600, Mike Meyer wrote: Hmm - what's the stupidity? I have a test machine running both -current and -stable Do you have the two FreeBSD installations on the same disk? If so, I'd love to hear how you did it. I spoke with others and they also had problems when trying it sysinstall. I finally did 1 normal install and then booted that and created the 2nd slice, lable, BSD partitions, etc.. by hand and then untared the 2nd installation bits. Yup, they're both on the same disk. At this point, I've done that two ways. First was with a system already running -current. I just used a 4.1-RELEASE CD and did a standard install from that - carefully ignoring the slice -current was on, except to mount it's swap instead of allocating one on the -RELEASE slice. Upgrading that to -stable went without a hitch. Later, I had a system running -stable, and wanted to create a -current slice on the same system. Like you, I used the running -stable to create, partition and label a second slice. I then nfs-mounted /usr/src and /usr/obj from a -current system onto the -stable system, and did a "make installworld DESTDIR=/new" from that /usr/src. Then a "make distribution" in /usr/src/etc with the appropriate DESTDIR to get those files installed. Finally tweak the new -current's config files from the running -stable system. I think I had more problems because of differences between the /etc/make.conf files on the -current NFS server and the -stable system than anything else. Again, I set things up with one swap partition shared between the two OSs. I've seen the claim that FreeBSD can swap to a Linux swap partition, but never tested it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
In message [EMAIL PROTECTED] "David O'Brien" writes: : Except for stupidity in libdisk(I believe) and thus sysinstall, there is : no, none, zero reason why one cannot have two installations of FreeBSD in : two different slices on the same disk. I've done make buildworld/installworld of both -current and -stable onto one disk in the 3.x/4.0-current time frame. It took a lot of tweaking, but I was able to boot off either one. I think that booteasy didn't boot the second partition properly and I had to play loader games. Sadly, the disk that had this on it one day started thumping, turning it into a rather large paperweight... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] "David O'Brien" writes: : Except for stupidity in libdisk(I believe) and thus sysinstall, there is : no, none, zero reason why one cannot have two installations of FreeBSD in : two different slices on the same disk. I've done make buildworld/installworld of both -current and -stable onto one disk in the 3.x/4.0-current time frame. It took a lot of tweaking, but I was able to boot off either one. I think that booteasy didn't boot the second partition properly and I had to play loader games. Sadly, the disk that had this on it one day started thumping, turning it into a rather large paperweight... FWIW, my system running both -current and -stable off of one disk uses grub for booting, not booteasy. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
On Wed, Nov 29, 2000 at 08:06:14AM +0100, News User wrote: I'm building news machines with two partitions for OSen, to allow me to boot into my choice, where my choice has been FreeBSD-STABLE or FreeBSD-CURRENT to see how the two compare, and if there are any significant improvements in -CURRENT. I know, ``don't do that'' but hey... Except for stupidity in libdisk(I believe) and thus sysinstall, there is no, none, zero reason why one cannot have two installations of FreeBSD in two different slices on the same disk. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
David O'Brien [EMAIL PROTECTED] types: On Wed, Nov 29, 2000 at 08:06:14AM +0100, News User wrote: I'm building news machines with two partitions for OSen, to allow me to boot into my choice, where my choice has been FreeBSD-STABLE or FreeBSD-CURRENT to see how the two compare, and if there are any significant improvements in -CURRENT. I know, ``don't do that'' but hey... Except for stupidity in libdisk(I believe) and thus sysinstall, there is no, none, zero reason why one cannot have two installations of FreeBSD in two different slices on the same disk. Hmm - what's the stupidity? I have a test machine running both -current and -stable (and NetBSD-current, Solaris, Linux, and last and least Win98), and haven't encountered any problems with it. mike -- Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Unix/FreeBSD consultant,email for rates. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Already told him. It is. On Sun, 20 Aug 2000, Tony Fleisher wrote: Not sure if this is related to the recent commit of DEVFS code, but a build of both the GERNERIC kernel and a custom kernel from a very recent (last few hours) cvsup of -current failed during the 'make depend' with an error trying to include "opt_devfs.h". The following following is the ouput from a custom kernel (/usr/local/src/freebsd/src is the base of my src): === md @ - /usr/local/src/freebsd/src/sys machine - /usr/local/src/freebsd/src/sys/i386/include touch opt_mfs.h touch opt_md.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../includ e -I/usr/include /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c:15: opt_devfs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/local/src/freebsd/src/sys/modules/md. *** Error code 1 Commenting out the line: #include "opt_devfs.h" from src/sys/dev/md/md.c got rid of this error, although I am not sure that this is the correct fix. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Someone can this idiot. On Fri, Mar 31, 2000 at 05:11:34PM +0200, Charlie Root wrote: Subject: Mail::Internet test subject This is a test message that was sent by the test suite of Mail::Internet. Testing. one From foo four From bar seven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Actually, I don't think so. I'm not 100% sure, but I think that you end up in the interrupt handler for the card that's going away, but with tty interrupts masked so you can't get back into DDB. If it's a modem card, then you'll have them masked as well. I'm _fairly_ sure that you'll find you're spinning in the card's interrupt handler. Stick a printf or two in there and see for yourself. I guess you must have been right. The card suspend and resumes fine now (apart from resource allocation, but that is a different issue). It seems that the proper deleting of the driver solved the problem of freezing my machine. Cheers, Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. If a USB device all of a sudden disappears, in the middle of a transaction for example, the transaction simply fails. This means that all is needed is proper error checking on all functions that return an error. PCMCIA has the problem that the hardware register you are talking to can disappear on the spot, between 2 outb()s. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Thu, 2 Dec 1999, Nick Hibma wrote: PCMCIA has the problem that the hardware register you are talking to can disappear on the spot, between 2 outb()s. Can't we do something about this using bus_space? This would give us a fair bit of overhead for PCMCIA devices as well as require us to more tightly couple newbus and bus_space (we'd probably want to 'cache' a function pointer to the method to avoid method lookup overhead.) /dirty hack -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Nick Hibma writes: : PCMCIA has the problem that the hardware register you are talking to can : disappear on the spot, between 2 outb()s. Yes. That's why one must poll the device, from time to time, to see if it is gone. Yucky-poo. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 2 Dec 1999, Nick Hibma wrote: : PCMCIA has the problem that the hardware register you are talking to can : disappear on the spot, between 2 outb()s. : : Can't we do something about this using bus_space? This would give us a : fair bit of overhead for PCMCIA devices as well as require us to more : tightly couple newbus and bus_space (we'd probably want to 'cache' a : function pointer to the method to avoid method lookup overhead.) I had the same thought, but w/o a signal or other out of band error communication, I'm not sure how to implement this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 2 Dec 1999, Nick Hibma wrote: : PCMCIA has the problem that the hardware register you are talking to can : disappear on the spot, between 2 outb()s. : : Can't we do something about this using bus_space? This would give us a : fair bit of overhead for PCMCIA devices as well as require us to more : tightly couple newbus and bus_space (we'd probably want to 'cache' a : function pointer to the method to avoid method lookup overhead.) I had the same thought, but w/o a signal or other out of band error communication, I'm not sure how to implement this. You can't without a race. You'd have to poll the hardware before and after every I/O operation to ensure that it was still there. Yick. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : On Tue, Nov 30, 1999 at 04:52:33PM -0700, Warner Losh wrote: : It would help me if you could send me your patches... : : Well, here's all I've got. It's basically just a sloppy version of : what you suggested. OK. This should help. I'll see if I can make it suck less. I'm not sure what to do about drivers that are sleeping in some routine or another when they are ejected, but at least I'll make sure taht teh detach happens at spl0, if it isn't already... The only "right" solution is for us to mandate that people down cards before ejecting them. The physical design of pccards basically gives us no other option. No matter how hard we try to get it "right" for spontaneous removal, we can't win that fight. Not to say we shouldn't try, but people should always hold foremost in their minds the fact that there is no complete solution for this, and the return on investment diminishes rapidly. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
With freeze I meant, freeze. Rock solid. Nothing to be done. Stepping through the code the laptop freezes in the second putb in pcic_disable. As in stepping the assembler to that outb does never return the prompt. Actually, I don't think so. I'm not 100% sure, but I think that you end up in the interrupt handler for the card that's going away, but with tty interrupts masked so you can't get back into DDB. If it's a modem card, then you'll have them masked as well. I'm _fairly_ sure that you'll find you're spinning in the card's interrupt handler. Stick a printf or two in there and see for yourself. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Mike Smith writes: : The only "right" solution is for us to mandate that people down cards : before ejecting them. The physical design of pccards basically gives us : no other option. No matter how hard we try to get it "right" for : spontaneous removal, we can't win that fight. I agree with this. In fact the pccard standard is very careful to state that pccard and cardbus support hot insertion rather than hot swap. I wanted to make it suck less and give poorly written drivers more of a chance to work. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Wed, Dec 01, 1999 at 09:05:38AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Smith writes: : The only "right" solution is for us to mandate that people down cards : before ejecting them. The physical design of pccards basically gives us : no other option. No matter how hard we try to get it "right" for : spontaneous removal, we can't win that fight. I agree with this. In fact the pccard standard is very careful to state that pccard and cardbus support hot insertion rather than hot swap. I wanted to make it suck less and give poorly written drivers more of a chance to work. I think it's pretty much a given, though, that once one puts a pccard in a laptop, one is very unlikely to be happy if one can't remove it without powering down the machine. Particularly given that laptops are much more useful if you can suspend them. So we need something. I would like to see that something along the lines of a method to shut down the card in preparation for removal, regardless of what kind of card it is. In other words, whereas right now I would have to "ifconfig down" if it's an ethernet card, "pppctl close" if it's a serial card, and unmount the filesystem if it's a flash card, I think there needs to be a way to say "shut down slot X" and either have those things happen based on a shutdown script, or make the underlying drivers fail gracefully (although I have difficulty imagining that happening in the case of a read/write mounted filesystem). There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
--- Blind-Carbon-Copy
To: Christopher Masto [EMAIL PROTECTED]
Subject: Re: PCCARD eject freeze (was Re: your mail)
Cc: [EMAIL PROTECTED]
In-reply-to: Your message of "Wed, 01 Dec 1999 12:36:29 EST."
[EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed, 01 Dec 1999 11:28:10 -0700
From: Warner Losh [EMAIL PROTECTED]
[[ Moved to new-bus since this starts to get into what to do on a
detach ]]
Problem summary for the new-bus readers:
device_detach deletes the softc allocated for the device.
Drivers cache copies of softc in their ISRs and other places where
they sleep and count on the cached copy of softc to still be around
when they are woken up. If a pccard is ejected between these points,
these cached copies disappear because the ejection code deletes the
device from the device tree (an as a side effect calls detach, which
frees the softc for the device).
Suspend has a similar problem because it can come in while a
device is sleeping.
In message [EMAIL PROTECTED] Christopher Masto writes:
: I think it's pretty much a given, though, that once one puts a pccard
: in a laptop, one is very unlikely to be happy if one can't remove it
: without powering down the machine. Particularly given that laptops
: are much more useful if you can suspend them. So we need something.
Agreed. Someone else will have to do the something, however, as I'm
not interested in doing work that extensive on the old pccard stuff.
I do not have the time if I'm going to make progress on newcard.
I'm interested in talking about how to do this generically, however,
since this will be one of the problems that I'll run into with
newcard.
: I would like to see that something along the lines of a method to shut
: down the card in preparation for removal, regardless of what kind of
: card it is.
There is some code floating around that would allow one to do a
pccardc power off slot 2
(or something to that effect, I've not used it). That would be a good
generic way of coping. The problem with this, as with the others, is
that the device may be in the middle doing something and needs to be
clear of its critical sections/busy loops. While it usually is in the
old system (and I don't think my code changes this much at all) there
is always a small window for it not to be.
: There are other contexts for the same issues anyway. USB has devices
: that go away suddenly, and it _is_ designed to be hot-removable, so
: people are going to be pulling the plug on network adapters, ZIP
: drives, etc. We need drivers that are capable of going away cleanly,
: or at least without a panic.
Right. That's why I've said things as "devices which support detach"
rather than "pccard devices". This is a generic problem, not limited
to pccard.
While pccard was broken for newbus, the thing that has changed is the
management of the softc. In the old regime it was managed by the
driver. In the new one it is managed by the newbus code.
Consequently, the time of softc's removal from the system has changed
from maybe never to always at detach. Hence a device can no longer
count on softc being there after the detach. Since the device can go
away between any instructions, this may behard to fix. Or it may just
be a matter of putting the pcic device's interrupt into the tty, net,
bio, cam and whatever other device classes are needed so that the
usual locking mechanisms would keep softc from disappearing at
interrupt context/usual critical section protection. It won't help
the actual hardware going away completely while interrupts are
blocked, but at least you want have softc going away in your critical
section. Less that completely satisfactory.
Another problem that some (all?) detachable drivers have is that they
don't keep a list of sleepers on a per instance basis, so when they
detach, they can't terminate the sleepers and bail out with an error
to the sleeping process (which makes these sleeps uninterruptable).
I'm starting to thing that we need a "rundown" or "shutdown" method
that gets called before the detach to give the device a chance to
shutdown gracefully before the executioner comes and removes it from
the tree. However, I think this just enshrines the race w/o actually
fixing it.
A final option would be to allow a sleep in the detach routine. The
driver would keep track of its sleepers. Detach would look like:
sc-gone = 1;
foreach sleeper
terminate sleep
while (sc-refcount)
sleep(sc-refcount);
each sleeper would then do something like
sc-refcount++
sleep()
if (sc-gone) {
sc-refcount--;
wakeup (sc-refcount);
return error;
}
...
sc-refcount--;
return;
With similar code (sans sleep) in the loops in the interrupt
routines.
Something ab
Re: PCCARD eject freeze (was Re: your mail)
On Wed, Dec 01, 1999 at 09:05:38AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Smith writes: : The only "right" solution is for us to mandate that people down cards : before ejecting them. ... I would like to see that something along the lines of a method to shut down the card in preparation for removal, That's what I said above. In other words, whereas right now I would have to "ifconfig down" if it's an ethernet card, "pppctl close" if it's a serial card, and unmount the filesystem if it's a flash card, None of those actions would be adequate. There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. You can't do this with pccard, full stop. It's not a code problem, it's a design problem fundamental to pccards. They could have fixed it with a few extra components, but that would have been too much like hard work. *sigh* -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, 30 Nov 1999, Mike Smith wrote: Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? You should definitely check the delete result, yes. Also, are you calling bus_generic_detach() after deleting the child? I got the impression from Doug that this is required... Nonono. If you call bus_generic_detach from anywhere, call it from ep_detach(). Don't call bus_generic_anything() outside the implementation of a driver. The device_delete_child() call implies a call to device_detach() which *may* use bus_generic_detach() to do some of its work. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, 30 Nov 1999, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? It might fail if the implied device_detach() fails. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Wed, Dec 01, 1999 at 12:02:54PM -0800, Mike Smith wrote: On Wed, Dec 01, 1999 at 09:05:38AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Smith writes: : The only "right" solution is for us to mandate that people down cards : before ejecting them. ... I would like to see that something along the lines of a method to shut down the card in preparation for removal, That's what I said above. The part after the comma was the point of the sentence. That the method to deactivate the card not be specific to the type of card in use, but rather to have a generic mechanism. That's quite possibly exactly what you said, in which case I'm just agreeing with you. :-) In other words, whereas right now I would have to "ifconfig down" if it's an ethernet card, "pppctl close" if it's a serial card, and unmount the filesystem if it's a flash card, None of those actions would be adequate. I meant to illustrate what I felt would be the wrong approach. I think I didn't get my point across, so I will rephrase it. Rather than ending up with a system where you can take the card out if it's "not in use" (where the definition of "not in use" is different for each device), I think it is important that instead the user can say "I want to take the card out of slot X, so make it possible for me to do so or tell me why I can't." There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. You can't do this with pccard, full stop. It's not a code problem, it's a design problem fundamental to pccards. I know that. The point was that lots of new busses ARE designed for hot plugging and unplugging, so it's not just pccard that needs to deal with it. Once the underlying mechanism is established for a driver to safely and cleanly go away, pccard just becomes a matter of telling the driver to go away before touching the eject button. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
: Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? That is a question of what the drivers are supposed to assume after DEVICE_DETACH(self) has been called on them. In USB land it means, bugger off, please, and don't touch that device no more. Even if the driver is still there (unable to detach for some reason, like a CAM SIM that cannot deallocate the bus), the device is gone anyway and the rest of the children should be zapped as well. So printing a message and continuing to delete the rest is your best bet IMHO. The driver itself should do the right thing. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
With freeze I meant, freeze. Rock solid. Nothing to be done. Stepping through the code the laptop freezes in the second putb in pcic_disable. As in stepping the assembler to that outb does never return the prompt. Nick From some very brief testing here, the problem is that the card's interrupt handler hasn't yet been disconected. When you power the card down, you get an edge on the interrupt pin, and then the driver interrupt handler spins madly because the card hardware is gone and thus doesn't behave. If you have an ethernet card, try suspending with just it in the slot and then break into DDB; I'll warrant that you end up inside the relevant driver's interrupt handler. If I'm correct, this is just an ordering issue; the driver has to be shut down _before_ the slot, not afterwards. The system freezes on powering down a PCCARD slot. From memory the location is putb1 called from pcic_disable. The freeze is easy to reproduce, just remove the card. When stepping through the code, even the debugger prompt does not return after the outb for PCIC_POWER on line 698 of pcic.c. This is on CURRENT as of yesterday evening, but other CURRENTs of the last month have the same problem. I've not been able to find a possible culprit in recent commits to pcic.c or pccard.c. Do you have any hint on how to debug this or what version of pcic.c I should take to get rid of this problem? pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 ... pcic: polling, can't alloc 0 pcic: polling, can't alloc 0 pcic0: VLSI 82C146 on isa0 pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 Thanks for the work being done. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
In message [EMAIL PROTECTED] Christopher Masto writes: : I noticed that the "new" code does the power off before the : reset.. dunno if this is significant. Shouldn't be... I gotta get a bouncer system that I can plug a bridge into to see if I can get this problem to happen for me (which i think I will). Damn. I miss my laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Hey, we're getting somewhere. It works, in that it stops the panic. I get the "ed0: unloaded" message, and the machine doesn't panic, but there are still some problems. It seems that device_delete_child is failing (I forgot to print the return code, but it is not zero), and reinserting the card results in "ed0 already exists, using next available unit number", and then the dreaded "driver allocation failed" (presumably the resources have not been freed). Putting in a different kind of card ends up with two children, so it seems that the only part of the delete actually happens. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
Christopher Masto wrote: On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Hey, we're getting somewhere. It works, in that it stops the panic. I get the "ed0: unloaded" message, and the machine doesn't panic, but there are still some problems. It seems that device_delete_child is failing (I forgot to print the return code, but it is not zero), I'll bet Warner meant device_delete_child(pccarddev, kid[i]); up there, and not device_delete_child(pccarddev, kid[0]); Did you try that? -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 02:54:28PM -0800, Frank Mayhar wrote:
On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote:
pccarddev = devclass_get_device(pccard_devclass, slt-slot);
device_get_children(pccarddev, kids, nkids)
for (i = 0; i nkids; i++)
device_delete_child(pccarddev, kid[0]);
I'll bet Warner meant
device_delete_child(pccarddev, kid[i]);
up there, and not
device_delete_child(pccarddev, kid[0]);
Did you try that?
Yes, the actual code I used is:
pccarddev = devclass_get_device(pccard_devclass, slt-slotnum);
device_get_children(pccarddev, kids, nkids);
printf("pccard: %d kids\n", nkids);
for (i = 0; i nkids; i++) {
printf("pccard: deleting kid %d\n", i);
if (ret=device_delete_child(pccarddev, kids[i]))
printf("pccard: delete kid %d failed: %d\n", i, ret);
}
It's not quite working. I think I got away ok with the ethernet card
because it wasn't being accessed, but my CDPD card with a running PPP
session pretty reliably still freezes up. Hrm. No, it's not freezing
up, it's a panic, but I'm running X and can't get to it.
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Frank Mayhar writes: : I'll bet Warner meant : device_delete_child(pccarddev, kid[i]); : up there, and not : device_delete_child(pccarddev, kid[0]); : : Did you try that? Yes. He did. Likely won't make a difference here because we don't add more than one child to the pccard slot child. I'll have to take a close look at this when I can get to a system I can crash a few dozen times to see what's going on. The delete_child should remove the instance of the child. Also, when I was having delete_child problems in the past (when I the first few iterations of the pccard code) I was able to ifconfig ed1 when ed0 would go away... Warner "Sir, as of Nov 30, your laptop is still in our Repair facility with not shipment ET, thank you for calling...A" Losh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : It's not quite working. I think I got away ok with the ethernet card : because it wasn't being accessed, but my CDPD card with a running PPP : session pretty reliably still freezes up. Hrm. No, it's not freezing : up, it's a panic, but I'm running X and can't get to it. Then don't do that :-) This sounds like the usual driver access driver memory that isn't there anymore problem. The driver's softc is blown away with the delete, even if it is sleeping somewhere and there is no way to tell it about it. At least that's my wild-ass guess not having the hardware to test it with here at work. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 04:04:40PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? I added a check of the return value. It seemed to be returning 12 (ENOMEM), but I'm not sure if that's real or garbage, since I'm having trouble finding a code path that would return that. And further data on the CDPD card.. removing it while PPP is still running just paniced in sioioctl. However, the delete_child didn't fail for sio, unlike with ed. I'm going to reboot and see if I can successfully remove and reinsert the card if I make sure nothing has sio open at the time. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : I added a check of the return value. It seemed to be returning 12 : (ENOMEM), but I'm not sure if that's real or garbage, since I'm having : trouble finding a code path that would return that. You might want to make ed_pccard_detach return an int and have it return 0. That's likely the problem. : And further data on the CDPD card.. removing it while PPP is still : running just paniced in sioioctl. However, the delete_child didn't : fail for sio, unlike with ed. I'm going to reboot and see if I can : successfully remove and reinsert the card if I make sure nothing has : sio open at the time. Hmmm. The sioioctl tells me that there is the memory problem I alluded to in the previous message.. At least that's my hunch... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
I'm on my way out for dinner, just thought I'd mention the latest experiment results. On Tue, Nov 30, 1999 at 04:19:18PM -0700, Warner Losh wrote: : And further data on the CDPD card.. removing it while PPP is still : running just paniced in sioioctl. However, the delete_child didn't : fail for sio, unlike with ed. I'm going to reboot and see if I can : successfully remove and reinsert the card if I make sure nothing has : sio open at the time. Hmmm. The sioioctl tells me that there is the memory problem I alluded to in the previous message.. At least that's my hunch... I just tried it without the device in use, and it froze solid after: pccard: 1 kids pccard: deleting kid 0 sio3: unload,gone pccard: delete kid 0 failed: 18 pccard: ready to power off pccard: card removed, slot 0 Ho hum. sio_pccard_detach also needs to be fixed to return 0, but I don't think that explains the freeze. Unfortunately, while I can sometimes squeeze in a few minutes to try quick fixes, my current job doesn't leave me with time to get enough clue to really work on this. If you lived in New York, I'd lend you my laptop. :-/ Good luck getting yours back. I have the same model, and desperately hoping I won't also have to deal with Sony's famous customer disservice. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Mike Smith writes: : You should definitely check the delete result, yes. : : Also, are you calling bus_generic_detach() after deleting the child? : I got the impression from Doug that this is required... In the child? device_delete_child() already calls device_detach(child). I can't call anything on the child device after delete_child becuase it is gone (and the memory is freed). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : Ho hum. sio_pccard_detach also needs to be fixed to return 0, but I : don't think that explains the freeze. Unfortunately, while I can : sometimes squeeze in a few minutes to try quick fixes, my current : job doesn't leave me with time to get enough clue to really work : on this. I think i know what is going on. I'll have to see if I can get that bouncer box up tonight. It has -stable on it right now due to previous contracts, but I need -current on it shortly for the newcard code testing (since I think that I'm a few code walk throughs away from hardware testing). It would help me if you could send me your patches... : If you lived in New York, I'd lend you my laptop. :-/ Good luck : getting yours back. I have the same model, and desperately hoping : I won't also have to deal with Sony's famous customer disservice. Nope. I'm in Boulder. If I have trouble getting the bouncer going tonight I'll hit my boss up to borrow his laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 04:52:33PM -0700, Warner Losh wrote:
It would help me if you could send me your patches...
Well, here's all I've got. It's basically just a sloppy version of
what you suggested.
Index: pccard.c
===
RCS file: /usr/local/ncvs/freebsd/src/sys/pccard/pccard.c,v
retrieving revision 1.93
diff -u -r1.93 pccard.c
--- pccard.c1999/11/20 05:01:59 1.93
+++ pccard.c1999/12/01 02:33:52
@@ -177,8 +177,10 @@
disable_slot(struct slot *slt)
{
device_t pccarddev;
+ device_t *kids;
+ int nkids;
struct pccard_devinfo *devi;
- int i;
+ int i, ret;
/*
* Unload all the drivers on this slot. Note we can't
@@ -191,14 +193,26 @@
* driver is accessing the device and it is removed, then
* all bets are off...
*/
- pccarddev = devclass_get_device(pccard_devclass, 0);
- for (devi = slt-devices; devi; devi = devi-next) {
- if (devi-isahd.id_device != 0) {
- device_delete_child(pccarddev, devi-isahd.id_device);
- devi-isahd.id_device = 0;
- }
+ pccarddev = devclass_get_device(pccard_devclass, slt-slotnum);
+ device_get_children(pccarddev, kids, nkids);
+ printf("pccard: %d kids\n", nkids);
+ for (i = 0; i nkids; i++) {
+ printf("pccard: deleting kid %d\n", i);
+ if (ret=device_delete_child(pccarddev, kids[i]))
+ printf("pccard: delete kid %d failed: %d\n", i, ret);
}
+ /* for (devi = slt-devices; devi; devi = devi-next) {
+ printf("pccard: considering delete\n");
+ if (devi-isahd.id_device != 0) {
+ printf("pccard: doing the delete\n");
+ if (device_delete_child(pccarddev, devi-isahd.id_device))
+ printf("pccard: device_delete_child failed\n");
+ devi-isahd.id_device = 0;
+ }
+ }
+ */
+ printf("pccard: ready to power off\n");
/* Power off the slot 1/2 second after removal of the card */
slt-poff_ch = timeout(power_off_slot, (caddr_t)slt, hz / 2);
slt-pwr_off_pending = 1;
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : On Tue, Nov 30, 1999 at 04:52:33PM -0700, Warner Losh wrote: : It would help me if you could send me your patches... : : Well, here's all I've got. It's basically just a sloppy version of : what you suggested. OK. This should help. I'll see if I can make it suck less. I'm not sure what to do about drivers that are sleeping in some routine or another when they are ejected, but at least I'll make sure taht teh detach happens at spl0, if it isn't already... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : Well, here's all I've got. It's basically just a sloppy version of : what you suggested. I've cleaned this up, worked it around, and managed to insert and eject my ep card 5 times in a row on my desktop kludge environment. It even appeared to be working. Don't know if this will work on a real laptop, but it is better than nothing. I specifically didn't set the suspend/resume code, and it is a different code path. I suspect to still see some hangs, but in the 1-2% range not the 100+% range on suspend due to the racing nature of things. I found another problem with the ep/ed driver's detach routines. They called if_down rather than if_detach. This left them in the list of interfaces, but they were really really gone for good at this point, so when the automatic ifconfig that I have on my machine ran, it paniced the system. I've not tried to fix the sc-gone functionality in the drivers that need it. Nor have I tested anything except the pccard ep driver. I'm too tired for that, and I hope I haven't made anything worse. I've committed these changes to -current for your enjoyment. Please let me know if you have problems with them on real hardware. Warner "Pining for the Fjords[*]" Losh [*] This norse word is pronounced "Sony VAIO" around here :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Try sending the command to [EMAIL PROTECTED] Nick On Thu, 29 Jul 1999, Joachim Kuebart wrote: unsubscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
On Thu, 6 May 1999, Tomer Weller wrote: whenever i try to compile KDE software (ports also) i get this error, though packages install fine. i installed KDE from packages, i suspect that's the problem. I didn't see a response to this as I was going through my inbox, so apologies if this has already been answered: What version of FreeBSD are you running, and which compiler? If you're using egcs as your compiler (either running 4.0, or [23].x + egcs port, then you have to compile the KDE dependencies manually using the same compiler or it will not work. In other words, egcs produces C++ code which is not binary-compatible with that produced by gcc (e.g., the package). You can tell whether this is the case by looking at the error log produced by the port configure script. Kris this is from the kmp3 port, but happens with every piece of kde software : checking for KDE... libraries /usr/local/lib, headers /usr/local/include checking for extra includes... no checking for extra libs... no checking for kde headers installed... yes checking for kde libraries installed... configure: error: your system fails at linking a small KDE application! Check, if your compiler is installed correctly and if you have used the same compiler to compile qt and kdelibs as you did use now *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. == Tomer Weller s...@i.am well...@netvision.net.il Drugs are good, and if you do'em pepole think that you're cool, NoFX To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-ports in the body of the message - That suit's sharper than a page of Oscar Wilde witticisms that's been rolled up into a point, sprinkled with lemon juice and jabbed into someone's eye Wow, that's sharp! - Ace Rimmer and the Cat, _Red Dwarf_ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
