Wish you happy surfing to 80 countries and 500+ TV channels available for FREE
Send this to your Friends Chain Letter That's right!
-- Send the Email Back to me! (must) Just click reply and send a
blank one!
Yep That's right FREE ~ 80 Countries and 500+ Channels to enjoy
It looks like the change in release/Makefile to add TARGET_ARCH breaks
the build of ghostscript-gnu. Actually just setting the TARGET_ARCH
environment variable and then trying to build print/ghostscript-gnu
will break:
beast:/usr/ports/print/ghostscript-gnu # setenv
On Wed, Jul 24, 2002 at 12:59:10PM +0200, John Hay wrote:
It looks like the change in release/Makefile to add TARGET_ARCH breaks
the build of ghostscript-gnu. Actually just setting the TARGET_ARCH
environment variable and then trying to build print/ghostscript-gnu
will break:
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
JFYI, I submitted a bug report to the gcc GNATS, the PR-Number is 7390.
Regards,
--
Michael Nottebrock
The circumstance ends uglily in the cruel result. - Babelfish
msg41295/pgp0.pgp
Description: PGP signature
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
--
Kernel build for GENERIC started on Wed Jul 24 11:45:59 GMT 2002
--
=== GENERIC
FYI: static unit limits for ppp are set:
Hi Jukka,
I forwarded your mail to freebsd-current.
It looks like someone forgot to add the mlockall(2) manpages. The
prototype is defined in /usr/include/sys/mman.h
(http://cvsweb.freebsd.org/src/sys/sys/mman.h )
-Wolfram
- Forwarded message from Jukka A. Ukkonen [EMAIL PROTECTED] -
In article [EMAIL PROTECTED],
Mike Barcroft [EMAIL PROTECTED] wrote:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
--
Kernel build for GENERIC started on Wed Jul 24 11:45:59 GMT 2002
On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
ru Moved vx(4) and all miibus consumers (including miibus) out
ru from kern.flp to mfsroot.flp. This leaves 9K of the free
ru space for kern.flp.
Yey! 5-current distribution will come back again, thank you!
This
On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
ru Moved vx(4) and all miibus consumers (including miibus) out
ru from kern.flp to mfsroot.flp. This leaves 9K of the free
ru space for kern.flp.
Yey! 5-current distribution will come back again, thank you!
On Wed, Jul 24, 2002 at 08:07:11PM +0200, John Hay wrote:
On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
ru Moved vx(4) and all miibus consumers (including miibus) out
ru from kern.flp to mfsroot.flp. This leaves 9K of the free
ru space for kern.flp.
On Wed, Jul 24, 2002 at 08:07:11PM +0200, John Hay wrote:
On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
ru Moved vx(4) and all miibus consumers (including miibus) out
ru from kern.flp to mfsroot.flp. This leaves 9K of the free
ru space for
ru This was broken again. I don't have any ideas of what to move
ru out.
There are some ideas to do around boot floppies in my mind:
1) More drivers to move kernel modules, including other network
drivers, pccard and friends, filesystems, etc. Apparantly it
reduces kernel size so
jhay nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
jhay reside somewhere else.
It seems that it's time to make the 3rd floppy for kernel modules...
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of
On Wed, 24 Jul 2002 20:28:02 +0200 (SAT), John Hay [EMAIL PROTECTED] said:
We can save some space (I think) by not gziping the individual help
files, but leave them unzipped. Then the final gzip of the whole image
should be able to do a better job of it. But I doubt if it will give
us enough
On 24-Jul-2002 Makoto Matsushita wrote:
jhay nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
jhay reside somewhere else.
It seems that it's time to make the 3rd floppy for kernel modules...
We could start using cdboot for CD installs, and then just tailor the
floppy
On Wed, Jul 24, 2002 at 03:03:44PM -0400, John Baldwin wrote:
On 24-Jul-2002 Makoto Matsushita wrote:
jhay nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
jhay reside somewhere else.
It seems that it's time to make the 3rd floppy for kernel modules...
We could
brooks It does work though.
It should work, but I wonder if 5-current kernel can mount CD-ROM as
the root filesystem. I've tried before (March/2002 or something), but
it doesn't work, kernel refused to mount CD-ROM (see email archive for
more detail). Sorry if it was already fixed.
-- -
My system is down to one cpu (the first slot is appears to have eaten
itself and using it results in interesting smells from the power supply),
but I'm still running a SMP kernel.
Anything else I should probe with gdb?
FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Wed Jul 24
TCP mount of nfs seems to be broken.
# mount bar:/usr /mnt
[tcp] bar:/usr: RPCPROG_NFS: RPC: Unknown protocol
I tracked this down to lib/libc/rpc/rpcb_clnt.c. Seems like
the problem is in __rpcb_findaddr_timed().
diff -r 1.9 rpcb_clnt.c
--- rpcb_clnt.c 22 Mar 2002 23:18:37 - 1.9
+++
In message: [EMAIL PROTECTED]
Makoto Matsushita [EMAIL PROTECTED] writes:
:
: ru This was broken again. I don't have any ideas of what to move
: ru out.
:
: There are some ideas to do around boot floppies in my mind:
:
: 1) More drivers to move kernel modules, including other
I have the same problem. heres my debug dump. It seems to happen to me
always when sound is playing. I also get pages of warnings about pcm
and could sleep with lock.
/usr/src/sys/vm/uma_core.c:1332: could sleep with pcm0:play:0 locked from
/usr/src/sys/dev/sound/pcm/dsp.c:690
M. Warner Losh wrote:
I've noticed that some of the older cam drivers are about all that is
in the way of making CAM truly loadable. By that I mean having a
kernel with all supported devices that aren't loadable forces CAM to
be in the kernel because some of the SCSI devices aren't (yet)
Alex Zepeda wrote:
[ kdbg output removed]
The most applicable dmesg output I could find was:
Memory modified after free 0xc215d000(8188)
panic: Most recently used by none
I've gotten this same panic with a kernel+world cvsup'd from Sun Jul 21
23:43 EDT, just got one a few minutes ago. I'm
In the last episode (Jul 24), Terry Lambert said:
M. Warner Losh wrote:
I've noticed that some of the older cam drivers are about all that is
in the way of making CAM truly loadable. By that I mean having a
kernel with all supported devices that aren't loadable forces CAM to
be in the
On Thu, 2002-07-25 at 11:45, Terry Lambert wrote:
Anything in the boot path needs to be static, by definition,
or you face the Catch-22 of needing to load the driver in
order to be able to load the driver.
Uhh, not really.
If your BIOS supports it (which it must for you to boot off it) then
Craig Dooley wrote:
I have the same problem. heres my debug dump. It seems to happen to me
always when sound is playing. I also get pages of warnings about pcm
and could sleep with lock.
/usr/src/sys/vm/uma_core.c:1332: could sleep with pcm0:play:0 locked from
Daniel O'Connor wrote:
On Thu, 2002-07-25 at 11:45, Terry Lambert wrote:
Anything in the boot path needs to be static, by definition,
or you face the Catch-22 of needing to load the driver in
order to be able to load the driver.
Uhh, not really.
If your BIOS supports it (which it must
M. Warner Losh wrote:
: Think CDROM install.
Dude, what crack are you smoking? How many times to we have to tell
you. We have a boot loader that knows how to read the kernel from the
cdrom or scsi or whatever. IT is a tiny increment to also load
additional modules at that time that
On Thu, 2002-07-25 at 14:01, Terry Lambert wrote:
So, given that the install from a CDROM boots from a floppy
image that's faked up by the CDROM drive BIOS, and the image
doesn't include the full boot loader, how exactly is it that
the partial boot loader code acts like the full bootloader
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
31 matches
Mail list logo
