Re: Way forward with BIND 8
On Sat, 7 Jun 2003, Brad Knowles wrote: This is a rather different statement than you previously gave. I've been extremely consistent in saying that I'm talking about the right thing to do _now_. I purposely tried to avoid confusing the issue with detailed plans for the future, however now that I know how much interest there is in this topic, I'll give more information to start with. But this is not at all how I interpreted your previous statements I can't be responsible for your perceptions. -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote: The compiler in 4.7 does not like this: -std=gnu99 As a result, buildworld of -CURRENT fails rather early. Committers are not required to support building 5-CURRENT, post 5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the change. However, someone will probably patch the build system to tolerate it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
On Fri, Jun 06, 2003 at 11:57:00PM -0700, David O'Brien wrote: On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote: The compiler in 4.7 does not like this: -std=gnu99 As a result, buildworld of -CURRENT fails rather early. Committers are not required to support building 5-CURRENT, post 5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the change. However, someone will probably patch the build system to tolerate it. That's a bit of an early call given that 5.x world is currently broken with the same error, as you know. Kris pgp0.pgp Description: PGP signature
LOR: dev/sound/isa/mss.c and dev/sound/pcm/channel.c
I was trying to get core or some sort of trace for what I think are kse related, but I get this instead. Randomly after this during various operations, my system totally locks up (I don't know enough, whether it's related or not). lock order reversal 1st 0xc40bb540 pcm0 (sound softc) @ /usr/src/sys/dev/sound/isa/mss.c:179 2nd 0xc40bb180 pcm0:play:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/channel.c :440 Stack backtrace: backtrace(c03e3e7c,c40bb180,c405ced4,c03d57a5,c03d587f) at backtrace+0x17 witness_lock(c40bb180,8,c03d587f,1b8,a) at witness_lock+0x697 _mtx_lock_flags(c40bb180,0,c03d587f,1b8,c40b9700) at _mtx_lock_flags+0xb2 chn_intr(c405ce80,18,0,1010b400,c40bb400) at chn_intr+0x2f mss_intr(c40b9700,0,c03deda1,216,c4091d3c) at mss_intr+0x8b ithread_loop(c4099080,d68e0d48,c03dec52,30c,0) at ithread_loop+0x182 fork_exit(c022cc70,c4099080,d68e0d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd68e0d7c, ebp = 0 --- -- Optimized, readable, on time; Pick any two. FreeBSD 5.1-CURRENT i386 3:17PM up 37 mins, 1 user, load averages: 0.56, 0.54, 0.46 signature.asc Description: This is a digitally signed message part
Re: Can't build -CURRENT on 4.7
On Sat, Jun 07, 2003 at 12:08:31AM -0700, Kris Kennaway wrote: On Fri, Jun 06, 2003 at 11:57:00PM -0700, David O'Brien wrote: On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote: The compiler in 4.7 does not like this: -std=gnu99 As a result, buildworld of -CURRENT fails rather early. Committers are not required to support building 5-CURRENT, post 5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the change. However, someone will probably patch the build system to tolerate it. That's a bit of an early call given that 5.x world is currently broken with the same error, as you know. I carefully worded the reply to specifically address build 5-CURRENT on 4.7. Can you try src/share/mk/bsd.sys.mk rev 1.29 to see if it fixes your problem? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
On Sat, Jun 07, 2003 at 01:07:24AM -0700, David O'Brien wrote: I carefully worded the reply to specifically address build 5-CURRENT on 4.7. Can you try src/share/mk/bsd.sys.mk rev 1.29 to see if it fixes your problem? Have you tested it thoroughly? Didn't you back out -std=c99 in a previous revision because it also caused problems? Kris pgp0.pgp Description: PGP signature
Virus Removal Notification
On 6/7/2003 the OWLS, Inc. mail server processed a message from your address that contained the W32/Sobig-C virus. The message was sent to [EMAIL PROTECTED] The OWLS, Inc. mail server removed the virus and notified the recipient. The message, without the detected virus attachments, is attached to this email as a zip file. Please note that the recipient of the original message was also sent this attachment. CleanMessage.zip Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
dhclient script in rc.d doesn't use ${dhcp_program} (conf/53007)
Hi folks- I'm happily using 5.1 and it's terrific. Keep up the great work. I just submitted a PR for a bug I noticed in the dhclient script. Namely, it ignores the setting of dhcp_program from rc.conf. A one-line fix did the trick for me, although there may be ramifications I'm not aware of. The PR is conf/53007. JN ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: imgact_gzip.c
In message [EMAIL PROTECTED], David Yeske wr ites: imgact_gzip.c seems to be pretty stale. Has anyone considered fixing this? If this were fixed then kldload() / linker_load_module() could deal with a gzipped .ko file, and gzipped elf executables would work also? At least originally imgact_gzip.c was heavily a.out aware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom_vol_ffs problems
In message [EMAIL PROTECTED], Per Kristian Hove writes: plan to growfs it later, and your fstab contains /dev/vol entries) the obvious thing would be to check the parent GEOM and check that the partition we're tasting is of type FS_BSDFFS. That would eliminate the c-partition problem. This does not work for FFS filesystems stored in apple or sun partitions, but theese do on the other hand, not have the magic 'c' problem. The problem here is the 'c' partitions magicness, and I have worked hard to make eliminate that magicness throughout, but due to the absolute diskoffset bogosity, we cannot dethaumagize it entirely yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient script in rc.d doesn't use ${dhcp_program}(conf/53007)
On Sat, 7 Jun 2003 03:18:18 -0600 John Nielsen [EMAIL PROTECTED] wrote: I just submitted a PR for a bug I noticed in the dhclient script. Namely, it ignores the setting of dhcp_program from rc.conf. A one-line fix did the trick for me, although there may be ramifications I'm not aware of. hmm it looks like the bug is actually our name for the program. In the new rc system there is glue code that automagically overides the command. But in order for it to work the variable has to be named a certain way in rc.conf. In this case the variable name is dhcp_program, but what it should really be is dhclient_program. This is another variable we're going to have to deprecate. Thanks for reporting this! Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
rcNG automonter(amd)
hi,
I have a problem with /etc/rc.d/amd, because of the line
command_args=
${amd_program} gets run in the background, ldconfig failes to cache libraries
in /usr/local/lib (which is automounted :-)
Is there realy a need for the ? amd will background itself after it's done
with the initialization stage anyway - and if not then it probably means
trouble.
danny
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On 6/6/2003 9:29 PM, Bernd Walter wrote: On Fri, Jun 06, 2003 at 01:17:43PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : I already wondered how you could route interrupts without ACPI until I : booted my printserver with a recent kernel. PCIBIOS! Well - I'm not very familar with what i386 offer here. Specs are available here, so I could read. But in any case Johns patch revived my printserver (old HX socket7 board). Either my BIOS is broken or FreeBSD doesn't use it correctly. Whatever - I can run tests on that machine if required. I agree to Bernd. I don't know the problem Warner have with the patch, because it removes a big problem on non-acpi machines. Maybe a look to kern/53010 (http://www.freebsd.org/cgi/query-pr.cgi?pr=53010) change Warner's mind. If required, I will test further patches according this problem, too. Jens -- dmesg of machine which now runs with the fix: 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.1-CURRENT #3: Sat Jun 7 12:06:31 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WINNIE Preloaded elf kernel /boot/kernel/kernel at 0xc03a2000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 199433685 Hz CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV real memory = 134217728 (128 MB) avail memory = 126369792 (120 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at device 1.1 (no driver attached) pci0: unknown at device 2.0 (no driver attached) pci0: unknown at device 2.1 (no driver attached) pci0: display, VGA at device 3.0 (no driver attached) ahc0: Adaptec 2940 Ultra SCSI adapter port 0xf800-0xf8ff mem 0xfedfe000-0xfedfefff irq 11 at device 18.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc1: Adaptec 2940 Ultra SCSI adapter port 0xf400-0xf4ff mem 0xfedff000-0xfedf irq 9 at device 19.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=5, 16/253 SCBs orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 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 ed1: Plug Play Ethernet Card at port 0x220-0x23f iomem 0xc8000-0xcbfff irq 3 on isa0 ed1: address 00:c0:26:30:3a:68, type NE2000 (16 bit) unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle da1 at ahc1 bus 0 target 0 lun 0 da1: IBM DCAS-32160 S65A Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15) da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da0 at ahc0 bus 0 target 0 lun 0 da0: IBM DORS-32160!# WA3E Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Mounting root from ufs:/dev/da0s1a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/53010: FreeBSD-CURRENT cannot use 2940 UW on SNI Pro C6(Pentium Pro System)
John's tweak patch for re-routing of PCI interrupts seems to work. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom_vol_ffs problems
[Poul-Henning Kamp, 2003-06-07] | This does not work for FFS filesystems stored in apple or sun partitions, | but theese do on the other hand, not have the magic 'c' problem. (I know it wouldn't work for FFS filesystems in non-BSD partitions, which must be supported. It was not my suggestion for a solution, it was the beginning of a chain of thought leading to this:) Sun partitions _do_ have a magic slice (slice 2), so I think geom_vol_ffs needs to know which types of providers it can and cannot attach to. Other not-yet-invented GEOMs may behave like sunlabels and bsdlabels do (have a magic slice/a slice overlapping its other slices), so geom_vol_ffs should have a list of explicitly allowed types of providers it can attach to: - parent geom is a BSD _and_ the partition type is FS_BSDFFS - parent geom is an MBR - parent geom is a DISK geom (whole disk, e.g. da0) - parent geom is a sunlabel _and_ the slice number is not 2 (either check for number=2 or tag=backup) - parent geom is an apple geom - parent geom is a gpt and its type is GPT_ENT_TYPE_FREEBSD_UFS - ... It should probably also know how to avoid connecting to a submirror in a mirror instead of the mirror and stuff like that. That also requires knowledge of the state of its parent. To be sure that geom_vol_ffs doesn't do the wrong thing (it should be reliable enough to be used in fstab), that check should perhaps be: - parent geom doesn't have geoms of any other type than: [explicit list, for the time being only dev] attached to it. so that adding new classes of GEOMs (GEOM_RAID5?) won't break geom_vol_ffs, but they may require geom_vol_ffs to be aware of them in order to have geom_vol_ffs working for those new classes. I'd really like geom_vol_ffs to be deterministic enough to be used in fstab. -- Per Kristian Hove Dept. of Mathematical Sciences Norwegian University of Science and Technology ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG automonter(amd)
On Sat, 07 Jun 2003 13:13:15 +0300
Danny Braniss [EMAIL PROTECTED] wrote:
hi,
I have a problem with /etc/rc.d/amd, because of the line
command_args=
${amd_program} gets run in the background, ldconfig failes to cache libraries
in /usr/local/lib (which is automounted :-)
Is there realy a need for the ? amd will background itself after it's
done
with the initialization stage anyway - and if not then it probably means
trouble.
This may have been because of a missed merge from rcOG. How does the following
work for you?
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - The Power To Serve
Index: etc/rc.d/amd
===
RCS file: /home/ncvs/src/etc/rc.d/amd,v
retrieving revision 1.9
diff -u -r1.9 amd
--- etc/rc.d/amd12 Oct 2002 10:31:31 - 1.9
+++ etc/rc.d/amd7 Jun 2003 11:49:26 -
@@ -18,7 +18,6 @@
case ${OSTYPE} in
FreeBSD)
start_precmd=amd_precmd
- command_args=
;;
NetBSD)
command_args='-p -a '$amd_dir' -F /etc/amd.conf /var/run/amd.pid'
@@ -56,6 +55,7 @@
warn 'amd will not load without arguments'
return 1
fi
+ rc_flags=${rc_flags}
;;
*)
rc_flags=-p ${rc_flags} /var/run/amd.pid 2 /dev/null \
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
On Fri, Jun 06, 2003 at 11:57:00PM -0700, David O'Brien wrote: On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote: The compiler in 4.7 does not like this: -std=gnu99 As a result, buildworld of -CURRENT fails rather early. Committers are not required to support building 5-CURRENT, post 5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the change. However, someone will probably patch the build system to tolerate it. Please correct me if I'm wrong, but I thought that this support will no longer be _required_ when we have a first release on the RELENG_5 (-STABLE) branch. [EMAIL PROTECTED] Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: [PATCH] Tweak re-routing of PCI interrupts
In message: [EMAIL PROTECTED] Jens Rehsack [EMAIL PROTECTED] writes: : On 6/6/2003 9:29 PM, Bernd Walter wrote: : On Fri, Jun 06, 2003 at 01:17:43PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Bernd Walter [EMAIL PROTECTED] writes: : : I already wondered how you could route interrupts without ACPI until I : : booted my printserver with a recent kernel. : : PCIBIOS! : : Well - I'm not very familar with what i386 offer here. : Specs are available here, so I could read. : But in any case Johns patch revived my printserver (old HX : socket7 board). : Either my BIOS is broken or FreeBSD doesn't use it correctly. : Whatever - I can run tests on that machine if required. : : I agree to Bernd. I don't know the problem Warner have with the patch, : because it removes a big problem on non-acpi machines. Maybe a look to : kern/53010 (http://www.freebsd.org/cgi/query-pr.cgi?pr=53010) change : Warner's mind. You misunderstand what I'm saying. I'm saying that I like the patch, but that I have reservations about not writing the intline back into the pci config register. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
In message: [EMAIL PROTECTED] Ruslan Ermilov [EMAIL PROTECTED] writes: : On Fri, Jun 06, 2003 at 11:57:00PM -0700, David O'Brien wrote: : On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote: : The compiler in 4.7 does not like this: : : -std=gnu99 : : As a result, buildworld of -CURRENT fails : rather early. : : Committers are not required to support building 5-CURRENT, post : 5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the : change. However, someone will probably patch the build system to : tolerate it. : : Please correct me if I'm wrong, but I thought that this support : will no longer be _required_ when we have a first release on the : RELENG_5 (-STABLE) branch. [EMAIL PROTECTED] First off, I'd like to say that's my understanding as well. Having said that, let's not get overly anal about the rules here. There's still a great need to have current build on 4.x machines. This is a long standing range war between ruslan and david over how much compatibility should be there. I do not want to see it play out in public again, but fear that it might. Let's apply some common sense to this exceptional situation we find ourselves in and not resort to being overly pedantic about rules. There are a number of people who cannot run a 5.0-RELEASE system on their hardware because it was too instable to build a world. So requiring a trip through 5.0 is not an option. Therefore, we have to tolerate going from 4.x to at least 5.1 and maybe a little farther. We're just barely past 5.1 right now, so it is a little fast to be breaking this path. I personally don't see that the addition of -std=gnu99 is enough of a win in -current to justify its painful addition and the issue of -stable compatibility is secondary to that. It's been added 3 or 4 times now and every time the world has broken on some architecture. That alone is reason to treat the change with some skeptism as to its correctness. My main point, however, is that common sense needs to be applied to this situation, not blind adherence to inflexible rules. That's the sort of thing that gets us as a project into trouble. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG automonter(amd)
This may have been because of a missed merge from rcOG. How does the following work for you? Cheers. it will fix my problem, but in an 'obscure way', just have to remember to set amd_flags my point is that amd should not be backgrounded by default, it does so anyway once it managed to register with the portmapper and some other initialization danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG automonter(amd)
On Sat, 07 Jun 2003 15:48:47 +0300 Danny Braniss [EMAIL PROTECTED] wrote: context I have a problem with /etc/rc.d/amd, because of the line command_args= [amd] gets run in the background, ldconfig failes to cache libraries in /usr/local/lib (which is automounted :-) /context my point is that amd should not be backgrounded by default, it does so anyway once it managed to register with the portmapper and some other initialization You might want to get David's (CCed) input then: description: revision 1.127 date: 2002/03/12 01:04:35; author: obrien; state: Exp; lines: +3 -3 Background the startup of `Amd', it often blocks on startup. = Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On Sat, Jun 07, 2003 at 01:08:12PM +0200, Jens Rehsack wrote: dmesg of machine which now runs with the fix: npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: Host to PCI bridge at pcibus 0 on motherboard Same situtation with my Board - no $PIR table. This is how it should look like (from an Asus T2P4): npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f09b0 pcib0: Host to PCI bridge at pcibus 0 on motherboard -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
How to kill a 5.0R installation with 5.1R
Folks, This is the second time that I have this happen here. I had a 5.0R installed on a box. After upgrading, (make world make kernel) the box crashes instantly in the boot loader and reboots itself. If I try to load the kernel manually, I get: Disk error 0x4, (lba=0xfc2247f) There should be at least a warning somewhere in UPDATING. This definitly sucks like hell. 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 -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to kill a 5.0R installation with 5.1R
On Sat, Jun 07, 2003 at 03:45:56PM +0200, Martin Blapp wrote: Folks, This is the second time that I have this happen here. I had a 5.0R installed on a box. After upgrading, (make world make kernel) the box crashes instantly in the boot loader and reboots itself. How does it crash? If I try to load the kernel manually, I get: Disk error 0x4, (lba=0xfc2247f) You mean without loader? From the boot blocks? If so, the support for this has been broken for a long time. Ask BDE for patches. :-) Also, have you tried the official 5.1-RELEASE bits, like booting from the installation CD-ROM? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: How to kill a 5.0R installation with 5.1R
Hi, This has been one of my laptops. It had three partitions on it, the first one FreeBSD. How does it crash? I have lilo installed. When I choose freebsd, I get the normal freebsd loader: FreeBSD/i386 BOOT After that, I see very fast a message scrolling over the screen, it turns black again, and voila, the box has rebooted. I've killed the second box the same way. After restoring boot0/boot1 I found that my disklables were nuked. Enjoy. You mean without loader? From the boot blocks? If so, the support for this has been broken for a long time. Ask BDE for patches. :-) Yes from the boot blocks. Also, have you tried the official 5.1-RELEASE bits, like booting from the installation CD-ROM? No, I just upgraded with RELENG_5_0_0 from source. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to kill a 5.0R installation with 5.1R
On Sat, Jun 07, 2003 at 03:45:56PM +0200, Martin Blapp wrote: Folks, This is the second time that I have this happen here. I had a 5.0R installed on a box. After upgrading, (make world make kernel) the box crashes instantly in the boot loader and reboots itself. Have you tried loader.old? I personally also keep a loader.work copy on my systems - just in case. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to kill a 5.0R installation with 5.1R
Hi, Have you tried loader.old? I personally also keep a loader.work copy on my systems - just in case. Whooo. Yes, loader.old did the trick. Wow :-) Thanky you very much ! I'm just curious now why the new loader instantly panics. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to kill a 5.0R installation with 5.1R
On Sat, Jun 07, 2003 at 04:00:46PM +0200, Martin Blapp wrote: Hi, This has been one of my laptops. It had three partitions on it, the first one FreeBSD. How does it crash? I have lilo installed. When I choose freebsd, I get the normal freebsd loader: FreeBSD/i386 BOOT After that, I see very fast a message scrolling over the screen, it turns black again, and voila, the box has rebooted. I've killed the second box the same way. After restoring boot0/boot1 I found that my disklables were nuked. Enjoy. Um, so what do you use? lilo or boot0? :-) Also, don't you think that it maybe a Linux part that's killing your FreeBSD disk labels? I don't believe loader(8) ever writes to this area of the disk, neither do boot0 and boot[12]. You mean without loader? From the boot blocks? If so, the support for this has been broken for a long time. Ask BDE for patches. :-) Yes from the boot blocks. This is unsupported, sorry. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: How to kill a 5.0R installation with 5.1R
Hi, over the screen, it turns black again, and voila, the box has rebooted. I've killed the second box the same way. After restoring boot0/boot1 I found that my disklables were nuked. Enjoy. Um, so what do you use? lilo or boot0? :-) Lilo. And the first box I killed with just a upgrade had only FreeBSD and boot0. So I don't think it's related to linux. This is unsupported, sorry. As you have seen, loading -boot-loader.old fixed the crash. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Audigy Support?
Hello all. I've been using the OSS drivers for my Audigy Gamer sound card for quite some time now, and would like to switch away from OSS. I vaguely remember, after searching Google, that someone had gotten this to work after a recent cvsup. Unfortunately, I cannot seem to get this to work natively. I've tried the usual emu_10k1 kernel module with no luck. I was just wondering if perhaps I'm not doing something correctly, or I should just stick with the OSS drivers for the time being. I'm running -Current as of June 06 2003. Thank you for your assistance, John Wilson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
David O'Brien wrote:
On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote:
The compiler in 4.7 does not like this:
-std=gnu99
As a result, buildworld of -CURRENT fails
rather early.
Committers are not required to support building 5-CURRENT, post
5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the
change. However, someone will probably patch the build system to
tolerate it.
Hmm.. I'll upgrade the machine to 4-STABLE and
see if that addresses it.
I'm also looking at at some other approaches.
For example, the attached patch changes BMAKEENV to
override CSTD in the early build phases. (This also
required changing a couple of 'inline' to '__inline'
in xlint/lint1/cgram.y.) This seems to get
it through the bootstrap, at least, although I'm still running
into build problems later on (but the cross-tools
are built by then, so I think these may be unrelated).
Tim Kientzle
Index: Makefile.inc1
===
RCS file: /usr/src/cvs/src/Makefile.inc1,v
retrieving revision 1.363
diff -u -r1.363 Makefile.inc1
--- Makefile.inc1 31 May 2003 21:29:38 - 1.363
+++ Makefile.inc1 7 Jun 2003 04:52:43 -
@@ -200,7 +204,7 @@
BMAKEENV= DESTDIR= \
INSTALL=sh ${.CURDIR}/tools/install.sh \
PATH=${BPATH}:${PATH} \
- WORLDTMP=${WORLDTMP} \
+ WORLDTMP=${WORLDTMP} CSTD=c90 \
MAKEFLAGS=-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}
BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \
${BMAKEENV} ${MAKE} -f Makefile.inc1 \
Index: usr.bin/xlint/lint1/cgram.y
===
RCS file: /usr/src/cvs/src/usr.bin/xlint/lint1/cgram.y,v
retrieving revision 1.7
diff -u -r1.7 cgram.y
--- usr.bin/xlint/lint1/cgram.y 3 Mar 2002 15:12:19 - 1.7
+++ usr.bin/xlint/lint1/cgram.y 7 Jun 2003 06:30:12 -
@@ -1642,17 +1642,17 @@
return (0);
}
-static inline int uq_gt(uint64_t, uint64_t);
-static inline int q_gt(int64_t, int64_t);
+static __inline int uq_gt(uint64_t, uint64_t);
+static __inline int q_gt(int64_t, int64_t);
-static inline int
+static __inline int
uq_gt(uint64_t a, uint64_t b)
{
return (a b);
}
-static inline int
+static __inline int
q_gt(int64_t a, int64_t b)
{
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
On Sat, Jun 07, 2003 at 06:30:11AM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Ruslan Ermilov [EMAIL PROTECTED] writes: : On Fri, Jun 06, 2003 at 11:57:00PM -0700, David O'Brien wrote: : On Fri, Jun 06, 2003 at 09:46:07PM -0700, Tim Kientzle wrote: : The compiler in 4.7 does not like this: : : -std=gnu99 : : As a result, buildworld of -CURRENT fails : rather early. : : Committers are not required to support building 5-CURRENT, post : 5.0-RELEASE on a 4.7 machine. So this is not grounds to remove the : change. However, someone will probably patch the build system to : tolerate it. : : Please correct me if I'm wrong, but I thought that this support : will no longer be _required_ when we have a first release on the : RELENG_5 (-STABLE) branch. [EMAIL PROTECTED] First off, I'd like to say that's my understanding as well. That was not my understanding at all. Having said that, let's not get overly anal about the rules here. There's still a great need to have current build on 4.x machines. This is a long standing range war between ruslan and david over how much compatibility should be there. I do not want to see it play out in public again, but fear that it might. How is this a war? My elusion to someone will probably patch the build system to tolerate it is that I expected that RU would add something to -legacy or Makefile.inc1 so that the 5-CURRENT build worked 4.0. I don't believe anyone can infer I would get in someone's way in doing this. We even have a freshly bumped __FreeBSD_version (501100) that can be used for this. I personally don't see that the addition of -std=gnu99 is enough of a win in -current to justify its painful addition and the issue of -stable compatibility is secondary to that. It's been added 3 or 4 times now and every time the world has broken on some architecture. That alone is reason to treat the change with some skeptism as to its correctness. And the TRB hasn't even responded to my or DES's emails on the topic. Note even a hi, we got your message and will mull over it. I (and another committer) had a agenda that DES's commit derailed and I'll be damned if I'm going to let it stop me given the amount of crap I've taken lately that has derailed every effort I've tried to make in FreeBSD for the past 2 months. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : First off, I'd like to say that's my understanding as well. : : That was not my understanding at all. The last time it came it, it was specifically stated that it was until the branch point. But so far the work arounds are fairly simple. I'm not going to give you more grief about it. : Having said that, let's not get overly anal about the rules here. : There's still a great need to have current build on 4.x machines. : This is a long standing range war between ruslan and david over how : much compatibility should be there. I do not want to see it play out : in public again, but fear that it might. : : How is this a war? My elusion to someone will probably patch the build : system to tolerate it is that I expected that RU would add something to : -legacy or Makefile.inc1 so that the 5-CURRENT build worked 4.0. I don't : believe anyone can infer I would get in someone's way in doing this. : We even have a freshly bumped __FreeBSD_version (501100) that can be used : for this. It isn't a war, yet. I'd like to keep it that way. There's some history here that makes me fear. However, I'll put those fears away and try to get a workaround that works. : I personally don't see that the addition of -std=gnu99 is enough of a : win in -current to justify its painful addition and the issue of : -stable compatibility is secondary to that. It's been added 3 or 4 : times now and every time the world has broken on some architecture. : That alone is reason to treat the change with some skeptism as to its : correctness. : : And the TRB hasn't even responded to my or DES's emails on the topic. : Note even a hi, we got your message and will mull over it. Noted. I'll go and re-read the trb@ request. It came in, and then there was a flurry of commits so I thought it was OBE. I'll go look into it. : I (and another committer) had a agenda that DES's commit derailed and : I'll be damned if I'm going to let it stop me given the amount of crap : I've taken lately that has derailed every effort I've tried to make in : FreeBSD for the past 2 months. I'm not trying to give you crap here. I'm trying to point out that there are additional concerns that come into play. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG automonter(amd)
On Sat, Jun 07, 2003 at 09:04:46AM -0400, Mike Makonnen wrote: On Sat, 07 Jun 2003 15:48:47 +0300 Danny Braniss [EMAIL PROTECTED] wrote: context I have a problem with /etc/rc.d/amd, because of the line command_args= [amd] gets run in the background, ldconfig failes to cache libraries in /usr/local/lib (which is automounted :-) /context my point is that amd should not be backgrounded by default, it does so anyway once it managed to register with the portmapper and some other initialization You might want to get David's (CCed) input then: description: revision 1.127 date: 2002/03/12 01:04:35; author: obrien; state: Exp; lines: +3 -3 Background the startup of `Amd', it often blocks on startup. = Amd is poorly designed the way it blocks and is overly sensative to one's network setup. Your's is the first trouble I've heard of with back grounding its invocation, and several were happy with it. I don't know what to say. remove rev 1.127 if you like. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.1-RELEASE (cvs) problems..
Hello there. Just installed FreeBSD 5.1-BETA from a ISO, then upgrade to
5.1-RELEASE via CVS (RELENG_5_1).
Looks like there are alot of problems with ACPI and the floppy disk
controller on this mainboard. It's a Abit BP6 Dual-CPU mainboard with two
Celeron 400MHz CPU's running on it.
I have a USB wireless mouse/keyboard package from logitech, where the
keyboard works fine after the usbd is up, but the mouse seems dead (I can
only get a PS/2 mouse to work).
-su-2.05b# ps auxw | grep moused
root376 0.0 0.1 1188 600 ?? Is7:22PM 0:00.00
/usr/sbin/moused -p /dev/ums0 -I /var/run/moused.ums0.pid
root445 0.0 0.1 1188 600 ?? Is7:22PM 0:00.00
/usr/sbin/moused -p /dev/psm0 -t auto
Attached is the complete dmesg buffer from startup, pciconf -lv and
acpidump. Any ideas are greatly appriciated.
Greetings, Erik.
begin 666 pciconf.txt
M86=P,$!P8VDP.C Z,#H)8VQAW,],'@P-C P,# @8V%R9#TP# P,# P,# P
M(-H:7 ],'@W,3DP.# X-B!R978],'@P,R!H9'(],'@P, T*( @('9E;F1O
MB @(#T@)TEN=5L($-OG!OF%T:6]N)PT*( @(1E=FEC92 @(#T@)[EMAIL PROTECTED]
[EMAIL PROTECTED]@@[EMAIL PROTECTED]@@0U!5('1O(%!#22![EMAIL PROTECTED]'4!);7!L
M96UE;G1E9DG#0H@( @8VQAW,@( @/2!BFED9V4-B @(!S=6)C;%S
MR ]($A/4U0M4$-)#0IP8VEB,4!P8VDP.C$Z,#H)8VQAW,],'@P-C T,# @
M8V%R9#TP# P,# P,# P(-H:7 ],'@W,3DQ.# X-B!R978],'@P,R!H9'(]
M,'@P,0T*( @('9E;F1OB @(#T@)TEN=5L($-OG!OF%T:6]N)PT*( @
M(1E=FEC92 @(#T@)[EMAIL PROTECTED]@O6E@@[EMAIL PROTECTED]@@04=0V5T(%!#22UT
M;[EMAIL PROTECTED])I9=E)PT*( @(-L87-S( @([EMAIL PROTECTED])I9=E#0H@( @W5B
M8VQAW,@/2!00TDM4$-)#0IIV%B,$!P8VDP.CZ,#H)8VQAW,],'@P-C Q
M,# @8V%R9#TP# P,# P,# P(-H:7 ],'@W,3$P.# X-B!R978],'@P,B!H
M9'(],'@P, T*( @('9E;F1OB @(#T@)TEN=5L($-OG!OF%T:6]N)PT*
M( @(1E=FEC92 @(#T@)[EMAIL PROTECTED],SQ04(O14(O34(@4$E)[EMAIL PROTECTED]
M($)R:61G92-B @(!C;%SR @( ]()R:61G90T*( @('-U8F-L87-S
M([EMAIL PROTECTED])+4E300T*871A-I,$!P8VDP.CZ,3H)8VQAW,],'@P,3 Q.# @
M8V%R9#TP# P,# P,# P(-H:7 ],'@W,3$Q.# X-B!R978],'@P,2!H9'(]
M,'@P, T*( @('9E;F1OB @(#T@)TEN=5L($-OG!OF%T:6]N)PT*( @
M(1E=FEC92 @(#T@)[EMAIL PROTECTED],SQ04(O14(O34(@4$E)[EMAIL PROTECTED]($-O
M;G1R;VQL97(G#0H@( @8VQAW,@( @/2!M87-S('-T;W)A9V4-B @(!S
M=6)C;%SR ]($%400T*=6AC:3! -I,#HW.C(Z6-L87-S/3!X,,P,S P
M(-AF0],'@P,# P,# P,!C:EP/3!X-S$Q,[EMAIL PROTECTED]@F5V/3!X,#$@:1R
M/3!X,# -B @(!V96YD;W(@( ](=);G1E;!#;W)P;W)A=EO;B-B @
M(!D979I8V4@( ](X,C,W,4%+T5+TU(%!)[EMAIL PROTECTED](%530B!)
M;G1EF9A8V4G#0H@( @8VQAW,@( @/2!S97)[EMAIL PROTECTED]@( @W5B
M8VQAW,@/2!54T(-G!I:[EMAIL PROTECTED]'!C:3 [EMAIL PROTECTED];%SSTP# V.# P,!C
M87)D/3!X,# P,# P,# @8VAI#TP#Q,3,X,[EMAIL PROTECTED](')E=CTP# R(ADCTP
M# P#0H@( @=F5N9]R( @/2 [EMAIL PROTECTED]]R871I;VXG#0H@( @
M95V:6-E( @/2 G.#(S-S%!0B]%0B]-0B!024E8-\T12\T32!0;W=EB!-
M86YA9V5M96YT($-O;G1R;VQL97(G#0H@( @8VQAW,@( @/2!BFED9V4-
MB @(!S=6)C;%SR ](%!#22UU;FMN;W=N#0IN;VYE,$!P8VDP.CDZ,#H)
M8VQAW,],'@P-# Q,# @8V%R9#TP# P-3,Q,3 R(-H:7 ],'@P,# T,3$P
M,B!R978],'@P,R!H9'(],'@P, T*( @('9E;F1OB @(#T@)T-R96%T:79E
M($QA8G,G#0H@( @95V:6-E( @/2 G14U5,3!+,B!!=61I;R!#:EPV5T
M(A30B!!=61I9WDI)PT*( @(-L87-S( @(#T@;75L=EM961I80T*( @
M('-U8F-L87-S([EMAIL PROTECTED]:6\-F5M=6IO3! -I,#HY.C$Z6-L87-S/3!X
M,#DX,# P(-AF0],'@P,#0P,3$P,B!C:EP/3!X-S P,S$Q,#(@F5V/3!X
M,#,@:1R/3!X,# -B @(!V96YD;W(@( ](=#F5A=EV92!,86)S)PT*
M( @(1E=FEC92 @(#T@)T%U9EG2!'86UE]R=!*;WES=EC:R-B @
M(!C;%SR @( ](EN'5T(1E=FEC90T*9G=O:-I,$!P8VDP.CDZ,CH)
M8VQAW,],'@P8S P,3 @8V%R9#TP# P,3 Q,3 R(-H:7 ],'@T,# Q,3$P
M,B!R978],'@P,2!H9'(],'@P, T*( @('9E;F1OB @(#T@)T-R96%T:79E
M($QA8G,G#0H@( @95V:6-E( @/2 G14U5,3!+,[EMAIL PROTECTED]
[EMAIL PROTECTED][EMAIL PROTECTED]')O;QEB-B @(!C;%SR @( ]('-EFEA
M;!B=7,-B @(!S=6)C;%SR ]($9IF57:7)E#0IE;3! -I,#HQ,SHP
[EMAIL PROTECTED];%SSTP# R,# P,!C87)D/3!X,# [EMAIL PROTECTED]@8VAI#TP#$P,4X
M,[EMAIL PROTECTED](')E=CTP# R(ADCTP# P#0H@( @=F5N9]R( @/2 G26YT96P@
M0V]R]R871I;VXG#0H@( @95V:6-E( @/2 G.#(U-#185!04D\O,3 P
M,!-5!':6=A8FET($5T:5R;F5T($-O;G1R;VQL97(G#0H@( @8VQAW,@
M( @/2!N971W;W)K#0H@( @W5B8VQAW,@/2!E=AEFYE= T*871A-I
M,4!P8VDP.C$Y.C Z6-L87-S/3!X,#$X,# P(-AF0],'@P,# P,# P,!C
M:EP/3!X,# P-#$Q,#,@F5V/3!X,#$@:1R/3!X,# -B @(!V96YD;W(@
M( ](=(:6=H4]I;[EMAIL PROTECTED]5C:YO;]G:65S($EN8RXG#0H@( @95V:6-E
M( @/2 G2%!4,WAX(%5$34$V-B\Q,# O,3,S($5)[EMAIL PROTECTED]')O;QEB-
MB @(!C;%SR @( ](UAW,@W1OF%G90T*871A-I,D!P8VDP.C$Y
M.C$Z6-L87-S/3!X,#$X,# P(-AF0],'@P,# P,# P,!C:EP/3!X,# P
M-#$Q,#,@F5V/3!X,#$@:1R/3!X,# -B @(!V96YD;W(@( ](=(:6=H
M4]I;[EMAIL PROTECTED]5C:YO;]G:65S($EN8RXG#0H@( @95V:6-E( @/2 G2%!4
M,WAX(%5$34$V-B\Q,# O,3,S($5)[EMAIL PROTECTED]')O;QEB-B @(!C;%S
MR @( ](UAW,@W1OF%G90T*;F]N93% -I,3HP.C Z6-L87-S/3!X
M,#,P,# P(-AF0],'@Q,#)D,3$P,B!C:EP/3!X,#$P,#$P94@F5V/3!X
M,3 @:1R/3!X,# -B @(!V96YD;W(@( ]([EMAIL PROTECTED]]R871I
M;VXG#0H@( @95V:6-E( @/2 G1V5;W)C92 [EMAIL PROTECTED],3!=)PT*( @
I(-L87-S( @([EMAIL PROTECTED]ESQA0T*( @('-U8F-L87-S([EMAIL PROTECTED]
`
end
begin 666 acpidump.txt
M+RH-E)31!05%(Z($-H96-KW5M/30S+!/14U)1#U!0DE4+!2V1T061D
MF5SSTP#(W9F8S,# [EMAIL PROTECTED]B\J#0I24T14.B!,96YG=@]-#0L(%)E
M=FES:6]N/3$L($-H96-KW5M/3(X+ T*4]%34E$/4%250L($]%32!486)L
Re: Can't build -CURRENT on 4.7
On Sat, Jun 07, 2003 at 10:38:15AM -0700, Tim Kientzle wrote:
Index: usr.bin/xlint/lint1/cgram.y
===
RCS file: /usr/src/cvs/src/usr.bin/xlint/lint1/cgram.y,v
retrieving revision 1.7
diff -u -r1.7 cgram.y
--- usr.bin/xlint/lint1/cgram.y 3 Mar 2002 15:12:19 - 1.7
+++ usr.bin/xlint/lint1/cgram.y 7 Jun 2003 06:30:12 -
@@ -1642,17 +1642,17 @@
-static inline int uq_gt(uint64_t, uint64_t);
-static inline int q_gt(int64_t, int64_t);
+static __inline int uq_gt(uint64_t, uint64_t);
+static __inline int q_gt(int64_t, int64_t);
-static inline int
+static __inline int
uq_gt(uint64_t a, uint64_t b)
{
return (a b);
}
-static inline int
+static __inline int
Good catch! The rest of the file used __include everywhere. I've fixed
the inconsistency.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
On Sat, Jun 07, 2003 at 10:38:15AM -0700, Tim Kientzle wrote:
Index: Makefile.inc1
===
RCS file: /usr/src/cvs/src/Makefile.inc1,v
retrieving revision 1.363
diff -u -r1.363 Makefile.inc1
--- Makefile.inc1 31 May 2003 21:29:38 - 1.363
+++ Makefile.inc1 7 Jun 2003 04:52:43 -
@@ -200,7 +204,7 @@
BMAKEENV=DESTDIR= \
INSTALL=sh ${.CURDIR}/tools/install.sh \
PATH=${BPATH}:${PATH} \
- WORLDTMP=${WORLDTMP} \
+ WORLDTMP=${WORLDTMP} CSTD=c90 \
This won't work on non-i386, due to alloca issues.
+ WORLDTMP=${WORLDTMP} CSTD= \
may.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-07 17:28:52 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-07 17:28:52 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-07 17:31:51 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims 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/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-07 18:23:57 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jun 7 18:23:57 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/pseudofs/pseudofs_fileno.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/pseudofs/pseudofs_vncache.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/pseudofs/pseudofs_vnops.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/specfs/spec_vnops.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/geom/geom_ctl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include
Re: [-CURRENT tinderbox] failure on i386/i386
In message [EMAIL PROTECTED], Tinderbox wri tes: /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/geom/geom_dev.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/geom/geom_dev.c:81: conflicting types for `g_dev_print' /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/geom/geom.h:175: previous declaration of `g_dev_print' *** Error code 1 This is a pretty amazing race, those two files were committed together... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Audigy Support?
There seems to be a patch floating around. I saw it at bsdforums.org - see http://www.bsdforums.org/forums/showthread.php?s=threadid=6961 . It's created by Orlando Bassotto. I don't know if is yet included in the FreeBSD source, or why it is not. Best regards, Arjan On Saturday 07 June 2003 19:19, John Wilson wrote: Hello all. I've been using the OSS drivers for my Audigy Gamer sound card for quite some time now, and would like to switch away from OSS. I vaguely remember, after searching Google, that someone had gotten this to work after a recent cvsup. Unfortunately, I cannot seem to get this to work natively. I've tried the usual emu_10k1 kernel module with no luck. I was just wondering if perhaps I'm not doing something correctly, or I should just stick with the OSS drivers for the time being. I'm running -Current as of June 06 2003. Thank you for your assistance, John Wilson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
In message: [EMAIL PROTECTED]
David O'Brien [EMAIL PROTECTED] writes:
: + WORLDTMP=${WORLDTMP} CSTD= \
:
: may.
This seems to mostly work... I'm trying to sort out a couple of other
issues, but those may be related to other changes that I've made in my
test tree.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Regression: Playing QT files from mplayer stopped working in 5.1
Hi, Since a short time (don't know exactly when it happened) it's not possible anymore to play Quicktime files (.mov) with mplayer on 5.1-CURRENT. It has to be a change in -CURRENT, I haven't updated mplayer. When trying to play a QT file, mplayer outputs: win32 libquicktime loader (c) Sascha Sommer Standard init done you may now call supported functions loader_init DONE??? loader_init DONE! External func COMCTL32.dll:17 External func COMCTL32.dll:16 QuickTime5 DLLs found QuickTime.qts patched!!! old entry=0x62924c30 theQuickTimeDispatcher catched - 0x62924c30 Win32 Warning: Accessed uninitialized Critical Section (0x62b7fcd0)! WARNING! Invalid Ptr handle! Win32 Warning: Accessed uninitialized Critical Section (0x62b7fcb8)! MPlayer interrupted by signal 11 in module: init_audio_codec - MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. For details, see DOCS/bugreports.html#crash.b. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. Best regards, Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
Fri, Jun 06, 2003 at 03:01:02, DougB wrote about Re: Way forward with BIND 8: FYI, for those wondering why I'm not considering BIND 9 for import, please see http://people.freebsd.org/~dougb/whybind8.html Among other things: standard resolver is waaay(tm) old. Even keeping with BIND8, it is old. At least, it isn't thread-safe; this is too ugly for 5.*. Unlike IRS code (gethostby*()), its upgrading to thread safe version is conceptually easy. I've created and successfully tested patch to upgrade it to 8.3.4 version, losing only res_*update() and RES_INSECURE*; it was very simple, and a person more informed in its specifics including KAME hacks can do it better. (ftp://segfault.kiev.ua/pub/freebsd/newresolv for someone wanting to see it. I should repeast that this attempt may be too lame and forgetting some principal moments, but it was successfully tested on real load for a long time.) -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regression: Playing QT files from mplayer stopped working in 5.1
On Sat, 7 Jun 2003 22:28:29 +0200, Arjan van Leeuwen [EMAIL PROTECTED] wrote: Hi, Since a short time (don't know exactly when it happened) it's not possible anymore to play Quicktime files (.mov) with mplayer on 5.1- CURRENT. It has to be a change in -CURRENT, I haven't updated mplayer. When trying to play a QT file, mplayer outputs: It happened on me too, so to other users over at bsdforums.org.. I don't have the problem with 5.0-CURRENT, until I upgraded to 5.1-CURRENT and now xine and mplayer will not work with the quicktime anymore. They both will crash with the dump core. I will have to turn on the debug and post the info of run them under gdb to see if it will help. I am cc'ing to the maintainer of xine and mplayer here, btw.. Cheers, Mezz win32 libquicktime loader (c) Sascha Sommer Standard init done you may now call supported functions loader_init DONE??? loader_init DONE! External func COMCTL32.dll:17 External func COMCTL32.dll:16 QuickTime5 DLLs found QuickTime.qts patched!!! old entry=0x62924c30 theQuickTimeDispatcher catched - 0x62924c30 Win32 Warning: Accessed uninitialized Critical Section (0x62b7fcd0)! WARNING! Invalid Ptr handle! Win32 Warning: Accessed uninitialized Critical Section (0x62b7fcb8)! MPlayer interrupted by signal 11 in module: init_audio_codec - MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. For details, see DOCS/bugreports.html#crash.b. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. Best regards, Arjan -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Audigy Support?
On Sat, Jun 07, 2003 at 01:19:42PM -0400, John Wilson wrote:
I've been using the OSS drivers for my Audigy Gamer sound card for quite
some time now, and would like to switch away from OSS. I vaguely
remember, after searching Google, that someone had gotten this to work
after a recent cvsup. Unfortunately, I cannot seem to get this to work
natively.
Here is what I use. I tried to make it as non-distruptive of pre-Audigy
cards as possible, but it won't work with them for some reason. Thus why
this patch hasn't been committed yet.
Index: dev/sound/pci/emu10k1.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pci/emu10k1.c,v
retrieving revision 1.37
diff -u -r1.37 emu10k1.c
--- dev/sound/pci/emu10k1.c 20 Apr 2003 09:07:14 - 1.37
+++ dev/sound/pci/emu10k1.c 7 Jun 2003 21:19:50 -
@@ -1,4 +1,5 @@
/*
+ * Copyright (c) 2003 Orlando Bassotto [EMAIL PROTECTED]
* Copyright (c) 1999 Cameron Grant [EMAIL PROTECTED]
* All rights reserved.
*
@@ -27,6 +28,9 @@
#include dev/sound/pcm/sound.h
#include dev/sound/pcm/ac97.h
#include gnu/dev/sound/pci/emu10k1.h
+#include gnu/dev/sound/pci/emu10k1-ac97.h
+#include gnu/dev/sound/pci/emu10k1-alsa.h
+#include dev/sound/pci/emu10k1.h
#include pci/pcireg.h
#include pci/pcivar.h
@@ -39,9 +43,25 @@
#defineEMU10K1_PCI_ID 0x00021102
#defineEMU10K2_PCI_ID 0x00041102
#defineEMU_DEFAULT_BUFSZ 4096
-#defineEMU_CHANS 4
+#define EMU_MAX_CHANS 8
#undef EMUDEBUG
+#defineEMUPAGESIZE 4096/* don't change */
+#defineMAXREQVOICES8
+#defineMAXPAGES(32768 * 64 / EMUPAGESIZE) /* WAVEOUT_MAXBUFSIZE
* NUM_G / EMUPAGESIZE */
+#defineRESERVED0
+#defineNUM_MIDI16
+#defineNUM_G 64 /* use all channels */
+#defineNUM_FXSENDS 4
+
+#defineTMEMSIZE256*1024
+#defineTMEMSIZEREG 4
+
+#defineENABLE 0x
+#defineDISABLE 0x
+#defineENV_ON 0x80
+#defineENV_OFF 0x00
+
struct emu_memblk {
SLIST_ENTRY(emu_memblk) link;
void *buf;
@@ -63,6 +83,8 @@
int b16:1, stereo:1, busy:1, running:1, ismaster:1;
int speed;
int start, end, vol;
+ int fxrt1; /* FX routing */
+ int fxrt2; /* FX routing (only for audigy) */
u_int32_t buf;
struct emu_voice *slave;
struct pcm_channel *channel;
@@ -91,7 +113,8 @@
struct sc_info {
device_tdev;
u_int32_t type, rev;
- u_int32_t tos_link:1, APS:1;
+ u_int32_t tos_link:1, APS:1, audigy:1, audigy2:1;
+ u_int32_t addrmask; /* wider if audigy */
bus_space_tag_t st;
bus_space_handle_t sh;
@@ -104,9 +127,10 @@
unsigned int bufsz;
int timer, timerinterval;
int pnum, rnum;
+ int nchans;
struct emu_mem mem;
struct emu_voice voice[64];
- struct sc_pchinfo pch[EMU_CHANS];
+ struct sc_pchinfo pch[EMU_MAX_CHANS];
struct sc_rchinfo rch[3];
};
@@ -166,6 +190,8 @@
static struct pcmchan_caps emu_playcaps = {4000, 48000, emu_pfmt, 0};
static int adcspeed[8] = {48000, 44100, 32000, 24000, 22050, 16000, 11025, 8000};
+/* audigy supports 12kHz. */
+static int audigy_adcspeed[9] = {48000, 44100, 32000, 24000, 22050, 16000, 12000,
11025, 8000};
/* */
/* Hardware */
@@ -205,7 +231,7 @@
{
u_int32_t ptr, val, mask, size, offset;
- ptr = ((reg 16) PTR_ADDRESS_MASK) | (chn PTR_CHANNELNUM_MASK);
+ ptr = ((reg 16) sc-addrmask) | (chn PTR_CHANNELNUM_MASK);
emu_wr(sc, PTR, ptr, 4);
val = emu_rd(sc, DATA, 4);
if (reg 0xff00) {
@@ -223,7 +249,7 @@
{
u_int32_t ptr, mask, size, offset;
- ptr = ((reg 16) PTR_ADDRESS_MASK) | (chn PTR_CHANNELNUM_MASK);
+ ptr = ((reg 16) sc-addrmask) | (chn PTR_CHANNELNUM_MASK);
emu_wr(sc, PTR, ptr, 4);
if (reg 0xff00) {
size = (reg 24) 0x3f;
@@ -239,7 +265,8 @@
static void
emu_wrefx(struct sc_info *sc, unsigned int pc, unsigned int data)
{
- emu_wrptr(sc, 0, MICROCODEBASE + pc, data);
+ pc += sc-audigy ? AUDIGY_CODEBASE : MICROCODEBASE;
+ emu_wrptr(sc, 0, pc, data);
}
/* */
@@ -282,7 +309,7 @@
int i, tmp, rate;
rate = 0;
- for (i = 0; i EMU_CHANS; i++) {
+ for (i = 0; i sc-nchans; i++) {
pch = sc-pch[i];
if (pch-buffer) {
tmp = (pch-spd * sndbuf_getbps(pch-buffer)) / pch-blksz;
@@ -345,6 +372,16 @@
return val;
}
+static int
+audigy_recval(int speed) {
+ int val;
+
+ val = 0;
Old Courier MTA , broken
Hi, courier in ports is 0.39 when current courier is 0.40.2 afaik. Additionaly it wont build without editing the Makefile and taking out the brake. Any idea when current courier will be implemented ? thx alot -- Christophe Zwecker mail: [EMAIL PROTECTED] Hamburg, Germanyfon: +49 179 3994867 http://www.zwecker.de Who is General Failure ? And why is he reading my disk ?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-07 21:10:21 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-07 21:10:21 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-07 21:12:45 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims 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/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] === sbin/badsect cc -O -pipe-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/badsect/badsect.c cc -O -pipe-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -static -o badsect badsect.o -lufs gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/badsect/badsect.8 badsect.8.gz === sbin/bsdlabel cc -O -pipe-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/bsdlabel/bsdlabel.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/bsdlabel/bsdlabel.c:128: `LABELSECTOR' undeclared here (not in a function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/bsdlabel/bsdlabel.c:129: `LABELOFFSET' undeclared here (not in a function) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/bsdlabel. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-07 21:56:00 - /usr/bin/make returned exit code 1 TB --- 2003-06-07 21:56:00 - ERROR: failed to build world TB --- 2003-06-07 21:56:00 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build -CURRENT on 4.7
David O'Brien wrote:
This won't work on non-i386, due to alloca issues.
+ WORLDTMP=${WORLDTMP} CSTD= \
may.
Hmmm... This seems like the Right Thing in
any case, since it is one less assumption you're
making about the build environment.
I'm still getting buildworld failures, though.
Long after the bootstrap, using the new
tools, I'm seeing consistent failures in
libpthread:
building shared library libkse.so.1
thr_libc.So: In function `sigaction':
thr_libc.So(.text+0x54): multiple definition of `_sigaction'
thr_sigaction.So:/usr/src/current/lib/libpthread/thread/thr_sigaction.c:43: first
defined here
thr_libc.So: In function `sigprocmask':
thr_libc.So(.text+0x34): multiple definition of `_sigprocmask'
thr_sigprocmask.So:/usr/src/current/lib/libpthread/thread/thr_sigprocmask.c:46: first
defined here
*** Error code 1
Stop in /usr/src/current/lib/libpthread.
*** Error code 1
Tim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-BETA em
There... http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/52835 Pete - Original Message - From: Robert Watson [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 15, 2003 9:54 PM Subject: Re: 5.1-BETA em Could you file a PR for this, if it hasn't already been resolved? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Fri, 9 May 2003, Petri Helenius wrote: I installed 5.0-RELEASE on an X31 IBM laptop and em0 worked. (1.4.x driver) Then I cvsupped -CURRENT two days ago and now the em0 probe only displays: em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 0x8000-0x803f mem 0xc020-0xc020, 0xc022-0xc023 irq 11 at device 1.0 on pci2 em0: The EEPROM Checksum Is Not Valid em0: Unable to initialize the hardware The chip is supposedly Intel mobile GE, and the machine has Win XP as dual booth with FreeBSD. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
installworld failure
% make installworld === gnu/usr.bin/binutils === gnu/usr.bin/binutils/libiberty === gnu/usr.bin/binutils/libbfd === gnu/usr.bin/binutils/libopcodes === gnu/usr.bin/binutils/libbinutils === gnu/usr.bin/binutils/addr2line install -s -o root -g wheel -m 555 addr2line /usr/bin install: addr2line: No such file or directory *** Error code 71 Stop in /usr/src/gnu/usr.bin/binutils/addr2line. *** Error code 1 -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
4.8 - 5.0-CURRENT build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm attempting to do a 'make buildworld' for FreeeBSD 5.0-CURRENT on a FreeBSD 4.8 box # uname -a FreeBSD 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I receive the following error when libpthread is built # cd libpthread # ls Makefileman support test archpthread.map sys thread # make building shared library libkse.so.1 thr_libc.So: In function `sigaction': thr_libc.So(.text+0x54): multiple definition of `_sigaction' thr_sigaction.So(.text+0x0): first defined here thr_libc.So: In function `sigprocmask': thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' thr_sigprocmask.So(.text+0x0): first defined here *** Error code 1 Does anyone know something about this? Thanks a lot! - -- Evan Sarmiento ([EMAIL PROTECTED]) WWW: http://evms.no-ip.org:8080 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+4nwbECYZSrUV88QRAkUcAKDoRnCy821sTRzrNtoRG3JkN3AZSwCfVVkC +HcRu11AaIW63kABzDfVLrc= =vnkt -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE SMP panics fixed.
I found the culprit. It was an off by one error. rev 1.35 has the fix. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8 - 5.0-CURRENT build error
In message: [EMAIL PROTECTED] Evan S. [EMAIL PROTECTED] writes: : # make : building shared library libkse.so.1 : thr_libc.So: In function `sigaction': : thr_libc.So(.text+0x54): multiple definition of `_sigaction' : thr_sigaction.So(.text+0x0): first defined here : thr_libc.So: In function `sigprocmask': : thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' : thr_sigprocmask.So(.text+0x0): first defined here : *** Error code 1 : : Does anyone know something about this? Yes. It's broken. :-) I'm looking into it... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
p5-GD-1.41 wont build
Hi, when trying to build above I get this: AutoSplitting blib/lib/GD.pm (blib/lib/auto/GD) /usr/local/bin/perl5.6.1 -I/usr/local/lib/perl5/5.6.1/mach -I/usr/local/lib/perl5/5.6.1/BSDPAN /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap -typemap typemap GD.xs GD.xsc mv GD.xsc GD.c cc -c -I/usr/local/include -I/usr/local/include/gd -I/usr/local/include/freetype -I@@X11BASE@@/include -I@@X11BASE@@/include/X11 -O -pipe -mcpu=pentiumpro -O -pipe -mcpu=pentiumpro-DVERSION=\1.41\ -DXS_VERSION=\1.41\ -DPIC -fPIC -I/usr/local/lib/perl5/5.6.1/mach/CORE -DHAVE_JPEG -DHAVE_TTF -DHAVE_XPM GD.c GD.xs: In function `newDynamicCtx': GD.xs:342: structure has no member named `free' GD.xs: In function `XS_GD__Image_newFromPngData': GD.xs:395: structure has no member named `free' GD.xs: In function `XS_GD__Image_newFromGdData': GD.xs:412: structure has no member named `free' GD.xs: In function `XS_GD__Image_newFromGd2Data': GD.xs:429: structure has no member named `free' GD.xs: In function `XS_GD__Image_newFromJpegData': GD.xs:472: structure has no member named `free' GD.xs: In function `XS_GD__Image_newFromWBMPData': GD.xs:494: structure has no member named `free' *** Error code 1 Stop in /usr/ports/graphics/p5-GD/work/GD-1.41. *** Error code 1 Stop in /usr/ports/graphics/p5-GD. *** Error code 1 Stop in /usr/ports/graphics/p5-GD-Graph. anyone an idea what I have to do ? thx alot for help! Christophe -- Christophe Zwecker mail: [EMAIL PROTECTED] Hamburg, Germanyfon: +49 179 3994867 http://www.zwecker.de Who is General Failure ? And why is he reading my disk ?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sendmail starts before rpc.statd and rpc.lockd
Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C. NFS access cache time=2 Starting statd. Starting lockd. It looks like sendmail starts before rpc.lockd and rpc.statd? This will cause diskless clients to hang? This is a nfs server and diskless client running 5.1-RELEASE. I'm running rpc.lockd and rpc.statd on the server and the client. Should rpc.lockd and rpc.statd be started before sendmail starts? Regards, David Yeske __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail starts before rpc.statd and rpc.lockd
Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C. NFS access cache time=2 Starting statd. Starting lockd. I should clarify that /etc/rc.d/virecover is calling sendmail. Does virecover need to be called this early on? Regards, David Yeske __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
