Getting USB detach events enabled in time for 5.2-R?
Hi all, I was wondering if there's any possibility in getting USB detach events working in time for the 5.2 release? The PR in question is kern/46488, and I submitted patches for this issue quite a while ago (Oct 24). Unfortunately jmg appears to be busy with other things as I have been unable to get in touch with him to discuss this one. The basic issue is that currently no USB detach events are delivered when a device detaches. The particular call to do so is commented out in usb_subr.c, and I discovered why when I brought it back in action - Instant Panic(tm) on detach for some devices. I rooted out why it happens and provided patches for it (see specifics in the PR and referenced emails there). The changes are quite small (~5 lines), and have been verified by others than myself. My reasoning for wanting this fixed in time for 5.2-R is that it's functionality advertised in the manpages for e.g. usbd(8), and it's quite important for people who rely on external USB keyboards for their laptops, amongst other things. If I'm being too pushy about this, then my apologies, but I wanted to bring this one into the spotlight for a moment since I think it's a good tradeoff in terms of functionality gained vs effort involved. If I can be of any further assistance in regards to this, please let me know. Regards, /Johny -- Johny Mattsson - System Designer ,-. ,-. ,-. There is no truth. http://www.earthmagic.org _.' `-' `-' There is only perception. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On 26 Nov, Stefan Ehmann wrote:
I got the following panic twice when starting xawtv using 5.2 BETA (CVS
from Oct 23)
panic: blockable sleep lock (sleep mutex) sellck
@/usr/src/sys/kern/sys_generic.c:1145
I don't think it is directly related to bktr since the last commit there
was ~3 months ago. Here is the dmesg output for completeness though.
bktr0: BrookTree 878 mem 0xdf103000-0xdf103fff irq 10 at device 12.0
on pci0
bktr0: Card has no configuration EEPROM. Cannot determine card make.
bktr0: IMS TV Turbo, Philips FR1236 NTSC FM tuner.
Here is a backtrace:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-undermydesk-freebsd...
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
panic messages:
--
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
syncing disks, buffers remaining... 3023 3023 panic: mi_switch: switch
in a critical section
#5 0xc05153b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#6 0xc053c010 in witness_lock (lock=0xc076cf40, flags=8,
file=0xc06d2139 /usr/src/sys/kern/sys_generic.c, line=1145)
at /usr/src/sys/kern/subr_witness.c:609
#7 0xc050b57a in _mtx_lock_flags (m=0xc3a56dc0, opts=0,
file=0xc06ff79c \037#nÀ\t, line=-1065955520)
at /usr/src/sys/kern/kern_mutex.c:221
#8 0xc0540436 in selrecord (selector=0xc076cf40, sip=0xc3a56dc0)
at /usr/src/sys/kern/sys_generic.c:1145
#9 0xc08509f1 in bktr_poll () from /boot/kernel/bktr.ko
The bktr_poll() implementation invokes the macros DISABLE_INTR() and
ENABLE_INTR() as a wrapper around a block of code that calls
selrecord().
DISABLE_INTR(s);
if (events (POLLIN | POLLRDNORM)) {
switch ( FUNCTION( minor(dev) ) ) {
case VBI_DEV:
if(bktr-vbisize == 0)
selrecord(td, bktr-vbi_select);
else
revents |= events (POLLIN | POLLRDNORM);
break;
}
}
ENABLE_INTR(s);
The implementation of DISABLE_INTR() and ENABLE_INTR() is defined in
bktr_os.h as:
#if defined(__FreeBSD__)
#if (__FreeBSD_version =50)
#define DECLARE_INTR_MASK(s)/* no need to declare 's' */
#define DISABLE_INTR(s) critical_enter()
#define ENABLE_INTR(s) critical_exit()
#else
The man page for critical_enter() and friends says:
DESCRIPTION
These functions are used to prevent preemption in a critical region of
code. All that is guaranteed is that the thread currently executing on a
CPU will not be preempted. Specifically, a thread in a critical region
will not migrate to another CPU while it is in a critical region. The
current CPU may still trigger faults and exceptions during a critical
section; however, these faults are usually fatal.
The cpu_critical_enter() and cpu_critical_exit() functions provide the
machine dependent disabling of preemption, normally by disabling inter-
rupts on the local CPU.
The critical_enter() and critical_exit() functions provide a machine
independent wrapper around the machine dependent API. This wrapper cur-
rently saves state regarding nested critical sections. Nearly all code
should use these versions of the API.
Note that these functions are not required to provide any inter-CPU syn-
chronization, data protection, or memory ordering guarantees and thus
should not be used to protect shared data structures.
These functions should be used with care as an infinite loop within a
critical region will deadlock the CPU. Also, they should not be inter-
locked with operations on mutexes, sx locks, semaphores, or other syn-
chronization primitives.
The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
cause a context switch if the mutex is already locked by another thread.
This is contrary to what bktr_poll() wants to accomplish by calling
critical_enter().
I'm guessing that bktr_poll() wants to prevent bktr-vbisize from being
updated by an interrupt while the above mentioned block of code is
executing, possibly to prevent a select wakeup from being missed. If
this is correct, the proper fix would probably be for a mutex to be
added to the bktr structure, and the DISABLE_INTR() and ENABLE_INTR()
calls above to lock and unlock this mutex. Other places in the code
that manipulate bktr-vbisize should grab the mutex before doing so, and
there are places in the code that are currently calling tsleep() that
should probably be
Re: pcm(4) related panic
On Nov 25, Don Lewis wrote:
On 25 Nov, Don Lewis wrote:
On 25 Nov, Artur Poplawski wrote:
Artur Poplawski [EMAIL PROTECTED] wrote:
Hello,
On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic
like this:
Sleeping on swread with the following non-sleepable locks held:
exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \
/usr/src/sys/dev/sound/pcm/dsp.c:146
This enables the panic.
panic: sleeping thread (pid 583) owns a non-sleepable lock
Then the panic happens when another thread tries to grab the mutex.
The problem is that the pcm code attempts to hold a mutex across a call
to uiomove(), which can sleep if the userland buffer that it is trying
to access is paged out. Either the buffer has to be pre-wired before
calling getchns(), or the mutex has to be dropped around the call to
uiomove(). The amount of memory to be wired should be limited to
'sz' as calculated by chn_read() and chn_write(), which complicates the
logic. Dropping the mutex probably has other issues.
Following up to myself ...
It might be safe to drop the mutex for the uiomove() call if the code
set flags to enforce a limit of one reader and one writer at a time to
keep the code from being re-entered. The buffer pointer manipulations
in sndbuf_dispose() and sndbuf_acquire() would probably still have to be
protected by the mutex. If this can be made to work, it would probably
be preferable to wiring the buffer. It would have a lot less CPU
overhead, and would work better with large buffers, which could still be
allowed to page normally.
Don,
I never would have suspected that uio might sleep and panic,
thanks for the clue.
Artur,
Could you try the attached patch.
Thanks,
--Mat
--
Any idiot can face a crisis; it is this day-to-day living
that wears you out.
- Chekhov
--- channel.c Sun Nov 9 04:17:22 2003
+++ /sys/dev/sound/pcm/channel.cWed Nov 26 02:21:14 2003
@@ -250,6 +250,8 @@
{
int ret, timeout, newsize, count, sz;
struct snd_dbuf *bs = c-bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
/*
@@ -291,7 +293,22 @@
sz = MIN(sz, buf-uio_resid);
KASSERT(sz 0, (confusion in chn_write));
/* printf(sz: %d\n, sz); */
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 togo 0) {
+ p = sndbuf_getfreeptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_acquire(bs, NULL, t);
+ }
+ ret = 0;
+#endif
if (ret == 0 !(c-flags CHN_F_TRIGGERED))
chn_start(c, 0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
current freezing with sendmail-msp sumitting to ipv6 ::1.25
Hi, yesterday I tried to make the system's sendmail-msp submit to ::1.25 instead of 127.0.0.1:25 on an up-to-date FreeBSD-current installation . When injecting a lot of messages via bsmtp (rsmtp command) the system freezes solid after putting about 10 to 20 into the mail queue and doesn't even get as far as delivering them into the user's mailbox. There are no messages on the console or in the log files, the console doesn't respond any more and only way to revive the system is a hard reboot. Reverting to the old setting makes everything work fine again. Am I just doing it the wrong way round[tm] or is there some instability with IPv6 in FreeBSD-current? -- bye, Micha I hate forms! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
On Tue, Nov 25, 2003 at 09:14:10PM -0700, M. Warner Losh wrote: We recommend make buildworld make buildkernel make installkernel reboot -s - single user make installworld make buildkernel ; make installkernel can be shortened to just make kernel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Terry Lambert wrote: Stefan Farfeleder wrote: On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. Wrong, counter-example: strtol(). Wrong; the standard specifies that the errno shall only be checked when the return value is -1. The exception in the strtol() case is only for presetting errno to 0 before you make the call, and making a check only following a -1 return. Wrong, strtol() can set errno in two cases, when the value is outside the range of representable values or when no conversion could be performed. In the former case it will either return LONG_MIN or LONG_MAX and set errno to ERANGE, in the latter case it will return 0 and set errno to EINVAL. The return value of -1 has thus no special meaning and if your strtol() implementation is standard compliant and you set errno to 0 prior to calling it as you should, errno will always be 0 after strtol() has returned -1. The only cases where there is a _potential_ error returned by strtol() is when it returns 0, LONG_MIN or LONG_MAX. The behaviour described here is for a strtol() compliant with the IEEE Std 1003.1-2001 standard. In strict ISO C, strtol() is not forced to set errno to EINVAL when no conversions could be performed, it only has to return 0. Moreover, the implementation may set errno to something even when the conversion was successful. So, in strict ISO C, errno is meaningful only if strtol() returns LONG_MIN or LONG_MAX. In any case, a return value of -1 does not mean anything for strtol(). Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Wrong, strtol() can set errno in two cases, when the value is outside the range of representable values or when no conversion could be performed. well 'natch. it's trying to do math.h style hacks and overloads errno. iirc those sorts of things stem from V6/V7 on the PDP/11 when you may have had no FPU and 32 bit ops were library functions. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
Brad Knowles wrote: At 2:48 PM -0800 2003/11/25, Matthew Dillon wrote: What I am advocating is that FreeBSD-5 not marginalize and restrict (make less flexible) basic infrastructure in order to get other infrastructure working. If you've got working, debugged code that works in the manner you are espousing, and still achieves the same goal of making NSS and PAM work everywhere, I'm sure we'd all love to see it. In the absence of any code contribution to the contrary, I see no alternative than the method that has been selected. Sure, it's not great. Sure, it's slower (more or less, depending on which benchmarks you believe). I don't know what Matt is planning on delivering, but... http://developer.apple.com/darwin/projects/opendirectory/ [...] lookupd is included with the Darwin project and is documented online in Apple's Support database and as part of Mac OS X and Darwin in the form of man pages. [...] FreeBSD has also been offered, at least three times, similar proxy code from two universities, under BSD license. I think the ball is in the court of the people asking Where is the code? to take the code which has been made available, and commit it. Lest this be considered advocacy, let me emphasize that I think it is not the canonically correct approach to do this. FWIW, my personal presference is a libdlopen that can be linked statically. I've explained how to make one three times, have offered my own prototype code (which requires GCC modifications to constructor parameter lists in the generated code, for C++ to continue working), and an European fellow posted an implementation that, while it didn't add full functionality, was good enough to enable writing PAM and NSS modules, at least, even though it would not permit a satically linked JRE to run JNI modules. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
At 12:23 AM -0500 11/26/03, Michael Edenfield wrote: Just to provide some real-world numbers, here's what I got out of a buildworld: I have reformatted the numbers that Michael reported, into the following table: Static /bin/sh: Dynamic /bin/sh: real385m29.977s real455m44.852s = 18.22% user111m58.508s user113m17.807s = 1.18% sys 93m14.450s sys 103m16.509s = 10.76% user+sys = 5.53% Here are some buildworld numbers of my own, from my system. In my case, I am running on a single Athlon MP2000, with a gig of memory. It does a buildworld without paging to disk. Static sh, No -j: Dynamic sh, No -j: real84m31.366s real86m22.429s = 2.04% user50m33.013s user51m13.080s = 1.32% sys 29m59.047s sys 33m04.082s = 10.29% user+sys = 4.66% Static sh, -j2:Dynamic sh, -j2: real92m38.656s real95m21.027s = 2.92% user51m48.970s user52m29.152s = 1.29% sys 32m07.293s sys 34m40.595s = 7.95% user+sys = 3.84% Buildworld, static, with no '-j', executed /bin/sh 32,308 times. Buildworld, static, with '-j2', executed /bin/sh 32,802 times. (I was expecting a much larger difference between the number of /bin/sh's in a plain 'make buildworld' versus 'make -j2 buildworld' But apparently I was wrong...). On all attempts, I started out by doing: rm -Rf /usr/obj/usr/src/* sync ; sleep 1 ; sync ; sleep 1 ; sync before doing the 'make' command. I usually start up a 'script' command to capture the output of buildworld, but I did not do that for these tests. All of the above buildworlds were typed in at the console. Plain console, no X11 running. All are running on a snapshot of -current as of sometime Tuesday. All are compiling the exact same /usr/src (left over from installing that snapshot of -current). Aside: building 5.1-security on this same hardware took the following times: real54m10.092s [ 71.03% ] user41m39.121s [ 24.40% ] sys 10m20.325s [ 210.69% ] And those times *are* with 'script' running, as well as a perl-script which I use to summarize interesting data from the output of a buildworld. So, those times include extra overhead which is not included in the above buildworlds. That's from a 'make -j3', and obviously has a static /bin/sh. So, if you take that as the base, then the buildworld for 5.2-release (using *static* /bin/sh and -j2) will see the performance hits that I put in brackets. That probably seems like a pretty horrifying hit, but remember that 5.1-release did *not* build /rescue at all (not for me at least :-), and that is probably a significant part of the increase. I add all this just because it is easy to imagine that some people will do world-stones of 5.1-release vs 5.2-release, and might assume that the entire difference is due to /bin/sh or the dynamic /bin /sbin in general. The above is not a good enough benchmark to say *where* the time has gone, but please consider the issue of building /rescue! I have attempted to do a decent job at coming up with all these numbers, but I'm sure they are not perfect. It would be good to use something other than world-stones as a benchmark, but of course I'm not volunteering to do that... For those who think I'm spoiled by fast hardware, please note that all of the above has been done while doing just two buildworlds and one buildkernel+installkernel on my sparc64 box (and that second buildworld is not done yet...). So I certainly am interested in how freebsd runs on slower HW! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal Trap 1: priviliged instruction fault while in kernel mode
Instruction pointer: 0x8:0c021B8C0 And then the box was frozen solid The trap occured while compiling world over NFS V3/UDP. FreeBSD 5.1-RELEASE-p10 #0: Tue Oct 28 22:09:12 CET 2003 [EMAIL PROTECTED]:/mnt2/obj/usr/src51/src/sys/FILES Preloaded elf kernel /boot/kernel/kernel at 0xc04b6000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 199904643 Hz CPU: Cyrix 6x86MX (199.90-MHz 686-class CPU) Origin = CyrixInstead Id = 0x600 Stepping = 0 DIR=0x0753 Features=0x80a135FPU,DE,TSC,MSR,CX8,PGE,CMOV,MMX real memory = 100663296 (96 MB) avail memory = 92393472 (88 MB) With other Traps I've seen suggestions as to defective hardware. Would this be in the same category, or would the Cyrix processor account for this?? Thanx, --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
recent current panic
i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c0898daf,0,c087197f,d629d8dc,100) at Debugger+0x55 panic(c087197f,c0854d72,c168bd00,c095c9e0,d629d9fc) at panic+0x156 if_simloop(c2cace00,c168bd00,2,0,1) at if_simloop+0xc5 looutput(c2cace00,c168bd00,c2c86290,c2f31400,14b) at looutput+0xde ip_output(c168bd00,0,0,0,0) at ip_output+0xce1 tcp_output(c2f53000,c1687800,c08a4a60,29e,0) at tcp_output+0xcd0 tcp_usr_send(c2f23000,0,c1687800,0,0) at tcp_usr_send+0x1bd sosend(c2f23000,0,d629dc80,c1687800,0) at sosend+0x44d soo_write(c2dafd48,d629dc80,c310f280,0,c2caedc0) at soo_write+0x70 dofilewrite(c2caedc0,c2dafd48,0,805e640,2b) at dofilewrite+0xfb write(c2caedc0,d629dd14,c08b7a15,3ee,3) at write+0x6e syscall(2f,2f,2f,805f1a7,) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282c50af, esp = 0xbfbfe9ec, ebp = 0xbfbfea08 --- db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Marcel Moolenaar wrote: On Tue, Nov 25, 2003 at 05:44:18PM -0800, Terry Lambert wrote: E.B. Dreger wrote: Dynamic linking works by the kernel running the dynamic linker, which loads shared objects and fixes the symbol tables, yes? No. Dynamic linking works because the crt0 mmap's the /usr/libexec/ld.so file as executable, and then points known stub offsets into it. No. Dynamic linking works because the kernel loads and runs the dynamic linker when it sees that the executable defines an interpeter. Since I have patches to make dlopen work with static binaries, and it doesn't work this way, I must conclude you have not really looked deeply into solving the problem. While the ELF specification, and the SVID III, specifically set aside enough space that you can leave the first page unmapped and have room for the kernel to load in the ld.so (and thereby save yourself recreating that part of the address space on exec of non-setuid/setgid binaries, where it's not a security issue), FreeBSD doesn't do this. I can only conclude that either no one has gotten around to it since I pointed it out 6 years ago, or someone is intent on FreBSD's exec beinbg slower than it needs to be. In any case, I point you to /usr/src/lib/csu/i386/crt0.c, which contains these lines of code: [...] /* Map in ld.so */ crt.crt_ba = (int)_mmap(0, hdr.a_text, PROT_READ|PROT_EXEC, MAP_FILE|MAP_PRIVATE, crt.crt_ldfd, N_TXTOFF(hdr)); [...] A complete executable (i.e. staticly linked) does not export any symbols, or at least not in the same way a shared executable and shared libraries do. This is why I keep saying that compiler work would be needed to export symbols from the original binary and any statically linked libraries. If I try to dynamicly link libbar into a complete executable foo and libbar depends on libc, then there's no guarantee that all the required bits from libc are in foo, Correct, for the current (flawed) implementation of the linker. nor is there any guarantee that the bits are actually visible or even accessable (no linkage table). In fact, there is a guaranteed that they are not there, for the current (flawed) implementation of the linker. Dynamicly loading libc for use by libbar can work, but it's not guaranteed. One failure mode is suddenly having two instances of a common variable instead of one. Another is the clobbering of data caused reinitializations. The first problem is a non-issue, at least for FreeBSD supplied libraries. For other libraries, yes, it could be an issue. The second is always a non-issue, since the loading of shared objects occurs in a hierarchy, and you are perfectly allowed to have multiple instances of different versions of shared objects existing simultaneously. In fact, if you read the dlsym(3) manual page, you will see that there exists a special handle identifier, RTLD_NEXT, specifically to enable a program to traverse this hierarchy in order to obtain the correct symbol. If you are still interested in the details of obtaining the correct subhierarchy from an arbitrary graph of such hierarchies, the way in which this is normally accomplished is to look for a symbol at your own hierarchy level, for which the address is known (since both the program iterating and the symbol you are looking for come from the same .so file and can be compared), and thereafter descend into your own branch to find the symbol in queation. So, the problem of dynamic linking a shared library into a static process is non-trivial and probably cannot be solved genericly. And yet both Solaris and SVR4 manage to accomplish this. Of course, they are not using the crt0.o code supplied by the GCC people, who have so far failed to ship a set of tools (gcc, binutils) that can do the job. The problem can be resolved generically. Under restricted and controlled conditions you can make it work. I would call it the ability to have plugins, not the ability to load dynamic libraries. Then you are probaly using the implementation that was posted to -current about half a year ago, which failed to take into account the symbol sets, and made no changes to the constructor argument list. If you look in crt0.c again, you will see a number of lines that look like this: #ifdef DYNAMIC /* ld(1) convention: if DYNAMIC = 0 then statically linked */ /* sometimes GCC is too smart/stupid for its own good */ x = (caddr_t)_DYNAMIC; if (x) __do_dynamic_link(argv); #endif /* DYNAMIC */ This is the conditional compilation unit for the dynamic crt0.o, as the same source file is use for both dynamic and static linking. The value of 'x' and 'argv' in this case are, for the first, the location of the 'struct _dynamic' that's is used to gate the call to __do_dynamic_link(), and the environment I spoke of from my previous post. The
Re: rc scripts run double on boot?
On Tue, Nov 25, 2003 at 09:35:29AM -0800, Nate Lawson wrote: With a recent -current, I've noticed double prints for the last few rc scripts, like this: Starting cron. Local package initialization:. Local package initialization:. Additional TCP options:. Additional TCP options:. Anyone else seeing this? Looks like a couple of RC scripts were renamed/moved in more recent -CURRENT than 5.1-RELEASE. this bit me recently. The offending scripts were along the lines of /etc/rc.d/network3 if I recall. There were two. I rm'd the offending ones without thinking the other day after a grep -Hr of rc.d :-) Sorry I can't be of more help :-) BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
obrien wrote @ Tue, 25 Nov 2003 18:55:05 -0800: On Tue, Nov 25, 2003 at 03:07:55PM +1030, Daniel O'Connor wrote: What about the newer version of gcc? That is considerably slower than previous versions, but I don't see people screaming to have it removed. Uh... you must not know what you are talking about. GCC *COMPILES* slower as it does a better job of optimizing (which adds time to the compiling time). The produced optimzied binaries have quicker *RUN-TIME*s. For C++ maybe, for C compile times (tripled?) stood in no relation to the run-time improvements (minor to negative), but GCC ppl are constantly improving (3.3 and on) and 2.9x was a dead horse. I see only very minor relation to the static/dynamic discussion. I don't know what the reason is for going dynamic by default _now_, but i am sure it got nothing to do with the unbelievable points presented till now like space savings or NSS. Stuff gets default when it's ready, and that would in this case mean after performance of dynamic binaries has improved and those ppl that want to introduce it present a solution, where everything has been thought of, and discussions like /bin/sh or /sbin/sh have already been had and solved. Introduce dynamic option now. Improve dynamic linking and make a good solution for a rescue. Then and only then make it the default. Everything else leads to threads like these, because it doesn't make sense to ppl. aha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Maxime Henrion wrote:
Terry Lambert wrote:
Wrong, counter-example: strtol().
Wrong; the standard specifies that the errno shall only be
checked when the return value is -1. The exception in the
strtol() case is only for presetting errno to 0 before you
make the call, and making a check only following a -1 return.
[ ... ]
The only cases where there is a _potential_ error returned by strtol()
is when it returns 0, LONG_MIN or LONG_MAX.
So check it only in those cases.
I don't see the problem with errno being set willy-nilly in a
library to multiple different values in implementing some standards
defined behaviour, so long as it's indicated correctly.
Moreover, the implementation may set errno to something
even when the conversion was successful. So, in strict ISO C, errno is
meaningful only if strtol() returns LONG_MIN or LONG_MAX.
You should write your code to expect that a 0 return is not
an error indicator, then.
You know, real hardware would SIGFPE...
In any case, a return value of -1 does not mean anything for strtol().
Which is irrelevent to the discussion about whether or not a
library is allowed to futz errno to non-0 any time it wants.
We all know that the *only* reason this issue arose is that somone
was writing bogus error checking code that did something like:
errno = 0;
(void)some_library_function_returning_neg_one_on_error();
if (errno != 0) {
printf( I should have checked my return value, but\n);
printf( standards documents and man pages confuse me.\n);
}
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: Matthew Dillon [EMAIL PROTECTED] writes: How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
wi driver reads wrong first 8 bytes when in monitor mode in data packets
If I am not wrong, it seems that the wi driver, when in monitor mode, will skip
8 bytes of data input (filling it in with random values).
We notice in if_wi.c:
case 7:
switch (rx_frame-wi_whdr.i_fc[0] IEEE80211_FC0_TYPE_MASK) {
case IEEE80211_FC0_TYPE_DATA:
hdrlen = WI_DATA_HDRLEN;
data is then read according to the hdrlen offset.
if (wi_read_bap(sc, fid, hdrlen, mtod(m, caddr_t) + hdrlen,
datlen + 2) == 0) {
in if_wavelan_ieee.h:
#define WI_DATA_HDRLEN 0x44
#define WI_MGMT_HDRLEN 0x3C
#define WI_CTL_HDRLEN 0x3C
we notice that data frames seem to have an 8 byte header extra
we then notice
/*
* all data packets have a snap (sub-network access protocol) header that
* isn't entirely definied, but added for ethernet compatibility.
*/
struct wi_snap_frame {
u_int16_t wi_dat[3];
u_int16_t wi_type;
};
(it is 8 bytes)
It seems like if the llc/snap is treated as a 802.11 header per se and not act
ual data. (Maybe this was the mentality of the developers).
Under normal circumstances this is ok, since many people do not care about sna
p/llc when in monitor mode. Infact, the ip header will be just fine.
However when auditing wep, those 8 bytes are crucial (since the first 3+1 bytes
contain IV information) and the first few bytes of cyphertext are normally used
in known plaintext attacks. Infact, bsd-airtools will probably not work at all.
I am running:
FreeBSD tribal.sorbonet.org 5.2-BETA FreeBSD 5.2-BETA #5: Wed Nov 26 05:24:11 GM
T 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SORBO i386
A very basic patch which seems to works is:
if_wavelan_ieee.h.diff:
** CUT
*** if_wavelan_ieee.h.orig Wed Nov 26 06:00:58 2003
--- if_wavelan_ieee.h Wed Nov 26 05:08:08 2003
***
*** 466,472
u_int8_twi_src_addr[6];
u_int16_t wi_len;
};
! #define WI_DATA_HDRLEN0x44
#define WI_MGMT_HDRLEN0x3C
#define WI_CTL_HDRLEN 0x3C
--- 466,472
u_int8_twi_src_addr[6];
u_int16_t wi_len;
};
! #define WI_DATA_HDRLEN0x3C
#define WI_MGMT_HDRLEN0x3C
#define WI_CTL_HDRLEN 0x3C
** CUT
Andrea Bittau
[EMAIL PROTECTED]
http://www.darkircop.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Terry Lambert writes: Since I have patches to make dlopen work with static binaries, and : [ snip ] : As to inevitable where are the patches?, please check the -current list archives, you will find at least one set there. I've looked without much success. Could you give a timeframe, a subject and/or something? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm(4) related panic
Mathew Kanner [EMAIL PROTECTED] wrote: On Nov 25, Don Lewis wrote: On 25 Nov, Don Lewis wrote: On 25 Nov, Artur Poplawski wrote: Artur Poplawski [EMAIL PROTECTED] wrote: Hello, On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic like this: Sleeping on swread with the following non-sleepable locks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ /usr/src/sys/dev/sound/pcm/dsp.c:146 This enables the panic. panic: sleeping thread (pid 583) owns a non-sleepable lock Then the panic happens when another thread tries to grab the mutex. The problem is that the pcm code attempts to hold a mutex across a call to uiomove(), which can sleep if the userland buffer that it is trying to access is paged out. Either the buffer has to be pre-wired before calling getchns(), or the mutex has to be dropped around the call to uiomove(). The amount of memory to be wired should be limited to 'sz' as calculated by chn_read() and chn_write(), which complicates the logic. Dropping the mutex probably has other issues. Following up to myself ... It might be safe to drop the mutex for the uiomove() call if the code set flags to enforce a limit of one reader and one writer at a time to keep the code from being re-entered. The buffer pointer manipulations in sndbuf_dispose() and sndbuf_acquire() would probably still have to be protected by the mutex. If this can be made to work, it would probably be preferable to wiring the buffer. It would have a lot less CPU overhead, and would work better with large buffers, which could still be allowed to page normally. Don, I never would have suspected that uio might sleep and panic, thanks for the clue. Artur, Could you try the attached patch. I've tried the patch -- and it works great! :-) I was unable to trigger the panic with the patch applied, although I tried really hard -- so I guess the problem is solved. Mat and Don, I'm really very thankful for your help. Best regards, Artur ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2 STABLE?
Will 5.2-RELEASE mark the beginning of the new STABLE branch? If not, do we know approximately when this branch is planned? Thanks in advance, Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2 STABLE?
On Wed, Nov 26, 2003 at 08:19:59AM -0600, Thomas T. Veldhouse wrote: Will 5.2-RELEASE mark the beginning of the new STABLE branch? If not, do we know approximately when this branch is planned? http://www.freebsd.org/doc/en_US.ISO8859-1/articles/5-roadmap/schedule.html -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2 STABLE?
Document of interest to you: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/5-roadmap/index.html The schedule can be found at (when RELENG_5 is scheduled to be branched): http://www.freebsd.org/doc/en_US.ISO8859-1/articles/5-roadmap/schedule.html Thomas T. Veldhouse writes: Will 5.2-RELEASE mark the beginning of the new STABLE branch? If not, do we know approximately when this branch is planned? Thanks in advance, Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Ryan leadZERO Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh [EMAIL PROTECTED] [031126 00:43]: In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : * M. Warner Losh [EMAIL PROTECTED] [031125 12:07]: : In message: [EMAIL PROTECTED] : boyd, rounin [EMAIL PROTECTED] writes: : : i see that there some doubt about whether running lots of : : shell scripts ever happens. what happens when you : : use make? lots of shells get run and they run small : : (one line?) scripts. : : make buildworld slows down 1% when you switch from static /bin/sh to : dynamic. : : I'm all for dynamic / and dynamic /bin/sh, but this doesn't even come : close to what I observed on my systems. I see anywhere from 15% to 20% : slowdown in buildworld, depending on how bad my hardware already is. I : posted my most recent numbers earlier. My dual athlon make -j 4 buildworld differed by about 16-20 seconds on a 36 minute buildworld. : It's difficult to get lots of these numbers, unfortunately, because it : takes a good 6-8 hours just to complete one build. But the numbers are : fairly consistant across the different degrees of old crappy hardware I : have. So you are seeing a about an hour slowdown (16% slowdown on 6 hours is 1 hour) from before/after? Or are you seeing an hour slowdown from 4.x - 5.2-beta? I have two 5.x systems, both with dynamic / that were built within the past month. One's a bit older, probably a month or so, as I was waiting for the statfs changes to settle before upgrading it. The other was built about 3 days ago. The first one is pretty old, I only use it for a firewall because no one will let me spring for a replacement: CPU: Pentium II/Pentium II Xeon/Celeron (399.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 66977792 (63 MB) avail memory = 60477440 (57 MB) ad0: 19470MB QUANTUM FIREBALLlct20 20 [39560/16/63] at ata0-master UDMA33 This machine usually takes 10-12 hours to do a full buildworld with -j 3 (which somehow seems to be the fastest). With static /bin/sh it was took just about an hour and a half less, but again, I could only do one pair since that took the whole day :) The other is slightly better and is my personal FreeBSD workstation, which I run -CURRENT on for test purposes and cuz I like it better :) CPU: AMD-K7(tm) Processor (499.04-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x612 Stepping = 2 Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX AMD Features=0xc040AMIE,DSP,3DNow! real memory = 335478784 (319 MB) avail memory = 316243968 (301 MB) ad0: 16603MB Maxtor 91731U4 [33735/16/63] at ata0-master UDMA66 This one completes a buildworld in about 7-8 hours, the static /bin/sh run took about an hour less. I posted those numbers here earlier. I don't have any decent hardware running 5.x, all the new machines in real user are still using 4.8, so these are the only numbers I can come up with. Again, I *like* the ability to have NSS in /bin/sh, and the idea of dynamic linking in general appeals to me. The hour to hour-and-a-half slowdown might seem huge, but `make buildworld` really is the worst case scenario I could come up with, and 15% slowdown in the *worst* real-world case is certainly much better than 40%. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* Garance A Drosihn [EMAIL PROTECTED] [031126 06:56]:
At 12:23 AM -0500 11/26/03, Michael Edenfield wrote:
Just to provide some real-world numbers, here's what I got
out of a buildworld:
I have reformatted the numbers that Michael reported,
into the following table:
Static /bin/sh: Dynamic /bin/sh:
real385m29.977s real455m44.852s = 18.22%
user111m58.508s user113m17.807s = 1.18%
sys 93m14.450s sys 103m16.509s = 10.76%
user+sys = 5.53%
Since I forgot to include this information (sorry!):
Both runs were done by doing:
rm -rf /usr/obj
sync
script logfile
cp -f /bin/sh.{dynamic,static} /bin/sh
file /bin/sh
time make -j 4 buildworld
They were on a single CPU Athlon 500 with 320MB of RAM. I actually
don't normally do -j 4 on this system, only -j 2, but I'm use to
building on the dual Athlons we use to make production kernels and it
slipped in. Since it takes hours to run once it's started I just let it
run. :)
--Mike
pgp0.pgp
Description: PGP signature
Re: Modem(PCMCIA) works on 4.8, hangs machine on 5.2-BETA
On Tue, 25 Nov 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Larry Rosenman [EMAIL PROTECTED] writes: : sio2 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0 : sio2: type 16550A : sio2: unable to activate interrupt in fast mode - using normal mode : The SIO2 is my Toshiba 3CXM056-BNW modem, and is what I'm sending this : from on 4.8. : : What debug/help do y'all need to fix it? Hmm, sounds like an interrupt storm. What kind of pccard bridge do you have? TI1520. Warner -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA + netatalk = crash
On my dual CPU P6DGH the 11/22 cvsup of 5.2-BETA and netatalk crashes on boot. Stopping netatalk from starting stops the crash. I wasn't able to catch any crash information, but am currently recompiling with sources from last night to see if it's repeatable. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB lpt and NOPRIME
I have had the problem listed in the article below for years (4.x and 5.x). I have been unable to use my Lexmark Optra 312 (USB) with FreeBSD (w/cups) because there is so often a page of trash printed before a print job begins. This ONLY happens on FreeBSD and not on Linux 2.4 (w/cups). I have posted about it here before, but never a response, but now I have found this nearly three year old reference to the very same problem and I was hoping somebody in the know might understand how a fix could be made to the FreeBSD lpt or ulpt driver. http://mail-index.netbsd.org/tech-kern/2001/02/08/0019.html Thanks in advance, Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Announcing 5.2-BETA
All, It's my pleasure to announce the availability of 5.2-BETA ISO images and ftp install sets for i386 and alpha. Amd64, sparc64, ia64, and pc98 sets will be available shortly. Please test this as much as possible and let us know of the problems that you find. Some known problems to watch out for: - Certain SMP systems may fail to boot. Disabling ACPI may work around this. - NFS might be unstable in certain situations, though we have not been able to identify what situations yet. - Rebuilding ata-raid arrays may cause panics. Please see the 5.2 TODO list at http://www.freebsd.org/releases/5.2R/todo.html for the list of other problems and areas that need testing. ISO images and ftp install sets are available from ftp.freebsd.org and its mirrors at /pub/FreeBSD/releases/ARCH. If the bits have not reached your favorite mirror yet, please check the list of alternate mirrors at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html Please help us make 5.2 the best FreeBSD release ever! Thank you, The Release Engineering Team ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
UFS lockups
I observe UFS lockups under heavy I/O. To reproduce the problem run around 10 copies of cp -Rp /usr/some-random-dir. All cp's after some time are hanging on getblk. du's running concurrently are hanging in ufs state. The filesystems are UFS2. The Server is running 5.2-BETA on SMP Dell 2650. Filesystems are laid on Adaptec RAID controller (aac). Any ideas how to trace the problem? /S ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB lpt and NOPRIME
On 2003-11-26 08:54 -0600, Thomas T. Veldhouse [EMAIL PROTECTED] wrote: I have had the problem listed in the article below for years (4.x and 5.x). I have been unable to use my Lexmark Optra 312 (USB) with FreeBSD (w/cups) because there is so often a page of trash printed before a print job begins. This ONLY happens on FreeBSD and not on Linux 2.4 (w/cups). I have posted about it here before, but never a response, but now I have found this nearly three year old reference to the very same problem and I was hoping somebody in the know might understand how a fix could be made to the FreeBSD lpt or ulpt driver. http://mail-index.netbsd.org/tech-kern/2001/02/08/0019.html Have you tried using /dev/unlpt0 instead of /dev/ulpt0 ? See man 4 ulpt ... Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Tue, Nov 25, 2003 at 01:41:53PM -0500 I heard the voice of Garance A Drosihn, and lo! it spake thus: It is a bit more complicated than that, because programs may include embedded references to other files. So, I think some developer would *have* to do a little up-front work for any program that would be optionally-added to /rescue. Oh, sure; nothing's ever as easy as it should be :) The advantage of this method is it's simple, cheap, automatic, and lets us say You can try setting ADDITIONAL_RESCUE=usr.sbin/foo in make.conf and it may work, without putting extra burden on developers or people who don't wanna. It may only be a fifth of a loaf, but... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Tue, Nov 25, 2003 at 02:17:02PM -0500 I heard the voice of
slave-mike, and lo! it spake thus:
Would it be possible to get a copy of this script?
Please! :)
Oh, it's pretty simplistic. It's actually on a box that's in the closet
right now, but I think this is an older working version:
---
liblist:
@echo '== Getting needed libraries'
-@(cd ${SRCBASE}/bin ldd ${BINFILES}) liblist.raw
-@(cd ${SRCBASE}/sbin ldd ${SBINFILES}) liblist.raw
[ ... similar stuff for other dirs ... ]
[EMAIL PROTECTED] -v '^[a-z]' liblist.raw | awk '{print $$3}' | sort | uniq \
| sed 's,^${SRCBASE},,' | sed 's,^/,,' liblist.cooked
[EMAIL PROTECTED] liblist.cooked
@tar -cf - -C ${SRCBASE} `cat liblist.cooked` \
| tar -xvpf - -C ${DSTBASE}
-@(cd ${SRCBASE}/usr/lib install -c -m 444 pam_* ${DSTBASE}/usr/lib)
@echo '== Done libraries'
---
You'll note that I already manually slipped in the pam_* .so's, which is
one of those additional non-obvious extra files things that Garance
mentioned in the other message. I could probably replace the whole
transformation pipeline with a few lines of actual scripted awk(1); I
just did it all inline in the Makefile because I was lazy.
${SRCBASE} is somewhere I DESTDIR='d an installworld previously, and
${DSTBASE} becomes (as a result of a bunch of other make targets, of
which this is one of the later ones) a dir I can tar up and untar
somewhere as /.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
On Tue, Nov 25, 2003 at 08:57:10AM -0800 I heard the voice of Kevin Oberman, and lo! it spake thus: While UPDATING contain details on updating a system, the Makefile in /usr/src (actually Makefile.inc1) contains a target of 'world' and, through V3 of FreeBSD, this was considered the appropriate target for re-compiling sources. In the days of V4, a new methodology for updating that was far less prone to failure that would leave a system unusable was developed with two new targets, 'buildworld' and 'installworld'. I think you're a wee bit off on dates there... src/Makefile: revision 1.109.2.9 date: 1997/08/05 03:46:23; author: asami; state: Exp; lines: +192 -91 This patch splits world into two parts, buildworld and installworld, which can be run together or separately (or even on different machines). The buildworld target does not install anything outside /usr/obj; you still need to be root to run it (the default install rules want to set the ownership, etc.), but it's now possible to upgrade a bunch of -stable machines by running make buildworld on a 2.1.5 NFS server and then running make installworld on each of the clients, while not compromising the stability of the server at all. Reviewed by:too many many people to list here, special thanks to bde 1.109.2.9 was between 2.2.2 and 2.2.5. It was committed in parallel to HEAD at the same time (1.133). That's all over a year before 3 became -STABLE. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: requesting vinum help
Geeze! Not only aren't there any emails, but I've started a full blown thread! --On Tuesday, November 25, 2003 8:39 AM -0800 Joel M. Baldwin [EMAIL PROTECTED] wrote: Could a vinum guru please contact me via email? I've lost 2 vinum volumes as a result of the latest fiasco and naturally am eager to figure out what's going on and recover the data. --On Tuesday, November 25, 2003 10:48 AM -0600 Eric Anderson [EMAIL PROTECTED] wrote: This isn't necessarily directed at you - I'm just using this email as a footstep to send this general comment - I am kind of under the assumption that -current is more of a test bed, and anything can happen at any time, which is why it's bad to run -current on a machine you care deeply about (at least its data). I think I've seen at least 5 mails in the past few weeks about people getting jammed into a corner with (what sounds like) production type boxes, or at least important boxes (or they wouldn't need a vinum?).. It seems odd to me that they wouldn't give it a whirl first before attempting to use it on a box they seem so protective of. Anyway, I'm just stating that running -current is for testing and developing, not really for production - at least I'm fairly certain. Please wrap your messages rather than typing your entire message in one LONG line. How can you test if you don't use? I'm not in 'production', I'm just running a box at home and I'm sure that there are lots of others doing the same. I've been running -current for something like 5 years, have rarely had any major problems, and have on occasion reported my problems to the list. That's what it's all about. The worst you could say is that I should have been more careful and that I should read -current ( which I archive but don't read because there's rarely anything of interest in the list ( with the occasional notable exception like now ) ) Feel free to delete this mail and ignore me.. Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- --On Wednesday, November 26, 2003 10:25 AM +1030 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Tuesday, 25 November 2003 at 10:48:44 -0600, Eric Anderson wrote: I am kind of under the assumption that -current is more of a test bed, and anything can happen at any time, which is why it's bad to run -current on a machine you care deeply about (at least its data). Correct. More to the point, though, it requires you to rely more on yourself. At the very least, this means RTFM, which in this case includes a number of things to submit if you have problems. It's at the end of vinum(4) or at http://www.vinumvm.org/vinum/how-to-debug.html. Does someone answer email at [EMAIL PROTECTED] I never received a response when I sent a query there and that's the email in the above URL. I've rtfm and I don't find it very useful in explaining why what should be a good vinum volume is giving me a 'fsck: Could not determine filesystem type'. A also don't know what operations would cause data damage so I'm asking for assistance rather than running around in the dark. Greg -- See complete headers for address and phone numbers. --On Wednesday, November 26, 2003 1:05 AM +0100 Max Laier [EMAIL PROTECTED] wrote: The not so good point about the original request is that he is looking for private assistance, while the problem and - even more - the solution of it might be very interesting to all of us (more than much of the other ongoing threads, for sure). I was trying to use some restraint and not rant and rave in public like I wanted to do. I'm rather miffed that nothing appeared in UPDATING. Rather than an unproductive public RANT I thought I'd ask for private assistance. I can post a summary afterwards if you like, or even better write a better FAQ/tutorial on vinum. -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound stop'd working after upgrade ...
On Wednesday 26 November 2003 01:24, Marc G. Fournier wrote: pcm0: Intel ICH4 (82801DB) port 0xe400-0xe43f,0xe000-0xe0ff mem 0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0 pcm0: Avance Logic ALC650 AC97 Codec and, from what I can tell, the proper devices are being built in /dev, but try and play music using xmms, and I get nothing ... Not sure what to debug, or where ... help? :( Does 'mixer' report anything valid? I had this over the weekend and can't remember how I cured it (I think I cvsupped at the time), but I know that mixer gave some error instead of proper stats. -- Melvyn pgp0.pgp Description: signature
Re: USB lpt and NOPRIME
Stefan Eßer wrote: Have you tried using /dev/unlpt0 instead of /dev/ulpt0 ? See man 4 ulpt ... Regards, STefan Yes, the problem occurs with both. One just takes longer to start the printjob than the other, but both will spew out a bad page prior to the first page of the job. It is not consistant with all documents printed, but the data printed on the page appears to be partial printer commands (and it is stairstepped). Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: requesting vinum help
In message [EMAIL PROTECTED], Joel M. Baldwin writes: I was trying to use some restraint and not rant and rave in public like I wanted to do. I'm rather miffed that nothing appeared in UPDATING. Rather than an unproductive public RANT I thought I'd ask for private assistance. I can post a summary afterwards if you like, or even better write a better FAQ/tutorial on vinum. Joel, The problem is that vinum is hot political potato in the project. In the eyes of a fair number of competent people, vinum has never quite made it. I think most of them have given it a shot and lost data to it. Some of them, after looking in the code to fix the problem, said never again! and now hate vinum of a good heart. Greg has disclaimed maintainership of vinum some time ago for reasons of politics, and he now is of the opinion that it is everybodys (elses) task to maintain vinum. Everybody else disagree and belive that vinum is very much Gregs own problem. With Greg being a core@ member, and well known for his ability to talk an acturan megadonkey into taking a stroll after first having talked its legs off about procedural issues, Doing something about vinum is permanently on the we should really... list and everybody hopes somebody else will deal with it. Of course, in the end nobody does. As matters stand, we are doing our users a disservice by continuing to pretend everything is OK when in fact it is not at all. Personally, I think vinum(8) should not be in our 5-STABLE featureset if it is not brought up to current standards and actively maintained. But at the very least we should have the release notes reflect that vinum is unmaintained and belived to unreliable and have vinum(8) issue a very stern warning to people along those lines. I'm sure that a major bikeshed will now ensue and people will argue that there is a lot more to this dispute than what I've said above. They're right of course, this is a very short summary :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
On Wed, Nov 26, 2003 at 04:16:06AM -0800, Terry Lambert wrote:
Dynamic linking works because the kernel loads and runs the dynamic
linker when it sees that the executable defines an interpeter.
Since I have patches to make dlopen work with static binaries, and
it doesn't work this way, I must conclude you have not really looked
deeply into solving the problem.
True. I did not look at aout.
In any case, I point you to /usr/src/lib/csu/i386/crt0.c, which
contains these lines of code:
This is aout specific code, not ELF code.
Ether way, you still need to deal with the linker changes necessary
to export the symbol set for all statically linked objects, and to
force the inclusion of all archive members when statically linking,
if one of the linked libraries is libdl, if you wanted a full
implementation.
I think the cure is worse than the decease in this case. You don't
want the full libc linked into a static sh, simply because we need
to be able to load a shared library at runtime.
If you can get gcc and binutils to add the necessary support, then
we can talk further. Until then it's academic.
BTW: IEEE 1003.1-2003 requires a full implementation of dlopen, and
does not permit an exception for statically linked binaries:
http://www.opengroup.org/onlinepubs/007904975/functions/dlopen.html
Yes it does:
\begin{quote}
... Implementations may also impose specific constraints on the
construction of programs that can employ dlopen() and its related
services.
\end{quote}
I'll also point out that the ELF specification does not define static
linking *at all*.
I think that's because it doesn't need any special mention.
Note that staticly linked executables can be in violation of platform
runtime specifications.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Wed, Nov 26, 2003 at 10:16:37AM -0600, Matthew D. Fuller wrote: The advantage of this method is it's simple, cheap, automatic, and lets us say You can try setting ADDITIONAL_RESCUE=usr.sbin/foo in make.conf and it may work, Please send a tested patch for this. :-) If ADDITIONAL_RESCUE will end the thread I'm all for it. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Nvidia problem fixed in current?
1. Was the problem with the nvidia driver ever fixed? (I reported this more than a month ago --- the kernel nvidia driver only works with parameters set to lower the speed of the interface, and even then failed with some OpenGL programs like OpenUniverse). 2. Can one upgrade to 5.2 beta by cvsupping to current and rebuilding world and kernel? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: requesting vinum help
On Wed, 26 Nov 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Joel M. Baldwin writes: I was trying to use some restraint and not rant and rave in public like I wanted to do. I'm rather miffed that nothing appeared in UPDATING. Rather than an unproductive public RANT I thought I'd ask for private assistance. I can post a summary afterwards if you like, or even better write a better FAQ/tutorial on vinum. Joel, The problem is that vinum is hot political potato in the project. In the eyes of a fair number of competent people, vinum has never quite made it. I think most of them have given it a shot and lost data to it. Some of them, after looking in the code to fix the problem, said never again! and now hate vinum of a good heart. Greg has disclaimed maintainership of vinum some time ago for reasons of politics, and he now is of the opinion that it is everybodys (elses) task to maintain vinum. Everybody else disagree and belive that vinum is very much Gregs own problem. With Greg being a core@ member, and well known for his ability to talk an acturan megadonkey into taking a stroll after first having talked its legs off about procedural issues, Doing something about vinum is permanently on the we should really... list and everybody hopes somebody else will deal with it. Of course, in the end nobody does. As matters stand, we are doing our users a disservice by continuing to pretend everything is OK when in fact it is not at all. Personally, I think vinum(8) should not be in our 5-STABLE featureset if it is not brought up to current standards and actively maintained. But at the very least we should have the release notes reflect that vinum is unmaintained and belived to unreliable and have vinum(8) issue a very stern warning to people along those lines. I'm sure that a major bikeshed will now ensue and people will argue that there is a lot more to this dispute than what I've said above. They're right of course, this is a very short summary :-) Poul-Henning I am using vinum atm, and I am having serious problems with it. After about 16 hrs of writing data to a vinum volume via NFS at a constant data stream of 200k/sec and reading at 400k/sec at the same time, the whole machine just freezes, hard. The only thing I can do is reboot. This behavior appears in 4.8 and 5-CURRENT. I have no indication of what is wrong, or how to go about finding it out. The problem is either with NFS or Vinum, and I'm leaning towards Vinum (because of the failure in both -STABLE and -CURRENT). I'm not the kind of person that relies on other people, and I like to fix my own problems, but this is a problem which I cannot fix at this time. So, I'm planning to look through the code of vinum and start messing with it to figure out how it works and how to debug it. This is how important Vinum is to me at the moment. I'm not a kernel coder, or an intense coder in general (but I'm proficient in C/C++, and have used FreeBSD for quite some years now), so I'm reading the Kernel Developer's Handbook as a starting point. If anyone has other online documentation on FreeBSD Kernel programming, it would be much appreciated. What would also be appreciated is an overall map of how vinum is organized and how it works. Otherwise, I'll have to painstaikingly go through the code and figure everything out little by little (which I plan to do, but if you know how Vinum works, everything is much easier, makes sense right away, and takes less time). Thank you in advance. Cosmin Stroe. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Matthew D. Fuller wrote: On Tue, Nov 25, 2003 at 01:41:53PM -0500 I heard the voice of Garance A Drosihn, and lo! it spake thus: It is a bit more complicated than that, because programs may include embedded references to other files. So, I think some developer would *have* to do a little up-front work for any program that would be optionally-added to /rescue. Oh, sure; nothing's ever as easy as it should be :) The advantage of this method is it's simple, cheap, automatic, and lets us say You can try setting ADDITIONAL_RESCUE=usr.sbin/foo in make.conf and it may work, without putting extra burden on developers or people who don't wanna. It may only be a fifth of a loaf, but... ... but a /rescue that doesn't work is useless. The one critical property of /rescue is that it MUST WORK when /bin and /sbin are both hosed. Your technique here cannot gaurantee this. Testing /rescue is not a simple exercise. You must first break both /bin and /sbin and unmount /usr. You must then test EVERY part of /rescue, since adding or removing one program can potentially break other programs (whose hard-coded references to that program may need to be adjusted). There are (fortunately) a few shortcuts (I spent a long time poring over the output of 'strings /rescue/rescue' to check for hard-coded references), but it's still not pretty. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Recent ATA drivers giving problems with SATA
About a month ago, I bought a new SATA controller and a 160 GB Seagate SATA drive for my -CURRENT machine. All was working fine until about a week ago. Then, the drive started experiencing hard, unrecoverable DMA errors. I RMA'd the drive, then bought a new Maxtor 80 GB SATA drive (just yesterday). I started a buildworld on this drive, and it religiously fails about half-way through all the time (never at exactly the same place twice, however). The kernels I had when the failures occurred were: FreeBSD fugu.marcuscom.com 5.2-BETA FreeBSD 5.2-BETA #0: Mon Nov 24 23:14:49 EST 2003 [EMAIL PROTECTED]:/space/obj/usr/src/sys/FUGU i386 FreeBSD fugu.marcuscom.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Nov 17 21:23:07 EST 2003 [EMAIL PROTECTED]:/space/obj/usr/src/sys/FUGU i386 Kernels before that did not experience the problem. The buildworld fails with an Input/Output error, then I see the following on the console: Nov 26 02:35:12 fugu kernel: ad4: WARNING - WRITE_DMA recovered from missing interrupt Nov 26 02:35:12 fugu kernel: ad4: FAILURE - WRITE_DMA status=ffBUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR error=0 Nov 26 02:35:22 fugu kernel: ad4: WARNING - READ_DMA recovered from missing interrupt Nov 26 02:35:22 fugu kernel: ad4: FAILURE - READ_DMA status=ffBUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR error=0 ... Nov 26 04:37:24 fugu kernel: ad4: timeout sending command=ca Nov 26 04:37:24 fugu kernel: ad4: error issuing DMA command At this point, the machine is unusable, and the above two lines scroll by continuously until the machine is rebooted. Here are the dmesg specifics for the controller and drive: atapci1: SiI 3112 SATA150 controller port 0x14b0-0x14bf,0x14c0-0x14c3,0x14c8-0x14cf,0x14c4-0x14c7,0x14d0-0x14d7 mem 0xe800a000-0xe800a1ff irq 9 at device 16.0 on pci0 GEOM: create disk ad4 dp=0xc5246460 ad4: 78167MB Maxtor 6Y080M0 [158816/16/63] at ata2-master UDMA133 Nothing else was changed in the machine except the specific version of -CURRENT since the time things worked and now. In addition to replacing the drive, I have replaced the SATA cable as well. My plan is to revert the ATA drivers to two weeks ago, and see if the problem persists. Failing that, I will test to see if this is a cooling problem. Failing that, I will replace the SATA controller. However, I wanted to know if I'm barking up the wrong tree, and perhaps this is a software issue. Thanks. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Sound stop'd working after upgrade ...
On Wed, 26 Nov 2003, Melvyn Sopacua wrote: On Wednesday 26 November 2003 01:24, Marc G. Fournier wrote: pcm0: Intel ICH4 (82801DB) port 0xe400-0xe43f,0xe000-0xe0ff mem 0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0 pcm0: Avance Logic ALC650 AC97 Codec and, from what I can tell, the proper devices are being built in /dev, but try and play music using xmms, and I get nothing ... Not sure what to debug, or where ... help? :( Does 'mixer' report anything valid? I had this over the weekend and can't remember how I cured it (I think I cvsupped at the time), but I know that mixer gave some error instead of proper stats. nope, looks fine: ganymede# mixer Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 88:88 Mixer line is currently set to 88:88 Mixer mic is currently set to 0:0 Mixer cd is currently set to 75:75 Mixer rec is currently set to 0:0 Mixer ogainis currently set to 50:50 Mixer line1is currently set to 75:75 Mixer phin is currently set to 0:0 Mixer phoutis currently set to 0:0 Mixer videois currently set to 75:75 Recording source: line is there some way of 'testing' it from the command line? I know you used to be able to cat a file to the device, but I think that was way back when it was one snd device instead of several ... I'm wondering if maybe the ich driver ... there was a problem introduced awhile back, that a cvsup and upgrade fixed ... just curious if maybe it got re-introduced, maybe ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound stop'd working after upgrade ...
On Wed, 26 Nov 2003, Melvyn Sopacua wrote: On Wednesday 26 November 2003 01:24, Marc G. Fournier wrote: pcm0: Intel ICH4 (82801DB) port 0xe400-0xe43f,0xe000-0xe0ff mem 0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0 pcm0: Avance Logic ALC650 AC97 Codec and, from what I can tell, the proper devices are being built in /dev, but try and play music using xmms, and I get nothing ... Not sure what to debug, or where ... help? :( Does 'mixer' report anything valid? I had this over the weekend and can't remember how I cured it (I think I cvsupped at the time), but I know that mixer gave some error instead of proper stats. nope, looks fine: ganymede# mixer Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 88:88 Mixer line is currently set to 88:88 Mixer mic is currently set to 0:0 Mixer cd is currently set to 75:75 Mixer rec is currently set to 0:0 Mixer ogainis currently set to 50:50 Mixer line1is currently set to 75:75 Mixer phin is currently set to 0:0 Mixer phoutis currently set to 0:0 Mixer videois currently set to 75:75 Recording source: line is there some way of 'testing' it from the command line? I know you used to be able to cat a file to the device, but I think that was way back when it was one snd device instead of several ... I'm wondering if maybe the ich driver ... there was a problem introduced awhile back, that a cvsup and upgrade fixed ... just curious if maybe it got re-introduced, maybe ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia problem fixed in current?
On Wednesday 26 November 2003 18:40, Justin Smith wrote: 1. Was the problem with the nvidia driver ever fixed? (I reported this more than a month ago --- the kernel nvidia driver only works with parameters set to lower the speed of the interface, and even then failed with some OpenGL programs like OpenUniverse). If you're talking about the nvidia driver (not the xfree86) then this isn't true in general. It's been working here without any tweaks fine since -current short after 5.1-release, also OpenUniverse is running without problems here. But the nvidia driver is still the same, you have to talk to nvidia to release a new one. 2. Can one upgrade to 5.2 beta by cvsupping to current and rebuilding world and kernel? Yes. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: signature
df: negative overflow?
Hi, cvs as of Sunday ~11:00am GMT. Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ad0s2a 484 70 374 16% / devfs 0 0 0 100% /dev /dev/md0 62 0 57 0% /tmp /dev/ad0s2d 4958 893 3668 20% /home /dev/ad0s2f 4958 3319 1241 73% /usr /dev/ad0s2g 16374 12841 15% /usr/local /dev/ad0s2e 989 946 36028797018963931 104% /var Filesystem Size Used Avail Capacity Mounted on /dev/ad0s2a 484M 71M 375M 16% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 63M 8.0K 58M 0% /tmp /dev/ad0s2d 4.8G 893M 3.6G 20% /home /dev/ad0s2f 4.8G 3.2G 1.2G 73% /usr /dev/ad0s2g 16G 2.2G 13G 15% /usr/local /dev/ad0s2e 989M 947M -36.4M 104% /var -- Melvyn pgp0.pgp Description: signature
Re: Recent ATA drivers giving problems with SATA
It seems Joe Marcus Clarke wrote:
atapci1: SiI 3112 SATA150 controller port
0x14b0-0x14bf,0x14c0-0x14c3,0x14c8-0x14cf,0x14c4-0x14c7,0x14d0-0x14d7
mem 0xe800a000-0xe800a1ff irq 9 at device 16.0 on pci0
GEOM: create disk ad4 dp=0xc5246460
ad4: 78167MB Maxtor 6Y080M0 [158816/16/63] at ata2-master UDMA133
Nothing else was changed in the machine except the specific version of
-CURRENT since the time things worked and now. In addition to replacing
the drive, I have replaced the SATA cable as well. My plan is to revert
the ATA drivers to two weeks ago, and see if the problem persists.
Failing that, I will test to see if this is a cooling problem. Failing
that, I will replace the SATA controller. However, I wanted to know if
I'm barking up the wrong tree, and perhaps this is a software issue.
There are some early issues of the SiI3112 chips that has problems that
can cause datacorruption etc etc..
You can try the following patch (which btw re@ has for approval),
otherwise I'd try another controller as there seem to be no end of the
troubles with the Sii 3112 chips (brings back to mind the horror times
from when they where called CMD and did the CMD640 disaster)...
Index: ata-all.h
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v
retrieving revision 1.67
diff -u -r1.67 ata-all.h
--- ata-all.h 11 Nov 2003 14:55:35 - 1.67
+++ ata-all.h 22 Nov 2003 20:53:40 -
@@ -246,6 +246,7 @@
struct ata_dmaentry*dmatab;/* DMA transfer table */
bus_addr_t mdmatab;/* bus address of dmatab */
u_int32_t alignment; /* DMA engine alignment */
+u_int32_t boundary; /* DMA engine boundary */
u_int32_t max_iosize; /* DMA engine max IO size */
u_int32_t cur_iosize; /* DMA engine current IO size */
intflags;
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.47
diff -u -r1.47 ata-chipset.c
--- ata-chipset.c 21 Nov 2003 22:58:56 - 1.47
+++ ata-chipset.c 22 Nov 2003 20:50:42 -
@@ -1576,8 +1576,10 @@
struct ata_pci_controller *ctlr = device_get_softc(dev);
struct ata_chip_id *idx;
static struct ata_chip_id ids[] =
-{{ ATA_SII3112, 0x00, SIIMEMIO, 0,ATA_SA150, SiI 3112 },
- { ATA_SII3112_1, 0x00, SIIMEMIO, 0,ATA_SA150, SiI 3112 },
+{{ ATA_SII3112, 0x02, SIIMEMIO, 0,ATA_SA150, SiI 3112 },
+ { ATA_SII3112_1, 0x02, SIIMEMIO, 0,ATA_SA150, SiI 3112 },
+ { ATA_SII3112, 0x00, SIIMEMIO, SIIBUG, ATA_SA150, SiI 3112 },
+ { ATA_SII3112_1, 0x00, SIIMEMIO, SIIBUG, ATA_SA150, SiI 3112 },
{ ATA_SII0680, 0x00, SIIMEMIO, SIISETCLK, ATA_UDMA6, SiI 0680 },
{ ATA_CMD649,0x00, 0, SIIINTR, ATA_UDMA5, CMD 649 },
{ ATA_CMD648,0x00, 0, SIIINTR, ATA_UDMA4, CMD 648 },
@@ -1684,6 +1686,8 @@
if (ctlr-chip-max_dma = ATA_SA150)
ch-flags |= ATA_NO_SLAVE;
ctlr-dmainit(ch);
+if (ctlr-chip-cfg2 SIIBUG)
+ ch-dma-boundary = 8 * 1024;
return 0;
}
Index: ata-dma.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v
retrieving revision 1.122
diff -u -r1.122 ata-dma.c
--- ata-dma.c 21 Oct 2003 19:20:37 - 1.122
+++ ata-dma.c 22 Nov 2003 20:51:07 -
@@ -74,7 +74,8 @@
ch-dma-load = ata_dmaload;
ch-dma-unload = ata_dmaunload;
ch-dma-alignment = 2;
- ch-dma-max_iosize = 64*1024;
+ ch-dma-max_iosize = 64 * 1024;
+ ch-dma-boundary = 64 * 1024;
}
}
@@ -106,9 +107,10 @@
BUS_DMA_ALLOCNOW, NULL, NULL, ch-dma-cdmatag))
goto error;
-if (bus_dma_tag_create(ch-dma-dmatag, ch-dma-alignment, 64*1024,
+if (bus_dma_tag_create(ch-dma-dmatag,ch-dma-alignment,ch-dma-boundary,
BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR,
- NULL, NULL, MAXPHYS, ATA_DMA_ENTRIES, MAXSEGSZ,
+ NULL, NULL, ch-dma-max_iosize,
+ ATA_DMA_ENTRIES, ch-dma-boundary,
BUS_DMA_ALLOCNOW, NULL, NULL, ch-dma-ddmatag))
goto error;
Index: ata-pci.h
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-pci.h,v
retrieving revision 1.18
diff -u -r1.18 ata-pci.h
--- ata-pci.h 18 Nov 2003 15:27:28 - 1.18
+++ ata-pci.h 21 Nov 2003 23:06:24 -
@@ -255,6 +255,7 @@
#define SIIMEMIO 1
#define SIIINTR0x01
#define SIISETCLK 0x02
+#define SIIBUG 0x04
#define SIS_SOUTH 1
#define SISSATA2
-Søren
5.2-BETA: giving up on 4 buffers (ata)
Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... Regards, -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
David O'Brien wrote: ... lets agree that the FTP client will be the last thing added to /rescue that is outside the original charter. I sincerely hope it will be. Mostly because I have a large chunk of new code to contribute that's broken and sitting in pieces all over my hard disk at the moment. (Working out APIs for new libraries is not a simple task. sigh) I don't have a lot of time for FreeBSD hacking, and this thread has consumed a rather sizable percentage of it. If we're going to add an FTP client, lets pick the one with the best functionality for the job -- /usr/bin/ftp. I may not know the complete URL to the bits I need, and if so with fetch you're still screwed. On the other hand, /usr/bin/ftp also has drawbacks: It requires ncurses (one reason I am interested in dropping vi is to shed the ncurses library and the need for a termcap file), it's considerably larger than fetch, and it doesn't support HTTP. But you are right that if you need to get a file from somewhere, you probably don't already know the exact location of that file, and ftp's browsing ability would be very useful then. Harumph It's a very good suggestion; I'll have to get back to you on it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Dynamic slowdown -- sometimes, sometimes not
Gang: The problem with measuring the dynamic slowdown is that some of the overhead can be hidden by the kernel (e.g. prezeroing.) (Sorry for not directly replying -- my email filtering is wierd.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
IPv6 locking crash (recursion)
Has anyone else tried out the most basic IPv6 test: ndp -I iface and
then ping6 fe80::normal address without %iface extension? I was
greeted by recursion on a non-recursive lock. After some sleuthing,
I tried to determine what conditions could be tested for that would
indicate this must not call the nd6_is_addr_neighbor() call because
we're from a normal RTM_RESOLVE initializing a new route, and this
is the most correct thing I can come up with. It actually would do
something entirely different if recursion were allowed. Comments?
Index: nd6.c
===
RCS file: /u/FreeBSD-cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.37
diff -u -r1.37 nd6.c
--- nd6.c 8 Nov 2003 23:36:32 - 1.37
+++ nd6.c 26 Nov 2003 13:45:45 -
@@ -1095,7 +1095,8 @@
if (req == RTM_RESOLVE
(nd6_need_cache(ifp) == 0 || /* stf case */
-!nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp))) {
+ ((!(rt-rt_flags RTF_WASCLONED) || rt-rt_flags RTF_LLINFO)
+ !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp {
/*
* FreeBSD and BSD/OS often make a cloned host route based
* on a less-specific route (e.g. the default route).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
Date: Wed, 26 Nov 2003 19:37:45 +0100 From: Matthias Andree [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... This looks like a GEOM related issue, although I am not completely sure of this. I have observed the following: System dies leaving the file systems dirty. (File systems have soft-updates enabled.) I reboot to single user and fsck all partitions including the root. I halt or reboot. I get a number of dirty buffers and the syncer eventually gives up. If I issue a mount -u / before shutting down, the problem does not occur. Why I should be able to get dirty buffers on a file system that has never been mounted as RW, I don't understand, but I see it every time I reboot after a crash. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: df: negative overflow?
* Melvyn Sopacua [EMAIL PROTECTED] [031126 13:23]: /dev/ad0s2e ? 989M ? 947M -36.4M ? 104% ? ?/var This is normal. Each filesystem has a chunk of reserved space for root-only, for disaster recovery and such. Your /var filesystem is full, and has begun overflowing into that reserved space by 36.4MB. Essentially, there is no free space left in the file system, and you must get rid of 36.4MB of data before you can begin to get any free space. --Mike pgp0.pgp Description: PGP signature
Re: 5.2-BETA: giving up on 4 buffers (ata)
Matthias Andree wrote:
when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on
flushing 4 dirty blocks.
This is easy to reproduce, but apparently uninteresting to the developers:
Reboot to single user, run full fsck, halt.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
please test pcm patch
Hello All,
Please test a pcm patch that releases the channel lock around
calls to uio move. This is a more complete patch than the previous
one as it also does the _read routine. I will ask the RE to commit
this if I hear a couple of it works.
Pointed out by: Artur Poplawski
Explained by: Don Lewis
--Mat
--
sig machine broken
--- channel.c Sun Nov 9 04:17:22 2003
+++ /sys/dev/sound/pcm/channel.cWed Nov 26 13:50:20 2003
@@ -250,6 +250,8 @@
{
int ret, timeout, newsize, count, sz;
struct snd_dbuf *bs = c-bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
/*
@@ -291,7 +293,22 @@
sz = MIN(sz, buf-uio_resid);
KASSERT(sz 0, (confusion in chn_write));
/* printf(sz: %d\n, sz); */
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 togo 0) {
+ p = sndbuf_getfreeptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_acquire(bs, NULL, t);
+ }
+ ret = 0;
+#endif
if (ret == 0 !(c-flags CHN_F_TRIGGERED))
chn_start(c, 0);
}
@@ -395,6 +412,8 @@
{
int ret, timeout, sz, count;
struct snd_dbuf *bs = c-bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
if (!(c-flags CHN_F_TRIGGERED))
@@ -406,7 +425,22 @@
sz = MIN(buf-uio_resid, sndbuf_getready(bs));
if (sz 0) {
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 togo 0) {
+ p = sndbuf_getreadyptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_dispose(bs, NULL, t);
+ }
+ ret = 0;
+#endif
} else {
if (c-flags CHN_F_NBIO) {
ret = EWOULDBLOCK;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
In message [EMAIL PROTECTED], Kevin Oberman writes: Date: Wed, 26 Nov 2003 19:37:45 +0100 From: Matthias Andree [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... This looks like a GEOM related issue, although I am not completely sure of this. Why do you think it has anything to do with GEOM ? When we give up on buffers, then superblocks are likely victims, in particular when softupdates dependencies are involved. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
Kevin Oberman [EMAIL PROTECTED] writes: Date: Wed, 26 Nov 2003 19:37:45 +0100 From: Matthias Andree [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... This looks like a GEOM related issue, although I am not completely sure of this. I have observed the following: System dies leaving the file systems dirty. (File systems have soft-updates enabled.) I reboot to single user and fsck all partitions including the root. I halt or reboot. I get a number of dirty buffers and the syncer eventually gives up. If I issue a mount -u / before shutting down, the problem does not occur. Why I should be able to get dirty buffers on a file system that has never been mounted as RW, I don't understand, but I see it every time I reboot after a crash. It happened to me many times on various machines. Some running 4.x, so no GEOM. I wonder why all the file systems are marked dirty. The buffers are associated with specific device anyway. /S ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: df: negative overflow?
On Wednesday 26 November 2003 19:52, Michael Edenfield wrote: * Melvyn Sopacua [EMAIL PROTECTED] [031126 13:23]: /dev/ad0s2e ? 989M ? 947M -36.4M ? 104% ? ?/var This is normal. Each filesystem has a chunk of reserved space for root-only, Yes, sorry I wasn't too clear (I thought the bug would stand out). But here's the really important line: /dev/ad0s2e 989 946 36028797018963931 104% /var ^ Looks like an integer overflow of some kind. --Mike -- Melvyn pgp0.pgp Description: signature
Re: 5.2-BETA: giving up on 4 buffers (ata)
In a message written on Thu, Nov 27, 2003 at 04:52:04AM +1000, Andy Farkas wrote: Matthias Andree wrote: when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. This is easy to reproduce, but apparently uninteresting to the developers: Reboot to single user, run full fsck, halt. I'll also note in my FreeBSD current debugging of some drivers it was about a 50/50 shot as to if this would happen. Having to fsck every other reboot was only made less painful by the background fsck thing. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
acpi_cpu changes complete
I believe this completes the changes to acpi_cpu for 5.2. Please test on SMP boxes and laptops and if you were disabling it before, please re-enable it to test. (To do that, remove debug.acpi.disable from loader.conf). Thanks, Nate -- Forwarded message -- Date: Wed, 26 Nov 2003 11:02:07 -0800 (PST) From: Nate Lawson [EMAIL PROTECTED] Modified files: sys/dev/acpica acpi_cpu.c sys/modules/acpi Makefile Log: * Add acpi_pcpu_get_id(idx, *acpi_id, *cpu_id) which fetches the idx'th present CPU with pc_acpi_id equal to *acpi_id. If *acpi_id does not match that processor's pc_acpi_id, return the value for ProcId derived from the MADT in *acpi_id. If pc_acpi_id is 0x, always override it with the value of *acpi_id. Finally, return pc_cpuid in *cpu_id and use that as our primary key. * Use pc_cpuid as our unique key because we know it is valid since MD code set it. The values for ProcId in the ASL and MADT don't match up on some machines (!), forcing us to fall back to ordered probing in that case. * Remove some #ifdef SMP since the refcount doesn't hurt performance and will be needed for dynamic _CST objects. Only one #ifdef SMP (for smp_rendezvous) remains. * Hook up SMP in the compile flags in the Makefile. Tested by: marcel, truckman Approved by:re (scottl) Revision ChangesPath 1.21 +48 -49src/sys/dev/acpica/acpi_cpu.c 1.33 +5 -2 src/sys/modules/acpi/Makefile ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic with ugen
Hi,
I'm still trying to write a webcam application for my
Creative Videoblaster Webcam Go. I have not much luck, but
I accidently discovered how to cause panic with few lines
of code while using ugen.
Here is the code:
--
#include stdio.h
#include stdlib.h
#include unistd.h
#include fcntl.h
#include dev/usb/usb.h
#include sys/ioctl.h
#include sys/param.h
#define DEVNAME /dev/ugen0
static char dev_name[MAXPATHLEN];
int main(int argc, char *argv[]) {
int fdout;
int i;
sprintf(dev_name,%s,DEVNAME);
fdout=open(dev_name, O_RDWR, 0);
if (fdout0) {
perror(open);
fprintf(stderr, Cannot open device: %s\n,DEVNAME);
exit(-1);
}
i=0;
/* PANIC here in ioctl (during second run) */
if(ioctl(fdout, USB_SET_CONFIG, i) 0) {
perror(ioctl(USB_SET_CONFIG));
exit(-1);
}
close(fdout);
return 0;
}
--
Run it once, you'll get an error. The second run
will cause a panic.
Additional info:
5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Nov 18 00:30:15 CET 2003 i386
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
ugen0: WINBOND W9967CF, rev 1.10/1.10, addr 3
Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent ATA drivers giving problems with SATA
On Wed, 2003-11-26 at 13:28, Soren Schmidt wrote: It seems Joe Marcus Clarke wrote: atapci1: SiI 3112 SATA150 controller port 0x14b0-0x14bf,0x14c0-0x14c3,0x14c8-0x14cf,0x14c4-0x14c7,0x14d0-0x14d7 mem 0xe800a000-0xe800a1ff irq 9 at device 16.0 on pci0 GEOM: create disk ad4 dp=0xc5246460 ad4: 78167MB Maxtor 6Y080M0 [158816/16/63] at ata2-master UDMA133 Nothing else was changed in the machine except the specific version of -CURRENT since the time things worked and now. In addition to replacing the drive, I have replaced the SATA cable as well. My plan is to revert the ATA drivers to two weeks ago, and see if the problem persists. Failing that, I will test to see if this is a cooling problem. Failing that, I will replace the SATA controller. However, I wanted to know if I'm barking up the wrong tree, and perhaps this is a software issue. There are some early issues of the SiI3112 chips that has problems that can cause datacorruption etc etc.. You can try the following patch (which btw re@ has for approval), otherwise I'd try another controller as there seem to be no end of the troubles with the Sii 3112 chips (brings back to mind the horror times from when they where called CMD and did the CMD640 disaster)... Thanks, but this patch immediately causes an Input/Output error trying to do a large rm. A few seconds later, and the machine is locked up (probably spewing the same DMA timeouts, but I won't be able to check until I get back home). Joe [ATA patch elided] -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: panic: NULL softc for 0
This should be completely resolved by the commit I just made. Please test. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Wednesday 26 November 2003 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... Same here, since about 2 weeks. I thought it was just my machine :). Best regards, Arjan pgp0.pgp Description: signature
RE: 4 - 5 Problem
I'm still getting this with fresh sources. Has anyone else done 4-5 in the last few days? Is it worth filing a PR? Lawrence Farr EPC Direct Limited -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Farr Sent: 25 November 2003 16:27 To: 'Clement Laforet' Cc: [EMAIL PROTECTED] Subject: RE: 4 - 5 Problem Err yes I did. Im trying to install a kernel. Lawrence Farr EPC Direct Limited -Original Message- From: Clement Laforet [mailto:[EMAIL PROTECTED] Sent: 25 November 2003 16:26 To: Lawrence Farr Cc: [EMAIL PROTECTED] Subject: Re: 4 - 5 Problem On Tue, 25 Nov 2003 16:18:26 - Lawrence Farr [EMAIL PROTECTED] wrote: the Current target machine is from Thu Sep 25 14:32:19 GMT 2003, the stable one from Mon Mar 24 16:30:45 GMT 2003, and the src and obj are fresh from last night. did you read /usr/src/UPDATING ? 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. clem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: please test pcm patch
On Wednesday 26 November 2003 19:54, Mathew Kanner wrote: Hello All, Please test a pcm patch that releases the channel lock around calls to uio move. This is a more complete patch than the previous one as it also does the _read routine. I will ask the RE to commit this if I hear a couple of it works. it works But I haven't had any problems before (besides some replay delay, thus asynch audio/video) Here is what dmesg prints: pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: Analog Devices AD1885 AC97 Codec pcm0: measured ac97 link rate at 55934 Hz Thanks, -Harry Pointed out by: Artur Poplawski Explained by: Don Lewis --Mat pgp0.pgp Description: signature
Re: recent current panic
On Wednesday 26 November 2003 04:00 am,wrote: i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c0898daf,0,c087197f,d629d8dc,100) at Debugger+0x55 panic(c087197f,c0854d72,c168bd00,c095c9e0,d629d9fc) at panic+0x156 if_simloop(c2cace00,c168bd00,2,0,1) at if_simloop+0xc5 looutput(c2cace00,c168bd00,c2c86290,c2f31400,14b) at looutput+0xde ip_output(c168bd00,0,0,0,0) at ip_output+0xce1 tcp_output(c2f53000,c1687800,c08a4a60,29e,0) at tcp_output+0xcd0 tcp_usr_send(c2f23000,0,c1687800,0,0) at tcp_usr_send+0x1bd sosend(c2f23000,0,d629dc80,c1687800,0) at sosend+0x44d soo_write(c2dafd48,d629dc80,c310f280,0,c2caedc0) at soo_write+0x70 dofilewrite(c2caedc0,c2dafd48,0,805e640,2b) at dofilewrite+0xfb write(c2caedc0,d629dd14,c08b7a15,3ee,3) at write+0x6e syscall(2f,2f,2f,805f1a7,) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282c50af, esp = 0xbfbfe9ec, ebp = 0xbfbfea08 --- Thanks, I've got a fix for this. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
Martin wrote: Run it once, you'll get an error. The second run will cause a panic. Additional info: 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Nov 18 00:30:15 CET 2003 i386 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 ugen0: WINBOND W9967CF, rev 1.10/1.10, addr 3 This sounds similar to a bug which (I thought) I fixed earlier in the year [multiple calls of USB_SET_CONFIG conflicted with devfs, fixed in sys/dev/ugen.c rev 1.71]. I have a modem attached to the USB connector at the moment, so it's a bit tricky to test. Can you (or someone) provide a backtrace to help trace the cause? (and is the panic don't do that, perchance?) -- Cheers, Jay http://www.evilrealms.net/ - Systems Administrator Developer http://www.imperial.ac.uk/ - 3rd year CS student ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent ATA drivers giving problems with SATA
On Wed, 2003-11-26 at 13:28, Soren Schmidt wrote: It seems Joe Marcus Clarke wrote: atapci1: SiI 3112 SATA150 controller port 0x14b0-0x14bf,0x14c0-0x14c3,0x14c8-0x14cf,0x14c4-0x14c7,0x14d0-0x14d7 mem 0xe800a000-0xe800a1ff irq 9 at device 16.0 on pci0 GEOM: create disk ad4 dp=0xc5246460 ad4: 78167MB Maxtor 6Y080M0 [158816/16/63] at ata2-master UDMA133 Nothing else was changed in the machine except the specific version of -CURRENT since the time things worked and now. In addition to replacing the drive, I have replaced the SATA cable as well. My plan is to revert the ATA drivers to two weeks ago, and see if the problem persists. Failing that, I will test to see if this is a cooling problem. Failing that, I will replace the SATA controller. However, I wanted to know if I'm barking up the wrong tree, and perhaps this is a software issue. There are some early issues of the SiI3112 chips that has problems that can cause datacorruption etc etc.. You can try the following patch (which btw re@ has for approval), otherwise I'd try another controller as there seem to be no end of the troubles with the Sii 3112 chips (brings back to mind the horror times from when they where called CMD and did the CMD640 disaster)... On the other controller front, what about the Adaptec 1205SA host controller? Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: 40% slowdown with dynamic /bin/sh
:At 00:23 26/11/2003 -0500, Michael Edenfield wrote: :Static /bin/sh: : real385m29.977s : user111m58.508s : sys 93m14.450s : :Dynamic /bin/sh: : real455m44.852s : user113m17.807s : sys 103m16.509s : : Given that user+sys real in both cases, it looks like you're running :out of memory; it's not surprising that dynamic linking has an increased :cost in such circumstances, since reading the diverse files into memory :will take longer than reading a single static binary. : I doubt many systems will experience this sort of performance delta. : :Colin Percival It definitely looks memory related but the system isn't necessarily 'running out' of memory. It could simply be that the less memory available for caching files is causing more disk I/O to occur. It should be possible to quanity this by doing a full timing of the build ( /usr/bin/time -l ), which theoretically includes I/O ops. Dynamically linked code definitely dirties more anonymous memory then static, and definitely accesses more shared file pages. The difference is going to depend on the complexity of the program. How much this effects system peformance depends on the situation. If the system has significant idle cycles available the impact should not be too serious, but if it doesn't then the overhead will drag down the pre-zerod pages (even if the program is exec'd, does something real quick, and exits). I have included a program below that prints the delta free page count and the delta zero-fill count once a second. This can be used to estimate anonymous memory use. Run the program and let it stabilize. Be sure that the system is idle. Then run the target program (it needs to stick around, it can't just exec and exit), then exit the target program and repeat. Leave several seconds in between invocation, exit, and repeat to allow the system to stabilize. Note that it may take several runs to get reliable information since the program is measuring anonymous memory use for the whole system. Also note that shared pages will not be measured by this program, only the number of dirtied anonymous pages. If on an idle system the program is not reporting '0 0' then your system isn't idle :-). The main indicator is the 'freepg' negative jump when the target program is invoked. The zfod count will be a subset of that, indicating the number of zero-fill pages requested (verses program text/data COW pages which do not need zero'd pages but still eat anonymous memory for the duration of the target program). When I tested it with a static and dynamic /bin/sh on 4.8 I got (looking at 'freepg'), 20 pages for the static binary and 50 pages for the dynamic binary. So a dynamic /bin/sh eats 30 * 4K = 120K more anonymous memory then a static /bin/sh. In the same test I got 12 ZFOD faults for the static binary and 34 ZFOD faults for the dynamic binary, which means that 22 additional pre-zero'd pages are being allocated in the dynamic case (88KB). If /bin/sh is exec'd a lot in a situation where the system is otherwise not idle, this will impact the number of pre-zero'd pages available on the system. Each exec of a dyanmic /bin/sh eats 22 additional pages (88K) worth of zero-fill. Each resident copy of (exec'd) /bin/sh eats 120KB more dirty anonymous memory. make buildworld -j 1 may have as many as a dozen /bin/sh's exec'd at any given moment (impact 120K each) depending on where in the build it is. -j 2 and so forth will have even more. This will impact your system relative to the amount of total system memory you have. The more system memory you have, the less the percentage impact. /bin/sh /bin/csh -- --- static freepg -19 zfod 12 freepg -140 zfod 129 dynamic freepg -50 zfod 34 freepg -167 zfod 149 /usr/bin/make (note that make is static by default) -- static freepg -33 zfod 27 dynamic freepg -51 zfod 44 As you can see, the issue becomes less significant on a percentage basis with larger programs that already allocate more incidental memory. Also to my surprise I found that 'make' was already static. It would seem that this issue was recognized long ago. bzip2, chflags, make, and objformat are compiled statically even though they reside in /usr/bin. -Matt /* * print delta free pages and zfod requests once a second. Leave running * while testing other programs. Note: ozfod is not displayed. ozfod is * a subset of zfod, just as zfod deltas are a subset of v_free_count * allocations. */ #include sys/types.h #include sys/sysctl.h #include stdio.h #include
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : time make -j 4 buildworld Hmmm, more jobs. : They were on a single CPU Athlon 500 with 320MB of RAM. 320MB is not enough RAM not to swap. I did some preliminary testing last night (which I lost due to a crash) that showed that a simple 'make buildworld' slowed down 1-2% depending on how many times I ran them. However, make -s buildworld (with or without -j 4 on my dual athlon) was faster than a normal buildworld, but the dynamic /bin/sh was more like 5-7% slower. The difference here is that there are fewer context switches (and I guess less chance for parallelization). In all make buildworld, the number of page faults was 10x for the dynamic case than for the static case. However, having said that, I think everybody realizes the following: 1) Dynamic linking is slower. 2) Speed improvements in this area are possible, as demonstrated by other projects. 3) PIC code is slower than non-PIC code, in general, and also gcc runs about 5-10% slower depending on if you are running out of a shared library or a static one. shared libraries must use PIC code (at this time). 4) People like to complain. Warner P.S. One interesting note: /bin/sh when linked statically with libedit and libncurses but dynamically with libc runs about 10% slower for my /usr/bin/true/true tests than when all three are dynamically linked. So it seems that not all dynamic linking is bad for performance. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Announcing 5.2-BETA
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : Please help us make 5.2 the best FreeBSD release ever! Well Done! Thanks for all your (both personally and the whole re@ team) efforts in making this happen! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hanging at boot
On Mon, 24 Nov 2003 08:00:49 +0100, Manfred Lotz wrote: Hi there, Last time (around middle of October) when I tried out a new current kernel it was hanging at boot time at acd1 ata1 is: acd1: DVD-ROM TOSHIBA DVD-ROM SD-M1612 at ata1-slave UDMA33 I tried it again yesterday. Now acd1 seems to be fine. However it hangs at acd2.After the following message acd2: CD-RW MITSUMI DW-7801TE at ata3-master UDMA33 it stops working. No error message is showing up. In the meantime I found out that the cause of the problem is atapicam. If I remove it from my kernel config I'm fine (but I have no atapicam). Manfred ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
: That seems to have the most impact. We can also expend our efforts : to improve dynamic linking performance, since that will improve the : performance of the other 99.9% of the universe. : : :What happened to mdodd's prebinding efforts? : :Drew Prebinding was put into DFly but the improvement is barely noticeable when you prebind /bin/sh. Prebinding is only really useful for much larger programs like mozilla which have thousands or tens of thousands of bindings. These numbers are on DragonFly and will be different on FBsd, but the relative numbers should be similar with a FBsd prebinding implementation. /bin/sh -- static freepg -16 zfod 12 dynamic freepg -46 zfod 34 dyn/prebind freepg -46 zfod 26 saves 8*4=32KB worth of pre-zero'd pages but does not save any anon memory. 1000 runs of /bin/sh -c exit 0 (program to vfork/exec /bin/sh -c exit 0 1000 times). This effectively measures startup overhead only and is not inclusive of what a script might do in addition to starting up. /bin/sh static 11023 zfod's00.54s dynamic 33023 zfod's02.88s dyn/prebind 25023 zfod's02.36s There isn't much of a time improvement but there is a significant improvement in the number of ZFOD's with prebinding. leaf:/usr/obj/usr/src/bin/sh# prebind /usr/obj/usr/src/bin/sh/sh object /usr/obj/usr/src/bin/sh/sh uniqid 986137809 object /usr/lib/libedit.so.3 uniqid -1757875926 object /usr/lib/libncurses.so.5 uniqid 1023436343 object /usr/lib/libc.so.4 uniqid 2011683737 Non-PLT Prebindings: object /usr/lib/libedit.so.3 count 5 object /usr/lib/libncurses.so.5 count 63 object /usr/lib/libc.so.4 count 203 PLT Prebindings: object /usr/obj/usr/src/bin/sh/sh count 106 object /usr/lib/libedit.so.3 count 63 object /usr/lib/libncurses.so.5 count 270 object /usr/lib/libc.so.4 count 638 Non-PLT COPY Prebindings: object /usr/obj/usr/src/bin/sh/sh count 13 -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound stop'd working after upgrade ...
On Wednesday 26 November 2003 19:14, Marc G. Fournier wrote: On Wed, 26 Nov 2003, Melvyn Sopacua wrote: On Wednesday 26 November 2003 01:24, Marc G. Fournier wrote: pcm0: Intel ICH4 (82801DB) port 0xe400-0xe43f,0xe000-0xe0ff mem 0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0 pcm0: Avance Logic ALC650 AC97 Codec and, from what I can tell, the proper devices are being built in /dev, but try and play music using xmms, and I get nothing ... Not sure what to debug, or where ... help? :( Does 'mixer' report anything valid? I had this over the weekend and can't remember how I cured it (I think I cvsupped at the time), but I know that mixer gave some error instead of proper stats. nope, looks fine: [ ... ] is there some way of 'testing' it from the command line? I know you used to be able to cat a file to the device, but I think that was way back when it was one snd device instead of several ... * XMMS via esd and Arts running? * XMMS and null-output plugin? cdplay(1) and a cd is how I got onto the problem. portinstall ogg|mpg123 with an ogg/mp3 will also give you plenty of testing. There's wavplay also, but it needs proper wavheaders (ie: doesn't support raw wavs). -- Melvyn pgp0.pgp Description: signature
Re: Sound stop'd working after upgrade ...
On Wed, 26 Nov 2003, Melvyn Sopacua wrote: On Wednesday 26 November 2003 19:14, Marc G. Fournier wrote: On Wed, 26 Nov 2003, Melvyn Sopacua wrote: On Wednesday 26 November 2003 01:24, Marc G. Fournier wrote: pcm0: Intel ICH4 (82801DB) port 0xe400-0xe43f,0xe000-0xe0ff mem 0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0 pcm0: Avance Logic ALC650 AC97 Codec and, from what I can tell, the proper devices are being built in /dev, but try and play music using xmms, and I get nothing ... Not sure what to debug, or where ... help? :( Does 'mixer' report anything valid? I had this over the weekend and can't remember how I cured it (I think I cvsupped at the time), but I know that mixer gave some error instead of proper stats. nope, looks fine: [ ... ] is there some way of 'testing' it from the command line? I know you used to be able to cat a file to the device, but I think that was way back when it was one snd device instead of several ... * XMMS via esd and Arts running? * XMMS and null-output plugin? cdplay(1) and a cd is how I got onto the problem. portinstall ogg|mpg123 with an ogg/mp3 will also give you plenty of testing. There's wavplay also, but it needs proper wavheaders (ie: doesn't support raw wavs). I just disabled ACPI in my BIOs, and all works once more ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Fri, 21 Nov 2003, Lukas Ertl wrote: On Fri, 21 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. Now I've tried running make buildkernel and tarring /usr/src to a different location, with different setting for hw.acpi.cpu.cx_lowest. I couldn't see any real difference - neither in performance nor in heat emission. Well, heat emission will be high during benchmarks because the CPU is rarely idle. My fan always comes on my laptop during buildworld. But the difference is when it's mostly idle (checking email, web browsing). With machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting there. With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the box is still warm. With cx_lowest=2 (C3, 120 us transition time), the box is very cool but some IO gets a little slower (serial port). But not much. The problem is that the fan in this machine always kicks in after several minutes, and then stays on. This is very annoying. If you're testing C3 states, you have to disable USB in your kernel config. (I just load USB as modules since performance is not an issue and I like to use C3 while on the road to get max power savings). It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal BTW, I'm having another ACPI question, do these figures here make sense? hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._CRT: 3662 They are valid, yes. If I understood the ACPI spec correctly, _PSV is the temperature where passive cooling actions begin, and _CRT is the critical temp, where the OS should initiate a shutdown. First, _PSV seems to be way to high, and second, they are so close to each other. You are correct. _PSV is not currently implemented by FreeBSD but I hope to do it at some point. Once we have all methods of processor control (cpufreq, Cx, and throttling), we can use them to implement _PSV. In any case, I think the _PSV value is set high because your platform designer expects active cooling to be the most effective and passive, since it slows down performance, is a last resort. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent ATA drivers giving problems with SATA
It seems Joe Marcus Clarke wrote: There are some early issues of the SiI3112 chips that has problems that can cause datacorruption etc etc.. You can try the following patch (which btw re@ has for approval), otherwise I'd try another controller as there seem to be no end of the troubles with the Sii 3112 chips (brings back to mind the horror times from when they where called CMD and did the CMD640 disaster)... On the other controller front, what about the Adaptec 1205SA host controller? I dont know that one, and Adaptec say nothing about what hardware they use on thier web (why does that have to be a secret until you have bought the product, or is that exaclty why ?). I suspect it is the same as the 1210SA RAID thing just without the RAID part of the BIOS, ie thats also a ds3112 chip (with Adaptecs special PCI id, *sigh*).. Go for Promise, they support us with docs and HW for development :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh [EMAIL PROTECTED] [031126 14:51]: In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : They were on a single CPU Athlon 500 with 320MB of RAM. 320MB is not enough RAM not to swap. However, having said that, I think everybody realizes the following: 1) Dynamic linking is slower. 2) Speed improvements in this area are possible, as demonstrated by other projects. 3) PIC code is slower than non-PIC code, in general, and also gcc runs about 5-10% slower depending on if you are running out of a shared library or a static one. shared libraries must use PIC code (at this time). 4) People like to complain. Just for the record, I've been running WITH_DYNAMICROOT since nearly the day it came out and don't *notice* any problems. Mostly because the noise of dynamic linking overhead gets lost in the noise of my hardware sucks so bad I have to take a vacation during buildworlds. My startup takes upwards of 5 minutes anyway, another 45 seconds won't even make me blink. I'm certainly not complaining about the performance :) I only posted those numbers to: 1) Give real world numbers, not interesting but unrealistic numbers 2) Show that even worst-case numbers weren't on the level of 40% slowdown. 3) Hopefully help someone figure out where to best improve the dynamic linker. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
On Wed, 26 Nov 2003, Terry Lambert wrote: I don't know what Matt is planning on delivering, but... http://developer.apple.com/darwin/projects/opendirectory/ [...] lookupd is included with the Darwin project and is documented online in Apple's Support database and as part of Mac OS X and Darwin in the form of man pages. [...] Hmm. Are you offering to port Mach IPC to FreeBSD as well? :-) FreeBSD has also been offered, at least three times, similar proxy code from two universities, under BSD license. Can't speak to that, not having seen it. Got some pointers? I'm fine with the notion of using IPC-based directory services, but it's not simply a question of finding a tarball and committing it. There's no lack of standards, APIs, etc, to pick from. Since you're pointing at an Apple solution, it's worth pointing out that Apple has also been in flux on the topic of directory service APIs over the last two years, trying to move away from NetInfo and towards DirectoryServices. One of the things we're still trying to address for FreeBSD is how to fit into a world of distributed directory services where, until the last year or so, it's really been unclear what the most interoperable and easiest to manage solution would be. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ISO IMAGES
Will ISO images be released for 5.2-BETA i386? Or is that strictly an -RC thing? Thanks. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
MD Date: Tue, 25 Nov 2003 11:50:25 -0800 (PST) MD From: Matthew Dillon MD (B) the authentication code access an IPC service which *ONLY* allows MD challenge/response, does *NOT* give you direct access to the MD encrypted contents of the password file, and which limits the challenge MD rate to prevent dictionary attacks? Sounds kind of like SASL... Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ISO IMAGES
The availability of ISO images was announced to this mailing list this morning. Please check your local mirror; i386, alpha, and amd64 should be available on most mirrors now. Scott On Wed, 26 Nov 2003, Jesse Guardiani wrote: Will ISO images be released for 5.2-BETA i386? Or is that strictly an -RC thing? Thanks. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)
Is my expectation wrong or is there a pertinent IPFW2 bug in a current 5.2-BETA kernel? You're alone in this, though cjc hasn't been able to reproduce this. ^^^ not Are you on a multi-homed system? -sc Ack! If ever there was a missing word to change the meaning of an email! What I meant to say was you're *not* alone in this... I'm having this problem on my firewall/nat box but not my laptop. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ISO IMAGES
Hi. Will ISO images be released for 5.2-BETA i386? Or is that strictly an -RC thing? Ftp'ed to ftp.freebsd.org using a freebsd-ftp-client but couldn't find the ISO-image for 5.2 beta. Using OS X's finder found the folder and files. Peculiar. Permissions? regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ISO IMAGES
On 2003.11.26 22:53:26 +0100, Claus Guttesen wrote: Hi. Will ISO images be released for 5.2-BETA i386? Or is that strictly an -RC thing? Ftp'ed to ftp.freebsd.org using a freebsd-ftp-client but couldn't find the ISO-image for 5.2 beta. Using OS X's finder found the folder and files. Peculiar. Permissions? No, ftp.freebsd.org is actually two servers. At the moment one of them has the images, not the other: [EMAIL PROTECTED]:ISO] host ftp.freebsd.org ftp.freebsd.org has address 62.243.72.50 ftp.freebsd.org has address 204.152.184.73 ftp.freebsd.org has address 2001:4f8:0:2::e [EMAIL PROTECTED]:ISO] ncftpls ftp://62.243.72.50/pub/FreeBSD/ISO-IMAGES-i386/5.2/ ncftpls: Could not change directory: server said: No such directory. [EMAIL PROTECTED]:ISO] ncftpls ftp://204.152.184.73/pub/FreeBSD/ISO-IMAGES-i386/5.2/ 5.2-BETA-i386-disc2.iso 5.2-BETA-i386-miniinst.iso CHECKSUM.MD5 [EMAIL PROTECTED]:ISO] BTW, ftp.se.freebsd.org also has them, which is probably closer to you :-). -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Nate Lawson wrote: It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least no 'standard' one - anyone knows what hides behind this HKEY device every ThinkPad seems to have?) You are correct. _PSV is not currently implemented by FreeBSD but I hope to do it at some point. Once we have all methods of processor control (cpufreq, Cx, and throttling), we can use them to implement _PSV. In any case, I think the _PSV value is set high because your platform designer expects active cooling to be the most effective and passive, since it slows down performance, is a last resort. Ah, sounds reasonable, thanks for the explaination. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Lukas Ertl wrote: On Wed, 26 Nov 2003, Nate Lawson wrote: It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least no 'standard' one - anyone knows what hides behind this HKEY device every ThinkPad seems to have?) It's not called FAN. It is a device with a certain PNP id and controlled by a power resource. I need the output of sysctl hw.acpi.thermal to see your _ACx values. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Nate Lawson wrote: On Wed, 26 Nov 2003, Lukas Ertl wrote: On Wed, 26 Nov 2003, Nate Lawson wrote: It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least no 'standard' one - anyone knows what hides behind this HKEY device every ThinkPad seems to have?) It's not called FAN. It is a device with a certain PNP id and controlled by a power resource. That's what I meant, actually. I need the output of sysctl hw.acpi.thermal to see your _ACx values. hw.acpi.thermal.tz0.temperature: 3072 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3662 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
zone(9) is broken on SMP?!
If I build attached kmod and kldload/-unload it on a GENERIC kernel w/ SMP apic it'll error out: Zone was not empty (xx items). Lost X pages of memory. w/o SMP apic the problem disappears. This is on a p4 HTT, but seems reproducible on proper SMP systems as well. UP systems don't show it however. Can somebody please try and report? Thanks! -- Best regards, Max mailto:[EMAIL PROTECTED] Makefile. Description: Binary data uma_test.c Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: requesting vinum help
On Wednesday, 26 November 2003 at 12:04:52 -0600, Cosmin Stroe wrote: I am using vinum atm, and I am having serious problems with it. After about 16 hrs of writing data to a vinum volume via NFS at a constant data stream of 200k/sec and reading at 400k/sec at the same time, the whole machine just freezes, hard. The only thing I can do is reboot. This behavior appears in 4.8 and 5-CURRENT. I have no indication of what is wrong, or how to go about finding it out. The problem is either with NFS or Vinum, and I'm leaning towards Vinum (because of the failure in both -STABLE and -CURRENT). I'm not the kind of person that relies on other people, and I like to fix my own problems, but this is a problem which I cannot fix at this time. So, I'm planning to look through the code of vinum and start messing with it to figure out how it works and how to debug it. This is unlikely to get you very far. Some more details (offline if you prefer) would be handy, but as you say, you can't even be sure that it's Vinum. The best thing would be to get the system into the kernel debugger at the point of freeze, if that's possible, and try to work out what has happened. What would also be appreciated is an overall map of how vinum is organized and how it works. You've read the documentation on http://www.vinumvm.org/, right? If you have any questions, I'm sure it can be improved on. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)
On Wednesday 26 November 2003 01:40 pm, Sean Chittenden wrote: Is my expectation wrong or is there a pertinent IPFW2 bug in a current 5.2-BETA kernel? You're alone in this, though cjc hasn't been able to reproduce this. ^^^ not Are you on a multi-homed system? -sc Ack! If ever there was a missing word to change the meaning of an email! What I meant to say was you're *not* alone in this... I'm having this problem on my firewall/nat box but not my laptop. -sc We've got a fix coming. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
On Wed, 2003-11-26 at 20:44, Jay Cornwall wrote: Can you (or someone) provide a backtrace to help trace the cause? OK. Here is what I found out, I didn't write down any register contents and stuff, sorry. It looks like this: WARNING: Driver mistake: destroy_dev on 114/1 panic: don't do that db trace Debugger() panic() destroy_dev() ugen_destroy_devnodes() ugen_set_config() ugen_do_ioctl() ugenioctl() spec_ioctl() spec_vnoperate() vn_ioctl() ioctl() syscall() Xint0x80_syscall() This was the latest kernel: 5.2-BETA FreeBSD 5.2-BETA #0: Wed Nov 26 22:24:43 CET 2003 i386 Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: zone(9) is broken on SMP?!
Max Laier wrote: If I build attached kmod and kldload/-unload it on a GENERIC kernel w/ SMP apic it'll error out: Zone was not empty (xx items). Lost X pages of memory. This is on a p4 HTT, but seems reproducible on proper SMP systems as well. UP systems don't show it however. Can somebody please try and report? Thanks! Yes this is reproducible on a real SMP system: bender kernel: Zone UMA test zone was not empty (65 items). Lost 1 pages of memory. Regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
Martin wrote: It looks like this: panic() destroy_dev() ugen_destroy_devnodes() ugen_set_config() Yes, that's the one, and I think I can see why. The existing code fixed devfs problems for normal ugen_set_config calls, but doesn't account for what happens when an error occurs (which is presumably happening in your example program, as you said it gives an error the first time round) - the devfs stuff only half completes. (actually, looking at that error handling code, it doesn't look like it's been thought through well anyway - /* XXX should only do this after setting new altno has succeeded */ - maybe time to clean this code up?) After the device endpoints are destroyed (sys/dev/ugen.c:1038), the returns on lines 1055 and 1058 need to be covered by a devnode recovery procedure - particularly tricky given we just wiped the endpoint descriptors clean. I'll look at restructuring this code tomorrow, if Bernd doesn't beat me to it. -- Cheers, Jay http://www.evilrealms.net/ - Systems Administrator Developer http://www.imperial.ac.uk/ - 3rd year CS student ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: zone(9) is broken on SMP?!
On Thu, 27 Nov 2003, Florian C. Smeets wrote: Max Laier wrote: If I build attached kmod and kldload/-unload it on a GENERIC kernel w/ SMP apic it'll error out: Zone was not empty (xx items). Lost X pages of memory. This is on a p4 HTT, but seems reproducible on proper SMP systems as well. UP systems don't show it however. Can somebody please try and report? Thanks! Yes this is reproducible on a real SMP system: bender kernel: Zone UMA test zone was not empty (65 items). Lost 1 pages of memory. I'll look into this over the weekend thanks. Cheers, Jeff Regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Debugging 5.2 Beta
Hi All, Just grabbed the 5.2Beta mini iso. Sadly the machine I tried it on caused a panic during kernel boot. A boot -v shows the last lines as (hand transcribed): PNP0700: ading dma mask 0x4 pnpbios: handle 10 device ID PNP0700 (0007d041) Fatal trap 9: general protection falut while in kernel mode cpuid=0; apic id=00 instruction pointer = 0x58:0x1023 stack pointer = 0x10:0xf80 frame pointer = 0x10:0x0 code segment = base 0xc00f, limit 0x, type 0x1b = DPL 0, pres1, def 32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL=0 current process = 0 (swapper) track number =9 panic: general protection fault cpuid = 0; uptime: 1s Tried turning PNP off/on in the bios, tried toggling hint.acpi.disable 0/1, not luck. Quick stats: P4 3G with HTT, 1024MB ram. MPTable: Springdale-G , pnpbios 15 devices, FreeBSD 4.9 runs nicely on the box with the attached dmesg. The box has a Promisc SATA Raid controller (which isn't detected under 4.9) which I'd really like to get working hence the attempt at 5.2. Any way to drop to DDB go get better traces? as debug.debugger_on_panic=1 debug.witness_ddb=1 do nothing. Cheers, Benjamin -- 3D Research Associate / System Administrator +61 8 8302 3669 School of Computer and Information Science Room D1-07, ML Campus University of South AustraliaMawson Lakes Blvd. [EMAIL PROTECTED] South Australia, 5095 F00D C83D 5F7E 5561 DF91 B74D E602 CAA3 4842 B5B4 Copyright (c) 1992-2003 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 4.9-RC #0: Wed Oct 29 06:26:58 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1072889856 (1047744K bytes) avail memory = 1038823424 (1014476K bytes) Preloaded elf kernel kernel at 0xc0548000. Warning: Pentium 4 CPU: PSE disabled Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 12 entries at 0xc00f3d20 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: PCI to PCI bridge (vendor=8086 device=2571) at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia model 0181 graphics accelerator at 0.0 irq 11 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xcc00-0xcc1f irq 11 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xd000-0xd01f irq 5 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xd400-0xd41f irq 10 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xd800-0xd81f irq 11 at device 29.3 on pci0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: USB controller at 29.7 irq 9 pcib2: Intel 82801BA/BAM (ICH2) Hub to PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib2 pci2: unknown card (vendor=0x105a, dev=0x3371) at 1.0 irq 11 fwohci0: Lucent FW322/323 mem 0xfeafe000-0xfeafefff irq 3 at device 7.0 on pci2 fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channel is 8. fwohci0: EUI64 00:07:e9:00:00:3d:6d:51 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 if_fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:07:e9:3d:6d:51 sbp0: SBP2/SCSI over firewire on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fxp0: Intel 82801BA (D865) Pro/100 VE Ethernet port 0xb000-0xb03f mem 0xfeafd000-0xfeafdfff irq 5 at device 8.0 on pci2 fxp0: Ethernet address 00:07:e9:3d:6d:51 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI to ISA
Change install-order? (upgrade from static to dynamic root)
I just installed 5.1-release on a sparc64, and then cvsup'ed to the latest snapshot of -current. Since that update is such a large jump in time, I was going from a system which had no /rescue or /libexec to one which builds everything dynamically. This gets one into a mess in the middle of installworld, where suddenly almost everything dies with messages like: ELF interpreter /libexec/ld-elf.so.1 not found I know others have run into this problem, but there seems to be nothing in UPDATING to warn people about it. Or at least, I didn't see anything in /usr/src/UPDATING under sparc64. Instead of warning people, I was wondering if there would be any downside to having installworld always install /rescue first (since that should not depend on anything else), and install /libexec before installing executables. - - - - I did recover from that mess by taking advantage of tips given in previous threads on this situation. I used the rescue binary in to give me a few key commands, doing something like: cd /usr/obj/usr/src/rescue/rescue ./rescue mkdir /usr/tempbin ./rescue ln rescue /usr/tempbin/cp ./rescue ln rescue /usr/tempbin/cat ./rescue ln rescue /usr/tempbin/ldconfig ./rescue ln rescue /usr/tempbin/ln ...etc... PATH=/usr/tempbin cd /usr/obj/usr/src/libexec/rtld-elf cp -p * /libexec ldconfig -m /lib cd /usr/obj/usr/src/usr.bin/xinstall cp -p xinstall /usr/bin/install I may have missed a few steps there, but I think that got me far enough along that I could 'make install's in /usr/src/lib and /usr/src/libexec. Once I was confident that I had enough working parts installed, I went back and repeated the 'make installworld'. Seems to have worked out OK. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Update to 5.2 beta from 5.1-current didn't work right
I did a binary update from 5.1-current, created with a mid October snapshot, to 5.2 beta. The installer had trouble, at one point reporting negative disk space available when of course there is plenty of space. This server has a single SATA drive with three slices for FreeBSD, a 5 GB /, and 42 GB /usr, along with swap. I had to do a binary update as this is a system that has been problematic with the ATA subsystem due to the combination of the Adaptec SATA 1210SA (in non RAID mode with a single drive) and a Maxtor 6Y120M0 120 GB drive. The system acts as if some of the older pre 64 bit filesystem code in still present the beta boot/kernel. I did boot from the mini-iso CD-ROM. Once the installer finished, I rebooted. The server claims to be a 5.2 beta kernel, but perhaps as a side effect of the new dynamic linking must have some old pre-64-bit filesystem code it is still using. === $ uname -a FreeBSD barney.computinginnovations.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue Nov 25 08:24:08 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 === As a result, on reboot, df core dumped as did fsck and mount. The static mount in /rescue did work though. As these problems look like what is in UPDATING: === 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Note that the backwards compatibility is only present when the kernel is configured with the COMPAT_FREEBSD4 option. Since even /bin/sh will not run with a new kernel without said option you're pretty much dead in the water without it. Make sure you have COMPAT_FREEBSD4! Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Marco Wertejuk [EMAIL PROTECTED] also reports that cfsd (ports/security/cfs) needs to be recompiled after these changes are installed. === I will cvsup to current then build and install a new kernel, then build and install world per UPDATING. If anyone wants more information, let me know. Below is the verbose dmesg. -Derek verbose dmesg: Nov 26 19:02:28 barney syslogd: kernel boot file is /boot/kernel/kernel Nov 26 19:02:28 barney kernel: 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10B 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10C 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10D 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11A 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11B 0x69 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11C 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11D 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12A 0x62 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12B 0x63 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12C 0x61 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12D 0x60 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13A 0x63 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13B 0x62 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13C 0x69 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13D 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 5 14A 0x61 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 5 14B 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 5 14C 0x60 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 5 14D 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 6 15A 0x62 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 6 15B 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 6 15C 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 6 15D 0x69 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: AcpiOsDerivePciId: bus 0 dev 31 func 0 Nov 26 19:02:28 barney kernel: acpi0: Power Button (fixed) Nov 26 19:02:28 barney kernel: ACPI timer
