Re: fdisk issues?
On Mon, 13 Jan 2003, Bruce Evans wrote: On Sun, 12 Jan 2003, Nate Lawson wrote: On Sun, 12 Jan 2003, Sean Kelly wrote: edgemaster# fdisk ad1 Floating exception (core dumped) ... The more important question is who in the kernel is setting these to 0? as that part needs work too. Well, fdisk itself sets these to 0. The ioctls to get the number of heads and sectors may fail because they are unimplemented, and then the sloppy error handling in the code quoted above bites. It divides if the DIOCGMEDIASIZE ioctl succeeded, but a divisor is 0 if the earlier head or sector ioctl failed. The head and/or sector counts are only statically initialized to 0 in this case, since the fallback which set them to 1 was axed. This explains Sean's case. He was not using GEOM (see his original mail). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cvsweb
Hi All, Has the cvs website stopped updating itself? http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/ is showing ver 1.131 of todo.sgml but http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml is showing ver 1.120 I was using it to see the progress up to 5.0, quite handy. Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Sun, 12 Jan 2003, Marcel Moolenaar wrote:
On Sun, Jan 12, 2003 at 06:27:00PM -0800, Terry Lambert wrote:
Therefore, it seems to me, that the correct place to put them is in
the machine/floatingpoint.h header (the other alternative was the
machine/ieeefp.h header; this seemed wrong to me, but I'm willing
to reroll the patch, if there's a lot of disagreement over this point).
I would like to see it in machine/ieeefp.h:
I wouldn't like to see it moved.
The synopsis section of our manpage clearly states the inclusion
of ieeefp.h. That header file includes a machine dependent
counterpart machine/ieeefp.h. On alpha, ia64 and sparc64
machine/floatingpoint.h is empty with the exception of the
inclusion of machine/ieeefp.h.
Hence, I would like to see the prototypes and/or implementation
in machine/ieeefp.h.
The prototypes are machine-independent, so they are correctly placed
in ieeefp.h. This has the technical problem that it is difficult
to implement declared functions as inlines (*), so we use an ugly
i386 ifdef in ieefp.h to prevent them being declared. This seems
least evil since inlining them doesn't seem to be useful and the
wart only affects i386's, and these functions should be obsoleted
by the C99 functions as soon as possible.
%%%
(*) The folling implementations don't work:
(1)
int foo(int x);
static /* inline */ int foo(int x) { return x; }
This is not conforming C IIRC. TenDRA says:
z.c, line 2: Warning:
[ISO 6.1.2.2]: 'foo' previously declared with external linkage (at line 1).
(Since this is only a warning, I'm not sure that it is an error.)
(2)
static /* inline */ int foo(int x) { return x; }
int foo(int x);
This is conforming C, but helpful compilers warn about it with certain
warning flags:
z.c:2: warning: redundant redeclaration of `foo' in same scope
z.c:1: warning: previous declaration of `foo'
%%%
Since on i386 machine/floatingpoint.h
also includes machine/ieeefp.h, we should be able to move
the implementation on i386 to machine/ieeefp.h as well. If
possible, I'd like to see machine/floatingpoint.h retired
unless there's a compelling reason to keep it...
There is no good reason for these to be separate, but they may be
required for compatibility. IIRC, their names and interfaces were
copied from some system (Sun) that had them, but they were slightly
misplaced (machine is a BSDism AFAIK so other systems couldn't have
anything there)... According to google, floatingpoint.h was in
/usr/include in SunOS in 1992 (we link it there), and it seems to
be the primary interface (Sun apparently had ieeefp.h in sys then,
but non-BSD hits on it are not as common.
So we seem to have headers half compatible with at least the old version
of SunOS that they attempt to be compatible with:
- We have floatingpoint.h as a primary interface on i386's only. It
doesn't quite work on other arches since it doesn't include ieeefp.h.
- We implement floatingpoint.h as a link to machine/floatingpoint.h
to get the MD and implementation details right and the MI details wrong.
Perhaps the broken ports include this and not machine/floatingpoint.h.
Then they would be less broken.
- We also have ieeefp.h as a primary interface which works on all arches,
and our man pages say to use this.
- Applications can easily shoot there feet off by stepping into this header
tangle in any place except the one that is actually docuemented under
FreeBSD.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Sun, 12 Jan 2003, Terry Lambert wrote: This patch also affects the IA64 and Alpha, as well as just the SPARC. It took a lot of discussion, but it seems to me that the problem is that the prototypes in scope aren't in scope when the wrong include file is included. Right. It is mainly an application bug like I said. The prototypes also aren't in scope when stdio.h is included, and the fix is not to add them to stdio.h. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Mon, Jan 13, 2003 at 07:59:30PM +1100, Bruce Evans wrote: The synopsis section of our manpage clearly states the inclusion of ieeefp.h. That header file includes a machine dependent counterpart machine/ieeefp.h. On alpha, ia64 and sparc64 machine/floatingpoint.h is empty with the exception of the inclusion of machine/ieeefp.h. Hence, I would like to see the prototypes and/or implementation in machine/ieeefp.h. The prototypes are machine-independent, so they are correctly placed in ieeefp.h. Agreed in principle, not in practice. This has the technical problem that it is difficult to implement declared functions as inlines (*), so we use an ugly i386 ifdef in ieefp.h to prevent them being declared. This seems least evil since inlining them doesn't seem to be useful and the wart only affects i386's, and these functions should be obsoleted by the C99 functions as soon as possible. This part is what makes me opt for moving the prototypes to the MD header. These functions are trivial most of the time that inlining them makes sense. I don't see why other platforms can't or won't inline in the future. What about signaling the MI header about the existence (or non- existence) of inline functions and/or macros in the MD header so that the MI header can optionally provide the prototypes? This can be done by having the MD header define (or undefine) some macro (or set of macros). Also, it appears to me that we always have to provide non-inlined versions in libc for when inlining is disabled. See ctype.h. I may misinterpret the comment though... Since on i386 machine/floatingpoint.h also includes machine/ieeefp.h, we should be able to move the implementation on i386 to machine/ieeefp.h as well. If possible, I'd like to see machine/floatingpoint.h retired unless there's a compelling reason to keep it... There is no good reason for these to be separate, but they may be required for compatibility. It appears to be mostly a FreeBSD-ism in its current form. Both NetBSD and OpenBSD resist having it. Maybe the newer platforms should just remove it before it grows code... Anyone object to remove the header on at least sparc64 and ia64? (powerpc doesn't have it -- keep it that way :-) Am I right when I say that removing floatingpoint.h (both the MD file and the MI link) will fix the port, independent of how we shape ieeefp.h? - We implement floatingpoint.h as a link to machine/floatingpoint.h to get the MD and implementation details right and the MI details wrong. Perhaps the broken ports include this and not machine/floatingpoint.h. Then they would be less broken. Some configure scripts may check for floatingpoint.h for compatibility with SunOS/Solaris. I doubt they will check machine/floatingpoint.h In summary: I like Terry's second patch but am sensitive to having the MI prototypes in ieeefp.h as well as allowing inlining. What about something like the following to keep the prototypes in ieeefp.h, but still allow inlining (in combination with Terrys patch): Index: ieeefp.h === RCS file: /home/ncvs/src/include/ieeefp.h,v retrieving revision 1.6 diff -u -r1.6 ieeefp.h --- ieeefp.h23 Mar 2002 17:24:53 - 1.6 +++ ieeefp.h13 Jan 2003 09:59:08 - @@ -12,9 +12,9 @@ #include sys/cdefs.h #include machine/ieeefp.h -#ifdef __i386__ -#include machine/floatingpoint.h -#else /* !__i386__ */ +#if !defined(_IEEEFP_INLINED_) __BEGIN_DECLS extern fp_rnd_tfpgetround(void); extern fp_rnd_tfpsetround(fp_rnd_t); @@ -23,6 +23,6 @@ extern fp_except_t fpgetsticky(void); extern fp_except_t fpsetsticky(fp_except_t); __END_DECLS -#endif /* __i386__ */ +#endif /* !_IEEEFP_INLINED */ #endif /* _IEEEFP_H_ */ -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
On Sun, 12 Jan 2003 20:35:41 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: Could your Zip disk be missing or bad? Usually I don't have a zip disk in the drive at boot time... I give it a try (tomorrow). I've tried both here, works just fine on a newly compiled current It seems I have no luck... not even that you can't reproduce the tagged queueing problem, you also can't reproduce this problem. Whats wrong with my system? :-( I've tried with a disk in the drive, same behavior. I'm going to update to todays sources, and start from a clean kernel compile directory... let's see how far I get then. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
It seems Alexander Leidinger wrote: On Sun, 12 Jan 2003 20:35:41 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: Could your Zip disk be missing or bad? Usually I don't have a zip disk in the drive at boot time... I give it a try (tomorrow). I've tried both here, works just fine on a newly compiled current It seems I have no luck... not even that you can't reproduce the tagged queueing problem, you also can't reproduce this problem. Whats wrong with my system? :-( Dunno, but it is the 13'th today :) I've tried with a disk in the drive, same behavior. I'm going to update to todays sources, and start from a clean kernel compile directory... let's see how far I get then. Form a system compile from source 0800 today: ad0: 13042MB IBM-DPTA-371360 [26500/16/63] at ata0-master UDMA33 afd0: 96MB IOMEGA ZIP 100 ATAPI [32/64/96] at ata0-slave PIO0 acd0: CD-RW Hewlett-Packard DVD Writer 100 at ata1-slave PIO4 pst0: 17385MB PROMISE TECH. I2O RAID DEVICE [2216/255/63] on pstpci0 Mounting root from ufs:/dev/ad0a Thats without media in the ZIP drive, boots just fine, system in VIA 694 based so that should give me enough trouble :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
On Mon, 13 Jan 2003 11:51:20 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: It seems I have no luck... not even that you can't reproduce the tagged queueing problem, you also can't reproduce this problem. Whats wrong with my system? :-( Dunno, but it is the 13'th today :) I don't have a problem with this date: calendar -f /usr/share/calendar/calendar.freebsd -t 13.03 My hope is a stale dependency for sys... I'm going to cvsup now. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
I would like to point to a currently unresolved issue that Thomas Moestl is helping me solve on freebsd-sparc@. It isn't listed on the Open Issues page, but I'd say it's something that needs to be resolved before the release is rolled. The thread is titled panic: trap: fast data access mmu miss and is about an error causing the sym SCSI controller to fail to mount root at best, and panic at worst. The sym controller is listed as supported hardware, and used in several Sun boxes, so IMHO I'd say it warrants the attention. Regards, Roderick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Mon, 13 Jan 2003, Marcel Moolenaar wrote: On Mon, Jan 13, 2003 at 07:59:30PM +1100, Bruce Evans wrote: The synopsis section of our manpage clearly states the inclusion of ieeefp.h. That header file includes a machine dependent counterpart machine/ieeefp.h. On alpha, ia64 and sparc64 machine/floatingpoint.h is empty with the exception of the inclusion of machine/ieeefp.h. Hence, I would like to see the prototypes and/or implementation in machine/ieeefp.h. The prototypes are machine-independent, so they are correctly placed in ieeefp.h. Agreed in principle, not in practice. This has the technical problem that it is difficult to implement declared functions as inlines (*), so we use an ugly i386 ifdef in ieefp.h to prevent them being declared. This seems least evil since inlining them doesn't seem to be useful and the wart only affects i386's, and these functions should be obsoleted by the C99 functions as soon as possible. This part is what makes me opt for moving the prototypes to the MD header. These functions are trivial most of the time that inlining them makes sense. I don't see why other platforms can't or won't inline in the future. Hand-inlining things rarely makes sense, especially for little-used compatibility-cruft functions like these. A technical reason for not inlining some of them is that they may need to interact with signal handling. We currently avoid most signal-handling problems related to changing the FP environment by switching the critical part of the environment in setjmp/longjmp, at least on i386's, but C99 seems to forbid this. I think the functions that change the FP environment need to save their setting somehwere so that longjmp() can restore the default FP environment (not necessarily the one when setjmp() was called). I don't know how to do this properly reentrantly. What about signaling the MI header about the existence (or non- existence) of inline functions and/or macros in the MD header so that the MI header can optionally provide the prototypes? This can be done by having the MD header define (or undefine) some macro (or set of macros). I'd like to have a simple general way to do this, but don't care about it for these functions. Also, it appears to me that we always have to provide non-inlined versions in libc for when inlining is disabled. See ctype.h. I may misinterpret the comment though... Non-inline versions are needed for at least calling functions through function pointers if this is supported, and C requires it to be supported for most functions including the ctype 1's. This requirement causes some of the implementation complications in ctype.h. Since on i386 machine/floatingpoint.h also includes machine/ieeefp.h, we should be able to move the implementation on i386 to machine/ieeefp.h as well. If possible, I'd like to see machine/floatingpoint.h retired unless there's a compelling reason to keep it... There is no good reason for these to be separate, but they may be required for compatibility. It appears to be mostly a FreeBSD-ism in its current form. Both NetBSD and OpenBSD resist having it. Maybe the newer platforms should just remove it before it grows code... That makes sense. floatingpoint.h was added to FreeBSD in 1993/08 (before FreeBSD-1.0R) and never picked up by OtherBSD. ieeefp.h in NetBSD seems to date from 1995/04. ieeefp.h was added to FreeBSD at the same time as floatingpoint.h. It was originally in a Sun- compatible place (sys/ieeefp.h), but had mostly-wrong contents (i386 bits). sys may be MD in SunOS but it isn't in BSD. This was fixed in FreeBSD-2 by moving it to machine. Anyone object to remove the header on at least sparc64 and ia64? (powerpc doesn't have it -- keep it that way :-) Not me. Then sparc64 and ia64 will give even better early warnings of broken ports :-). Am I right when I say that removing floatingpoint.h (both the MD file and the MI link) will fix the port, independent of how we shape ieeefp.h? - We implement floatingpoint.h as a link to machine/floatingpoint.h to get the MD and implementation details right and the MI details wrong. Perhaps the broken ports include this and not machine/floatingpoint.h. Then they would be less broken. Some configure scripts may check for floatingpoint.h for compatibility with SunOS/Solaris. I doubt they will check machine/floatingpoint.h That's a good reason not to have it. Hopefully its nonexistence in OtherBSD has resulted in its use being correctly configured. However, I suspect most uses in ports are in hard-coded FreeBSD patches. This is confirmed by grepping for floatingpoint\.h and ieeefp\.h in ncvs/ports. In summary: I like Terry's second patch but am sensitive to having the MI prototypes in ieeefp.h as well as allowing inlining. What about something like the following to keep the prototypes in ieeefp.h, but still allow inlining (in combination
Re: world broken at libkvm
On 2003-01-12 20:14, [EMAIL PROTECTED] (Joe Laughlin) wrote: walt wrote: cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:376: structure has no member named `ke_pctcpu' Myself and two others have seen this as well. I'm building world trying to track the commit that broke things now. It looks like the following commit could be the one that broke things: src/sys/kern/sched_4bsd.c,v revision 1.8 date: 2003/01/12 19:04:49; author: jeff; state: Exp; lines: +30 -15 - Move ke_pctcpu and ke_cpticks into the scheduler specific datastructure. This will prevent access through mechanisms other than the published interfaces. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
In message [EMAIL PROTECTED], Roderick van Domburg writes: I would like to point to a currently unresolved issue that Thomas Moestl is helping me solve on freebsd-sparc@. It isn't listed on the Open Issues page, but I'd say it's something that needs to be resolved before the release is rolled. The thread is titled panic: trap: fast data access mmu miss and is about an error causing the sym SCSI controller to fail to mount root at best, and panic at worst. Well, we all want our pet bug fixed before the release rolls, but at some point we simply have to call it quits and ship the release. I personally know this particular bug very well, I have rebooted the AC/DC200 netra I had borrowed about 10 times more than I needed to to get past this bug :-) The sym controller is listed as supported hardware, and used in several Sun boxes, so IMHO I'd say it warrants the attention. All bugs warrent attention. Some of them get it. Don't worry, that bug, like all the others will get fixed and you will be able to get an update for it in due time. In the meantime we _really_ have to ship 5.0-RELEASE, we keep slipping it. -- 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
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 Mon Jan 13 03:04:19 PST 2003 -- Kernel build for GENERIC completed on Mon Jan 13 03:36:48 PST 2003 -- Kernel build for LINT started on Mon Jan 13 03:36:48 PST 2003 -- === vinum Makefile, line 4445: warning: duplicate script for target geom_bsd.o [...] /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...] /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...] /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...] cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] *** 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
FAST_IPSEC/racoon vs CISCO PIX anyone?
Hi, Problems interworking this combination, with ESP tunnel. SA gets negotiated OK, but ESP packets get rejected by the PIX: it says host not found a.b.c.d where a.b.c.d is its own endpoint address, and sends invalid SPI back to our end, even thought the SPI on the rejected ESP packet is the one just negitiated. This is RC2, racoon-20021120a. FWIW the same problem occurs on 4.7 with 'ordinary' IPSEC too. Any suggestions? TIA -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata timeouts until setting hw.ata.wc to zero
Fritz Heinrichmeyer wrote: last week i was in fear of a complete data loss as my freebsd current system freezed with ata ad0 timeout like this. kernel: ad0: READ command timeout tag=0 serv=0 - resetting For now it seems we have a non freebsd related hardware problem here ... Sorry for the noise. -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken at libkvm
Make sure you have rev 1.289 of sys/sys/proc.h, which is expected to fix the problem you're reporting. Ciao, Sheldon. - Original Message - Date: Sun, 12 Jan 2003 18:14:51 -0800 From: walt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: world broken at libkvm cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:376: structure has no member named `ke_pctcpu' 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: ATA seems to lock up the system at boot (KT133A)
On Mon, 13 Jan 2003 11:51:20 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: Thats without media in the ZIP drive, boots just fine, system in VIA 694 based so that should give me enough trouble :) I tried with recent sources and a clean (make clean; make clean; make cleandir; make cleandir; make depend make -j 4 make install) kernel compile directory. No luck. :-( After disabling the second channel - where the zip drive is attached to - in the BIOS, the system doesn't hang at boot. Anything I can do to find the cause? Bye, Alexander. -- Yes, I've heard of decaf. What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
On Mon, Jan 13, 2003 at 11:47:14AM +0100, Alexander Leidinger wrote: On Sun, 12 Jan 2003 20:35:41 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: Could your Zip disk be missing or bad? Usually I don't have a zip disk in the drive at boot time... I give it a try (tomorrow). I've tried both here, works just fine on a newly compiled current I have a LS120 atapi-drive here that doesn't work under FreeBSD if it's the master on it's channel but works fine if it's a slave to a = UDMA33 hd (the fact that it doesn't work when being slave to UDMA33 may also mean that that it doesn't work on 80-pin cables). Depending on the FreeBSD- version it goes awry when getting probed or probes but doesn't work afterwards. I noticed it first on 4-stable after a larger ata-code merge (it worked happily before) a half year ago or so, I dropped Soeren a note but no reaction. The difference between the configurations you and Soeren posted is also that you are running the atapi ZIP-drive as master and Soeren as slave, so maybe this could be a hint that something goes wrong with initialisation when atapi floppy-drives are attached as masters. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems installing apps that use a Java installer
Ive been trying to install JBuilder 7 and Weblogic 7 and have been having no luck. Both apps extract themselves and then try to use their own JDK to start the installer, however they both then seg fault. I tried running the 'java' that they include and found that it is the cause of the seg fault. I was able to get JBuilder installed by replacing its JDK with the FreeBSD port. However I still have not been able to get Weblogic to install. I do have the BSD JDK port, 1.3.1-p7, installed and it works fine. Any ideas what would cause these Java installers using their own JDK to seg fault all the time? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC2/if_awi.ko doesn't load
Jun Kuriyama [EMAIL PROTECTED] writes:
At Fri, 10 Jan 2003 00:33:47 + (UTC),
Nicolas Christin wrote:
I just tried to give a shot to 5.0-RC2 on an old box of mine that can
only perform network installs (no CD drive). During the boot process, a
module failed to load.
DEBUG: Loading module if_awi.ko (BayStack 660 and others)
link_elf: symbol rc4_init undefined
I got same result on today's snapshot of HEAD (20030113-JPSNAP). I'm
using {kern,mfsroot}.flp and FTP installation.
Same here on an old box with a PCI/ISA MB w/P100 CPU, but booting RC2
from floppies and installing from CDROM. The machine will boot Linux
off CDROM, but neither 4.7-RELEASE or 5.0-RC2 (a design decision to not
support older CDROM drive booting, rumor has it). :(
But got this message in a popup box:
Loading module if_awi.ko failed
BayStack 660 and others
Didn't get the link_elf: line. Installation continued until trying
to load software from CDROM after which this appeared:
Error mounting /dev/acd0 on /dist: \
Operation not supported by device (19)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
It seems [EMAIL PROTECTED] wrote: posted is also that you are running the atapi ZIP-drive as master and Soeren as slave, so maybe this could be a hint that something goes wrong with initialisation when atapi floppy-drives are attached as masters. That makes no difference I still cant get it to fail :( acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 13042MB IBM-DPTA-371360 [26500/16/63] at ata0-master UDMA66 afd0: 96MB IOMEGA ZIP 100 ATAPI [32/64/96] at ata1-master PIO0 Mounting root from ufs:/dev/ad0a -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FAST_IPSEC/racoon vs CISCO PIX anyone?
Bob Bishop wrote: Hi, Problems interworking this combination, with ESP tunnel. SA gets negotiated OK, but ESP packets get rejected by the PIX: it says host not found a.b.c.d where a.b.c.d is its own endpoint address, and sends invalid SPI back to our end, even thought the SPI on the rejected ESP packet is the one just negitiated. This is RC2, racoon-20021120a. FWIW the same problem occurs on 4.7 with 'ordinary' IPSEC too. Any suggestions? TIA Well, this question can be silly, specially if you have already established tunnels before, but... Did you negotiate a SA for each direction? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It was one of those perfect summer days -- the sun was shining, a breeze was blowing, the birds were singing, and the lawn mower was broken ... -- James Dent To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems installing apps that use a Java installer
I found what is causing their JDK's to seg fault. I happen to try coping over the Sun JDK to where the weblogic files were in /tmp. When I tried running the JDK from /tmp it began crashing with a segfault. So I moved the extracted WL files to /usr/local, and ran it. In order to run some other app I had to make tmp a symlink to /usr/tmp to allow for more space. Apparantly the JDK cant handle the sym link and seg faults. The Weblogic installer now launches, but freezes after the splash screen. If I run the installer using the Sun jdk it runs fine. On Mon, 2003-01-13 at 10:03, Daren Desjardins wrote: Ive been trying to install JBuilder 7 and Weblogic 7 and have been having no luck. Both apps extract themselves and then try to use their own JDK to start the installer, however they both then seg fault. I tried running the 'java' that they include and found that it is the cause of the seg fault. I was able to get JBuilder installed by replacing its JDK with the FreeBSD port. However I still have not been able to get Weblogic to install. I do have the BSD JDK port, 1.3.1-p7, installed and it works fine. Any ideas what would cause these Java installers using their own JDK to seg fault all the time? 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: IPFW2 skipto + logging
On Sun, Jan 12, 2003 at 04:52:53PM +0300, Maxim Konovalov wrote: Hello, Please try a next patch: It seems, that now logging with skipto is working correctly (I get expected results), but funny thing, when there is no log rule, the skipto command won't work. Consider this results: portal# ipfw show 00100172 139364 skipto 400 log ip from 192.168.0.0/24 to 192.168.0.0/24 00101 0 0 skipto 400 log ip from 192.168.0.0/24 to 192.168.0.0/24 00102 0 0 skipto 400 log ip from 192.168.0.0/24 to 192.168.0.0/24 00400180 140052 allow ip from any to any 65535 0 0 deny ip from any to any and portal# ipfw show 00100186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00101186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00102186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00103186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00400192 141136 allow ip from any to any 65535 0 0 deny ip from any to any The second one, without logging is just not working now... Best regards, Wiktor Niesiobedzki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC2 won't install (zf_read vm_fault) while 4.7 will
Joel Baldwin wrote: --On Friday, January 10, 2003 5:36 PM -0800 Gary W. Swearingen [EMAIL PROTECTED] wrote: I got an old P100 I'm preparing for NAT duty at a Linux meeting and I tried to install 5.0-RC2 on it. Near end of mfsroot.flp loading I get: zf_read: unexpected EOF I bit-checked the CD and floppies and they're good. Try making another floppy. I've thought I had a good floppy before and gotten that error. That was it. The floppy had been formatted verified bit-pattern- tested a few months ago and diff'ed against the image after writing, but somehow it got buggered before I could use it (or while). G. It won't even format now. :( Still can't boot 5.0-RC2 (on that box), but I've added my note about that to another post reporting a very similar problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PANIC in tcp_syncache.c sonewconn() line 562
Hi all,
Two days before RELEASE, I have a nice announcement ...
Newest CURRENT ... Easy to reproduce:
Get http://people.freebsd.org/~mbr/ports/drac.tgz
Install the port.
Add
drac3/tcp
to /etc/services
Add
dracstream tcp nowait root/usr/local/sbin/rpc.dracd rpc.dracd
to /etc/inetd.conf
Restart inetd.
telnet localhost 3
BM
#10 0xc03df350 in trap (frame=
{tf_fs = 24, tf_es = -65520, tf_ds = 16, tf_edi = 2, tf_esi = -1031597312,
tf_ebp = -854635944, tf_isp = -854635988, tf_ebx = -1031595264, tf_edx = 4,
tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071076206, tf_cs
= 8, tf_eflags = 66050, tf_esp = -1031595264, tf_ss =
0}) at /usr/src/sys/i386/i386/trap.c:445
#11 0xc03cf9f8 in calltrap () at {standard input}:98
#12 0xc02e1f3f in syncache_socket (sc=0xc2831300, lso=0xc2831300, m=0xc0ed9c00)
at /usr/src/sys/netinet/tcp_syncache.c:562
#13 0xc02e23e8 in syncache_expand (inc=0xcd0f4b4c, th=0xc0ed9c68,
sop=0xcd0f4b18, m=0xc0ed9c00)
at /usr/src/sys/netinet/tcp_syncache.c:781
#14 0xc02db779 in tcp_input (m=0xc0ed9c68, off0=20) at
/usr/src/sys/netinet/tcp_input.c:703
#15 0xc02d409b in ip_input (m=0xc0ed9c00) at /usr/src/sys/netinet/ip_input.c:923
#16 0xc02d4192 in ipintr () at /usr/src/sys/netinet/ip_input.c:941
#17 0xc02c1713 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
#18 0xc0238df1 in ithread_loop (arg=0xc0eba000) at
/usr/src/sys/kern/kern_intr.c:535
#19 0xc0237cf3 in fork_exit (callout=0xc0238c20 ithread_loop, arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:873
562 so = sonewconn(lso, SS_ISCONNECTED);
Martin
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FAST_IPSEC/racoon vs CISCO PIX anyone?
At 16:09 13/1/03, Daniel C. Sobral wrote: Bob Bishop wrote: Hi, Problems interworking this combination, with ESP tunnel. SA gets negotiated OK, but ESP packets get rejected by the PIX: it says host not found a.b.c.d where a.b.c.d is its own endpoint address, and sends invalid SPI back to our end, even thought the SPI on the rejected ESP packet is the one just negitiated. This is RC2, racoon-20021120a. FWIW the same problem occurs on 4.7 with 'ordinary' IPSEC too. Any suggestions? TIA Well, this question can be silly, specially if you have already established tunnels before, but... Did you negotiate a SA for each direction? Yes, symmetrically. And we have done this stuff before (but not to a PIX). -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It was one of those perfect summer days -- the sun was shining, a breeze was blowing, the birds were singing, and the lawn mower was broken ... -- James Dent -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FAST_IPSEC/racoon vs CISCO PIX anyone?
On Mon, 13 Jan 2003, Bob Bishop wrote: Yes, symmetrically. And we have done this stuff before (but not to a PIX). I've found that racoon/KAME to blackboxes is an interesting art, it took me 4 weeks to find all the right things to do to get KAME/racoon to work with RedCreek Ravlin units, now they are very stable. So unfortunately, unless you can find someone that has specifically config'd racoon to work with ciscos, you might have a bitch of a time :) -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.uk AilleCat@EFNet Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
Alexander Leidinger wrote: Hi, a dmesg from a working kernel (from Jan 5) shows: ---snip--- acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 58644MB IC35L060AVER07-0 [119150/16/63] at ata0-master tagged UDMA100 afd0: 96MB IOMEGA ZIP 100 ATAPI [32/64/96] at ata1-master PIO0 Waiting 6 seconds for SCSI devices to settle ---snip--- The not working kernel from yesterday locks up after printing the ad0 line... Assuming this is the same as I see on my -STABLE box, this started months ago. I have a SCSI Jaz drive (similar to a Zip) which started to hang the machine after the ad0 line when I remove the cartridge from the Jaz. Same here.. with FreeBSD-CURRENT and FreeBSD-RELASE/STABLE.. and since a long time. my test box is a Pentium III on a ASUS P2B-LS.. (Intel PIIX4 ATA33 controller) the P2B-LS has an onboard adaptec aic7890 (i think.. will double check if s/o need that info) If the SCSI device is enable on the MoBo (with or without SCSI device plugged), FreeBSD-* will systematically hang at boot (tried with FreeBSD-* install CDs, and with an already installed FreeBSD) without panicing.. (FreeBSD-* mean 4.[4567] (maybe earlier, can't remember) and -STABLE/-CURRENT) The only way i manage to install FreeBSD on that hardware is when i disable on the MoBo (via a jumper) the AIC interface.. Without SCSI devices, the ASUS P2B-LS is ok.. here's the dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Fri Jan 10 11:56:35 EST 2003 [EMAIL PROTECTED]:/mnt/space/obj/mnt/space/src/sys/Tulkar Preloaded elf kernel /boot/kernel/kernel at 0xc041d000. Preloaded elf module /boot/kernel/acpi.ko at 0xc041d0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 451024514 Hz CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268423168 (255 MB) avail memory = 256282624 (244 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2B-LS on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 8 entries at 0xc00f0d10 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 4.2 (no driver attached) pci0: bridge, PCI-unknown at device 4.3 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xd000-0xd01f mem 0xd480-0xd48f,0xd700-0xd7000fff irq 1 0 at device 7.0 on pci0 fxp0: Ethernet address 00:e0:18:98:17:62 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: multimedia, audio at device 12.0 (no driver attached) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ad0: 19544MB Maxtor 92049U6 [39709/16/63] at ata0-master UDMA33 ad1: 8063MB WDC AC28400R [16383/16/63] at ata0-slave UDMA33 acd0: CDROM LG CD-ROM CRD-8522B at ata1-master PIO4 MBREXT Slice 5 on ad0s2: 00 01 81 40 0b fe 3f 3f 3f 00 00 00 c1 85 78 01 |...@..???.x.| [0] f:00 typ:11 s(CHS):64/1/129 e(CHS):63/254/63 s:63 l:24675777 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad1s1a The hang
Re: FreeBSD 5.0 RC3 now available
Once again it's my pleasure to announce Release Cadidate 3 of
FreeBSD 5.0.
Perhaps I do things in a non-standard way, but its worked for the last 8
years from 2.x through to 4.7-stable.
Firstly, I download 'floppies' and create the 2 boot disks, kern.flp and
mgsroot.flp. Then I download 'bin' (now called 'base'!?) to my fileserver.
Next, I boot the box with 2 the new floppies, and tell sysinstall to use
'FTP' to the fileserver URL (ftp://172.22.2.2) and install 'minimal' (in
other words, just install 'bin' (now called 'base'!? - anyone remember
the acronym POLA?)).
Sysinstall complains about not being able to find the 'crypto' stuff, but
thats ok - its always done that.
Next, I reboot the newly installed 'base' system, login as root, then
'shutdown now' to return back to network-enabled single user mode.
Then I download 'cvsup-without-gui-16.1f.tgz' (into /root) and do a
'pkg_install cvsup-without-gui-16.1f.tgz' so I can cvsup the entire source
tree onto the new box and do the make build{world,kernel} thing on the new
box.
No go for 5.0-RC3:
# pkg_add cvsup-without-gui-16.1f.tgz
/usr/libexec/ld-elf.so.1: Shared object libssl.so.2 not found
#
Why does pkg_install now need libssl?
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Asus A7N8X Deluxe, nForce2 chipset, 3com MAC, Broadcom/Altima PHY
On Sun, Jan 12, 2003 at 01:04:30PM -0800, David O'Brien wrote: On Sun, Jan 12, 2003 at 09:07:31PM +0200, Mikko S. Hyvarinen wrote: The on-board 3com MAC and Broadcom/Altima PHY are not being detected by the xl(4) driver in -current (cvsup done yesterday evening). In the Award BIOS there is only one setting for the 3com device, a supposed on/off switch with only values Disabled and Auto; I have used Auto. ... FWIW, the diff for the files mentioned is attached, in case someone wants to continue from here. Thanks! I committed this patch so it didn't get lost and maybe someone else with one of these boards can take it all the way. As usual, it had to be something simple. With the attached change on top of the previous set the Altima AC101L PHY is detected correctly. I'm not so sure whether that xl_choose_xcvr() modification is actually necessary, but one can never be too sure. Tested with 10baseT/UTP and it works normally. Regards, MSH -- All opinions expressed above are mine alone and do not express the views of my employer or any other organizations that I am affiliated with. Index: sys/pci/if_xl.c === RCS file: /data/cvs/freebsd/src/sys/pci/if_xl.c,v retrieving revision 1.121 diff -u -r1.121 if_xl.c --- sys/pci/if_xl.c 12 Jan 2003 21:03:38 - 1.121 +++ sys/pci/if_xl.c 13 Jan 2003 16:24:50 - @@ -1245,6 +1245,7 @@ case TC_DEVICEID_HURRICANE_656: /* 3c656 */ case TC_DEVICEID_HURRICANE_656B:/* 3c656B */ case TC_DEVICEID_TORNADO_656C: /* 3c656C */ + case TC_DEVICEID_TORNADO_10_100BT_NVIDIA: /* nVidia nForce2 integrated */ sc-xl_media = XL_MEDIAOPT_MII; sc-xl_xcvr = XL_XCVR_MII; if (verbose) @@ -1340,6 +1341,8 @@ pci_get_device(dev) == TC_DEVICEID_HURRICANE_656B) sc-xl_flags |= XL_FLAG_INVERT_MII_PWR | XL_FLAG_INVERT_LED_PWR; + if (pci_get_device(dev) == TC_DEVICEID_TORNADO_10_100BT_NVIDIA) + sc-xl_flags |= XL_FLAG_PHYOK; /* * If this is a 3c905B, we have to check one extra thing.
Re: PANIC in tcp_syncache.c sonewconn() line 562
Hi all, Two days before RELEASE, I have a nice announcement ... Newest CURRENT ... Easy to reproduce: Ah yes, it seems that the bug is present in STABLE too ... This was 4.7 RELEASE. Here you can just use the drac port from /usr/ports/mail/drac which does the right thing. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvsweb
If memory serves me right, Andrew Thompson wrote: Has the cvs website stopped updating itself? http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/ is showing ver 1.131 of todo.sgml but http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml is showing ver 1.120 Hmmm? When I just looked, http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml showed revisions of todo.sgml up to (and including) 1.131. Bruce. msg50108/pgp0.pgp Description: PGP signature
Re: PANIC in tcp_syncache.c sonewconn() line 562
Hello, Two days before RELEASE, I have a nice announcement ... Newest CURRENT I have one too: kern/46861 It's a simple FTP server, nothing more. It seems it is related to the load. Now, when it does only about 30-40 Mbps continous traffic, it has an uptime of 3 days. With 80-90 Mbps traffic it had only 3 hours... --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
On Tue, Jan 14, 2003 at 03:22:02AM +1000, Andy Farkas wrote: Once again it's my pleasure to announce Release Cadidate 3 of FreeBSD 5.0. Sysinstall complains about not being able to find the 'crypto' stuff, but thats ok - its always done that. Obviously, this isn't okay. No go for 5.0-RC3: # pkg_add cvsup-without-gui-16.1f.tgz /usr/libexec/ld-elf.so.1: Shared object libssl.so.2 not found # Why does pkg_install now need libssl? troutmask:kargl[251] ldd /usr/sbin/pkg_add /usr/sbin/pkg_add: libfetch.so.3 = /usr/lib/libfetch.so.3 (0x28074000) libmd.so.2 = /usr/lib/libmd.so.2 (0x2808) libssl.so.2 = /usr/lib/libssl.so.2 (0x2808a000) libcrypto.so.2 = /usr/lib/libcrypto.so.2 (0x280b9000) libc.so.5 = /usr/lib/libc.so.5 (0x2817f000) I suspect your previous success in upgrading was accomplished because the version number of libssl didn't change. Many of the shared libraries in 5.0 have version number bumps, including libssl.so.2. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
Why does pkg_install now need libssl?
troutmask:kargl[251] ldd /usr/sbin/pkg_add
/usr/sbin/pkg_add:
libfetch.so.3 = /usr/lib/libfetch.so.3 (0x28074000)
libmd.so.2 = /usr/lib/libmd.so.2 (0x2808)
libssl.so.2 = /usr/lib/libssl.so.2 (0x2808a000)
libcrypto.so.2 = /usr/lib/libcrypto.so.2 (0x280b9000)
libc.so.5 = /usr/lib/libc.so.5 (0x2817f000)
I suspect your previous success in upgrading was accomplished
because the version number of libssl didn't change. Many of
the shared libraries in 5.0 have version number bumps,
including libssl.so.2.
--
Steve
FreeBSD 4.7-STABLE #1: Sat Jan 11 16:15:40 EST 2003:
# ldd /usr/sbin/pkg_add
/usr/sbin/pkg_add:
libfetch.so.3 = /usr/lib/libfetch.so.3 (0x2806f000)
libmd.so.2 = /usr/lib/libmd.so.2 (0x2807a000)
libc.so.4 = /usr/lib/libc.so.4 (0x28083000)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
Le Monday 13 January 2003 18:22, Andy Farkas a écrit : [SNIP] # pkg_add cvsup-without-gui-16.1f.tgz /usr/libexec/ld-elf.so.1: Shared object libssl.so.2 not found # Why does pkg_install now need libssl? indeed : (see http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/add/Makefile#rev1.15) machine# ldd /usr/sbin/pkg_add /usr/sbin/pkg_add: libfetch.so.3 = /usr/lib/libfetch.so.3 (0x28074000) libmd.so.2 = /usr/lib/libmd.so.2 (0x2808) libssl.so.2 = /usr/lib/libssl.so.2 (0x2808a000) libcrypto.so.2 = /usr/lib/libcrypto.so.2 (0x280b9000) libc.so.5 = /usr/lib/libc.so.5 (0x2817f000) machine# uname -a FreeBSD YYY 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Fri Jan 10 14:11:57 CET 2003 XXX@YYY:/files3/obj/usr/src/sys/SMP i386 machine# whereas : other_mach% ldd /usr/sbin/pkg_add /usr/sbin/pkg_add: libfetch.so.3 = /usr/lib/libfetch.so.3 (0x2806f000) libmd.so.2 = /usr/lib/libmd.so.2 (0x28079000) libc.so.4 = /usr/lib/libc.so.4 (0x28082000) other_mach% uname -a FreeBSD ZZZ 4.7-STABLE FreeBSD 4.7-STABLE #0: Sat Jan 4 12:51:32 CET 2003 XXX@ZZZ:/usr/obj/usr/src/sys/ZZZ i386 other_mach% TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
Le Monday 13 January 2003 18:22, Andy Farkas a écrit :
French is such a sexy language... :)
indeed :
(see
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/add/Makefile#rev1.15)
Again, the acronym POLA springs to mind
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Asus A7N8X Deluxe, nForce2 chipset, integrated AC97 audio
/-- Mikko S. Hyvarinen wrote: | ... | With this patch the on-board AC97 audio controller and Realtek Semiconductor | ALC650 CODEC work as far as I can test; tested with headphones in line-out | and playing two albums of MP3 audio with mpg123. | ... MSH The patches have been applied to current and will follow to stable in a few days. Cheers - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
If memory serves me right, Andy Farkas wrote: Once again it's my pleasure to announce Release Cadidate 3 of FreeBSD 5.0. Perhaps I do things in a non-standard way, but its worked for the last 8 years from 2.x through to 4.7-stable. Firstly, I download 'floppies' and create the 2 boot disks, kern.flp and mgsroot.flp. Then I download 'bin' (now called 'base'!?) to my fileserver. Next, I boot the box with 2 the new floppies, and tell sysinstall to use 'FTP' to the fileserver URL (ftp://172.22.2.2) and install 'minimal' (in other words, just install 'bin' (now called 'base'!? - anyone remember the acronym POLA?)). ...which was documented (along with the reason why this change was made) in the release notes. :-) Cheers, Bruce. msg50115/pgp0.pgp Description: PGP signature
5.0-RC3 /etc/rc.d/ipfw natd start-up script bug -- was: 5.0-RC1/etc/rc.d/ipfw script and NAT
Is there any chance of getting the fix suggested in PR-47024 in 5.0 before release? Looks like a similar script bug with natd start-up was fixed in 4.x-STABLE back in Feb. of 2002 -- See the CVS logs for /etc/rc.network, in particular, cjc's log entries for revision 1.124 (MAIN) and revision 1.74.2.31 (RELENG_4) where this very same bug was addressed and fixed in rc.network. Thanks! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FAST_IPSEC/racoon vs CISCO PIX anyone?
Bob Bishop wrote: At 16:09 13/1/03, Daniel C. Sobral wrote: Bob Bishop wrote: Hi, Problems interworking this combination, with ESP tunnel. SA gets negotiated OK, but ESP packets get rejected by the PIX: it says host not found a.b.c.d where a.b.c.d is its own endpoint address, and sends invalid SPI back to our end, even thought the SPI on the rejected ESP packet is the one just negitiated. This is RC2, racoon-20021120a. FWIW the same problem occurs on 4.7 with 'ordinary' IPSEC too. Any suggestions? TIA Well, this question can be silly, specially if you have already established tunnels before, but... Did you negotiate a SA for each direction? Yes, symmetrically. And we have done this stuff before (but not to a PIX). Ok. Well, I don't _use_ Pix/Cisco, but we have some tunnels to both from an isakmpd-based software. Below is a configuration used on a Pix using site. Remote refers to us, and Local to the Pix. Personally, I think some lines are rather dubious. It's better to have _them_ initiate the tunnel negotiation, and debug to see exactly what they are proposing. Any difference will cause problem. The most common difference is Pix-users defining the access-list of the tunnel just like the firewall rule. Since my side only negotiates protocol IP, this cause problem, we the rules on their side are for TCP tunnels, ICMP tunnels, etc. The first rule of the access-list here doesn't seem strictly necessary, as long as there is a rule enabling UDP port 500 and ESP between the gateways. name remote-ip GatewayRemote name local-ip GatewayLocal access-list tunnel_specification permit ip host GatewayLocal host GatewayRemote access-list tunnel_specification permit ip host EndPointLocal host EndPointRemote isakmp enable outside (Is the the interface??? I don't know) isakmp key SHAREDSECRET address GatewayRemote netmask 255.255.255.255 no-xauth no-config-mode isakmp policy 20 authentication pre-shared isakmp policy 20 encryption des isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 864000 crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto map outside_map 20 ipsec-isakmp crypto map outside_map 20 match address tunnel_specification crypto map outside_map 20 set peer GatewayRemote crypto map outside_map 20 set transform-set ESP-DES-SHA crypto map outside_map 20 set security-association lifetime seconds 3600 kilobytes 4500 -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Men are superior to women. -- The Koran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Linux Emulation Panic
Two panics produced when using Linux emulation on a machine CVSUP'ed two hours ago. Both very easy to produce. Am I the only one running Linux emulation on -current? Or is something wacked-ifed with this machine? Thanks, Chuck McCrobie [EMAIL PROTECTED] 1. cd /usr/ports/emulators/linux_base ; make install (hand-typed, sorry for typo's) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x08:0xc4670534 stack pointer = 0x10:0xdcb45c98 frame pointer = 0x10:0xdcb45c9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1516 (glibc_post_upgrade) kernel: type 12 trap, code=0 Stopped at stackgap_init+0x14: mol 0x2c(%eax),%edx db trace stackgrap_init(dcv45cd0,c047d023,c4360c78,c4361540,dcb45ce0) at stackgap_init+0x14 linux_execve(c4361540,dcb45d10,dcb45cfc,dcb45d00,3) at linux_execve+0x17 syscall(2f,2f,2f,8048816,bfbfea50) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (11, Linux ELF, linux_execve), eip=0x80486c2, esp=0xbfbfea2c, ebp=0xbfbfea38 2. kldload linux ; /compat/linux/sbin/ldconfig sorry, no panic information for this one __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sony VAIO GRX-670 Touchpad Support in -current
Should this be a send-pr or can someone commit it from here? Thank you, Chuck McCrobie [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com psm.c.diff Description: psm.c.diff
Re: Linux Emulation Panic
What exactly were you running? I use linux emulation on -CURRENT right now for mozilla and a few other packages, and havn't had any panics... you might have your kernel modules out of sync with your kernel. Ken On Mon, 13 Jan 2003, Chuck McCrobie wrote: Two panics produced when using Linux emulation on a machine CVSUP'ed two hours ago. Both very easy to produce. Am I the only one running Linux emulation on -current? Or is something wacked-ifed with this machine? Thanks, Chuck McCrobie [EMAIL PROTECTED] 1. cd /usr/ports/emulators/linux_base ; make install (hand-typed, sorry for typo's) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x08:0xc4670534 stack pointer = 0x10:0xdcb45c98 frame pointer = 0x10:0xdcb45c9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1516 (glibc_post_upgrade) kernel: type 12 trap, code=0 Stopped at stackgap_init+0x14: mol 0x2c(%eax),%edx db trace stackgrap_init(dcv45cd0,c047d023,c4360c78,c4361540,dcb45ce0) at stackgap_init+0x14 linux_execve(c4361540,dcb45d10,dcb45cfc,dcb45d00,3) at linux_execve+0x17 syscall(2f,2f,2f,8048816,bfbfea50) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (11, Linux ELF, linux_execve), eip=0x80486c2, esp=0xbfbfea2c, ebp=0xbfbfea38 2. kldload linux ; /compat/linux/sbin/ldconfig sorry, no panic information for this one __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com 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: Important, agp_via.c missing PCI ID!
On 11-Jan-2003 David Holm wrote: Hi, the FreeBSD kernel is missing the PCI ID for the Apollo Pro 133A PCI bridge even though it is supported by the agp_via code. Please see this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=46983 //David Holm According to /usr/share/misc/pci_vendors, that device is not for the Pro 133A but for the PM133: 0605VT8605 ProSavage PM133 System Controller 0691VT82C691/693A/694X Apollo Pro/133/133A System Controller The patch should make no functional difference since the generic probe should work (it should be listed as a VIA Generic host to PCI bridge). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvsweb
On Tue, 2003-01-14 at 06:30, Bruce A. Mah wrote: If memory serves me right, Andrew Thompson wrote: Has the cvs website stopped updating itself? http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/ is showing ver 1.131 of todo.sgml but http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml is showing ver 1.120 Hmmm? When I just looked, http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml showed revisions of todo.sgml up to (and including) 1.131. Sorry, false alarm, Mozilla was misbehaving. I had cleared the memory/disk cache under prefs and it was still showing 1.120. I just tried putting a ? at the end of the url and whammo, 1.131. Now I think about it, it stopped working when I moved to mozilla-devel. Time to have a tinker me thinks. Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Here's a PR for you: PR's dont send
A couple days ago, I tried to send a PR with send-pr(1), and it said PR sent although it said it quite rapidly, which made it look like that wasn't true, and sure enough the PR certainly didn't make it. Anyways, here's the PR in question: SEND-PR: BE ADVISED THAT FREEBSD PROBLEM REPORTS ARE PUBLIC INFORMATION AND SEND-PR: WILL BE PUBLISHED AS-IS ON THE PROJECT'S MAILING LISTS AND WEB SITES. SEND-PR: DO NOT SUBMIT ANY INFORMATION YOU DO NOT WANT MADE PUBLIC. SEND-PR: SEND-PR: For sensitive security issues, consider contacting the FreeBSD SEND-PR: security officer team ([EMAIL PROTECTED]) directly. SEND-PR: SEND-PR: Choose from the following categories: SEND-PR: SEND-PR: advocacy alpha bin conf docs gnu SEND-PR: i386 ia64 java kern misc ports SEND-PR: powerpc sparc64 standards www SEND-PR: To: [EMAIL PROTECTED] From: Craig R [EMAIL PROTECTED] Reply-To: Craig R [EMAIL PROTECTED] Cc: X-send-pr-version: 3.113 X-GNATS-Notify: Submitter-Id: current-users Originator:Craig R Organization: organization of PR author (multiple lines) Confidential: no FreeBSD PRs are public data Synopsis: Floppy controller won't configure on FIC VA-503+ mainboard, USB busted too Severity: serious Priority: medium Category: kern Class: sw-bug Release: FreeBSD 5.0-RC1 i386 Environment: System: FreeBSD boss.sewer.org 5.0-RC1 FreeBSD 5.0-RC1 #1: Sat Dec 14 13:04:26 E ST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BOSSKERN i386 Description: The floppy controller doesn't configure properly on the FIC VA-503+ motherboard. This has been verified with two boards.The lines below (dmesg output) show the problem. As an aside, USB support and pci support appear to be limited as well. A Tyan S1590 mainboard worked fine, which is odd because it has the same VIA Apo llo MVP3 chipset. This PR most likely overlaps with i386/46194. This problem doesn't occur in -STABLE. How-To-Repeat: Buy the motherboard specified, and put FreeBSD 5.0-RC1 on it. This has been a problem since DP2, probably even earlier. Fix: No idea, probabaly in the fdc driver. --- 450aft1 begins here --- 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 5.0-RC1 #1: Sat Dec 14 13:04:26 EST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BOSSKERN Preloaded elf kernel /boot/kernel/kernel at 0xc03ce000. Preloaded elf module /boot/kernel/acpi.ko at 0xc03ce0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 451025647 Hz CPU: AMD-K6(tm) 3D processor (451.03-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 268369920 (255 MB) avail memory = 256663552 (244 MB) Initializing GEOMetry subsystem K6-family MTRR support enabled (2 registers) npx0: math processor on motherboard npx0: INT 16 interface acpi0: FICVA503P on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 6 entries at 0xc00fdd60 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed, AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT acpi_timer0: 32-bit timer at 3.579545MHz port 0x6008-0x600b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6080-0x60ff,0x6000-0x607f,0xcf8-0xcff on ac pi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C597 (Apollo VP3) host to PCI bridge mem 0xe000-0xe0ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C586 ATA33 controller port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 7.3 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.VTAC - AE_NOT_F OUND pci0: couldn't attach pci bus device_probe_and_attach: pcib2 attach returned 6 rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem 0xe400-0xe4ff ir q 5 at device 8.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:50:bf:5a:eb:c9 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xec00-0xec1f irq 11 at device 9. 0 on pci0 ed0: address 00:60:67:3a:b1:70, type NE2000 (16 bit) pci0: display, VGA at device 10.0 (no driver attached) fdc0: cannot reserve I/O port range (1 ports) ppc0 port
Re: Still problems with PCCARD NICs
Date: Mon, 13 Jan 2003 11:24:14 +1030 From: Greg 'groggy' Lehey [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I haven't done much with PCCARD on -CURRENT lately. Last time I tried, a couple of months ago, I got repeated freezes on the two 100 Mb/s NICs I have. I've just built a kernel as of about 30 hours ago, and I find: 1. Xircom RealPort RE-100 (xe driver). Comes up with unidentified media. Doesn't react to dhclient. Won't let me set the mediaopt. I have to first set a valid IP address, after which it comes up as 100baseTX. I can't find a way to set full-duplex, but maybe the card doesn't support it. I tried to tar an NFS-mounted file system to see how fast it went: tar cf /dev/null /src Almost immediately, I got these messages, repeated frequently: Jan 13 10:57:29 sydney kernel: xe0: discard oversize frame (ether type 800 flags 3 len 1518 max 1514) Jan 13 10:58:13 sydney kernel: xe0: discard oversize frame (ether type 800 flags 3 len 1518 max 1514) I checked at the other end and confirmed that the frames were in fact 1514 bytes long. Odd. I've been running RC2 for a few days using an RE-100 with no problems. Is it possible that the frames are getting 802.1Q tags (4 bytes) added to them? R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Here's a PR for you: PR's dont send
On Mon, 13 Jan 2003, Craig Reyenga wrote: ACPI-1287: *** Error: Method execution failed, AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT You have a problem in your dsdt. For now, disable ACPI. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
Bruce Evans wrote: The prototypes are machine-independent, so they are correctly placed in ieeefp.h. This has the technical problem that it is difficult to implement declared functions as inlines (*), so we use an ugly i386 ifdef in ieefp.h to prevent them being declared. In fact, this is exactly the problem. The correct thing to do is to ensure that the values come into scope at the same level in all implementations. Effectively, this means that the #define's for the i386 version's inline references need to be at the same level as the prototype declarations. Where the prototype declatations take place is actually moot. This seems least evil since inlining them doesn't seem to be useful and the wart only affects i386's, and these functions should be obsoleted by the C99 functions as soon as possible. I think it is better to fully adhere to an old standard than to partially adhere to a new one. FreeBSD was much better off, in terms of software portability, when it supported the full Draft 4 pthreads standard (both Jeremy Allison and I had a hand in the final work of making it conform), than it was when it was in partial conformance to the new standard. Whether or not inlining them should be ripped out in favor of real library routines, as in OpenBSD and NetBSD, is another matter, and, as far as I'm concerned, that's off the table for discussion at this point. I'm unwilling to change implementation this late in the game, only organization. No matter how you look at it, the code should be organized such that including the same header files, *whatever* they are, ends up with the same results on all flavors of FreeBSD. Riht now, that does not happen. Both of the proposed patches fix this. Another way of fixing this would be to move the #define's for the inline versions *up* into /usr/include/ieeefp.h, so that the scope comes from there. This is consistant with your suggestion here. There are two reason to not do this, at this point: 1) It will cause some ports to be broken; arguably, these ports *should* be broken. But when you complain about them, you are really complaining that the machine/XXX.h scope is visible to user programs directly, instead of forcing them to include the correct header files, instead. I think this complaint should be addressed in the compiler, and can be, by having a #pragma that maches the directory visible to the compiler, with the default being invisible, and the regular headers can set the #pragma, and third party code can break. I would argue that, whatever you do to address the complaint, however, you address it *later*. 2) This approach has the negative effect of leaving platform variant code in a system header file. This is, in my opinion, and incredibly broken thing to do, even if you ignore all other issues. If you are dead set on this approach, I can provide a patch that will move the i386 #define's from machine/floatingpoint.h up into ieeefp.h; but I believe this is bad design at its worst. Since on i386 machine/floatingpoint.h also includes machine/ieeefp.h, we should be able to move the implementation on i386 to machine/ieeefp.h as well. If possible, I'd like to see machine/floatingpoint.h retired unless there's a compelling reason to keep it... There is no good reason for these to be separate, but they may be required for compatibility. IIRC, their names and interfaces were copied from some system (Sun) that had them, but they were slightly misplaced (machine is a BSDism AFAIK so other systems couldn't have anything there)... According to google, floatingpoint.h was in /usr/include in SunOS in 1992 (we link it there), and it seems to be the primary interface (Sun apparently had ieeefp.h in sys then, but non-BSD hits on it are not as common. I agree that floatingpoint.h is probably something that should gracefully fall into compatability, in terms of a message that says deprecated; include XXX instead; FreeBSD already has a number of these. But in any case, this is not really a functional issue, and I really don't care about it. 8-). - Applications can easily shoot there feet off by stepping into this header tangle in any place except the one that is actually docuemented under FreeBSD. This is the case as it is today. The patches I have proposed, both reattach the feet of a number of application in ports, based on them already having stepped in this mine field. I think it's not reasonable to believe that you can make people rewrite all the old code in the world to conform to new standards (e.g. C99, etc.). Basically, this means to me that a successful standard is not one which tries to change how things are done, but instead permits legacy code to continue to function. This *also* argues for pushing the declaration scope for these things down,
Re: [PATCH] Re: fpsetmask on sparc64
Bruce Evans wrote: On Sun, 12 Jan 2003, Terry Lambert wrote: This patch also affects the IA64 and Alpha, as well as just the SPARC. It took a lot of discussion, but it seems to me that the problem is that the prototypes in scope aren't in scope when the wrong include file is included. Right. It is mainly an application bug like I said. The prototypes also aren't in scope when stdio.h is included, and the fix is not to add them to stdio.h. I really disagree. A legacy application *can't* be said to be buggy. If someone cuts you off, and you get into an accident, it was the fault of the person who cut you off, not you. If a legacy application stops working because a system changes, it's the fault of the system doing the changing, not the fault of the people back in 1984 who didn't know ANSI was going to bung-up the C language until their application no longer worked. There has to be some allowance for the continuity of code; it can't just be orphaned instantaneously, without some warning from the system vendor. Say we took your approach, and moved the #define's for the inlines up into ieeefp.h, exposing platform dependencies in a (supposedly) platform independent header file. How many ports would break? All of the ports that won't compile on Alpha or SPARC or IA64 today, will end up not compiling on i386, either. That's not an acceptable thing, right before the 5.0 release. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Important, agp_via.c missing PCI ID!
On Mon, 13 Jan 2003 14:35:43 -0500 (EST) John Baldwin [EMAIL PROTECTED] wrote: According to /usr/share/misc/pci_vendors, that device is not for the Pro 133A but for the PM133: 0605VT8605 ProSavage PM133 System Controller 0691VT82C691/693A/694X Apollo Pro/133/133A System Controller I promise you it's an Apollo Pro 133A and it identifies with 0605, not with 0691. This is the mobo I have: http://www.motherboard.cz/mb/asus/CUV4X.htm The patch should make no functional difference since the generic probe should work (it should be listed as a VIA Generic host to PCI bridge). It doesn't, without adding that line my computer reboots when running OpenGL apps. I have tried maybe 5 times to recompile the kernel without it, same result every time. Is there anything I can do to confirm, check why I need this or something? I have tried checking the syslogs after the computer reboots but I never found anything related to it. I'd prefer not to run too many tests though, since sometimes my drives get corrupted. I just switched back to CURRENT to check how it would behave when I added these lines. When I load agp.ko now I get this extra output: on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND and I had to set the AGP rate to 0, otherwise the machine will hang randomly (not OpenGL related this time since it will hang even though I haven't run any OpenGL apps). I have tried not loading agp.ko and using nvidias agp (by enabling in XF86Config), but that yields the same result as agp_via.c without the added ID. Now this is very strange, I did a search and indeed, the id is 0691. I was unable to find the page that said that it was 0605 =(. Now I'm positive I have a CUV4X mobo which has a 694X AGP chipset. Do you have any hints to how I can debug this, because it works with id 0605 and it doesn't work without it, which does not make any sense I guess. //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
In message [EMAIL PROTECTED], Ju lian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. Better plan: Abandon BSD labels before disks outgrow them. -- 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] Re: fpsetmask on sparc64
Marcel Moolenaar wrote: This part is what makes me opt for moving the prototypes to the MD header. These functions are trivial most of the time that inlining them makes sense. I don't see why other platforms can't or won't inline in the future. I think so, too, but it depends on the hardware. What about signaling the MI header about the existence (or non- existence) of inline functions and/or macros in the MD header so that the MI header can optionally provide the prototypes? This can be done by having the MD header define (or undefine) some macro (or set of macros). This would be a Bad Thing(tm). Specifically, it would throw some namespace pollution into the implementation space, which is not something that should be permitted, I think. Also, it appears to me that we always have to provide non-inlined versions in libc for when inlining is disabled. See ctype.h. I may misinterpret the comment though... No, this is true. There is also a problem with the GNUC tests in the inilining definitions, particularly, since there is a cdefs.h in scope, and there's a portable way to get rid of the GNUC-isms. Am I right when I say that removing floatingpoint.h (both the MD file and the MI link) will fix the port, independent of how we shape ieeefp.h? IMO, no. The port will remain broken. Kris is the person to ask on this, actually, since he's the one who reported the problem, initially. - We implement floatingpoint.h as a link to machine/floatingpoint.h to get the MD and implementation details right and the MI details wrong. Perhaps the broken ports include this and not machine/floatingpoint.h. Then they would be less broken. Some configure scripts may check for floatingpoint.h for compatibility with SunOS/Solaris. I doubt they will check machine/floatingpoint.h And here's the reason why. The SPARC platform for FreeBSD will need to be sensitive to the fact that people will port from SPARC running some other OS to SPARC running FreeBSD. The most likely source of ported code in this case is SPARC running Solaris, which has the header file in question. In summary: I like Terry's second patch but am sensitive to having the MI prototypes in ieeefp.h as well as allowing inlining. What about something like the following to keep the prototypes in ieeefp.h, but still allow inlining (in combination with Terrys patch): This is a patch post-application of my patch; you are missing the floating point function prototypes in the non-inlined case. 8-). But it's fixable. I personally worry about putting stuff into the namespace that people might then key off of when doing ports or other work, in order to let them use FreeBSD-isms. I'm particularly sensitive on this point, because I personally abused the PTHREAD_MUTEX_INITIALIZER to distinguish between draft 4 and standard implementations, and then that was the first thing that they added going from draft 4 to standard, without implementing all of the rest of the standard first. 8-(. This broke a lot of pthreaded code that I worked on and threw the patches back to the maintainers, including MySQL, OpenLDAP, ACAP, and anything statically declaring the mutex-using classes that implement using threads in the C++ STL code out of MCSCA. It was a real mess when FreeBSD made that change. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Mon, Jan 13, 2003 at 10:21:59PM +1100, Bruce Evans wrote: This part is what makes me opt for moving the prototypes to the MD header. These functions are trivial most of the time that inlining them makes sense. I don't see why other platforms can't or won't inline in the future. Hand-inlining things rarely makes sense, especially for little-used compatibility-cruft functions like these. Aahh.. But by hand-inlining compatibility cruft, you remove them from the ABI! You only have them in the API, which is the lesser evil of the two when you want to remove the compatibility cruft completely. A technical reason for not inlining some of them is that they may need to interact with signal handling. I don't see how this is related. The only advantage of not inlining is the ability to declare the functions as weak so that they can be overridden. In all other cases it's just an implementation detail that should not affect the functionality. We currently avoid most signal-handling problems related to changing the FP environment by switching the critical part of the environment in setjmp/longjmp, at least on i386's, but C99 seems to forbid this. I think the functions that change the FP environment need to save their setting somehwere so that longjmp() can restore the default FP environment (not necessarily the one when setjmp() was called). I don't know how to do this properly reentrantly. On ia64 the FP environment is callee saved and thus put in jmpbuf. The general modus operandi seems that functions either use the settings as inherited, or otherwise explicitly set them. This also applies to signal handlers. Thus when the FP environment is changed at function entry, the only action required is to restore the FP environment at function exit. Also, it appears to me that we always have to provide non-inlined versions in libc for when inlining is disabled. See ctype.h. I may misinterpret the comment though... Non-inline versions are needed for at least calling functions through function pointers if this is supported, and C requires it to be supported for most functions including the ctype 1's. This requirement causes some of the implementation complications in ctype.h. I see. Using static inline functions rather than macros should mostly solve this. Function pointer comparison will not work though, but I don't know if it has to. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
I agree with that too. On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. Better plan: Abandon BSD labels before disks outgrow them. -- 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] Re: fpsetmask on sparc64
On Mon, Jan 13, 2003 at 12:42:24PM -0800, Terry Lambert wrote: Some configure scripts may check for floatingpoint.h for compatibility with SunOS/Solaris. I doubt they will check machine/floatingpoint.h And here's the reason why. The SPARC platform for FreeBSD will need to be sensitive to the fact that people will port from SPARC running some other OS to SPARC running FreeBSD. The most likely source of ported code in this case is SPARC running Solaris, which has the header file in question. Ok. I'm now going to throw (an interpretation of) your own words into the mix and let you decide how you want to prioritize them. You said that FreeBSD on different platforms should not cause variation in the API or ABI. If having floatingpoint.h on sparc64 makes sense, then having all kinds of proprietary OS quirks on platforms with proprietary OSes also makes sense. This contradicts with the uniformity across platforms. Either we present the FreeBSD ABI and API uniformly across the supported platforms or we provide an uniform subset and allow deviation for ease of porting but then also have to accept porting across different FreeBSD implementations. I favor an uniform ABI/API if only to keep our ports meisters sane, but also because there's just too much difference that the existence or non-existence of floatingpoint.h will not make a big difference in porting SunOS/Solaris code. This is gut-feeling -- use salt... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Important, agp_via.c missing PCI ID!
On 13-Jan-2003 David Holm wrote: On Mon, 13 Jan 2003 14:35:43 -0500 (EST) John Baldwin [EMAIL PROTECTED] wrote: According to /usr/share/misc/pci_vendors, that device is not for the Pro 133A but for the PM133: 0605VT8605 ProSavage PM133 System Controller 0691VT82C691/693A/694X Apollo Pro/133/133A System Controller I promise you it's an Apollo Pro 133A and it identifies with 0605, not with 0691. This is the mobo I have: http://www.motherboard.cz/mb/asus/CUV4X.htm The patch should make no functional difference since the generic probe should work (it should be listed as a VIA Generic host to PCI bridge). It doesn't, without adding that line my computer reboots when running OpenGL apps. I have tried maybe 5 times to recompile the kernel without it, same result every time. Is there anything I can do to confirm, check why I need this or something? I have tried checking the syslogs after the computer reboots but I never found anything related to it. I'd prefer not to run too many tests though, since sometimes my drives get corrupted. I just switched back to CURRENT to check how it would behave when I added these lines. When I load agp.ko now I get this extra output: on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND and I had to set the AGP rate to 0, otherwise the machine will hang randomly (not OpenGL related this time since it will hang even though I haven't run any OpenGL apps). I have tried not loading agp.ko and using nvidias agp (by enabling in XF86Config), but that yields the same result as agp_via.c without the added ID. Now this is very strange, I did a search and indeed, the id is 0691. I was unable to find the page that said that it was 0605 =(. Now I'm positive I have a CUV4X mobo which has a 694X AGP chipset. Do you have any hints to how I can debug this, because it works with id 0605 and it doesn't work without it, which does not make any sense I guess. What is the output of 'dmesg | grep agp' both with and without the patch? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_SPECSTRATEGY on non-VCHR
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Lars Eggert writes: just got this on today's -current, when accessing a mounted NTFS partition: VOP_SPECSTRATEGY on non-VCHR : 0xc6d73c34: tag ntfs, type VREG, usecount 3, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ntfs: SHARED (count 1) Can you try this patch ? The patch fixes things in the sense that I now longer see the message. Thanks! Index: vnode_pager.c === RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v retrieving revision 1.167 diff -u -r1.167 vnode_pager.c --- vnode_pager.c 5 Jan 2003 20:32:03 - 1.167 +++ vnode_pager.c 12 Jan 2003 10:21:08 - @@ -823,7 +823,10 @@ cnt.v_vnodepgsin += count; /* do the input */ - VOP_SPECSTRATEGY(bp-b_vp, bp); + if (dp-v_type == VCHR) + VOP_SPECSTRATEGY(bp-b_vp, bp); + else + VOP_STRATEGY(bp-b_vp, bp); s = splvm(); /* we definitely need to be at splvm here */ Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Emulation Panic
Thank you. That was it. Booted from /boot/cvsup/kernel, loaded modules from /boot/kernel/*. Now, if I can just figure out read-conf and friends in loader. It seems I have to manually: loader unload loader set kernel=cvsup loader set kernelname=/boot/cvsup/kernel loader set module_path=/boot/cvsup loader boot I want to have two different kernels - one I know works (older -current) and the latest cvsup of -current. Then, I would like to: loader some-command-to-load-alternate-configuration I suppose that's read-conf, but that doesn't seem to like me :( I have: /boot/cvsup.conf as: unload kernel=cvsup kernelname=/boot/cvsup/kernel module_path=/boot/cvsup then I use: loader read-conf cvsup.conf but the changes don't take effect. Oh well, maybe some more experimentation later... Thanks, Chuck McCrobie --- Kenneth Culver [EMAIL PROTECTED] wrote: What exactly were you running? I use linux emulation on -CURRENT right now for mozilla and a few other packages, and havn't had any panics... you might have your kernel modules out of sync with your kernel. Ken On Mon, 13 Jan 2003, Chuck McCrobie wrote: Two panics produced when using Linux emulation on a machine CVSUP'ed two hours ago. Both very easy to produce. Am I the only one running Linux emulation on -current? Or is something wacked-ifed with this machine? Thanks, Chuck McCrobie [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
Marcel Moolenaar wrote: Ok. I'm now going to throw (an interpretation of) your own words into the mix and let you decide how you want to prioritize them. I *live* to be hung on my own petard... go for it! 8-). You said that FreeBSD on different platforms should not cause variation in the API or ABI. If having floatingpoint.h on sparc64 makes sense, then having all kinds of proprietary OS quirks on platforms with proprietary OSes also makes sense. This contradicts with the uniformity across platforms. Either we present the FreeBSD ABI and API uniformly across the supported platforms or we provide an uniform subset and allow deviation for ease of porting but then also have to accept porting across different FreeBSD implementations. OK. I understand the discrepancy here. I'm going to point out up front that /usr/include/floatingpoint.h is actually a symlink to /usr/include/machine/floatingpoint.h, so this argument doesn't apply in this case. But that doesn't invalidate your argument, so it still needs to be addressed. The answer is that there should be no variation among platforms at the API level, inasmuch as it's possible to not vary between them. Having floatingpoint.h on SPARC makes sense, in terms of being able to support a *legacy* interface for *legacy* code that needs it. Both uses of the word legacy are important here. I think that the header file should complain, during compilation, when it is used, e.g.: #warning this file includes floatingpoint.h which is obsoleted, use ieeefp.h instead This doesn't contradict uniformity across platforms, per se, since the interface is deprecated. That said, it should be uniformly deprecated across platforms; here's why: When someone ports code from Solaris SPARC to FreeBSD SPARC, the resulting port should compile on FreeBSD Alpha, FreeBS IA64, and FreeBSD i386, without modifications, so long as the software uses published interfaces (any file in /usr/include, but not in machine/ or sys/). This is about setting up rules that result in more FreeBSD software for all versions of FreeBSD, not just for one, and not to discourage porting to FreeBSD. I don't think it's acceptable to have porting differences across implementations, if it can be helped. It sets a bad precedent. I favor an uniform ABI/API if only to keep our ports meisters sane, I don't really care if they are sane, but I'd prefer it if they don't go postal on me. 8-) 8-). but also because there's just too much difference that the existence or non-existence of floatingpoint.h will not make a big difference in porting SunOS/Solaris code. This is gut-feeling -- use salt... It is, I think, an interface that can be deprecatedm but not removed, at this point. Removal can wait for one minor release following the insertion of a compilation warning message (or however long it is we are going to have to keep living with it, because of the volume of legacy software that needs it (i.e. as long as we have to live with values.h, I think, and as long as we lived with direct.h/dirent.h; I notice that direct.h is finally gone, now...). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linux Emulation Panic
On 13-Jan-2003 Chuck McCrobie wrote: Thank you. That was it. Booted from /boot/cvsup/kernel, loaded modules from /boot/kernel/*. Now, if I can just figure out read-conf and friends in loader. It seems I have to manually: loader unload loader set kernel=cvsup loader set kernelname=/boot/cvsup/kernel loader set module_path=/boot/cvsup loader boot I want to have two different kernels - one I know works (older -current) and the latest cvsup of -current. Then, I would like to: loader some-command-to-load-alternate-configuration I suppose that's read-conf, but that doesn't seem to like me :( I have: /boot/cvsup.conf as: unload kernel=cvsup kernelname=/boot/cvsup/kernel module_path=/boot/cvsup then I use: loader read-conf cvsup.conf but the changes don't take effect. Oh well, maybe some more experimentation later... Just do 'boot cvsup' and it should do what you want for this case. (Booting from a differently named kernel than the default) Thanks, Chuck McCrobie --- Kenneth Culver [EMAIL PROTECTED] wrote: What exactly were you running? I use linux emulation on -CURRENT right now for mozilla and a few other packages, and havn't had any panics... you might have your kernel modules out of sync with your kernel. Ken On Mon, 13 Jan 2003, Chuck McCrobie wrote: Two panics produced when using Linux emulation on a machine CVSUP'ed two hours ago. Both very easy to produce. Am I the only one running Linux emulation on -current? Or is something wacked-ifed with this machine? Thanks, Chuck McCrobie [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Mon, Jan 13, 2003 at 01:12:56PM -0800, Terry Lambert wrote:
To my mind, this is a problem to address *after* the 5.0 release;
one hopes that the ports compilation issues will be addressed
*before* the 5.0 release.
We tag in 2 days. Forget about 5.0-R. The chance of breaking more
than that we fix is too high. This needs a couple of bento runs
before we can see the impact and flush out the nits.
\begin{image}
assume there's some ascii art here that shows a traffic sign with
the heads of our REs and the following text:
No rushing in the RC zone
\end{image}
:-)
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PANIC in tcp_syncache.c sonewconn() line 562
On Mon, 2003/01/13 at 17:47:11 +0100, Martin Blapp wrote:
#10 0xc03df350 in trap (frame=
{tf_fs = 24, tf_es = -65520, tf_ds = 16, tf_edi = 2, tf_esi = -1031597312,
tf_ebp = -854635944, tf_isp = -854635988, tf_ebx = -1031595264, tf_edx = 4,
tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071076206, tf_cs
= 8, tf_eflags = 66050, tf_esp = -1031595264, tf_ss =
0}) at /usr/src/sys/i386/i386/trap.c:445
#11 0xc03cf9f8 in calltrap () at {standard input}:98
#12 0xc02e1f3f in syncache_socket (sc=0xc2831300, lso=0xc2831300, m=0xc0ed9c00)
at /usr/src/sys/netinet/tcp_syncache.c:562
#13 0xc02e23e8 in syncache_expand (inc=0xcd0f4b4c, th=0xc0ed9c68,
sop=0xcd0f4b18, m=0xc0ed9c00)
at /usr/src/sys/netinet/tcp_syncache.c:781
#14 0xc02db779 in tcp_input (m=0xc0ed9c68, off0=20) at
/usr/src/sys/netinet/tcp_input.c:703
#15 0xc02d409b in ip_input (m=0xc0ed9c00) at /usr/src/sys/netinet/ip_input.c:923
#16 0xc02d4192 in ipintr () at /usr/src/sys/netinet/ip_input.c:941
#17 0xc02c1713 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
#18 0xc0238df1 in ithread_loop (arg=0xc0eba000) at
/usr/src/sys/kern/kern_intr.c:535
#19 0xc0237cf3 in fork_exit (callout=0xc0238c20 ithread_loop, arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:873
562 so = sonewconn(lso, SS_ISCONNECTED);
This seems to actually be a quite old bug: we allow listen() to be
called on connected sockets, which messes up the state of the socket
(it will get SO_ACCEPTCONN set). Before syncache, this would likely
only lead to the connection becoming catatonic, unless a matching SYN
packet came along (in a state where the initial SYN of the connection
was already received). With syncache however, a panic can be triggered
by normal ACK packets.
In your example, the listen is buried in the bowels of the RPC code.
The solution should be to reject the listen() with EINVAL (which seems
to be that standard-mandated error for connected sockets); patch
attached.
Any thoughts on this?
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: kern/uipc_socket.c
===
RCS file: /ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.140
diff -u -r1.140 uipc_socket.c
--- kern/uipc_socket.c 5 Jan 2003 11:14:04 - 1.140
+++ kern/uipc_socket.c 13 Jan 2003 21:43:52 -
@@ -266,6 +266,10 @@
int s, error;
s = splnet();
+ if (so-so_state (SS_ISCONNECTED | SS_ISCONNECTING)) {
+ splx(s);
+ return (EINVAL);
+ }
error = (*so-so_proto-pr_usrreqs-pru_listen)(so, td);
if (error) {
splx(s);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
Marcel Moolenaar wrote: A technical reason for not inlining some of them is that they may need to interact with signal handling. I don't see how this is related. The only advantage of not inlining is the ability to declare the functions as weak so that they can be overridden. In all other cases it's just an implementation detail that should not affect the functionality. This does not apply in this case, since the inlined function is not itself making a system call that could be interrupted by a signal. This argument only applies in the case where the inlined function makes a system call, and the default behaviour is not SA_RESTART. Non-inline versions are needed for at least calling functions through function pointers if this is supported, and C requires it to be supported for most functions including the ctype 1's. This requirement causes some of the implementation complications in ctype.h. I see. Using static inline functions rather than macros should mostly solve this. Function pointer comparison will not work though, but I don't know if it has to. This is a valid argument, but we are not really here to fix the lack of an i386 prototype in scope in the case that inilining is disabled, any more than we are here to fix the fact that everything goes to hell if the #ifdef for GNUC fails because another compiler is being used. The prototypes are out of scope in the non-inline case, but the #define's are not. I don't know the correct compiler voodoo to make the #define's go away when inlining is disabled, the way the inline functions themselves do (maybe Bruce can help out here). The other issue is that there are not i386 implementations for these functions in /usr/src/lib/libc/i386/gen, at this point, so you would either need to pull the code in from NetBSD/OpenBSD, or you would need to have a .c file that forces the inlining with stub instances, including the machine dependent header file. To my mind, this is a problem to address *after* the 5.0 release; one hopes that the ports compilation issues will be addressed *before* the 5.0 release. One also hopes that the *way* they are addressed will be to make the ports *work* on IA64, SPARC, and Alpha, rather than making them *break* on i386. Consistent behaviour is not a good thing, if it's consistently *bad*... 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problems after resume from suspend in current as of January 9
On Fri, Jan 10, 2003 at 12:22:22PM +1100, Mark Sergeant wrote: I'm running a toshiba portege 4000 with -CURRENT as of January 9. Suspending and resuming runs fine apart from USB, on resume it is unable to recognise my USB mouse (logitech), nothing even registers that it is plugged in, nor does the mouse get any power yet on booting normally USB works fine. Has anyone got any ideas how I can work around this issues ? It may be the USB controller is being shutdown and not restarted. To check whether the USB controller is up try: usbdevs -v which I believe should complain: no USB controllers found or similar. You may want to check the BIOS for any obvious settings related to USB and power management. Is ACPI involved in suspension? I'm sorry but I know nothing about ACPI (or laptop power management). -- Marc Butler [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
On Mon, 13 Jan 2003, Terry Lambert wrote: Bruce Evans wrote: On Sun, 12 Jan 2003, Terry Lambert wrote: This patch also affects the IA64 and Alpha, as well as just the SPARC. It took a lot of discussion, but it seems to me that the problem is that the prototypes in scope aren't in scope when the wrong include file is included. Right. It is mainly an application bug like I said. The prototypes also aren't in scope when stdio.h is included, and the fix is not to add them to stdio.h. I really disagree. A legacy application *can't* be said to be buggy. Depends how legacy. There has to be some allowance for the continuity of code; it can't just be orphaned instantaneously, without some warning from the system vendor. A warning was given here more than 4 years ago: % RCS file: /home/ncvs/src/include/ieeefp.h,v % Working file: ieeefp.h % head: 1.6 % ... % % revision 1.1 % date: 1998/12/23 11:50:52; author: dfr; state: Exp; % branches: 1.1.2; % Implement fpsetmask() and other fp*() functions. Programs should use % % #include ieeefp.h % % to access these functions instead of the i386 specific % % #include machine/floatingpoint.h % % Submitted by: Hidetoshi Shimokawa [EMAIL PROTECTED] % Say we took your approach, and moved the #define's for the inlines up into ieeefp.h, exposing platform dependencies in a (supposedly) platform independent header file. How many ports would break? All Not my approach. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
[EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? 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 Mon Jan 13 15:06:42 PST 2003 -- Kernel build for GENERIC completed on Mon Jan 13 15:41:51 PST 2003 -- Kernel build for LINT started on Mon Jan 13 15:41:52 PST 2003 -- === vinum Makefile, line 4445: warning: duplicate script for target geom_bsd.o [...] /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...] /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...] /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...] cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] *** 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
FreeBSD on Dell Inspiron 8200 notebook
Greetings: Is anyone running FreeBSD on a Dell Inspiron 8200 notebook? I'm trying to figure out if there is a way to prevent the notebook from suspending when the lid is closed. Thanks. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD on Dell Inspiron 8200 notebook
* Vincent Poy ([EMAIL PROTECTED]) wrote: Greetings: Is anyone running FreeBSD on a Dell Inspiron 8200 notebook? I'm trying to figure out if there is a way to prevent the notebook from suspending when the lid is closed. Thanks. On mine, there are a load of settings in the BIOS to do with what the laptop does when it is on AC/Battery and you close the lid etc. It may be worth messing around with those and seeing if it sorts the problem out. I don't remember mine suspending when I close the lid but then again, I have always been on the AC when I do so. HTH Al -- I'm just Al LJ : http://www.livejournal.com/users/everlone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD on Dell Inspiron 8200 notebook
On Tue, 14 Jan 2003, Alistair Sutton wrote: * Vincent Poy ([EMAIL PROTECTED]) wrote: Greetings: Is anyone running FreeBSD on a Dell Inspiron 8200 notebook? I'm trying to figure out if there is a way to prevent the notebook from suspending when the lid is closed. Thanks. On mine, there are a load of settings in the BIOS to do with what the laptop does when it is on AC/Battery and you close the lid etc. It may be worth messing around with those and seeing if it sorts the problem out. I don't remember mine suspending when I close the lid but then again, I have always been on the AC when I do so. HTH Al Actually, in the BIOS, I already have the close lid changed from suspend to I think active and it didn't make a difference. When I closed the lid, it just suspends still. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD on Dell Inspiron 8200 notebook
Vincent Poy wrote: Greetings: Is anyone running FreeBSD on a Dell Inspiron 8200 notebook? I'm trying to figure out if there is a way to prevent the notebook from suspending when the lid is closed. Thanks. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I have that notebook, and I have the same problem. Setting the hw.acpi sysctls that control the sleep states and actions doesn't seem to make a difference. Disabling acpi might make it work (haven't tried), but then it probably won't route interrupts from the cardbus slots anymore. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
On Mon, 13 Jan 2003, walt wrote: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? gpt I don't know where it comes from but I believe it's the native partition format for ia64 architecture machines. 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: FreeBSD on Dell Inspiron 8200 notebook
* Vincent Poy ([EMAIL PROTECTED]) wrote: On Tue, 14 Jan 2003, Alistair Sutton wrote: * Vincent Poy ([EMAIL PROTECTED]) wrote: Greetings: Is anyone running FreeBSD on a Dell Inspiron 8200 notebook? I'm trying to figure out if there is a way to prevent the notebook from suspending when the lid is closed. Thanks. On mine, there are a load of settings in the BIOS to do with what the laptop does when it is on AC/Battery and you close the lid etc. It may be worth messing around with those and seeing if it sorts the problem out. I don't remember mine suspending when I close the lid but then again, I have always been on the AC when I do so. Actually, in the BIOS, I already have the close lid changed from suspend to I think active and it didn't make a difference. When I closed the lid, it just suspends still. Changing the options so that they are set to suspend appears to have landed me with the same problem now. Despite changing them back so that the screen should stay active, the laptop now suspends whenever I close the lid. I have a feeling this is going to take quite a few hours of fiddling to get sorted (if it is even possible to sort it). Al -- I'm just Al LJ : http://www.livejournal.com/users/everlone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
Julian Elischer wrote: On Mon, 13 Jan 2003, walt wrote: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? gpt I don't know where it comes from but I believe it's the native partition format for ia64 architecture machines. Pros: - fully 64 bit clean - maximum of 16384 partitions - unique id's for disks, partitions and OS types. - we already have the basic code support for it in the tree. - its on intel's roadmap for future i386 servers (for what thats worth) along with EFI. - it is possible to boot from, but needs new boot code written(*). Cons: - If you follow the spec strictly, it will not share disks with another fdisk-using OS. If strictly implemented according to the specs, it replaces the fdisk MBR and owns the entire disk. Our code however isn't that strict and will accept a GPT inside an MBR slice, meaning for i386 we can use GPT as a replacement for disklabel. - Booting is interesting(*). * - When GPT is used with EFI, the firmware has got a mini OS in rom which has native FAT32 file system support, which means we can just mount the boot partition and copy loader.efi in there and there are *no* bootblocks.. However, if we were to use it standalone we would not have this and would have to boot ourselves. The way this would be done is to put real boot code in the MBR, which would scan the gpt table to find a boot partition that contained the equivalent of what is now boot2. We could make this as big as we liked, but I'd imagine it would be 64K by default. That boot2 code would then be able to read UFS natively, just like now. In other words, it wouldn't be all that different to now except that somebody has to write it. Alternatively, we could deviate a bit from the strict specs and reserve the entire first track for boot code and avoid the problem that way. This would be easier and less likely to run into major code space pressure problems as it wouldn't have to parse GPT tables. Personally, unless EFI on i386 actually gets off the ground, if somebody is seriously considering this, I'd be inclined to suggest using a fairly loose gpt interpretation and using gpt as a replacement for disklabel inside a freebsd slice. That way it is easy to play nice with other OS's and less pain to deal with for booting. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Important, agp_via.c missing PCI ID!
On Mon, 13 Jan 2003 16:16:51 -0500 (EST) John Baldwin [EMAIL PROTECTED] wrote: On 13-Jan-2003 David Holm wrote: What is the output of 'dmesg | grep agp' both with and without the patch? Now this is strange. I cvsupped before recompiling the kernel. Now all I get when loading the module (with or without the patch): pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND I don't understand why it doesn't fall back to the generic. //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Important, agp_via.c missing PCI ID!
On Tue, 14 Jan 2003 03:14:59 +0100 David Holm [EMAIL PROTECTED] wrote: On Mon, 13 Jan 2003 16:16:51 -0500 (EST) John Baldwin [EMAIL PROTECTED] wrote: On 13-Jan-2003 David Holm wrote: What is the output of 'dmesg | grep agp' both with and without the patch? Now this is strange. I cvsupped before recompiling the kernel. Now all I get when loading the module (with or without the patch): pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND I don't understand why it doesn't fall back to the generic. My mistake, I didn't preload the module. I thought I could load it on a booted system. Anyway, with the standard agp module preloaded I get the following: pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND With my modified version I get: Preloaded elf module /boot/kernel/agp.ko at 0xc0551154. agp0: VIA 82C694X (Apollo Pro 133A) host to PCI bridge mem 0xe000-0xefff at device 0.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND I added some debug output to agp_via.c to see what was going on: agp0: id is 0x6051106 (- it prints the device id returned by pci_get_devid(dev)) pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) It seems it never enters the generic but goes past it and returns NULL. (I even modified the line to and the result of pci_get_vendor(dev) with 0x) Also, acpi returns this which confirms my mobo model: acpi0: ASUS CUV4Xon motherboard //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[simon@uow.edu.au: Problems installing 5.0 RC2 on a Compaq Amarda M700 (acpi problems)]
Sent this to questions@ got no response. Hoping someone in here can help me. - Forwarded message from Simon Coggins [EMAIL PROTECTED] - Date: Sat, 11 Jan 2003 21:56:29 +1100 From: Simon Coggins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Problems installing 5.0 RC2 on a Compaq Amarda M700 (acpi problems) Organisation: University of Wollongong (http://www.uow.edu.au/) Hi, I'm having a problem installing 5.0 RC2 from cd onto my Compaq amarda M700 laptop. I get errors from acpi on boot that look like: ACPI-1287: *** Method execution failed. AE_AML_BUFFER_LIMIT And a complaint about tempurature. Then it tries to mount the memory file system and hangs. If I use unset acpi_load it boots up, (lots of unknown pci problems) but it boots and will install. After installation the system will not boot as it can't mount the root file system. I get : setrootbyname failed ffs_mountroot: can't find rootvp root mount failed: 6 If I again do a unset acpi_load, the system boots and I can log in. I've tried set hw.acpi.ec.event_driven=1 and that didn't make a different. I've captured acpidump and dmesg if you want to look at that. http://chaotic.oz.org/other/bsd-5.0/erwin-5.0RC2-acpidump.txt http://chaotic.oz.org/other/bsd-5.0/erwin-5.0RC2-dmesg.txt Any ideas? -- Simon Coggins (SAGE-AU Member)Email: [EMAIL PROTECTED] Network and System Management Officer Phone: +61-2-4221-3775 Information Technology Systems (ITS) Mobile: 0408 115861 University of Wollongong, 2522, Australia Fax: +61-2-4229-1985 - End forwarded message - -- Simon Coggins (SAGE-AU Member)Email: [EMAIL PROTECTED] Network and System Management Officer Phone: +61-2-4221-3775 Information Technology Systems (ITS) Mobile: 0408 115861 University of Wollongong, 2522, Australia Fax: +61-2-4229-1985 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: fpsetmask on sparc64
Bruce Evans wrote: There has to be some allowance for the continuity of code; it can't just be orphaned instantaneously, without some warning from the system vendor. A warning was given here more than 4 years ago: [ ... ] This was a commit log message; that's very different than a #warning in the header file. Say we took your approach, and moved the #define's for the inlines up into ieeefp.h, exposing platform dependencies in a (supposedly) platform independent header file. How many ports would break? All Not my approach. It's as close to your approach as we are likely to get, unless people are willing to rip out the inlining on the i386, and replace it with libc/gen/*.c code, so that they can put in pure prototypes in the header file, and take the additional overhead that this causes, relative to, say, Linux or some other OS that inlines the code. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Can't mount /dev/acd0c with rc3 install
I have been unable to install FreeBSD 5.0rc[1,2,3] from CD. After I have selected all my options, it will format the disk and then complain that it can not mount my IDE DVD drive (it is new, it could not mount my old one either -- or my CD drive on acd1c). However, I am able to install with a network (FTP) install and I can mount the CD manually without trouble. I am using a Asus K7V motherboard (VIA chipset) with a classic Athlon 600 MHz processor and 384MB PC133. Tom Veldhouse To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problems after resume from suspend in current as ofJanuary 9
on resume with a usbdevs -v I get ... Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x), AcerLabs(0x), rev 1.00 port 1 addr 2: low speed, power 100 mA, config 1, USB Mouse(0xc00c), Logitech(0x046d), rev 6.20 port 2 powered port 3 powered Regardless of whether the mouse is plugged in or not. I also tried plugging in an intellimouse explorer a usb keyboard, both of which failed to work, neither were powered up at all. I should note that under 4.7 suspend and resume works fine. I tried to kill and restart usbd but no luck. So for now I'm stuck with shutting down the system. Cheers, Mark On Tue, 2003-01-14 at 09:28, Marc Butler wrote: On Fri, Jan 10, 2003 at 12:22:22PM +1100, Mark Sergeant wrote: I'm running a toshiba portege 4000 with -CURRENT as of January 9. Suspending and resuming runs fine apart from USB, on resume it is unable to recognise my USB mouse (logitech), nothing even registers that it is plugged in, nor does the mouse get any power yet on booting normally USB works fine. Has anyone got any ideas how I can work around this issues ? It may be the USB controller is being shutdown and not restarted. To check whether the USB controller is up try: usbdevs -v which I believe should complain: no USB controllers found or similar. You may want to check the BIOS for any obvious settings related to USB and power management. Is ACPI involved in suspension? I'm sorry but I know nothing about ACPI (or laptop power management). -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
In message [EMAIL PROTECTED], walt writes: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? Probably EFI/GPT labels -- 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
