command line switch to disable following symlink in DIFF program
Is "diff" program supposed to have a switch at command line to disable following (ignore) symbolic links when -r switch is given, like many other programs do? In many places, a directory or source file can be symbolically linked multiple times to different archives. Since the original source will be diffed anyway, why "diff" needs to follow symlinks to compare a same source multiple times? In the other case, if partition A has a symlink to somewhere in partition B, which has a symlink back to partition A , then "diff -r" will loop forever. I think that "diff" need a switch to disable following symlink to compare final object, instead, just check if symlink exists in both checked directories, like ls -P. -Jin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: jailctl with multiple ip per jail
Hello OxY, Monday, December 12, 2005, 10:35:33 PM, you wrote: > yes, i know that, but what i want is to use an existing jail > with 2ip > not to create additional jails.. although i dont know if it really works, but here is what i was able to google (check those mijail patches) :) place your questions on pjd@ http://garage.freebsd.pl/ -- Best regards, Danielmailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jailctl with multiple ip per jail
yes, i know that, but what i want is to use an existing jail with 2ip not to create additional jails.. - Original Message - From: "wiqd" <[EMAIL PROTECTED]> To: "OxY" <[EMAIL PROTECTED]> Cc: Sent: Monday, December 12, 2005 10:16 PM Subject: Re: jailctl with multiple ip per jail On Mon, Dec 12, 2005 at 10:09:13PM +0100, OxY wrote: i think i can define other jails with this, am i wrong? You can define as many jails as you want with this, and use jailctl to start and stop them as needed. Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jailctl with multiple ip per jail
On Mon, Dec 12, 2005 at 10:09:13PM +0100, OxY wrote: >i think i can define other jails with this, am i wrong? You can define as many jails as you want with this, and use jailctl to start and stop them as needed. Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jailctl with multiple ip per jail
i think i can define other jails with this, am i wrong? - Original Message - From: "wiqd" <[EMAIL PROTECTED]> To: "OxY" <[EMAIL PROTECTED]> Cc: Sent: Monday, December 12, 2005 10:04 PM Subject: Re: jailctl with multiple ip per jail On Mon, Dec 12, 2005 at 06:58:06PM +0100, OxY wrote: hi! i have a little problem with jailctl, (sorry if it's not the right maillist, dunno where should i ask it) my question is can i use jailctl with two or more ip/jail or not? in the jails.conf i have to add hostname:ipaddress per jail, and wonder if i could make it work with other ip addresses... hi there, yes just add them all, seperated with a space. Example: # List the names of all your jails here JAILS="host1.domain.tld:192.168.1.20 host2.domain.tld:192.168.1.21 host3.domain.tld:192.168.1.22" thanks for your help! Hope it does help :) Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jailctl with multiple ip per jail
On Mon, Dec 12, 2005 at 06:58:06PM +0100, OxY wrote: >hi! > >i have a little problem with jailctl, (sorry if it's not the right maillist, >dunno where should i ask it) > >my question is can i use jailctl with two or more ip/jail or not? > >in the jails.conf i have to add hostname:ipaddress per jail, and wonder >if i could make it work with other ip addresses... hi there, yes just add them all, seperated with a space. Example: # List the names of all your jails here JAILS="host1.domain.tld:192.168.1.20 host2.domain.tld:192.168.1.21 host3.domain.tld:192.168.1.22" > >thanks for your help! Hope it does help :) Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jailctl with multiple ip per jail
On 12/12/05, OxY <[EMAIL PROTECTED]> wrote: > hi! Hi, > > my question is can i use jailctl with two or more ip/jail or not? AFAIK, you can use bind a jail just to one Ip address... Don't know if things have changed since 6.0 > thanks for your help! Hope this helps, -- Pietro Cerutti <[EMAIL PROTECTED]> Beansidhe - SwiSS Death / Thrash Metal Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming or what?" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Wednesday 07 December 2005 05:09 pm, Danilo Asara wrote:
> [EMAIL PROTECTED] [~]$ uname -a
> FreeBSD resolza.fastwebnet.it 6.0-STABLE FreeBSD 6.0-STABLE #0: Fri
> Nov18 11:19:38 CET
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RESOLZA i386
> [EMAIL PROTECTED] [~]$
>
>
> [EMAIL PROTECTED] [/usr/crash]# kgdb kernel.debug.0 vmcore.0
> [GDB will not be able to debug user-mode
> threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i386-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc0500411
> stack pointer = 0x28:0xef58fcac
> frame pointer = 0x28:0xef58fcdc
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 722 (artsd)
> trap number = 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> kdb_backtrace(100,c2a83a80,28,ef58fc6c,c) at kdb_backtrace+0x29
> panic(c06b2fec,c06d9f5b,0,f,c09b) at panic+0x114
> trap_fatal(ef58fc6c,0,c2a83a80,c2890bb8,c) at trap_fatal+0x2ca
> trap_pfault(ef58fc6c,0,0) at trap_pfault+0x1d7
> trap(8,28,28,c2ea9e70,c2a83a80) at trap+0x2fd
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc0500411, esp = 0xef58fcac, ebp = 0xef58fcdc ---
> kse_release(c2a83a80,ef58fd04,1,0,200292) at kse_release+0x165
> syscall(3b,3b,3b,80f2100,81) at syscall+0x2bf
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (383, FreeBSD ELF32, kse_release), eip = 0x287d81af, esp =
> 0xbf9fef30, ebp = 0xbf9fef8c ---
> Uptime: 12h9m20s
> Dumping 1023 MB (2 chunks)
> chunk 0: 1MB (159 pages) ... ok
> chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879
> 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591
> 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303
> 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
>
> #0 doadump () at pcpu.h:165
> 165 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) where
> #0 doadump () at pcpu.h:165
> #1 0xc05132bf in boot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:399
> #2 0xc0513615 in panic (fmt=0xc06b2fec "%s")
> at /usr/src/sys/kern/kern_shutdown.c:555
> #3 0xc068d8ca in trap_fatal (frame=0xef58fc6c, eva=0)
> at /usr/src/sys/i386/i386/trap.c:831
> #4 0xc068d5d7 in trap_pfault (frame=0xef58fc6c, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:742
> #5 0xc068d1ed in trap (frame=
> {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1024811408, tf_esi =
> -1029162368, tf_ebp = -279380772, tf_isp = -279380840, tf_ebx =
> -1026066384, tf_edx = -1029162368, tf_ecx = -1026066303, tf_eax = 0,
> tf_trapno = 12, tf_err = 0, tf_eip = -1068497903, tf_cs = 32, tf_eflags
> = 2687622, tf_esp = -1036728832, tf_ss = 30})
> at /usr/src/sys/i386/i386/trap.c:432
> #6 0xc067aaca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #7 0xc0500411 in kse_release (td=0xc2a83a80, uap=0xef58fd04)
> at /usr/src/sys/kern/kern_kse.c:428
The problem is here. You can try posting this to [EMAIL PROTECTED] and see
if someone there can help you debug this further.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DragonFly talk at the upcoming BAYLISA (15 December 2005)
:Hello Matt! : :I hope you'll make the materials available on the Net. Yah, I'm putting some slides together and will make them available after the talk. -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jailctl with multiple ip per jail
hi! i have a little problem with jailctl, (sorry if it's not the right maillist, dunno where should i ask it) my question is can i use jailctl with two or more ip/jail or not? in the jails.conf i have to add hostname:ipaddress per jail, and wonder if i could make it work with other ip addresses... thanks for your help! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mmap() sendfile()
On 12/12/2005 08:38, Mike Silbersack wrote: > On Mon, 12 Dec 2005, Cedric Tabary wrote: > > >If it is true, doing a sendfile() on some very big files (even if not > >keeping the descriptor open after) will kill the cache ? > > > >Please help me to understand why this patch ? and the difference between > >sendfile() and mmap() at the memory or cache level.. > > > >Cédric > > My memory escapes me on all the details, but there were two potential > reasons not to use sendfile with 4.x that no longer apply in 5.x and > above: > > 1. Sendfile used to send small files inefficiently, sending the http > headers in one packet and the data in another. I fixed this in 5.x. > > 2. Alan Cox improved the memory efficiency of sendfile greatly, it now > uses a single kernel buffer for all copies of the same block of the same > file, whereas the old implementation made an in-kernel copy of each block, > making it no more memory efficient than using mbufs. What about using sendfile() or mmap() on NFS ? Cédric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/ports/sysutils/sge is broken ? for amd 64
On Mon, Dec 12, 2005 at 06:39:03PM +0900, gama wrote: > Thank you for good advises. > I could go ahead. > But, now , my installation of sge for amd64 is stopped due to unkown > reasons > anyone could install sge for amd64? > My message is like belows You still didn't turn off java support like it was suggested. Kris pgpVYGoVjFZpk.pgp Description: PGP signature
Re: mmap() sendfile()
On Mon, 12 Dec 2005, Cedric Tabary wrote: If it is true, doing a sendfile() on some very big files (even if not keeping the descriptor open after) will kill the cache ? Please help me to understand why this patch ? and the difference between sendfile() and mmap() at the memory or cache level.. Cédric My memory escapes me on all the details, but there were two potential reasons not to use sendfile with 4.x that no longer apply in 5.x and above: 1. Sendfile used to send small files inefficiently, sending the http headers in one packet and the data in another. I fixed this in 5.x. 2. Alan Cox improved the memory efficiency of sendfile greatly, it now uses a single kernel buffer for all copies of the same block of the same file, whereas the old implementation made an in-kernel copy of each block, making it no more memory efficient than using mbufs. So, if there was a reason to not use sendfile under 4.x, it's probably not true anymore. Someone sent me a patch to thttpd which made it more efficient on FreeBSD a looong time ago, I don't recall what changes he had made. Mike "Silby" Silbersack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl, HW_PHYSMEM, and crippled gcc
On 2005-12-09 21:46, Dan Nelson <[EMAIL PROTECTED]> wrote:
>In the last episode (Dec 10), Giorgos Keramidas said:
On Thu, Dec 08, 2005 at 05:06:16PM -0800, Steve Kargl wrote:
> Anyone have any insight into fixing gcc to make better
> use of system memory on systems with more than 4 GB.
> It appears that libiberty/physmem.c tries to use sysctl()
> to determine the amount of physical memory in a system.
>
> { /* This works on *bsd and darwin. */
> unsigned int physmem;
> size_t len = sizeof physmem;
> static int mib[2] = { CTL_HW, HW_PHYSMEM };
>
> if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0
> && len == sizeof (physmem))
> return (double) physmem;
> }
>
> This works if you have less than 4GB because of the unsigned
> int physmem. I have 12 GB, which of course, when expanded
> to the number of bytes doesn't fit into a unsigned int physmem.
>>
>> Can someone with access to a system with more than 4 GB verify that the
>> following works correctly?
>>
>> % flame:/home/keramida/tmp/physmem$ cat -n physmem.c
>> % 9 int
>> % 10 main(void)
>> % 11 {
>> % 12 uint64_t physmem;
>> % 13 size_t len = sizeof physmem;
>> % 14 static int mib[] = { CTL_HW, HW_PHYSMEM };
>> % 15 static size_t miblen = sizeof(mib) / sizeof(mib[0]);
>> % 16
>> % 17 if (sysctl(mib, miblen, &physmem, &len, NULL, 0) != 0)
>> % 18 err(1, "sysctl hw.physmem");
>> % 19 printf("Physical memory = %ju bytes\n", (intmax_t)physmem);
>> % 20 return EXIT_SUCCESS;
>> % 21 }
>
> Won't this break on x86, where physmem is 32 bits? Just use "unsigned
> long", which is what the sysctl type is according to kern_mib.c .
I'm not sure it breaks, but seeing it just work on a couple of systems
doesn't mean much. You're right of course, that the correct type from
kern_mib.c is better.
Thanks :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Cardbus panics
- Forwarded message from Josef Grosch <[EMAIL PROTECTED]> - Date: Sat, 10 Dec 2005 13:52:43 -0800 From: Josef Grosch <[EMAIL PROTECTED]> To: freebsd-questions@freebsd.org Subject: Cardbus panics I have an IBM T22 thinkpad running FreeBSD 5.4-RELEASE-p8. I have the CardBus devices in the current kernel. When I insert a CardBus device, A Xircom RealPort CardBus Ethernet I get a kernel panic like so; Dec 9 18:42:32 paris kernel: cbb alloc res fail Dec 9 18:42:32 paris kernel: cardbus1: Can't get memory for IO ports Dec 9 18:42:32 paris kernel: dc0: port 0-0x7f mem \ 0x8800-0x880007ff,0x88000800-0x88000fff at device 0.0 on cardbus1 Dec 9 18:42:32 paris kernel: cbb alloc res fail Dec 9 18:42:32 paris kernel: dc0: couldn't map ports/memory Dec 9 18:42:32 paris kernel: Dec 9 18:42:32 paris kernel: Dec 9 18:42:32 paris kernel: Fatal trap 12: page fault while in kernel mode Dec 9 18:42:32 paris kernel: fault virtual address = 0x30 Dec 9 18:42:32 paris kernel: fault code= supervisor write, pag\ e not present Dec 9 18:42:32 paris kernel: instruction pointer = 0x8:0xc07b01f2 Dec 9 18:42:32 paris kernel: stack pointer = 0x10:0xd5428c10 Dec 9 18:42:32 paris kernel: frame pointer = 0x10:0xd5428c14 Dec 9 18:42:32 paris kernel: code segment = base 0x0, limit 0xfff\ ff, type 0x1b Dec 9 18:42:32 paris kernel: = DPL 0, pres 1, def32 1, gran 1 Dec 9 18:42:32 paris kernel: processor eflags = interrupt enabled, resume, IO\ PL = 0 Dec 9 18:42:32 paris kernel: current process = 38 (cbb1) Dec 9 18:42:32 paris kernel: trap number = 12 Dec 9 18:42:32 paris kernel: panic: page fault Dec 9 18:42:32 paris kernel: Uptime: 35s Dec 9 18:42:32 paris kernel: Cannot dump. No dump device defined. Dec 9 18:42:32 paris kernel: Automatic reboot in 15 seconds - press a key on t\ he console to abort Any ideas How I can fix this? The suggested sysctl, hw.pci.allow_unsupported_io_range, does not seem to exist in the kernel. Josef -- Josef Grosch | Another day closer to a | FreeBSD 5.4 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. - End forwarded message - -- Josef Grosch | Another day closer to a | FreeBSD 5.4 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgpc6StQOPoVd.pgp Description: PGP signature
Re: mmap() sendfile()
On Mon, Dec 12, 2005 at 09:39:30AM +0100, Cedric Tabary wrote:
>
> This is some sort of file cache, it works by mmap()ing some files and
> keeping the mmap address in a hashtable. I suppose this is used to keep
> the file in memory until munmap() is called.
I guess this is used for accessing file's data directly (read automatic),
without read(2) and write(2) system calls, according to source files
if mmap(2) is not supported, then malloc(3) and read(2) are used for reading
files (I checked source files very quickly) and write(2) for transferring
data to socket. I do not understand why mmap() is called with MAP_PRIVATE
and PROT_READ at the same time, because copy-objects are not supported
on FreeBSD (probably on other systems too).
> The patch is just removing the mmap() and keeping file descriptors open
> for use by sendfile(). But I don't know if replacing the mmap() by
> sendfile() has the same cache effect ?!
The sendfile(2) system call is used for transferring some portion
of a file to a stream socket. Since this is a system call and not
library function it can implement data transfers from a file to
a socket entirely in the kernel, without bringing data to the
userspace as in case of read(2) or mmap(2). This technique sometimes
is called "zerocopy".
> Keeping the file descriptor open after using sendfile() will keep the
> file in memory ??
I think no. Owners of files' pages are VM objects, even if a file
(really vnode) does not have any reference and hold counter, its vnode
will go to the free list, but its VM pages in corresponding VM object
will be still in memory, until another pages which have higher priority
(according to the logic of VM system) will cause removing of file's
pages from the VM cache or until there are not enough free vnodes.
Just test it: open file, write something to it, close it and
{ read it and close it } several times, reboot and read this file
again and compare times.
> If it is true, doing a sendfile() on some very big files (even if not
> keeping the descriptor open after) will kill the cache ?
VM system keeps pages in several queues (read classes), so reading
big files will not remove frequently used pages (also wired pages
cannot be removed from memory). Read corresponding paragraph
in FAQ ("What do the various memory states..." and next one).
> Please help me to understand why this patch ? and the difference between
> sendfile() and mmap() at the memory or cache level..
sendfile(2) will transfer data from a file to a socket entirely in
the kernel, without context switching, unlike read(2) which requires
context switching and mmap(2) which will require context switching in
case of page fault; as I understand VM cache will be used in the same
way.
As usually correct me if I'm wrong.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
boot FreeBSD from cdrom using grub
Hi,
I'm trying to make an iso image that will boot FreeBSD using GRUB
boot loader.
Grub will boot /boot/loader and the loader will boot /boot/kernel. It
goes well on my disk, but when I try to make a livecd, it fails. I spend
some time figuring out that loader does not probe cd it self, it depends
on boot1 to tell him when cd to boot. So I did some hack on loader.
Bellow is the diff:
*** sys/boot/i386/loader/main.c.bak Sun Dec 11 19:32:29 2005
--- sys/boot/i386/loader/main.c Sun Dec 11 22:04:29 2005
***
*** 228,235
if ((new_currdev.d_type == biosdisk.dv_type) &&
((new_currdev.d_kind.biosdisk.unit = bd_bios2unit(biosdev)) ==
-1)) {
printf("Can't work out which disk we are booting from.\n"
! "Guessed BIOS device 0x%x not found by probes, defaulting
to disk0:\n", biosdev);
! new_currdev.d_kind.biosdisk.unit = 0;
}
env_setenv("currdev", EV_VOLATILE, i386_fmtdev(&new_currdev),
i386_setcurrdev, env_nounset);
--- 228,238
if ((new_currdev.d_type == biosdisk.dv_type) &&
((new_currdev.d_kind.biosdisk.unit = bd_bios2unit(biosdev)) ==
-1)) {
printf("Can't work out which disk we are booting from.\n"
! "Guessed BIOS device 0x%x not found by probes, defaulting
to cd0(%d):\n", biosdev, biosdev);
! bc_add(biosdev);
! new_currdev.d_type = bioscd.dv_type;
! new_currdev.d_dev = &bioscd;
! new_currdev.d_kind.bioscd.unit = bc_bios2unit(biosdev);
}
env_setenv("currdev", EV_VOLATILE, i386_fmtdev(&new_currdev),
i386_setcurrdev, env_nounset);
Then the kernel starts, but when the kernel try to mount the root fs, it
stops. I have the follow line in my /etc/fstab
/dev/acd0c / cd9660 ro 0 0
I am stranded. Anyone can help?
thx
Tony
*** sys/boot/i386/loader/main.c.bak Sun Dec 11 19:32:29 2005
--- sys/boot/i386/loader/main.c Sun Dec 11 22:04:29 2005
***
*** 228,235
if ((new_currdev.d_type == biosdisk.dv_type) &&
((new_currdev.d_kind.biosdisk.unit = bd_bios2unit(biosdev)) == -1)) {
printf("Can't work out which disk we are booting from.\n"
! "Guessed BIOS device 0x%x not found by probes, defaulting to
disk0:\n", biosdev);
! new_currdev.d_kind.biosdisk.unit = 0;
}
env_setenv("currdev", EV_VOLATILE, i386_fmtdev(&new_currdev),
i386_setcurrdev, env_nounset);
--- 228,238
if ((new_currdev.d_type == biosdisk.dv_type) &&
((new_currdev.d_kind.biosdisk.unit = bd_bios2unit(biosdev)) == -1)) {
printf("Can't work out which disk we are booting from.\n"
! "Guessed BIOS device 0x%x not found by probes, defaulting to
cd0(%d):\n", biosdev, biosdev);
! bc_add(biosdev);
! new_currdev.d_type = bioscd.dv_type;
! new_currdev.d_dev = &bioscd;
! new_currdev.d_kind.bioscd.unit = bc_bios2unit(biosdev);
}
env_setenv("currdev", EV_VOLATILE, i386_fmtdev(&new_currdev),
i386_setcurrdev, env_nounset);___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/ports/sysutils/sge is broken ? for amd 64
Thank you for good advises. I could go ahead. But, now , my installation of sge for amd64 is stopped due to unkown reasons anyone could install sge for amd64? My message is like belows - if [ -s /usr/ports/java/jdk15/work/control/build/bsd-amd64/tmp/java/java.lang/java/. classes.list ] ; \ then /usr/local/linux-sun-jdk1.4.2/bin/javac -J-Xbootclasspath/p:../../sun/javac/ javac/gjc.jar -Xbootclasspath/p:../../sun/javac/javac/collect.jar -target jsr14 -J-Xmx128m -classpath /usr/ports/java/jdk15/work/control/build/bsd-amd64/classes -bootclasspath "/usr/ports/java/jdk15/work/control/build/bsd-amd64/lib/jce.jar:/usr/ports/j ava/jdk15/work/control/build/bsd-amd64/lib/jsse.jar" -sourcepath "/usr/ports/java/jdk15/work/control/build/bsd-amd64/gensrc:../../../src/sola ris/classes:../../../src/share/classes" -d /usr/ports/java/jdk15/work/control/build/bsd-amd64/classes -encoding cii -source 1.5 -source 1.5 -target 1.5 -encoding ascii \ ../../../src/share/classes/java/lang/Object.java ../../../src/share/classes/java/lang/Class.java ../../../src/share/classes/java/lang/Thread.java ../../../src/share/classes/java/lang/Character.java ../../../src/share/classes/sun/misc/ASCIICaseInsensitiveComparator.java ../../../src/share/classes/sun/misc/VM.java ../../../src/share/classes/sun/misc/Signal.java ../../../src/share/classes/sun/misc/NativeSignalHandler.java ../../../src/share/classes/java/lang/ThreadGroup.java ../../../src/share/classes/java/lang/ThreadLocal.java ../../../src/share/classes/java/lang/InheritableThreadLocal.java ../../../src/share/classes/java/lang/String.java ../../../src/share/classes/java/lang/ConditionalSpecialCasing.java ../../../src/share/classes/java/lang/StringCoding.java ../../../src/share/classes/java/lang/StringBuffer.java ../../../src/share/classes/java/lang/StringBuilder.java ../../../src/share/classes/java/lang/SuppressWarnings.java ../../../src/share/classes/java/lang/AbstractStringBuilder.java ../../../src/share/classes/java/lang/ClassLoader.java ../../../src/share/classes/java/lang/AssertionStatusDirectives.java ../../../src/share/classes/java/lang/Enum.java ../../../src/share/classes/java/lang/StrictMath.java ../../../src/share/classes/java/lang/Math.java ../../../src/share/classes/sun/misc/FloatingDecimal.java ../../../src/share/classes/sun/misc/FormattedFloatingDecimal.java ../../../src/share/classes/java/lang/Number.java ../../../src/share/classes/java/lang/Byte.java ../../../src/share/classes/java/lang/Short.java ../../../src/share/classes/java/lang/Integer.java ../../../src/share/classes/java/lang/Long.java ../../../src/share/classes/java/lang/Float.java ../../../src/share/classes/java/lang/Double.java ../../../src/share/classes/java/lang/Boolean.java ../../../src/share/classes/java/lang/Void.java ../../../src/share/classes/java/lang/Runnable.java ../../../src/share/classes/java/lang/Cloneable.java ../../../src/share/classes/java/lang/CharSequence.java ../../../src/share/classes/java/lang/SecurityManager.java ../../../src/share/classes/java/lang/Runtime.java ../../../src/share/classes/java/lang/RuntimePermission.java ../../../src/share/classes/java/lang/Shutdown.java ../../../src/solaris/classes/java/lang/Terminator.java ../../../src/share/classes/java/lang/System.java ../../../src/share/classes/java/lang/Compiler.java ../../../src/share/classes/java/lang/Throwable.java ../../../src/share/classes/java/lang/Exception.java ../../../src/share/classes/java/lang/IllegalAccessException.java ../../../src/share/classes/java/lang/InstantiationException.java ../../../src/share/classes/java/lang/ClassNotFoundException.java ../../../src/share/classes/java/lang/CloneNotSupportedException.java ../../../src/share/classes/java/lang/InterruptedException.java ../../../src/share/classes/java/lang/NoSuchFieldException.java ../../../src/share/classes/java/lang/NoSuchMethodException.java ../../../src/share/classes/java/lang/RuntimeException.java ../../../src/share/classes/java/lang/ArithmeticException.java ../../../src/share/classes/java/lang/ArrayStoreException.java ../../../src/share/classes/java/lang/ClassCastException.java ../../../src/share/classes/java/lang/IndexOutOfBoundsException.java ../../../src/share/classes/java/lang/ArrayIndexOutOfBoundsException.java ../../../src/share/classes/java/lang/StringIndexOutOfBoundsException.java ../../../src/share/classes/java/lang/NegativeArraySizeException.java ../../../src/share/classes/java/lang/NullPointerException.java ../../../src/share/classes/java/lang/IllegalStateException.java ../../../src/share/classes/java/lang/IllegalArgumentException.java ../../../src/share/classes/java/lang/NumberFormatException.java ../../../src/share/classes/java/lang/IllegalThreadStateException.java ../../../src/share/classes/java/lang/IllegalMonitorStateException.java ../../../src/share/classes/java/lang/SecurityException.java ../../../src/share/classes/java/lang/Type
mmap() sendfile()
I was looking at the freebsd port of thttpd and i saw this patch : /usr/ports/www/thttpd/files/patch-mmc.c This is some sort of file cache, it works by mmap()ing some files and keeping the mmap address in a hashtable. I suppose this is used to keep the file in memory until munmap() is called. The patch is just removing the mmap() and keeping file descriptors open for use by sendfile(). But I don't know if replacing the mmap() by sendfile() has the same cache effect ?! Keeping the file descriptor open after using sendfile() will keep the file in memory ?? If it is true, doing a sendfile() on some very big files (even if not keeping the descriptor open after) will kill the cache ? Please help me to understand why this patch ? and the difference between sendfile() and mmap() at the memory or cache level.. Cédric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
