Re: hack.So: could not read symbols
2012/3/12 Fernando Apesteguía : > I'm using 9.0-RELEASE. > > I downloaded the snapshot "9.0-CURRENT-201012" and tried to build it's > kernel but I get this error: > > hack.So: could not read symbols: File in wrong format > > file reports this: > > ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically > linked, not stripped > > I compared this file with the same file generated during the > compilation of the 9.0-RELEASE GENERIC kernel and they are identical. > > What's the problem here? I saw a similar issue trying to build a stable/8 kernel on 9.0-RELEASE. Doing a make kernel-toolchain before make buildkernel fixed the issue. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel memory usage
CPU architecture and model have a lot to do with performance. You will also get different results if you used qemu in place of VirtualBox. Qemu allows you to choose different emulated architectures, CPUs, and machine bases. What's the downside? You have to use the command line. Install qemu and run a series of virtual machines. Embedded devices also include Power(PC), ARMv?, Coldfire, et al; you're only dealing with i386 and/or the 64 bit extension (AMD64). CISC- which does not contain any hardware modification to be a RISC replacement- runs fewer instructions than RISC due to the limited number of registers. Take this into consideration every time a program runs. Everything else also matters on real and emulated systems: Is it ide, scsi, sdd, flashdevice for the hard drive? What type of RAM? Dedicated or shared disk? On 3/11/12, Da Rock <9phack...@herveybayaustralia.com.au> wrote: > I may be required to move this to embedded, but I am only looking for > generalisation. > > Recently a thread came up on questions regarding memory usage, and a > post was made regarding wired memory being nearly all kernel- something > I was ready to dispute, but then I thought I'd better make sure. > > So I tested a few theories first off: > > 1. Comparing memory usage across machines > > I checked servers and desktops as well as vm's for memory usage, and I > found some interesting results. On a firewall with no apps installed > only 35M wired is used, on a desktop up to 700M~ can be used. Even as a > dedicated server with a few services used it remains around 35M. > > Surely this means that the wired memory used is not just kernel? But I > held off my assumptions as it was still plausible that the structures > used by the kernel could balloon that far, too. > > 2. Stripped down, lean mean, kernel machine > > I then (using a vm I was building a kernel for anyway) stripped down a > kernel in a VBox VM using le drivers for network to see what could be > achieved. This is my kernel conf: > > include GENERIC > ident VPN > options IPSEC > options IPSEC_DEBUG > options IPSEC_NAT_T > device crypto > device enc > > # minimise kernel > nooptions UFS_GJOURNAL > nooptions MD_ROOT > nooptions NFSCL > nooptions NFSD > nooptions NFSLOCKD > nooptions NFS_ROOT > nooptions MSDOSFS > nooptions CD9660 > nooptions PROCFS > nooptions PSEUDOFS > nodevice fdc > nodevice mvs > nodevice siis > nodevice ahc > nodevice ahd > nodevice esp > nodevice hptiop > nodevice isp > nodevice mpt > nodevice mps > nodevice sym > nodevice trm > nodevice adv > nodevice adw > nodevice aic > nodevice bt > nodevice ses > nodevice amr > nodevice arcmsr > nodevice ciss > nodevice dpt > nodevice hptmv > nodevice hptrr > nodevice irr > nodevice ips > nodevice mly > nodevice twa > nodevice aac > nodevice aacp > nodevice ida > nodevice mfi > nodevice mlx > nodevice twe > nodevice tws > nodevice splash > nodevice cbb > nodevice pccard > nodevice cardbus > nodevice uart > nodevice ppc > nodevice ppbus > nodevice lpt > nodevice plip > nodevice ppi > nodevice puc > nodevice bxe > nodevice de > nodevice em > nodevice igb > nodevice ixgbe > nodevice ti > nodevice txp > nodevice vx > nodevice miibus > nodevice ae > nodevice age > nodevice alc > nodevice ale > nodevice bce > nodevice bfe > nodevice bge > nodevice dc > nodevice et > nodevice fxp > nodevice jme > nodevice lge > nodevice msk > nodevice nfe > nodevice nge > nodevice pcn > nodevice re > nodevice rl > nodevice sf > nodevice sge > nodevice sis > nodevice sk > nodevice ste > nodevice stge > nodevice tl > nodevice tx > nodevice vge > nodevice vr > nodevice wb > nodevice xl > nodevice cs > nodevice ed > nodevice ex > nodevice ep > nodevice fe > nodevice sn > nodevice xe > nodevice wlan > nooptions IEEE80211_DEBUG > nooptions IEEE80211_AMPDU_AGE > nooptions IEEE80211_SUPPORT_MESH > nodevice wlan_wep > nodevice wlan_ccmp > nodevice wlan_tkip > nodevice wlan_amrr > nodevice an > nodevice ath > nodevice ath_pci > nodevice ath_hal > nooptions AH_SUPPORT_AR5416 > nodevice ath_rate_sample > nodevice ipw > nodevice iwi > nodevice iwn > nodevice malo > nodevice mwl > nodevice ral > nodevice wi > nodevice wpi > nodevice md > nooption USB_DEBUG > nodevice uhci > nodevice ohci > nodevice ehci > nodevice xhci > nodevice usb > nodevice uhid > nodevice ukbd > nodevice ulpt > nodevice umass > nodevice ums > nodevice urio > nodevice u3g > nodevice uark > nodevice ubsa > nodevice uftdi > nodevice uipaq > nodevice uplcom > nodevice uslcom > nodevice uvisor > nodevice uvscom > nodevice aue > nodevice axe > nodevice cdce > nodevice cue > nodevice kue > nodevice rue > nodevice udav > nodevice rum > nodevice run > nodevice uath > nodevice upgt > nodevice ural > nodevice urtw > nodevice zyd > #nodevice firewire > nodevice fwe > nodevice fwip > #nodevice dcons > #nodevice dcons_rom > nodevice sound > nodevice snd_es137x > nodevice snd_hda > nodevice snd_ich > nodevice snd_uaudio > nodevice snd_via8233 > > World was also rebuilt as recommended by t
hack.So: could not read symbols
I'm using 9.0-RELEASE. I downloaded the snapshot "9.0-CURRENT-201012" and tried to build it's kernel but I get this error: hack.So: could not read symbols: File in wrong format file reports this: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped I compared this file with the same file generated during the compilation of the 9.0-RELEASE GENERIC kernel and they are identical. What's the problem here? Thanks in advance ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [vfs] buf_daemon() slows down write() severely on low-speed CPU
On Mon, Mar 12, 2012 at 04:00:58PM +0100, Svatopluk Kraus wrote: > Hi, > >I have solved a following problem. If a big file (according to > 'hidirtybuffers') is being written, the write speed is very poor. > >It's observed on system with elan 486 and 32MB RAM (i.e., low speed > CPU and not too much memory) running FreeBSD-9. > >Analysis: A file is being written. All or almost all dirty buffers > belong to the file. The file vnode is almost all time locked by > writing process. The buf_daemon() can not flush any dirty buffer as a > chance to acquire the file vnode lock is very low. A number of dirty > buffers grows up very slow and with each new dirty buffer slower, > because buf_daemon() eats more and more CPU time by looping on dirty > buffers queue (with very low or no effect). > >This slowing down effect is started by buf_daemon() itself, when > 'numdirtybuffers' reaches 'lodirtybuffers' threshold and buf_daemon() > is waked up by own timeout. The timeout fires at 'hz' period, but > starts to fire at 'hz/10' immediately as buf_daemon() fails to reach > 'lodirtybuffers' threshold. When 'numdirtybuffers' (now slowly) > reaches ((lodirtybuffers + hidirtybuffers) / 2) threshold, the > buf_daemon() can be waked up within bdwrite() too and it's much worse. > Finally and with very slow speed, the 'hidirtybuffers' or > 'dirtybufthresh' is reached, the dirty buffers are flushed, and > everything starts from beginning... Note that for some time, bufdaemon work is distributed among bufdaemon thread itself and any thread that fails to allocate a buffer, esp. a thread that owns vnode lock and covers long queue of dirty buffers. > >On the system, a buffer size is 512 bytes and the default > thresholds are following: > >vfs.hidirtybuffers = 134 >vfs.lodirtybuffers = 67 >vfs.dirtybufthresh = 120 > >For example, a 2MB file is copied into flash disk in about 3 > minutes and 15 second. If dirtybufthresh is set to 40, the copy time > is about 20 seconds. > >My solution is a mix of three things: >1. Suppresion of buf_daemon() wakeup by setting bd_request to 1 in > the main buf_daemon() loop. I cannot understand this. Please provide a patch that shows what do you mean there. >2. Increment of buf_daemon() fast timeout from hz/10 to hz/4. >3. Tuning dirtybufthresh to (((lodirtybuffers + hidirtybuffers) / > 2) - 15) magic. Even hz / 10 is awfully long time on modern hardware. The dirtybufthresh is already the sysctl that you can change. The 32MB is indeed around the lowest amount of memory where recent FreeBSD can make an illusion of being useful. I am not sure how much should the system be tuned by default for such configuration. > >The mention copy time is about 30 seconds now. > >The described problem is just for information to anyone who can be > interested in. Comments are welcome. However, the bd_request thing is > more general. > >bd_request (despite its description) should be 0 only when > buf_daemon() is in sleep(). Otherwise, wakeup() on &bd_request channel > is useless. Therefore, setting bd_request to 1 in the main > buf_daemon() loop is correct and better as it saves time spent by > wakeup() on not existing channel. > > Svata > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" pgpzucBWBKxIH.pgp Description: PGP signature
pccbb device doesn't send device_shutdown() to childs (reboot freezes)
Hi, I solved very curious problem with rarely system (FreeBSD-9) freezing during reboot. Finally, I found out that system freezes in ep device callout. The part of device tree is following: -> pccbb -> pccard -> ep cbb_pci_shutdown() method in pccbb device places the cards in reset, turns off the interrupts and powers down the socket. No child has a chance to know about it. Thus, if ep device callout fires between device_shutdown() is called on root device and interrupts are disabled, the callout freezes in never-ending while loop, which reads status from hardware (now without power). I propose following change (editted by hand) in cbb_pci_shutdown(): struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(brdev); + + /* Inform all childs. */ + bus_generic_shutdown(brdev); + /* * We're about to pull the rug out from the card, so mark it as * gone to prevent harm. */ sc->cardok = 0; Futhermore, ep device (ed device too, ... ?) has not implemented device_shutdown method. So, fixing pccbb device is not enough to solve the freezing problem. I somehow patched the mentioned devices too, but maybe someone more competent should do it for FreeBSD tree. Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[vfs] buf_daemon() slows down write() severely on low-speed CPU
Hi, I have solved a following problem. If a big file (according to 'hidirtybuffers') is being written, the write speed is very poor. It's observed on system with elan 486 and 32MB RAM (i.e., low speed CPU and not too much memory) running FreeBSD-9. Analysis: A file is being written. All or almost all dirty buffers belong to the file. The file vnode is almost all time locked by writing process. The buf_daemon() can not flush any dirty buffer as a chance to acquire the file vnode lock is very low. A number of dirty buffers grows up very slow and with each new dirty buffer slower, because buf_daemon() eats more and more CPU time by looping on dirty buffers queue (with very low or no effect). This slowing down effect is started by buf_daemon() itself, when 'numdirtybuffers' reaches 'lodirtybuffers' threshold and buf_daemon() is waked up by own timeout. The timeout fires at 'hz' period, but starts to fire at 'hz/10' immediately as buf_daemon() fails to reach 'lodirtybuffers' threshold. When 'numdirtybuffers' (now slowly) reaches ((lodirtybuffers + hidirtybuffers) / 2) threshold, the buf_daemon() can be waked up within bdwrite() too and it's much worse. Finally and with very slow speed, the 'hidirtybuffers' or 'dirtybufthresh' is reached, the dirty buffers are flushed, and everything starts from beginning... On the system, a buffer size is 512 bytes and the default thresholds are following: vfs.hidirtybuffers = 134 vfs.lodirtybuffers = 67 vfs.dirtybufthresh = 120 For example, a 2MB file is copied into flash disk in about 3 minutes and 15 second. If dirtybufthresh is set to 40, the copy time is about 20 seconds. My solution is a mix of three things: 1. Suppresion of buf_daemon() wakeup by setting bd_request to 1 in the main buf_daemon() loop. 2. Increment of buf_daemon() fast timeout from hz/10 to hz/4. 3. Tuning dirtybufthresh to (((lodirtybuffers + hidirtybuffers) / 2) - 15) magic. The mention copy time is about 30 seconds now. The described problem is just for information to anyone who can be interested in. Comments are welcome. However, the bd_request thing is more general. bd_request (despite its description) should be 0 only when buf_daemon() is in sleep(). Otherwise, wakeup() on &bd_request channel is useless. Therefore, setting bd_request to 1 in the main buf_daemon() loop is correct and better as it saves time spent by wakeup() on not existing channel. Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pmc(3): when are the counters updated?
2012/3/12 Vitaly Magerya
> Fabien Thomas wrote:
> >> So, what's going on here? Is this the intended behavior, or can it
> >> be changed? And how do I get accurate readings?
> >
> > If i remember well:
> > The current code will get real HW PMC if the PMC is running and attached
> to owner.
> > The first case is not true in your code so you get the saved value which
> is updated at
> > process switch out time.
> >
> > I think you can do:
> > pmc_read
> > pmc_stop.
>
> Changing the code to this:
>
>[...]
>pmc_read(pmcid, &value);
>pmc_stop(pmcid);
>printf("reading #1: %lu\n", (unsigned long)value);
>pmc_read(pmcid, &value);
>printf("reading #2: %lu\n", (unsigned long)value);
>sleep(1);
>pmc_read(pmcid, &value);
>printf("reading #3: %lu\n", (unsigned long)value);
>[...]
>
> Gives me this output:
>
>reading #1: 15039441
>reading #2: 0
>reading #3: 15084037
>
> So, it seems that you are correct; pmc_read reports current values if
> the PMC is not stopped, after which it's updated on context switches.
>
>
Hello,
I've used the PMC library in the past, and I think that you can't stop
the counters if you want to read them. By having them started, you can read
their value anywhere in the code, not only in context switches.
I suggest you changing the code to something like
pmc_read(..);
do_some_calculation(..);
pmc_read(..); /* difference between reads is devoted to
do_some_calculation */
and when you're about to finalize the application, issue pmc_stop.
Please, also note, sleep(1) yields the process, so counting it (even if
it's 1 second or more) will probably result in very low counter values.
Regards
--
Fry: You can see how I lived before I met you.
Bender: You lived before you met me?!
Fry: Yeah, lots of people did.
Bender: Really?!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pmc(3): when are the counters updated?
Fabien Thomas wrote:
>> So, what's going on here? Is this the intended behavior, or can it
>> be changed? And how do I get accurate readings?
>
> If i remember well:
> The current code will get real HW PMC if the PMC is running and attached to
> owner.
> The first case is not true in your code so you get the saved value which is
> updated at
> process switch out time.
>
> I think you can do:
> pmc_read
> pmc_stop.
Changing the code to this:
[...]
pmc_read(pmcid, &value);
pmc_stop(pmcid);
printf("reading #1: %lu\n", (unsigned long)value);
pmc_read(pmcid, &value);
printf("reading #2: %lu\n", (unsigned long)value);
sleep(1);
pmc_read(pmcid, &value);
printf("reading #3: %lu\n", (unsigned long)value);
[...]
Gives me this output:
reading #1: 15039441
reading #2: 0
reading #3: 15084037
So, it seems that you are correct; pmc_read reports current values if
the PMC is not stopped, after which it's updated on context switches.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
How to mount my USB disk ?
Once plugged, usbconfig will show: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12M) pwr=SAVE ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON But there is no da* in /dev, then i donot know how to mount it ? Sincerely! - e^(π.i) + 1 = 0 -- View this message in context: http://freebsd.1045724.n5.nabble.com/How-to-mount-my-USB-disk-tp5556741p5556741.html Sent from the freebsd-hackers mailing list archive at Nabble.com. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pmc(3): when are the counters updated?
Le 11 mars 2012 à 16:45, Vitaly Magerya a écrit :
> Hi, folks. I'm trying to use pmc(3) to analyze code fragments, and
> I've run into strange behavior: the counter values returned by
> pmc_read(3) sometimes show no increment between readings, but are
> updated a second later; even if the PMC in question was stopped
> before.
>
> Here's a test program:
>
>#include
>#include
>#include
>#include
>
>int main() {
>pmc_id_t pmcid;
>pmc_value_t value;
>int i;
>
>pmc_init();
>pmc_allocate("instructions", PMC_MODE_TC, 0, PMC_CPU_ANY, &pmcid);
>pmc_start(pmcid);
>for (i = 0; i < 500; i++);
>pmc_stop(pmcid);
>pmc_read(pmcid, &value);
>printf("first reading: %lu\n", (unsigned long)value);
>sleep(1);
>pmc_read(pmcid, &value);
>printf("second reading: %lu\n", (unsigned long)value);
>}
>
> It's output on my system (FreeBSD 8.2 amd64, an Intel Atom processor)
> is something like this:
>
>first reading: 0
>second reading: 15090110
>
> I don't really like both numbers; I expect the first reading not
> to be zero (there obviously are instructions between pmc_start and
> pmc_stop), and I expect the second reading not to differ from the
> first, as the PMC was stopped before both of them, so it's value
> should not change.
>
> So, what's going on here? Is this the intended behavior, or can it
> be changed? And how do I get accurate readings?
If i remember well:
The current code will get real HW PMC if the PMC is running and attached to
owner.
The first case is not true in your code so you get the saved value which is
updated at
process switch out time.
I think you can do:
pmc_read
pmc_stop.
>
> (BTW, is this the right list for such questions?)
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
