Re: Dangling symlink in /usr/compat/linux
Hello Doug, Sorry for the belated answer, I hit the hay in the meantime... but now, good morning to everybody outta there:-) On Sun, Feb 04, 2001 at 05:05:11PM -0800, Doug Barton wrote: Ummm... duh. :) I confirmed this on two machines. OK I think I nailed it:-) I took a trip to the /var/db/pkg directory, it was very educational:-) /var/db/pkg/linux_base-6.1/+CONTENTS, the offending line in my installled copy: @exec ln -sf ../X11R6/lib/X11 %D/usr/lib/X11 @unexec rm %D/usr/lib/X11 But the port that actually did something to that directory was linux_devtools. It puts the config directory for X11 there. So you may very much be correct... unless you install linux_devtools, there may be no /usr/X11R6/lib/X11 directory at all. So short workaround: install linux_devtools:-) Long workaround: Take a long hard look at what's going on before posting to say that *it works for me* /*note to myself */ Solution: ? ( Maybe create the directory once we symlink to it? Seems like a good idea... ) (Most probably this problem never surfaced before because the maintainers had both ports installed on their systems.) Luckily, the date on the directories tipped me off, since I installed the devtools port only two days later... Have you installed any linux X apps other than real player? That and netscape are all I have installed. No, only Netscape, RP, Flash plugin and linux-jdk are linux apps on my system (oh yes and that unwieldy beast, Star Office) all from ports, except for RP which I downloaded quite some time ago and installed by hand and had no reason to upgrade ever since... but most of these do not put anything under the /usr/compat/linux/ hierarchy at all, but rather prefer /usr/local. (I installed linux-base quite some time ago but I know it works because I use RealPlayer every day:-) Me too. Using it right now:-) Good line quality from Charleston, SC. -- 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: Broken procfs/status, related to kthreads
On Mon, 5 Feb 2001, Bruce Evans wrote: On Sun, 4 Feb 2001, Andrzej Bialecki wrote: According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... The commands with $ in them are much less likely than the names with spaces, which on -current are guaranteed to occur. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel target died...
John Indra wrote: Latest -CURRENT buidkernel died with this error messages: === sound/driver === sound/driver/ad1816 rm -f setdef0.c setdef1.c setdefs.h setdef0.o setdef1.o snd_ad1816.ko snd_ad1816.kld ad1816.o @ machine symb.tmp tmp.o bus_if.h device_if.h isa_if.h pci_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h === sound/driver/cmi cd: can't cd to /usr/src/sys/modules/sound/driver/cmi *** Error code 2 In order to follow -current you have to follow freebsd-current mailing list and the commit logs. Cameron recently committed some new stuff, then committed the makefile for it a little while after. This was all described on the lists. If you're using cvsup, try it again. If you're using cvs, make sure you include the -d flag to update. -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel target died...
On Mon, Feb 05, 2001 at 01:30:26AM -0800, Doug Barton wrote: In order to follow -current you have to follow freebsd-current mailing list and the commit logs. Cameron recently committed some new stuff, then committed the makefile for it a little while after. This was all described on the lists. If you're using cvsup, try it again. If you're using cvs, make sure you include the -d flag to update. Sorry... I am subscribed to freebsd-current and commit logs mailing list. But sometimes I just skip reading those commit logs :) Will try tommorrow... /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[a.campi@inet.it: Page fault]
On -CURRENT I get this under different conditions, i.e. sometimes at boot as mentioned a couple of days ago, and today again at pccard extraction. I can provide other info if instructed as to what info you need. ;-) Bye, Andrea Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xdeadc0de stack pointer = 0x10:0xc65def68 frame pointer = 0x10:0xc65def78 code segment= base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 257 (irq3: ep0) kernel: type 12 trap, code=0 Stopped at 0xdeadc0de: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc01eb46c stack pointer = 0x10:0xc65dedcc frame pointer = 0x10:0xc65dedd0 code segment= base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 257 (irq3: ep0) kernel: type 12 trap, code=0 db -- There's no place like ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Aironet under NEWCARD
Now I'm on to that ich (i810 and 440MX) AC97 audio driver :-) Great news! And please MFC it asap ;-) Seriously, I've been using it on -STABLE for months, if you need volunteers for testing, I can help. Bye, Andrea Regards Gabriel On Sun, Feb 04, 2001 at 02:57:51AM +, Jose Gabriel J Marcelino wrote: Hi, - The main problem however is that now the OLDCARD kernel crashes after I remove my Cisco 340 (Aironet) PC Card from the only PC card slot present. I can give more detailed information on that if someone wants it, but I guess the later has to do with the NEWCARD changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Press every key to continue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
od driver for -CURRENT
I've made an attempt at an update for -CURRENT of Shunsuke Akiyama's od driver for magneto-optical disks, which I got from his archives at ftp://daemon.jp.freebsd.org/pub/FreeBSD-jp/OD/ . I have only tested it a little, but I'm able to do "tar cf /dev/od0 ..." under 4-STABLE and untar under Linux 2.2.16 or FreeBSD 5-CURRENT. If under -CURRENT I boot up while the MO disk (a 640 MB one) is in the drive (Olympus MOS364), the data read from it gets corrupted. That happens with the da driver as well. I merged the changes from the da driver into the od driver, so I probably brought the bug in too. Anyway, it's at http://people.freebsd.org/~trevor/src/od-20010203-current.diff.gz . -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3974) Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Dans votre courrier du 25 Jan 16:49 vous ecrivez : In your previous mail you wrote: It is not impossible to support IPv6 NFS without switching to TI-RPC, INRIA IPv6 has the code (IIRC). = this code was ported to FreeBSD 4.2. I'll give more details as soon as I am back to my office (ie. next week). The code is available on ftp.imag.fr, directory /archive/networking/ipv6/INRIA/FreeBSD4 files FILES-NFS-FreeBSD42.tgz (files) or PATCH-NFS-FreeBSD42 (patch) It as been tested against Solaris8. However, if you try this, there will be a lot of of non-intuitive typecast against library arguments. = this is a matter of taste. TI-RPC is not perfect tooo (:-). and also the old RPC interface is too weak to manage correctly different types of transport at the same time. It agree that a long term solution is to change to the TI-RPC interface, but the real TI-RPC libraries are complicated. -- Jean-Luc RICHIER ([EMAIL PROTECTED] [EMAIL PROTECTED]) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
I was able to do: # mount_msdos /dev/od0 /mnt # newfs_msdos /dev/od0 # cp mozilla-win32-0.7.zip /mnt/ under FreeBSD -CURRENT, then unzip the file under Windows 95 OSR2 with no problems. However, the patched sysinstall still crashes, and neither disklabel nor newfs are working: # disklabel -r -w /dev/od0 mo640 disklabel: ioctl DIOCWLABEL: Operation not supported by device # newfs -T mo640 /dev/od0c Warning: Block size restricts cylinders per group to 10. Warning: 3776 sector(s) in last cylinder unallocated /dev/od0c: 1241408 sectors in 76 cylinders of 1 tracks, 16384 sectors 606.2MB in 8 cyl groups (10 c/g, 80.00MB/g, 9600 i/g) super-block backups (for fsck -b #) at: write error: 1241404 newfs: wtfs - writecombine: Invalid argument -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
In local.freebsd.current you write: On Mon, 5 Feb 2001, Bruce Evans wrote: [...] I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... IMHO a correct solution would be to use a separator that cannot occur in any of the fields. All fields but the command name can be considered "well behaved" (= under control by procfs), and the command name is subject to file name limitations: that leaves NUL, "\n" and maybe "/" (of only the basename is shown) as safe separators. The "cmdline" file seems to solve the problem by using NULs. Come to think of it: another solution, in this case, would be to put the command name last on the line: anything beyond field N is the command name, including any spaces. But, please, no quoting. $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
On Mon, Feb 05, 2001, Andrzej Bialecki wrote: Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... The commands with $ in them are much less likely than the names with spaces, which on -current are guaranteed to occur. .. or we output information in a new file (say, /proc/$pid/stat?) which looks like the rlimit output? I like that idea better. adrian -- Adrian Chadd"Programming is like sex: [EMAIL PROTECTED] One mistake and you have to support for a lifetime." -- rec.humor.funny 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 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. -- 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: od driver for -CURRENT
On Mon, Feb 05, 2001 at 09:34:44AM -0500, Trevor Johnson wrote: I've made an attempt at an update for -CURRENT of Shunsuke Akiyama's od driver for magneto-optical disks, which I got from his archives at ftp://daemon.jp.freebsd.org/pub/FreeBSD-jp/OD/ . I have only tested it a little, but I'm able to do "tar cf /dev/od0 ..." under 4-STABLE and untar under Linux 2.2.16 or FreeBSD 5-CURRENT. If under -CURRENT I boot up while the MO disk (a 640 MB one) is in the drive (Olympus MOS364), the data read from it gets corrupted. That happens with the da driver as well. I merged the changes from the da driver into the od driver, so I probably brought the bug in too. Anyway, it's at http://people.freebsd.org/~trevor/src/od-20010203-current.diff.gz What is the od driver able to do that the da driver can't? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
On Tue, Feb 06, 2001 at 00:15:27 +0100, Bernd Walter wrote: On Mon, Feb 05, 2001 at 09:34:44AM -0500, Trevor Johnson wrote: I've made an attempt at an update for -CURRENT of Shunsuke Akiyama's od driver for magneto-optical disks, which I got from his archives at ftp://daemon.jp.freebsd.org/pub/FreeBSD-jp/OD/ . I have only tested it a little, but I'm able to do "tar cf /dev/od0 ..." under 4-STABLE and untar under Linux 2.2.16 or FreeBSD 5-CURRENT. If under -CURRENT I boot up while the MO disk (a 640 MB one) is in the drive (Olympus MOS364), the data read from it gets corrupted. That happens with the da driver as well. I merged the changes from the da driver into the od driver, so I probably brought the bug in too. Anyway, it's at http://people.freebsd.org/~trevor/src/od-20010203-current.diff.gz What is the od driver able to do that the da driver can't? I exchanged some mail with Akiyama-san around the end of October about the od(4) driver. In short, we'd like to make sure that the cd(4) driver and da(4) driver have the od driver's functionality, so there isn't a need for another driver. I think we already have the most important functionality from the od(4) driver in the da and cd drivers. If there are any features that are in the od(4) driver that should be in the da(4) or cd(4) drivers, but aren't, please speak up. Note that his patches also include some other filesystem-type patches, which would have to be looked at by someone who actually knows something about filesystems. :) (i.e. not me) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p On Mon, Feb 05, 2001 at 08:27:19PM -0500, Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange fopen() behaviour (was: xsane patch to maintainer)
Hi,
Would you mind if I commit the attached patch for the xsane port ?
It makes sense - rather than dropping a core when fopen() fails (and
fclose() is called with a NULL arg). It happens when your home
directory isn't writable :-/
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.
Anyway, here's the patch if you're interested. I'll look into things
further on Wednesday.
Cheers.
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
--- src/xsane-preview.c.origSun Jan 14 15:35:06 2001
+++ src/xsane-preview.c Tue Feb 6 03:03:18 2001
@@ -2802,6 +2802,7 @@
int i;
char buf[256];
char filename[PATH_MAX];
+ FILE *fp;
DBG(DBG_proc, "preview_new\n");
@@ -2830,9 +2831,17 @@
if (preview_make_image_path(p, sizeof(filename), filename, i)=0)
{
umask(0177); /* create temporary file with "-rw---"
permissions */
- fclose(fopen(filename, "wb")); /* make sure file exists, b = binary mode for
win32 */
- umask(XSANE_DEFAULT_UMASK); /* define new file permissions */
- p-filename[i] = strdup(filename);/* store filename */
+ fp = fopen(filename, "wb"); /* make sure file exists, b = binary mode for
+win32 */
+ if (fp == NULL) {
+fprintf(stderr, "%s: could not create for preview-level %d: %s\n", filename,
+i, strerror(errno));
+p-filename[i] = NULL;
+ }
+ else
+ {
+fclose(fp);
+umask(XSANE_DEFAULT_UMASK);/* define new file permissions */
+p-filename[i] = strdup(filename);/* store filename */
+ }
}
else
{
Re: Strange fopen() behaviour
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 !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour (was: xsane patch to maintainer)
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory'
^^
surely this is not nice!! My guess is that the double slash is confusing
everything...
Anyway, I'm more interested in below:
@@ -2830,9 +2831,17 @@
if (preview_make_image_path(p, sizeof(filename), filename, i)=0)
{
umask(0177); /* create temporary file with "-rw---"
permissions */
- fclose(fopen(filename, "wb")); /* make sure file exists, b = binary mode for
win32 */
- umask(XSANE_DEFAULT_UMASK);/* define new file permissions */
- p-filename[i] = strdup(filename);/* store filename */
+ fp = fopen(filename, "wb");/* make sure file exists, b = binary mode for
win32 */
+ if (fp == NULL) {
+fprintf(stderr, "%s: could not create for preview-level %d: %s\n",
filename, i, strerror(errno));
+p-filename[i] = NULL;
+ }
+ else
+ {
+fclose(fp);
+umask(XSANE_DEFAULT_UMASK); /* define new file permissions */
+p-filename[i] = strdup(filename);/* store filename */
+ }
I REALLY hope above code is NEVER EVER run as root, as this is a great
recipe for interesting failures...
/me hands Brian a few symlinks to /etc/master.passwd from /tmp
If you are patching it, make sure you get it right, you'd do
everybody a big favor.
Bye,
Andrea
--
It is easier to fix Unix than to live with NT.
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 06-Feb-01 Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. -- 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: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Andrea Campi wrote: Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p That means it is free'd memory. One cause might be something that is free'ing its interrupt handler w/o releasing it properly. Alternatively, it might be a race in the interrupt list code that was been brought about by preemption. Since locks are rather expensive, we have avoided locking the list of interrupt handlers in the past, but we may have to break down and do that now. :( This will hurt interrupt latency unless I can figure out a slick way of fixing it. Can anyone confirm that a pre-preemption kernel works fine for them? -- 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
md, current and stable
Howdy, Since the new md was introduced, it is not possible to build a -current snapshot on a -stable box. Are there any plans to MFC this soon? Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
John Baldwin said: On 06-Feb-01 Andrea Campi wrote: Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p That means it is free'd memory. One cause might be something that is free'ing its interrupt handler w/o releasing it properly. Alternatively, it might be a race in the interrupt list code that was been brought about by preemption. Since locks are rather expensive, we have avoided locking the list of interrupt handlers in the past, but we may have to break down and do that now. :( This will hurt interrupt latency unless I can figure out a slick way of fixing it. Can anyone confirm that a pre-preemption kernel works fine for them? I have 2 SMP boxes (one with pentium 200MMX's, the other with PPro 233's. There are other differences in peripherals). Both boxes run an identical build of a kernel dating to sun 4th feb. The PPro is rock-stable. The PentiumMMX is very fragile, and will panic easily (often in vm_fault) with a sig9 (IIRC). M -- Mark Murray Warning: this .sig is umop ap!sdn 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] Date: Mon, 5 Feb 2001 17:00:41 -0700 I think we already have the most important functionality from the od(4) driver in the da and cd drivers. If there are any features that are in the od(4) driver that should be in the da(4) or cd(4) drivers, but aren't, please speak up. Though I have not tried `da' lately, if you don't insert a medium in the drive at the time of CAM rescan bus, `da' tries to get the geometry by XPT_CALC_GEOMETRY then panics with divided by zero in most SCSI drivers. With `od' it says just the medium is 0MB and does not cause panic. Probably `od' knows the medium is not in the drive (watching UNIT READY or something?). Is it safe to change the size (geometry) of media with `da', eg. at first no medium (0MB), then 128MB, 230MB, 640MB (sector size is 2048bytes) and so on ? // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
