buildworld failed. again...
Latest -CURRENT buildworld target failed again with this message: === share/monetdef grep -v '^#' /usr/src/share/monetdef/en_US.ISO_8859-1.src en_US.ISO_8859-1.out grep -v '^#' /usr/src/share/monetdef/nl_NL.ISO_8859-1.src nl_NL.ISO_8859-1.out grep -v '^#' /usr/src/share/monetdef/ru_RU.KOI8-R.src ru_RU.KOI8-R.out === share/msgdef grep -v '^#' /usr/src/share/msgdef/en_US.ISO_8859-1.src en_US.ISO_8859-1.out grep -v '^#' /usr/src/share/msgdef/nl_NL.ISO_8859-1.src nl_NL.ISO_8859-1.out grep -v '^#' /usr/src/share/msgdef/ru_RU.KOI8-R.src ru_RU.KOI8-R.out === share/numericdef make: don't know how to make nl_NL.ISO_8859-1.out. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error I thought that this problem has been fixed. Am I the only one experiencing this? /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failed
-On [20010209 05:35], John Indra ([EMAIL PROTECTED]) wrote: Dunno whether this happens only to me, but in my machine, latest -CURRENT buildworld target failed with this message: === share/numericdef make: don't know how to make nl_NL.ISO_8859-1.out. Stop Should be fixed. Apologies. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Fallen into ever-mourn, with these wings so torn, after your day my dawn... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current buildworld broken
-On [20010207 11:00], Harti Brandt ([EMAIL PROTECTED]) wrote: With a freshly CVSuped current I get: === usr.bin/ncal cc -O -pipe -Wall -Wmissing-prototypes -fstrict-prototypes -ansi -pedantic -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/ncal/ncal.c /usr/src/usr.bin/ncal/ncal.c: In function `printeaster': /usr/src/usr.bin/ncal/ncal.c:390: warning: unknown conversion type character `F' in format You are probably caught in between commits. Always cvsup after such problems, after you waited an hour or so for your favourite cvsup mirror up pick up any further commits, and then try again, and THEN report things like this. Saves traffic. :) -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Fallen into ever-mourn, with these wings so torn, after your day my dawn... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current buildworld broken
On Fri, 9 Feb 2001, Jeroen Ruigrok van der Werven wrote: JRvdW-On [20010207 11:00], Harti Brandt ([EMAIL PROTECTED]) wrote: JRvdW JRvdWWith a freshly CVSuped current I get: JRvdW ... JRvdW JRvdWYou are probably caught in between commits. JRvdW JRvdWAlways cvsup after such problems, after you waited an hour or so for JRvdWyour favourite cvsup mirror up pick up any further commits, and then try JRvdWagain, and THEN report things like this. Saves traffic. :) I did report after cvsupping twice, but I had a cvs that dumped core in deep subdirectories and did not tell me about that. In my feeling cvs has become quit unstable for a couple of months now... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with playback via pcm device
i have Ensoniq ES1371-based soundcard supported by pcm driver and experience some problems. the sound played is interruped by clicks and distorsions, and they appear more often when the disk activity is high. during playback the kernel generates messages like 'pcm0: hwptr went backwards 64 - 32'. any ideas? I have similar problems, except the disruptions only seem to occur during keyboard activity. I ran a cvsup while using mpg123 and had no problems, which is pretty impressive since the machine is a P133. However, even a small amount of typing causes noticeable audio glitches. This happens both with a ES1371 and an old SB16 ISA card. It seems I may also be losing keystrokes from the keyboard, though I haven't confirmed it's not a problem with the keyboard itself. - Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with playback via pcm device
On 09-Feb-01 Mike Holling wrote: i have Ensoniq ES1371-based soundcard supported by pcm driver and experience some problems. the sound played is interruped by clicks and distorsions, and they appear more often when the disk activity is high. during playback the kernel generates messages like 'pcm0: hwptr went backwards 64 - 32'. any ideas? I have similar problems, except the disruptions only seem to occur during keyboard activity. I ran a cvsup while using mpg123 and had no problems, which is pretty impressive since the machine is a P133. However, even a small amount of typing causes noticeable audio glitches. This happens both with a ES1371 and an old SB16 ISA card. It seems I may also be losing keystrokes from the keyboard, though I haven't confirmed it's not a problem with the keyboard itself. This could be related to the entropy gathering by the random kthread. Have you tried removing the random device from your kernel? - Mike -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/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: problems with playback via pcm device
On Fri, 9 Feb 2001, John Baldwin wrote: i have Ensoniq ES1371-based soundcard supported by pcm driver and experience some problems. the sound played is interruped by clicks and distorsions, and they appear more often when the disk activity is high. during playback the kernel generates messages like 'pcm0: hwptr went backwards 64 - 32'. any ideas? This could be related to the entropy gathering by the random kthread. Have you tried removing the random device from your kernel? yes, i've tried. no effect. sincerely, ilya naumov (at work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with playback via pcm device
This could be related to the entropy gathering by the random kthread. Have you tried removing the random device from your kernel? yes, i've tried. no effect. This seems to have fixed the problem for me, thanks! I'm using the machine now and am getting no keyboard-related glitches in audio, just when the machine gets busy (which is fine since I don't expect a P133 to be able to do too much else when playing MP3's). - Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: "Kenneth D. Merry" [EMAIL PROTECTED] Subject: Re: od driver for -CURRENT By the way, in Japanese users mailing list, some said that `da' does not check whether a medium is writerable or not (write protected). If you mount a write protected medium with -rw, it will lead bad condition when you do umount. Hmm, can you demonstrate the problem? The write-protect check in the od driver is one of the things that the da driver doesn't have. I figured it wouldn't really be necessary, since any attempted writes would be returned with errors. The problem is you cannot unmount after -rw mount with a write-protected medium. Below has been done also in 4.2-RELEASE with GENERIC kernel, 1. Insert a write protected medium, 2. mount /dev/da0s1c /mnt, cel# mount /dev/da0s1c /mnt 3. umount /mnt cel# umount /mnt umount: unmount of /mnt failed: Input/output error cel# umount /mnt umount: unmount of /mnt failed: Input/output error Umount does not success and `Write protected' messages continue to appear 4. reboot (umount fails) In /var/log/mesages, Feb 9 21:10:28 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 7 c9 2 0 Feb 9 21:10:28 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:28 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 7 c9 2 0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 7 c9 2 0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:35 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:10:40 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 0 49 4 0 Feb 9 21:10:40 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:10:40 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:11:09 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 0 49 4 0 Feb 9 21:11:09 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:11:09 cel /kernel: (da0:ahc0:0:3:0): Write protected Feb 9 21:11:38 cel /kernel: (da0:ahc0:0:3:0): WRITE(06). CDB: a 0 0 49 4 0 Feb 9 21:11:38 cel /kernel: (da0:ahc0:0:3:0): DATA PROTECT asc:27,0 Feb 9 21:11:38 cel /kernel: (da0:ahc0:0:3:0): Write protected Hope this helps. // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel trap 12 with interrupts disabled
On 9 Feb, Bruce Evans wrote: Pagefaults occur in copyin() (called from addupc_task() which is called from ast()) while sched_lock is held. This is not good. Incrementing the profiling counters is supposed to be pushed to ordinary process context so that things like copyin() can work (they have to be able to fault in pages, so they have to be able to sleep...), so using sched_lock to lock things here is wrong. Are we talking about /sys/kern/kern_clock.c: statclock()? I'm not familiar with the kernel and that's the only place I find something related to profiling if I grep for "profil" and look at the results. If yes, what is to to? If I run it withhin X11, the machine deadlocks hard (no response from the numlock led on the keyboard), withhin a virtual console I get a lot of "kernel trap ..." and the program runs fine. It's surprising that it doesn't always deadlock. First I thought I have a hardware problem, I was able to profile the program 4-5 times withhin X11 at a day before. Without changing anything except the options to the program I wasn't able to profile it later. Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here I am again. Didn't get as far as a login prompt, I have a panic when qmail starts up: Turn MUTEX_DEBUG off. It appears to be broken atm. Done, no panic, and performance is bad but not so bad. -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Thu, Feb 08, 2001 at 09:56:43AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Andrea Campi writes: : Will try again with cardbus and report. So are you saying it SHOULD work : (as far as my chipset is behaving, I suppose)? Cardbus works, more or less, on -current right now. Some cards just work, other cards need help. I keep meaning to do a survey, but haven't found the time to do it yet. Of course cardbus per se is working, I meant irq sharing when using cardbus... And, it's not working for me, i.e. my pccard using cardbus is working on irq 11, my csa audio card is probed and configured on irq 11, but audio playback is not. If you or anybody else has time and is willing to debug this I am available, but I understand there are a lot of things which are more urgent so I will just wait. On a separate note, I am thinking about adapting rc.pccard to carbus, or writing a new rc.cardbus; is anybody working on this? Going back to the original thread, removing my card under cardbus simply hangs my laptop. I have no idea how to debug this. Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangling symlink in /usr/compat/linux
[taken to -ports] Szilveszter Adam wrote: @exec ln -sf ../X11R6/lib/X11 %D/usr/lib/X11 @unexec rm %D/usr/lib/X11 The link is correct. On a Redhat 6.2 system: dhcp00% cd /mnt/usr/lib dhcp00% ls -al X11 lrwxrwxrwx 1 root wheel 16 Jul 18 2000 X11 - ../X11R6/lib/X11 dhcp00% more /mnt/etc/redhat-release Red Hat Linux release 6.2 (Zoot) Solution: ? ( Maybe create the directory once we symlink to it? Seems like a good idea... ) Can you tell me what the problem was. I missed that. (Most probably this problem never surfaced before because the maintainers had both ports installed on their systems.) I do have both ports in fact :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel trap 12 with interrupts disabled
On Fri, 9 Feb 2001, Alexander Leidinger wrote:
On 9 Feb, Bruce Evans wrote:
Pagefaults occur in copyin() (called from addupc_task() which is called
from ast()) while sched_lock is held. This is not good. Incrementing
the profiling counters is supposed to be pushed to ordinary process
context so that things like copyin() can work (they have to be able
to fault in pages, so they have to be able to sleep...), so using
sched_lock to lock things here is wrong.
Are we talking about /sys/kern/kern_clock.c: statclock()? I'm not
No :-). ast() is in /sys/${MACHINE}/${MACHINE}/trap.c. Incrementing
the profiling counters is much too hard to do in statclock(), since
statclock() is a fast interrupt handler, so statclock() only schedules
an AST to do the increment. The scheduling of the AST is rather tangled
and pessimized to support optimizations that aren't possible while
statclock() is a fast interrupt handler. See addupc_intr(), fuswintr(),
suswintr() and need_proftick().
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pkg_update
On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote: On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled: | It seems pkg_update is only usable when installing from packages, not from | ports. Because it is a package update system. If you want to update from the ports, use 'pkg_version -c |sh' Never, ever, *ever* do this. "pkg_version -c" is a hack to make cut-n-paste easier. The output is sorted alphabetically and no notice is taken of dependencies between different ports. *If* you know what you're doing then -c is useful to help save you some typing. But you should never run the commands automatically. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangling symlink in /usr/compat/linux
Hello Marcel,
On Fri, Feb 09, 2001 at 10:23:16AM -0800, Marcel Moolenaar wrote:
[taken to -ports]
I see it nowhere in the headers, so I am going to add a Cc: for it...
The link is correct. On a Redhat 6.2 system:
dhcp00% cd /mnt/usr/lib
dhcp00% ls -al X11
lrwxrwxrwx 1 root wheel 16 Jul 18 2000 X11 - ../X11R6/lib/X11
dhcp00% more /mnt/etc/redhat-release
Red Hat Linux release 6.2 (Zoot)
Which is not the point:-)
Solution: ? ( Maybe create the directory once we symlink to it? Seems like
a good idea... )
Can you tell me what the problem was. I missed that.
The problem if you want it that way, is that although the symlink is
created upon installing linux_base, the directory it points to is not.
Hence the ${SUBJECT} about a "Dangling symlink". (If you install
linux_devtools, the directory is created, since there is a subdir in it.
That's why the problem may be harder to detect:-)
Maybe it would be a good idea to create a (empty if need be)
/usr/compat/linux/usr/X11R6/lib/X11 directory upon installing linux_base?
I have no idea how this came up btw, maybe some installation of some
third-party sw tried to follow the symlink and got confused? I just tried
to react to the problem at hand...
(Most probably this problem never surfaced before because the maintainers
had both ports installed on their systems.)
I do have both ports in fact :-)
Me too, that's why I at first very self-confidently posted something along
the lines of "It works for me!" which earned blank stares from just about
anybody else:-)
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
On Fri, 9 Feb 2001 [EMAIL PROTECTED] wrote: From: "Kenneth D. Merry" [EMAIL PROTECTED] Subject: Re: od driver for -CURRENT By the way, in Japanese users mailing list, some said that `da' does not check whether a medium is writerable or not (write protected). If you mount a write protected medium with -rw, it will lead bad condition when you do umount. Hmm, can you demonstrate the problem? The write-protect check in the od driver is one of the things that the da driver doesn't have. I figured it wouldn't really be necessary, since any attempted writes would be returned with errors. The problem is you cannot unmount after -rw mount with a write-protected medium. This is essentially the same bug that causes problems for writing to write protected media or unwriteable blocks using the block device. There are many open PRs about this bug. It used to cause panics, but now it just causes endless retries (except under RELENG_3 where it still causes panics). The fix is to not retry endlessly. The correct number of retries is not clear. RELENG_2 has the slightly wrong fix of not retrying at all (in the vfs layer). Not retrying is probably right for most errors on physical blocks, but for write protect errors you might want to physically change the write protection so retrying (not too often) for a minute or two might be best. Anyway, there needs to be a way to stop the retries. I first saw this problem for a floppy driver that I wrote in 1984. It retried endlessly. Users did not like this :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Andrew Gallatin writes: Dag-Erling Smorgrav writes: Julian Elischer [EMAIL PROTECTED] writes: I believe that vmware mmaps a region of memory and then somehow syncs it to disk. (It is certainly doing something like it here). Theory: VMWare mmaps a region of memory corresponding to the virtual machine's "physical" RAM, then touches every page during startup. Unless some form of clustering is done, this causes 16384 write operations for a 64 MB virtual machine... Pretty much. But the issue is that this should never hit the disk unless we're under memory pressure because it is mapped MAP_NOSYNC (actually the file is unlinked prior to the mmap() and a heuristic in vm_mmap() detects this and sets MAP_NOSYNC). I take it back. At least with the latest version of vmware, it is apparently not mapped MAP_NOSYNC. I think they've moved from mmap'ing a file in $TMPDIR to just using the CONFIG.std save/resume file. Perhaps this is only if you have resumed from a suspended state... I haven't checked that out yet. At any rate, hacking linux_mmap to ad MAP_NOSYNC to mmaped files, in combination with yesterdays patch, appears to improve perf. considerably. Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Andrew Gallatin wrote: Andrew Gallatin writes: Dag-Erling Smorgrav writes: Julian Elischer [EMAIL PROTECTED] writes: I believe that vmware mmaps a region of memory and then somehow syncs it to disk. (It is certainly doing something like it here). Theory: VMWare mmaps a region of memory corresponding to the virtual machine's "physical" RAM, then touches every page during startup. Unless some form of clustering is done, this causes 16384 write operations for a 64 MB virtual machine... Pretty much. But the issue is that this should never hit the disk unless we're under memory pressure because it is mapped MAP_NOSYNC (actually the file is unlinked prior to the mmap() and a heuristic in vm_mmap() detects this and sets MAP_NOSYNC). I take it back. At least with the latest version of vmware, it is apparently not mapped MAP_NOSYNC. I think they've moved from mmap'ing a file in $TMPDIR to just using the CONFIG.std save/resume file. Perhaps this is only if you have resumed from a suspended state... I haven't checked that out yet. At any rate, hacking linux_mmap to ad MAP_NOSYNC to mmaped files, in combination with yesterdays patch, appears to improve perf. considerably. I don't like the sound of that hack.. are they doing something in Linux to tell Linux to not sync it? I nkow it's gross but could we only do that hack if it'a vmware? (probably should be on -emulation) Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg_update
If memory serves me right, Nik Clayton wrote: On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote: On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled: | It seems pkg_update is only usable when installing from packages, not fro m | ports. Because it is a package update system. If you want to update from the ports, use 'pkg_version -c |sh' Never, ever, *ever* do this. "pkg_version -c" is a hack to make cut-n-paste easier. The output is sorted alphabetically and no notice is taken of dependencies between different ports. Plus it's been known to wipe out Ports Upgrade kits. This was particularly bad when some upgrade kits replaced little non-essentials like ld*.so, things like that. I just put a big fat warning to this effect followed by "exit 1" at the start of the commands output, and committed to -CURRENT. I'll MFC early next week. Bruce. PGP signature
Re: pkg_update
On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote: On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled: | It seems pkg_update is only usable when installing from packages, not from | ports. Because it is a package update system. If you want to update from the ports, use 'pkg_version -c |sh' Never, ever, *ever* do this. Just installing a new version of a port seems to work. Couldn't it be made possible to use just the update-of-dependencies part of pkg_update without doing the pkg_delete/pkg_install bit? Perhaps I'll try... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg_update
[moved to -ports] If memory serves me right, "Leif Neland" wrote: Couldn't it be made possible to use just the update-of-dependencies part of p kg_update without doing the pkg_delete/pkg_install bit? Perhaps I'll try... Manipulating the bits is relatively straightforward. Doing so in a meaningful way, and being able to cover all the edge cases, that's quite hard (as I've just re-learned). If you browse through the archives of -ports for the last few days, you'll get an idea of some of the problems. Every few months, the topic comes up, and discussion is just tapering off from the last round. Not to say you shouldn't work on this problem...just saying that it's not quite as straightforward as most people (myself included) think when they first tackle it. Cheers, Bruce. PGP signature
Re: Strange fopen() behaviour
Just to follow up, this was fixed with v1.9 of src/lib/libc/stdio/findfp.c
Thanks Maxim !
I've cc'd -current as I think something more sinister is going on.
To recap, I'm having trouble running xsane on -current from about two
days ago. fopen() is failing...
The attached patch exposes more about what's wrong. Interestingly
enough, the file it's trying to create is in /tmp (mode 1777,
separate filesystem), and according to truss:
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or
directory'
umask(0x7f) = 7 (0x7)
/tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create
for preview-level 0: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or
directory'
umask(0x7f) = 127 (0x7f)
/tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create
for preview-level 1: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or
directory'
umask(0x7f) = 127 (0x7f)
break(0x8134000) = 0 (0x0)
/tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create
for preview-level 2: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
fopen() is failing after calling lstat() (I assume via _open()) !!!
As if the "wb" didn't mean O_CREAT ??!? Very strange.
[.]
And just to top it all, I see this in my daily report (first time
I've ever seen it on this machine...):
dev.lan.Awfulhak.org kernel log messages:
microuptime() went backwards (18415.166882 - 18415.158249)
microuptime() went backwards (18490.192910 - 18490.187579)
microuptime() went backwards (19572.644000 - 19572.638237)
microuptime() went backwards (19878.637972 - 19878.637330)
microuptime() went backwards (20043.869158 - 20043.868971)
microuptime() went backwards (20074.159108 - 20074.152253)
microuptime() went backwards (20210.078270 - 20210.072448)
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED] Andrea Campi writes: : Of course cardbus per se is working, I meant irq sharing when using cardbus... Works great for me. : And, it's not working for me, i.e. my pccard using cardbus is working on irq : 11, my csa audio card is probed and configured on irq 11, but audio playback : is not. Audio and current is also dicy. : just wait. On a separate note, I am thinking about adapting rc.pccard to : carbus, or writing a new rc.cardbus; is anybody working on this? /sbin/devd :-) : Going back to the original thread, removing my card under cardbus simply : hangs my laptop. I have no idea how to debug this. Neither do I. I make guesses until it is working. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current SMP Kernel panics
A current kernel built 10 mins ago form fresh cvsup panics: APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 IPsec: Initialized Security Association Processing. panic: mutex sched lock not owned at ../../kern/kern_synch.c:175 cpuid = 0; lapic.id = syncing disks... done Uptime: 0s dpt0: Shutting down (mode 100) HBA. Please wait... dpt0: Controller was warned of shutdown and is now disabled Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel.c disklabel.8 patch
Hi, I've been using the disklabel.c patch which allows easier configuration by being able to specify a new disklabel of the form: #size offsetfstype [fsize bsize bps/cpg] a: 400M04.2BSD 4096 1638475 # (Cyl.0 - 812*) b: 1G* swap c: **unused e: 204800*4.2BSD f: 5g*4.2BSD g: **4.2BSD An up-to-date copy of disklabel.c can be found at: http://people.freebsd.org/~jwd/disklabel.c The man page can be found at: http://people.freebsd.org/~jwd/disklabel/disklabel.8 or in html format: http://people.freebsd.org/~jwd/disklabel/disklabel.8.html Patch files: http://people.freebsd.org/~jwd/disklabel/disklabel.c.patch http://people.freebsd.org/~jwd/disklabel/disklabel.8.patch I'd like to commit these if no one sees any major problems with them. These patches are the original work of Randell Jesup, and I believe Matt Dillon, with additional work by Warner Losh. Please let me know if I've left someone out. Incorporated into this is the fix for PR bin/22727. A simple one character fix. Comments Welcome! -John ps: The .html file was generated via groff. It seems to have some interesting side effects with the '[' and ']' characters. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
