Re: burncd...
I had similar trouble, but can burn under windows (except 2k which is buggy) j. -- Close your eyes. Now forget what you see. What do you feel? -- My heart. -- Come here. -- Your heart. -- See? We're exactly the same. Jon Smith -- Senior Math Major @ Purdue On Sat, 19 Aug 2000, Michael Matsumura wrote: On Sat, Aug 19, 2000 at 01:51:25PM +0100, Ben Smithurst wrote: Michael Matsumura wrote: What's the status on the development of burncd? Looks like it hasn't been updated since the beginning of March...is it stable? I can't burn a CD without it failing with the following: burncd is fairly simple, and it looks to me like this is a problem either in the atapicd driver or with your hardware. I could burn CDs in linux with cdrecord, so its probably not my hardware...damn :\ Is there a better way to burn a CD with an ATAPI cd-rw? There are some scripts in /usr/share/examples/atapi, which you might get to use. If you get better results, you might like to investigate what the two programs to differently and try to fix burncd. [root:~]# ls -l /usr/share/examples/atapi/ total 0 [root:~]# ls -l /usr/src/share/examples/atapi gnuls: /usr/src/share/examples/atapi: No such file or directory Thanks for the MX record information...learn something new every day... :) -- Michael Matsumura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: remove empty TEMPROOT dirs at mergemaster's end? (was: cvs commit: src/usr.sbin/mergemaster mergemaster.sh)
Gerhard Sittig wrote:
On Thu, Aug 17, 2000 at 12:38 -0700, Doug Barton wrote:
I think I am confused, but that's why we like to solicit
feedback from users. :) Most of the time when people leave them
temproot directory around it's to deal with a specific file or
files that they decided to merge later. If you leave that
directory behind and there are real files left to deal with mm
spits out a list of files for your consideration, which can be
handled with 'mergemaster -r' or by hand.
That's when I thought "Why not make the directory hierarchy look
like the mm list of what needs further attention? Without
burying these files in a tree with mostly empty directories.".
But that only matters to people who go in there by hand, and that's a very
small percentage.
I'm human and thus I'm subject to forgetting what I've seen
before on the screen (the file list) once I had a look at the
first two files and managing the needed merge. :)
99% of the files you'd ever want to merge by hand are in /etc. Not too
hard to remember. :)
Maybe what is left to do is a one (or two) line patch adding some
echo 'to remove the empty dirs but leave the files intact type'
echo '"find' ${TEMPROOT} '-type d -size 0 -delete" (w/o quotes)'
I was attempting to make a rather poor joke, actually. It would be much
easier to do 'find . -type f -size +0'. The point is that mm already
handles the cases that a normal user is likely to need handled. People who
want to go tromping through directory structures should be learning the
proper use of unix commands that already exist for those purposes. For
instance, if you actually wanted to prune the directory structure 'find -d
. -type d -links 2 -exec rmdir {} \;' would do a pretty good job
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Crystal Semi (pcm) Audio card probing problem
This may be related to the problem reported in the "pcm0 play interrupt timeout, channel dead" thread. The problem in that the Crystal Audio sound card on my ThinkPad 600E is inconsistently probed. The result is that it is sometimes pcm0 and sometimes pcm1. If I get this from my device probe, the CS423x is pcm1: csa0: Crystal Semiconductor CS4610/4611 Audio accelerator mem 0x5000-0x500f,0x5010-0x50100fff irq 11 at device 6.0 on pci0 pcm0: CS461x PCM Audio on csa0 pcm0: ac97 codec invalid or not present (id == 0) device_probe_and_attach: pcm0 attach returned 6 pcm1: CS423x-PCI at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 But, it it probes like this, the "real" sound device is pcm0: csa0: Crystal Semiconductor CS4610/4611 Audio accelerator mem 0x5000-0x500f,0x5010-0x50100fff irq 11 at device 6.0 on pci0 device_probe_and_attach: csa0 attach returned 6 pcm0: CS423x-PCI at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 It seems about 50/50 on which way it probes for any given reboot. Of course, every time it flips, I need to log in a s root and switch the device over. This is at least a bit of a pain. Has anyone got an explanation of why this happens and if there is a chance of getting it fixed? It bothers me when my system acts in a non-deterministic fashion in something that should be as repeatable as a device probe! It also wastes irq 11 in the first case and I have a tight IRQ situation on that system, in any case. It's been doing this since I upgraded to 4.0-Stable about a month after 4.0 was released and about three days after Xircom Ethernet support went in. It may have been doing it under 3.4, but I never used the audio, so I really don't know. 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: mt broken?
Mike Harding wrote: The man page is incorrect - it specifies /dev/nsa0. But what was below wasn't the man page but the output of the command. From /usr/src/sys/sys/mtio.h : #ifndef _KERNEL #define DEFTAPE "/dev/nsa0" #endif It appears to be set wrong. Mike Date: Fri, 18 Aug 2000 23:57:35 -0500 From: Mike Murphree [EMAIL PROTECTED] X-Accept-Language: en Content-Type: text/plain; charset=iso-8859-15 Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists Ok, what happened to this: %mt status mt: /dev/nsa0: No such file or directory It's missing an 'r' in the device. From dmesg: FreeBSD 4.1-STABLE #0: Mon Aug 14 02:23:31 CDT 2000 Waiting 2 seconds for SCSI devices to settle sa0 at ncr0 bus 0 target 5 lun 0 sa0: AIWA GD-8000 0119 Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 7) As expected, the following works normally: mt -f /dev/nrsa0 status Thanks, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: burncd...
Michael Matsumura wrote: [root:~]# ls -l /usr/share/examples/atapi/ total 0 [root:~]# ls -l /usr/src/share/examples/atapi gnuls: /usr/src/share/examples/atapi: No such file or directory I guess it was removed for 4.x since burncd was added. The burndata script is basically just: device=/dev/r$1 wormcontrol -f$device prepdisk double wormcontrol -f$device track data dd if=$2 of=$device bs=20k wormcontrol -f$device fixate 1 onp I don't know if this will help though, or even if it will work at all. I guess you'll get the same problem as this probably does similar things to burncd. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: custom kernel problem
Hi! The result of the 'file' command on the generated core file (if any) would help knowing which tool really segfault! Phil. On 18 Aug, Greg Prosser wrote: Is it the compiler or make that is segfaulting? Better phrasing: Do any other system binaries segfault? Is there a noticeable pattern or perhaps similarities? The last time I worked on a machine where make/other stuff started segfaulting, it turned out to be 'cc' segfaulting, and that was at the fault of either some bad ram, or other hardware issues. The machine doing this was an OC'd cpu, and when it was restored to normal speed I'm told the problems stopped, but I'm not sure. If it is make that is segfaulting, on the other hand, and if nothing else appears to have the problem, try going into /usr/src and just rebuilding make, perhaps one of your compiles went bad in the past. /gp on Fri, 18 Aug 2000, zshack babbled .. ;; this system is on a cyrix processer ;; any idea why its seg faulting?? ;; ;; ;; su-2.04# /usr/sbin/config PIGLET ;; Don't forget to do a ``make depend'' ;; Kernel build directory is ../../compile/PIGLET ;; su-2.04# cd ../../compile/PIGLET ;; su-2.04# make depend ;; Segmentation fault (core dumped) ;; ;; ;; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
bad /dev/cuaa1??
This is rather bizarre. I have two virtually identical USR modems; I also have vitually identical ppp and tip and cu setup--I just copied over tarballs from this system to sage.thought.org. According to ppp: Warning: deflink: /dev/cuaa1: Bad file descriptor tip and cu (cu -pport1 dir) indicate that something is amiss with /dev/cuaa1. The LED's are on my older modem are not what they were some months ago. If I remember correctly the switches in back were fine so I shouldn't have to change anything. Can anybody figure out how to get this second link working? thanks much, gary -- Gary D. Kline [EMAIL PROTECTED] Public service Unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: bad /dev/cuaa1??
Stupid question, but have you tried remaking the device node? G. -- Greg Work Email: [EMAIL PROTECTED] -- - Original Message - From: "Gary Kline" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 20, 2000 11:54 AM Subject: bad /dev/cuaa1?? This is rather bizarre. I have two virtually identical USR modems; I also have vitually identical ppp and tip and cu setup--I just copied over tarballs from this system to sage.thought.org. According to ppp: Warning: deflink: /dev/cuaa1: Bad file descriptor tip and cu (cu -pport1 dir) indicate that something is amiss with /dev/cuaa1. The LED's are on my older modem are not what they were some months ago. If I remember correctly the switches in back were fine so I shouldn't have to change anything. Can anybody figure out how to get this second link working? thanks much, gary -- Gary D. Kline [EMAIL PROTECTED] Public service Unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: bad /dev/cuaa1??
On Sun, Aug 20, 2000 at 12:04:06PM +0930, Greg Work wrote: Stupid question, but have you tried remaking the device node? Yup; no diff. -- Gary D. Kline [EMAIL PROTECTED] Public service Unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
not in bitmap
Curiouser and curiouser. dmesg reports: sio1: configured irq 3 not in bitmap of probed irqs 0 Any thoughts on this? like maybe the mouse and modem just maybe are switched? (XF86Setup fails 100% too.) gary -- Gary D. Kline [EMAIL PROTECTED] Public service Unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: not in bitmap
On Saturday, 19 August 2000 at 20:41:54 -0700, Gary Kline wrote: Curiouser and curiouser. dmesg reports: sio1: configured irq 3 not in bitmap of probed irqs 0 Any thoughts on this? like maybe the mouse and modem just maybe are switched? Well, it would be nice to know the usual background. Hardware, OS release (are you running FreeBSD? The only thing that says so is that fairly specific message saying that the probe isn't getting any interrupts). (XF86Setup fails 100% too.) Well, it would do. -- 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-stable" in the body of the message
Re: not in bitmap
On Sun, Aug 20, 2000 at 01:25:57PM +0930, Greg Lehey wrote: On Saturday, 19 August 2000 at 20:41:54 -0700, Gary Kline wrote: Curiouser and curiouser. dmesg reports: sio1: configured irq 3 not in bitmap of probed irqs 0 Any thoughts on this? like maybe the mouse and modem just maybe are switched? Well, it would be nice to know the usual background. Hardware, OS release (are you running FreeBSD? The only thing that says so is that fairly specific message saying that the probe isn't getting any interrupts). It's a 200MHz P5, modem is a USR Sportster that ran well on _this_ system (tao) for 4 years. The other box is running 4.0-RELEASE. I'm trying to get both boxes working with modems because I'm getting close to upgrading this platform to 4.1; also because I'd like to experiment with dial-in ... (XF86Setup fails 100% too.) Well, it would do. gary -- Gary D. Kline [EMAIL PROTECTED] Public service Unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
