4.4-RELEASE hangs during boot on SMP machine.
Hi, The subject tells the problem. The machine is a SMP machine with two PII 450 with onboard IDE and SCSI. Another IDE controller is attached too, a Promose FastTrak 100 TX4. I have tried to disable things like the parallel port, serial port, floppy controller, USB, the onboard SCSI-controller without getting any progress in the boot process. Booting with boot -v, the last lines before it hangs are: Device configuration finished. bpf: l0 attached bpf: sl0 attached What I really want to know is how to get more information about what's happening to give a better problem description. Can anyone give me a hint? /jonas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-RELEASE hangs during boot on SMP machine.
Try using just the primary IDE controller only and make sure its not sharing its IRQ with anyone else. ---Mike At 11:32 AM 9/20/2001 +0200, jonas wrote: Hi, The subject tells the problem. The machine is a SMP machine with two PII 450 with onboard IDE and SCSI. Another IDE controller is attached too, a Promose FastTrak 100 TX4. I have tried to disable things like the parallel port, serial port, floppy controller, USB, the onboard SCSI-controller without getting any progress in the boot process. Booting with boot -v, the last lines before it hangs are: Device configuration finished. bpf: l0 attached bpf: sl0 attached What I really want to know is how to get more information about what's happening to give a better problem description. Can anyone give me a hint? /jonas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: hw.ata.wc hw.ata.tags softupdates short question
Date: Fri, 21 Sep 2001 12:18:32 +0930 (CST) From: Daniel O'Connor [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On 20-Sep-2001 Nuno Teixeira wrote: For what I heard, I concluded that we shouldn't use softupdates with write cache turned on. The first time that I tried this I loose a lot of work due to a power failure. You shouldn't use write caching, period. Well you can but if you lose power you WILL lose data. If you just want speed and care naught about your data go ahead :) (I guess a UPS would increase your confidence) 1. Can I use softupdates with hw.ata.wc=1 and hw.ata.tags=1 safely? 2. Does hw.ata.tags=1 allows write caching to be safely turned on really? No, write caching tells the drive Please lie to me about command completion so when the OS performs a write the drive caches it and says yes that's on disk, when it isn't. OK. I've seen some questionable information in this thread and some that I'm almost sure is simply wrong. I'm going to describe the situation as I understand it and if you are SURE something I say is wrong, please correct it. (Especially if you write disk drivers for FreeBSD. I have written disk drivers, but not in FreeBSD and not for ATA disks, so am not really competent.) 1. IBM drives that do tagging are claimed to be safe. The way tagging works should assure that the critical metadata is always written to disk. And tagging depends on write cache to work, but you don't need to turn it on as turning on tagging DOES turn on write cache as it is used by tagging and attempting to turn it on with the hw.ata.wc sysctl is meaningless and ignored. 2. On a disk that has a lot of writes like a news server is especially susceptible to data loss. If a system is not UPS protected and running software to shutdown cleanly before the UPS dies, write cache on a server is with ATA disks is probably a bad idea. But then again, ATA disks on a server are probably a bad idea. 3. The combination of soft updates and WC is especially risky as you might lose both the last bit of data written to disk, but metadata that can lead to a major corruption. Even then, it's reasonably unlikely, but I don't think reasonably unlikely is reasonable. 4. Some disks always write data (eventually). Some NEVER write out data that is re-written frequently. It's just about impossible to tell which a drive does and the only documentation is the drive's micro-code which you are very unlikely to ever see and less likely to understand unless you write disk code. (I have a friend who does and it is about as opaque a bunch of C++ as I have ever seen unless you REALLY understand disk design.) 5. Many disks seem to make NO attempt to write the data on power outage. I run with WC on my laptop because it's extremely unlikely to lose power. But I also back up the disk (dd mirroring) on a regular basis just in case. It's also worth noting that Soren reversed himself and made wc default a few months after 4.3 was released. I assume it defaults to on in 4.4, although I have not checked. This makes me suspect that he decided that the risk was reasonable. But I really should not speak for him. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-RELEASE and tools directory
On Thu, 20 Sep 2001, Igor Roshchin wrote: I am not able to find this in -stable for this week, so, I wonder why the tools directory is missing in 4.4-RELEASE (At least on the web-site, I haven't checked the ISO-image yet) ? Seems to be missing on both the 4.4-install.iso and the 4.4-mini.iso Annelise -- Annelise Anderson Author of: FreeBSD: An Open-Source Operating System for Your PC Book Website: http://www.bittreepress.com/FreeBSD/introbook/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: hw.ata.wc hw.ata.tags softupdates short question
Daniel O'Connor [EMAIL PROTECTED] types: On 20-Sep-2001 Nuno Teixeira wrote: For what I heard, I concluded that we shouldn't use softupdates with write cache turned on. The first time that I tried this I loose a lot of work due to a power failure. You shouldn't use write caching, period. Matt Dillon disagrees. From the tuning(7) man page: There is a new experimental feature for IDE hard drives called hw.ata.tags (you also set this in the bootloader) which allows write caching to be safely turned on. This brings SCSI tagging features to IDE drives. In other words, write caching is safe if the drive and driver supports tagged queuing. For IDE drives, Matt goes on to say: As of this writing only IBM DPTA and DTLA drives support the feature. Warning! These drives apparently have quality control problems and I do not recommend purchasing them at this time. If you need performance, go with SCSI. No, write caching tells the drive Please lie to me about command completion so when the OS performs a write the drive caches it and says yes that's on disk, when it isn't. Tagged queuing allows the writes to complete in a different order than they were issued. This allows the drives to both have an effective write cache, *and* to notify the controller when sectors are actually on the disk. Kevin Oberman [EMAIL PROTECTED] types: 1. IBM drives that do tagging are claimed to be safe. The way tagging works should assure that the critical metadata is always written to disk. To clarify, it isn't the drive that knows about critical metadata. That's softupdates doing it's job. Softupdates has to trust the drive to make sure the critical metadata is on the disk. This is why write caching sans tagged queuing and softupdates are such a bad idea. This is also why a file system with soft updates enabled simply ignore the async flag on any mount request. It's also worth noting that Soren reversed himself and made wc default a few months after 4.3 was released. I assume it defaults to on in 4.4, although I have not checked. This makes me suspect that he decided that the risk was reasonable. But I really should not speak for him. If you wade through the mail lists during the 4.3 beta and release periods, what you'll find is that disk performance took a major hit - some people claimed as much as a factor of 6. No one discussed any change in the risk assessment. I think he turned it back on for the same reason he turned it off: popular demand URL: ttp://www.FreeBSD.org/cgi/getmsg.cgi?fetch=51636+0+/usr/local/www/db/text/2001/freebsd-mobile/20010318.freebsd-mobile . mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
kernel config fails if src/sys/compile directory doesn't exit. bug?
i upgraded recently to 4.4-release (releng_4_4 cvsup tag) from -prerelease. i noticed that kernel config fails (in /usr/src/sys/i386/conf) if /usr/src/sys/compile directory doesn't exist. tried these variations... # [/usr/sbin/]config [-r] BOVINE ...error message was... config: ../../compile/BOVINE: No such file or directory ...after creating the ../../compile directory, config ran and kernel was installed w/o problems. questions: - shouldn't config create the src/sys/compile? - is this a software (known) bug? - if config isn't supposed to create the compile directory and kernel config/build fails, shouldn't it be documented? by the way, config(8) talks only about the destination directory creation (in this case, BOVINE) but not any intermediary... ... config should be run from the conf subdirectory of the system source (usually /sys/ARCH/conf), where ARCH represents one of the architectures supported by FreeBSD. config creates the directory ../../compile/SYSTEM_NAME or the one given with the -d option as neces- sary and places all output files there. If the output directory already exists and the -r flag was specified, it will be removed first. ... -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: RE: hw.ata.wc hw.ata.tags softupdates short question
Basically write-caching becomes irrelevant when you have tags, because the host does not have to wait for a write to complete before starting the next one. When IDE tags work, write caching no longer matters. Without IDE tags you have to turn write caching on in order to get similar write performance. Without write caching or tags for IDE, the driver must wait for a write to get completely on the disk and return an acknowledgement before it can begin queueing the next write. Unfortunately IDE drives are driven by the consumer market. They just don't work all that well if write caching is turned off (and tags are a relatively new feature for IDE), which is why we turned write-caching back on by default for IDE. While this theoretically introduces the possibility of out-of-order writes, and while out of order writes have been shown to occur under certain heavy load situations, we do not know of a single case where the IDE write caching feature has actually resulted in any corrupt data. Now with that all said it may seem that IDE + tags is the perfect solution for IDE. Unfortunately IDE is a moving target.. the chances of getting a highly reliable IDE solution are fairly low. Just look at all the problems we have with something as simple as IDE+DMA. SCSI hard drives almost universally have tags so this isn't an issue with SCSI. The simple answer is that if you care at all about reliability, pay the premium for SCSI. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
cdda2wav does not work for me
Hello, yesterday i tried to rip an audio cdrom with cdda2wav. As far as i remember this worked 4 months ago on my box at home. Now a track will be copied fast but finally there are a lot of errors like. acd0: READ_CD - ILLEGAL REQUEST asc=21 ascq=00 error=04 Of course i use latest FreeBSD-STABLE. I can read tracks with Nero under Windows btw.. More messages are attached. Messages -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh
