Re: HEADSUP: wd driver will be retired!
On Wed, 15 Dec 1999, Robert Watson wrote: On Tue, 14 Dec 1999, Peter Wemm wrote: The RZ1000 is *dangerous*! We are doing no favours by making it run.. :-/ IMHO It is better to loose the user by not playing ball than to corrupt their data or run unreliably and make them hate us for it. http://www.faqs.org/faqs/pc-hardware-faq/enhanced-IDE/part1/ ... In both cases, the corruption occurs only in specific software environments and is very subtle; you can go on working for months without suspecting anything more than buggy software. The damage can I believe the FreeBSD environment is not one of the environments that has the problem. E.g., since the same spl (splbio()) is used for IDE and floppy interrupts and all device accesses occur at this spl (or higher), so mixing IDE and floppy accesses is almost automatically prevented. Since someone has code to detect these, how about putting this code in the ata driver probe so it can say something appropriately obscene and we start getting feedback about how widely deployed they are, and so that users can evaluate their risk in using the new driver? There's also Here is the code to detect and fix the problem with rz1000's in the wd driver: "" :-). The code to detect and fix the problem with CMD640B's is larger (about 60 lines plus grot in the infrastructure). Detection alone is easy (just a pci id compare). The ata driver already prints something obscene: "CMD 640 ATA controller (generic mode)" :-). Bruce 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 Tue, 14 Dec 1999, Peter Wemm wrote: The RZ1000 is *dangerous*! We are doing no favours by making it run.. :-/ IMHO It is better to loose the user by not playing ball than to corrupt their data or run unreliably and make them hate us for it. http://www.faqs.org/faqs/pc-hardware-faq/enhanced-IDE/part1/ ... In both cases, the corruption occurs only in specific software environments and is very subtle; you can go on working for months without suspecting anything more than buggy software. The damage can be immense. For all the details, look at Roedy Green's ([EMAIL PROTECTED]) "PCI EIDE controller flaws" FAQ included with his EIDE test ftp://garbo.uwasa.fi/pc/diskutil/eidete19.zip program which will test your system for the bugs. BE WARNED that you're playing Russian roulette with your data if you continue working on an affected machine without taking notice of this problem. Since someone has code to detect these, how about putting this code in the ata driver probe so it can say something appropriately obscene and we start getting feedback about how widely deployed they are, and so that users can evaluate their risk in using the new driver? There's also mention of being able to disable features in the bios to fix this--is this a workaround that can be initiated from user software in a useful way? I.e., if the ata driver detects bad hardware, it pulls in a loadable kernel module that would somehow address the problem, or avoids the issues which cause corruption, if identifiable? Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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 Robert Watson wrote: On Tue, 14 Dec 1999, Peter Wemm wrote: The RZ1000 is *dangerous*! We are doing no favours by making it run.. :-/ IMHO It is better to loose the user by not playing ball than to corrupt their data or run unreliably and make them hate us for it. http://www.faqs.org/faqs/pc-hardware-faq/enhanced-IDE/part1/ Amen! Since someone has code to detect these, how about putting this code in the ata driver probe so it can say something appropriately obscene and we start getting feedback about how widely deployed they are, and so that users can evaluate their risk in using the new driver? There's also mention of being able to disable features in the bios to fix this--is this a workaround that can be initiated from user software in a useful way? I.e., if the ata driver detects bad hardware, it pulls in a loadable kernel module that would somehow address the problem, or avoids the issues which cause corruption, if identifiable? That particular chip is so broken in so obscure ways, that most of the "fixes" floating around doesn't. Its just plain broken, and should be avoided totally and at all cost... -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!
On Wed, Dec 15, 1999 at 07:01:59PM +0100, Soren Schmidt [EMAIL PROTECTED] wrote: That particular chip is so broken in so obscure ways, that most of the "fixes" floating around doesn't. Its just plain broken, and should be avoided totally and at all cost... It will be nice to let the user know about very broken hardware. -- Vallo Kallaste [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!
"Mike" == Mike Smith [EMAIL PROTECTED] writes: Mike The "right" solution is and has always been to name your Mike disks and mount them by name. Once devfs is a reality, Mike we'll be able to do just this. Until then, the problem's Mike not really as bad as you make it out to be. I like the assigned-name solution. I still don't like dynamic disk names. It's not a show-stopper by any stretch, but if you move disks around, (not uncommon on development machines) it's a pain. And while you're correct about the boot/fsck issues, adding a renumbering in /etc/fstab to my restart sequence isn't doing anything to get the machine back up quickly (or reliably). Anyway, enough of this -- I have config files to go hardwire :-) --lyndon 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 I didn't like about CAM was that I lost my tape drive. Since I had all my backups and archives on DAT, it felt like a bad thing. Which reminds me -- can anyone spare a 2.1 CD? Please send me private mail, if so: I foolishly neglected to convert to CD, and now I can't find 2.1 on the web anywhere. 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 Mon, Dec 13, 1999 at 15:45:15 -0600, Anthony Kimball wrote: What I didn't like about CAM was that I lost my tape drive. Since I had all my backups and archives on DAT, it felt like a bad thing. What do you mean you "lost" your tape drive? CAM has included a tape driver almost from day one, and it certainly went into the tree with a tape driver. It certainly works with *my* DAT drive... Which reminds me -- can anyone spare a 2.1 CD? Please send me private mail, if so: I foolishly neglected to convert to CD, and now I can't find 2.1 on the web anywhere. Do you mean straight 2.1, or a release in the 2.1 series? If you want 2.1.7.1, check here: ftp://ftp.kdm.org/pub/FreeBSD 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 Saturday, 11 December 1999 at 8:52:28 +0100, Poul-Henning Kamp wrote: 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.coptionaltw i386/isa/vesa.c optionalvga +i386/isa/SirNotAppaeringInThisKerenl.c optionalwd i386/isa/wd.coptionalwd i386/isa/wd.coptionalwdc i386/isa/wfd.c optionalwfd I could go along with that. I've been trying to figure out exactly what you mean with this change. I've decided you mean this is a line you need to remove in order to build a kernel with wd. Correct? That might work, but I think it's a bit of a kludge. Why not just change the name of the driver to owd? That way people will have to make a conscious effort to stay with that driver, and we can issue them with the dire warnings about the effects of doing so. And probably an #error "Don't use this driver, use ata-disk instead" in wd.d Remember this fix is supposed to be for non-CURRENT users, people who are traumatized enough already. A warning from config(8) would serve a similar purpose. 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 19:01:49 +0100, 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. Oh. Somehow I missed this. Sure, I saw commits, but I can't recall a "HEADS UP: ata is good enough for general testing now". If I had done so, I might have changed months ago, and a lot of this principle discussion would be deferred to the next night of the long axes. 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. Again, it's not the bugs I'm worried about. Anyway, the 'else' part must read: and if not, it will go into -RELEASE buggy. 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
Wiring drive IDs (was: HEADSUP: wd driver will be retired!)
p On Saturday, 11 December 1999 at 18:28:42 +0800, Peter Wemm wrote: Dieter Rothacker wrote: On Sat, 11 Dec 1999 14:21:25 +0800 (WST), Michael Kennett wrote: Note that wd1 is not present. This caused a mild hickup when rebooting the new kernel, since the new ata controller assigned the labels ad0 and ad1 to the drives. It was not possible to boot into multiuser mode without changin g the /etc/fstab file to rename the /dev/wd2* entries to /dev/ad1*. That was easy to fix, however for a newbie it might cause problems. I mention it now , since the upgrade from 3.x might need special handling of this case (?). You should use the kernel option "options ATA_STATIC_ID" for such cases. At least it works for me :-) I think this should only apply to the /dev/wd* compatability devices. ie: use the correct numbering for new installs onto ad*, but still support the old spread-out naming for wd*. This used to be more important as it required fiddling with $root_disk_unit, but the new mountroot code has relieved the pressure there. We've been through this before (and no, it has nothing to do with Danish axes :-) As long as we refer to them in /etc/fstab, we should have consistent ways of referring to specific drives. I think the *correct* way to refer to drives is by an ID field on the drive itself, the way Vinum does it. That way you could swap drives around anyway you want and the system can handle, and you would still be able to locate your partitions. But in the meantime, it's nice to know that you can add a primary slave without your fstab falling apart. 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 19:19:43 +0100, Poul-Henning Kamp wrote: 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 ? Two months? I thought the date was 15 January. Anyway, it's fairly evident what Nate's "whining" about. What part of "FUNCTIONALITY LOSS" don't you understand? 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. OK, why don't you save time and leave wd in the tree. Comment it out of GENERIC, leave a comment explaining what it's for and that it will go away as soon as ata has the complete functionality. 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: HEADSUP: wd driver will be retired!
On Saturday, 11 December 1999 at 15:03:19 +1000, Stephen McKay wrote: 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 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: What if we do this decisive break with past ? public: Um, sounds scary. When will you do it? Will I lose anything? core: We think a month from now, and you will lose support for x and y. public: We don't use x and y any more, so fine. instead of the current (caricatured for emphasis): core: We will do decisive break with past soon. Probably today. public: Oh my God! core: It's for your own good. You always complain and make it difficult! public: We don't want to change anything, ever! It's so hard! You must support all my hardware for ever and ever! You obviously haven't seen it from this viewpoint (s/core/committers/): committers: We will do decisive break with past soon. Probably today. public: What does this mean for me? committers: It's all new, all better, much better code. public: Will it do everything the old driver did? committers: Well, no, but that's coming. public: And what do I do in the meantime? committers: Stop whining. On Friday, 10 December 1999 at 21:57:17 -0800, Mike Smith wrote: On Friday, 10th December 1999, Mike Smith wrote: 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. OK, now explain how that statement relates to the matter at hand. Who is going to be in pain if the "losers" get their way? Who if not? Your whole attitude shows a surprisingly one-sided view of things. There are people out there who are going to suffer because of short-term decisions which aren't really necessary right now. Amongst others, they're the people who are paying your salary. 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: HEADSUP: wd driver will be retired!
On Saturday, 11 December 1999 at 12:39:15 +1000, Stephen McKay wrote: 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. The kind of people I'm talking about are end users. They wouldn't know how to extract the driver from the CVS tree and build it. 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: HEADSUP: wd driver will be retired!
On Saturday, 11 December 1999 at 2:09:48 +0800, Peter Wemm wrote: 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. I think a 90% performance hit is a bug in most people's books. From what I've seen, that's a conservative estimate. 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*. Agreed. I'm not saying "don't make it the default", I'm saying "leave an escape path". 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: HEADSUP: wd driver will be retired!
On Saturday, 11 December 1999 at 0:55:15 +0100, Poul-Henning Kamp wrote: 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. OK, so rename the wd driver to owd. Make it necessary to change the config in any way. Print out dire warnings on every boot and every config(8). 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. I think it has settled in, yes. 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. OK, as long as we have an alternative, such as I suggest above. Once we have established that the new driver doesn't leave a large number of people stranded it will be killed for good. The new driver? That's counterproductive :-) I'd like to see a definition of "large number". 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. You're talking about different people here. Understand that the users of -CURRENT are numbered in the hundreds; the users of -RELEASE are numbered in the hundreds of thousands. 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 17:54:14 -0800, Mike Smith 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. :) :) :) 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. Using derogatory terminology doesn't alter the facts, it just alters people's view of you. We're not talking "whining" here, we're talking policy. And the policy has good, solid reasoning behind it, something we've seen precious little of in favour of immediately axing the wd driver. 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. By "graffiti and vandalism", are you referring to the Danish Axes? I wouldn't call that graffiti, and the Vandals are only distantly related to the Danes :-) 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 17:11:53 +0100, Poul-Henning Kamp wrote: 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. Experience has also taught us that people draw the lines in different places. I haven't seen enough consideration of the end user in all this discussion. Look at the sound code to see why your proposal doesn't work in our reality. You're going to have to help me here. I hadn't used the sound code up to a couple of months ago. 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 23:32:27 -0800, Mike Smith wrote: [missing attribution to Greg Childers [EMAIL PROTECTED]] 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. OK, and I think I can agree that we don't need to carry support for this chip over into ata. But what does Greg do? He has this hardware. He can do one of four things: 1. Throw it away and get something better. 2. Carry on running 3.X forever. 3. Get pissed off with FreeBSD and go elsewhere. 4. Use the wd driver which has been left in 4.x for exactly this kind of problem. Why make life difficult for him? 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 19:04:33 +0100, Poul-Henning Kamp wrote: 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. Agreed. As I said earlier in the thread, the problem is that we're 5 weeks from releasing this code as 4.0-RELEASE. I think we might be able to compromise here: issue 4.0 with a disclaimer saying "AFAWK Cyrix DMA support is broken. If you have a Cyrix [IDE] chip, use 3.[45]-RELEASE instead.". 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." I haven't noticed anybody doing that. It's certainly not my concern; as soon as I get home I'm going to try out the 5591 code and make sure it works correctly. 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. To which the answer is what I said above: today's -CURRENT is next month's -RELEASE. 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: HEADSUP: wd driver will be retired!
On Saturday, 11 December 1999 at 0:02:47 +0800, Peter Wemm wrote: 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. There's more than energy involved. We need the hardware. 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. Who are you talking to? The relatively non-technical people who buy the CDs because they know that FreeBSD is a reliable, no-problems operating system. Then they discover that functionality they had is gone again. Send that to /. and smoke it. Like it or not, we have a reputation to maintain. We have to live up to expectations. 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: HEADSUP: wd driver will be retired!
On Friday, 10 December 1999 at 22:44:36 +0100, Soren Schmidt wrote: 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... Sure, this thread has gone on far too long. Let's agree to the principle of leaving drivers in the system, disabled, until their replacements can do everything that they can. It looks like ata is nearly there, but what about those Cyrix users? Who has a Cyrix chip? Until we find somebody with hardware, inclination and ability, it's going to be difficult to replace the wd driver. 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: HEADSUP: wd driver will be retired!
Greg Lehey wrote: On Friday, 10 December 1999 at 23:32:27 -0800, Mike Smith wrote: [missing attribution to Greg Childers [EMAIL PROTECTED]] 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. OK, and I think I can agree that we don't need to carry support for this chip over into ata. But what does Greg do? He has this hardware. He can do one of four things: 1. Throw it away and get something better. 2. Carry on running 3.X forever. 3. Get pissed off with FreeBSD and go elsewhere. 4. Use the wd driver which has been left in 4.x for exactly this kind of problem. Why make life difficult for him? The RZ1000 is *dangerous*! We are doing no favours by making it run.. :-/ IMHO It is better to loose the user by not playing ball than to corrupt their data or run unreliably and make them hate us for it. http://www.faqs.org/faqs/pc-hardware-faq/enhanced-IDE/part1/ 3.3. Are those rumors about buggy interfaces true? Very true, unfortunately. This FAQ doesn't really deal with specific interfaces, but two very popular interface chips have been shown to contain bugs too serious to ignore: o the CMD640x, a dual-channel PCI to EIDE interface used on many mainboards (Intel!) and interface boards, has a number of dangerous bugs you need to be aware of. o The PC-Tech RZ-1000, used on ATT, Dell, Gateway and Intel boards, also has two data-corrupting bugs. See also http://www.intel.com/procs/support/rz1000/index.htm. In both cases, the corruption occurs only in specific software environments and is very subtle; you can go on working for months without suspecting anything more than buggy software. The damage can be immense. For all the details, look at Roedy Green's ([EMAIL PROTECTED]) "PCI EIDE controller flaws" FAQ included with his EIDE test ftp://garbo.uwasa.fi/pc/diskutil/eidete19.zip program which will test your system for the bugs. BE WARNED that you're playing Russian roulette with your data if you continue working on an affected machine without taking notice of this problem. Have a look at the intel information. It explains about having to mask interrupts during a data transfer, and how dangerous mixing floppy and IDE access is with that chip. 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!
On 1999-Dec-12 05:54:12 +1100, Greg Lehey [EMAIL PROTECTED] wrote: On Friday, 10 December 1999 at 19:01:49 +0100, Poul-Henning Kamp wrote: The ata driver has been available for you and other to test for a long time. Oh. Somehow I missed this. Sure, I saw commits, but I can't recall a "HEADS UP: ata is good enough for general testing now". If I had done so, I might have changed months ago, and a lot of this principle discussion would be deferred to the next night of the long axes. I don't recall anything like this either. I _do_ remember all the commit messages stating 'this driver can hose your disk real bad' which tended to disuade me from experimenting in the early days. (None of my systems are `scratch boxes' to the extent that I can afford for the disk contents to be scrambled regularly). Checking back though the commit logs, the last commit that explicitly included the 'As usual USE AT YOUR OWN RISK!!, this is still alpha level code' comment was on 21st September. There's nothing in the logs explicitly stating that the code is now `beta', `pre-production' or `production' quality. 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!
At 07:40 AM 12/14/99 +0800, Peter Wemm wrote: Greg Lehey wrote: On Friday, 10 December 1999 at 23:32:27 -0800, Mike Smith wrote: [missing attribution to Greg Childers [EMAIL PROTECTED]] 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. The RZ1000 is *dangerous*! We are doing no favours by making it run.. :-/ IMHO It is better to loose the user by not playing ball than to corrupt their data or run unreliably and make them hate us for it. http://www.faqs.org/faqs/pc-hardware-faq/enhanced-IDE/part1/ snip o The PC-Tech RZ-1000, used on ATT, Dell, Gateway and Intel boards, also has two data-corrupting bugs. See also http://www.intel.com/procs/support/rz1000/index.htm. In both cases, the corruption occurs only in specific software environments and is very subtle; you can go on working for months without suspecting anything more than buggy software. The damage can be immense. For all the details, look at Roedy Green's ([EMAIL PROTECTED]) "PCI EIDE controller flaws" FAQ included with his EIDE test ftp://garbo.uwasa.fi/pc/diskutil/eidete19.zip program which will test your system for the bugs. Thanks for the info! I wasn't aware of this problem. Fortunately, the fix was easy. From eideflaw.txt in the above mentioned utility (actually it's eidete20.zip now): Some BIOSes have a feature disable the EIDE prefetch buffer. snip This will bypass both RZ-1000 flaws... I haven't tried ATA after today's update. I'll do that tomorrow. 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!
3. Get pissed off with FreeBSD and go elsewhere. don't worry I am sure that quite a few user have left already. This kind of situation reminds of when I accidently broke the gus max backwards compatibility. An old friend of mine sent me a quiet note stating that he switch OSes cause he couldn't use his soundcard with FreeBSD . The mail didn't surprise me what really surprise is that he just switch OSes without warning me. So we have quiet types and "loud" types of users. The users which complaint don't bother me at least I know what they are thinking . The users / developers ratio initially bother me in the multimedia mailing list;however, I came to the conclusion that we do need a large user base to maximize test coverage and feasibility . -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Audio support [was Re: HEADSUP: wd driver will be retired!]
In [EMAIL PROTECTED] Kenneth Wayne Culver [EMAIL PROTECTED] wrote: Just a question which I'm not sure is soundcard related. My xmms no longer starts up anymore, it just hangs in Poll before it actually puts anything on the display, is that because /dev/dsp isn't working? Thw 'xmms' problem is not soundcard related. It is uthreads related. Daniel Eischen already have the patches to solve this problem. In the meantime you can try to make the following: Manually unpack your default Skin (now it is 'zip'-ped - is it ?). After that your 'xmms' will start to make noises (somebody calla them music ;-). N.Dudorov 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, Dec 10, 1999 at 07:01:49PM +0100, Poul-Henning Kamp wrote: The ata driver has been available for you and other to test for a long time. That may be the case, but the vast majority of our users don't run -current, for good reason, and so are in no position to test it. 4.0 will be their first exposure to ata, and you should definitely expect it to have problems that have been shaken out of the wd driver. Poul, I'd like to know what's wrong with (1) Putting ata in GENERIC (2) Keeping wd in LINT, commented out (3) A big notice in UPDATING, saying that ata is the replacement for wd. Make wd require "options I_WANT_WD" or something similar, so that people can't simply re-config their existing configuration file. That gives you the best of all possible worlds. Most people can move to ata immediately. Those people that can't can still run 4.0 with wd, and will know that it's going away for 4.1, and can take part in reporting the problems they're having with ata. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Wilko Bulte writes: On Sat, Dec 11, 1999 at 09:00:52AM -0800, Bob Vaughan wrote: Subject: Re: HEADSUP: wd driver will be retired! Date: Fri, 10 Dec 1999 19:19:43 +0100 From: Poul-Henning Kamp [EMAIL PROTECTED] 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 Seriously: I don't expect NOTE TO="SELF" to be meant seriously. Right? Right. -- 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: ata: lost disk contact errors [was: Re: HEADSUP: wd driver will be retired!]
On Sat, Dec 11, 1999 at 12:57:04PM -0800, Doug White [EMAIL PROTECTED] wrote: I'm getting the "lost disk contact" messages every now and then, but only on our mp3 machine with PIIX3 controller and IBM UDMA/66 disk. It's an PPro machine with Intel mobo. Can it be related to newer IBM disks? Depends on what 'now and then' is. The Deskstar series of drives was not intended to run 24/7, and therefore shut themselves down every week to clean the heads. Mhm, now I remember the discussion in -current list some time ago. It can be, yes, but I need to follow the logs to say for sure. About month ago the messages appeared several times per day, not per week. Thank you refreshing my memory :-) -- Vallo Kallaste [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], Nik Clayton writ es: On Fri, Dec 10, 1999 at 07:01:49PM +0100, Poul-Henning Kamp wrote: The ata driver has been available for you and other to test for a long time. That may be the case, but the vast majority of our users don't run -current, for good reason, and so are in no position to test it. 4.0 will be their first exposure to ata, and you should definitely expect it to have problems that have been shaken out of the wd driver. Poul, I'd like to know what's wrong with (1) Putting ata in GENERIC (2) Keeping wd in LINT, commented out This will not force CURRENT users to change their configs, a config with wd in it will still work unchanged. Peter just added code for issuing warnings, but I'd prefer for the build to actually break until people fix it. -- 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: Audio support [was Re: HEADSUP: wd driver will be retired!]
On Sat, 11 Dec 1999, Marcel Moolenaar wrote: "Jordan K. Hubbard" wrote: 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. The recent commits made existing support even worse. Yes, I'm talking about the ESS1888. It's more dead than before. I'll have to make the noise myself these days, and I can tell you it's no opera :-) In short: Gimme patches! I'll be happy to test and, in a spare hour, can even do some trial and error on my own. I'm not going to beg... Which commits broke the ESS1888? I haven't tested it for a couple of weeks but I have an ESS1888 in one of my alpha boxes which worked a while ago after I fixed a few bits and pieces in the driver. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Sun, Dec 12, 1999 at 11:59:38AM +0100, Poul-Henning Kamp wrote: Poul, I'd like to know what's wrong with (1) Putting ata in GENERIC (2) Keeping wd in LINT, commented out This will not force CURRENT users to change their configs, a config with wd in it will still work unchanged. Peter just added code for issuing warnings, but I'd prefer for the build to actually break until people fix it. wd.c #ifndef I_WANT_WD #error "You must really, really, really want to use this driver." #error "See UPDATING for details." #else ... #endif If someone takes their existing config file and tries to build a kernel from it, it will break. That meets every definition of "force CURRENT users to change their configs" that I can think of. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Audio support [was Re: HEADSUP: wd driver will be retired!]
Doug Rabson wrote: The recent commits made existing support even worse. Yes, I'm talking about the ESS1888. It's more dead than before. I'll have to make the noise myself these days, and I can tell you it's no opera :-) In short: Gimme patches! I'll be happy to test and, in a spare hour, can even do some trial and error on my own. I'm not going to beg... Which commits broke the ESS1888? I haven't tested it for a couple of weeks but I have an ESS1888 in one of my alpha boxes which worked a while ago after I fixed a few bits and pieces in the driver. The first breakage was with the introduction of newmidi IIRC. The mixer worked, but any dsp related functions were broken. See: sys/dev/sound/isa/es1888.c rev 1.3 In recent kernel even the mixer is dead and the soundcard is left in a state where all volumes are zeroed, preventing audio CD playing as well. See: sys/dev/sound/isa/es1888.c rev 1.4 Relevant kernel config options: options PNPBIOS controller isa0 controller eisa0 controller pci0 controller pnp0 device pcm0 I have to re-enable sbc0 to see if any changes therein apply to ESS as well. Should I have sbc0 in the first place? -- 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: Audio support [was Re: HEADSUP: wd driver will be retired!]
On Sun, 12 Dec 1999, Marcel Moolenaar wrote: Doug Rabson wrote: The recent commits made existing support even worse. Yes, I'm talking about the ESS1888. It's more dead than before. I'll have to make the noise myself these days, and I can tell you it's no opera :-) In short: Gimme patches! I'll be happy to test and, in a spare hour, can even do some trial and error on my own. I'm not going to beg... Which commits broke the ESS1888? I haven't tested it for a couple of weeks but I have an ESS1888 in one of my alpha boxes which worked a while ago after I fixed a few bits and pieces in the driver. The first breakage was with the introduction of newmidi IIRC. The mixer worked, but any dsp related functions were broken. See: sys/dev/sound/isa/es1888.c rev 1.3 In recent kernel even the mixer is dead and the soundcard is left in a state where all volumes are zeroed, preventing audio CD playing as well. See: sys/dev/sound/isa/es1888.c rev 1.4 I'll look into this. It won't be today though since I have an Aikido grading to go to this afternoon. Relevant kernel config options: options PNPBIOS controller isa0 controller eisa0 controller pci0 controller pnp0 device pcm0 I have to re-enable sbc0 to see if any changes therein apply to ESS as well. Should I have sbc0 in the first place? I think so. I'll make sure when I get a chance to hack on this. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Leif Neland wrote: On Sun, 12 Dec 1999, Nik Clayton wrote: (3) A big notice in UPDATING, saying that ata is the replacement for wd. Make wd require "options I_WANT_WD" or something similar, so that people can't simply re-config their existing configuration file. To be nasty: Change to to I_WANT_WD first. Next week: I_REALLY_WANT_WD Next week: I_REALLY_REALLY_WANT_WD and so on... This should force all to concider changing to ata... Leif Well, I've added (which was fairly easy) a warning mechanism to config(8) and have added warnings if the drivers are used. It's pretty loud but it shouldn't be able to be missed. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: lost disk contact errors [was: Re: HEADSUP: wd driver will be retired!]
It seems Vallo Kallaste wrote: On Sat, Dec 11, 1999 at 12:57:04PM -0800, Doug White [EMAIL PROTECTED] wrote: I'm getting the "lost disk contact" messages every now and then, but only on our mp3 machine with PIIX3 controller and IBM UDMA/66 disk. It's an PPro machine with Intel mobo. Can it be related to newer IBM disks? Depends on what 'now and then' is. The Deskstar series of drives was not intended to run 24/7, and therefore shut themselves down every week to clean the heads. Mhm, now I remember the discussion in -current list some time ago. It can be, yes, but I need to follow the logs to say for sure. About month ago the messages appeared several times per day, not per week. Thank you refreshing my memory :-) Well, I use alot of IBM's and I've newer seen them do this... Have you tried upping the timeout in ata-disk.c about line 426 to say 10s and see if it changes behavior ?? -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!
In message [EMAIL PROTECTED], Michael Kennett writes: Finally, I've noticed the following messages: Dec 11 13:54:50 rabbit /kernel: ad1: UDMA CRC READ ERROR blk# 0 retrying Dec 11 13:54:50 rabbit last message repeated 2 times Dec 11 13:54:50 rabbit /kernel: ad1: UDMA CRC READ ERROR blk# 0 falling back to PIO mode This is actually a very good example of where the new driver gives us a marked improvement: It has a fall back path for troubled hardware, to safe modes. -- 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: Reasonable decision-making [Re: HEADSUP: wd driver will be retired!]
In message [EMAIL PROTECTED], "Jordan K. Hubbard" 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. 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. I am keeping very close track of the messages from people who report problems with the new drivers, but I am totally ignoring the noise by people who "just on principle" are against this move. 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. Unless we break kernel configs with the wd driver in it, we will never get rid of it. -- 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 Sat, 11 Dec 1999 14:21:25 +0800 (WST), Michael Kennett wrote: Note that wd1 is not present. This caused a mild hickup when rebooting the new kernel, since the new ata controller assigned the labels ad0 and ad1 to the drives. It was not possible to boot into multiuser mode without changing the /etc/fstab file to rename the /dev/wd2* entries to /dev/ad1*. That was easy to fix, however for a newbie it might cause problems. I mention it now, since the upgrade from 3.x might need special handling of this case (?). You should use the kernel option "optionsATA_STATIC_ID" for such cases. At least it works for me :-) -- Dieter Rothacker To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Dieter Rothacker wrote: On Sat, 11 Dec 1999 14:21:25 +0800 (WST), Michael Kennett wrote: Note that wd1 is not present. This caused a mild hickup when rebooting the new kernel, since the new ata controller assigned the labels ad0 and ad1 to the drives. It was not possible to boot into multiuser mode without changin g the /etc/fstab file to rename the /dev/wd2* entries to /dev/ad1*. That was easy to fix, however for a newbie it might cause problems. I mention it now , since the upgrade from 3.x might need special handling of this case (?). You should use the kernel option "options ATA_STATIC_ID" for such cases. At least it works for me :-) I think this should only apply to the /dev/wd* compatability devices. ie: use the correct numbering for new installs onto ad*, but still support the old spread-out naming for wd*. This used to be more important as it required fiddling with $root_disk_unit, but the new mountroot code has relieved the pressure there. 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!
On Sat, 11 Dec 1999 18:28:42 +0800, Peter Wemm wrote: Dieter Rothacker wrote: You should use the kernel option "options ATA_STATIC_ID" for such cases. At least it works for me :-) I think this should only apply to the /dev/wd* compatability devices. ie: use the correct numbering for new installs onto ad*, but still support the old spread-out naming for wd*. This used to be more important as it required fiddling with $root_disk_unit, but the new mountroot code has relieved the pressure there. Why would you want to define "correct" numbering the non-spread-out numbering? Or did I misunderstand you? I have all my disks as master drives on the channels. Now, when I hook up another disk for backup or maintenance purposes, my numbering is messed up. With spread-out numbering I do not have to worry about anything... sounds more "correct" to me. -- Dieter Rothacker To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Audio support [was Re: HEADSUP: wd driver will be retired!]
"Jordan K. Hubbard" wrote: 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. The recent commits made existing support even worse. Yes, I'm talking about the ESS1888. It's more dead than before. I'll have to make the noise myself these days, and I can tell you it's no opera :-) In short: Gimme patches! I'll be happy to test and, in a spare hour, can even do some trial and error on my own. I'm not going to beg... -- 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: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED], Stephen McKay writes : 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". First of all, "core" is not really involved in this per se. It might be that these things have to be predicted by -core and handled "touchy feely" like: core: What if we do this decisive break with past ? public:Um, sounds scary. When will you do it? Will I lose anything? core: We think a month from now, and you will lose support for x and y. public: We don't use x and y any more, so fine. So far, whenever this has been tried, the public reponse have been: public:We don't want to change anything, ever! It's so hard! You must support all my hardware for ever and ever! instead of the current (caricatured for emphasis): core: We will do decisive break with past soon. Probably today. public:Oh my God! core: It's for your own good. You always complain and make it difficult! public:We don't want to change anything, ever! It's so hard! You must support all my hardware for ever and ever! I'm sure you will notice the similarity. -- 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
ata: lost disk contact errors [was: Re: HEADSUP: wd driver will be retired!]
On Fri, Dec 10, 1999 at 09:31:57PM +0100, Soren Schmidt [EMAIL PROTECTED] wrote: 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 ? Hmm, I have one in my development machine, so it takes a fair bit of beating, I haven't seen any of these problems. Could you mail me a dmesg, preferably from a verbose boot. I'm getting the "lost disk contact" messages every now and then, but only on our mp3 machine with PIIX3 controller and IBM UDMA/66 disk. It's an PPro machine with Intel mobo. Can it be related to newer IBM disks? 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: Thu Nov 25 13:23:02 EET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/Muzz Timecounter "i8254" frequency 1193200 Hz Timecounter "TSC" frequency 166195509 Hz CPU: Pentium Pro (166.20-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x612 Stepping = 2 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV real memory = 33554432 (32768K bytes) avail memory = 29683712 (28988K bytes) Preloaded elf kernel "kernel" at 0xc02bf000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02bf09c. module_register_init: MOD_LOAD (vesa, c02194a4, 0) error 6 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX3 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 xl0: 3Com 3c905-TX Fast Etherlink XL irq 10 at device 11.0 on pci0 xl0: Ethernet address: 00:60:08:05:58:14 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vga-pci0: ATI model 4755 graphics accelerator at device 17.0 on pci0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 8 virtual consoles, flags=0x200 fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 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 gusc0: Gravis UltraSound Plug Play PCM at port 0x220-0x22f,0x320-0x327,0x32c-0x32f irq 11 drq 5,7 on isa0 pcm0: GUS CS4231 on gusc0 unknown0: Disabled Device on isa0 unknown1: Disabled Device on isa0 unknown2: Disabled Device on isa0 unknown3: Disabled Device on isa0 ad0: IBM-DPTA-353750/P51OA30A ATA-4 disk at ata0 as master ad0: 35772MB (73261440 sectors), 7144 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 31 depth queue, DMA acd0: 685A/8.4D CDROM drive at ata1 as master acd0: read 1171KB/s (1171KB/s), 120KB buffer, PIO acd0: supported read types: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked Mounting root from ufs:/dev/wd0s1a WARNING: / was not properly dismounted xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done ata0-master: ad_timeout: lost disk contact - resetting ata0: resetting devices .. done -- Vallo Kallaste [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!
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. That's simply not true. It's taken me less than 5 minutes total to respond to these silly emails, and it'd take me at least a week to get familiar enough with the code to do anything useful, and another 3-4 weeks to get it past the maintainer's filters (validly so), because my one week of understanding would be missing alot of lessons learned that I'm not aware of. However, it appears to be the mindset of the developers that the problems that people complain about are either trivially easy to solve that it's expected that unless they have a solution to it, they're stupid. Or, the problem is so hard that they want people not to complain unless they have a solution for it, since expecting *THE DEVELOPERS* to solve such a protracted and complex set of problems is ludicrous. You must be an idiot to not understand this, or a complete boob for expecting a member of a volunteer project to spend his free time working on it. In other words, and opion shared that is contrary to the developers implies stupidity on the part of the user. It's a no-win situation for everyone involved. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SiS ata Driver (was Re: HEADSUP: wd driver will be retired!)
On Thu, Dec 09, 1999 at 11:28:20AM +0100, Soren Schmidt wrote: It seems Soren Schmidt wrote: It seems Richard Seaman, Jr. wrote: On Wed, Dec 08, 1999 at 03:02:37PM +0100, Soren Schmidt wrote: OK, you asked for it, following is a patch to support the sis 5591 chipset. Remember this is done blindfolded, I have no HW to test on, but you guys do :) Seems to work. I'll let it run for a few days, but I'd guess it is fine. Great, I have a sligthly modified version that I'd like you to test, but it'll have to wait until I get home to my dev box. Thanks for testing it out!! Can I have you try this patch instead, it is much simpler, and should give the same results if I read the SiS specs right.. Tried it. Same result as the last patch. Seems to work fine. If you want the dmesg, let me know (same as last time, which I sent you). No problems over the last 2 days with the ata driver. FYI: wd vs ata on AMD 266 with SiS 5591 and IBM-DJNA-371800: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU WD512 9204 95.1 13615 68.5 5741 34.0 10051 92.2 15282 45.4 135.9 3.6 ATA 512 9446 95.2 13723 72.1 4430 25.4 10187 92.0 14836 42.9 132.0 3.5 -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reasonable decision-making [Re: HEADSUP: wd driver will be retired!]
On Fri, Dec 10, 1999 at 11:20:19PM -0800, Jordan K. Hubbard wrote: my strategy on the whole affair at this point has been to simply make marks on a tally-sheet near my keyboard, While there is now working support for SiS 5591, and thus my initial objection to removal of the wd drivers is now gone, I would still vote to retain it for some intermediate period. You can put my vote in the appropriate column of your tally. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 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 Sat, Dec 11, 1999 at 09:00:52AM -0800, Bob Vaughan wrote: Subject: Re: HEADSUP: wd driver will be retired! Date: Fri, 10 Dec 1999 19:19:43 +0100 From: Poul-Henning Kamp [EMAIL PROTECTED] 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 Bad idea.. this would create problems for people who run -current, but read mail on -stable boxes.. If -current is broken, how are they going to report it? Maybe phk will volunteer his private phone number for those cases? ;-) ;-) Seriously: I don't expect NOTE TO="SELF" to be meant seriously. Right? [has -current on 3 axp and 2 intels, mails from -stable] -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org 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 11-Dec-99 Poul-Henning Kamp wrote: 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.i3861999/11/28 17:51:06 1.282 +++ files.i3861999/12/11 01:31:00 @@ -318,6 +318,7 @@ i386/isa/stallion.c optionalstl i386/isa/tw.coptionaltw i386/isa/vesa.c optionalvga +i386/isa/SirNotAppaeringInThisKerenl.c optionalwd i386/isa/wd.coptionalwd i386/isa/wd.coptionalwdc i386/isa/wfd.c optionalwfd I could go along with that. And probably an #error "Don't use this driver, use ata-disk instead" in wd.d What about no change to files.i386 (so that if someone's computer can't handle ata for the moment its one less step they have to go to compile a kernel with the old system), keep the #error above, but wrap it in a #ifndef FORCE_WD/#endif or something similar. Then, if someone does have to have the old drivers for some reason, they can stick 'option FORCE_WD' in their kernel config. You could then choose where to document FORCE_WD.. either in expanding the #error message to be more verbose and detailing the existance of this option if it's use is necessary (my preference), or make it a "closely guarded secret" you have to post a question to -current to get. -current people are not bozos, if you complete the ata driver enough in the ata message, they will switch to it, and they will know to even if they are a luser who's not reading -current like they should. FWIW, I've been using ata on my -current test box since I've started running -current (about two months) w/o any problems. -- 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! -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 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. I'll have to second you on that one, I've been applying patchs of my own as well as other's patchs to make my soundcard even detect. I used to be able to get my ViBRA16X to work using the Voxware drivers, but since the PnP changes, I've had to use pcm because Voxware will no longer detect my soundcard with the bios in PnP OS mode. (And when I turn PnP OS off, the OS won't boot) My modem which used to be detected simply as sio1, now won't even attach to the sio driver. 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. :-) I agree, we need to start supporting that hardware that currently doesn't work, but used to work if we want to keep our user base growing (I personally have won 30 converts from Linux, and about 4 new users). = | 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
Re: Audio support [was Re: HEADSUP: wd driver will be retired!]
Just a question which I'm not sure is soundcard related. My xmms no longer starts up anymore, it just hangs in Poll before it actually puts anything on the display, is that because /dev/dsp isn't working? = | 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/| = On Sat, 11 Dec 1999, Kenneth Wayne Culver wrote: 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. I'll have to second you on that one, I've been applying patchs of my own as well as other's patchs to make my soundcard even detect. I used to be able to get my ViBRA16X to work using the Voxware drivers, but since the PnP changes, I've had to use pcm because Voxware will no longer detect my soundcard with the bios in PnP OS mode. (And when I turn PnP OS off, the OS won't boot) My modem which used to be detected simply as sio1, now won't even attach to the sio driver. 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. :-) I agree, we need to start supporting that hardware that currently doesn't work, but used to work if we want to keep our user base growing (I personally have won 30 converts from Linux, and about 4 new users). = | 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 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, Dec 10, 1999 at 09:22:55PM -0700, 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. BUT not any longer. Thus we have no choice but fully make the sd-da change. [David says this as last weekend he had to change fstabs and /dev for 5 of his machines] -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Audio support [was Re: HEADSUP: wd driver will be retired!]
Kenneth Wayne Culver wrote: 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. I'll have to second you on that one, I've been applying patchs of my own as well as other's patchs to make my soundcard even detect. I used to be able to get my ViBRA16X to work using the Voxware drivers, but since the PnP changes, I've had to use pcm because Voxware will no longer detect my soundcard with the bios in PnP OS mode. (And when I turn PnP OS off, the OS won't boot) My modem which used to be detected simply as sio1, now won't even attach to the sio driver. Regarding the modem.. Look in sys/isa/sio.c for sio_ids[]. Look up the ID of your modem (pnpinfo) and add the logical ID (not the vendor ID) to the table. It should work, and when it does, please send a patch. 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!
"Dieter" == Dieter Rothacker [EMAIL PROTECTED] writes: Dieter Why would you want to define "correct" numbering the Dieter non-spread-out numbering? Or did I misunderstand you? I Dieter have all my disks as master drives on the channels. Now, Dieter when I hook up another disk for backup or maintenance Dieter purposes, my numbering is messed up. Or worse, on a file server where you lose a low-numbered disk, not only does that one go away, but everything higher numbered loses as well. This "feature" does nothing other than introduce a gratuitous backwards-incompatibility. There is nothing wrong with the "old" scheme. I've loathed this behaviour since it was introduced into SCSI/CAM, and would rejoice at its removal. --lyndon 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 Sat, 11 Dec 1999, Lyndon Nerenberg wrote: "Dieter" == Dieter Rothacker [EMAIL PROTECTED] writes: Dieter Why would you want to define "correct" numbering the Dieter non-spread-out numbering? Or did I misunderstand you? I Dieter have all my disks as master drives on the channels. Now, Dieter when I hook up another disk for backup or maintenance Dieter purposes, my numbering is messed up. Or worse, on a file server where you lose a low-numbered disk, not only does that one go away, but everything higher numbered loses as well. This "feature" does nothing other than introduce a gratuitous backwards-incompatibility. There is nothing wrong with the "old" scheme. I've loathed this behaviour since it was introduced into SCSI/CAM, and would rejoice at its removal. --lyndon As I understand it, cam or pre-cam or wd or ata it is simply an issue of defaults. If you plan to use disks that die or become removed, simply read LINT on how to wire your disk id's. 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, Dec 10, 1999 at 05:15:29PM +0100, Poul-Henning Kamp wrote: Please, help Sos fix ATA if you know of a problem. Please, help fix PCCARD if you know of a problem. Ok, so now the attitude is I need to spend all my time: 1. Fix ATA to work on my laptop (there are timeout issues) 2. Fix PCCARD on my laptop so I can suspend 3. Fix if_ep so my 574tx works again. 4. Fix if_xe so I could use my other 10/100 PCCard while the 574tx support is broke. 5. Fix if_ep so the 389d doesn't run only on the watchdog timer 6. Fix if_ed if that becomes broken *again* on the laptop 7. Fix newpcm so I have sounds support (was broken on two of my machines) 8. Fix `make world' so I can fully sync things again. 9. Fix if_fxp to not crash on my Alpha? Is this list long enough yet? I only have X amount of FreeBSD time. Should I just start O'BrienBSD since I'm now have to develop the whole OS? OR, I can work on the compiler and close my open PRs. Of course if I simply don't update my machine for 3 months, god knows if my compiler changes won't break world or cause other problems. -- -- David([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!
"Adam" == Adam [EMAIL PROTECTED] writes: Adam As I understand it, cam or pre-cam or wd or ata it is simply Adam an issue of defaults. If you plan to use disks that die or Adam become removed, simply read LINT on how to wire your disk Adam id's. I understand. The point is: why? I had a perfectly good working system. Why should I have to make changes to support this new behaviour? What is the "benefit" of the new system? All I see is a make-work project for all my kernel configuration files. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
Lyndon Nerenberg wrote: "Adam" == Adam [EMAIL PROTECTED] writes: Adam As I understand it, cam or pre-cam or wd or ata it is simply Adam an issue of defaults. If you plan to use disks that die or Adam become removed, simply read LINT on how to wire your disk Adam id's. I understand. The point is: why? I had a perfectly good working system. Why should I have to make changes to support this new behaviour? What is the "benefit" of the new system? All I see is a make-work project for all my kernel configuration files. The old wd driver was *solely* this way. It was not possible to have a dynamic system. If you didn't have a 'device wdX at wdcY drive Z', you had to recompile the kernel just to get to it. The scsi system has always been dynamic with a wiring *option* right from as far back as 2.0. CAM didn't change this. What is different with ata is that it has a strange hybrid of the two. By default (no options) it behaves like scsi. With ATA_STATIC_ID, it does something different - it emulates the old GENERIC layout, and it's not possible to change that. It used to be possible to have wd0 on wdc0 drive 1, and wd1 on wdc0 drive 0 (ie: backwards). It has no wiring option, but this isn't hard to add for isa-compatable devices. However, I point you to this example: ata-pci0: Intel PIIX4 ATA controller at device 7.1 on pci0 ata-pci0: Busmastering DMA not enabled ata-pci1: HighPoint HPT366 ATA controller irq 11 at device 10.0 on pci0 ata-pci1: Busmastering DMA supported ata2 at 0x9800 irq 11 on ata-pci1 ata-pci2: HighPoint HPT366 ATA controller irq 11 at device 10.1 on pci0 ata-pci2: Busmastering DMA supported ata3 at 0xa400 irq 11 on ata-pci2 ata-pci3: HighPoint HPT366 ATA controller irq 10 at device 11.0 on pci0 ata-pci3: Busmastering DMA supported ata4 at 0xb000 irq 10 on ata-pci3 ata-pci4: HighPoint HPT366 ATA controller irq 10 at device 11.1 on pci0 ata-pci4: Busmastering DMA supported ata5 at 0xbc00 irq 10 on ata-pci4 ata-pci5: HighPoint HPT366 ATA controller irq 12 at device 12.0 on pci0 ata-pci5: Busmastering DMA supported ata6 at 0xc800 irq 12 on ata-pci5 ata-pci6: HighPoint HPT366 ATA controller irq 12 at device 12.1 on pci0 ata-pci6: Busmastering DMA supported ata7 at 0xd400 irq 12 on ata-pci6 ad0: QUANTUM FIREBALL CX10.2A/A3F.0B00 ATA-4 disk at ata2 as master ad0: 9787MB (20044080 sectors), 19885 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad1: QUANTUM FIREBALL CX6.4A/A3F.0B00 ATA-4 disk at ata3 as master ad1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, UDMA33 ad2: QUANTUM FIREBALL CX6.4A/A3F.0B00 ATA-4 disk at ata4 as master ad2: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad2: 16 secs/int, 1 depth queue, UDMA33 ad3: QUANTUM FIREBALL CX6.4A/A3F.0B00 ATA-4 disk at ata5 as master ad3: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad3: 16 secs/int, 1 depth queue, UDMA33 ad4: QUANTUM FIREBALL CX6.4A/A3F.0B00 ATA-4 disk at ata6 as master ad4: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad4: 16 secs/int, 1 depth queue, UDMA33 ad5: QUANTUM FIREBALL CX6.4A/A3F.0B00 ATA-4 disk at ata7 as master ad5: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad5: 16 secs/int, 1 depth queue, UDMA33 Note that ata0 and ata1 are missing and that there are no fixed or anchorable points. It's *impossible* to wire this down with config(8), either for wdc or ata. I know it isn't wired because I got burned setting it up. I started with a controller in the right-most slot. It just happened that this motherboard that's the highest pci device ID slot. So, after setting up and adding the other two controllers, ata2 suddenly became ata7. ad0 became ad4. ATA_STATIC_ID wouldn't help because it would still have changed (ad0 would be ad4 in static mode, and after plugging in the new controllers, ad4 would have changed to at14. ie: no use at all.) wdc does not support this configuration. It can't hook onto arbitary pci ide devices. With a largely dynamic bus system like PCI etc, we need a better solution. Static wiring is not it. What Mike Smith suggested is probably about the best we can do and that requires devfs support. Each disk label would have some identifier which would be a name for the disk when attached. ie: you name your boot ide disk "foo" and it's device nodes become "foo", "foos1a" or whatever. If you move that disk from one cable to another, the device name remains constant. If you add a new controller to the motherboard and the PCI bus is renumbered, you're still ok. But.. that requires devfs to make it work. 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!
... The scsi system has always been dynamic with a wiring *option* right from as far back as 2.0. CAM didn't change this. as far back as 386BSD and the patchkit. -- 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!
phk wrote: This is *CURRENT* remember ? We want this transistion done and tested before current becomes 4.0-RELEASE. The time is NOW! Not quite: this is -current, 4 days before a functionality freeze and potentially less than one month before 4.0-RELEASE. Replacing critical parts of the system at this stage is a bad idea because it's simply not going to leave enough time for the ata drivers to mature and stabilise to the same level as the wd drivers. By all means, make the transition, but if you're going to do it, please don't release 4.0 in early Jan. As an end user, I have no problem with the removal of the wd drivers (or with releasing 4.0 a little later than planned), but if making this transition is something which is going to potentially compromise either stability or hardware support due to the time-scales involved, then it is ill-advised. This isn't Linux, you know. Nick 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 Sat, Dec 11, 1999 at 02:48:12PM -0700, Lyndon Nerenberg wrote: "Dieter" == Dieter Rothacker [EMAIL PROTECTED] writes: Dieter Why would you want to define "correct" numbering the Dieter non-spread-out numbering? Or did I misunderstand you? I Dieter have all my disks as master drives on the channels. Now, Dieter when I hook up another disk for backup or maintenance Dieter purposes, my numbering is messed up. Or worse, on a file server where you lose a low-numbered disk, not only does that one go away, but everything higher numbered loses as well. This "feature" does nothing other than introduce a gratuitous backwards-incompatibility. There is nothing wrong with the "old" scheme. I've loathed this behaviour since it was introduced into SCSI/CAM, and would rejoice at its removal. I don't see why one should not wire-down the SCSI devices to whatever one's preference is. This works just brilliantly. But maybe it is that me having a small mountain of StorageWorks hotplug SCSI devices makes me defensive in this respect.. W/ -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Audio support [was Re: HEADSUP: wd driver will be retired!]
Here is a patch for my modem:
--- sio.c.orig Sat Dec 11 19:51:29 1999
+++ sio.c Sat Dec 11 19:51:20 1999
@@ -553,6 +553,7 @@
{0x31307256, NULL}, /* USR3031 */
{0x8020b04e, NULL}, /* SUP2080 */
{0x8024b04e, NULL}, /* SUP2480 */
+{0x7420b04e, NULL},/* SUP2070 */
{0}
};
=
| 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/|
=
On Sun, 12 Dec 1999, Peter Wemm wrote:
Kenneth Wayne Culver wrote:
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.
I'll have to second you on that one, I've been applying patchs of my own
as well as other's patchs to make my soundcard even detect. I used to be
able to get my ViBRA16X to work using the Voxware drivers, but since the
PnP changes, I've had to use pcm because Voxware will no longer detect my
soundcard with the bios in PnP OS mode. (And when I turn PnP OS off, the
OS won't boot) My modem which used to be detected simply as sio1, now
won't even attach to the sio driver.
Regarding the modem.. Look in sys/isa/sio.c for sio_ids[]. Look up the
ID of your modem (pnpinfo) and add the logical ID (not the vendor ID) to
the table. It should work, and when it does, please send a patch.
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!
I think this should only apply to the /dev/wd* compatability devices. ie: use the correct numbering for new installs onto ad*, but still support the old spread-out naming for wd*. This used to be more important as it required fiddling with $root_disk_unit, but the new mountroot code has relieved the pressure there. Hmm. That'd actually be quite doable, but I think it might massively confuse people running in 'compatibility' mode. IMO the 'clean break' approach may have more initial noise overhead, but in the long run it's not going to scare folks so much. -- \\ 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 Sat, 11 Dec 1999, Lyndon Nerenberg wrote: Or worse, on a file server where you lose a low-numbered disk, not only does that one go away, but everything higher numbered loses as well. This "feature" does nothing other than introduce a gratuitous Amen to this. If the default kernel or GENERIC shipped with the disks wired, it would be so much nicer. NT generally gets this one right, once you assign letters to partition, they tend to stick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
"Dieter" == Dieter Rothacker [EMAIL PROTECTED] writes: Dieter Why would you want to define "correct" numbering the Dieter non-spread-out numbering? Or did I misunderstand you? I Dieter have all my disks as master drives on the channels. Now, Dieter when I hook up another disk for backup or maintenance Dieter purposes, my numbering is messed up. Or worse, on a file server where you lose a low-numbered disk, not only does that one go away, but everything higher numbered loses as well. This "feature" does nothing other than introduce a gratuitous backwards-incompatibility. There is nothing wrong with the "old" scheme. I've loathed this behaviour since it was introduced into SCSI/CAM, and would rejoice at its removal. This is the usual poorly thought out argument, which fails to note that when you lose a disk you're already screwed due by /etc/fstab and the need to hard-mount local filesystems. The "right" solution is and has always been to name your disks and mount them by name. Once devfs is a reality, we'll be able to do just this. Until then, the problem's not really as bad as you make it out to be. -- \\ 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] "David O'Brien" writes: : On Fri, Dec 10, 1999 at 09:22:55PM -0700, 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. : : BUT not any longer. Thus we have no choice but fully make the sd-da : change. [David says this as last weekend he had to change fstabs and : /dev for 5 of his machines] Are you sure this isn't just for "special" devices (eg root, default swap and the like)? I have a machine where da0 is root, but my jaz drive is sd1c which is running a kernel that post-dates the sd removal from the kernel. 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] "David O'Brien" writes: : 2. Fix PCCARD on my laptop so I can suspend What's the current issue? I have 0 problems suspending/resuming. I'd like to know what is still broken, if anything, with the latest -current. : OR, I can work on the compiler and close my open PRs. Of course if I : simply don't update my machine for 3 months, god knows if my compiler : changes won't break world or cause other problems. Actually, the put up or shut up argument doesn't apply to people that have done and continue to do a significant amount of work in other areas. At least I would be greatly offended if someone hit me with it in an area other than security or pccard when I complained about (and helped to diagnose) a problem in their area of code. Me, I'm tired of maintaining the old pccard code while writing new, but I know it has to be done... 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] Mike Smith writes: : This is the usual poorly thought out argument, which fails to note that : when you lose a disk you're already screwed due by /etc/fstab and the : need to hard-mount local filesystems. No. You aren't screwed. I have a system that needs /, /var, /usr and /usr/local (all on one disk) to boot, but puts the fsck/mount of all the other file systems into the background. If one of them fails, all the others are still available. : The "right" solution is and has always been to name your disks and mount : them by name. Once devfs is a reality, we'll be able to do just this. : Until then, the problem's not really as bad as you make it out to be. I'd have to disagree with this. I was constantly getting burned by the scsi system until I started hard wiring my scsi disks. The JAZ drive I have had a period in its life when sometimes it wouldn't power on (due to a bad power connection it was later discovered), so sometimes at boot the system would see it and sometimes not. My /jaz partition would wound up being where my /big partition should be and my /big partition wouldn't be there at all when this happened. After hardwiring, /jaz was the only one affected. The same issue is there with ethernet interfaces too, btw. I have a server that has 2 single fxp cards and 4 dual fxp cards. We need to replace one of the single fxp cards with a dual one (no more slots and need another interface), but to do this will require lots of renumbering/cable shuffle, etc because ALL the interface numbers will change when we do this. I'm not convinced that the "right" solution is really "right" here. Warner 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
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: 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: 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: 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
