Re: OpenSSL update
On Fri, 10 Dec 1999, Brian Fundakowski Feldman wrote: Why don't you want libssl, too? If we don't have that, then we'll end up having to install the port for using SSL and there will be redundancy (wasted space) and two copies of OpenSSL to maintain, still. Since it wasn't going to be used immediately it was suggested to leave it out for now. However it doesn't seem feasible anyway. Since I'm flying back home to australia next tuesday, and we have a feature freeze for -current coming up, what I'll probably do is just import all of openssl into the international repository, and enable the build only for people who have defined USA_RESIDENT==NO. When I get back in January I can get the munged version (i.e. w/o RSA sources, optionally building with RSAREF) imported and enabled for US people, as well as solving the binary distribution problem. The alternative, given the feature freeze, seems to be to forgo any kind of enhanced crypto support in 4.x, which would suck. Sound okay to everyone? Sounds great. I hope this means I get to import OpenSSH! Due to the US export stupidity someone else would probably have to import it into internat so the actual code doesn't leave the US, but historically we seem to have allowed non-crypto commits once it's there (e.g. minor changes, etc). Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
On Thu, 9 Dec 1999, Archie Cobbs wrote: Andrzej Bialecki writes: I'd like to know whether we reached some conclusions concerning the naming of sysctl variables created (or related to) KLDs. I know that Linux emulator creates "compat.linux". I don't know if any other module creates sysctls (well, except my SPY module.. :-). So, what is the current thinking? Should we use modules.my_module.whatever, or kld.my_kld.whatever, or just sprinkle the new sysctls randomly over the tree, according to their functions, e.g. kern.my_module_kern_hook net.inet.my_module_inet_hook ... I think the latter. In 'theory' there should be no discernable difference between functionality from a KLD vs. the same functionality compiled directly into the kernel. Yes, assuming that the same functionality CAN be compiled in statically. IMHO the kernel modularity is a laudable goal, and if it works well, there are only few cases when you would want to make a monolithic kernel. IMHO, of course :-) KLD's are just a linking mechanism, and shouldn't have any more significance than that from a usability perspective. Hah. If it were so simple... Let's take the example of a module foo, which provides unique features of bar and baz. They are unrelated to any already existing category. Where they should be hooked up? kernel? machdep? Then these categories will become a messy, amorphic trashcans. Also, it will be difficult to see which sysctls will disappear when the module is unloaded. Also, if we say that modules should register their sysctls in easily discernible place in the tree, we set up a good example for third party vendors, who otherwise will sprinkle their own sysctls all over the tree... You can probably see from the above what is my preference.. ;-) More or less, my question is: how the sysctl tree will look like when _most_ of the kernel will be in modules? Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release broken
Make release in a -current cvsuped just now broke. It looks like the aout directory is not there. Fixed. Thanks. I'm testing as well, so if anything comes up, let me know. Ok, It got a little further. It now dies with during the "Rebuilding dependencies" phase with: -- mkdep -f .depend -a -nostdinc -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -I/usr/obj/usr/src/gnu/usr.bin/cc/c++filt/../cc_tools -I/usr/src/gnu/usr.bin/cc/c++filt/../cc_tools -I/usr/src/gnu/usr.bin/cc/c++filt/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/c++filt/../../../../contrib/gcc/config -DMAIN -DIN_GCC -DVERSION=\"2.95.2\" -I/usr/obj/usr/src/tmp/usr/include /usr/src/gnu/usr.bin/cc/c++filt/../../../../contrib/gcc/cplus-dem.c /usr/src/gnu/usr.bin/cc/c++filt/../../../../contrib/gcc/getopt.c /usr/src/gnu/usr.bin/cc/c++filt/../../../../contrib/gcc/getopt1.c underscore.c cd /usr/src/gnu/usr.bin/cc/c++filt; make _EXTRADEPEND echo c++filt: /usr/obj/usr/src/tmp/usr/lib/libc.a .depend === gnu/usr.bin/cc/doc === gnu/usr.bin/cc/cc1obj make: don't know how to make objc-parse.c. Stop *** Error code 2 -- The reason is that in Makefile.inc1 BMAKE sets -DNO_OBJC (and a lot of others). BMAKE is used to do the cleanup and make the obj dirs, so the /usr/obj/usr/src/gnu/usr.bin/cc/cc1obj dir is never created. To make the dependencies and the rest XMAKE is used and then -DNO_OBJC and friends are not defined... Wipe your /usr/obj dir and do a make world, and you will see. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Flash (was: Re: Sound card support)
Hi .. Under current the flash plugin works with the linux version of Netscape and the linuxelator ... Sound etc, everything works ok ... except for the odd crash of netscape which is normal :) Hmmm. The developers of mozilla are dying to get bug reports http://www.mozilla.org 8) Someone for berkeley.edu last week reported 36 bugs which made the developers very happy ... -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Flash (was: Re: Sound card support)
Hi, On Thu, Dec 09, 1999 at 11:16:58PM +0300, Dmitrij Tejblum wrote: Good luck using it under current. First site you hit quits netscape without reasons... ... yes. I built the port for the first time just yesterday and made the same experience. ...until you drop out of X and see a __sh_getcontext IIRC warning on your console. If you can hack on the flash plugin's Makefile, try add -fno-exceptions there. ... many thanks for the tip. It's up and running. Regards, Andreas P.S.: ... the port's maintainer is cc-ed ... -- : TSE GmbH Neue Medien : Gsf: Arne Reuter: : : Hovestrasse 14: Andreas Braukmann : We do it with : : D-48351 Everswinkel : HRB: 1430, AG WAF : FreeBSD/SMP: :: : Anti-Spam Petition: http://www.politik-digital.de/spam/: : PGP-Key:http://www.tse-online.de/~ab/public-key: : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
On Fri, 10 Dec 1999, Andre Albsmeier wrote:
On Thu, 09-Dec-1999 at 15:02:41 -0800, Alfred Perlstein wrote:
On Thu, 9 Dec 1999, Andre Albsmeier wrote:
...
For better reference, here is the current patch:
I don't have too much time to think about this, argue me this:
Sure, please tell me if you don't want to get CC'ed on this anymore.
I'm sorry if I sounded like that, I didn't mean to. :)
why should I allow a user to print any file on the system?
the race condition is still there.
Right :-(. The file won't be given to the user anymore but he can
print everything. However, there must be a solution for this...
Can someone take a look at this?
Basically, it makes the link to the file, if it can unlink the original
it will then chown the spool file if it can't delete or read the original
then the user didn't have permission and it backs out.
Index: lpr.c
===
RCS file: /home/ncvs/src/usr.sbin/lpr/lpr/lpr.c,v
retrieving revision 1.31
diff -u -r1.31 lpr.c
--- lpr.c 1999/11/30 16:15:22 1.31
+++ lpr.c 1999/12/10 14:09:08
@@ -384,6 +384,46 @@
}
if (sflag)
printf("%s: %s: not linked, copying instead\n", name, arg);
+ if (f) {
+ seteuid(euid);
+ if (link(arg, dfname) == 0) {
+ int ret;
+
+ seteuid(uid);
+ /*
+* if we can access and remove the file without
+* special setuid-ness then allow it.
+*/
+ ret = access(dfname, R_OK);
+ if (ret == 0)
+ ret = unlink(arg);
+ seteuid(euid);
+ if (ret == 0) {
+ /* unlink was successful fixup perms */
+ chown(dfname, userid, getegid());
+ chmod(dfname, S_IRUSR | S_IWUSR | S_IRGRP |
+S_IWGRP);
+ } else {
+ /*
+* the user handed me a file the don't have
+access to,
+* remove it from the spooldir and try other
+methods
+*/
+ unlink(dfname);
+ seteuid(uid);
+ goto nohardlink;
+ }
+ seteuid(uid);
+ if (format == 'p')
+ card('T', title ? title : arg);
+ for (i = 0; i ncopies; i++)
+ card(format, dfname[inchar-2]);
+ card('U', dfname[inchar-2]);
+ card('N', arg);
+ nact++;
+ continue;
+ }
+ seteuid(uid); /* restore old uid */
+ }
+nohardlink:
if ((i = open(arg, O_RDONLY)) 0) {
printf("%s: cannot open %s\n", name, arg);
} else {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make release broken
John Hay wrote: The reason is that in Makefile.inc1 BMAKE sets -DNO_OBJC (and a lot of others). BMAKE is used to do the cleanup and make the obj dirs, so the /usr/obj/usr/src/gnu/usr.bin/cc/cc1obj dir is never created. To make the dependencies and the rest XMAKE is used and then -DNO_OBJC and friends are not defined... I already have a fix for this. The object tree should not be created using BMAKE, but must be created using XMAKE. -- 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: Route table leaks
At 12:17 AM +0100 1999/12/10, Brad Knowles wrote: In -CURRENT, I would say that this could probably be committed, if John feels safe. I am not yet convinced that it should be committed to -STABLE, although things do look good so far. Well, things continue to look good: Fri Dec 10 10:59:55 CET 1999 netstat -ran | wc -l 121 vmstat -m | grep routetbl | grep K routetbl 24634K 35K 40960K 2750 0 16,32,64,128,256 uptime 10:59AM up 16:08, 0 users, load averages: 3.49, 3.83, 3.61 Fri Dec 10 11:00:56 CET 1999 netstat -ran | wc -l 120 vmstat -m | grep routetbl | grep K routetbl 24434K 35K 40960K 2750 0 16,32,64,128,256 uptime 11:00AM up 16:09, 0 users, load averages: 3.41, 3.81, 3.62 Looking at our stats for yesterday on this machine, we came pretty close to setting some new records for volume, and did quite a lot of articles. At this stage, given that this patch has fixed John's problems, that the previous patch appears to have fixed Joe's problems, and that I seem to be running fine after almost a day, I'd feel more comfortable if John decides he wants to commit this patch to -STABLE. When that happens, I'll cvsup rebuild all the machines I can, so that they can all get the benefit of this patch and the other changes that have gone in recently. Thanks! -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Partial disabling of wd functionality (Was: Re: HEADSUP: wd driver will be retired!)
It seems Maxim Sobolev wrote: Peter Jeremy wrote: On 1999-Dec-09 10:19:22 +1100, Maxim Sobolev [EMAIL PROTECTED] wrote: Why do not remove from wd driver support for chipsets already implemented/tested in ata driver? This requires additional developer effort - appropriate changes have to be determined and tested. It's easy to totally remove the old driver, it would be a fair amount of effort to disable the functionality also provided by the new driver, without affecting the other functionality. I'm not talking about disabling all functionality for partcular chips. It would be sufficient to disable in wd DMA/UDMA support for chipsets already supported by ata, which will encourage all users with these chipsets to use ata (while in case of any problems they still will be able to fallback to wd though it would work somewhat slower). When I do my next commit to the ata driver suite, only the Cyrix chipset will be unsupported, and that is AFAIK used in embedded systems, not in ordinary PC's. I've got the docs on the Cyrix, so support for that might actually come too... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SiS 5591 ATA controller and latest -current'
It seems Donn Miller wrote: I rebuilt my kernel on Tuesday or thereabouts with the new ata controller. It worked perfectly with my SiS 5591. But, with the latest cvsup, now the boot hangs and the hard drive is on solid when it gets to the part mounting root on /dev/ad0s1a. Also, my UDMA/33 drive gets probed as a regular DMA drive before the hang occurs. Erhm, there is NO support for the SIS5591 in the official sources, so I dont see how you should have gotten UDMA33 with that, are you sure you havn't applied the experimental patches I posted here to the older kernel ?? I had to boot into kernel.old, which had a slightly older (3 days old) version of the ata driver. Here's the output of dmesg with kernel.old: ad0: FUJITSU MPB3032ATU/2009 ATA-3 disk at ata0 as master ad0: 3093MB (6335280 sectors), 6704 cyls, 15 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 Now, here's the output I get before my machine hangs: ad0: FUJITSU MPB3032ATU/2009 ATA-3 disk at ata0 as master ad0: 3093MB (6335280 sectors), 6704 cyls, 15 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, DMA I used identical kernel config files, and I had these options enabled: options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices Well, this was the same config file that gave me the correct UDMA33 probe previously. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SiS 5591 ATA controller and latest -current'
On Fri, 10 Dec 1999, Soren Schmidt wrote: Erhm, there is NO support for the SIS5591 in the official sources, so I dont see how you should have gotten UDMA33 with that, are you sure you havn't applied the experimental patches I posted here to the older kernel ?? Yes, come to think of it, I did remember applying the patches to the "older", previous kernel. When I cvsup'd the new sources, I didn't apply the patch. Thanks for the info. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: why 'The legacy aout build' was removed from current ?
Chuck Robey wrote: This isn't taking the execution of aout binaries out, just stopping a world build. This is only going to stop 3rd party developers from making a 4.0 aout platform to create *more* aout binaries. They'll probably hang on for dear life on 2.2, just as long as they can. Heh. :-) True enough. But *new* developments won't. What Motoyuki-san is complaining about is that applications that depend on a.out libraries will suffer. Alas, I don't think that's the case, since all these libraries are (or ought to be, anyway) in compat. Looking at copious examples from real life, forcing 3rd party developers to upgrade is a good way to lose 3rd party developers. It just *sounds* like a good way to go. As long as this is a change for building world, and not making changes to the kern/imgact things (so we keep on executing aout binaries) then this is probably the best way to go. OTOH, going the other way around is the reason why we (users) had to deal with things like 1 Mb RAM and 64 Kb segments in the age of 486s, one generation after the introduction of the 80386. As a free operating system supported by volunteer effort, we are interested in driving the hardware to it's limits instead of being limited by the ways we once did things. -- Daniel C. Sobral(8-DCS) who is as social as a wampas [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL update
Kris Kennaway [EMAIL PROTECTED] wrote: I have it building fine, although compiling without RSA seems broken in openssl 0.9.4. Well, it works fine in the OpenBSD tree. You might want to take a look at what's been done there. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MCA support
On Thu, 9 Dec 1999, Rodney W. Grimes wrote: My m77 has weird problems reading the floppy drive. I'm fairly sure this has everything to do with code in the loader/bootstrap that doesn't like the 2.88M drive. I used the 1.2M drive and it works great. I suspect a normal 1.44M drive would be good too. The loader just uses the BIOS; you can't blame it. 8) I can confirm the loader problem on IBM MCA machines with 2.88M drives, and you _CAN_ blame the loader if it does not make the _CORRECT_ calls to the BIOS :-) Well, I stayed up hacking on boot1 last night and couldn't figure anything out. I did manage to get the 'correct' A20 setup switch implemented but that doesn't change anything. Color me confused. Any ideas? -- | 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
Lost PCMCIA sio (was: HEADSUP: wd driver will be retired!)
On Thursday, 9 December 1999 at 8:46:13 -0500, Daniel Eischen wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : Right now, I have no sound (not detected), no USB (panic on removal), : can't use my sio pccard, can't eject my ed pccard, my IDE drives are : taking hours to dump and fsck, and my TV card is missing every other : line if I try to use the (not working anyway) closed caption decoder. I have some patches for the can't eject the network cards from a user that I'm trying out and would then need to get committed to the network layer to properly support if_detach(). What's wrong with your sio pccard? Mine works well enough... Mine hasn't worked since a kernel built from Nov 23 sources. It broke sometime between then and December 4th. Just built a new kernel from todays sources, and still no go. pccardd[47]: driver allocation failed for Motorola(MONTANA 33.6 FAX/MODEM): Device not configured This closely parallels my experience. I used to get: Dec 5 11:57:53 mojave /kernel.old: sio1 at port 0x2e8-0x2ef irq 5 slot 1 on pccard0 Dec 5 11:57:53 mojave /kernel.old: sio1: type 16550A Now I get: Dec 9 20:08:02 mojave pccardd[53]: driver allocation failed for CIRRUS LOGIC 56K MODEM(CL-MD56XX): Device not configured This happened some time towards the end of last month. 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: PNPBIOS vs cs423B codec
[EMAIL PROTECTED] wrote:
Managed to get the sound stuff working on this thinkpad 600e, for anyone
who cares...
Had to update to the most recent bios, and made sure "quick boot" was
disabled (hold down F1 while powering on to get into bios). I removed the
"csa0" device from the kernel config, despite having a CS4610 probed
during boot. Also set up a pcm0 config line of the sort...
device pcm0 at isa? port ? irq 5 drq 1 flags 0x10
% cat /dev/sndstat
FreeBSD Audio Driver (newpcm) Dec 9 1999 17:28:08
Installed devices:
pcm0: SoundBlaster Pro 3.2 at io 0x220 irq 5 drq 0:1 (1/1 channels
duplex)
the relevant PNP boot messages without pcm enabled...
CSC0100: adding io range 0x530-0x537, size=0x8, align=0
CSC0100: adding io range 0x388-0x38b, size=0x4, align=0
CSC0100: adding io range 0x220-0x233, size=0x14, align=0x20
CSC0100: adding irq mask 0x20
CSC0100: adding dma mask 0x2
CSC0100: adding dma mask 0x1
CSC0100: start dependant
pnpbios: handle 14 device ID CSC0100 (0001630e)
...
unknown6: CSC0100 at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq
1,0 on isa0
Hmm.. My CS4236B chip reports as "CSC"
pcm0: CS4236 at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0
Vendor ID CSC0b36 (0x360b630e), Serial Number 0x
PnP Version 1.0, Vendor Version 1
Device Description: CS4236 Audio
Logical Device ID: CSC 0x630e #0
Device Description: WSS/SB
You might try this patch to sys/dev/sound/isa:
Index: mss.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/mss.c,v
retrieving revision 1.37
diff -u -r1.37 mss.c
--- mss.c 1999/12/06 18:26:30 1.37
+++ mss.c 1999/12/10 15:31:49
@@ -1343,6 +1343,7 @@
switch (logical_id) {
case 0x630e: /* CSC */
+ case 0x0001630e: /* CSC0100 */
if (id == 0x3700630e) s = "CS4237";
else if (id == 0x2500630e) s = "CS4235";
else if (id == 0x3600630e) s = "CS4236";
Please try this again with 'options PNPBIOS' and *only* 'device pcm0' with
no 'at isa...' cruft.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lost PCMCIA sio (was: HEADSUP: wd driver will be retired!)
In message [EMAIL PROTECTED] Greg Lehey writes: : This happened some time towards the end of last month. Try my latest fixes. Towards the end of November, I broke sio, but spent a couple of hours last night fixing it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Jeroen Ruigrok/Asmodai wrote: -On [19991209 16:03], Greg Lehey ([EMAIL PROTECTED]) wrote: On Wednesday, 8 December 1999 at 20:23:24 +0100, Brad Knowles wrote: This is -CURRENT. It pains me to say it, but anyone trying to run anything "useful" on -CURRENT gets what they deserve. This is the only place where we can make clean breaks with the past, and as painful as that can be, we simply have to do that occasionally. Next month it'll be -RELEASE. This isn't the time to remove such significant functionality. If it weren't for that, I'd agree with you. Think about that some more. After that it will be 4.1. Nice to give people a driver and then rip it out when 4.1 comes when Soren fixes the last of the things people needed to have into the ata driver. I was already testing the ata driver and even procured some more info for Soren than he already had. Same goes for a bunch of other people. But the opposite goes for a lot of people. People running CURRENT to be cutting edge as in being elite with the latest FreeBSD thus get bitten. I'd say, cut loose the wd driver. (VoxWare removed would be cool too.) If half as much energy was spent adding the missing bits of functionality to the new systems as people have been spending complaining it then we'd be there ages ago. Trying desperately to prolong the agony by keeping the old stuff on life support is counter productive. Damn it people! If you want cyrix busmaster support, then the code is there, it's not all that hard to extract and adapt the cyrix code to ata. If you have got cyrix hardware and can test your work, then even better. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Greg Lehey writes: We're getting off track again: the real issue is that you shouldn't completely replace old drivers with new, better written, less buggy drivers which have significantly less than the full functionality of the old driver. And while that attitude might work for an organization where some PHB type can dictate what people should or shouldn't do, experience has taught us that at some point you draw a line in the sand and force people to concentrate on the path forward. Look at the sound code to see why your proposal doesn't work in our reality. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Peter Wemm writes : I'd say, cut loose the wd driver. (VoxWare removed would be cool too.) If half as much energy was spent adding the missing bits of functionality to the new systems as people have been spending complaining it then we'd be there ages ago. Trying desperately to prolong the agony by keeping the old stuff on life support is counter productive. I can only agree, with all the stuff there is on front of us, the entire of energy people put into defending code which is rotting away is wasted. Please, help Sos fix ATA if you know of a problem. Please, help fix PCCARD if you know of a problem. Please DO SOMETHING PRODUCTIVE, rather than whine. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lost PCMCIA sio (was: HEADSUP: wd driver will be retired!)
On Thu, Dec 09, 1999 at 11:01:16PM -0500, Greg Lehey wrote: pccardd[47]: driver allocation failed for Motorola(MONTANA 33.6 FAX/MODEM): Device not configured This closely parallels my experience. I used to get: Dec 5 11:57:53 mojave /kernel.old: sio1 at port 0x2e8-0x2ef irq 5 slot 1 on pccard0 Dec 5 11:57:53 mojave /kernel.old: sio1: type 16550A Now I get: Dec 9 20:08:02 mojave pccardd[53]: driver allocation failed for CIRRUS LOGIC 56K MODEM(CL-MD56XX): Device not configured This happened some time towards the end of last month. I saw the message about the missing #include "card.h", and that was it (along with a broken prototype). Still freezes when I eject, but I'll try again after cvsupping Warner's latest. -- 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: Lost PCMCIA sio (was: HEADSUP: wd driver will be retired!)
In message [EMAIL PROTECTED] Christopher Masto writes: : I saw the message about the missing #include "card.h", and that was it : (along with a broken prototype). Still freezes when I eject, but I'll : try again after cvsupping Warner's latest. No. That wasn't it. There are still resource problems and bad memory frees in the code before I fixed it. I also just committed the kludge to sys/net/if.c to make if_detach more stable. We'll see if I catch hell for it or not. You might want to grab that as well. This is the last I plan on doing to the old pccard code for a while. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In a few days time the wd driver will be retired from FreeBSDs i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in 4.1. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
What we need here is a commitment to these new initiatives, not a lot of fence-sitting and clutching our knitting to our chests. If all our users were developers I would agree. But *most* of our users are not developers. Again, I say, think of what we're trying to achieve here. Good question. What are we trying to achieve here? I thought it was to provide the best OS that is usable to the largest number of users? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Nate Williams writes: In a few days time the wd driver will be retired from FreeBSDs i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in 4.1. The ata driver has been available for you and other to test for a long time. 4.0-REL is still some time away, so if you are quick you can still give it a good shakeout and have any bugs you find fixed before 4.0-RELEASE. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
The sound drivers are fine . What we need are people willing to work on the sound drivers . -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Nate Williams writes: What we need here is a commitment to these new initiatives, not a lot of fence-sitting and clutching our knitting to our chests. If all our users were developers I would agree. But *most* of our users are not developers. -CURRENT should have very few users who are not developers in some capacity. Good question. What are we trying to achieve here? I thought it was to provide the best OS that is usable to the largest number of users? And this requires us to move away the old cruft so we force the people on the bleeding edge to test the new stuff. All in all, it sounds to me like a lot of people are presenting a stance which can be summarized as: "why should *I* have to be guinea-pig for the ata driver in -current make somebody else test it first." To which the answer is: If you decide to run -current you have tacitly agreed to be a guinea-pig for FreeBSD developers, so shut up and test. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nate Williams writes: In a few days time the wd driver will be retired from FreeBSDs i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in 4.1. The ata driver has been available for you and other to test for a long time. 4.0-REL is still some time away, so if you are quick you can still give it a good shakeout and have any bugs you find fixed before 4.0-RELEASE. Also, I'd like to reiterate something again.. Not running as fast as possible is *not* a showstopper. If a device runs in generic PIO or WDMA mode instead of udma mode, it's *not* the end of the earth. People in that scenario won't be stranded. What is a killer is if a large number of people on popular hardware can't even boot, *at all*, in no, way, shape or form. Only that. The only way to find that out for sure before 4.0 is to push the issue *now*. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Nate Williams writes: What we need here is a commitment to these new initiatives, not a lot of fence-sitting and clutching our knitting to our chests. If all our users were developers I would agree. But *most* of our users are not developers. -CURRENT should have very few users who are not developers in some capacity. Sure, but in a couple of weeks, -current will be 4.0-Release, which is not -current anymore. Good question. What are we trying to achieve here? I thought it was to provide the best OS that is usable to the largest number of users? And this requires us to move away the old cruft so we force the people on the bleeding edge to test the new stuff. Force people is what I'm having problems with. *Most* people will install 4.0, and give it a good shakeout. The rest of the people are choosing to stick with the old driver for their reasons, and you're (in effect) telling them that you know better than they do what their needs are. And, you're 'forcing' them to either cod or have their systems not work as well as they used to do. From my experience, this is unacceptable if we're in the business of providing a product/service to our users. So, I ask again, what exactly are we trying to accomplish here? All in all, it sounds to me like a lot of people are presenting a stance which can be summarized as: "why should *I* have to be guinea-pig for the ata driver in -current make somebody else test it first." Right, there are people *WILLING* to test it. To which the answer is: If you decide to run -current you have tacitly agreed to be a guinea-pig for FreeBSD developers, so shut up and test. I'm with Warner. If the ATA driver went golden 2-3 months ago, then I'd say go for it. But not 2-3 days ago. You're only telling your user-base that they are less important than you are. (Although, this may be what you believe, so who am I to tell you otherwise). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In a few days time the wd driver will be retired from FreeBSDs i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in 4.1. The ata driver has been available for you and other to test for a long time. And your point is? I'm a user, not a developer. If I wanted to be a developer, I'd have written my own device driver. I want to *USE* FreeBSD, not develop it. It's been considered 'alpha quality' until a couple of days ago. I wouldn't install beta software on any of my systems, and now you're telling me that in order to use FreeBSD, I have to become a beta-tester, since it may/may not work on my systems. 4.0-REL is still some time away, so if you are quick you can still give it a good shakeout and have any bugs you find fixed before 4.0-RELEASE. So, again, who are our customers here? A bunch of developers who enjoy beta-testing other people's code, or people who want to *USE* FreeBSD? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
At 2:33 AM -0800 12/10/99, Alfred Perlstein wrote: Can someone take a look at this? Basically, it makes the link to the file, if it can unlink the original it will then chown the spool file if it can't delete or read the original then the user didn't have permission and it backs out. I'm thinking you'd what to add an lstat call after creating the hardlink. Check the new file to see if it's a symlink, and if it is, then delete the new file and go to nohardlink. Then proceed with the rest of your code (which looks fine to me, but remember I'm the guy who wrote a message explicitly for one mailing list, and then sent it to the other one...). I'm not sure on that, and haven't had time to look at the code yet. I'm just wondering about the case where a user might do a lpr -r -s somesymlink and want to be sure this does the right thing. I suspect that currently (without this patch) lpr will copy the REAL file, and then remove the symlink. I don't think we want to hard-link to the symlink, and then remove the original symlink. Remember, my mind is tired enough that I could easily be making things up here... It may be that the situation I'm wondering about is already covered by other checks in the code. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
What is a killer is if a large number of people on popular hardware can't even boot, *at all*, in no, way, shape or form. Only that. The only way to find that out for sure before 4.0 is to push the issue *now*. I disagree, but I'm not making the decision. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Nate Williams writes: I'm with Warner. If the ATA driver went golden 2-3 months ago, then I'd say go for it. But not 2-3 days ago. You're only telling your user-base that they are less important than you are. (Although, this may be what you believe, so who am I to tell you otherwise). The ATA driver went golden now, and to make sure nobody is distracted from testing it before 4.0-RELEASE is cut, the wd driver will be removed. It's really that simple. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Nate Williams writes: In a few days time the wd driver will be retired from FreeBSDs i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in 4.1. The ata driver has been available for you and other to test for a long time. And your point is? I'm a user, not a developer. If I wanted to be a developer, I'd have written my own device driver. I want to *USE* FreeBSD, not develop it. Then don't run -current. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In a few days time the wd driver will be retired from FreeBSDs i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in 4.1. The ata driver has been available for you and other to test for a long time. And your point is? I'm a user, not a developer. If I wanted to be a developer, I'd have written my own device driver. I want to *USE* FreeBSD, not develop it. Then don't run -current. I don't, but I will be running 4.0, which won't have a WD driver. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Nate Williams writes: And your point is? I'm a user, not a developer. If I wanted to be a developer, I'd have written my own device driver. I want to *USE* FreeBSD, not develop it. Then don't run -current. I don't, but I will be running 4.0, which won't have a WD driver. NOTE TO="SELF" Maybe we should put a special marker in -currents sendmail and reject all email to the current list if they don't originate from such a system. /NOTE So, if you're not running -current, please stop whining on the -current list will you ? 4.0 will have a perfectly good diskdriver, we probably have two entire months to find and nail any remaning bugs, so what the proton do you think you're acheiving by whining here ? I'll tell you in case you can't figure out the answer to that rather simple question: You're annoying people and wasting developer time. That's what. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On 9 Dec, Mike Smith wrote:
There also exist cases where the chipset is supported but a particular
functionality isn´t supported yet (in my case it´s the possibility to
access MS-DOS formated ZIP-disks, harddisk access works well, and I´m
not the only one with this problem (not counting the people which have
not tried to use the ata driver but need to access MS-DOS-ZIPs too)).
I'm completely at a loss as to how the ata driver could be responsible
for your inability to read these disks. I don't have a copy of your
original problem report to hand, but since I have all the hardware here
I'd appreciate it if you could be a little more explicit about your
problem.
The ata driver just moves bytes; it doesn't give a damn what they are.
Try to mount a MS-DOS formatted ZIP-disk (or to access it with mtools).
With wfd I´m able to access it, with afd I can´t access it.
- Yes, I´m used the right /dev entries and remade them with the
newest MAKEDEV, everytime I tested it.
- Yes, I´m used the right fstab/mtools.conf entries ({,r}{a,w}fd0s4).
If you need more info (dmesg of boot -v with ata and/or wd driver,
{g,b}zipped image of an empty, unaccessible ZIP-disk, ...) just ask.
Bye,
Alexander.
--
The best things in life are free, but the
expensive ones are still worth a look.
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: HEADSUP: wd driver will be retired!
In article [EMAIL PROTECTED] PHK writes: NOTE TO="SELF" Maybe we should put a special marker in -currents sendmail and reject all email to the current list if they don't originate from such a system. /NOTE I'll tell you in case you can't figure out the answer to that rather simple question: You're annoying people and wasting developer time. That's what. And further evidence that FreeBSD is turning into PHKBSD: what PHK wants, despite objections from other people, PHK does, and damn any consequences, whether they be social, political, or technical. Several people have raised valid objections to PHK's actions (again -- at least he bothered warning people this time), and have proposed an alternate solution, which PHK has ignored (again -- at least this time he bothered saying so). And, once again, PHK's response is: shut up and go away. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Hi, I'm new to this list. I was running the new ATA driver on an IBM UDMA/66 HighPoint HPT366 IDE controller until last week (sometimes after CTM src-cur-4110). I've recompiled my system and my kernel and the system was not able to find the partition on my UDM66-Disk, was not able to disklabel, after a fresh fdisk. I've connected the disk back to the UDM33 controller and it works fine. Now I get the message twice a day: ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done I've applied the patches until 4133 and will try to reconnect the disk to the UDMA66 controller. Am I missing something about UDMA33/UDMA66 or specifically about the HighPoint controller ? regards, -- Jean Louis Ntakpe Texas Instruments - Freising [EMAIL PROTECTED] Wafer Fab Automation Group [EMAIL PROTECTED]Haggerty Str. 1 D-85350 Freising, Germany Phone +49 8161 80-3816 Fax +49 8161 80-3762 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
On Fri, 10 Dec 1999, Garance A Drosihn wrote: At 2:33 AM -0800 12/10/99, Alfred Perlstein wrote: Can someone take a look at this? Basically, it makes the link to the file, if it can unlink the original it will then chown the spool file if it can't delete or read the original then the user didn't have permission and it backs out. I'm thinking you'd what to add an lstat call after creating the hardlink. Check the new file to see if it's a symlink, and if it is, then delete the new file and go to nohardlink. Then proceed with the rest of your code (which looks fine to me, but remember I'm the guy who wrote a message explicitly for one mailing list, and then sent it to the other one...). I'm not sure on that, and haven't had time to look at the code yet. I'm just wondering about the case where a user might do a lpr -r -s somesymlink and want to be sure this does the right thing. I suspect that currently (without this patch) lpr will copy the REAL file, and then remove the symlink. I don't think we want to hard-link to the symlink, and then remove the original symlink. Remember, my mind is tired enough that I could easily be making things up here... It may be that the situation I'm wondering about is already covered by other checks in the code. ugh, good call. i'll look into it. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SB ViBRA16X
I have checked the mailing list archives and havn't been able to find anything on this so here goes: I have a SoundBlaster ViBRA16X, and a Diamond SupraExpress 56i modem. The SoundBlaster worked fine with PnP OS turned off in Bios, as did the modem. They were detected as non PnP devices by FreeBSD. With the recent changes (controller pnp0 is no longer an option) Neither of these devices works correctly. The Soundcard is detected ok, but it won't play any sound through /dev/dsp, the modem won't even attach to sio0 anymore. Here is a dmesg output, if any other information is needed, I would be glad to provide it: 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: Tue Dec 7 18:31:44 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/MYKERNEL Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (451.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 127414272 (124428K bytes) Preloaded elf kernel "kernel" at 0xc029c000. Preloaded elf module "bktr.ko" at 0xc029c09c. Pentium Pro MTRR support enabled apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: VGA-compatible display device at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 pci0: UHCI USB controller (vendor=0x8086, dev=0x7112) at 7.2 irq 11 chip1: Intel 82371AB Power management controller at device 7.3 on pci0 pci0: unknown card (vendor=0x121a, dev=0x0002) at 13.0 pci0: unknown card (vendor=0x121a, dev=0x0002) at 15.0 bktr0: BrookTree 878 irq 5 at device 17.0 on pci0 bktr0: Hauppauge Model 61291 D110 Warning - Unknown Hauppauge Tuner 0xa Hauppauge WinCast/TV, Philips NTSC tuner. pci0: unknown card (vendor=0x109e, dev=0x0878) at 17.1 irq 5 de0: Digital 21140A Fast Ethernet irq 10 at device 19.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:c0:f0:1f:21:02 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 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 vpo0: Iomega VPI0 Parallel to SCSI interface on ppbus 0 vpo0: EPP 1.9 mode unknown0: SupraExpress 56i at port 0x2f8-0x2ff irq 3 on isa0 sbc0: Creative ViBRA16X PnP at port 0x220-0x22f,0x300-0x301,0x388-0x38b irq 9 drq 0,1 on isa0 pcm0: SB PCM Audio on sbc0 unknown1: Game at port 0x201 on isa0 ad0: Maxtor 90845D4/GAS54112 ATA-4 disk at ata0 as master ad0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad1: Maxtor 84320D4/NAVX1920 ATA-3 disk at ata0 as slave ad1: 4120MB (8438850 sectors), 8930 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, UDMA33 ad2: FUJITSU MPC3064AT/6020 ATA-3 disk at ata1 as master ad2: 6187MB (12672450 sectors), 13410 cyls, 15 heads, 63 S/T, 512 B/S ad2: 16 secs/int, 1 depth queue, UDMA33 acd0: CD-ROM 40X/AKU/U30 CDROM drive at ata1 as slave , 128KB buffer, PIO acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data/audio disc loaded, unlocked da0 at vpo0 bus 0 target 6 lun 0 da0: IOMEGA ZIP 100 D.09 Removable Direct Access SCSI-2 device da0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/wd1s1a de0: enabling 10baseT port To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Please, help fix PCCARD if you know of a problem. Yes. I think I've been the only one fixing bugs lately in PCCARD. :- Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Nate Williams writes: : : I'm with Warner. If the ATA driver went golden 2-3 months ago, then I'd : say go for it. But not 2-3 days ago. You're only telling your : user-base that they are less important than you are. (Although, this : may be what you believe, so who am I to tell you otherwise). : : The ATA driver went golden now, and to make sure nobody is distracted : from testing it before 4.0-RELEASE is cut, the wd driver will be : removed. : : It's really that simple. Isn't that unprecidented? In the past there has always been a period of shakeout between the two events longer than a couple of days. That's the part that you are ignoring. It isn't how we've done things before. You should make it clear that this is a departure from the past, and you should also make sure that the pc98 folks aren't left holding the bag. We've been telling people for a long time that the wd driver would remain around even after ata went golden to support the ESDI systems still in service. That sounds like it is changing now. It just feels like it is being rushed too much. My objections would go away if you said it is going to die in the week between xmas and new years. remove it from files today, to make sure that only the really clueful can get to it, but don't do a cvs remove until after the holidays... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
If half as much energy was spent adding the missing bits of functionality to the new systems as people have been spending complaining it then we'd be there ages ago. Not true. It doesn't take a disk expert to complain about a policy, but it takes one to fix bugs/add features to the existing driver. :) :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Warner Losh writes: : The ATA driver went golden now, and to make sure nobody is distracted : from testing it before 4.0-RELEASE is cut, the wd driver will be : removed. : : It's really that simple. Isn't that unprecidented? In the past there has always been a period of shakeout between the two events longer than a couple of days. Well, the only precedent we have is CAM/SCSI, and it was done the same way. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
It seems Nate Williams wrote: If half as much energy was spent adding the missing bits of functionality to the new systems as people have been spending complaining it then we'd be there ages ago. Not true. It doesn't take a disk expert to complain about a policy, but it takes one to fix bugs/add features to the existing driver. :) :) :) Yeah, and some of them is spending valueable time going thru all this garbage in their mailbox instead of doing something usefull. Excuse me for not taking part in this, but I _really_ think I can use my time for better things... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Poul-Henning Kamp wrote... In message [EMAIL PROTECTED], Warner Losh writes: : The ATA driver went golden now, and to make sure nobody is distracted : from testing it before 4.0-RELEASE is cut, the wd driver will be : removed. : : It's really that simple. Isn't that unprecidented? In the past there has always been a period of shakeout between the two events longer than a couple of days. Well, the only precedent we have is CAM/SCSI, and it was done the same way. I don't think you should look at the CAM integration as a precendent for the current ATA situation. We had a switchover from the old SCSI layer to CAM instead of a transition because it would have been much more difficult to have both SCSI layers in the tree at the same time. In the case of the ATA code, both it and the wd driver have existed in the tree for quite a while, apparantly without problems. So I don't think there is a real parallel there. IMO, if the ATA driver supports all the chipsets that the wd driver does, then it's probably okay to throw the switch to get people testing the new driver. If it doesn't, though, I think we should wait on throwing the switch until it supports them all. Unlike the CAM case, there isn't a compelling reason to throw the switch before the new code supports every chipset. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
At 10:32 PM +0100 1999/12/10, Poul-Henning Kamp wrote: Well, the only precedent we have is CAM/SCSI, and it was done the same way. Given some of the things I've heard about the CAM/SCSI debacle, I'm not sure that this is a good example to be trotting out right now. Personally, I don't think that this is an experience we'd want to be repeating -- especially not with something related to disk devices. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Brad Knowles wrote... At 10:32 PM +0100 1999/12/10, Poul-Henning Kamp wrote: Well, the only precedent we have is CAM/SCSI, and it was done the same way. Given some of the things I've heard about the CAM/SCSI debacle, I'm not sure that this is a good example to be trotting out right now. Personally, I don't think that this is an experience we'd want to be repeating -- especially not with something related to disk devices. I agree that the CAM integration shouldn't be used as a precedent here. I don't agree with your characterization of it as a "debacle", though. On the whole, we gained a whole lot and lost very little. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Luoqi Chen writes: This discussion is not going anywhere. Why can't everyone calm down and find a comprise? Here's my proposal: 1. leave the the code and config option in the source tree for now 2. remove all traces of wd in documentation/GENERIC/LINT/MAKEDEV that is, anyone who wants to use the wd driver still can, but it is officially unsupported. This fails the most important criteria for the transistion to ATA: it doesn't break existing kernel configs. Listen guys, this is a tempest in a tea-cup, we are not loosing any functionality here, we are gaining functionality. The wd driver doesn't have anything to recommend it on the i386 platform and we need to switch to ATA. This is *CURRENT* remember ? We want this transistion done and tested before current becomes 4.0-RELEASE. The time is NOW! If we don't force people over to the ata driver it will not get tested as much as it needs to. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
I think there has been enough objections to the idea of just removing wd.c for it to stay for a few months. It doesn't hurt to keep it. Especially if it's not on by default. I think this argument can go away for a while. On Fri, 10 Dec 1999, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Warner Losh writes: : The ATA driver went golden now, and to make sure nobody is distracted : from testing it before 4.0-RELEASE is cut, the wd driver will be : removed. : : It's really that simple. Isn't that unprecidented? In the past there has always been a period of shakeout between the two events longer than a couple of days. Well, the only precedent we have is CAM/SCSI, and it was done the same way. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! 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
snd0 pcm0
What's the status on the newpcm? is it still broken? When I use newpcm, these problems occur: 1. when I use waveplay to play a file, even after it completely plays the file (and return to the shell prompt), I still hear about 1-2 seconds of sound playing repeatedly. 2. when I use xmms or mpg123, it plays the first file ok, and when I press the stop button and play another, sound applications freeze. 3. when using mtv, sound doesn't work and freezes all sound apps. When using snd0, I have access to all sound apps but when I play mp3 files using any mp3 players, I hear the first 2-3 min fine and then I start hearing statics (nasty statics that don't go away until i press "pause" and play "start" again.) Any reference pages for the answers to these problems? or anybody knows this? FreeBSD nowcool.dhs.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Dec 2 00:35:27 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/NOWCOOL i386 that's when I supped and my snd configurations look like: # for snd0, I use following four lines. controller snd0 device css0 at isa? port 0x534 irq 5 drq 1 flags 0x08 device opl0 at isa? port 0x388 device mpu0 at isa? port 0x330 irq 6 drq 0 # for newpcm, I use following lines options PNPBIOS controller pnp0# PnP support for ISA device pcm0 any clues would be appreciated thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
At 3:05 PM -0700 1999/12/10, Kenneth D. Merry wrote: I agree that the CAM integration shouldn't be used as a precedent here. I don't agree with your characterization of it as a "debacle", though. On the whole, we gained a whole lot and lost very little. Long-term, yes I believe we gained a lot. Short-term, what I recall having heard from some of the people who lived through it, well let's just say it was really ugly and nasty for a certain period of time. If possible, I'd like to see us avoid the same kind of problems with wd vs. ata, if we can. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
At 11:22 PM 12/10/99 +0100, Poul-Henning Kamp wrote: This discussion is not going anywhere. Why can't everyone calm down and find a comprise? Here's my proposal: 1. leave the the code and config option in the source tree for now 2. remove all traces of wd in documentation/GENERIC/LINT/MAKEDEV Listen guys, this is a tempest in a tea-cup, we are not loosing any functionality here, we are gaining functionality. Except that ATA currently does not work on my system. So I assume I'm not the only one. I am not a developer but I am running current on a test system to see what's in line for stable. I do not mind when things break for a while. But, since others did not seem to have this problem, I sent an email to the list. The link is below. So far, I've heard no word, and things are still broken. For this reason, I'd like wd to stay in the tree until ATA is fixed. Otherwise, my machine is unusable. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=761360+0+current/freebsd-current Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Fri, 10 Dec 1999, Poul-Henning Kamp wrote: Listen guys, this is a tempest in a tea-cup, we are not loosing any functionality here, we are gaining functionality. Poul-Henning, what I'm seeing here is a LOT of voices raised against this idea, both from key developers and other citizens of -current. Regardless of whether or not you think you're right and what reasons you have for thinking so, what this is saying is that there a lot of people who do not want this, and you would do well to listen to them. No-one (as far as I can see) is objecting to making ata the default (which it already is), and to kill wd in some number of weeks. Why can't you just do that, and put and end to this discussion happily? Will a few weeks really harm the development process? Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Brad Knowles wrote... At 3:05 PM -0700 1999/12/10, Kenneth D. Merry wrote: I agree that the CAM integration shouldn't be used as a precedent here. I don't agree with your characterization of it as a "debacle", though. On the whole, we gained a whole lot and lost very little. Long-term, yes I believe we gained a lot. Short-term, what I recall having heard from some of the people who lived through it, well let's just say it was really ugly and nasty for a certain period of time. I don't think it was ugly and nasty at all. You're basing your opinions on second hand hearsay. If you can produce specific examples of why it was "really ugly and nasty", fine, but why not avoid making statements you can't support? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Fri, 10 Dec 1999, Poul-Henning Kamp wrote: This fails the most important criteria for the transistion to ATA: it doesn't break existing kernel configs. Listen guys, this is a tempest in a tea-cup, we are not loosing any functionality here, we are gaining functionality. The wd driver doesn't have anything to recommend it on the i386 platform and we need to switch to ATA. Then go and switch.. I'm not stopping you. Just leave the old files there in the meanwhile! It's not hurting you to do so, so stop being so unwilling to listen to other people's opinions and get on with your development! In the meanwhile I'll look at Cyrix support. But first I have to learn about the ata driver and I have too much on my plate as it is.. This is *CURRENT* remember ? We want this transistion done and tested before current becomes 4.0-RELEASE. The time is NOW! So add your new stuff.. there is no hurry to remove the old one. The fact that there is an objection from more than 2 committers on this should have killed the argument already. You'd complain if someone other than you went ahead with something with this amount of objection. Stop trying to steamroll and just Leave the files alone. The same rules apply to you as others and the over-riding rule has always been that a decent level of objection on a non crucial point is enough to stop it reagrdless of what the author of the point feels. That's the way it goes. for adding new stuff, and for deleting old stuff. If you feel that you are excempt from peer review and that the committers as a group should be ignorable, just let us know. If we don't force people over to the ata driver it will not get tested as much as it needs to. It'll get tested well and truely enough if it's teh default. and if it DOESN't work for someone, havingn the wd to fall back on would be a bloody good idea (TM). -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! 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: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Kris Ken naway writes: No-one (as far as I can see) is objecting to making ata the default (which it already is), and to kill wd in some number of weeks. Why can't you just do that, and put and end to this discussion happily? Will a few weeks really harm the development process? You overlook one simple thing here: If we want the ata driver tested, we need to make existing kernel configs break, otherwise people will not change them to use ata. We know this from bitter experience. The removal of wd has many discrete steps, but the first one is to make it clear to people that it is going away, this has been done by now I belive. The next thing is to break all the kernel configs, this has yet to happen, but it will happen real soon. This means that you have to really insist badly to make the wd driver work for you. Once we have established that the new driver doesn't leave a large number of people stranded it will be killed for good. What we need right NOW is for people to test the ata driver, and if it doesn't work, to debug as well as they can and report in excrutiating detail to sos so that he has a chance to analyze the problems. Just saying "It doesn't work for me" will simply not do. The more senior the person reporting, the more detail and quality information should be able to expect. Now, get back to work! -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Poul-Henning Kamp [EMAIL PROTECTED] wrote: Once we have established that the new driver doesn't leave a large number of people stranded it will be killed for good. I think this is a key issue, if not *THE* key issue. Please correct me if I'm wrong, but PHK and others are basically saying: 1. If we allow the old drivers to exist, many people will not use the new drivers, and the new drivers will get little testing. 2. We, therefore, need to force people to use the new drivers by getting rid of the old ones. The concerns that other people have are: 1. "I'm worried about ATA. It was just called ``alpha-quality'' a few days ago, and now you want to promote it to something past ``beta-quality'', where, during a typical beta-test, both old and new drivers coexist. I'm worried about the stability of the ATA drivers." The timing is extremely unfortunate. Many people would have much fewer concerns (or "whining", as has been poorly said) if there were a "testing period" longer than a few days (where the ATA drivers are the default, but the old wd drivers still existed). 2. Functionality is currently missing. I hope I'm wrong, but the attitude seems to be: "If the ATA drivers are missing functionality, either fix it yourself or send hardware to the developers. If you can't fix it, you shouldn't be running -current". Well, this is fine to say, but I'd like to point out: * Many -current users have newer hardware, and tend to have fewer hardware that may not be supported by the new ATA drivers. Many -current users can afford to buy newer hardware (or do so because of business/consulting reasons). * I believe that many users of -release or -stable (who are not running -current and are not reading -current) tend to use older hardware -- the kind that may not be supported by the ATA drivers. The problem here is that we are potentially preventing users of older hardware from running 4.0-release/-stable when it comes out, because no one running -current has an example of their older hardware, and we removed the old drivers which may have worked. In other words, it's unclear as to whether or not the new driver will leave any significant number of people stranded, even if all -current developers test the h*ll out of ATA. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : You overlook one simple thing here: If we want the ata driver tested, : we need to make existing kernel configs break, otherwise people : will not change them to use ata. We know this from bitter experience. If all you are talking about is something like: Index: files.i386 === RCS file: /home/imp/FreeBSD/CVS/src/sys/i386/conf/files.i386,v retrieving revision 1.282 diff -u -r1.282 files.i386 --- files.i386 1999/11/28 17:51:06 1.282 +++ files.i386 1999/12/11 01:31:00 @@ -318,6 +318,7 @@ i386/isa/stallion.coptionalstl i386/isa/tw.c optionaltw i386/isa/vesa.coptionalvga +i386/isa/SirNotAppaeringInThisKerenl.c optionalwd i386/isa/wd.c optionalwd i386/isa/wd.c optionalwdc i386/isa/wfd.c optionalwfd I could go along with that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
If half as much energy was spent adding the missing bits of functionality to the new systems as people have been spending complaining it then we'd be there ages ago. Not true. It doesn't take a disk expert to complain about a policy, but it takes one to fix bugs/add features to the existing driver. :) :) :) That's ignoring the fact that it takes less energy to become enough of a "disk expert" to do something useful than it takes to engage in the sort of protracted whining that we're seeing. It does take more foresight and commitment to actually doing something though, and given the popularity of graffiti and mindless vandalism these days perhaps that's just par for the course. -- \\ 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
ATA weird message?
Hi all, I am using -current as of December 9 (CTM:src-cur.4130.gz), and got following weird ATA related messages while 'make -j4 buildworld'. I never had this kind of message when using wd drivers. ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata1-master: ad_timeout: lost disk contact - resetting ata1: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata1-master: ad_timeout: lost disk contact - resetting ata1: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata1-master: ad_timeout: lost disk contact - resetting ata1: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0-master: ad_timeout: trying fallback to PIO mode ata0: resetting devices .. done ata1-master: ad_timeout: lost disk contact - resetting ata1-master: ad_timeout: trying fallback to PIO mode ata1: resetting devices .. done What's happening here? System configuration follows: --8888888-- FreeBSD 4.0-CURRENT #0: Thu Dec 9 22:17:58 JST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/JKPC15 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67043328 (65472K bytes) avail memory = 61542400 (60100K bytes) Preloaded elf kernel "kernel" at 0xc0346000. Pentium Pro MTRR support enabled --8888888-- ata-pci0: Intel PIIX4 ATA controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ad0: TOSHIBA MK1011GAV/H0.07 C ATA-4 disk at ata0 as master ad0: 9590MB (19640880 sectors), 19485 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad2: HITACHI_DK227A-50/00L0A0A3 ATA-3 disk at ata1 as master ad2: 4789MB (9809100 sectors), 10380 cyls, 15 heads, 63 S/T, 512 B/S ad2: 16 secs/int, 1 depth queue, UDMA33 --8888888-- # ATA and ATAPI devices controller ata0 controller ata1 #controller ata2 device atadisk0# ATA disk drives device atapicd0# ATAPI CDROM drives device atapifd0# ATAPI floppy drives #device atapist0# ATAPI tape drives options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices --- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Office of Business Planning Developement, Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103, Japan Tel: +81-3-3245-3318 Fax: +81-3-32454-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: why 'The legacy aout build' was removed from current ?
On Fri, 10 Dec 1999, Daniel C. Sobral wrote: What Motoyuki-san is complaining about is that applications that depend on a.out libraries will suffer. Alas, I don't think that's the case, since all these libraries are (or ought to be, anyway) in compat. Looking at copious examples from real life, forcing 3rd party developers to upgrade is a good way to lose 3rd party developers. It just *sounds* like a good way to go. As long as this is a change for building world, and not making changes to the kern/imgact things (so we keep on executing aout binaries) then this is probably the best way to go. OTOH, going the other way around is the reason why we (users) had to deal with things like 1 Mb RAM and 64 Kb segments in the age of 486s, one generation after the introduction of the 80386. As a free operating system supported by volunteer effort, we are interested in driving the hardware to it's limits instead of being limited by the ways we once did things. Absolutely, but (here's the caveat) if it *doesn't* hold up any new development, and there's a significant base of users actually deriving benefit from it, then I wouldn't agree. I'm kinda binary about that test, because I fully agree that, if it holds up technology in a project like ours, it's out the door! Stopping the new aout world builds doesn't injure users of aout software, it only *really* strongly discourages new development in aout. I think it just needed to be emphasized that the aout imgact stuff isn't being tossed, so aout executables will still work (those that aren't otherwise incompatible). Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Friday, 10th December 1999, "Kenneth D. Merry" wrote: Brad Knowles wrote... At 3:05 PM -0700 1999/12/10, Kenneth D. Merry wrote: I agree that the CAM integration shouldn't be used as a precedent here. I don't agree with your characterization of it as a "debacle", though. On the whole, we gained a whole lot and lost very little. Long-term, yes I believe we gained a lot. Short-term, what I recall having heard from some of the people who lived through it, well let's just say it was really ugly and nasty for a certain period of time. I don't think it was ugly and nasty at all. You're basing your opinions on second hand hearsay. If you can produce specific examples of why it was "really ugly and nasty", fine, but why not avoid making statements you can't support? This must depend on your perspective. My first hand view is that it was ugly and nasty. This is because I lost support for hardware I was actively using (some temporarily, some permanently), and because I had no control over the pace of change. For a bunch of reasons, there was no way I could keep up (and that meant porting old drivers to keep up). It sure felt ugly to me. The unnecessary renaming of device files made it worse. But that shouldn't stop us from moving forward with the ata driver. I think that a small slowing of the pace, and a bit more understanding toward those with unusual hardware will help. And I support PHK's hard line stance (except for the rushed pace) toward making the kernel break for users of wd. It has to be so, or no one will move. The wd code will still be in the CVS tree for desperate people to revive to use, and to port the missing bits into the ata driver. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
We've been telling people for a long time that the wd driver would remain around even after ata went golden to support the ESDI systems still in service. That sounds like it is changing now. Real support for ESDI died with bad144... Error free ESDI disks are very rare, even the best in my collection has 1 hard error and 3 soft. It just feels like it is being rushed too much. My objections would go away if you said it is going to die in the week between xmas and new years. remove it from files today, to make sure that only the really clueful can get to it, but don't do a cvs remove until after the holidays... Someone needs to dull the dane's axe, it's cutting a bit deep and fast! :-) :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Stephen McKay wrote... On Friday, 10th December 1999, "Kenneth D. Merry" wrote: Brad Knowles wrote... At 3:05 PM -0700 1999/12/10, Kenneth D. Merry wrote: I agree that the CAM integration shouldn't be used as a precedent here. I don't agree with your characterization of it as a "debacle", though. On the whole, we gained a whole lot and lost very little. Long-term, yes I believe we gained a lot. Short-term, what I recall having heard from some of the people who lived through it, well let's just say it was really ugly and nasty for a certain period of time. I don't think it was ugly and nasty at all. You're basing your opinions on second hand hearsay. If you can produce specific examples of why it was "really ugly and nasty", fine, but why not avoid making statements you can't support? This must depend on your perspective. My first hand view is that it was ugly and nasty. This is because I lost support for hardware I was actively using (some temporarily, some permanently), and because I had no control over the pace of change. For a bunch of reasons, there was no way I could keep up (and that meant porting old drivers to keep up). It sure felt ugly to me. The unnecessary renaming of device files made it worse. I suppose it does depend on your perspective. We gave people about a year's worth of notice that some drivers would be going away unless someone stepped forward to port them. In most cases, no one stepped forward, and in one notable case, someone did step forward but never delivered. There was no way around the pace of the change -- it was an all or nothing transition. And as for the device renaming, you didn't have to change anything from sd-da. The old device names and nodes were supported in most every way. There were a lot of mis-informed people on the lists who claimed that you had to change your device names. That was completely untrue, and I attempted to correct people, but the myth and FUD continued to propagate. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Fri, 10 Dec 1999, Kenneth D. Merry wrote: And as for the device renaming, you didn't have to change anything from sd-da. The old device names and nodes were supported in most every way. There were a lot of mis-informed people on the lists who claimed that you had to change your device names. That was completely untrue, and I attempted to correct people, but the myth and FUD continued to propagate. Of course the whole idea of changing from sd to da was (in my opinion) rather silly in the first place since it actually didn't achieve anything except to make people wonder how such silliness was allowed to occur. (i.e the pain far outweighed the asthetic gain, because there was some minor pain and the asthetic gain existed in the minds of about 3 people on the planet) It would have hurt absolutely nothing to keep calling them sd0 etc. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
And as for the device renaming, you didn't have to change anything from sd-da. The old device names and nodes were supported in most every way. There were a lot of mis-informed people on the lists who claimed that you had to change your device names. That was completely untrue, and I attempted to correct people, but the myth and FUD continued to propagate. Changing the device nodes' names was the only sensible thing to do when everything else that referred to the device by name (source files, kernel config, boot-time messages) used the new name. Ther -- \\ 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: HEADSUP: wd driver will be retired!
On Friday, 10th December 1999, Mike Smith wrote: The same mentality that made the CAM cutover a "debacle" is making the ata cutover a "debacle". This "mentality" might be an unavoidable part of human nature. I found That was my musing in the next paragraph. my first reaction was "How dare they take away something I have now?!" and it took some careful thinking to see that my loss was actually very small against future benefits. It might be that these things have to be predicted by -core and handled "touchy feely" like: Core isn't typically involved in these decisions, nor should it be. I also raised the point you make here when I said that it'd have been nice for the parties responsible for the change to soften the blow a bit. Fortunately, the CAM folks persisted despite the criticism, and I'm glad to see that Soren is taking the same stance. Not everything improved with CAM. Personally I'm only receiving the benifits of CAM now, about a year after it replaced the old system. On the balance it has been good for FreeBSD, but you have to remember that there will be small pockets of users that will get the short end of the stick. How the project deals with the losers in these deals is important for its long term health. It's more how the losers deal with the project, to be honest. There has to be a way to make them realise that it's not reasonable to expect everyone else to live in pain just because they (think they) are still comfortable. -- \\ 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
Audio support [was Re: HEADSUP: wd driver will be retired!]
The same thing is about to apply to the woxware sound code, we have a new shiny system that works and is much better designed... Actually, I'm sad to say that our shiny new sound system does *not* work for some of the most popular audio chipsets on the market today (where the older "luigi" sound system did support them) and this is a matter of significant concern to some folks, myself included. We're getting a larger population of people who expect FreeBSD to simply continue to work from release to release, and this is not an unreasonable expectation when you think about it. Unfortunately, when we remove support for a piece of hardware which was formerly supported (the aic driver being a good example) and this particular hardware happens to be in those people's machines, well, it's easy to see where "continuing to work" is no longer a claim we can make for FreeBSD's progress in such cases. When this is also for some really old and grotty piece of hardware, like floppy tape drives, and nobody is interested in actively maintaining the driver for it, then that's a reasonably justifable argument for taking that kind of public relations trade-off. When the hardware in question is something that's currently being sold on the open market and is still quite popular, like the SB16 PCI or Vibra16X on-board audio chipset, then killing off support for it is quite another thing. Both of those device currently refuse to work in any of my -current test boxes and perhaps you should have chosen a better example in making your argument. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Mike Smith wrote... And as for the device renaming, you didn't have to change anything from sd-da. The old device names and nodes were supported in most every way. There were a lot of mis-informed people on the lists who claimed that you had to change your device names. That was completely untrue, and I attempted to correct people, but the myth and FUD continued to propagate. Changing the device nodes' names was the only sensible thing to do when everything else that referred to the device by name (source files, kernel config, boot-time messages) used the new name. Ther Looks like your mail got a little truncated. In any case, yes, it does make more sense to be consistent and use the new names, but what I was getting at is that there were some folks who said things like: "You have to change all your device names to da* in order to use CAM." That isn't true, of course, but it certainly caused some confusion and consternation. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
timecounter
I am not sure the timecounters are being detected properly on my home computer. A while back (around August) -CURRENT's kernel detected 2 timecounters, and using systat -vm, I could see clk generating 100 interrupts (I'm assuming per second) and rtc0 generating about 128 per second. Around the time we changed over to gcc-2.95.2, I noticed that rtc0 is no longer detected, and only one timecounter is detected at boot. The bad effect of this is that the system doesn't accurately show the cpu usage. Any suggestions on how to fix this, or pointers to where the cpu_initclocks() function would be nice :-) Thanks = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Reasonable decision-making [Re: HEADSUP: wd driver will be retired!]
The ATA driver went golden now, and to make sure nobody is distracted from testing it before 4.0-RELEASE is cut, the wd driver will be removed. It's really that simple. Well, I'm not sure that's really true yet and I would honestly prefer it if you wouldn't make "conclusive statements" like this without waiting for a reasonable period of time, *after* the flame war in progress has died down and everyone's done venting and flapping their arms, to come to a decision with all the "votes" carefully weighed (and appropriately weighted). To do otherwise would send a strong message that your intention was to procede regardless of public opinion, which would further imply that the more consensus-based process of deciding these things somehow does not apply to you. People would then ask why this process does not apply to you when it appears to apply to others, raising embarassing and annoying questions about equality, egalitarianism, core Stalins, the insidious effects of space aliens genetically modifying Danish dairy cows, etc. etc. From what I've seen of the thread so far, this has already sort of begun to happen and my strategy on the whole affair at this point has been to simply make marks on a tally-sheet near my keyboard, whacking `delete' in the mailer after making the appropriate check mark under the "yes", "no", "undecided" or "went off into the weeds on a completely unrelated tangent" columns. This allows me to try and sift out all the emoting from the Real Issue(tm) to be decided and, hopefully, come to my own conclusions based on the tally-sheet and further discussion with those parties directly involved (no, I didn't forget them). I'll even be happy to post my little tally of this whole sorry thread to -committers, assuming there's any interest in such a synopsis. In any case, the Real Issue here appears to be whether or not it's necessary to socially engineer people by removing the wd driver one week after the ata driver was declared "golden" or whether it's perhaps more prudent to simply leave the damn thing there for now and just stop maintaining it, leaving its future to Darwin and/or some future committer who takes an axe to it because it's rotted for so long that it finally no longer even builds and/or functions at all. All other discussion has been more or less tangental to that issue. I have my own opinions on this, of course, but I'm more interested in what everyone else here has to say about it right now. Maybe I'll change my mind once I've finished making my little marks and talking to people, and you yourself would certainly not lose any points with your audience by demonstrating a similar degree of flexibility. It certainly doesn't seem like too much to ask for. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA weird message?
On 11 Dec, Munehiro Matsuda wrote: Hi all, I am using -current as of December 9 (CTM:src-cur.4130.gz), and got following weird ATA related messages while 'make -j4 buildworld'. I never had this kind of message when using wd drivers. ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata1-master: ad_timeout: lost disk contact - resetting ata1: resetting devices .. done I too am seeing this. I decided tonight to go from -STABLE (3.4-RC) to -CURRENT. After I built a 4.0-CURRENT kernel and rebooted into single user mode, I started to "make -j10 buildworld" with /usr mounted async. In about 10 minutes, I got a similar error to the above error: ata1-master: ad_timeout: lost disk contact - resetting ata1: resetting devices .. done ad_transfer: timeout waiting for DRQ At that point, my system freezes up. I have to reboot. I thought it was the "-j10", so when I rebooted back into -CURRENT kernel single user mode, I did just a "make buildworld". After some time, it again gave me the same error. I booted into -STABLE and verified that everything was working and it was. So I recompiled the -CURRENT kernel without SOFTUPDATES (and all other "extras"), just in case. It went further this time in the build, but still froze with the above error. Summary: The error occurred no matter if I was using softupdates, async mount, or normal mount. I cannot build -CURRENT. In -STABLE, I am fine, and have been running -STABLE for over a year now on this machine. Information on System: Dual Pentium 200 on ASUS P/E-P55T2P4D motherboard with 128Megs EDO RAM. dmesg from -STABLE: FreeBSD 3.4-RC #1: Thu Dec 9 19:45:30 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/PATRICK Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC real memory = 134217728 (131072K bytes) avail memory = 12800 (125000K bytes) Programming 16 pins in IOAPIC #0 EISA INTCONTROL = 0c00 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 Preloaded elf kernel "kernel.stable" at 0xc025e000. eisa0: ASU5201 (System Board) Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: Intel 82439HX PCI cache memory controller rev 0x01 on pci0.0.0 chip1: Intel 82375EB PCI-EISA bridge rev 0x05 on pci0.7.0 vga0: ATI model 4750 graphics accelerator rev 0x5c int a irq 10 on pci0.10.0 fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x08 int a irq 11 on pci0.1 1.0 fxp0: Ethernet address 00:90:27:cb:0f:32 ide_pci0: PCI IDE controller (busmaster capable) rev 0x01 int a irq 14 on pci 0.13.0 Probing for PnP devices: CSN 1 Vendor ID: ALS0120 [0x20019305] Serial 0x Comp ID: @@@ [0x000 0] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 ed0 at 0x280-0x29f irq 10 on isa ed0: address 00:e0:29:17:73:26, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0x90ff on isa wdc0: unit 0 (wd0): ST34321A, LBA, 32-bit, multi-block-32 wd0: 4103MB (8404830 sectors), 523 cyls, 255 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0x90ff90ff on isa wdc1: unit 0 (wd2): ST34321A, LBA, 32-bit, multi-block-32 wd2: 4103MB (8404830 sectors), 523 cyls, 255 heads, 63 S/T, 512 B/S wdc1: unit 1 (atapi): CD-524EA/1.0A, removable, accel, ovlap, dma, iordis acd0: drive speed 4134KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 plip0: PLIP network interface on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface joy0 at 0x201 on isa joy0: joystick Intel Pentium detected, installing workaround for F00F bug APIC_IO: routing 8254 via pin 2 changing root device to wd2s1a SMP: AP CPU #1 Launched! Some probes from -CURRENT: mainboard0:ASU5201 (System Board) on eisa 0 slot 0 ata-pci0: CMD 646 ATA controller (generic mode) irq 14 at device 13.0 on pci0 ata-pci0: Busmastering DMA Supported If someone needs more information or for me to do any testing, please let me know. I'm not a developer, but I'm
Install of 4.0-19991208-CURRENT
I've just tried installing the last current snapshot (4.0-19991208-CURRENT) onto an IBM laptop (365, type 2625-2E9) with a Xircom networking card (CE3B-100BTX). It failed -- the pccard was not recognized. I mention this because the floppies/pccard/README.TXT mentioned the systems that have been tested. Regards, Mike Kennett ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Except that ATA currently does not work on my system. So I assume I'm not the only one. Actually, to quote from your original message: ] According to technical product summary, the primary IDE interface, on ] which both my drives reside, is a PCTech RZ1000 on the PCI local bus. Nobody in their right mind uses the RZ1000 chipset for IDE. It's one of the classic "broken" parts (along with several of the CMD64x family) that you just don't use. You're probably not the only one out there with one of these controllers, but there aren't anywhere near that many of them still circulating after the massive problems that were encountered with that part _many_ years ago. I am not a developer but I am running current on a test system to see what's in line for stable. I do not mind when things break for a while. But, since others did not seem to have this problem, I sent an email to the list. The link is below. So far, I've heard no word, and things are still broken. For this reason, I'd like wd to stay in the tree until ATA is fixed. Otherwise, my machine is unusable. I'm not really in a position to determine what will or won't happen regarding support for known-defective hardware like the RZ1000 or the CMD640, but I'd say that it's likely to receive fairly low-priority treatment. It's not, of course, clear from your message whether the problem is actually related to the RZ1000 part itself, or whether it's actually a manifestation of the "system goes nowhere at startup" problem that other people are seeing (seems to be related to interrupt handling by the 'ata' driver). -- \\ 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: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : You overlook one simple thing here: If we want the ata driver tested, : we need to make existing kernel configs break, otherwise people : will not change them to use ata. We know this from bitter experience. If all you are talking about is something like: Index: files.i386 === RCS file: /home/imp/FreeBSD/CVS/src/sys/i386/conf/files.i386,v retrieving revision 1.282 diff -u -r1.282 files.i386 --- files.i386 1999/11/28 17:51:06 1.282 +++ files.i386 1999/12/11 01:31:00 @@ -318,6 +318,7 @@ i386/isa/stallion.c optionalstl i386/isa/tw.c optionaltw i386/isa/vesa.c optionalvga +i386/isa/SirNotAppaeringInThisKerenl.coptionalwd i386/isa/wd.c optionalwd i386/isa/wd.c optionalwdc i386/isa/wfd.coptionalwfd I could go along with that. And probably an #error "Don't use this driver, use ata-disk instead" in wd.d -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: timecounter
The rtc is not a timecounter, and I doubt the the problem is related to timecounters at all. The RTC is always detected, because we know it is there, but it may be that you don't get any interrupts from it, I don't know why that might be. Poul-Henning In message [EMAIL PROTECTED], Ke nneth Culver writes: I am not sure the timecounters are being detected properly on my home computer. A while back (around August) -CURRENT's kernel detected 2 timecounters, and using systat -vm, I could see clk generating 100 interrupts (I'm assuming per second) and rtc0 generating about 128 per second. Around the time we changed over to gcc-2.95.2, I noticed that rtc0 is no longer detected, and only one timecounter is detected at boot. The bad effect of this is that the system doesn't accurately show the cpu usage. Any suggestions on how to fix this, or pointers to where the cpu_initclocks() function would be nice :-) Thanks = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq| | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
