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
AMI MegaRAID driver compatibility update
For those who are keeping track of this, just a quick update. The 'amr' driver for AMI MegaRAID controllers in -current and available for -stable at http://www.freebsd.org/~msmith/RAID/ami has now been tested with the following AMI MegaRAID controllers: Enterprise 1500 aka 467 (new) Enterprise 1300 aka 434 (new) Enterprise 1200 aka 428 aka Dell PERC Enterprise 1100(?) aka 418 Express 200 aka 466 aka Dell PERC 2/SC It is expected to also work with: Enterprise 1400 (we expect a loan unit in a few days) Enterprise 300 (no loan unit forthcoming) Enterprise 1500-H (RAID 0/1 only) Enterprise 1400-H (RAID 0/1 only) Users have also reported success with various HP NetRAID adapters based on AMI products. Thanks to ASA Computers (www.asacomputers.com) for the loan of the Enterprise 1500 and 1300 controllers that were used in this validation. -- \\ 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: kernel: -mpreferred-stack-boundary=2 ??
It would be better for GCC to force alignment only within those
procedures that need it rather then force all procedures to guarentee
alignment. Then we could have the best of both worlds.
Determining whether it is necessary is non-trivial, you would have to
go through all local variables after stack slots have been allocated.
I'm not certain whether the current code for alignment is useful at
all, since it depends on the alignment being set properly before the
first compiled function is called. If the exec code in the kernel or
the library startup code does not ensure this, it is useless to
maintain relative alignment in userland programs.
In fact, as far as I can tell, this *is* currently broken (I didn't
look too carefully, though, and am too far from my -current box to
test it right now).
Fixing this in the kernel would be a bit messy as it may vary
depending on the sysentvec.
Perhaps crt1.c should call main like this (I can't immediately figure
out whether the stack pointer should be correctly aligned before the
return address is pushed or after the previous stack frame is pushed,
this is assuming the former, s/subl/addl/ would change it).
asm volatile("andl $~15,%%esp;"
"subl $4,%%esp;"
"pushl %3;"
"pushl %2;"
"pushl %1;"
"call main;"
"movl %%eax,(%%esp);"
"call exit"
: "rm" (argc), "rm" (argv), "rm" (env));
Possibly followed by something to indicate to gcc that it shouldn't
generate code to clean up the stack frame (e.g. for (;;) ; ).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Ville-Pertti Keinonen wrote: Perhaps crt1.c should call main like this (I can't immediately figure out whether the stack pointer should be correctly aligned before the return address is pushed or after the previous stack frame is pushed, this is assuming the former, s/subl/addl/ would change it). The stack must be aligned before the return address is pushed: The following C fragment f(1); f(2); Translates to addl $-12,%esp pushl $1 call f addl $16,%esp addl $-12,%esp pushl $2 call f addl $16,%esp This assumes the stack is already aligned, of course. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc_r.so.3 and compat3x
On Tue, 30 Nov 1999, David O'Brien wrote: that it requires libc_r.so.3; unfortunately, compat3x does not contain this lib. Any chance of having it added to compat3x? Yes. The PR is assigned to me, but David already has it on his TODO list. Compat3x is updated late to make sure the latest libraries are in. Until 3.4-REL (when libc*.so.3 will be added to compat3x), you can download the bin.?? files from a 3-STABLE snapshot and grab them. That's kinda hefty for a small port :) I have it marked as broken for -current until the lib is in compat3x. - Chris D. Faulhaber | You can ISO9001 certify the process of System/Network Administrator,| shooting yourself in the foot, so long Reality Check Information, Inc. | as the process is documented and reliably [EMAIL PROTECTED] | produces the proper result. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
The stack must be aligned before the return address is pushed: The following C fragment f(1); f(2); Translates to addl $-12,%esp pushl $1 call f addl $16,%esp addl $-12,%esp pushl $2 call f addl $16,%esp This assumes the stack is already aligned, of course. That just keeps it aligned the same, *relatively*. You have to cause the compiler to generate something that must be aligned to a 16-byte boundary to figure out at which point the stack pointer is assumed to be aligned. In fact, I think that the stack is aligned after pushing the previous frame pointer, a 4-word struct with __attribute__((aligned(16))) is placed starting at -32(%ebp). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Bruce Evans [EMAIL PROTECTED] writes: If the caller has passed a double, then the stack alignment can be determined at compile time and the current subl-type adjustment can be used. Doubles are not aligned when passed as parameters and passing a double doesn't guarantee that there are local variables in the caller that are doubles. Anyhow, I don't think significant changes to gcc should be made in FreeBSD when they only affect code size and performance, suggestions to improve such things should be discussed on the gcc list and adopted through official gcc releases. The defaults can, of course, be changed, but userland code is not that size-critical. In any case, userland code should at least use double-alignment, otherwise you could get poor performance in common floating point code. SSE code is not necessarily worth that much consideration yet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Importing Eric's latest termcap?
I have been contemplating replacing our /usr/src/share/termcap/termcap.src with the latest termcap file maintained by Eric Raymond. His latest version seems 10.2.7 dated 10 March 1999. While our termcap.src has been maintained well by ache and other committers, Eric's version appears more comprehensive. If we are to use it, we shall modify other files in /usr/src/share/termcap as well. Makefile- needs to be updated README - delete, it is obsolete tck - delete reorder - delete, as it is unnecessary anymore The patch is placed in: http://www.freebsd.org/~yokota/termcap.diff.gz cd /usr/src/share/termcap gunzip termcap.diff.gz | patch rm README tck reorder Please have a look and try. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new MAKEDEV and the second CDROM
On 1 Dec, F. Heinrichmeyer wrote: On a freebsd-current box there is a second scsi-cdrom (a cd-writer working fine with cdrecord). I remade the devices with MAKEDEV, everything is new, but there is nothing new like cd1c ... Looking at the source the minor number of cd0c has to be increased by 8. With a second CD-ROM try "/dev/MAKEDEV cd2" (= "make 2 cd devices"). Bye, Alexander. -- I thought I wanted a career, turns out I just wanted paychecks. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report - Nov.
Hi, Doug Rabson wrote: Please see http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp This sounds very promising. I will check out the code soon and try to give feedback. Creating the ACPI namespace is a necessary first step before its possible to do full AML interpreting. Thanks! I'm now preparing also own memory management subsystem to avoid memory leakage in kernel space and to utilize VM efficiently. I believe it should be also one of the important things. In the beginning of this project, we thought merging them to 4.0-RELEASE would be very much exciting, but it seems the codes are still young to merge and 4.0-RELEASE feature freeze is comming soon. We will try another chance, hopefully we have AML interpreter in kernel space at that time. I think we should aim to do most of the work in 5.0 after we branch off 4.0. Perhaps some of it can be back-ported after it become stable in 5.0. OK, we'll do best we can do aiming merge into 5.0-CURRENT. Warner Losh wrote: Cool. This is indeed good news. Keep up the good reports. iwasaki-san to acpi-jp wa domo arigato gozaimasu. We will! We shall keep the reports periodically (maybe monthly? of course depending on our progress). I think that we, folks in Japan, learned enough communications won't hurt anything. # Dou itasimasite :-) Doug Rabson and Warner Losh, thanks for your valuable advice and words of encouragement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A Maior Vitrine de Profissionais do Brasil
Você ainda não faz parte da maior vitrine de profissionais do Brasil? Deixe www.curriculum.com.br trabalhar por você! Cadastre-se gratuitamente e faça como inúmeros outros profissionais. Independente se está ou não empregado, coloque-se a disposição do mercado de trabalho. Este é o futuro. Deixe as portas abertas para novas oportunidades e utilize a força da Internet para trabalhar por você. www.curriculum.com.br sempre trabalhando por você hoje e sempre! 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
Soundblaster 128 PCI
I have a Soundblaster 128 PCI (labeled "MODEL:CT4810") which I can't get to work with newpcm. It shows up like this in dmesg: pci0: unknown card (vendor=0x3274, dev=0x1371) at 10.0 irq 5 and in 'pciconf -l': none0@pci0:10:0:class=0x040100 card=0x13711274 chip=0x13713274 rev=0x06 hdr=0x00 I tried changing ES1371_PCI_ID to 0x13713274 in es137x.c; it'll probe and attach, but any attempt to play sound results in regular "wait source ready timeout 0x10 [0x]" messages. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc_r.so.3 and compat3x
On Wed, Dec 01, 1999 at 07:49:19AM -0500, Chris D. Faulhaber wrote: That's kinda hefty for a small port :) I have it marked as broken for -current until the lib is in compat3x. Why? Many of us still have libc*.so.3 from when that was the version in -CURRENT until a month ago. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 128 PCI
Dag-Erling Smorgrav wrote: I have a Soundblaster 128 PCI (labeled "MODEL:CT4810") which I can't get to work with newpcm. It shows up like this in dmesg: pci0: unknown card (vendor=0x3274, dev=0x1371) at 10.0 irq 5 and in 'pciconf -l': none0@pci0:10:0:class=0x040100 card=0x13711274 chip=0x13713274 rev=0x06 hdr=0x00 I tried changing ES1371_PCI_ID to 0x13713274 in es137x.c; it'll probe and attach, but any attempt to play sound results in regular "wait source ready timeout 0x10 [0x]" messages. What mother board are you using? There have been some reports of the new 1371's not working with non intel chip sets. Asus boards are know to be a problem. Apparently it is a timing bug in the sound card. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] 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: 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 about it strikes me as bad, but I can't quite put my
Re: libc_r.so.3 and compat3x
On Wed, 1 Dec 1999, David O'Brien wrote: On Wed, Dec 01, 1999 at 07:49:19AM -0500, Chris D. Faulhaber wrote: That's kinda hefty for a small port :) I have it marked as broken for -current until the lib is in compat3x. Why? Many of us still have libc*.so.3 from when that was the version in -CURRENT until a month ago. For those who (re)install -current from scratch. I guess I'll add a hook that checks for libc_r.so.3 and inform them that lib is necessary. - Chris D. Faulhaber | You can ISO9001 certify the process of System/Network Administrator, | shooting yourself in the foot, so long Reality Check Information, Inc. | as the process is documented and reliably [EMAIL PROTECTED]| produces the proper result. 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. ... 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
removing enigma(1)
[Donning asbestos underwear] With the FreeBSD 4.0 code freeze fast approaching, are there any compelling reasons to keep enigma (src/usr.bin/enigma) in the source tree? Yes, I know it is a *small* utility, but 1. it provides rather weak encryption, 2. the crypto-distribution is available with stronger encryption, and 3. src/ports/security contains stronger encryption schemes. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing enigma(1)
From: Steve Kargl [EMAIL PROTECTED] Date: Wed, 1 Dec 1999 12:20:19 -0800 (PST) With the FreeBSD 4.0 code freeze fast approaching, are there any compelling reasons to keep enigma (src/usr.bin/enigma) in the source tree? Yes, I know it is a *small* utility, but 1. it provides rather weak encryption, 2. the crypto-distribution is available with stronger encryption, and 3. src/ports/security contains stronger encryption schemes. Maybe relocate it to games :-)/2, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing enigma(1)
With the FreeBSD 4.0 code freeze fast approaching, are there any compelling reasons to keep enigma (src/usr.bin/enigma) in the source tree? How dare you be so anti-bloat, living so close to Redmond?:-) [But otherwise a nice place, Seattle. I used to live there] Enigma is just a format converter at this point and should be left around (after renaming it crypt -- which is how it is known on all Unix versions older than 10 years). Some of us old fogeys still have old encrypted files exhumed, from moldy old files for which crypt is useful (and not just for reburying). crypt should be left around *somewhere*. If you have to throw something out, throw our perl [ducking for cover...:-] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD
On Tue, Nov 30, 1999 at 10:34:56AM -0700, Davec wrote: Yup tried it, didn't work. Got the same error messages (refer to the [LONG] email I sent a few days past. Thanks for the suggestion though. I missed that one apparently. Send it to me in private and I'll see what I can do. Dave -- [EMAIL PROTECTED] PS. I'm about giving up on this. Probably going to just go with ipfw and live with it, or go back to the Oct. 10 snap of -CURRENT. The current -current should work fine in kld mode. I intend to commit a fix for the static part in the coming days. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing enigma(1)
On Wed, Dec 01, 1999 at 04:09:11PM -0500, a little birdie told me
that Bakul Shah remarked
Enigma is just a format converter at this point and should be
left around (after renaming it crypt -- which is how it is
known on all Unix versions older than 10 years). Some of us
Renaming?
[15:25:53] mortis:~
(ttyp9):{838}% ll -i `which crypt` `which enigma`
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/crypt*
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/enigma*
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
FutureSouth Communications |ISPHelp ISP Consulting
"The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: removing enigma(1)
On Wed, Dec 01, 1999 at 03:26:34PM -0600, Matthew D. Fuller wrote:
On Wed, Dec 01, 1999 at 04:09:11PM -0500, a little birdie told me
that Bakul Shah remarked
Enigma is just a format converter at this point and should be
left around (after renaming it crypt -- which is how it is
known on all Unix versions older than 10 years). Some of us
Renaming?
[15:25:53] mortis:~
(ttyp9):{838}% ll -i `which crypt` `which enigma`
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/crypt*
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/enigma*
Ok, so the verdict is that enigma isn't contributing to bloat in
any measurable way whatsoever, because it's merely a hard link to
"crypt", a utility which has long been a useful part of UNIX and
which is required so that people can decrypt their old files (without
needing to spend an hour or so on a brute-force keysearch :-)
- mark
--
Mark Newton Email: [EMAIL PROTECTED] (W)
Network Engineer Email: [EMAIL PROTECTED] (H)
Internode Systems Pty Ltd Desk: +61-8-82232999
"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: removing enigma(1)
On Wed, 1 Dec 1999, Matthew D. Fuller wrote:
On Wed, Dec 01, 1999 at 04:09:11PM -0500, a little birdie told me
that Bakul Shah remarked
Enigma is just a format converter at this point and should be
left around (after renaming it crypt -- which is how it is
known on all Unix versions older than 10 years). Some of us
Renaming?
[15:25:53] mortis:~
(ttyp9):{838}% ll -i `which crypt` `which enigma`
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/crypt*
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/enigma*
Why is that a hard link instead of a symbolic link?
Jamie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
su and traceroute
I just cvsuped to -current right after bind-8.2.2
was merged into the source tree. I noticed two problems. Su won't
work and traceroute gives me the following
traceroute: icmp socket: Operation not
permitted
here are its permissions
-r-sr-xr-x 1 root wheel 12076
Dec 1 14:15 /usr/sbin/traceroute
su just says Sorry and it has the same permissions,
I ran gdb on it and here's a screen shot
253
if (pwd-pw_uid == 0 (gr = getgrgid((gid_t)0)) (gdb)
step255
for (g = gr-gr_mem;; ++g) {(gdb)
step256
if (!*g) {(gdb)
step262
if (strcmp(username, *g) == 0) {(gdb)
step255
for (g = gr-gr_mem;; ++g) {(gdb)
step256
if (!*g) {(gdb)
step262
if (strcmp(username, *g) == 0) {(gdb)
step271
if (*pwd-pw_passwd) {(gdb)
step278
p = skey_getpass("Password:", pwd, 1);(gdb)
stepPassword:279
if (!(!strcmp(pwd-pw_passwd, skey_crypt(p, pwd-pw_passwd, pwd,
1))(gdb)
step292
fprintf(stderr, "Sorry\n");(gdb)
Anyone have any ideas? I am in the wheel
group, but I shouldn't have to be for traceroute and I have this problem for all
users, including new ones that I create.
Re: removing enigma(1)
On Wed, Dec 01, 1999 at 04:36:12PM -0500, a little birdie told me
that James Howard remarked
On Wed, 1 Dec 1999, Matthew D. Fuller wrote:
[15:25:53] mortis:~
(ttyp9):{838}% ll -i `which crypt` `which enigma`
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/crypt*
23155 -r-xr-xr-x 2 root wheel 4980 Oct 29 13:47 /usr/bin/enigma*
Why is that a hard link instead of a symbolic link?
Probably the same reason most (all?) things in the base system that run
linked are hard links:
(ll -i | sort is instructive)
/sbin:
14445 -r-xr-xr-x 2 root wheel 150840 Oct 29 13:46 mount_mfs*
14445 -r-xr-xr-x 2 root wheel 150840 Oct 29 13:46 newfs*
(That's pretty cool, if mildly weird)
14442 -r-xr-xr-x 5 root wheel 59756 Oct 29 13:46 mount_devfs*
14442 -r-xr-xr-x 5 root wheel 59756 Oct 29 13:46 mount_fdesc*
14442 -r-xr-xr-x 5 root wheel 59756 Oct 29 13:46 mount_kernfs*
14442 -r-xr-xr-x 5 root wheel 59756 Oct 29 13:46 mount_procfs*
14442 -r-xr-xr-x 5 root wheel 59756 Oct 29 13:46 mount_std*
/bin:
124 -r-xr-xr-x 2 root wheel 48592 Oct 29 13:43 [*
124 -r-xr-xr-x 2 root wheel 48592 Oct 29 13:43 test*
Sendmail the same way (I can't show it since I have Postfix installed,
but...) (Ah, here's another system:)
430769 -r-sr-xr-x 5 root 7 290816 Nov 18 1998 /usr/bin/mailq*
430769 -r-sr-xr-x 5 root 7 290816 Nov 18 1998 /usr/bin/newaliases*
430769 -r-sr-xr-x 5 root 7 290816 Nov 18 1998 /usr/sbin/sendmail*
etc.
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
FutureSouth Communications |ISPHelp ISP Consulting
"The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Nevermind: su and traceroute
Nevermind, I had nosuid in fstab, totally forgot
about it.
- Original Message -
From:
David W.
Chapman Jr.
To: [EMAIL PROTECTED]
Sent: Wednesday, December 01, 1999 3:54
PM
Subject: su and traceroute
I just cvsuped to -current right after bind-8.2.2
was merged into the source tree. I noticed two problems. Su won't
work and traceroute gives me the following
traceroute: icmp socket: Operation not
permitted
here are its permissions
-r-sr-xr-x 1 root wheel 12076
Dec 1 14:15 /usr/sbin/traceroute
su just says Sorry and it has the same permissions,
I ran gdb on it and here's a screen shot
253
if (pwd-pw_uid == 0 (gr = getgrgid((gid_t)0))
(gdb)
step255
for (g = gr-gr_mem;; ++g) {(gdb)
step256
if (!*g) {(gdb)
step262
if (strcmp(username, *g) == 0) {(gdb)
step255
for (g = gr-gr_mem;; ++g) {(gdb)
step256
if (!*g) {(gdb)
step262
if (strcmp(username, *g) == 0) {(gdb)
step271
if (*pwd-pw_passwd) {(gdb)
step278
p = skey_getpass("Password:", pwd, 1);(gdb)
stepPassword:279
if (!(!strcmp(pwd-pw_passwd, skey_crypt(p, pwd-pw_passwd, pwd,
1))(gdb)
step292
fprintf(stderr, "Sorry\n");(gdb)
Anyone have any ideas? I am in the wheel
group, but I shouldn't have to be for traceroute and I have this problem for
all users, including new ones that I
create.
Re: gcc-2.95.2, jade and freebsd-sgml-documentation
[ I've cc'd FreeBSD-doc on this, in case there's someone there who's solved the problem you're having ] On Sun, Nov 28, 1999 at 05:38:57PM +0100, F. Heinrichmeyer wrote: i tried to make me a new handbook, so i needed jade. But the newest C++ fashion (g++ under current) has changed to fast for this very old 1998 heavily template based source code distribution ;-). I had a lot of problems with const and not const .. and gave up. It is far to much to post here ... A lot of error messages are clearly written 1 to 1 from the ansi standard (yes we finally spent the 18 dollars ...), but something especially about a class "Location" looks really strange. What tool is recommendet to rebuild the documentation? Unfortunately, jade is the tool of choice. I don't run -current, so haven't had a chance to test out jade with the new GCC. However, could you take a look at OpenJade? It's not in the ports tree yet (should you want to submit a port I'll get it committed), and is a continuation of the Jade codebase after the original author (James Clark) moved on to other things. There's an OpenJade home page at http://www.netfolder.com/DSSSL/ and information about the OpenJade CVS repository at http://jade-cvs.avionitek.com/ I hope that helps. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I WOULD LIKE TO JOIN THE MAILING LIST
HELLO MY NAME IS TONY. I HAVE BEEN DOING RESEARCH ON FREEBSD. I'M PLANNING TO SETUP A SYSTEM WITH THIS OS. I WOULD THANK YOU FOR PLACING ME ON YOUR MAILING LIST TO BENEFIT FROM THE EXPERIENCE OTHERS AND EXPERTISE TO MAKE MY TRANSITION SMOOTH.PLEASE USE THIS E-MAIL ADDRESS [EMAIL PROTECTED]. THANK YOU FOR YOUR COOPERATION.
Re: I WOULD LIKE TO JOIN THE MAILING LIST
On Wed, Dec 01, 1999, tonymb wrote: HELLO MY NAME IS TONY. I HAVE BEEN DOING RESEARCH ON FREEBSD. I'M PLANNING TO SETUP A SYSTEM WITH THIS OS. I WOULD THANK YOU FOR PLACING ME ON YOUR MAILING LIST TO BENEFIT FROM THE EXPERIENCE OTHERS AND EXPERTISE TO MAKE MY TRANSITION SMOOTH.PLEASE USE THIS E-MAIL ADDRESS [EMAIL PROTECTED] THANK YOU FOR YOUR COOPERATION. Did you even BOTHER to read the FAQ or ANYTHING at http://www.FreeBSD.org? -- |Chris Costello [EMAIL PROTECTED] |Maintenance-free: When it breaks, it can't be fixed... `--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I WOULD LIKE TO JOIN THE MAILING LIST
On Wednesday, 1 December 1999 at 16:40:33 -0600, tonymb wrote: HELLO MY NAME IS TONY. I HAVE BEEN DOING RESEARCH ON FREEBSD. I'M PLANNING TO SETUP A SYSTEM WITH THIS OS. I WOULD THANK YOU FOR PLACING ME ON YOUR MAILING LIST TO BENEFIT FROM THE EXPERIENCE OTHERS AND EXPERTISE TO MAKE MY TRANSITION SMOOTH.PLEASE USE THIS E-MAIL ADDRESS [EMAIL PROTECTED] THANK YOU FOR YOUR COOPERATION. OK. One thing at a time. 1: Look at the left of your keyboard. You'll find a key marked "Caps Lock". Press it. hello my name is tony. i have been doing research on freebsd. i'm planning to setup a system with this os. i would thank you for placing me on your mailing list to benefit from the experience others and expertise to make my transition smooth.please use this e-mail address [EMAIL PROTECTED] thank you for your cooperation. Ah, that's a little better, isn't it? 2: At the other end you'll find another larger key marked "Enter". Use it approximately every 70 characters, between words: hello my name is tony. i have been doing research on freebsd. i'm planning to setup a system with this os. i would thank you for placing me on your mailing list to benefit from the experience others and expertise to make my transition smooth.please use this e-mail address [EMAIL PROTECTED] thank you for your cooperation. Ah. Now it's readable. You should, of course, use capital letters here and there. 3: Use a web browser and access http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL. It'll tell you which mailing list is for what. I'd suggest -newbies and/or -questions for the start. A bit further down the page you will find instructions for how to subscribe to the mailing list of your choice. While you have the browser running, check out http://www.lemis.com/email.html, which will tell you how to write more legible mail, and http://www.lemis.com/questions.html, which will give you other tips about how to send mail to the FreeBSD mailing lists. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers 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
rpc.umntall does not work with AIX
I am getting the folowing error messages for each mounted directory every time rpc.umntall is being run: Bad MNT RPC: RPC: Remote system error The following is fragment of my /etc/fstab file: # DeviceMountpoint FStype Options DumpPass# kan:/home/ak03 /usr/home/ak03 nfs rw 0 0 tips6:/usr/local/aix/javapkg /usr/local/javapkg nfs rw 0 0 kan there is running AIX 4.2 and tips6 box is HP/UX I am perfectly willing to do any necessary debugging if someone with sufficient NFS knowledge will point me in right direction. -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 01-Dec-99 Time: 17:53:48 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release failure
Has anyone been able to do a make release recently? It seems to break when trying to build jade from the ports, which I think is due to the new compiler import. I saw that there are recent snapshots on current.freebsd.org, which is confusing because I can't get jade to build: ../include/StringOf.h:38: `Stringshort unsigned int::operator [](unsigned int)' has already been declared in `Stringshort unsigned int' ../include/StringOf.h:40: `Stringshort unsigned int::begin()' has already been declared in `Stringshort unsigned int' *** Error code 1 Stop in /usr/ports/textproc/jade/work/jade-1.2.1/lib. *** Error code 1 Stop in /usr/ports/textproc/jade/work/jade-1.2.1. *** Error code 1 Stop in /usr/ports/textproc/jade/work/jade-1.2.1. *** Error code 1 Stop in /usr/ports/textproc/jade. *** Error code 1 Stop in /usr/ports/textproc/jade. *** Error code 1 Stop in /usr/ports/textproc/jade. -- Neal Westfall | mailto:[EMAIL PROTECTED] | http://www.odc.net/~nwestfal "What is today a matter of academic speculation begins tomorrow to move armies and pull down empires. In that second stage, it has gone too far to be combatted; the time to stop it was when it was still a matter of impassionate debate." -- J. Gresham Machen, "Christianity and Culture" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
On Tue, 30 Nov 1999, Brian Fundakowski Feldman wrote: kind of thing I'd rather have. I like the precomputed one (add all argv[] strlen's and malloc that) better, anyway. ..and as soon as warner reviews my revised patch, it will be committed :-) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with ATA
I've updated to the latest -current, and things have gone awry. At boot, the console freezes at the end of the dmesg. The startup process continues, tho, and I can telnet into the box. Then madness ensues. The contents of some files I create disappears, top freezes after listing the processes, never showing cpu usage, c. Switching to the wd drivers fixes everything. Below is the dmesg from the kernel with ATA. The previous working kernel was compiled from Oct. 5 sources. Just ask for any other info you need. Thanks, Greg Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Wed Dec 1 23:24:15 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/MYGENERIC Calibrating clock(s) ... TSC clock: 66644219 Hz, i8254 clock: 1193175 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium/P5 (66.64-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x517 Stepping = 7 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0023d000 - 0x01ffdfff, 31199232 bytes (7617 pages) avail memory = 30502912 (29788K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f0120 bios32: Entry = 0xf146c (c00f146c) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x1450 pnpbios: Found PnP BIOS data at 0xc00f0130 pnpbios: Entry = f:1247 Rev = 1.0 Other BIOS signatures found: ACPI: Intel Pentium detected, installing workaround for F00F bug Creating DISK md0 pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x (0x8000) pci_open(1b): mode1res=0x (0xff01) pci_open(2):mode 2 enable port (0x0cf8) is 0x00 pci_open(2a): mode2res=0x0e (0x0e) pci_open(2a): now trying mechanism 2 pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086) npx0: math processor on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 300751879 bytes/sec bzero() bandwidth = 151125887 bytes/sec pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x (0x8000) pci_open(1b): mode1res=0x (0xff01) pci_open(2):mode 2 enable port (0x0cf8) is 0x00 pci_open(2a): mode2res=0x0e (0x0e) pci_open(2a): now trying mechanism 2 pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086) pcib0: Host to PCI bridge on motherboard found- vendor=0x8086, dev=0x04a3, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x1042, dev=0x1000, revid=0x01 class=01-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base 01f0, size 3 map[14]: type 1, range 32, base 03f4, size 2 found- vendor=0x8086, dev=0x0484, revid=0x00 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 pci0: PCI bus on pcib0 CPU: Pentium, 66MHz, CPU-Memory posting ON Warning: Cache parity disabled! Warning: DRAM parity mask! Cache: 256KB writeback, cache clocks=3-2-2-2/4-2-2-2 Cache flags: cache-all byte-control DRAM: page mode memory clocks=X-4-4-4 (70ns) CPU-PCI: posting ON, burst mode ON, PCI clocks=2-1-1-1 PCI-Memory: posting ON Refresh: RAS#Only BurstOf4 ata-pci0: Unknown PCI IDE controller (generic mode) at device 1.0 on pci0 ata-pci0: Busmastering DMA not supported ata0: iobase=0x01f0 altiobase=0x03f4 ata0: mask=03 status0=50 status1=50 ata0: mask=03 status0=50 status1=50 ata0: devices = 0x3 ata0 at 0x01f0 irq 0 on ata-pci0 isab0: Intel 82378IB PCI to ISA bridge at device 2.0 on pci0 Bus Modes: Bus Park, Resource Lock, Coprocessor errors enabled Keyboard controller: 60h,62h,64h,66h RTC: 70h-77h Port 92: enabled isa0: ISA bus on isab0 Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d psm0: current command byte:0065 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return
minor bug in ee?
I recently noticed that ^v (the scroll down a page command in ee) must be entered twice to scroll down once (i.e. if you hit ^v once it won't do anything, you must hit it again) on a 4.0-CURRENT system. As far as I can recall, this has been happening for as long as I've been tracking -CURRENT (~1 month), and still continues on the system I updated as of Nov. 30. 3-STABLE (as of Dec. 1) doesn't have this problem - it has a simple one-to-one ratio for ^v / scroll down. As far as I can recall, none of the other 3.x or 2.x releases had this problem either. I doubt this is very important - should I file a PR or anything? -Charon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 128 PCI
-On [19991201 20:01], Russell Cattelan ([EMAIL PROTECTED]) wrote: Dag-Erling Smorgrav wrote: I have a Soundblaster 128 PCI (labeled "MODEL:CT4810") which I can't get to work with newpcm. What mother board are you using? There have been some reports of the new 1371's not working with non intel chip sets. Asus boards are know to be a problem. Apparently it is a timing bug in the sound card. The timing bug, is that a PCI bus clock/signal bug which the card has, or an internal timing problem? -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Learn e-mail netiquette: http://www.lemis.com/email.html We do not count a man's years, until he has nothing left to count... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
