Re: [Fwd: mkisofs | burncd not working in 5.0 ?]
Alexander Leidinger wrote:
Please try the patch in from the mail to -current with the Message-ID
<[EMAIL PROTECTED]> and report if it works for
you.
I've applied the patch included here, but it leads to an error (the .rej
file shows it). I infer from the reject that a "while" has to be
replaced by an "if", and so I've edited it by hand.
The problem is that my system still shows the same behavior as before :(
Maybe I've applied the wrong patch?
CU,
David.
diff -u -2 -r1.81 fifo_vnops.c
--- fifo_vnops.c13 Jan 2003 00:28:57 - 1.81
+++ fifo_vnops.c9 Feb 2003 17:32:16 -
@@ -227,5 +227,5 @@
}
if ((ap->a_mode & FREAD) && (ap->a_mode & O_NONBLOCK) == 0) {
- while (fip->fi_writers == 0) {
+ if (fip->fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)&fip->fi_readers,
@@ -234,4 +234,9 @@
if (error)
goto bad;
+ /*
+* We must have got woken up because we had a writer.
+* That (and not still having one) is the condition
+* that we must wait for.
+*/
}
}
@@ -243,16 +248,16 @@
}
} else {
- while (fip->fi_readers == 0) {
+ if (fip->fi_readers == 0) {
VOP_UNLOCK(vp, 0, td);
- /*
-* XXX: Some race I havn't located is solved
-* by timing out after a sec. Race seen when
-* sendmail hangs here during boot /phk
-*/
error = tsleep((caddr_t)&fip->fi_writers,
- PCATCH | PSOCK, "fifoow", hz);
+ PCATCH | PSOCK, "fifoow", 0);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (error)
goto bad;
+ /*
+* We must have got woken up because we had
+* a reader. That (and not still having one)
+* is the condition that we must wait for.
+*/
}
}
***
*** 227,231
}
if ((ap->a_mode & FREAD) && (ap->a_mode & O_NONBLOCK) == 0) {
- while (fip->fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)&fip->fi_readers,
--- 227,231
}
if ((ap->a_mode & FREAD) && (ap->a_mode & O_NONBLOCK) == 0) {
+ if (fip->fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)&fip->fi_readers,
[Fwd: mkisofs | burncd not working in 5.0 ?]
(forwarded from the NG comp.unix.bsd.freebsd.misc, from which I got no answer) Hi! I'm somehow surprised that the following command pipe doesn't work any more in 5.0R: $ mkisofs -J -r mydir | burncd -f /dev/acd1c -s 16 data - fixate next writeable LBA 0 writing from stdin $ _ ...and nothing else happens. I've also tried with a named pipe, also with a strange result: $ mkfifo mypipe $ mkisofs -J -r -o mypipe mydir (1s lag) mkisofs: Resource temporarily unavailable. Unable to open disc image file. If I begin at the other side of the pipe, I get the same result as case 1: $ burncd -f /dev/acd1c -s 16 data mypipe fixate & $ mkisofs -J -r -o mypipe mydir next writeable LBA 0 writing from file mypipe size 0 KB Broken pipe Same results if I try to pass data in blocks by piping everything thru dd bs=2k, so I don't know any more tricks :( Not to mention that case 1 worked in 4-STABLE. Does anybody know what is happening here? Any hints will be greatly appreciated. Regards, David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/smb where are you?
Christian Gusenbauer wrote:
Hello!
Using a kernel from last friday, I'm not able to get /dev/smb
working. I've added these options to my kernel config:
device smbus device intpm device alpm
device ichsmb device viapm device amdpm
device nfpm device smb
Maybe you need the following line in your /boot/device.hints:
hint.smb.0.at="smbus"
I figured that out from my 4.x config file ("device smb0 at smbus?" in
MYKERNEL).
Good luck!
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [Fwd: panic: don't do that ?]
Olivier Houchard wrote: Ooops sorry. They have to be applied in /sys/dev/sound/pcm. My bad, next time I'll make them against /usr/src :) Thanks! That did the trick. Where I have to keep an eye is to the "device busy" problem, since it doesn't appear immediately. CU, David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Fwd: panic: don't do that ?]
Olivier Houchard wrote: I'm afraid I don't know anything about that. The oid doesn't exist for me if I don't load the kernel module. That's my fault for being imprecise. I forgot to mention that I had snd_pcm.ko loaded, but nothing else. I believe it has been fixed on -CURRENT. You may try this patch : http://people.FreeBSD.org/~cognet/sound.c.diff Thanks for the patch, I'll try it. AFAIK, The device being busy issue is fixed by Brian Feldman's recent commit. You can find the patch here : http://people.FreeBSD.org/~cognet/dsp.c.diff Thanks for this one also, will test both. CU, David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Fwd: panic: don't do that ?]
Hi!
I've sent this post to comp.unix.bsd.freebsd, and I've been told that I
should report the problem to this list, so...
Original Message
Hi folks!
I was trying to modularize the sound in my 5.0R machine, which has two
sound cards:
$ dmesg | grep pcm.:
pcm0: port 0xb000-0xb003,0xb400-0xb403,0xb800-0xb8ff irq
9 at device 4.5 on pci0
pcm1: port 0xa000-0xa03f irq 9 at device 10.0 on pci0
In order for them to work properly as modules, the files
snd_{pcm,via82c686,es137x}.ko have to be loaded in the beginning AFAIK.
Or else they won't be recognized and will be given as PCI devices with
"no driver attached".
Well, two issues:
1)
If they aren't loaded (I forgot them on the 1st try by mistake), the
kernel panics if I try to change hw.snd.maxautovchans (that odd "bwrite:
buffer is not busy???" message again!). That shouldn't happen: if I
don't have any soundcards, this oid shouldn't _exist_ either!
2)
If they're loaded, an attempt to unload snd_via82c686.ko results in a
panic with the funny message in the subject. But: Aren't modules
supposed to be unloadable? What's the fun with modules then?
Any hints on solving this?
My attempt to load modules instead of the monolithic solution (which
always works) comes due to an odd behaviour of pcm0 (multiplexed with
hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
busy after their first usage. I wanted to address it by unloading the
affected module and loading it again, but... that'll panic the system.
Has someone had something similar?
Thanks in advance,
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: copy extended attributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Err... I'm using 5.0-RELEASE, I forgot to say. Is there a change in - -CURRENT about this? Thanks, David. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Oa5QK3CyMA5SxrwRAnngAKCIfvYW6te70xJqfX2rgQlmRRNRPQCfZpMe dXEyKOcxRL+vc0XaYB6Cmyw= =dW1e -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
copy extended attributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! After some investigation, I come to the conclusion that there is no means to copy the extended attributes of a file by using standard commands like cp (even with the -p option) or mv. At least it works with mv if the rename(2) syscall is used (ie. moves within the same filesystem), but as soon as it has to cross filesystems, extended attrs get lost. Naturally I'm speaking of copying from a UFS2 fs to a UFS2 fs. Am I missing something here or is it really a 'bug'? (or a feature, it depends :) ) Cheers, David. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Oa2/K3CyMA5SxrwRAlJIAJ9PiRlDJzaKCbUgn6j7zP7uWPfNSACfaTJG Ok6dBmRefs6ezyJUlhJhIZE= =MLoF -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
