Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Thu, Jun 24, 2010 at 05:50:59PM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: Dag-Erling Smørgrav d...@des.no writes: I expect this to produce the same error as before; if not, there is something seriously wrong. the error is different... echo fsck_ffs: /usr/lib/libc.a /usr/lib/libufs.a .depend cc -O1 -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c dir.c This is wrong. It shouldn't compile anything. Did you do anything at all to your tree (src or obj) after the failed buildworld? sorry, I probably misunderstood you again. I did rm -rf /usr/obj/* before trying your suggested commands. I guess now this is not what you wanted. So, just for me to be clear, I need to proceed with the buildworld, until I get the error, and then, without cleaning anything, do % cd /usr/src % make buildenv % cd rescue/rescue % make Is that correct? sorry for the bother and many thanks for your help -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, 24 Jun 2010 09:54:45 -0700 Ted Faber fa...@isi.edu wrote: On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote: On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. The clear winner, and one I was unaware of. Thanks, Tom. CUPS_OVERWRITE_BASE seems to do an odd thing. It doesn't install the cups binaries in /usr/bin, but it does do a chmod on everything it replaces in /usr/bin . For example praxis:~$ ls -l /usr/bin/lpr -r-sr-sr-x 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr # portupgrade -f cups-base-1.4.3 praxis:~$ ls -l /usr/bin/lpr -- 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr I'll still use it, but interesting behavior. IMO if you're going to make the binaries in base non-executable you might just as well delete them. But CUPS_OVERWRITE_BASE does have the advantage that it works without (active) user intervention. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: So, just for me to be clear, I need to proceed with the buildworld, until I get the error, and then, without cleaning anything, do % cd /usr/src % make buildenv % cd rescue/rescue % make Is that correct? Yes. Then you take the cc comand line that failed and run it again with the -v option and show us the output. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic in deadlkres
I've got panic on 9-current from Jun 25 2010
May be this is bug in deadlock resolver
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/kern/kern_clock.c:203
db show alllocks
Process 0 (kernel) thread 0xc4dcd270 (100047)
shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
/usr/src/sys/kern/kern_clock.c:193
db show lock 0xc4dcd270
class: spin mutex
name: D
flags: {SPIN, RECURSE}
state: {OWNED}
(kgdb) bt
#0 doadump () at pcpu.h:248
#1 0xc05ae59f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ae825 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc048ff45 in db_panic (addr=Could not find the frame base for db_panic.
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc04923ef in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229
#7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc078696b in trap (frame=0xc4b31bd0) at /usr/src/sys/i386/i386/trap.c:692
#9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc05daf30 in kdb_enter (why=0xc07ea02d panic, msg=0xc07ea02d panic) at
cpufunc.h:71
#11 0xc05ae806 in panic (fmt=0xc07efd94 blockable sleep lock (%s) %s @ %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:573
#12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203, interlock=0x0)
at /usr/src/sys/kern/subr_witness.c:1067
#13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203)
at /usr/src/sys/kern/kern_mutex.c:200
#14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#15 0xc0588721 in fork_exit (callout=0xc05705ea deadlkres, arg=0x0,
frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843
#16 0xc076ca80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
--
WBR,
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic in deadlkres
On Fri, 25 Jun 2010 09:50:40 + (UTC), Anton Yuzhaninov wrote:
AY I've got panic on 9-current from Jun 25 2010
It's wrong date. The system is:
FreeBSD 9.0-CURRENT #0: Fri May 28 23:47:37 MSD 2010
AY
AY May be this is bug in deadlock resolver
AY
AY panic: blockable sleep lock (sleep mutex) process lock @
AY /usr/src/sys/kern/kern_clock.c:203
AY
db show alllocks
AY Process 0 (kernel) thread 0xc4dcd270 (100047)
AY shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
AY /usr/src/sys/kern/kern_clock.c:193
AY
db show lock 0xc4dcd270
AY class: spin mutex
AY name: D
AY flags: {SPIN, RECURSE}
AY state: {OWNED}
--
WBR,
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Use of boot0cfg to set boot slice broke between r209459 and r209502
Well, one one of my machines -- I realize that there are some machines for which it's been problematic for a while. And all of the machines I'm using run FreeBSD/i386. But it had been working on my build machine since I acquired it (a few months ago) in daily use. Of course, I didn't notice the effect, as after I finished building smoke-checking head on the build machine, I power it off, via: sudo boot0cfg -s 2 aacd0 sudo shutdown -p now || sudo shutdown -r now (as leaving it on generates too much noise and heat). And when I powered it up last night (in preparation for the nightly update of my local mirrors and the start of the morning's builds), I failed to note that it was running head, vs. stable/7 (as I had intended). A similar use of boot0cfg on my laptop remains working. Here are the respective uname -a outputs from the build machine: FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #198 r209459: Wed Jun 23 06:05:16 PDT 2010 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #199 r209502: Thu Jun 24 05:41:59 PDT 2010 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 (As you can see, I run a GENERIC kernel on the build machine.) I've placed a copy of a recent stable/7 dmesg.boot in http://www.catwhisker.org/~david/FreeBSD/stable_7/dmesg.boot; when I next boot CURRENT, I'll grab dmesg.boot stuff it in http://www.catwhisker.org/~david/FreeBSD/head/dmesg.boot. (That should be within a few hours.) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpeQoVMvQMHr.pgp Description: PGP signature
Re: Use of boot0cfg to set boot slice broke between r209459 and r209502
On Friday 25 June 2010 7:40:11 am David Wolfskill wrote: Well, one one of my machines -- I realize that there are some machines for which it's been problematic for a while. And all of the machines I'm using run FreeBSD/i386. 209469 perhaps? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADS UP: removal of acpi_aiboost(4)
Hi, In about a month, acpi_aiboost(4) will be removed. You should start using acpi_aibs(4) starting today. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iSCSI boot driver version 0.1.1 for iBFT
Sorry, isboot-0.1.1 was broken under i386 kernel + loader. The version 0.1.2 is uploaded in my blog. Also I uploaded isboot integrated FreeBSD 7.3 disc1, 8.1-RC1 dics1 and making script. Use at your own risk. You need only iBFT supported NIC and iSCSI target. Please see Intel's site about iBFT supported NIC. http://www.intel.com/support/network/adapter/pro100/sb/CS-028681.htm If you can connect to iSCSI target by NIC BIOS, isboot.ko shows the following log. In this case, em0 is configured automatically with NIC0 parameter in iBFT, and you can install FreeBSD to da1 directly and you can boot from da1. If you want to try to copy existing FreeBSD, then configure NIC and loading isboot.ko via loader.conf or kldload isboot.ko from shell. Then, use normal way such as dump/restore. Note: do not set IP to em0 when installation. it might be a problem. --- iSCSI boot driver version 0.1.2 IS: Initiator name: iqn.2007-09.jp.ne.peach:pluto NIC0: IP address: 192.168.3.48 NIC0: Prefix: 24 NIC0: Gateway: 0.0.0.0 NIC0: MAC address: 00:15:17:97:85:ab TGT0: Target IP address: 192.168.3.36 TGT0: Target Port: 3260 TGT0: Target LUN: 2 TGT0: Target name: iqn.2007-09.jp.ne.peach:isboot1 Boot NIC: em0 Configure IPv4 by NIC0 Attempting to login to iSCSI target and scan all LUNs. ... cut ... da0 at isboot0 bus 0 scbus0 target 0 lun 0 da0: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C) da1 at isboot0 bus 0 scbus0 target 0 lun 2 da1: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da1: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) da2 at isboot0 bus 0 scbus0 target 0 lun 3 da2: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da2: 1024MB (2097152 512 byte sectors: 64H 32S/T 1024C) ... cut ... Boot device: da1 --- Download links: http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh Try it you self :) Daisuke Aoyama ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Use of boot0cfg to set boot slice broke between r209459 and r209502
On Fri, Jun 25, 2010 at 08:37:36AM -0400, John Baldwin wrote: On Friday 25 June 2010 7:40:11 am David Wolfskill wrote: Well, one one of my machines -- I realize that there are some machines for which it's been problematic for a while. And all of the machines I'm using run FreeBSD/i386. 209469 perhaps? Apparently so. Here's what I did to test the above assertion: * Booted the build machine from slice 4 (usual head slice); cloned that slice to slice 1; booted from slice 1. * In a head src working directory, I issued svn diff -c209469 and saw that r209469 merely added 2 lines to usr.sbin/boot0cfg/boot0cfg.c. * On the build machine's src working directory, I edited usr.sbin/boot0cfg/boot0cfg.c to remove the lines in question. * Then (as root), I made /usr/src/usr.sbin/boot0cfg/ my current working directory and issued: make make install * I then issued boot0cfg -s 4 aacd0 shutdown -r now then watched the serial console. * I noticed that the default boot slice -- which had been 1 -- was now 4. * For grins, I then booted slice 4 (head) in single-user mode, mounted the file systems, then invoked the boot0cfg executable from slice 1 to switch the default to slice 2, then issued halt -p. I waited a bit, then powered the machine back up (WoL can be handy!) noted it was booting from slice 2, brought it up in single-user mode, then issued halt -p to reduce its power consumption and heat nouse generation. All that said, it looks as if r209469 merely noticed an existing error condition and tried to do something arguably sensible with it, rather than merely ignore it. So it would seem that there's a more fundamental issue at stake, here Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpbEZn5Am1Ln.pgp Description: PGP signature
Re: panic in deadlkres
On 25 June 2010 13:50, Anton Yuzhaninov cit...@citrin.ru wrote:
I've got panic on 9-current from Jun 25 2010
May be this is bug in deadlock resolver
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/kern/kern_clock.c:203
db show alllocks
Process 0 (kernel) thread 0xc4dcd270 (100047)
shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
/usr/src/sys/kern/kern_clock.c:193
db show lock 0xc4dcd270
class: spin mutex
name: D
flags: {SPIN, RECURSE}
state: {OWNED}
(kgdb) bt
#0 doadump () at pcpu.h:248
#1 0xc05ae59f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ae825 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc048ff45 in db_panic (addr=Could not find the frame base for db_panic.
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc04923ef in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229
#7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc078696b in trap (frame=0xc4b31bd0) at /usr/src/sys/i386/i386/trap.c:692
#9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc05daf30 in kdb_enter (why=0xc07ea02d panic, msg=0xc07ea02d panic)
at cpufunc.h:71
#11 0xc05ae806 in panic (fmt=0xc07efd94 blockable sleep lock (%s) %s @
%s:%d) at /usr/src/sys/kern/kern_shutdown.c:573
#12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9,
file=0xc07e3b20 /usr/src/sys/kern/kern_clock.c, line=203, interlock=0x0)
at /usr/src/sys/kern/subr_witness.c:1067
#13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203)
at /usr/src/sys/kern/kern_mutex.c:200
#14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#15 0xc0588721 in fork_exit (callout=0xc05705ea deadlkres, arg=0x0,
frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843
#16 0xc076ca80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
Hi!
[throw in ideas (just ignore them if they're dumb, thinking badly atm).]
AFAIK, that indicates that some thread already has
a spin mutex and then it tries to acquire a sleep mutex.
Looks like kern/kern_clock.c v1.213 (SVN rev 206482)
has a regression in handling ticks wrap-up
w.r.t. it doesn't release a thread mutex, does it?
From subr_witness.c:
1062: * Since spin locks include a critical section, this check
1063: * implicitly enforces a lock order of all sleep
locks before
1064: * all spin locks.
1065: */
1066:if (td-td_critnest != 0 !kdb_active)
1067:panic(blockable sleep lock (%s) %s @ %s:%d,
1068:class-lc_name, lock-lo_name, file, line);
From kern_clock.c, v1.213 (in several places, while holding a thread lock):
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick)
+ continue;
Should not it be like the next:
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick) {
+ thread_unlock(td);
+ continue;
+ }
The precondition idea to reproduce it is to lock a subject thread
in some deadlkres callout, handle re-wrap condition, then try
to lock a process to witch the thread belongs in (n+m)'th deadlkres
callout, or in different context.
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iSCSI boot driver version 0.1.1 for iBFT
On 25/06/2010 17:32, Daisuke Aoyama wrote: Sorry, isboot-0.1.1 was broken under i386 kernel + loader. The version 0.1.2 is uploaded in my blog. Also I uploaded isboot integrated FreeBSD 7.3 disc1, 8.1-RC1 dics1 and making script. Use at your own risk. You need only iBFT supported NIC and iSCSI target. Since I dont have a supported nic, would the iscsi support in gpxe (http://etherboot.org/wiki/iscsiboot) be enough? (might give it a try if i get time after the weekend.) Vince Please see Intel's site about iBFT supported NIC. http://www.intel.com/support/network/adapter/pro100/sb/CS-028681.htm If you can connect to iSCSI target by NIC BIOS, isboot.ko shows the following log. In this case, em0 is configured automatically with NIC0 parameter in iBFT, and you can install FreeBSD to da1 directly and you can boot from da1. If you want to try to copy existing FreeBSD, then configure NIC and loading isboot.ko via loader.conf or kldload isboot.ko from shell. Then, use normal way such as dump/restore. Note: do not set IP to em0 when installation. it might be a problem. --- iSCSI boot driver version 0.1.2 IS: Initiator name: iqn.2007-09.jp.ne.peach:pluto NIC0: IP address: 192.168.3.48 NIC0: Prefix: 24 NIC0: Gateway: 0.0.0.0 NIC0: MAC address: 00:15:17:97:85:ab TGT0: Target IP address: 192.168.3.36 TGT0: Target Port: 3260 TGT0: Target LUN: 2 TGT0: Target name: iqn.2007-09.jp.ne.peach:isboot1 Boot NIC: em0 Configure IPv4 by NIC0 Attempting to login to iSCSI target and scan all LUNs. ... cut ... da0 at isboot0 bus 0 scbus0 target 0 lun 0 da0: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C) da1 at isboot0 bus 0 scbus0 target 0 lun 2 da1: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da1: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) da2 at isboot0 bus 0 scbus0 target 0 lun 3 da2: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da2: 1024MB (2097152 512 byte sectors: 64H 32S/T 1024C) ... cut ... Boot device: da1 --- Download links: http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh Try it you self :) Daisuke Aoyama ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: I need reply in Embedded FreeBSD Kernel Theme
hi sorry for being late in reply but I had some problems in the last week. I hope u still remeber what I was talking about :) @chargen Thanx for ur reply. Embedded computer systems permeate all aspects of our daily lives. Alarm clocks, coffee makers, digital watches, cell phones, and automobiles are just a few of the devices that make use of embedded systems. The design and development of such systems is unique, because the design constraints are different for each system. I supposed a new design for reducing the size of the kernel to be able to work in such an environment which has some constraints make it does not have the ability to get large memory, large storage devices or others. / as far as your document goes: We will unload all the drivers that indicated with zeros in the module metadata file. That would make the OS to be a few of Megabytes. unload? what is the logic here? I'm sorry but what is the real gain here, // The configuration file is dependent on the kernel (which is included as a compiled kernel). If I unload these unneeded drivers, I decrease the size of the compiled kernel So it will have the ability to work in more constrained environment and that is suitable to work for Operating Systems for small chips for embedded systems. As the Internet grew, the requirements of embedded systems also began to grow in complexity. In addition to solving classic embedded systems problems, system designers were required to add connectivity for sending and receiving data or providing an automated method for software upgrades. Rather than increase the development effort, system designers have moved toward using third-party hardware and evaluating open source software. Thanx Chargen @ andrew Thanx for your reply. I appreciate your effort to download the document. Regarding the uploading of the document to that site, I am sorry for that but I tried to attach it with the email but it was refused because its size was too large. I did not send it in the text part because the text format and tables will be lost. I am sorry for that. // /// After a couple of quick readings, I'm not sure I correctly understand what you plan to achieve. It sounds like you are trying to achive something like hardware specific dynamic module loading (like in Solaris, for example), but then it also sounds like you are trying to build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. Are you compiling a kernel at some point rather than just generating a loader.conf for modules in order to minimise the running size? This approach will combine the two both. It will build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. It also will use hardware specific dynamic module loading because I don't have to load all the drivers for devices connected to the machine. I will use this dynamic module loading at the start-up only not at the run time because some considerations of the embedded systems for chips not being to load modules and change how to work at run time. that would make power problems. I was most confused by We will unload all the drivers that indicated with zeros in the module metadata file. That would make the OS to be a few of Megabytes. Whether you are compiling a kernel for the (chosen) hardware based on a generated kernel or loader config, I don't see a sensible case in which you would ever need to unload any driver. /// yeah I know it is not sensible but I wrote it as a result of what I supposed before so it has no meaning. just a result to clarify what I reduced here. Thanx for ur sympathy and I will be glad to send you my next file to get ur comments about. As much fun as it is spending hours manually tweaking and testing a kernel config for each system and deciding what modules to use, I like the idea of a one time guided process based on accurately identified hardware to build an optimal kernel, so I hope that's what you're proposing. // Actually, I am deciding many time guided process based on accurately identified hardware to build an optimal kernel because I think this is more dynamic for considerations of changing the purpose of the embedded system. I mean sometimes u may need to perform deterministic operation in this boot so u do not have to load all drivers which there will be a lot of unneeded drivers of them at this boot process. I will determine the dependencies to provide optimal kernel. Thanx Andrew @ Matt Thanx for ur reply Matt.
HEADS-UP: object directory name change
I recently committed a change that changes the name of the object tree where things are built to if you are cross compiling. Rather than /usr/obj/$TARGET_ARCH, it is now /usr/obj/$TARGET.$TARGET_ARCH. The reason for the change is so that embedded platforms with multiple endians can compile into the same tree. This means that if you are cross building on a regular basis, you'll need to update your cross tools. If you are building kernels, then you'll need a make kernel-toolchain for things to work again. You'll also be able to reclaim the disk space used by the old tree. If you want, a simple mv will do the trick. In a few days mips and arm will change how endian is represented and you'll need two trees for each if you want to compile both endians (one for mips.mipsel and one for mips.mipseb). I'm still working out some snags with how make universe will cope with the kernels, so I've not pulled the trigger on that change yet. thank you for your patience... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: I need reply in Embedded FreeBSD Kernel Theme
On 24 June 2010 11:06, Mohammed Farrag mfar...@freebsd.org wrote: @ Matt Thanx for ur reply Matt. / FreeBSD is already a very modular system and the traditional way (a traditional way) to build for embedded systems is to follow the NanoBSD build method (tools included in the source tree) with a stripped down kernel in which you only load the modules your hardware requires using the FreeBSD loader (or after the initial boot). yeah I read about that. My mentor suggested that before and my idea is very close to NanoBSD but I don't know if the freebsd loader will load the moduls based on the hardware requirements or user requirements. I will be glad to reply me. Modules are loaded by the user adding entries to /boot/loader.conf. e.g. if_sis_load=YES. That example will load the sis driver for the Silicon Image network interfaces on my Soekris net4801 board as I have removed almost everything in my kernel and just load the modules I require. Some modules will automatically load when another driver requires them. FreeBSD does not try to discover and reconfigure your hardware at boot time like the kudzu utility in Linux. Instead it will attach to the hardware for which you have drivers in your kernel or for which you have told the loader to load modules for. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
