Re: Death sentence to KLD screen savers? Comments?
I propose to have user-land screen savers instead of KLD screen savers. [ ... performance degradation ... ] [ ... file access ... ] I don't see either of these as being compelling arguments in favor of a user space implementation; I guess this means you want to do file access in your screen saver(s). Both points/complaints/requests have been raised several times in our mailing lists in the past. (Sorry, I don't keep copies.) Some people don't like cputime eaten up by the screen saver in the kernel... Some peopel want to write interesting screen savers... Now if you could run Windows screen saver modules, you might have a good argument for change, above and beyond change for the sake of change. Personally I am not interested in fancy screen savers :-) But, just want to keep things tidy and keep the system running smoothly. By moving much of the screen saver support from the console driver to the user-land... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
You can stick the screen saver in a low priority kthread and achieve the same effect. As the screen saver accesses and uses syscons' internal structures and facilities, its operation must be carefully coordinated with syscons. Thus, putting the screen saver in a kthread will require major restructuring in various parts of syscons. It is much easier, at least to me, to just remove much of the KLD screen saver support from syscons to the user-land, than to utilize the kthread :-) You can use kldload or the loader with the -t 'foo' stuff to load configuratio n files, etc. that modules can get at. Um, I know the loader can load arbitrary files in the kernel space with its '-t' option (the splash screen actually uses it to load a bitmap). But, can kldload do similar thing? It donesn't look it can... Kazu Just pointing out that userland is not the only way of achieving your goals. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
It is much easier, at least to me, to just remove much of the KLD screen saver support from syscons to the user-land, than to utilize the kthread :-) Just FWIW, I think that moving the screen saver to userspace is an excellent thing to do. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: filesystem errors
In message [EMAIL PROTECTED], Michael Harnois writes:
I'm tearing my hair out trying to find a filesystem error that's
causing me a panic: ufsdirhash_checkblock: bad dir inode.
When I run fsck from a single user boot, it finds no errors.
When I run it on the same filesystem mounted, it finds errors: but, of
course, it then can't correct them
[Kirk, I'm cc'ing you because here the dirhash code sanity checks
found a directory entry with d_ino == 0 that was not at the start
of a DIRBLKSIZ block. This doesn't happen normally, but it seems
from this report that fsck does not correct this. Is it a basic
filesystem assumption that d_ino == 0 can only happen at the start
of a directory block, or is it something the code should tolerate?]
Interesting - this is an error reported by the UFS_DIRHASH code
that you enabled in your kernel config. A sanity check that the
dirhash code is performing is failing. These checks are designed
to catch bugs in the dirhash code, but in this case I think it may
be a bug that fsck is not finding this problem, or else my sanity
tests are too strict.
A workaround is to turn off the sanity checks with:
sysctl vfs.ufs.dirhash_docheck=0
or to remove UFS_DIRHASH from your kernel config. You could also
try to find the directory that is causing the problems. Copy the
following script to a file called dircheck.pl, and try running:
chmod 755 dircheck.pl
find / -fstype ufs -type d -print0 | xargs ./dircheck.pl
That should show up any directories that would fail that dirhash
sanity check - there will probably just be one or two that resulted
from some old filesystem corruption.
Ian
#!/usr/local/bin/perl
while (defined($dir = shift)) {
unless (open(DIR, $dir)) {
print STDERR $dir: $!\n;
next;
}
$b = 0;
my(%dir) = ();
while (sysread(DIR, $dat, 512) == 512) {
$off = 0;
while (length($dat) 0) {
($dir{'d_ino'}, $dir{'d_reclen'}, $dir{'d_type'},
$dir{'d_namlen'}) = unpack(LSCC, $dat);
$dir{'d_name'} = substr($dat, 8, $dir{'d_namlen'});
$minreclen = (8 + $dir{'d_namlen'} + 1 + 3) (~3);
$gapinfo = ($dir{'d_reclen'} == $minreclen) ? :
sprintf([%d], $dir{'d_reclen'} - $minreclen);
if ($dir{'d_ino'} == 0 $off != 0) {
printf(%s off %d ino %d reclen 0x%x type 0%o
. namelen %d name '%s' %s\n,
$dir, $off, $dir{'d_ino'},
$dir{'d_reclen'}, $dir{'d_type'},
$dir{'d_namlen'}, $dir{'d_name'},
$gapinfo);
}
if ($dir{'d_reclen'} length($dat)) {
die reclen too long!\n;
}
$dat = substr($dat, $dir{'d_reclen'});
$off += $dir{'d_reclen'};
}
$b++;
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: filesystem errors
On Thu, 26 Jul 2001 15:14:09 +0100, Ian Dowse [EMAIL PROTECTED] said: That should show up any directories that would fail that dirhash sanity check - there will probably just be one or two that resulted from some old filesystem corruption. The only result it generated was /usr/home/mdharnois off 120 ino 0 reclen 0x188 type 010 namelen 14 name '.fetchmail.pid' [368] and that file is destroted and recreated every couple of minutes. -- Michael D. Harnois bilocational bivocational Washburn, Iowa Minneapolis, Minnesota Sed quis custodiet ipsos custodes? -- Juvenal To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: filesystem errors
In message [EMAIL PROTECTED], Michael Harnois writes: The only result it generated was /usr/home/mdharnois off 120 ino 0 reclen 0x188 type 010 namelen 14 name '.fetc hmail.pid' [368] and that file is destroted and recreated every couple of minutes. It's the directory (/usr/home/mdharnois), not the file that is the problem. If you recreate the directory: cd /usr/home mv mdharnois mdharnois.old mkdir mdharnois chown mdharnois:mdharnois mdharnois # (or whatever) mv mdharnois.old/* mdharnois/ mv mdharnois.old/.[a-zA-Z0-9]* mdharnois/ rmdir mdharnois.old this problem should go away permanently. Even just creating loads of files in the existing directory might be enough to reuse the bit of the directory that has d_ino == 0. Running ./dircheck.pl /usr/home/mdharnois will check if there is still a problem. However, I'd like to know if this is something that fsck should detect and correct automatically. It is an odd case, because the ffs filesystem code never creates directory entries like this, but I think it will not object to them if it finds them. This kind of ambiguity is probably a bad thing. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gif devices in -current
When I compiled/installed -current, and started setting things up again, I noticed that gif devices now expect IPv6 prefix lengths of 128. Most providers use 127, and some even use 64 as prefix lengths for tunnels. I was just curious why the change was made to only support prefix lengths of 128. Is there an RFC that covers this perhaps? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make world broken by STDIN_ changes
=== usr.sbin/pcvt/vttest cc -O -pipe -march=k6 -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/pcvt/vttest/main.c /usr/src/usr.sbin/pcvt/vttest/main.c: In function `readnl': /usr/src/usr.sbin/pcvt/vttest/main.c:1942: `STDIN_FILENO' undeclared (first use in this function) /usr/src/usr.sbin/pcvt/vttest/main.c:1942: (Each undeclared identifier is reported only once /usr/src/usr.sbin/pcvt/vttest/main.c:1942: for each function it appears in.) *** Error code 1 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Recursing on a non-recursive lock
Hi All, For a while now (July 12 first noticed) I've been experiencing a intermittent panic on a non-recursive lock. Whilst I can grab the panic, savecore panics again writing it. It seems to occur only under heavy disk io and hence a make install of XFree86 causes the condition (not always at the same place). Details below: This always occurs sometime before the panic: lock order reversal 1st 0xc907c1fc process lock @ ../../../vm/vm_glue.c:469 2nd 0xc0b4cfb0 lockmgr interlock @ ../../../kern/kern_lock.c:239 Then sometime later (beware, hand transcribed)... recursed on non-recursive lock (sleep mutex) process lock @ ../../../kern_lock:262 first acquired @ ../../../kern/kern_exit.c:327 panic: recurse Debugger(panic) Stopped at Debugger+0x45: pushl %ebx dbtrace Debugger(c040a27b) at Debugger+0x45 panic(c040cf28,0,c04ad7fc,c907bca0,0) at panic 0x70 witness_lock(c907bdbc,8,c04087b4,106) at witness_lock+0x356 lockmgr(c04ad7fc,1,0,c907bca0,c90ced88) at lockmgr+0x200 vm_map_lock_read(c04ad7cc,1,c907bca0,c04ad7cc,c027f001) at vm_map_lock_read+01a vm_map_lookup(c90cee04,c9122000,1,c90cee08,c90cedfc) at vm_map_lookup+0x5f vm_fault1(c04ad7cc,c9122000,1,0,0) at vm_fault1+0x90 vm_fault(c04ad7cc,c9122000,1,0,0) at vm_fault+0x96 trap_pfault(c90ceee0,0,c91222ac) at trap_pfault+0x2d1 trap(c0400018,10,c9070010,c907bca0,c90cdd18) at trap+0x774 calltrap() at tcalltrap+0x5 --- trap 0xc, eip = 0xc024aac2, esp = 0xc90cef20, ebp=0xc90cef40 exit1(c907bca0,0,c90cefa0,c03b35a9,c907bca0) at exit1+0x1006 sys_exit(c907bca0,c90cef80,,0,80bc608) at sys_exit+0x15 syscall(80b002f,812002f,bfbf002f,80bc608,0) at syscall+0x695 syscall_with_err_pushed() at syscall_with_err_pushed+01b --- syscall ( 1, FreeBSD Elf, sys_exit), eip=0x8093f54, esp=0xbfbfd0e0, ebp=0xbfbfd10c dbshow locks exclusive( sleep mutex ) lockmgr ( 0xc0480700 ) locked @ ../../../kern/kern_lock.c:239 exclusive( sleep mutex ) process lock ( 0xc907bdbc ) locked @ ../../../kern/kern_exit.c:327 exclusive ( sx ) proctree (0xc04be5e0) locked @ ../../../kernl/kern_exit.c:282 exclusive (sleep mutex) Giant ( 0xc04c4400) locked @ ../../../vm/vm_fault.c:195 Other useful stuff (tired of transcribing): Fatal trap 12: page fault while in kernel mode fault code = supervisor read, page not present current process = 5756 (ld) If this is not enough to help diagnose the problem, what else can I provide (sadly I can't give symbols as this fault occured compiling the kernel :( The machine is a Dell Inspiron 8000 laptop (dmesg attached) and the problem is getting more frequent with newer kernels. Cheers, Benjamin Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Jul 26 16:39:37 CST 2001 root@draco:/usr/src/sys/i386/compile/NEWCARD Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (698.48-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134127616 (130984K bytes) avail memory = 124493824 (121576K bytes) Preloaded elf kernel kernel at 0xc05c5000. Preloaded splash_image_data /boot/splash.bmp at 0xc05c509c. Preloaded elf module snd_maestro3.ko at 0xc05c50ec. Preloaded elf module snd_pcm.ko at 0xc05c5190. Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 10 entries at 0xc00fbc20 acpi0: DELL CPi R on motherboard Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu: CLK_VAL field overflows P_CNT register acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 acpi_pcib0: Host-PCI bridge on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) pcib2: PCI-PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib2 pcm0: ESS Technology Maestro3 port 0xdc00-0xdcff mem 0xf6ffe000-0xf6ff irq 5 at device 3.0 on pci2 pcib3: PCI-PCI bridge at device 6.0 on pci2 pci3: PCI bus on pcib3 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xecc0-0xecff mem 0xf8e0-0xf8ef,0xf8fff000-0xf8ff irq 11 at device 4.0 on pci3 fxp0: Ethernet address 00:20:e0:64:53:e7 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci3: simple comms at 8.0 (no driver attached) pccbb0: TI4451 PCI-CardBus Bridge irq 11 at device 15.0 on pci2 pcib2: device pccbb0 requested
Re: su root broken in -CURRENT
On Wed, 25 Jul 2001 19:20:45 MST, Kris Kennaway wrote: Isn't this backwards? Code shouldn't be making assumptions about the special meaning of numeric gids. What if you wanted to renumber gid wheel to something else? So? My primary group is 0. In /etc/group, group wheel's numeric value is 0. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Strange select(2) misbehaviour when linked with -pthread
Hi,
I found that the attached small program behaves very strangely when
linked with -pthread - it chews 100% CPU cycles while waiting in
select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE
systems. *weird*
-Maxim
P.S. And yes, I know that I ought to use NULL instead of tv when I
want to wait indefinitely in select(2), but it is how some programs
work.
#include stdio.h
#include string.h
#include sys/types.h
#include sys/time.h
#include unistd.h
int main()
{
int retval, fd;
u_int32_t timeout;
struct timeval tv;
fd_set mask;
fd = 0;
timeout = ~0;
tv.tv_sec = timeout/1000;
tv.tv_usec = (timeout%1000)*1000;
FD_ZERO(mask);
FD_SET(fd, mask);
retval = select(1, mask, NULL, NULL, tv);
exit(0);
}
HEADS UP: ACPI bug
There is a bug in the Intel ACPI CA code which will cause your system to power off upon waking from suspend mode. Iwasaki-san tracked it down and posted a fix to the acpi-jp list (message 1186) for folks that want to patch locally. Intel have adopted the patch, and the next update will fix this problem. (I would assume sometime in the next 2-3 weeks.) Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Strange select(2) misbehaviour when linked with -pthread
On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote: I found that the attached small program behaves very strangely when linked with -pthread - it chews 100% CPU cycles while waiting in select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE systems. *weird* The timeout is too long. At the moment there is an arbitary limit on how long you can wait 'cos the kernel incorrectly uses itimerfix on the timeout passed to select. I have patches to improve the situation and I was waiting for Bruce to review them, but I've been using them at home for ages, so maybe I should just commit them. The patches only have select return an error if the timeout is too long to be implimented using the kernel's counters. P.S. And yes, I know that I ought to use NULL instead of tv when I want to wait indefinitely in select(2), but it is how some programs work. Or don't work as the case may be ;-) Posix doesn't actually require select to be able to deal with large wait times (I think 31 days was the figure I found in the SUSv2 spec). Have a look at: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18909 for more details. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Strange select(2) misbehaviour when linked with -pthread
On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote: I found that the attached small program behaves very strangely when linked with -pthread - it chews 100% CPU cycles while waiting in select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE systems. *weird* The timeout is too long. At the moment there is an arbitary limit on how long you can wait 'cos the kernel incorrectly uses itimerfix on the timeout passed to select. I have patches to improve the situation and I was waiting for Bruce to review them, but I've been using them at home for ages, so maybe I should just commit them. The patches only have select return an error if the timeout is too long to be implimented using the kernel's counters. I am not sure that the error is what we want to get in this situation. Perhaps more *compatible* solution would be wait indefinitely if timeout is too large. P.S. And yes, I know that I ought to use NULL instead of tv when I want to wait indefinitely in select(2), but it is how some programs work. Or don't work as the case may be ;-) Posix doesn't actually require select to be able to deal with large wait times (I think 31 days was the figure I found in the SUSv2 spec). Have a look at: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18909 for more details. Interesting, but this isn't really relevant to my question. I want to know why the program in question behaves difefrently when linked with and without -pthead flag (bug in libc_r?). Also [EINVAL] is not what I'm seeing here, because as you can easily check in my test case tv.tv_sec == 4294976, which is less that 10 - upper limit of our select(2) implementation depicted in PR 18909. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: HEADS UP: ACPI bug
On 24-Jul-01 Mike Smith wrote: There is a bug in the Intel ACPI CA code which will cause your system to power off upon waking from suspend mode. Iwasaki-san tracked it down and posted a fix to the acpi-jp list (message 1186) for folks that want to patch locally. Intel have adopted the patch, and the next update will fix this problem. (I would assume sometime in the next 2-3 weeks.) And Peter has committed the patch to the INTEL vendor branch already... -- 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: Strange select(2) misbehaviour when linked with -pthread
In message [EMAIL PROTECTED] David Malone writes: : Or don't work as the case may be ;-) Posix doesn't actually require : select to be able to deal with large wait times (I think 31 days was : the figure I found in the SUSv2 spec). Have a look at: 31 days, interestingly enough, is very close to the amount of time it takes for a 32 bit counter to wrap in milliseconds. Oh, wait, that's 49 days and a little bit. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3dfx module breaks without /sys symlink
I remember getting mails about my driver before, so it's ok. Basically, whenever bsd.kmod.mk is broken, my module (being the first in the list), is always where the error pops up. I'll take a look at it, but you shouldn't be using it on -stable. It is only guaranteed to work on -current, in fact, all my stable patches are out of date since I no longer have been running -stable (and -current is where new features belong). On Wed, Jul 25, 2001 at 12:51:57PM +0200, Sheldon Hearn wrote, and it was proclaimed: On Wed, 25 Jul 2001 03:45:34 MST, Dima Dorfman wrote: This isn't Coleman's fault; it's a bug in bsd.kmod.mk, which was fixed in r1.86 (or r1.75.2.3 in RELENG_4), and it affects all modules (3dfx is failing because it's first on the list). Are you running a stale -stable (e.g., before 2001/05/18)? I'm running -stable as of last week, so no. Ciao, Sheldon. PGP signature
Re: gif devices in -current
When I compiled/installed -current, and started setting things up again, I noticed that gif devices now expect IPv6 prefix lengths of 128. Most providers use 127, and some even use 64 as prefix lengths for tunnels. I was just curious why the change was made to only support prefix lengths of 128. Is there an RFC that covers this perhaps? either of the following works. the other configurations are now considered ambiguous. (the point is, if you specify prefixlen 128 you don't need to say the peer's address) # ifconfig inet6 A prefixlen X (X can be 128) # ifconfig inet6 A B prefixlen 128 itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gif devices in -current
On Fri, 27 Jul 2001 [EMAIL PROTECTED] wrote: either of the following works. the other configurations are now considered ambiguous. (the point is, if you specify prefixlen 128 you don't need to say the peer's address) # ifconfig inet6 A prefixlen X (X can be 128) # ifconfig inet6 A B prefixlen 128 ah. now, that makes common sense. *hasn't thunk too hard lately*. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lock order reversals that aren't problematic
I'm curious what the long-term plan is for witness(4). For example, it complains about BPF and device locks being reversed when BPF takes the device out of promiscuous mode -- lock order reversal 1st 0xc04c1560 bpf global lock @ /usr/src/sys/net/bpf.c:365 2nd 0xc1302b88 dc1 @ /usr/src/sys/pci/if_dc.c:3251 This is because when traffic is being handed to bpf from the device, the device is locked so witness first sees dc1's lock and then bpf's. The lock reversal occurs when the socket is closed; bpfclose() calls bpf_detachd() which calls ifpromisc() which calls into the device, which obtains its lock, but bpf is already locked.. It's hard to add this case to the blessed_list, since it can be any ethernet driver paired with bpf. Basically, I'm curious if this is a problem that needs to be solved (i.e. the eventual goal is for witness to never print any notices) or if this is expected behavior (i.e. witness is expected to say things and it's up to the developer to determine if a given thing that witness says is a problem). Thanks, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
