Re: acpid implementation?
On Fri, 2002-11-08 at 22:23, Hiten Pandya wrote: > On Wed, Nov 06, 2002 at 10:27:47PM +0100, Frode Nordahl wrote the words in effect of: > > Hello, > > > > I have been searching mailing lists and my friend Google for information > > about a acpid (like apmd) implementation for FreeBSD, but I have found > > nothing. > > > > Does one exist anywhere, or has anyone started out on something without > > telling anyone? :) > > Why do you need an acpid? misc stuff instruct dhclient to get a new lease on resume (maybe free it on sleep), try to configure wlan if no link detected on ethernet etc. I put my computer to sleep instead of turning it of most of the time, and having to run "killall dhclient; dhclient dc0" every time I resume it after coming home / go to work is a bit annoying :) I'm sure people have this and other things they want to configure their computer to do on sleep / resume. > -- > Hiten Pandya > [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> Brooks Davis <[EMAIL PROTECTED]> writes: : On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote: : > I'd love for there to be a way to know which binaries use __sF. : : The following script run on your bin, sbin, lib, and libexec directories : does a pretty decent job of finding files that contain refrences to __sF : and listing the ports that use them (depend on portupgrade). I'm talking a warning at runtime for libraries that have the timebomb in them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dnet causes Hard Lock on SMP kernel? ( was 'Why is my -current system Hard Locking?' )
At Fri, 8 Nov 2002 00:58:10 + (UTC), Joel M. Baldwin <[EMAIL PROTECTED]> wrote: > > I got same result on my box. Only solution I have is deinstall > > dnetc. :-) ... > What motherboard/CPU is this on? > Have you tried a nonSMP kernel? It's SuperMicro's P3TDDE with dual P-III (1.13GHz). Yes, it works fine when I removed "options SMP" and "options apic" from kernel configuration. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock during buildworld
On Fri, 8 Nov 2002, Andrea Campi wrote:
> Hi all,
>
> for months now I've been having a reproducible hang under load
> (make -j4 buildworld on a uniprocessor with plenty of RAM). I transcribed
> some info which might be useful to debug it; it seems to me this is a
> deadlock (am I right?). I'll leave the laptop in ddb so I can provide
> more info.
>
> This is last week current; I had seen a few commits I thought might fix
> this but no.
>
>
> db> show locked
> Locked vnodes
> 0xc202ca68: tag ufs, type VDIR, usecont 1, writecount 0, refcount 2, flags
>(VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53304
> ino 31744, on dev ad2s2f (4, 16)
> 0xc27e04a0: tag ufs, type VREG, usecount 18, writecount 0, refcount 1, flags
>(VV_TEXT|VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53301 with 3 pending
> ino 87582, on dev ad2s2f (4, 16)
> 0xc2c13940: tag ufs, type VREG, usecount 18, writecount 0, refcount 1, flags
>(VV_TEXT|VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53302 with 3 pending
> ino 33113, on dev ad2s2f (4, 16)
>
At first glance, I think the following patch might fix it:
Index: kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.197
diff -u -r1.197 kern_exec.c
--- kern_exec.c 5 Nov 2002 18:04:50 - 1.197
+++ kern_exec.c 9 Nov 2002 06:02:25 -
@@ -628,14 +628,14 @@
if (imgp->firstpage)
exec_unmap_first_page(imgp);
- if (imgp->stringbase != NULL)
- kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase,
- ARG_MAX + PAGE_SIZE);
-
if (imgp->vp) {
NDFREE(ndp, NDF_ONLY_PNBUF);
vput(imgp->vp);
}
+
+ if (imgp->stringbase != NULL)
+ kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase,
+ ARG_MAX + PAGE_SIZE);
if (imgp->object)
vm_object_deallocate(imgp->object);
I'll look into it some more, but it looks like someone is holding the exec
map while they are trying to lock that vnode. That doesn't seem correct,
but this patch will fix the problem if that is the case. It's too bad we
dont have witness on lockmgr..
Thanks,
Jeff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: getting rid of devfs...
Ok here are some thought about devfs 1/ devices are coming and going and becoming more portable 2/ disk partitioning schemes are also multiplying 3/ devices such as usb or bluetooth nets can be configured in arbitray ways 4/ there are more than 256 types of device in the world. With these in mind, devfs takes a device NAME and directly maps it to teh driver in a way that is not controlled by the minor number. In the old scheme you had to have some algorythm to map a minor number to a partition or a virtual device or a logical instance. In the case of ttys this wasn't too hard, but even that grew to take several minor numbers per device, and disk partitions became impossible to correctly describe in the bits allocated.. Thus the GEOM code for example divides up the disk and exports a number of device names to /dev, but depending on the way the drive is layed out there may be no possible wy to describe that layout using the old bitmask scheme. for example in GEOM you can theoretically partition ad0s3d into another set of partitions so you would have ad0s3da, ad0s3db ad0s3dc ad0s3dd etc. You CAN NOT describe that as the old bitmask set. other possibilities include striping two disks together under GEOM.. how do you describe that? When we pass the 255th device driver what major number do you assign to the next one? You can still make device nodes so that the disk can be exported, but as, in -current the major and minor number will not exist (in effect it would be like they are being defined dynamically..i And -current will eventually ignore such nodes. they are for export only in case you need to export a filesystem to (say) linux. In fact majors and minors, being dynamic, could change from boot to boot. You would have no way to know what major and minor numbers to put on the nodes.. major and minor numbers are not needed and are going away entirely. the act of accessing the name in /dev is enough to identify to the kernel which driver to talk to and to identify to the driver which instance you are interested in. If you load a kernel module that wants major number x and soemone else writes a module that wants major number x, in teh old scheme you had to define a scheme to resolve the problem.. with devfs there IS no problem. For this all to work though we have to get rid of major numbers and minor numbers as such, and so once you've crossed that bridge there is no going back. Once devfs is standard, it's manditory (in effect.) julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I'm mostly off email
My normal server is offline. Anything sent to me in the last day or so will be in a queue waiting for it to come back online... meanwhile, I have undiverted my freebsd mail and am reading it on hub.. So if you are waiting for me to respond to something you sent today... contact me again. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getting rid of devfs...
On Fri, Nov 08, 2002 at 06:14:09PM -0600, Anti wrote: > and if you must? dual boot 4.7 here so was able to create the > devices easy enough from there and all is well, but i'd like to do > it on some other boxes where this isn't an option... Perhaps you could explain why it's not an option. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
At 6:13 PM -0500 11/8/02, Daniel Eischen wrote: On Fri, 8 Nov 2002, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Daniel Eischen <[EMAIL PROTECTED]> writes: : All the ports are going to be rebuilt for the release anyways, : so this doesn't affect fresh installs, correct? It is only a : problem when mixing older 4.x and 5.0 libraries/binaries with : __sF-free libc (if I understand things correctly). The problem is that you cannot have 4.x packages and 5.x packages > co-mingled on the same system. that's what I'm trying to fix. > You'd have to rebuild the 4.x packages before they are fixed. I don't think this is a show-stopper. Just recompile all your ports or use the pre-built 5.0 packages. This assumes that you have the source code to everything you are running, which may not be true. This also assumes that "all you need to do" is type another 'make' in some directory, and your source code will pleasantly compile without any new problems from any of the long list of changes to include-files, ports, or the new version of gcc. Yes, every user can eventually plow their way through all that work, and by the time they do we'll probably already have 5.1-release out. Philosophically I would prefer that __sF was completely gone for 5.0-release, but at the moment I think Warner is right in saying that we need to keep it in libc until at least 5.1. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d and sysctl.conf
On Wed, Oct 30, 2002 at 02:36:01PM -0800, Bill Fenner wrote: [ snip ] > > The update to the /etc/rc.d infrastructure keeps the ability to run > twice, but does not actually run it twice. I started creating an > /etc/rc.d/sysctl-last that would run "/etc/rc.d/sysctl lastload", > but realized that I didn't know how to say where the first/second > call should go. To strictly follow /etc/rc.d, I could change the > existing /etc/rc.d/sysctl to say "BEFORE: serial" and add "BEFORE: > securelevel" to sysctl-last, but I'm not sure this is appropriate given > the meta-checkpoints that we have. One of the hard things while I was doing the porting was deciding whether something in /etc/rc was there because it *must* run before the commands that were after it and after the commands that came before it. Since there haven't been any complaints in that regard I don't think the current order has broken anything. The general rule is to put something in REQUIRE and/or BEFORE only if it is necessary that some script be run before or after the current script. So, if the sysctls *must* be set before SERIAL, it should be in the BEFORE line. Otherwise, I would leave it as is and run `/etc/rc.d/sysctl lastload' in /etc/rc.d/securelevel just before rasing the securelevel (Please see the attached patch). > > (It also raises the question of if /etc/rc.d/securelevel actually > runs at the right time. /etc/rc puts it almost at the absolute end, > while rcorder sticks it somewhere in the middle -- number 67 of 102 > on my system.) We wanted to keep the differences between our scripts and NetBSD's to a minimum. So, if it turns out we've broken something because of where rcorder puts the securelevel script, then we'll have to modify the BEFORE line of the affected script. Cheers, Mike -- GPG Key: http://www.identd.net/~mtm/gpg.key pub 1024D/7D39509A 2002-10-08 Mike Makonnen <[EMAIL PROTECTED]> Key fingerprint = 5491 488A 0445 2DCC 777B 1F03 F3AB F9F8 7D39 509A msg46410/pgp0.pgp Description: PGP signature
Re: cvs commit: src/etc rc.subr
On Fri, Nov 08, 2002 at 06:26:13PM -0800, Doug Barton wrote: > > I'm not sure I like this change actually... having the debug output go > to syslog is very useful if you don't have a console on the system for > whatever reason. > I agree. It's also usefull when you're in an X session or other console messages have scrolled the output out of the buffer. Cheers, Mike. -- GPG Key: http://www.identd.net/~mtm/gpg.key pub 1024D/7D39509A 2002-10-08 Mike Makonnen <[EMAIL PROTECTED]> Key fingerprint = 5491 488A 0445 2DCC 777B 1F03 F3AB F9F8 7D39 509A msg46409/pgp0.pgp Description: PGP signature
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 10:09:10PM -0500, Hiten Pandya wrote: > P.S. hw.pci should moved somewhere global, but donno how this can be > done or even if it is possible to do. I think you just need a SYSCTL_DECL(_hw_pci) in scope. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg46408/pgp0.pgp Description: PGP signature
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 05:45:00PM -0500, Matthew N. Dodd wrote the words in effect of:
> On Fri, 8 Nov 2002, Terry Lambert wrote:
> > "Matthew N. Dodd" wrote:
> > > Recompile your kernel with
> > >
> > > options PCI_ALLOW_UNSUPPORTED_IO_RANGE
> >
> > Given the number of times that this comes up, can we change that to
> > "PCI_ALLOW_ACTUALLY_SUPPORTED_IO_RANGE_WHICH_IS_NON_DEFAULT_TO_BE_ANNOYING"
> > ?
>
> I think the plan is to make this option a loader tunable and make the
> conditional in the pci code "bitchy" and then fix the larger problem with
> IO ranges.
Hi there.
I have made a basic patch, which took me about 10 minutes to do so.
Basically, it removes the option PCI_ALLOW_UNSUPPORTED_IO_RANGE, and
replaces it with a loader tunable. This is no different from imp's
change to make PCI_ENABLE_IO_MODES a l-tunable. But this time, I do not
have a sysctl to show the _readonly_ value, this is because the hw.pci
node leaves in pci.c and I am unsure of how to tackle that. I have not
tested this patch, so consider it experimental.
Also. If this patch works, then we will have to remove the
PCI_ALLOW_UNSUPPORTED_I0_RANGE from ``options'' files and add entries
for hw.pci.enable_io_modes and this loader tunable to the loader(8)
manual page or some such.
Patch also available at:
http://www.unixdaemons.com/~hiten/work/diffs/pci_pci.patch
Cheers.
P.S. hw.pci should moved somewhere global, but donno how this can be
done or even if it is possible to do.
--
Hiten Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
--- /home/hiten/pci_pci.c Fri Nov 8 17:25:52 2002
+++ /sys/dev/pci/pci_pci.c Fri Nov 8 19:11:03 2002
@@ -38,6 +38,9 @@
#include
#include
#include
+#if 0
+#include
+#endif
#include
@@ -90,6 +93,18 @@
DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclass, 0, 0);
/*
+ * sysctl and tunable vars
+ */
+int pci_allow_unsupported_io_range = 1;
+TUNABLE_INT("hw.pci.allow_unsupported_io_range",
+ (int *)&pci_allow_unsupported_io_range);
+#if 0
+SYSCTL_INT(_hw_pci, OID_AUTO, allow_unsupported_io_range, CTLFLAG_RD,
+ &pci_allow_unsupported_io_range, 1,
+ "Allows the PCI Bridge to pass through an unsupported memory range"
+ "assigned by the BIOS.");
+#endif
+/*
* Generic device interface
*/
static int
@@ -288,21 +303,23 @@
switch (type) {
case SYS_RES_IOPORT:
if (!pcib_is_isa_io(start)) {
-#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE
- if (start < sc->iobase)
- start = sc->iobase;
- if (end > sc->iolimit)
- end = sc->iolimit;
- if (end < start)
- start = 0;
-#else
- if (start < sc->iobase)
- printf("start (%lx) < sc->iobase (%x)\n", start, sc->iobase);
- if (end > sc->iolimit)
- printf("end (%lx) > sc->iolimit (%x)\n", end, sc->iolimit);
- if (end < start)
- printf("end (%lx) < start (%lx)\n", end, start);
-#endif
+ if (!pci_allow_unsupported_io_range) {
+ if (start < sc->iobase)
+ start = sc->iobase;
+ if (end > sc->iolimit)
+ end = sc->iolimit;
+ if (end < start)
+ start = 0;
+ } else {
+ if (start < sc->iobase)
+ printf("start (%lx) < sc->iobase (%x)\n", start,
+ sc->iobase);
+ if (end > sc->iolimit)
+ printf("end (%lx) > sc->iolimit (%x)\n",
+ end, sc->iolimit);
+ if (end < start)
+ printf("end (%lx) < start (%lx)\n", end, start);
+ }
}
if (!pcib_is_isa_io(start) &&
((start < sc->iobase) || (end > sc->iolimit))) {
@@ -325,21 +342,23 @@
*/
case SYS_RES_MEMORY:
if (!pcib_is_isa_mem(start)) {
-#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE
- if (start < sc->membase && end >= sc->membase)
- start = sc->membase;
- if (end > sc->memlimit)
- end = sc->memlimit;
- if (end < start)
- start = 0;
-#else
- if (start < sc->membase && end > sc->membase)
- printf("start (%lx) < sc->membase (%x)\n", start, sc->membase);
- if (end > sc->memlimit)
- printf("end (%lx) > sc->memlimit (%x)\n", end, sc->memlimit);
- if (end < start)
- printf("end (%lx) < start (%lx)\n", end, start);
-#endif
+ if (!pci_allow_unsupported_io_range) {
+ if (start < sc->membase && end >= sc->membase)
+ start = sc->membase;
+ if (end > sc->memlimit)
+ end = sc->memlimit;
+
Re: getting rid of devfs...
and if you must? dual boot 4.7 here so was able to create the devices easy enough from there and all is well, but i'd like to do it on some other boxes where this isn't an option... On Sat, 09 Nov 2002 00:14:08 +0100 Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, Anti writes: > > > >how are you supposed to get rid of devfs? > > You're not. > > -- > 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/etc rc.subr
Gordon Tetlow wrote: > > On Fri, Nov 08, 2002 at 09:06:15AM -0800, Gordon Tetlow wrote: > > gordon 2002/11/08 09:06:15 PST > > > > Modified files: > > etc rc.subr > > Log: > > Diff reduction to NetBSD: > > > > Fix a minor grammer nit. > > Get rid of _echo that uses logger and just call logger in the 3 routines > > that need it. > > Add a comment referencing rc.conf(5) in the case of an incorrectly set > > variable. > > The other thing this does is disable sending debug output to syslog. It > really doesn't belong there anyway. After all, it just debugging. I'm not sure I like this change actually... having the debug output go to syslog is very useful if you don't have a console on the system for whatever reason. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, Nov 08, 2002 at 05:05:23PM -0800, Brooks Davis wrote:
> On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
> > I'd love for there to be a way to know which binaries use __sF.
>
> The following script run on your bin, sbin, lib, and libexec directories
> does a pretty decent job of finding files that contain refrences to __sF
> and listing the ports that use them (depend on portupgrade).
>
> #!/bin/sh
>
> sym=__sF
>
> for file in $*; do
> if [ -n "`nm ${file} 2>&1 | egrep " ${sym}$"`" ]; then
> echo ${file} `pkg_which $file`
> fi
> done
nm doesn't work on shared libraries. You can
use strings to find __sF in shared libs.
troutmask:kargl[201] cd /mnt/usr/lib/
troutmask:kargl[202] nm libm.a | grep sF
U __sF
troutmask:kargl[203] nm libm.so.2 | grep sF
nm: libm.so.2: no symbols
troutmask:kargl[204] strings libm.so.2 | grep sF
__sF
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, Nov 08, 2002 at 05:22:13PM -0800, [EMAIL PROTECTED] wrote: > BTW, I did remove the $ from $*. I thought it was running too fast :-) You're supposed to pass it a list of files not run it in a directory. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg46402/pgp0.pgp Description: PGP signature
Re: [PATCH] note the __sF change in src/UPDATING
Quoting Brooks Davis <[EMAIL PROTECTED]>:
| On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
| > I'd love for there to be a way to know which binaries use __sF.
|
| The following script run on your bin, sbin, lib, and libexec directories
| does a pretty decent job of finding files that contain refrences to __sF
| and listing the ports that use them (depend on portupgrade).
|
| -- Brooks
|
|
| #!/bin/sh
|
| sym=__sF
|
| for file in $*; do
| if [ -n "`nm ${file} 2>&1 | egrep " ${sym}$"`" ]; then
| echo ${file} `pkg_which $file`
| fi
| done
|
FWIW, while playing with the script I found libc_p.a from today's build.
ed
BTW, I did remove the $ from $*. I thought it was running too fast :-)
--
-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
> I'd love for there to be a way to know which binaries use __sF.
The following script run on your bin, sbin, lib, and libexec directories
does a pretty decent job of finding files that contain refrences to __sF
and listing the ports that use them (depend on portupgrade).
-- Brooks
#!/bin/sh
sym=__sF
for file in $*; do
if [ -n "`nm ${file} 2>&1 | egrep " ${sym}$"`" ]; then
echo ${file} `pkg_which $file`
fi
done
msg46400/pgp0.pgp
Description: PGP signature
Re: [PATCH] note the __sF change in src/UPDATING
Daniel Eischen wrote:
> I'm not even close to a shared library/linker expert, but
> I thought there was a way to have something run when an
> object file got loaded. From rtld(1):
>
> After all shared libraries have been successfully loaded, ld-elf.so.1
> proceeds to resolve external references from both the main program and
> all objects loaded. A mechanism is provided for initialization routines
> to be called on a per-object basis, giving a shared object an opportunity
> to perform any extra set-up before execution of the program proper
> begins. This is useful for C++ libraries that contain static construc-
> tors.
>
> If you put __sF in it's own file with whatever is needed for
> the above, won't that work?
The key to this is "on a per object basis".
You only get one .init section, and if you provide your own,
then the generated one is ignored and not used. This only
becomes a problem when you try to use Objective C or C++
code linked against the library, but at that point, it becomes
a critical problem; example:
static void _dl_init(void) __attribute__((section(".init")));
static void
_dl_init(void)
{
char*argv [2] = {
"./xxx",
NULL
};
__do_dynamic_link( argv);
}
This is code from my "libdlopen" that tries to work around the
problem with the argv parameter not being passed down to the
dynamic linker initialization. It uses the .init section, since
the constructor code is not properly called with a non-void
argument, and the constructor code is c++rt0 instead of crt0,
so it's not universally called (an artifact of static linking).
The "which is dangerous"/"which is stupid" messages are actually
ld.so hacks, or other linker hacks to do with symbol resolution,
rather than compile-time things
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
DND-VIRUSMELDUNG / Email zerstoert/deletet/cancellato
Multilingual message - scroll down! Deutsch: --- Die Antivirus checkroutine unseres Mailservers (ms.dindi.com) hat festgestellt, dass Sie von "[EMAIL PROTECTED]" (diese Adresse könnte gefälscht sein!!) eine Email-Nachricht erhalten haben, mit dem Betreff: "Re:freebsd-current,honey" an: [EMAIL PROTECTED] Es wurde dieser Virus gefunden: the W32/Klez.h@MM virus !!! Die infizierte Datei lautet: HA-BRÜ.bat Bitte setzen Sie sich eventuell mit dem Absender "[EMAIL PROTECTED]" dieses Virus in Verbindung, um weitere Schäden zu vermeiden. Bestimmte Virentypen (z.Bsp.: Klez-Varianten, Bugbear) fälschen diese Absender- adressen, d.h. der Virus muß nicht unbedingt von dem Absender abgeschickt worden sein, von dem Sie den Virus erhalten haben! Die infizierte Email-Nachricht wird aus Sicherheitsgründen nicht zugestellt, ist aber unter Quarantäne gestellt. Deutschsprachige Informationen zu diesem Virus finden Sie unter anderem unter: http://www.percomp.de/virusinformationen.html Dieser Service steht Ihnen als Kunde bei der DND Internet Agentur ohne Mehr- kosten permanent zur Verfügung. Der Sicherheit unserer Kunden und Partner wird bei DND höchstmöglichste Priorität eingeräumt. Ihre DND Internet Agentur Brixen / Tel.: +39 0472 802403 / Mail: [EMAIL PROTECTED] http://www.dindi.com Italiano: --- Il seguente messaggio di posta elettronica conteneva allegati con virus; il sistema automatico di controllo del nostro mailserver ha provveduto alla sua rimozione. Inviato da: "[EMAIL PROTECTED]" (potrebbe essere falsificato) Soggetto: "Re:freebsd-current,honey" Inviato a: [EMAIL PROTECTED] Nome del virus trovato: the W32/Klez.h@MM virus !!! File/allegato infettato: HA-BRÜ.bat Per maggiori informazioni si può mettere in contatto con il nostro personale. DND Agenzia Internet Bressanone / Tel.: +39 0472 802403 / Mail: [EMAIL PROTECTED] http://www.dindi.com English: --- The DND Antivirus software on dindi.com has reported that you sent a virus with the subject "Re:freebsd-current,honey" to: [EMAIL PROTECTED] The E-mail containing the virus has been quarantined to prevent further damage. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel not booting....Immediate crash
David Schultz wrote: > Thus spake Sidcarter <[EMAIL PROTECTED]>: > > Fatal trap 12: page fault while in vm86 mode > > fault virtual address = 0x9fdc8 > ^^^ > That's a region of memory right before the 640K mark, > and your BIOS is trying to use it. This used to work, > but revision 1.544 of src/sys/i386/i386/machdep.c moved > the code that mapped in those pages until *after* they > need to be used. I (unsuccessfully) petitioned the > committer who made the change to revert it, so for now > you'll have to manually remove it, being careful not to > step on the changes introduced in revisions 1.545 through > 1.547. Or look in the -current archives; Mitsuru IWASAKI posted a patch yesterday at 11:29 PM. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1206362+0+current/freebsd-current -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, 8 Nov 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Daniel Eischen <[EMAIL PROTECTED]> writes: > : On Fri, 8 Nov 2002, M. Warner Losh wrote: > : > : > In message: <[EMAIL PROTECTED]> > : > Daniel Eischen <[EMAIL PROTECTED]> writes: > : > : All the ports are going to be rebuilt for the release anyways, > : > : so this doesn't affect fresh installs, correct? It is only a > : > : problem when mixing older 4.x and 5.0 libraries/binaries with > : > : __sF-free libc (if I understand things correctly). > : > > : > The problem is that you cannot have 4.x packages and 5.x packages > : > co-mingled on the same system. that's what I'm trying to fix. You'd > : > have to rebuild the 4.x packages before they are fixed. > : > : I don't think this is a show-stopper. Just recompile all your > : ports or use the pre-built 5.0 packages. > > I disagree. No problem :-) > : > : This is 5.0; it is a major release and there will be some flies > : > : in the ointment. I say bite the bullet now -- don't wait. > : > : If we want to provide an optional compatability hack to libc > : > : so that folks can compile it with __sF support, then I think > : > : that is better than leaving __sF in the release, perhaps > : > : with a mktemp(3)-like warning if possible (?). > : > > : > You'd need a run-time warning for this to be effective. I'm not sure > : > that ld.so can do this right now. > : > : Could you put __sF in it's own file, and put the error in > : a .init section? We don't care about static binaries, right? > : They shouldn't have a problem. > > More details please. I'd love for there to be a way to know which > binaries use __sF. I'm not even close to a shared library/linker expert, but I thought there was a way to have something run when an object file got loaded. From rtld(1): After all shared libraries have been successfully loaded, ld-elf.so.1 proceeds to resolve external references from both the main program and all objects loaded. A mechanism is provided for initialization routines to be called on a per-object basis, giving a shared object an opportunity to perform any extra set-up before execution of the program proper begins. This is useful for C++ libraries that contain static construc- tors. If you put __sF in it's own file with whatever is needed for the above, won't that work? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel not booting....Immediate crash
Thus spake Sidcarter <[EMAIL PROTECTED]>: > Fatal trap 12: page fault while in vm86 mode > fault virtual address = 0x9fdc8 ^^^ That's a region of memory right before the 640K mark, and your BIOS is trying to use it. This used to work, but revision 1.544 of src/sys/i386/i386/machdep.c moved the code that mapped in those pages until *after* they need to be used. I (unsuccessfully) petitioned the committer who made the change to revert it, so for now you'll have to manually remove it, being careful not to step on the changes introduced in revisions 1.545 through 1.547. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fetch hates me! (panic)
I was trying to do 'portupgrade portupgrade' today and my -CURRENT
system rebooted. Strange - I haven't seen such behaviour before. I
believe it wouldn't happen before my last upgrade (it was 30-10-2002
-CURRENT system, and I cvsup'ed it on 6-11-2002)
After reboot I retried portupgrade - samre result. During next few
reboot cycles I managed to narrow the problem a little - I am getting
100% reproducible panics when running this script as root:
#!/bin/sh
export FTP_PASSIVE_MODE=no
fetch -v ftp://ftp.iDaemons.org/pub/distfiles/pkgtools-20021103-20021106.diff.bz2
So I've compiled in DDB, INVARIANTS and WITNESS stuff I have
previously removed from kernel. Here is the information I gathered:
1. First - I think this might be important (kernel message after samba
has started):
Local package initialization: apache2 proftpd rtc Sambaacquiring
duplicate lock
of same type: "inp"
1st inp @ /usr/src/sys/netinet/udp_usrreq.c:290
2nd inp @ /usr/src/sys/netinet/udp_usrreq.c:290
2. The crash (result of running the script). This is hand-copied, I
don't even have swap-space for crash dumps...
panic: process 657(fetch):32 holds inp but isn't blocked on a mutex
Debugger("panic")
Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c03906fb,c0405100,c038f900,d68bdc30,1) at ...
panic ...
propagate_priority(c152ea90,2,c038f82d23b,c4522c7c) at propagate_priority+0x1bf
_mtx_lock_sleep(c4522c7c,0,c03968a9,182,c4524ee0) at _mtx_lock_sleep+0x217
_mtx_lock_flags(c4522c72,0,c039b8a9,182,c03913eb) at _mtx_lock_flags+0x97
syncache_timer(2,0,c03913eb,bf,39a5) at syncache_timer+0xa4
softclock(0,0,c038e13c,230,c152da80) at softclock+0x18c
ithread_loop(c151c600,d68bdd48,c038de9b,354,c152ea90) at ithread_loop+0x16c
fork_exit(c01efef0,c151c600,a68bdd48) at fork_exit+0xa5
fork_trampoline() at fork_trampoline+0x1a
---trap 0x1, eip=0, esp=0xd68bdd7c, ebp=0 ---
--
Krzysztof Jędruczyk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 8 15:10:02 PST 2002 -- >>> Kernel build for GENERIC completed on Fri Nov 8 15:42:44 PST 2002 -- >>> Kernel build for LINT started on Fri Nov 8 15:42:44 PST 2002 -- ===> vinum "Makefile", line 4403: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> Daniel Eischen <[EMAIL PROTECTED]> writes: : On Fri, 8 Nov 2002, M. Warner Losh wrote: : : > In message: <[EMAIL PROTECTED]> : > Daniel Eischen <[EMAIL PROTECTED]> writes: : > : All the ports are going to be rebuilt for the release anyways, : > : so this doesn't affect fresh installs, correct? It is only a : > : problem when mixing older 4.x and 5.0 libraries/binaries with : > : __sF-free libc (if I understand things correctly). : > : > The problem is that you cannot have 4.x packages and 5.x packages : > co-mingled on the same system. that's what I'm trying to fix. You'd : > have to rebuild the 4.x packages before they are fixed. : : I don't think this is a show-stopper. Just recompile all your : ports or use the pre-built 5.0 packages. I disagree. : > : This is 5.0; it is a major release and there will be some flies : > : in the ointment. I say bite the bullet now -- don't wait. : > : If we want to provide an optional compatability hack to libc : > : so that folks can compile it with __sF support, then I think : > : that is better than leaving __sF in the release, perhaps : > : with a mktemp(3)-like warning if possible (?). : > : > You'd need a run-time warning for this to be effective. I'm not sure : > that ld.so can do this right now. : : Could you put __sF in it's own file, and put the error in : a .init section? We don't care about static binaries, right? : They shouldn't have a problem. More details please. I'd love for there to be a way to know which binaries use __sF. : > This is not a fly in the pointment, but rather a major incompatibility : > that makes it impossible to have a reasonable mix. : : If it's really a hassle for folks, then just provide the : optional compatability hack and make them rebuild libc. : Or provide a pre-built version that doesn't get installed : by default. I'm not sure that I agree with that solution. __sF was supposed to die in -stable around 4.3, but the ball got dropped on the floor. If it had, then I wouldn't care so much now. I don't see it as a big deal to have it for 5.0, but not 5.1 or 5.2 depending... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
> > I mean *all* the cruft -- old modules and config files, deprecated binaries
> > and man pages, even old shlibs if it's safe.
>
> I agree with you, and I was giving an example that a lesser form of
> this is already required during the upgrade.
>
> It would be VERY useful if someone could develop a script to do this
> (e.g. install various versions of 4.x and do an upgrade, then collect
> a complete list of all the stale files).
#=
#!/bin/sh
installdirs=/bin /sbin /usr/bin /usr/sbin /usr/libdata /usr/libexec /usr/include
/usr/share /usr/lib
for dir in ${installdirs} ; do
find ${dir} -type f -ctime +1 -delete
find ${dir} -type d -empty -delete
find ${dir} -type l -delete
done
# 4.x -> 5.x only:
# rm -rf /kernel* /modules*
cd /usr/src && make installworld
#=
The second "make installworld" is to repopulate your lib/compat/ dirs,
rebuild the hierarchy and to catch files (groff support IIRC) that
this erroneously deletes.
I do this pretty often.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: getting rid of devfs...
In message <[EMAIL PROTECTED]>, Anti writes: > >how are you supposed to get rid of devfs? You're not. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, 8 Nov 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Daniel Eischen <[EMAIL PROTECTED]> writes: > : All the ports are going to be rebuilt for the release anyways, > : so this doesn't affect fresh installs, correct? It is only a > : problem when mixing older 4.x and 5.0 libraries/binaries with > : __sF-free libc (if I understand things correctly). > > The problem is that you cannot have 4.x packages and 5.x packages > co-mingled on the same system. that's what I'm trying to fix. You'd > have to rebuild the 4.x packages before they are fixed. I don't think this is a show-stopper. Just recompile all your ports or use the pre-built 5.0 packages. > : This is 5.0; it is a major release and there will be some flies > : in the ointment. I say bite the bullet now -- don't wait. > : If we want to provide an optional compatability hack to libc > : so that folks can compile it with __sF support, then I think > : that is better than leaving __sF in the release, perhaps > : with a mktemp(3)-like warning if possible (?). > > You'd need a run-time warning for this to be effective. I'm not sure > that ld.so can do this right now. Could you put __sF in it's own file, and put the error in a .init section? We don't care about static binaries, right? They shouldn't have a problem. > This is not a fly in the pointment, but rather a major incompatibility > that makes it impossible to have a reasonable mix. If it's really a hassle for folks, then just provide the optional compatability hack and make them rebuild libc. Or provide a pre-built version that doesn't get installed by default. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
On Fri, 8 Nov 2002, Terry Lambert wrote: > Horen wrote: > > Now the missing facts: > > > >4.x binaries will not run on 5.0, lib.c inconsistency. > > You are not running the most recent 5.x. We can't help you, I > think. > > > >Identical XFree86 sources compiled nativly on 4.6, 4.7 and 5.0. > >4.6-4.7: no problem > >5.0: logout from X blocks the graphic card, Matrox MGA 400 > > and also Nvidia GeForce2 MX200 > > Different compilers. You have failed to narrow the problem down; > here's where it might be: > > 1)In the configuration code > 2)In the difference in the patches between the versions of > the ports tree for X11 > 3)In the X11 libraries' handling of threads > 4)In the 5.x implementation of pthreads > 5)In the GCC compiler optimizer > 6)In the GCC compiler code generator > 7)In the X11 source code; there are certain assumptions > that the new compiler makes which it was always permissable > for it to make, but which the old compiler did not make, > even though it was allowed to (i.e. a revealed bug in the > X11 sources) > 8)A bug in the AGP (/dev/agpart) code > 9)A bug in the ACPI handling of monitor power-down code > 10) A bug in the ACPI BIOS information of your computer itself > 11) In a mismatch between kernel and kernel module versions > 12) In a difference in the values of manifest constants > > > I doubt, that something else than OS related issues are the > > cause. > > Doubt it all you want; from the small amount of information you > have provided us, it looks to me like there is a possibility > that it's 50% non-OS-releated. > > > > Switched back to 4.7 , will try again 5.0 in few weeks. > > If it happens again, be sure and give us useful information, > like: > > o Since Warner fixed the libc incompatabilities, have > you installed the 4.7 version of X11 on 5.x, and does > the problem still happen? Yes, it happened, I didn't make notes exact which version of X11 it was. 4.7 was updated on 11/1/2002 > o Does it happen if ACPI isn't loaded? Didn't test it. > o Does it happen with the Xvga server, or only with the > accelerated server? It happens with both server. > o Are you on a laptop or a desktop? It's a desktop with following hardware configuration: Tyan Thunder K7 (S2462) Motherboard ( with onboard ATI graphic chip ) not used Intel MultiProcessor Specification v1.4 activated 2 G Ram 2 x Athlon 2000+ Gr. Cards tested Matrox MGA400 Max and Nvidia GeForce2 MX200 2 IBM SCSI HD ( each 36 G ) Monitor Sony GDM F520 > o If a desktop, does turning the monitor off and back on > "fix" the problem for you? No, only a reboot. > o What the checkout date for your 5.x source tree? It's > unlikely that someone would be willing to spend 30 hours Last checkout 11/7/2002. -Horen > duplicating your test environment, but you never know... > o The results of any discriminating tests for the possible > causes, per the list, earlier in this email. > > Thanks, > -- Terry > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
"M. Warner Losh" wrote: > My plan is as follows: > > 1) Restore __sF to libc for 5.0. > 2) Fix 4.x binaries so that __sF isn't referened in new >binaries. This should have been done in Aug 2001, but >wasn't. > > Depending on how things go, __sF will be removed in 5.1 or 5.2 after > we have the transition period we had originally planned for 4.x, but > implemented a year ago. Before anyone's head explodes, this will *NOT* generate *new* references to __sF. Warner is *NOT* talking about changing the definitions in stdio back to their old values. *NEW* code will get the *NEW* definitions, with certain specific exceptions. The exceptions are for new code linked against old libraries, or compiled with old tools, and linked agoinst those old tools' libraries (e.g. Modula 3 and FORTRAN 95). The issue this raises is that if/when the size of struct file changes, the old programs will quit working, unless *ALL* of the libraries which reference the obsoleted symbols varsions are bumped between 4.x and 5.x, and *ALL* of them are made available as part of the binary compatability package. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
getting rid of devfs...
how are you supposed to get rid of devfs? building a kernel without it won't boot since there are no devices... shouldn't there be a ./MAKEDEV all or something underneath the devfs mount so you can boot without it? or am i missing something? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, 8 Nov 2002, Terry Lambert wrote: > "Matthew N. Dodd" wrote: > > Recompile your kernel with > > > > options PCI_ALLOW_UNSUPPORTED_IO_RANGE > > Given the number of times that this comes up, can we change that to > "PCI_ALLOW_ACTUALLY_SUPPORTED_IO_RANGE_WHICH_IS_NON_DEFAULT_TO_BE_ANNOYING" > ? I think the plan is to make this option a loader tunable and make the conditional in the pci code "bitchy" and then fix the larger problem with IO ranges. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpid implementation?
Hiten Pandya wrote: > > I have been searching mailing lists and my friend Google for information > > about a acpid (like apmd) implementation for FreeBSD, but I have found > > nothing. > > > > Does one exist anywhere, or has anyone started out on something without > > telling anyone? :) > > Why do you need an acpid? Power profiles, for one. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
Ray Kohler wrote: > > Yes, it's already a mandatory step (remove old includes, or you can't > > build C++ programs). > > I mean *all* the cruft -- old modules and config files, deprecated binaries > and man pages, even old shlibs if it's safe. You need a registration system which can subsume all installed software into discrete components, and deinstall those components which have been removed, or, better, upgrade them with new version of components which are no longer default, and which have been made optional. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
"Matthew N. Dodd" wrote: > Recompile your kernel with > > options PCI_ALLOW_UNSUPPORTED_IO_RANGE Given the number of times that this comes up, can we change that to "PCI_ALLOW_ACTUALLY_SUPPORTED_IO_RANGE_WHICH_IS_NON_DEFAULT_TO_BE_ANNOYING" ? Thanks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
Maksim Yevmenkin wrote: > 1. Hardware: Attach the USB device into a USB port closer > to the root hub. > > 2. Software: Detect the CRC/Timeout error and count exceeded > and attempt to re-queue the packets while changing the length > of the packets. Changing the length of the packets will change > the CRC and thus will likely remove the combination of the > two events causing the failure. > > Status: > > Fixed in B-0 stepping. > > Note: > > This erratum was carried over from the Intel® 82371EB (PIIX4E). > > > > Needless to say that i have Intel 82371AB/EB chip in my laptop > *and* i'm getting CRCTO,TIMEOUT errors. all the dumps still > available at 3. Return your hardware for replacement by hardware with B-0 or higher stepping. 8-). Yes, it's likely the problem. The proper fix is probably #2, since it will make it work, no matter if you have bad hardware or not. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please add me to your mailing list, thank you
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
Andrew Kenneth Milton wrote:
> +---[ Steve Kargl ]--
> |
> | I agree with Dan. Let's do it now. My understanding is
> | that 5.0 will be an "early adopter" release and production
> | systems should run 4.7{8,9,..} until 5.1 is released.
> |
> | To accomplish the change, I think we need to do:
> | 1. Install a complete set of 4.7 shared libs in COMPAT4X.
> | This should porivde the necessary runtime compatibility
> | with 4.x.
> | 2. Bump all shared library on 5.0. This will get rid of
> | any interdependencies among the libraries and it deals
> | with the version number problems I detailed in the thread
> | "Ghost of __sF ..." a couple a days ago.
> | 3. Put a big fat WARNING in src/UPDATING about the problem
> | 4. Put the same WARNING in /etc/motd, so people currently
> | run -current will know to update their ports.
> | 5. Broadcast the WARNING to appropriate mailing lists and
> | newsgroups.
>
> 6. Assume Crash Position.
7. Profit!
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
Martin Faxer wrote: > the nvidia supplied drivers appear to work fine except for libGL* which > are compiled on an older system and thus give: > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libGL.so.1: Undefined symbol > "__sF" > > any way to get around this? Yes. Run a newer version of -current. Warner Losh fixed this in the last day or so. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Daniel Eischen wrote: > > By default, ti_jump_table entries contain pointers to dummy function like > > _return_zero if no threading library is loaded. When the threading library is > > loaded, ti_jump_table is populated with new pointers to functions implemented > > in threading library library. GDB did not allow me to track down where exactly > > this happens, I presume .init function in libpthread.so does that. > > OK, here's a patch that uses a jump table, as well as some other > fixes (use single underscore versions of pthread functions internally > in libc_r, avoid cancellation points for _pthread_cond_[timed]wait, > and other cleanups): > > http://people.freebsd.org/~deischen/libc-libc_r.diffs > > Can someone review and test this with GNOME? I don't use gnome, but it seems to work. You are a code-stud. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
Horen wrote: > Now the missing facts: > >4.x binaries will not run on 5.0, lib.c inconsistency. You are not running the most recent 5.x. We can't help you, I think. >Identical XFree86 sources compiled nativly on 4.6, 4.7 and 5.0. >4.6-4.7: no problem >5.0: logout from X blocks the graphic card, Matrox MGA 400 > and also Nvidia GeForce2 MX200 Different compilers. You have failed to narrow the problem down; here's where it might be: 1) In the configuration code 2) In the difference in the patches between the versions of the ports tree for X11 3) In the X11 libraries' handling of threads 4) In the 5.x implementation of pthreads 5) In the GCC compiler optimizer 6) In the GCC compiler code generator 7) In the X11 source code; there are certain assumptions that the new compiler makes which it was always permissable for it to make, but which the old compiler did not make, even though it was allowed to (i.e. a revealed bug in the X11 sources) 8) A bug in the AGP (/dev/agpart) code 9) A bug in the ACPI handling of monitor power-down code 10) A bug in the ACPI BIOS information of your computer itself 11) In a mismatch between kernel and kernel module versions 12) In a difference in the values of manifest constants > I doubt, that something else than OS related issues are the > cause. Doubt it all you want; from the small amount of information you have provided us, it looks to me like there is a possibility that it's 50% non-OS-releated. > Switched back to 4.7 , will try again 5.0 in few weeks. If it happens again, be sure and give us useful information, like: o Since Warner fixed the libc incompatabilities, have you installed the 4.7 version of X11 on 5.x, and does the problem still happen? o Does it happen if ACPI isn't loaded? o Does it happen with the Xvga server, or only with the accelerated server? o Are you on a laptop or a desktop? o If a desktop, does turning the monitor off and back on "fix" the problem for you? o What the checkout date for your 5.x source tree? It's unlikely that someone would be willing to spend 30 hours duplicating your test environment, but you never know... o The results of any discriminating tests for the possible causes, per the list, earlier in this email. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
On Fri, Nov 08, 2002 at 04:22:24PM -0500, Ray Kohler wrote: > > From [EMAIL PROTECTED] Fri Nov 8 16:15:05 2002 > > Date: Fri, 8 Nov 2002 13:02:58 -0800 > > From: Kris Kennaway <[EMAIL PROTECTED]> > > To: Ray Kohler <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > Subject: Re: perl5.6.1 wrapper > > > > On Fri, Nov 08, 2002 at 06:54:37AM -0500, Ray Kohler wrote: > > > > > Then we're back to the problem of there being a complete stale perl in > > > the base system after a 4.X->5.X upgrade, but then, I've always thought > > > that "clean out the cruft" ought to be a mandatory step in upgrading. > > > > Yes, it's already a mandatory step (remove old includes, or you can't > > build C++ programs). > > I mean *all* the cruft -- old modules and config files, deprecated binaries > and man pages, even old shlibs if it's safe. I agree with you, and I was giving an example that a lesser form of this is already required during the upgrade. It would be VERY useful if someone could develop a script to do this (e.g. install various versions of 4.x and do an upgrade, then collect a complete list of all the stale files). Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel not booting....Immediate crash
- Nate Lawson's Original Message - > On Thu, 7 Nov 2002, David Rhodu wrote: > > Sidcarter wrote: > > >Hi Folks, > > > > > > I just did a cvsup and installed a kernel. I have been trying this from > > > the past few days with the same error. I am copying this by hand, > > > since it crashes immediately after loading the modules. > > > The error message is here > > > > > > > > >Booting [/boot/kernel/kernel]... > > >/boot/kernel/acpi.ko text=0x30dbc data=0x1a58+0xb48 syms=[0x4+0x5770+0x4+0x73b9/]\ > > Try disabling acpi: > echo "hint.acpi.0.disable=1" >> /boot/device.hints I appear to be having the exact same problem with a new dual Xeon system. It boots 4.7 correctly. The header from a 4.7 dmesg shows: Copyright (c) 1992-2002 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 RELENG_4_7_0_RELEASE #0: Fri Nov 8 12:08:15 GMT 2002 root@:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium 4 (2791.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff,ACC,> real memory = 1073676288 (1048512K bytes) avail memory = 1039872000 (1015500K bytes) Preloaded elf kernel "kernel" at 0xc050e000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 19 entries at 0xc00f30a0 Trying to boot from a 5.0 iso fails immediately after loading the acpi.ko module. It panics with no traceback available. Breaking into the boot sequence and issuing: set hint.acpi.0.disable=1 has no effect. Any other ideas on how to boot and get 5.0 installed onto this hardware? Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> Steve Kargl <[EMAIL PROTECTED]> writes: : Here's the fun part. The following 5.0 libraries have the same : version number as their 4.x counterparts. Try running a 4.x : app linked against one of these libaries on a 5.0 machine. You : should also note that this list may not be complete list of : libraries suffering this problem. : : libalias.so.4libbz2.so.1 libcam.so.2 libcom_err.so.2 : libcrypto.so.2 libdes.so.3 libdialog.so.4 libfetch.so.3 : libftpio.so.5libg2c.so.1 libhistory.so.4 libipsec.so.1 : libisc.so.1 libkvm.so.2 libm.so.2libncp.so.1 : libncurses.so.5 libopie.so.2 libpcap.so.2 libreadline.so.4 : libsmb.so.1 libssh.so.2 libutil.so.3 You've also not listed all the package binaries that have similar problems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: On Fri, Nov 08, 2002 at 12:17:00PM -0500, Daniel Eischen wrote:
: > On Fri, 8 Nov 2002, M. Warner Losh wrote:
: >
: > >
: > > Yes, but this is too painful. If we were going to do this, the time
: > > for the pain was 6-9 months ago, not just before the release.
: >
: > All the ports are going to be rebuilt for the release anyways,
: > so this doesn't affect fresh installs, correct? It is only a
: > problem when mixing older 4.x and 5.0 libraries/binaries with
: > __sF-free libc (if I understand things correctly).
: >
: > This is 5.0; it is a major release and there will be some flies
: > in the ointment. I say bite the bullet now -- don't wait.
:
: I agree with Dan. Let's do it now. My understanding is
: that 5.0 will be an "early adopter" release and production
: systems should run 4.7{8,9,..} until 5.1 is released.
That's not a viable option. Even if 5.0 is an early adapter release,
then that would argue for keeping __sF in libc to aid in the
transition.
: To accomplish the change, I think we need to do:
: 1. Install a complete set of 4.7 shared libs in COMPAT4X.
: This should porivde the necessary runtime compatibility
: with 4.x.
That's not true. You can't mix and match 4.x and 5.x packages right now.
: 2. Bump all shared library on 5.0. This will get rid of
: any interdependencies among the libraries and it deals
: with the version number problems I detailed in the thread
: "Ghost of __sF ..." a couple a days ago.
Not a viable option. Unless you have patches that do this properly
for ports, where we are getting screwed now.
: 3. Put a big fat WARNING in src/UPDATING about the problem
Been there, done that, didn't help.
: 4. Put the same WARNING in /etc/motd, so people currently
: run -current will know to update their ports.
: 5. Broadcast the WARNING to appropriate mailing lists and
: newsgroups.
Been there, done that, didn't help.
So in short, these plans won't help anything :-(.
My plan is as follows:
1) Restore __sF to libc for 5.0.
2) Fix 4.x binaries so that __sF isn't referened in new
binaries. This should have been done in Aug 2001, but
wasn't.
Depending on how things go, __sF will be removed in 5.1 or 5.2 after
we have the transition period we had originally planned for 4.x, but
implemented a year ago.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> Daniel Eischen <[EMAIL PROTECTED]> writes: : All the ports are going to be rebuilt for the release anyways, : so this doesn't affect fresh installs, correct? It is only a : problem when mixing older 4.x and 5.0 libraries/binaries with : __sF-free libc (if I understand things correctly). The problem is that you cannot have 4.x packages and 5.x packages co-mingled on the same system. that's what I'm trying to fix. You'd have to rebuild the 4.x packages before they are fixed. : This is 5.0; it is a major release and there will be some flies : in the ointment. I say bite the bullet now -- don't wait. : If we want to provide an optional compatability hack to libc : so that folks can compile it with __sF support, then I think : that is better than leaving __sF in the release, perhaps : with a mktemp(3)-like warning if possible (?). You'd need a run-time warning for this to be effective. I'm not sure that ld.so can do this right now. This is not a fly in the pointment, but rather a major incompatibility that makes it impossible to have a reasonable mix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpid implementation?
On Wed, Nov 06, 2002 at 10:27:47PM +0100, Frode Nordahl wrote the words in effect of: > Hello, > > I have been searching mailing lists and my friend Google for information > about a acpid (like apmd) implementation for FreeBSD, but I have found > nothing. > > Does one exist anywhere, or has anyone started out on something without > telling anyone? :) Why do you need an acpid? -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
> From [EMAIL PROTECTED] Fri Nov 8 16:15:05 2002 > Date: Fri, 8 Nov 2002 13:02:58 -0800 > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Ray Kohler <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: perl5.6.1 wrapper > > On Fri, Nov 08, 2002 at 06:54:37AM -0500, Ray Kohler wrote: > > > Then we're back to the problem of there being a complete stale perl in > > the base system after a 4.X->5.X upgrade, but then, I've always thought > > that "clean out the cruft" ought to be a mandatory step in upgrading. > > Yes, it's already a mandatory step (remove old includes, or you can't > build C++ programs). I mean *all* the cruft -- old modules and config files, deprecated binaries and man pages, even old shlibs if it's safe. - @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
On Fri, Nov 08, 2002 at 06:54:37AM -0500, Ray Kohler wrote: > Then we're back to the problem of there being a complete stale perl in > the base system after a 4.X->5.X upgrade, but then, I've always thought > that "clean out the cruft" ought to be a mandatory step in upgrading. Yes, it's already a mandatory step (remove old includes, or you can't build C++ programs). Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 bootable snapshot iso availability?
Hi I have opportunity to test sparc64 installer and if time permits, OS itself for upcoming weekend. The boxes are Netra T1's with two different ethernet interfaces (2 eri and 4 qfe) and as usual SCSI disks and ATAPI cdrom. I did short sweep over sparc64 documents available online and found that ata(pi) and sysinstall aren't supported, but those times are over now I guess? From where I can download ISO image and give it a try? I don't mean to use 5.0-20021031-SNAP, sysinstall has been reworked extensively in the last days, that's it. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
phoenix works on -current!
I've sent mail to phoenix@ , but I thought I'd let this list know as well. Native phoenix works fine on -current for me, in spite of the Makefile claims. Install the perl5 port on a recent -current and phoenix will build and run perfectly. (And if it doesn't, I'm sure phoenix@ would like to know about it anyway.) - @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
Recompile your kernel with options PCI_ALLOW_UNSUPPORTED_IO_RANGE On Fri, 8 Nov 2002, Willem van Engen wrote: > Hmm, not for me (yet?). Part of dmesg: > > VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc03bb322 (122) > VESA: NVidia > VESA: NVidia Riva TNT A0 > > agp0: mem 0xe000-0xe3ff at >device 0.0 on pci0 > agp0: allocating GATT for aperture of size 256M > > nvidia0: mem 0xe600-0xe6ff,0xe400-0xe4ff irq 11 at >device 0.0 on pci1 > pcib1: device nvidia0 requested decoded memory range 0xe400-0xe4ff > pcib1: device nvidia0 requested unsupported memory range 0x0-0xe5ff (decoding >0xe400-0xe5ff, xe600-0xe6ff) > nvidia0: Unable to allocate NVIDIA memory resource. > device_probe_and_attach: nvidia0 attach returned 6 > > I had to disable the #error in nv_freebsd.h when compiling of course. > > - Willem > > > On Fri, 08 Nov 2002 14:11:08 +0100 > Juan Francisco Rodriguez Hervella <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > I've just seen the release of FreeBSD-NVIDIA driver for > > FreeBSD-4.7 > > > > Will this driver work with -CURRENT ?¿ > > > > PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203 > > > > -- > > JFRH. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
Dear Hackers, i'm replying to myself, because i think i might have found some more information on the problem. i would appreciate if any USB expert would care to comment on this. please take a look at http://www.geocities.com/m_evmenkin/usb/24505201.pdf and look for "USB Dribble" section. Let me quote it here 12. USB Dribble Issue: A USB receive packet with a bitstuff following the transmission of CRC, coupled with a dribble bit due to prop delays through cables and HUBs, may be incorrectly interpreted by the USB host controller state machine as a poorly formed EOP. Implication: The host controller response to this is a non-acknowledge with a CRC/Timeout status communicated to the software. If this condition persists, the error count associated with this packet will be exceeded and an interrupt can be generated to software. This will stall the USB device. Current software reports a device error to the user via a pop-up window. Another implication is that the installed base may have limited USB expandability via HUBs. Workaround: There are two possible workarounds. 1. Hardware: Attach the USB device into a USB port closer to the root hub. 2. Software: Detect the CRC/Timeout error and count exceeded and attempt to re-queue the packets while changing the length of the packets. Changing the length of the packets will change the CRC and thus will likely remove the combination of the two events causing the failure. Status: Fixed in B-0 stepping. Note: This erratum was carried over from the Intel® 82371EB (PIIX4E). Needless to say that i have Intel 82371AB/EB chip in my laptop *and* i'm getting CRCTO,TIMEOUT errors. all the dumps still available at http://www.geocities.com/m_evmenkin/usb/ could this be the problem? thanks, max Maksim Yevmenkin wrote: > > Dear Hackers, > > Who owns USB code in -current? I need an USB expert advice > on the FreeBSD specific USB problem. Basically whenever i > put my laptop into docking station and try to plug Bluetooth > USB dongle i get > > uhub1: device problem, disabling port 1 > > message. This problem *does not* exist when i try to > connect the USB dognle directly to the laptop. My current > theory is that extra USB hub in docking station somehow > makes the difference. I have attached few files that > might help. > > This problem is FreeBSD-specific and seems related to > Bluetooth USB dongles only. I have been contacted by other > people who have the same problem. I do not know what is so > special about Bluetooth USB dongles. USB mouse, for example, > works fine. Can it be power related? Both Windows and > Linux do not have this problem which makes me think that > there is something different about FreeBSD way of doing > things. > > Please advice. I will try to read USB spec, but if someone > could give me the right direction, that would be helpful. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, 8 Nov 2002, Juan Francisco Rodriguez Hervella wrote: > I've seen that... so, the only possibility we've got is to cry loudly at > NVIDIA people and ask them to make a driver for -CURRENT > > (I shouldn't install -CURRENT on my home computer :( I run -CURRENT on my systems (which is where I did the initial kernel driver work for this driver.) If you're clever you can edit the 1 file preventing the driver from building on -CURRENT and it will all just work. You'll note that the package detects DEVFS, which isn't a -STABLE feature. The driver works just fine on -CURRENT but don't bother NVIDIA with bug reports if you're trying to use it there. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
* Poul-Henning Kamp <[EMAIL PROTECTED]> [021108 05:29] wrote: > In message <[EMAIL PROTECTED]>, G > erald Pfeifer writes: > > >Sheesh. > > > >PHK, now we have the situation where user programs require #ifdefs > >to be portable among the BSDs when this was not required before. > > > >Please consider reverting > > That has been considered, and I don't think it is a sensible solution, > unless we can get rid of the DBREG_DRX() macro which was the cause > of the evilness: Honestly keeping it is probablly a good idea, using an acccessor macro for something like this may help us port to "near i386" arches. It might be a good idea to push Net/Open to add our macro. That way each can have thier own little nuainces but it will be masked by the macro. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CF-PCMCIA Adapter + CF-Card
Hi, > On todays Current i get on Insertion: > > pccard0: Allocation failed for cfe 0 > ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 > ad4: 61MB [490/8/32] at ata2-master BIOSPIO > > On todays Current i get on Boot: > > pccard0: Allocation failed for cfe 0 > ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 > ad0: 19077MB [41344/15/63] at ata0-master UDMA33 > ad4: READ command timeout tag=0 serv=0 - resetting > ata2: resetting devices .. > done > ad4: read interrupt arrived early > ad4: read error detected (too) late > ad4: [490/8/32] at ata2-master BIOSPIO > ad4: hard error cmd=read fsbn 104458130 of 0-3 >status=51 error=10 > ad4: 51004MB [21318/70/70] at ata2-master BIOSPIO > > at that point the kernel hangs :-) Yes, this problem was already analysed and I sent the patches to Soren and Warner. I couldn't find the patches right now, but they might still have it... Could you ask for them? I'll inform you when I can find it. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UFS2 extended attribute corruption woes
I've been dealing for some weeks now with having my system unexpectedly lock
up and be unreachable via Ctrl-Alt-Esc, and tracked it down as far as "the
daily script" or "trying to relabel the entire filesystem" until recently.
Imagine my relief when rwatson suggests to try using the serial console
instead. I sez, "You're nuts! Why would the serial console make any
difference from the syscons for trying to break to the debugger? This is
definitely a hard lock-up," I sez to Robert.
Lo and behold, I try it, and in fact I _can_ break to the debugger over the
serial console! I find out that I'm in ffs_findextattr() and in an infinite
loop. Upon further investigation, I discover that (long story short) I have
three files on my system which have completely invalid extents: one has 48
bytes of gibberish (not just a few bytes being corrupt) and two have 48
bytes of 0s. I'm not going to wonder too hard about how they got there
since I had bad RAM in the laptop for a while, but I did go ahead and fix
FFS to be more resilient.
Here are my changes to just return EIO instead of looping infinitely. Does
it seem to be correct? I've also got a change to fsck in the trustedbsd_mac
which detects and dumps corrupt extents, but I don't have it clearing and
fixing them yet. I think both are probably important to have :)
//depot/projects/trustedbsd/mac/sys/ufs/ffs/ffs_vnops.c#15 (text+ko) -
//depot/projects/trustedbsd/mac/sys/ufs/ffs/ffs_vnops.c#17 (text+ko) content
@@ -1324,11 +1324,12 @@
* the length of the EA, and possibly the pointer to the entry and to the data.
*/
static int
-ffs_findextattr(u_char *ptr, uint length, int nspace, const char *name, u_char **eap,
u_char **eac)
+ffs_findextattr(u_char *ptr, uint length, int nspace, const char *name,
+int *ealenp, u_char **eap, u_char **eac)
{
u_char *p, *pe, *pn, *p0;
- int eapad1, eapad2, ealength, ealen, nlen;
- uint32_t ul;
+ int eapad1, ealength, ealen, nlen;
+ uint32_t ul, eapad2;
pe = ptr + length;
nlen = strlen(name);
@@ -1339,16 +1340,23 @@
pn = p + ul;
/* make sure this entry is complete */
if (pn > pe)
- break;
+ return (EIO);
+ /* don't loop forever on a corrupt entry */
+ if (pn <= p)
+ return (EIO);
p += sizeof(uint32_t);
if (*p != nspace)
continue;
p++;
eapad2 = *p++;
+ /* padding is at most 7 bytes */
+ if (eapad2 >= 8)
+ return (EIO);
if (*p != nlen)
continue;
p++;
- if (bcmp(p, name, nlen))
+ /* compare only up to the end of this attribute */
+ if (p + nlen > pn || bcmp(p, name, nlen))
continue;
ealength = sizeof(uint32_t) + 3 + nlen;
eapad1 = 8 - (ealength % 8);
@@ -1361,9 +1369,10 @@
*eap = p0;
if (eac != NULL)
*eac = p;
- return (ealen);
+ *ealenp = ealen;
+ return (0);
}
- return(-1);
+ return (ENOATTR);
}
static int
@@ -1597,16 +1606,13 @@
eae = ip->i_ea_area;
easize = ip->i_ea_len;
if (strlen(ap->a_name) > 0) {
- ealen = ffs_findextattr(eae, easize,
- ap->a_attrnamespace, ap->a_name, NULL, &p);
- if (ealen >= 0) {
- error = 0;
+ error = ffs_findextattr(eae, easize,
+ ap->a_attrnamespace, ap->a_name, &ealen, NULL, &p);
+ if (error == 0) {
if (ap->a_size != NULL)
*ap->a_size = ealen;
else if (ap->a_uio != NULL)
error = uiomove(p, ealen, ap->a_uio);
- } else {
- error = ENOATTR;
}
} else {
error = 0;
@@ -1711,16 +1717,16 @@
bcopy(ip->i_ea_area, eae, ip->i_ea_len);
easize = ip->i_ea_len;
- olen = ffs_findextattr(eae, easize,
- ap->a_attrnamespace, ap->a_name, &p, NULL);
- if (olen == -1 && ealength == 0) {
- /* delete but nonexistent */
+ error = ffs_findextattr(eae, easize,
+ ap->a_attrnamespace, ap->a_name, &olen, &p, NULL);
+ if ((error == ENOATTR && ealength == 0) || /* delete but nonexistent */
+ (error != 0 && error != ENOATTR)) {/* corrupted? */
free(eae, M_TEMP);
if (stand_alone)
ffs_close_ea(ap->a_vp, 0, ap->a_cred, ap->a_td);
- return(ENOATTR);
+ return (error);
}
-if (olen == -1) {
Re: Kernel not booting....Immediate crash
On Thu, 7 Nov 2002, David Rhodu wrote: > Sidcarter wrote: > > >Hi Folks, > > > >I just did a cvsup and installed a kernel. I have been trying this from the past > >few days with the same error. I am copying this by hand, since it crashes > >immediately after loading the modules. > >The error message is here > > > > > >Booting [/boot/kernel/kernel]... > >/boot/kernel/acpi.ko text=0x30dbc data=0x1a58+0xb48 syms=[0x4+0x5770+0x4+0x73b9/]\ Try disabling acpi: echo "hint.acpi.0.disable=1" >> /boot/device.hints My IBM laptop does not work with ACPI yet. > >Fatal trap 12: page fault while in vm86 mode > >fault virtual address= 0x9fdc8 > >fault code = user read, page not present > >instruction pointer = 0xf000:0x145e > >stack pointer= 0x0:0xfb4 > >frame pointer= 0x0:0xfca > >code segment = base 0x0, limit 0x0, type 0x0 > > DPL 0, pres 0, def32, gran 0 > >processsor eflags= interrupt enabled, resume, vm86, IOPL=0 > >current process = 0 () > >kernel: type 12 trap, code=0 > >Stopped at 0x145e: addb%al,0(%eax) > >db> t > >(null)(eee06c0,1,e820,fee06c0,9775a707) at 0x145e > >db> > > > > > >uname -a > > > >FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 24 15:46:54 IST 2002 >root@calvin:/usr/obj/usr/src/sys/HOGWARTS i386 > > > >Any idea what could be wrong ? > > > >Becoz of this problem, I am also unable to do an install world as the it is looking >for sigaction in the kernel. > > > >TIA > >Regards > > Sid > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-current" in the body of the message > > > > > > > yeah, I've been getting the same thing with 4.7 and 5.0 on a few machines > > What is the type of machine you are running on? Most of mine were IBM's. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Sat, Nov 09, 2002 at 04:16:11AM +1000, Andrew Kenneth Milton wrote: > > 6. Assume Crash Position. > Thanks for your important contribution to a discussion which is addressing a rather serious problem. Here's the important part of the "Ghost..." thread. The following 4.7 libs make reference to __sF. libalias.so.4libbz2.so.1 libc.so.4libc_r.so.4 libcam.so.2 libcom_err.so.2 libcrypto.so.2 libdes.so.3 libdevstat.so.2 libdialog.so.4libedit.so.3 libfetch.so.3 libftpio.so.5libg2c.so.1 libgmp.so.3 libhistory.so.4 libipsec.so.1libisc.so.1 libkdb.so.3 libkrb.so.3 libkrb5.so.5 libkvm.so.2 libm.so.2libmp.so.3 libncp.so.1 libncurses.so.5 libopie.so.2 libpam.so.1 libpcap.so.2 libperl.so.3 libreadline.so.4 libroken.so.5 libskey.so.2 libsmb.so.1 libssh.so.2 libstdc++.so.3 libutil.so.3 Here's the fun part. The following 5.0 libraries have the same version number as their 4.x counterparts. Try running a 4.x app linked against one of these libaries on a 5.0 machine. You should also note that this list may not be complete list of libraries suffering this problem. libalias.so.4libbz2.so.1 libcam.so.2 libcom_err.so.2 libcrypto.so.2 libdes.so.3 libdialog.so.4 libfetch.so.3 libftpio.so.5libg2c.so.1 libhistory.so.4 libipsec.so.1 libisc.so.1 libkvm.so.2 libm.so.2libncp.so.1 libncurses.so.5 libopie.so.2 libpcap.so.2 libreadline.so.4 libsmb.so.1 libssh.so.2 libutil.so.3 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
+---[ Steve Kargl ]--
|
| I agree with Dan. Let's do it now. My understanding is
| that 5.0 will be an "early adopter" release and production
| systems should run 4.7{8,9,..} until 5.1 is released.
|
| To accomplish the change, I think we need to do:
| 1. Install a complete set of 4.7 shared libs in COMPAT4X.
| This should porivde the necessary runtime compatibility
| with 4.x.
| 2. Bump all shared library on 5.0. This will get rid of
| any interdependencies among the libraries and it deals
| with the version number problems I detailed in the thread
| "Ghost of __sF ..." a couple a days ago.
| 3. Put a big fat WARNING in src/UPDATING about the problem
| 4. Put the same WARNING in /etc/motd, so people currently
| run -current will know to update their ports.
| 5. Broadcast the WARNING to appropriate mailing lists and
| newsgroups.
6. Assume Crash Position.
--
Totally Holistic Enterprises Internet| | Andrew Milton
The Internet (Aust) Pty Ltd | M:+61 416 022 411 |
ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
CF-PCMCIA Adapter + CF-Card
Hi, i had a similar problem as reported by Tomi Vainio on 27.09.2002 with a CF-PCMCIA Adapter and a Sandisk 64MB CF Card with NEWCARD on a - -current of ~ 20.09.2002: (This is a Thinkpad X20) pccard0: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 pccard0: WARNING: Resource not reserved by pccard bus device_probe_and_attach: ata2 attach returned 6 On todays Current i get on Insertion: pccard0: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 ad4: 61MB [490/8/32] at ata2-master BIOSPIO On todays Current i get on Boot: pccard0: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 ad0: 19077MB [41344/15/63] at ata0-master UDMA33 ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. done ad4: read interrupt arrived early ad4: read error detected (too) late ad4: [490/8/32] at ata2-master BIOSPIO ad4: hard error cmd=read fsbn 104458130 of 0-3 status=51 error=10 ad4: 51004MB [21318/70/70] at ata2-master BIOSPIO at that point the kernel hangs :-) If i insert the card after the boot Process i can work on it without any Problems... Stephan - Stephan Holtwisch - [EMAIL PROTECTED] immutec GmbH - Mendelstraße 11 - 48149 Münster Tel: +49(0)251/980-1230 - Fax: +49(0)251/980-1231 www.immutec.com - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, Nov 08, 2002 at 12:17:00PM -0500, Daniel Eischen wrote:
> On Fri, 8 Nov 2002, M. Warner Losh wrote:
>
> >
> > Yes, but this is too painful. If we were going to do this, the time
> > for the pain was 6-9 months ago, not just before the release.
>
> All the ports are going to be rebuilt for the release anyways,
> so this doesn't affect fresh installs, correct? It is only a
> problem when mixing older 4.x and 5.0 libraries/binaries with
> __sF-free libc (if I understand things correctly).
>
> This is 5.0; it is a major release and there will be some flies
> in the ointment. I say bite the bullet now -- don't wait.
I agree with Dan. Let's do it now. My understanding is
that 5.0 will be an "early adopter" release and production
systems should run 4.7{8,9,..} until 5.1 is released.
To accomplish the change, I think we need to do:
1. Install a complete set of 4.7 shared libs in COMPAT4X.
This should porivde the necessary runtime compatibility
with 4.x.
2. Bump all shared library on 5.0. This will get rid of
any interdependencies among the libraries and it deals
with the version number problems I detailed in the thread
"Ghost of __sF ..." a couple a days ago.
3. Put a big fat WARNING in src/UPDATING about the problem
4. Put the same WARNING in /etc/motd, so people currently
run -current will know to update their ports.
5. Broadcast the WARNING to appropriate mailing lists and
newsgroups.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, 8 Nov 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Ray Kohler <[EMAIL PROTECTED]> writes: > : > From [EMAIL PROTECTED] Fri Nov 8 02:45:04 2002 > : > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST) > : > To: [EMAIL PROTECTED] > : > Subject: Re: [PATCH] note the __sF change in src/UPDATING > : > From: "M. Warner Losh" <[EMAIL PROTECTED]> > : > > : > In message: <[EMAIL PROTECTED]> > : > Ray Kohler <[EMAIL PROTECTED]> writes: > : > : Hear hear, I agree. There's no need to expose what ought to be > : > : "private" data to the world, especially when we can get the additional > : > : benefit here of letting us play with the implementation. > : > > : > -current already does this. The problem is that we're trying to shoot > : > the bad access in the head, and that is what is screwing people. So > : > the problem isn't that we're trying to export private data to the > : > world. Quite the contrary, we're trying to eliminate it and having > : > growing pains. > : > : Exactly. That's why I'm arguing against putting __sF back (or > : adopting equally crapulent measures). Growing pains are a necessary evil. > : (I also agree that we probably ought to staticize any other things of > : this nature while we're at it and get the pain over with.) > > Yes, but this is too painful. If we were going to do this, the time > for the pain was 6-9 months ago, not just before the release. All the ports are going to be rebuilt for the release anyways, so this doesn't affect fresh installs, correct? It is only a problem when mixing older 4.x and 5.0 libraries/binaries with __sF-free libc (if I understand things correctly). This is 5.0; it is a major release and there will be some flies in the ointment. I say bite the bullet now -- don't wait. If we want to provide an optional compatability hack to libc so that folks can compile it with __sF support, then I think that is better than leaving __sF in the release, perhaps with a mktemp(3)-like warning if possible (?). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
> From [EMAIL PROTECTED] Fri Nov 8 11:30:05 2002 > Date: Fri, 08 Nov 2002 09:27:32 -0700 (MST) > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [PATCH] note the __sF change in src/UPDATING > From: "M. Warner Losh" <[EMAIL PROTECTED]> > > In message: <[EMAIL PROTECTED]> > Ray Kohler <[EMAIL PROTECTED]> writes: > : > From [EMAIL PROTECTED] Fri Nov 8 02:45:04 2002 > : > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST) > : > To: [EMAIL PROTECTED] > : > Subject: Re: [PATCH] note the __sF change in src/UPDATING > : > From: "M. Warner Losh" <[EMAIL PROTECTED]> > : > > : > In message: <[EMAIL PROTECTED]> > : > Ray Kohler <[EMAIL PROTECTED]> writes: > : > : Hear hear, I agree. There's no need to expose what ought to be > : > : "private" data to the world, especially when we can get the additional > : > : benefit here of letting us play with the implementation. > : > > : > -current already does this. The problem is that we're trying to shoot > : > the bad access in the head, and that is what is screwing people. So > : > the problem isn't that we're trying to export private data to the > : > world. Quite the contrary, we're trying to eliminate it and having > : > growing pains. > : > : Exactly. That's why I'm arguing against putting __sF back (or > : adopting equally crapulent measures). Growing pains are a necessary evil. > : (I also agree that we probably ought to staticize any other things of > : this nature while we're at it and get the pain over with.) > > Yes, but this is too painful. If we were going to do this, the time > for the pain was 6-9 months ago, not just before the release. Yeah, that's true. I think unfortunately we ought to wait and do it next cycle, but when we do, do it completely and as quickly as possible. - @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
Does your kernel module load correctly? I get complaints about an unsupported memory range [see my previous post for more details]. I'm building a kernel with 'option PCI_ALLOW_UNSUPPORTED_IO_RANGE' now to see if that helps. And about __sF, could an LD_PRELOAD with a __sF 'stub' be a workaround? - Willem On Fri, 8 Nov 2002 17:30:19 +0100 Martin Faxer <[EMAIL PROTECTED]> wrote: > [ sorry for not getting the in-reply-to correct, i'm no longer > subscribed to current@ ] > > the nvidia supplied drivers appear to work fine except for libGL* > which are compiled on an older system and thus give: > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libGL.so.1: Undefined symbol > "__sF" > > any way to get around this? > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 05:43:20PM +0100, Martin Faxer wrote: > On Fri, Nov 08, 2002 at 05:30:19PM +0100, Martin Faxer wrote: > i apologize for not reading current@ a bit more :) > i found the __sF thread now :) another apology, since this is my 3rd mail in a very short period of time! however, i can inform you all that libGL works after having removed the static qualifier from __sF and recompiled libc! 13125 frames in 5.0 seconds = 2625.000 FPS 16237 frames in 5.0 seconds = 3247.400 FPS 16091 frames in 5.0 seconds = 3218.200 FPS this is on a -CURRENT from 31st oct :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 05:30:19PM +0100, Martin Faxer wrote: > [ sorry for not getting the in-reply-to correct, i'm no longer > subscribed to current@ ] > > the nvidia supplied drivers appear to work fine except for libGL* which > are compiled on an older system and thus give: > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libGL.so.1: Undefined symbol > "__sF" > > any way to get around this? i apologize for not reading current@ a bit more :) i found the __sF thread now :) i guess a temporary 'fix' will be to recompile my libc with __sF once again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
[ sorry for not getting the in-reply-to correct, i'm no longer subscribed to current@ ] the nvidia supplied drivers appear to work fine except for libGL* which are compiled on an older system and thus give: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libGL.so.1: Undefined symbol "__sF" any way to get around this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> Ray Kohler <[EMAIL PROTECTED]> writes: : > From [EMAIL PROTECTED] Fri Nov 8 02:45:04 2002 : > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST) : > To: [EMAIL PROTECTED] : > Subject: Re: [PATCH] note the __sF change in src/UPDATING : > From: "M. Warner Losh" <[EMAIL PROTECTED]> : > : > In message: <[EMAIL PROTECTED]> : > Ray Kohler <[EMAIL PROTECTED]> writes: : > : Hear hear, I agree. There's no need to expose what ought to be : > : "private" data to the world, especially when we can get the additional : > : benefit here of letting us play with the implementation. : > : > -current already does this. The problem is that we're trying to shoot : > the bad access in the head, and that is what is screwing people. So : > the problem isn't that we're trying to export private data to the : > world. Quite the contrary, we're trying to eliminate it and having : > growing pains. : : Exactly. That's why I'm arguing against putting __sF back (or : adopting equally crapulent measures). Growing pains are a necessary evil. : (I also agree that we probably ought to staticize any other things of : this nature while we're at it and get the pain over with.) Yes, but this is too painful. If we were going to do this, the time for the pain was 6-9 months ago, not just before the release. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
__printf0like not working?
Hi, I just doscovered, that the -Wformat feature does not work for warn() and err(), but works for printf() und Co. Was the __printf0like feature not patched into the actual gcc? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: > On Thu, 31 Oct 2002 12:20:14 -0500 (EST) > Daniel Eischen <[EMAIL PROTECTED]> wrote: > > > I wonder how it works for Solaris (you can see both the non-underscore > > and single-underscore symbols resolve to the same thing)? Perhaps their > > stubs in libc pull the libgcc trick? > > Solaris libc uses something called ti_jmp_table to locate pthread symbols. > Both _pthread and pthread functions resolve to the same stub which does > something like this: > > 1) fetch a function pointer from the ti_jmp_table > 2) jump to it. > > By default, ti_jump_table entries contain pointers to dummy function like > _return_zero if no threading library is loaded. When the threading library is > loaded, ti_jump_table is populated with new pointers to functions implemented > in threading library library. GDB did not allow me to track down where exactly > this happens, I presume .init function in libpthread.so does that. OK, here's a patch that uses a jump table, as well as some other fixes (use single underscore versions of pthread functions internally in libc_r, avoid cancellation points for _pthread_cond_[timed]wait, and other cleanups): http://people.freebsd.org/~deischen/libc-libc_r.diffs Can someone review and test this with GNOME? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
Hmm, not for me (yet?). Part of dmesg: VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc03bb322 (122) VESA: NVidia VESA: NVidia Riva TNT A0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 agp0: allocating GATT for aperture of size 256M nvidia0: mem 0xe600-0xe6ff,0xe400-0xe4ff irq 11 at device 0.0 on pci1 pcib1: device nvidia0 requested decoded memory range 0xe400-0xe4ff pcib1: device nvidia0 requested unsupported memory range 0x0-0xe5ff (decoding 0xe400-0xe5ff, xe600-0xe6ff) nvidia0: Unable to allocate NVIDIA memory resource. device_probe_and_attach: nvidia0 attach returned 6 I had to disable the #error in nv_freebsd.h when compiling of course. - Willem On Fri, 08 Nov 2002 14:11:08 +0100 Juan Francisco Rodriguez Hervella <[EMAIL PROTECTED]> wrote: > Hello, > > I've just seen the release of FreeBSD-NVIDIA driver for > FreeBSD-4.7 > > Will this driver work with -CURRENT ?¿ > > PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203 > > -- > JFRH. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
On Fri, 8 Nov 2002, Horen wrote: > On Thu, 7 Nov 2002, Terry Lambert wrote: > > > Horen wrote: > > > On FreeBSD 4.6 or 4.7 works, on FreeBSD 5.0 it doesn't work. > > > Don't you think it is OS related. ? > > > > THere are a lot of MS-DOS programs that won't run on FreeBSD; > > I don't think that's FreeBSD-related, I think it's the code > > doing the wrong things to run on FreeBSD. > The purpose of trying FreeBSD 5.0 was to test development code. I'm positive, few MS-DOS programs won't run on FreeBSD, probably some Mac OS 7 - 9 programs either. I'm doing nms development on unix (spec. BSD) for a very long while, didn't use it to test if MS Office will run. Now the missing facts: 4.x binaries will not run on 5.0, lib.c inconsistency. Identical XFree86 sources compiled nativly on 4.6, 4.7 and 5.0. 4.6-4.7: no problem 5.0: logout from X blocks the graphic card, Matrox MGA 400 and also Nvidia GeForce2 MX200 I doubt, that something else than OS related issues are the cause. Switched back to 4.7 , will try again 5.0 in few weeks. Thanks, -Horen > > > > > > I even installed Linux RedHat 8.0 ( gcc 3.2x ) code. It works. > > > Only on FreeBSD 5,0 , it doesn't work. > > > > Have you tried running the 4.x binaries on 5.x, or are you > > running different binaries? It could be that the code is > > broken in a way that exercises a complier error; 5.x uses a > > different compiler than 4.x. > > > > I would recommend you install the 4.x binaries on 5.x, rather > > than running 5.x binaries. > > > > If the binaries are exactly the same, then I will be willing > > to blame the OS, even though you are one of the few persons > > who are running into problems. > > > > As far as root cause analysis goes, you've given us a report > > that looks like "it doesn't work". If you can make it so that > > the only thing that has changed is the OS, then it willbe much > > easier to blame the OS. > > > > I'm still not sure that it isn't the AGP driver being different. > > > > Have you tried an unaccelerated X server? I'm talking "Xvga", > > not just turning off the acceleration in the config file... > > > > -- Terry > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setfacl requirements?
On Fri, 8 Nov 2002, Dan Pelleg wrote: > I'm trying to use setfacl - just the example that's in the manpage. All > I ever get is: setfacl: acl_get_file() failed: Operation not supported This error generally results from three cases: (1) UFS_ACL isn't enabled (2) Extended attributes aren't available on the file system (shouldn't happen for UFS2, but might happen for UFS1 if you don't have UFS_EXTATTR and appropriate configuration of EAs) (3) The file system isn't mounted with the ACL option: either -o acls (or acls in the fstab file), or more reliably, setting the "tunefs -a enable" flag in the file system configuration. > getfacl seems to work fwiw. For better or for worse, POSIX.1e defines that getfacl() will print the current file permissions as an ACL if ACLs aren't available on the file system. As such, you're probably just seeing the results of stat() printed in an ACL form. > Same results on UFS and UFS2 filesystems. I have UFS_ACL, also tried > UFS_EXTATTR. -current as of about a week ago. With UFS2, it should be sufficient to run the following command on the unmounted device: tunefs -a enable /dev/storagedevicehere and then mount the file system, which will result in ACLs being automatically enabled. As mentioned above, it is possible to set the flag using the mount -o options invocation, or via an fstab entry, but that's a lot less reliable if some sort of failure occurs, and also doesn't work well for the root file system. tunefs is the most reliable way to enable ACLs. Let us know if that doesn't work. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setfacl requirements?
Chris Faulhaber writes: > On Fri, Nov 08, 2002 at 09:38:17AM -0500, Dan Pelleg wrote: > > > > > > I'm trying to use setfacl - just the example that's in the manpage. All I > > ever get is: > > setfacl: acl_get_file() failed: Operation not supported > > > > getfacl seems to work fwiw. > > > > Same results on UFS and UFS2 filesystems. I have UFS_ACL, also tried > > UFS_EXTATTR. -current as of about a week ago. > > > > Any clue? > > > > Are ACL's enabled on the filesystem per /sys/ufs/ufs/README.acls? > No, they weren't. I somehow missed that file. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a queston about ACL acl_type_t
On Fri, Nov 08, 2002 at 11:17:39AM +0800, kai ouyang wrote: > Hi, > I am trying to understand the ACL implementation in FreeBSD-Current. I > have a question about ACL. > in "acl.h", there are some acl_type_t value macro: > /* > * Possible valid values for acl_type_t arguments. > */ > #define ACL_TYPE_ACCESS 0x > #define ACL_TYPE_DEFAULT 0x0001 > #define ACL_TYPE_AFS0x0002 > #define ACL_TYPE_CODA 0x0003 > #define ACL_TYPE_NTFS 0x0004 > #define ACL_TYPE_NWFS 0x0005 > > But I am not sure what's means. See the POSIX.1e draft[1] for detailed explanations. Basically we support access ACL's on files and directories allowing discretionary access control and default ACL's on directories which determine the default access ACL's on any files and directories created below it. > in the 'setfacl' source, I found the usage: > If we want to control a directory, > acl[ACL_TYPE_DEFAULT] = acl_get_file(filename, ACL_TYPE_DEFAULT); > if we want to sontrol a file, > acl[DEFAULT_ACL] = NULL; > Why? > What's the difference among those macros? > Why must a directory object reserve two acl_t_structs, and a file only need > one? > Because directories may have both default and access ACL's whereas files may only have access ACL's. [1] http://wt.xpilot.org/publications/posix.1e/ -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org msg46340/pgp0.pgp Description: PGP signature
Re: setfacl requirements?
On Fri, Nov 08, 2002 at 09:38:17AM -0500, Dan Pelleg wrote: > > > I'm trying to use setfacl - just the example that's in the manpage. All I > ever get is: > setfacl: acl_get_file() failed: Operation not supported > > getfacl seems to work fwiw. > > Same results on UFS and UFS2 filesystems. I have UFS_ACL, also tried > UFS_EXTATTR. -current as of about a week ago. > > Any clue? > Are ACL's enabled on the filesystem per /sys/ufs/ufs/README.acls? -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org msg46345/pgp0.pgp Description: PGP signature
setfacl requirements?
I'm trying to use setfacl - just the example that's in the manpage. All I ever get is: setfacl: acl_get_file() failed: Operation not supported getfacl seems to work fwiw. Same results on UFS and UFS2 filesystems. I have UFS_ACL, also tried UFS_EXTATTR. -current as of about a week ago. Any clue? -- Dan Pelleg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 8 14:03:12 GMT 2002 -- ===> ipfilter linking kernel.debug machdep.o(.bss+0x0): multiple definition of `physmem' vm_init.o(.bss+0x0): first defined here *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
Erik Trulsson wrote: > > On Fri, Nov 08, 2002 at 02:11:08PM +0100, Juan Francisco Rodriguez Hervella wrote: > > Hello, > > > > I've just seen the release of FreeBSD-NVIDIA driver for > > FreeBSD-4.7 > > > > Will this driver work with -CURRENT ?¿ > > > > PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203 > > The README file found at the above URL claims that: > > > FreeBSD -STABLE versions older than 4.7 and FreeBSD -CURRENT are > not supported. > > > So I guess the answer is no. > It is of course possible that it might work anyway even if NVIDIA don't > support it but since a kernel module is involved and those are generally > not portable between major releases it is not very likely it will work. > I've seen that... so, the only possibility we've got is to cry loudly at NVIDIA people and ask them to make a driver for -CURRENT (I shouldn't install -CURRENT on my home computer :( -- JFRH. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, 2002-11-08 at 23:52, Erik Trulsson wrote: > The README file found at the above URL claims that: > > > FreeBSD -STABLE versions older than 4.7 and FreeBSD -CURRENT are > not supported. > > > So I guess the answer is no. > It is of course possible that it might work anyway even if NVIDIA don't > support it but since a kernel module is involved and those are generally > not portable between major releases it is not very likely it will work. Actually it says it isn't _supported_ not it doesn't work :) The KLD consists of two parts - one is binary only, and the other has source so you can recompile it under different releases and have it work. Given that the version Matthew Dodd hacked together that used the _linux_ version of this worked in both -current and -stable I would suggest it's probably likely that it will work :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
In message <[EMAIL PROTECTED]>, G
erald Pfeifer writes:
>Sheesh.
>
>PHK, now we have the situation where user programs require #ifdefs
>to be portable among the BSDs when this was not required before.
>
>Please consider reverting
That has been considered, and I don't think it is a sensible solution,
unless we can get rid of the DBREG_DRX() macro which was the cause
of the evilness:
struct dbreg {
unsigned int dr0; /* debug address register 0 */
unsigned int dr1; /* debug address register 1 */
unsigned int dr2; /* debug address register 2 */
unsigned int dr3; /* debug address register 3 */
unsigned int dr4; /* reserved */
unsigned int dr5; /* reserved */
unsigned int dr6; /* debug status register */
unsigned int dr7; /* debug control register */
};
#define DBREG_DRX(d,x) ((&d->dr0)[x]) /* reference dr0 - dr7 by
register number */
If you tell me that DBREG_DRX is a FreeBSD only macro, then we should
nuke it and then I will not object to going back to the previous
structure definition.
--
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 02:11:08PM +0100, Juan Francisco Rodriguez Hervella wrote: > Hello, > > I've just seen the release of FreeBSD-NVIDIA driver for > FreeBSD-4.7 > > Will this driver work with -CURRENT ?¿ > > PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203 The README file found at the above URL claims that: FreeBSD -STABLE versions older than 4.7 and FreeBSD -CURRENT are not supported. So I guess the answer is no. It is of course possible that it might work anyway even if NVIDIA don't support it but since a kernel module is involved and those are generally not portable between major releases it is not very likely it will work. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
On Fri, 8 Nov 2002, Pierre Beyssac wrote: > Fine, but if included "as is" in Wine because, it will break > compatibility with Net/OpenBSD because DBREG_DRX is a FreeBSDism... > that's why I surrounded my patch with a #ifdef DBREG_DRX (which > seems cleaner than a #ifdef __FreeBSD__). Sheesh. PHK, now we have the situation where user programs require #ifdefs to be portable among the BSDs when this was not required before. Please consider reverting revision 1.28 date: 2002/10/20 20:48:56; author: phk; state: Exp; lines: +6 -9 Change the definition of the debugging registers to be an array, so that we can index into it, rather than do pointer gymnastics on a structure containing 8 elements. in src/sys/i386/include/reg.h. Gerald PS: Pierre, thanks a lot for spotting and addressing this! I certainly agree with preferring #ifdef DBREG_DRX over #ifdef __FreeBSD__. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
Hello, I've just seen the release of FreeBSD-NVIDIA driver for FreeBSD-4.7 Will this driver work with -CURRENT ?¿ PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203 -- JFRH. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
On Fri, Nov 08, 2002 at 02:04:01PM +0100, Pierre Beyssac wrote: > Fine, but if included "as is" in Wine because, it will break > compatibility with Net/OpenBSD because DBREG_DRX is a FreeBSDism... Sorry for the phrasing, remove the spurious "because" to make sense of it :) -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
On Fri, Nov 08, 2002 at 12:08:32PM +0100, Gerald Pfeifer wrote: > Unfortunately (in the sense that both of you duplicated effort), > Alfred independently came up with a similiar patch which went in as > $PORTSDIR/emulators/wine/files/patch-context_i386 > and which I already fed upstream to the Wine folks. Fine, but if included "as is" in Wine because, it will break compatibility with Net/OpenBSD because DBREG_DRX is a FreeBSDism... that's why I surrounded my patch with a #ifdef DBREG_DRX (which seems cleaner than a #ifdef __FreeBSD__). I'll send my patch with these additional explanations to Wine, then. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/secure/lib/libcrypto Makefile.inc
Upgrades from RELENG_4 and pre-"static __sF" systems should be working again. On Fri, Nov 08, 2002 at 04:47:51AM -0800, Ruslan Ermilov wrote: > ru 2002/11/08 04:47:51 PST > > Modified files: > secure/lib/libcrypto Makefile.inc > Log: > DON'T EVER PUT THIS BACK! > > Pointy hat to: obrien > > Revision ChangesPath > 1.29 +1 -1 src/secure/lib/libcrypto/Makefile.inc -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg46330/pgp0.pgp Description: PGP signature
Re: XFree
Horen <[EMAIL PROTECTED]> writes: > Posted a week ago the question, didn't get any reaction. > > Everything with current from last night works fine but killing > X or logging out ends in a black screen. No way to activate the > display without reboot. Remote login is fine. Typing blind works > too. I had similar problem when I upgraded to -current in september. I was using 800x600 VESA mode console at that time, and I found that removing SC_PIXEL_MODE from kernel, and returning back to the good old text mode solved problem for me. I have a G450. -- Krzysztof Jędruczyk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
> From [EMAIL PROTECTED] Fri Nov 8 04:15:04 2002 > To: Kris Kennaway <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: perl5.6.1 wrapper > Date: Fri, 08 Nov 2002 08:58:44 + > From: Mark Murray <[EMAIL PROTECTED]> > > IMVHO, the perl wrapper should be removed altogether, and the > perl port's "use.port" symlink-creating feature should be used > instead. > > M > > > Can someone explain why the perl wrapper needs to be hardlinked to > > perl5.6.1? > > > > The problem I am seeing is this: > > > > USE_PERL5=yes in a port adds the following BUILD_DEPENDS: > > > > enigma# make -V BUILD_DEPENDS > > perl5.6.1:/usr/ports/lang/perl5 > > > > However 5.0 has perl5.6.1 in the base system still, so this dependency > > is always satisfied, the perl port is never added and the port build > > that relies on it will fail. Then we're back to the problem of there being a complete stale perl in the base system after a 4.X->5.X upgrade, but then, I've always thought that "clean out the cruft" ought to be a mandatory step in upgrading. - @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
Doug Rabson wrote: > > It _would_ be a good idea to document any internal library > > symbols used by macros. Removing such symbols is a > > good way to break existing compiled applications. > > > > Library design involves a lot of tradeoffs. > > In the windows world, all this is handled by having a strict list of explicit > symbol exports, either in the source code using syntax extensions or with a > file supplied to the linker. I'm not sure whether binutils supports this kind > of thing but it would allow us to cut down the set of symbols exported from > libc.so. Linux does it, so binutils supports it. Linux does this for kernel modules, and for libraries. On Linux, glibc2 (or whatever it's called this morning) does not export any symbols that it uses internally. In the general case, it's better to eat some small amount of overhead, than to export a data interface. Note that data interfaces get in the way of the LGPL "relink" clause for shared libraries. For example, if you had a GPL'ed program that was written in Modula 3 or FORTRAN 95, that had a reference to the __sF, then distribution of that program would demand distribution of the intermediate library source code, where normally it would not be required, due to the "relink clause" not being satisfied, since an attempt to link against the 5.0 libc would fail. Data interfaces are a pain in the ass legally, as well as making your code not work. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
> From [EMAIL PROTECTED] Fri Nov 8 02:45:04 2002 > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST) > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] note the __sF change in src/UPDATING > From: "M. Warner Losh" <[EMAIL PROTECTED]> > > In message: <[EMAIL PROTECTED]> > Ray Kohler <[EMAIL PROTECTED]> writes: > : Hear hear, I agree. There's no need to expose what ought to be > : "private" data to the world, especially when we can get the additional > : benefit here of letting us play with the implementation. > > -current already does this. The problem is that we're trying to shoot > the bad access in the head, and that is what is screwing people. So > the problem isn't that we're trying to export private data to the > world. Quite the contrary, we're trying to eliminate it and having > growing pains. Exactly. That's why I'm arguing against putting __sF back (or adopting equally crapulent measures). Growing pains are a necessary evil. (I also agree that we probably ought to staticize any other things of this nature while we're at it and get the pain over with.) - @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 8 03:05:22 PST 2002 -- >>> Kernel build for GENERIC completed on Fri Nov 8 03:35:41 PST 2002 -- >>> Kernel build for LINT started on Fri Nov 8 03:35:41 PST 2002 -- ===> vinum "Makefile", line 4406: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
Horen wrote: > On FreeBSD 4.6 or 4.7 works, on FreeBSD 5.0 it doesn't work. > Don't you think it is OS related. ? > > I even installed Linux RedHat 8.0 ( gcc 3.2x ) code. It works. > Only on FreeBSD 5,0 , it doesn't work. Install X from FreeBSD 4.6 or 4.7 on FreeBSD 5.0... plain enough? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
On Fri, 8 Nov 2002, Pierre Beyssac wrote: >> As for source compatibility, just use the DBREG_DRX macro, which exists >> in both -STABLE and -CURRENT (it was merged into -STABLE two years ago). > It's too bad source compatibility hasn't been preserved. Indeed. > Argument d is not properly parenthesized, I'll commit the following > patch if nobody objects: > > - #define DBREG_DRX(d,x) (d->dr[(x)]) /* reference dr0 - dr7 by > - register number */ > + #define DBREG_DRX(d,x) ((d)->dr[(x)]) /* reference dr0 - dr7 by > + register number */ Alfred committed this very patch last night: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/reg.h > Now for Gerald and Krzysztof, could you try the attached patch? Works > for me under current at least. I'll test it under stable then I'll send > it to Wine. Yes, this looks fine. Unfortunately (in the sense that both of you duplicated effort), Alfred independently came up with a similiar patch which went in as $PORTSDIR/emulators/wine/files/patch-context_i386 and which I already fed upstream to the Wine folks. Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
On Thu, Nov 07, 2002 at 05:02:14PM -0800, Terry Lambert wrote: > Horen wrote: > > > You stated "Typing blind starts X again". > > > > > > Can you tell us what you mean by this? > > > > > > o It restarts X, as if you typed "startx" > > > > Exactly that. > > The problem is clearly in the X11 code, then, since it is not > resetting the card to the video mode it was in before X started. > > You would do well to look at the XFree86 mailing list archives, > since your answer is likely to be there (this is not a FreeBSD > specific problem, if it is not happening because of FreeBSD > specific code). > > The only possible way this could be a FreeBSD specific problem > is if you were using, e.g., the AGP driver, and it wasn't working. I have exactly the same problem with 2 Millenium cards on an HX chipset board (Socket 7) - no AGP. But my XFree is rather old 4.2.0_1,1 from 16th Jun and I also prefer not to restart my xsessions so I never mentioned. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
On Wed, Oct 30, 2002 at 05:29:39PM +0100, Dag-Erling Smorgrav wrote:
> That revision doesn't change the structure, just how it is defined, so
> binary compatibility is not an issue. As for source compatibility,
> just use the DBREG_DRX macro, which exists in both -STABLE and
> -CURRENT (it was merged into -STABLE two years ago).
It's too bad source compatibility hasn't been preserved. This macro
is a real PITA to use with a static structure (see my Wine patch
below).
Argument d is not properly parenthesized, I'll commit the following
patch if nobody objects:
- #define DBREG_DRX(d,x) (d->dr[(x)]) /* reference dr0 - dr7 by
- register number */
+ #define DBREG_DRX(d,x) ((d)->dr[(x)]) /* reference dr0 - dr7 by
+ register number */
Now for Gerald and Krzysztof, could you try the attached patch?
Works for me under current at least. I'll test it under stable then
I'll send it to Wine.
--
Pierre Beyssac [EMAIL PROTECTED] [EMAIL PROTECTED]
Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED]
--- context_i386.c.orig Wed Aug 14 22:59:03 2002
+++ context_i386.c Fri Nov 8 11:29:34 2002
@@ -373,6 +373,15 @@
struct dbreg dbregs;
if (ptrace( PTRACE_GETDBREGS, pid, (caddr_t) &dbregs, 0 ) == -1)
goto error;
+#ifdef DBREG_DRX
+ /* needed for FreeBSD, the structure fields have changed under 5.x */
+ context->Dr0 = DBREG_DRX((&dbregs), 0);
+ context->Dr1 = DBREG_DRX((&dbregs), 1);
+ context->Dr2 = DBREG_DRX((&dbregs), 2);
+ context->Dr3 = DBREG_DRX((&dbregs), 3);
+ context->Dr6 = DBREG_DRX((&dbregs), 6);
+ context->Dr7 = DBREG_DRX((&dbregs), 7);
+#else
context->Dr0 = dbregs.dr0;
context->Dr1 = dbregs.dr1;
context->Dr2 = dbregs.dr2;
@@ -380,6 +389,8 @@
context->Dr6 = dbregs.dr6;
context->Dr7 = dbregs.dr7;
#endif
+
+#endif
}
if (flags & CONTEXT_FLOATING_POINT)
{
@@ -437,6 +448,17 @@
{
#ifdef PTRACE_SETDBREGS
struct dbreg dbregs;
+#ifdef DBREG_DRX
+ /* needed for FreeBSD, the structure fields have changed under 5.x */
+ DBREG_DRX((&dbregs), 0) = context->Dr0;
+ DBREG_DRX((&dbregs), 1) = context->Dr1;
+ DBREG_DRX((&dbregs), 2) = context->Dr2;
+ DBREG_DRX((&dbregs), 3) = context->Dr3;
+ DBREG_DRX((&dbregs), 4) = 0;
+ DBREG_DRX((&dbregs), 5) = 0;
+ DBREG_DRX((&dbregs), 6) = context->Dr6;
+ DBREG_DRX((&dbregs), 7) = context->Dr7;
+#else
dbregs.dr0 = context->Dr0;
dbregs.dr1 = context->Dr1;
dbregs.dr2 = context->Dr2;
@@ -445,6 +467,7 @@
dbregs.dr5 = 0;
dbregs.dr6 = context->Dr6;
dbregs.dr7 = context->Dr7;
+#endif
if (ptrace( PTRACE_SETDBREGS, pid, (caddr_t) &dbregs, 0 ) == -1)
goto error;
#endif
Deadlock during buildworld
Hi all, for months now I've been having a reproducible hang under load (make -j4 buildworld on a uniprocessor with plenty of RAM). I transcribed some info which might be useful to debug it; it seems to me this is a deadlock (am I right?). I'll leave the laptop in ddb so I can provide more info. This is last week current; I had seen a few commits I thought might fix this but no. db> show locked Locked vnodes 0xc202ca68: tag ufs, type VDIR, usecont 1, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53304 ino 31744, on dev ad2s2f (4, 16) 0xc27e04a0: tag ufs, type VREG, usecount 18, writecount 0, refcount 1, flags (VV_TEXT|VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53301 with 3 pending ino 87582, on dev ad2s2f (4, 16) 0xc2c13940: tag ufs, type VREG, usecount 18, writecount 0, refcount 1, flags (VV_TEXT|VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53302 with 3 pending ino 33113, on dev ad2s2f (4, 16) db> trace 53301 mi_switch(c303f340,44,0,0,0) at mi_switch+0x15e msleep(c0d260b4,c03aece8,44,c0349f69,0) at msleep+0x4e1 acquire(c0d260b4,100,600,c0d26078,d035) at acquire+0xa7 lockmgr(...) at lockmgt+0x3c8 _vm_map_lock(...) at _vm_map_lock+0x32 kmem_free_wakeup(...) at kmem_free_wakeup+0x2a execve syscall Xint080_syscall --- syscall(0, FreeBSD ELF32, nosys), eip = 0x80480c0, esp = 0xbfbff8dc, ebp = 0 db> trace 53302 mi_switch(c1f77a90,44,0,0,0) at mi_switch+0x15e msleep(c0d260b4,c03aece8,44,c0349f69,0) at msleep+0x4e1 acquire(c0d260b4,100,600,c0d26078,d035) at acquire+0xa7 lockmgr(...) at lockmgt+0x3c8 _vm_map_lock(...) at _vm_map_lock+0x32 kmem_free_wakeup(...) at kmem_free_wakeup+0x2a execve syscall Xint080_syscall --- syscall(0, FreeBSD ELF32, nosys), eip = 0x80480c0, esp = 0xbfbff8dc, ebp = 0 db> trace 53304 mi_switch(c22aa8f0,50,0,1000,0) at mi_switch+0x15e msleep(c2c13a04,c03af920,50,c0348e2f,0) at msleep+0x4e1 acquire(c2c13a04,140,600,c201b6f0,d035) at acquire+0xa7 lockmgr(...) at lockmgt+0x3c8 vop_stdlock(...) at vop_stdlock+0x2c ufs_vnoperate(...) at ufs_vnoperate+0x18 vn_lock(...) at vn_lock+0x11e vget(...) at vget+0x100 vfs_cache_lookup(...) at vfs_cache_lookup+0x1ed ufs_vnoperate(...) at ufs_vnoperate+0x18 lookup(...) at lookup+0x302 namei(...) at namei+0x20b execve syscall Xint080_syscall --- syscall(0, FreeBSD ELF32, nosys), eip = 0x80480c0, esp = 0xbfbff8dc, ebp = 0 Bye, Andrea To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Thursday 07 November 2002 9:42 pm, Tim Kientzle wrote: > Terry Lambert asked: > > Any chance we could get rid of all externally visable symbols that > > are not defined as being there by some standard, and not just __sF, > > since we are breaking the FORTRAN compiler and other third party > > code already? > > This cannot be entirely done if you still want to > manage library bloat. In short, library routines > have shared interfaces between them---common variables > or common functions---that are internal to the library > and should not be used by applications. > > To avoid this, you would have to bundle library functions > together, which causes bloat. Worse, you would have to > avoid or drastically limit your use of macros. (Any > macro that uses one of these internal symbols generates > a dependency in the compiled application.) > > It _would_ be a good idea to document any internal library > symbols used by macros. Removing such symbols is a > good way to break existing compiled applications. > > Library design involves a lot of tradeoffs. In the windows world, all this is handled by having a strict list of explicit symbol exports, either in the source code using syntax extensions or with a file supplied to the linker. I'm not sure whether binutils supports this kind of thing but it would allow us to cut down the set of symbols exported from libc.so. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
