compile problem
I'm seeing this on a -CURRENT cvsupped around 4:30 AM EST on 1/11/03 cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../kern/kern_sysctl.c ../../../kern/kern_sysctl.c: In function `ogetkerninfo': ../../../kern/kern_sysctl.c:1393: `VM_METER' undeclared (first use in this function) ../../../kern/kern_sysctl.c:1393: (Each undeclared identifier is reported only once ../../../kern/kern_sysctl.c:1393: for each function it appears in.) *** Error code 1 Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 without swap
I am about to set up a FreeBSD 5.0 machine without a swap partition. The server has 1GB of RAM. Are there any caveats that I need to consider during installation or configuration? Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 without swap
On Sat, 11 Jan 2003 01:58:31 -0800 "Lucky Green" <[EMAIL PROTECTED]> wrote: Hi, > I am about to set up a FreeBSD 5.0 machine without a swap partition. > The server has 1GB of RAM. Are there any caveats that I need to > consider during installation or configuration? Having no swap will prevent you from getting crashdumps in case of panic which, if you run 5.0, is not that unusual. Besides these days harddrives cost $1/GB, so why not setup the swap partition anyway? Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Of course it runs NetBSD! msg49986/pgp0.pgp Description: PGP signature
Re: 5.0 without swap
Thus spake Lucky Green <[EMAIL PROTECTED]>: > I am about to set up a FreeBSD 5.0 machine without a swap partition. The > server has 1GB of RAM. Are there any caveats that I need to consider > during installation or configuration? If you're using sysinstall, it might insist that you have swap. Then again, that may be fixed by now. Beyond that, you won't be able to take kernel crash dumps, and you'll have to be careful that you don't run out of RAM. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: 5.0 without swap
Miguel wrote: > Having no swap will prevent you from getting crashdumps in > case of panic which, if you run 5.0, is not that unusual. > Besides these days harddrives cost $1/GB, so why not setup > the swap partition anyway? I don't want cleartext cryptographic keys to ever touch magnetic media, thus potentially opening the door to future forensic analysis. --Lucky, who thought that he once, many years ago, read that there was a kernel option one should set if you have no swap partition. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>: phk> I only have 2G ram and that's what I have tested (extensively). If we're phk> still broken for >2G ram, somebody needs to revist this. phk> phk> One thing you can try is reduce the value of the phk>sysctl kern.maxvnodes phk> phk> If you set it to the same value as used for 2G (appros 13), I phk> think your machine should survive with 3G RAM. Thank you for the clarification. I notice that the panic happens when numvnodes becomes more than about 185000. When kern.maxvnodes=13 (198799 by default) is specified, the system works fine under heavy loads during this week. Is anyone else suffering from it? If it happens on all of >2GB systems, I think it should be solved (or described in relnotes) before the release. -- | Hiroki SATO <[EMAIL PROTECTED]> 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 Sat Jan 11 03:05:32 PST 2003 -- ===> vinum /h/des/src/sys/kern/kern_sysctl.c: In function `ogetkerninfo': /h/des/src/sys/kern/kern_sysctl.c:1393: `VM_METER' undeclared (first use [...] /h/des/src/sys/kern/kern_sysctl.c:1393: (Each undeclared identifier is re [...] /h/des/src/sys/kern/kern_sysctl.c:1393: for each function it appears in.) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/GENERIC. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 without swap
Thus spake Lucky Green <[EMAIL PROTECTED]>: > Miguel wrote: > > Having no swap will prevent you from getting crashdumps in > > case of panic which, if you run 5.0, is not that unusual. > > Besides these days harddrives cost $1/GB, so why not setup > > the swap partition anyway? > > I don't want cleartext cryptographic keys to ever touch magnetic media, > thus potentially opening the door to future forensic analysis. You can accomplish that by wiring the pages containing your cryptographic keys, rather than effectively wiring every page in the system by having no swap space. Alternatively, unless you're really paranoid, it's probably sufficient to write over your swap partition with random data before you shut down the system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ia64 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Jan 11 04:11:36 PST 2003 -- ===> xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /home/tinderbox/ia64/src/sys/kern/kern_sysctl.c: In function `ogetkerninfo': /home/tinderbox/ia64/src/sys/kern/kern_sysctl.c:1393: `VM_METER' undeclared (first use in this function) /home/tinderbox/ia64/src/sys/kern/kern_sysctl.c:1393: (Each undeclared identifier is reported only once /home/tinderbox/ia64/src/sys/kern/kern_sysctl.c:1393: for each function it appears in.) *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. 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 11 Jan 2003 16:20:45 +1100 Mark Sergeant <[EMAIL PROTECTED]> wrote: > Both are turned on yes. Restarting both doesn't work, nothing works when > plugged into the usb ports after a resume. usbd automatically starts moused for an usb mouse. Maybe the existing moused and the moused started from usbd interfere... Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler 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: 5.0 without swap
On Sat, 11 Jan 2003 11:08:19 +0100 Miguel Mendez <[EMAIL PROTECTED]> wrote: > Having no swap will prevent you from getting crashdumps in case of > panic which, if you run 5.0, is not that unusual. What about generating a swap partition on the disk, but _not_ adding it to /etc/fstab. This way you can use the partition as a dumpdev, but without enabling the use of the swap in the system. Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler 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: 5.0 without swap
On Sat, Jan 11, 2003 at 02:16:45AM -0800, Lucky Green wrote: > Miguel wrote: > > Having no swap will prevent you from getting crashdumps in > > case of panic which, if you run 5.0, is not that unusual. > > Besides these days harddrives cost $1/GB, so why not setup > > the swap partition anyway? > > I don't want cleartext cryptographic keys to ever touch magnetic media, > thus potentially opening the door to future forensic analysis. > > --Lucky, who thought that he once, many years ago, read that there was a > kernel option one should set if you have no swap partition. > > It seems like you can encrypt swap with GBDE, at least that's what one item at http://www.freebsd.org/releases/5.0R/todo.html says. The manpage doesn't mention encrypting swap though. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49995/pgp0.pgp Description: PGP signature
Re: 5.0 without swap
On Sat, Jan 11, 2003 at 04:22:40PM +0100, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Christian Brueffer writes: > > >It seems like you can encrypt swap with GBDE, at least that's what one > >item at http://www.freebsd.org/releases/5.0R/todo.html says. > >The manpage doesn't mention encrypting swap though. > > GBDE encrypts disk partitions, you can put swap, ufs, msdosfs or > even oracle inside the encrypted partitions, GBDE doesn't care. > Nice, thanks for the clarification. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49996/pgp0.pgp Description: PGP signature
Re: 5.0 without swap
On Sat, 11 Jan 2003, David Schultz wrote: > Thus spake Lucky Green <[EMAIL PROTECTED]>: > > I am about to set up a FreeBSD 5.0 machine without a swap partition. The > > server has 1GB of RAM. Are there any caveats that I need to consider > > during installation or configuration? > > If you're using sysinstall, it might insist that you have swap. > Then again, that may be fixed by now. Beyond that, you won't be > able to take kernel crash dumps, and you'll have to be careful > that you don't run out of RAM. Kernel crash dumps may be made on almost any disk device. Swap devices just give a device that is safe to clobber with dumps. (I rarely use either a swap device or a dump device, but sometimes enable them independently as needed.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
Peter, reverting the revisions below *does* fix the problem. Tim has an alternative patch, though. At any rate, it seems kbyanc's solution was overly simplistic. But things are broken either way, and I'm not sure Tim's patch doesn't result in the kind of situation rev 1.134 tried to fix, nor if his patch actually gets all cases of the bug that results from 1.134. At any rate, I think that not receiving any event (after 1.134) is worse than receiving and event claim to have more bytes than are actually available (pre 1.134). It's not just Juli who have this problem. AilleCat, for instance, once she heard on irc that kq had a problem, tracked the problem *she* was having to the same place. Peter Wemm wrote: > > Tim Robbins wrote: > > On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote: > > > > > Lately, the data field for sockets, which holds bytes ready (in the EVFILT_ > > > READ case) to be read, is computed to be zero. This means that if you have > > > a low watermark which is >0 per the kq, THE EVENT WILL NEVER HAPPEN. Not t > o > > > mention that this means when the event IS triggered properly (if you can > > > call it that), it is always said to have =ZERO= bytes ready. > > [...] > > > > I can definitely reproduce this here and also fairly angry about it. > > In addition to what you mentioned, fstat() gives an incorrect st_size > > result now and it's likely that non-NOTE_LOWAT low watermarks are > > firing too early as well. > > > > Ugly test program @ http://people.freebsd.org/~tjr/kq.c > > In case anybody wants to play, I seem to recall some changes in uipc_socket.c > that caused some problems (totally hosed the resolver) a while back: > > revision 1.134 > date: 2002/11/01 21:27:59; author: kbyanc; state: Exp; lines: +1 -1 > Track the number of non-data chararacters stored in socket buffers so that > the data value returned by kevent()'s EVFILT_READ filter on non-TCP > sockets accurately reflects the amount of data that can be read from the > sockets by applications. > > PR: 30634 > Reviewed by:-net, -arch > Sponsored by: NTT Multimedia Communications Labs > MFC after: 2 weeks > > revision 1.136 > date: 2002/11/05 18:48:46; author: kbyanc; state: Exp; lines: +1 -1 > Fix filt_soread() to properly flag a kevent when a 0-byte datagram is > received. > > Verified by:dougb, Manfred Antar <[EMAIL PROTECTED]> > Sponsored by: NTT Multimedia Communications Labs > > > Is this related? > > 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 -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Spellng is overated anywy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ia64 tinderbox failure
* To: Cyberpunk <[EMAIL PROTECTED]> * Subject: Re: its a joke * From: Bill Fumerola <[EMAIL PROTECTED]> * Date: Tue, 9 Dec 1997 19:47:26 -0500 (EST) * cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> * In-Reply-To: <[EMAIL PROTECTED]> * Sender: [EMAIL PROTECTED] On Tue, 9 Dec 1997, Cyberpunk wrote: > > Silence == bot. I don't think so. There are (proven) ways of detecting a > > If that were the case then I guess the opers should be k-lined too after > all I've seen some with long idle times. Note the sarcastic "I don't think so." after my first sentence. Learn to read before you respond you clueless fuck. -. Bill Fumerola (NIC:BF1560) | Internet 123, Ltd. | email:[EMAIL PROTECTED] or pager:[EMAIL PROTECTED] | Computer Horizons Corp. Programmer (NASDAQ:CHRZ) | -/ ps. don't even start that 'uworld' thing you were saying two messages back because it only turns into a penis war. _ gifts, travel, e-cards, free e-mail, and more! .. http://www.egypt7000.com .. _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 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/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Jan 11 09:37:13 PST 2003 -- ===> vesa /local0/scratch/des/src/sys/pci/if_rl.c: In function `rl_attach': /local0/scratch/des/src/sys/pci/if_rl.c:991: `COREGA_DEVICEID_CBTXD' unde [...] /local0/scratch/des/src/sys/pci/if_rl.c:991: (Each undeclared identifier [...] /local0/scratch/des/src/sys/pci/if_rl.c:991: for each function it appears in.) *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ia64 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Jan 11 10:09:51 PST 2003 -- ===> xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /home/tinderbox/ia64/src/sys/pci/if_rl.c: In function `rl_attach': /home/tinderbox/ia64/src/sys/pci/if_rl.c:991: `COREGA_DEVICEID_CBTXD' undeclared (first use in this function) /home/tinderbox/ia64/src/sys/pci/if_rl.c:991: (Each undeclared identifier is reported only once /home/tinderbox/ia64/src/sys/pci/if_rl.c:991: for each function it appears in.) *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$BL$>5Bz9-9p"(!z:#G/$N1?@*!z(J
<MÒ>
dq[LÐ
¡ãALð²ó]³êÈ¢ûͱ±Ö
[EMAIL PROTECTED]
K¸{¶É ȽÌ[AhXÌÝ𨫺³¢
===
ÐÌåÈLÍð©µÜ¹ñ©I
zMƱ©çz[y[W»ìÜÅiÀÉĨó¯vµÜ·B
ºLe`wÉĨ\µÝº³¢B
===
§104-0061
sæâÀ8-19-3
æ2ECOr@3F
[}KWs
TEL@001-373-188-8477
FAX@03-3544-6218@@
===
âè¤iΩèWßܵ½BÁ³êé°êª èÜ·ÌÅ
¨\ÝͨßÉI
=
\\\\\\\\\\\\\\\\\\\\\\\\
rfIÌEÁê_b`CtErlNu
@@ `ujDåWEðÛErdwthEA_gObYÈÇ
@A_gÖAÌîñÚ@
@@¨\ÝE²¶E¤iÚ×Í@
@@@@@ºLtqkðNbNµÄ²º³¢B
«@@@@«@@@@«@
@@@http://218.5.79.238:4
\\\\\\\\\\\\\\\\\\\\\\\\
@@J^ObYEÉéîñEhÆObYEàׯîñÈÇ@
@@@@@@@@@@»Ì¼îñÚ@
@@¨\ÝE²¶E¤iÚ×Í@
@@@@@ºLtqkðNbNµÄ²º³¢B
«@@@@«@@@@«@
http://white.yaboo.dk/
\\\\\\\\\\\\\\\\\\\\\\\\
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
--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 but it continues booting. Just after normal msgs about fd0 & ppc, it starts spewing unending messages so fast I can't read them well. Something like this, over and over: vm_fault: pager read error pid 1 error 5 [...] spec_getpages: (md0) [...] 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. Get another floppy, format it, copy the boot.flp image onto it, and see if you're still having the errors. Apparently I have an Intel chipset. From boot msgs: Intel 82371SB PCI to ISA bridge Intel PIIX3 ATA controller fdc0 NEC 72065B or clone The 'puter installs Linux and FreeBSD 4.7 OK (except only Linux will boot from the CD). There were only a few msgs at groups.google.com with that error msg and not much help, but then I don't need 5.0 and so don't need help. BTW, that "md0" looked interesting to me because I just had this error on my main 5.0 (08'jan'03) system when trying to fix my script which uses (used) obsolete "vnconfig". $ XXX=$(mdconfig -a -t vnode -u 0 /big/ftp/pub/5.0-RC2-i386-disc1.iso) mdconfig: ioctl(/dev/mdctl): Bad address 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: releng_5_0 tun device drops packets that bpf recieves
Sorry for replying to myself. I forgot to mention the firewall rules. They are: diskless# ipfw show 00100 20 1776 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 346959 94613554 allow ip from any to any 65535 0 0 deny ip from any to any which is the default 'firewall_type="OPEN"'. --- Galen Sampson <[EMAIL PROTECTED]> wrote: > Hello All, > > I have recently been using windows to connect to the net with dialup. The > reason I haven't been using FreeBSD is because the tun0 interface drops ~30% > of > the packets it recieves. I thought that perhaps the phone number I was > calling > was sending me bad packets (with checksum errors, etc.). That doesn't seem > to > be the case. My next guess was that my resolver wasn't set up correctly, and > that was why all of my applications (mozilla, cvsup) couldn't reach hosts. I > used ethereal (snooping interface tun0, the interface that was used as the > point to point link) and found that packets were sent, and recieved, but > nslookup would still claim a timeout. Finally I decided to ping a raw IP > address that I knew was up (i.e. don't use the resolver) while ethereal was > running. Ping would claim a 30% packet loss, while ethereal would recieve an > ICMP response for every ICMP request sent. > > Why would bpf recieve all traffic (with correct checksums) while user > appications (ping) would claim a 30% packet loss? > > My kernel has the following options: > > options INET#InterNETworking > options INET6 #IPv6 communications protocols > options IPSEC #IP security > options IPSEC_ESP #IP security (crypto; define w/ IPSEC) > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > options IPFIREWALL_FORWARD #enable transparent proxy support > options IPV6FIREWALL#firewall for IPv6 > options IPV6FIREWALL_VERBOSE > options IPDIVERT#divert sockets > options IPSTEALTH #support for stealth forwarding > devicegif # IPv6 and IPv4 tunneling > devicetun # Packet tunnel. > > Realizing that it is possible that some of these options may be affecting > this > situation I commented out everything but 'options INET' however the kernel > won't link (attached kernel config file). Is 'options INET6' required if you > want ip/icmp/tcp/udp support? > > regards, > Galen > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com> # > # GENERIC -- Generic kernel configuration file for FreeBSD/i386 > # > # For more information on this file, please read the handbook section on > # Kernel Configuration Files: > # > #http://www.FreeBSD.org/handbook/kernelconfig-config.html > # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the NOTES configuration file. If you are > # in doubt as to the purpose or necessity of a line, check first in NOTES. > # > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.329 2001/11/06 16:15:47 obrien Exp > $ > > machine i386 > cpu I686_CPU > ident DISKLESS > > #To statically compile in device wiring instead of /boot/device.hints > #hints"GENERIC.hints" #Default places to look for devices. > > options NFS_ROOT > options BOOTP #NFS Root for diskless booting > options BOOTP_NFSROOT #NFS Root for diskless booting > > options INET#InterNETworking > #options INET6 #IPv6 communications protocols > #options IPSEC #IP security > #options IPSEC_ESP #IP security (crypto; define w/ IPSEC) > #options IPFIREWALL #firewall > #options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > #options IPFIREWALL_FORWARD #enable transparent proxy support > #options IPV6FIREWALL#firewall for IPv6 > #options IPV6FIREWALL_VERBOSE > #options IPDIVERT#divert sockets > #options IPSTEALTH #support for stealth forwarding > #options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default > #Must allow everything for diskless at > #first > > options
panic: trap: fast data access mmu miss
Running on a Sun Enterprise 250 with a single UltraSparc-II CPU, 512 MB RAM
and three Fujitsu SCSI-II hard disks. I've had this same problem with
sources over the past few (three?) days. I had to copy this dmesg by hand,
so please bear with any possible typos.
--8<--
picb1: at device 2.0 on pci0
pci1: on pcib1
isp0: port 0x1000-0x10ff mem
0x4008000-0x4008fff irq 16 at device 4.0 on pci1
isp0: invalid NVRAM header
sym0: <875> port 0x2000-0x20ff mem 0x410a000-0x410afff,0x4108000-0x41080ff
irq 32 at device 3.0 on pci0
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
sym1: <875> port 0x2400-0x24ff mem 0x410e000-0x410efff,0x410c000-0x410c0ff
irq 38 at device 3.1 on pci0
panic: trap: fast data access mmu miss
cpuid = 0;
Debugger("panic")
Stopped at Debugger+0x1c: ta %xcc, 1
db> trace
panic() at panic+0x134
trap() at trap+0x414
-- fast data access mmu miss tar=0 %o7=0xc0248c00 --
getbaddrcb() at getbaddrcb
psycho_dmamap_load() at psycho_dmamap_load+0x30
___dma_getp() at ___dma_getp+0xb8
___sym_malloc() at ___sym_malloc+0x70
__sym_calloc2() at __sym_calloc2+0xc
__sym_calloc_dma() at __sym_calloc_dma+0x64
sym_pci_attach() at sym_pci_attach+0x38
device_probe_and_attach at device_probe_and_attach+0xb8
bus_generic_attach() at bus_generic_attach+0x10
pci_attach() at pci_attach+0x9c
device_probe_and_attach at device_probe_and_attach+0xb8
bus_generic_attach() at bus_generic_attach+0x10
psycho_attach() at psycho_attach+0x9d8
device_probe_and_attach at device_probe_and_attach+0xb8
bus_generic_attach() at bus_generic_attach+0x10
device_probe_and_attach at device_probe_and_attach+0xb8
root_bus_configure() at root_bus_configure+0x18
configure() at configure+0x20
mi_startup() at mi_startup+0x12c
btext() at btext+0x30
db>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Important, agp_via.c missing PCI ID!
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 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 Sat Jan 11 15:08:33 PST 2003 -- >>> Kernel build for GENERIC completed on Sat Jan 11 15:44:08 PST 2003 -- >>> Kernel build for LINT started on Sat Jan 11 15:44:08 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/dev/usb/umodem.c:106: syntax error before numeric constant cc1: warnings being treated as errors /h/des/src/sys/dev/usb/umodem.c:106: warning: type defaults to `int' in d [...] /h/des/src/sys/dev/usb/umodem.c:106: warning: function declaration isn't [...] /h/des/src/sys/dev/usb/umodem.c:106: warning: data definition has no type [...] /h/des/src/sys/dev/usb/umodem.c:108: syntax error before '&' token /h/des/src/sys/dev/usb/umodem.c:108: warning: type defaults to `int' in d [...] /h/des/src/sys/dev/usb/umodem.c:108: warning: function declaration isn't [...] /h/des/src/sys/dev/usb/umodem.c:108: warning: data definition has no type [...] /h/des/src/sys/dev/usb/umodem.c: In function `umodem_detach': /h/des/src/sys/dev/usb/umodem.c:780: `flags' undeclared (first use in thi [...] /h/des/src/sys/dev/usb/umodem.c:780: (Each undeclared identifier is repor [...] /h/des/src/sys/dev/usb/umodem.c:780: for each function it appears in.) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On Sat, 11 Jan 2003, Daniel C. Sobral wrote: > Peter, reverting the revisions below *does* fix the problem. Tim has an > alternative patch, though. At any rate, it seems kbyanc's solution was > overly simplistic. But things are broken either way, and I'm not sure > Tim's patch doesn't result in the kind of situation rev 1.134 tried to > fix, nor if his patch actually gets all cases of the bug that results > from 1.134. > > At any rate, I think that not receiving any event (after 1.134) is worse > than receiving and event claim to have more bytes than are actually > available (pre 1.134). It's not just Juli who have this problem. > AilleCat, for instance, once she heard on irc that kq had a problem, > tracked the problem *she* was having to the same place. > Yes, this is correct, some events weren't being triggered and now, with reverting back (with some of the current changes like the aesthetic change to soo_kqfilter instead of sokqfilter,) now our application that relies upon kqueue for scheduling runs about twice as fast Maxim gave me a patch that accomplishes exactly what I did by hand... but it also leaves it in a state that it was before 1.134 where there were some problems that were supposed to be fixed in 1.134 and after... however IMO its *less* broken :) Anyway, since my understanding of this is much less than anyone else I'm inclined to go with whatever solution actually makes the events trigger for us :) I'm not a kernel programmer, nor will I ever be, I just know that reverting uipc_socket.c did solve some major problems I was having :) -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: Sound playback problem with Maestro3.c (?)
This is a software issue. The echoing is what happens when the sound driver doesn't receive audio data fast enough from an application (ie OSS). when the driver doesn't get the data in time, it plays whatever was last in the buffer until it does get audio. this sort of thing always happens no matter what the platform. My experience with BSD, and any not-successfully preemptive kernels is that io and process sceduling never provides proper attention to the processes requiring enough power for smooth audio. I beleive 5.0 will appreciate this point, and this mailing list would be a good place to start. Disk IO has always been a big factor for me. I've moved my audio development from my FBSD/Inspiron 8000 into the ASIO/DirectX arena for performance reasons. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Ferguson Sent: Tuesday, January 07, 2003 5:48 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Sound playback problem with Maestro3.c (?) Hi all, I'm experiencing a small issue with the sound output on the Maestro3 in my Dell Inspiron 8000 laptop. Every few seconds, the sound is briefly "interrupted", and the last few ms of audio are looped for about a quarter of a second. I've noticed that this can happen independently on either channel; often it will pause/loop on the left channel, then shortly thereafter on the right, or visa versa. Other times it will pause/loop on both channels at the same time. I've also noticed this condition can be exaggerated by moving the mouse while moused is running; the sound pause/loops much more frequently (although not for as long), and the music becomes noticeably slower. This happens both when moving the built-in PS/2 touchpad mouse and on a USB mouse, if I plug one in. My only ignorant guess would be that this is some kind of interrupt polling issue, but since I am new to BSD and I have no clue about the driver architecture or PCM, I can only venture a guess. :/ I was experiencing this in the 4.7-release kernel also (this bug is actually why I upgraded to -current :P). Some other users appear to be having the same problems (even when porting the driver to NetBSD?). Here are some links: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF8&threadm=a6u7p 2%24vlc%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1&prev=/groups%3Fq%3DFreeBSD %2BMaestro3%2Bpopping%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF8%26selm% 3Da6u7p2%2524vlc%25241%2540FreeBSD.csie.NCTU.edu.tw%26rnum%3D1 http://mail-index.netbsd.org/current-users/2001/08/23/0004.html I tried compiling without PNP and APM in the 4.7-release kernel, but I still saw the same issues, so I don't think they're entirely tied to that (especially since I'm running ACPI now in -current, without any apmd). My laptop is running the latest bios (A21), and the sound card has ID card=0x00a41028 chip-0x1998125d rev=0x10; my dmesg and pciconf output are also at ftp://129.110.23.84/. On a probably-unrelated side note, when I was running Linux on the same laptop (ducks), I had issues with the OS clock getting quickly out of sync with the HW clock; typically I would loose five minutes or more every hour. Although I haven't experienced the same thing with FreeBSD, I wonder if there is just something odd about interrupt handling or timing on the Inspiron 8000 line? Best regards, -- mcf 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: Sound playback problem with Maestro3.c (?) -- clock issue
never noticed anything like that -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul A. Mayer Sent: Wednesday, January 08, 2003 11:19 AM To: Michael Ferguson Cc: [EMAIL PROTECTED] Subject: Re: Sound playback problem with Maestro3.c (?) -- clock issue Hi Michael, Regarding your linux clock issue: There was a rather lively discussion at forums.gentoo.org about drastic clock sync loss caused by KDE. I don't know if it has been resolved in the 3.1 line, but if you were running linux KDE, you might take a look at that as a cause for the linux clock sync problem. /Paul Michael Ferguson wrote: > Hi all, > On a probably-unrelated side note, when I was running Linux on > the same laptop (ducks), I had issues with the OS clock getting quickly > out of sync with the HW clock; typically I would loose five minutes or > more every hour. Although I haven't experienced the same thing with > FreeBSD, I wonder if there is just something odd about interrupt > handling or timing on the Inspiron 8000 line? > 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
fpsetmask on sparc64
fpsetmask is not defined in or on sparc64 (it is on i386): /usr/include/machine/floatingpoint.h:#definefpsetmask(m)((fp_except_t) \ /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t); /usr/include/floatingpoint.h:#definefpsetmask(m)((fp_except_t) This appears to cause the following port failures/warnings: amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this function) glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use this function) lame-devel-3.89b.log:util.c:883: warning: implicit declaration of function `fpsetmask' smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function `fpsetmask' xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this function) Is this an omission, or are the ports wrong? Kris msg50011/pgp0.pgp Description: PGP signature
Re: 5.0 without swap
This is good stuff Geoffrey we may just "borrow" it. :) I know
you'ved saved me some work personally, as playing with gdbe is high on my
list of things to do.
Doug
On Sat, 11 Jan 2003, Geoffrey T. Falk wrote:
> For encrypting swap, try this:
>
>
> --- etc/rc.d/Makefile 22 Dec 2002 22:25:53 - 1.10
> +++ etc/rc.d/Makefile 12 Jan 2003 03:54:40 -
> @@ -4,7 +4,7 @@
> .include
>
> FILES= DAEMON LOGIN NETWORKING SERVERS abi accounting addswap adjkerntz amd \
> - apm apmd atm1 atm2.sh atm3.sh archdep bgfsck bootparams ccd cleanvar \
> + apm apmd atm1 atm2.sh atm3.sh archdep bdeswap bgfsck bootparams ccd cleanvar
>\
> cleartmp cron devd devdb devfs diskless dmesg dumpon fsck inetd \
> initdiskless initrandom ip6fw ipfilter ipfw ipmon ipnat ipsec \
> ipxrouted isdnd kadmind kerberos keyserv ldconfig local \
>
>
>
>
>
>
> etc/rc.d/bdeswap (new file):
>
> #!/bin/sh
> #
> # /usr/src/etc/rc.d/bdeswap
> #
> # Copyright (c) 2003 by Geoffrey T. Falk <[EMAIL PROTECTED]>.
> # All rights reserved.
> #
> # Prepare encrypted swap devices using GBDE
> #
> # Swap devices must be specified in /etc/fstab
> # as the bde device. This script detects all such
> # devices and configures them before they are
> # activated. Device should be specified with "noauto"
> # so that it is not picked up by swap1.
> # fstab Example:
> #/dev/ad0s1b.bde none swap sw,noauto 0 0
>
> # PROVIDE: bdeswap
> # REQUIRE: mountcritlocal
> # BEFORE: sysctl
> # KEYWORD: FreeBSD
>
> . /etc/rc.subr
>
> name="bdeswap"
> start_cmd="bdeswap_start"
> stop_cmd=":"
>
> # Generate a random password
> #
> randpass() {
> dd if=/dev/random bs=128 count=1 | cat -v
> }
>
> bde_attach()
> {
> DEV="$1"
> echo "Attaching encrypted swap device ${DEV}.bde"
>
> DEVBASE="`basename $DEV`"
> LOCK="/tmp/.gbde_lock.$DEVBASE"
> PASSWORD=`randpass`
> gbde init "$DEV" -P "$PASSWORD" -L "$LOCK"
> gbde attach "$DEV" -l "$LOCK" -p "$PASSWORD"
> }
>
> bdeswap_start()
> {
> case ${bde_swap} in
> [Yy][Ee][Ss])
> # Gather raw device name for each BDE swap device
> grep '^/dev/\w*\.bde\W*none\W*swap' /etc/fstab | \
> awk -F. '{print $1}' | \
> while read DEV; do
> bde_attach "$DEV"
> swapon "$DEV".bde
> done
> ;;
> esac
> }
>
> load_rc_config $name
> run_rc_command "$1"
>
>
>
> ###
>
> Geoffrey
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fpsetmask on sparc64
On Sat, Jan 11, 2003 at 07:16:26PM -0800, Kris Kennaway wrote: > fpsetmask is not defined in or > on sparc64 (it is on i386): > > /usr/include/machine/floatingpoint.h:#definefpsetmask(m)((fp_except_t) \ > /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t); > /usr/include/floatingpoint.h:#definefpsetmask(m)((fp_except_t) > > This appears to cause the following port failures/warnings: > > amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this >function) > glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use this >function) > lame-devel-3.89b.log:util.c:883: warning: implicit declaration of function >`fpsetmask' > smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function `fpsetmask' > xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this function) > > Is this an omission, or are the ports wrong? Here's another FP-related failure: http://bento.freebsd.org/errorlogs/sparc64-5-latest/xaos-3.0.log FP_X_DNML is defined on i386 in /usr/include/machine/ieeefp.h, but not on sparc64. Kris msg50013/pgp0.pgp Description: PGP signature
Re: fpsetmask on sparc64
On Sat, 11 Jan 2003, Kris Kennaway wrote:
> fpsetmask is not defined in or
> on sparc64 (it is on i386):
>
> /usr/include/machine/floatingpoint.h:#definefpsetmask(m)((fp_except_t) \
> /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t);
> /usr/include/floatingpoint.h:#definefpsetmask(m)((fp_except_t)
>
> This appears to cause the following port failures/warnings:
>
> amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this
>function)
> ...
> Is this an omission, or are the ports wrong?
First answer:
This is a bug in the ports. The non-i386 arches are apparently including
instead of the documented interface .
I think the ports are only meddling the FP mask to hide their FP errors
when running under FreeBSD-3.x and earlier anyway. They would have
to use to suppport FreeBSD-2.x since
didn't exist until FreeBSD-3.1. FreeBSD-4.0 and later hide FP errors
by default.
Second answer:
Ports should use the C99 interfaces fe{get,set}*() from , and then
only if C99 is supported. There might be problems with this too:
- C99 isn't supported yet.
- C99 doesn't have fesetmask(). This is partly because it would be
very unportable. It is not an IEEE FP feature. C99 only has
fesetenv(FE_DFL_ENV) to recover from any meddling with the FP
environment.
- Non-default FP environments should only be used in small sections
of code, since large parts of libraries, etc. are entitled to assume
that the environment is the default. So changing the FP mask to a
non-default value at program startup time would give undefined
behaviour if it were possible.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fpsetmask on sparc64
On Sat, 11 Jan 2003, Kris Kennaway wrote: > Here's another FP-related failure: > > http://bento.freebsd.org/errorlogs/sparc64-5-latest/xaos-3.0.log > > FP_X_DNML is defined on i386 in /usr/include/machine/ieeefp.h, but not > on sparc64. This is a bug in the port. Denormals are not in IEEE FP. i386 is the only supported arch that has them. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
if_sis.c failed to attach my SiS630 ethernet controller with the latest commit
Dear all, I have tracked down the change on sys/pci/if_sis.c ver. 1.61 failed to attach my SiS ethernet interface. I have an ASUS TUSI-M, a SiS630 motherboard and running the latest -current. After backed out if_sis.c to ver. 1.60, the ethernet works fine. Here's the dmesg extract related to the ethernet interface. I has turned on verbose boot, but it doesn't give me further information. sis0: port 0xd400-0xd4ff mem 0xe780-0xe7800fff irq 14 at device 1.1 on pci0 sis0: Ethernet address: 00:e0:18:00:00:03 sis0: MII without any PHY! device_probe_and_attach: sis0 attach returned 6 Regards, __ 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: fpsetmask on sparc64
Apparently, On Sat, Jan 11, 2003 at 07:16:26PM -0800, Kris Kennaway said words to the effect of; > fpsetmask is not defined in or > on sparc64 (it is on i386): > > /usr/include/machine/floatingpoint.h:#definefpsetmask(m)((fp_except_t) \ > /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t); > /usr/include/floatingpoint.h:#definefpsetmask(m)((fp_except_t) > > This appears to cause the following port failures/warnings: > > amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this >function) > glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use this >function) > lame-devel-3.89b.log:util.c:883: warning: implicit declaration of function >`fpsetmask' > smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function `fpsetmask' > xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this function) > > Is this an omission, or are the ports wrong? FWIW, the alpha headers are basically identical to the sparc64 ones. There may be missing ifdefs in the ports or the makefiles. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Fix man pages with iovec
Hi,
This patch fixes the read(2) and write(2) man pages
to accurately reflect the iovec structure defined
in and .
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
Index: read.2
===
RCS file: /home/ncvs/src/lib/libc/sys/read.2,v
retrieving revision 1.18
diff -u -r1.18 read.2
--- read.2 2002/12/19 09:40:25 1.18
+++ read.2 2003/01/12 07:05:27
@@ -85,7 +85,7 @@
.Pp
.Bd -literal -offset indent -compact
struct iovec {
- char *iov_base; /* Base address. */
+ void *iov_base; /* Base address. */
size_t iov_len;/* Length. */
};
.Ed
Index: write.2
===
RCS file: /home/ncvs/src/lib/libc/sys/write.2,v
retrieving revision 1.23
diff -u -r1.23 write.2
--- write.2 2002/12/19 09:40:25 1.23
+++ write.2 2003/01/12 07:05:28
@@ -85,7 +85,7 @@
.Pp
.Bd -literal -offset indent -compact
struct iovec {
- char *iov_base; /* Base address. */
+ void *iov_base; /* Base address. */
size_t iov_len;/* Length. */
};
.Ed
