Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Wed, 28 Aug 2013 15:56:30 +0200 Ivan Voras ivo...@freebsd.org wrote: [jump to the chase] Why not leave it for sysadmins to tune it themselves if they want it: 1) They usually don't know about it until it's too late. 2) Dirhash is typically miniscule compared to todays memory sizes - a few dozen MBs even on very busy systems, and there are no typical situations where a large number of entries are filled in at the same time which block eviction of a large-ish amount of memory, so having reclaimage higher will automatically help in file-system intensive spikes without harming other uses. So, if I understand this correctly, a normal desktop user won't notice any real change, except that buildworld might get faster, and big servers will benefit? But could this negatively impact small, embedded systems, which usually have only small memory footprints? Although I suppose one could argue that they usually don't have large numbers of files cached in memory at any given time. -- Gary Jennejohn ___ 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: HDD write cache
On Sat, 2 Feb 2013 01:19:50 +0100 (CET) Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Investigating a bit more a device reset will also trigger the change so after changing the value you can use camcontrol reset to trigger the change to apply using e.g. camcontrol reset 0:0:0 THIS actually work. And the results are disastrous. in spite of NCQ working and fully filled, when unpacking source tree (as a test) onto UFS filesystem gstat shows at most 100 IOPS, and average 700 with write cache disabled. this is on / partition that spans 1/10 of disk. Drive can actually manage multiple writes in short distance well with write cache enabled. I also noticed a drastic drop in throughput when I disabled the write cache, about a factor of 4 or 5. However, in my case every HDD supports NCQ (32 tags), but NCQ is not enabled on any HDD. Whether that's because the driver for my chipset (ATI IXP700 AHCI SATA controller) doesn't turn NCQ on or for another reason, I can't say. I looked at the man page for camcontrol but a mechanism to turn on NCQ in the HDDs didn't jump off the page. Does anyone know off-hand of a way to turn on NCQ in the HDDs, other than maybe modifying the driver? -- Gary Jennejohn ___ 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: CAM disk I/O starvation
On Tue, 17 Apr 2012 12:30:15 -0700 Adrian Chadd adr...@freebsd.org wrote: On 17 April 2012 12:15, Gary Jennejohn gljennj...@googlemail.com wrote: I still have the old problem kernel around, but it's probably not instrumented for any meaningful diagnoses. Well do you know which version of which tree you used to build that? If it's head, you could just keep an earlier source tree around to build a kernel from. My /usr/src is from SVN, so I just need to boot it and do uname to get the revision. As a former src committer I like to be on the bleeding edge and I always run HEAD. -- Gary Jennejohn ___ 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: CAM disk I/O starvation
On Mon, 16 Apr 2012 14:39:12 -0700
Adrian Chadd adr...@freebsd.org wrote:
On 11 April 2012 10:21, Gary Jennejohn gljennj...@googlemail.com wrote:
Just for the archive my bad disk performance seems to have been fixed in
HEAD by svn commit r234074. Seems that all interrupts were being handled
by a single CPU/core (I have 6), which resulted in abysmal interrupt
handling when mutltiple disks were busy.
Since this commit my disk preformance is back to normal and long lags
are a thing of the past.
Hi,
This is kind of worrying. You only have a few disks, a single core
SHOULD be able to handle all the interrupts for those disks whilst
leaving plenty of cycles to spare to drive the rest of your system.
And you have 5 other cores.
Would you be willing to help out diagnose exactly why that particular
behaviour is causing you so much trouble? It almost sounds like
something in the IO path is blocking for far too long, not allowing
the rest of the system to move forward. That's very worrying for an
interrupt handler. :)
Yes, I agree completely. My first thought was that disk I/O
scheduling had somehow been pessimized. But then I thought -
wait a minute, I have disk caches enabled and command queuing is
enabled for all of them, so that shouldn't really have any
noticeable impact. So I was at a loss to explain why disk performance
had suddenly gotten so bad.
I'd be willing to spend some time on diagnosing it, but I have to come
up with a scenario which would reliably reproduce the problem. AFAICR
it generally happened when I was running csup/svn because my CVS
repositoy is on one disk and /usr/{ports,src} are on a different one.
I still have the old problem kernel around, but it's probably not
instrumented for any meaningful diagnoses.
--
Gary Jennejohn
___
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: CAM disk I/O starvation
On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung jryto...@gmail.com wrote: On 4/3/12, Gary Jennejohn gljennj...@googlemail.com wrote: It would be interesting to see your patch. I always run HEAD but maybe I could use it as a base for my own mods/tests. Here is the patch [patch removed] Just for the archive my bad disk performance seems to have been fixed in HEAD by svn commit r234074. Seems that all interrupts were being handled by a single CPU/core (I have 6), which resulted in abysmal interrupt handling when mutltiple disks were busy. Since this commit my disk preformance is back to normal and long lags are a thing of the past. -- Gary Jennejohn ___ 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: CAM disk I/O starvation
On Thu, 5 Apr 2012 05:22:46 +0200 Alexander Leidinger alexan...@leidinger.net wrote: On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung jryto...@gmail.com wrote: On 4/3/12, Gary Jennejohn gljennj...@googlemail.com wrote: It would be interesting to see your patch. I always run HEAD but maybe I could use it as a base for my own mods/tests. Here is the patch This looks fair if all your disks are working at the same time (e.g. RAID only setup), but if you have a setup where you have multiple disks and only one is doing something, you limit the amount of tags which can be used. No idea what kind of performance impact this would have. What about the case where you have more disks than tags? I also noticed that you do a strncmp for da. What about ada (available in 9 and 10), I would assume it suffers from the same problem. It seems to. All my disks are ada. -- Gary Jennejohn ___ 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: CAM disk I/O starvation
On Mon, 2 Apr 2012 10:55:31 -0700 Jerry Toung jryto...@gmail.com wrote: I am convinced that there is a bug in the CAM code that leads to I/O starvation. I have already discussed this privately with some. I am now bringing this up to the general audience to get more feedback. I've observed this with my onboard ATI IXP700 AHCI SATA controller and 2 or 3 SATA disks. When one disk gets busy all others are pretty much blocked until it finishes. Seems to me that this behavior is (fairly) recent. [snip] I have a patch and it fixes those problems. I can share it to the list if requested to. da0 and da1 now both automatically get 126 openings and based on that, extra logic implements fairness in cam/cam_xpt.c. No more 0 MB/s on da1. This is on 8.1-RELEASE FreeBSD. It would be interesting to see your patch. I always run HEAD but maybe I could use it as a base for my own mods/tests. -- Gary Jennejohn ___ 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: Where and when /etc/fstab is checking during boot
On Sun, 4 Mar 2012 19:32:36 -0500 Robert Simmons rsimmo...@gmail.com wrote: I've just finished working though building a FreeBSD box with an encrypted root partition as mentioned in the geli(8) man page: Ask for the passphrase on boot, before the root partition is mounted. This makes it possible to use an encrypted root partition. One will still need bootable unencrypted storage with a /boot/ directory, which can be a CD-ROM disc or USB pen-drive, that can be removed after boot. I've noticed something quite interesting about the way that fstab is read during boot. If you follow the instructions exactly as they are written in the geli(8) man page you soon discover that you also must have an /etc/fstab file in that same unencrypted partition. But this need not be the complete fstab file. It only needs to have the one line that describes /. Later, after the encrypted partition is mounted, the /etc/fstab inside the encrypted partition is then read and all other partitions listed in fstab are mounted as written there. I've tested this by putting empty fstabs and fstabs with just the line for / in both locations and booting to see what happens. Is this the correct behavior? Shouldn't the fstab file be read completely once and not twice? man 5 fstab It isn't explicitly stated, but implied, that fsck(8), mount(8) and umount(8) parse fstab every time they're invoked. It's a feature. -- Gary Jennejohn ___ 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: [RFT][patch] Scheduling for HTT and not only
On Mon, 06 Feb 2012 09:04:31 +0200 Alexander Motin m...@freebsd.org wrote: I've analyzed scheduler behavior and think found the problem with HTT. SCHED_ULE knows about HTT and when doing load balancing once a second, it does right things. Unluckily, if some other thread gets in the way, process can be easily pushed out to another CPU, where it will stay for another second because of CPU affinity, possibly sharing physical core with something else without need. I've made a patch, reworking SCHED_ULE affinity code, to fix that: http://people.freebsd.org/~mav/sched.htt.patch 10.0-CURRENT FreeBSD r231026M: Mon Feb 6 10:40:10 CET 2012 amd64 CPU: AMD Phenom(tm) II X6 1090T Processor (3214.71-MHz K8-class CPU) This patch seems pretty good. Previously I was using SCHED_4BSD. My simple test was make -j6 buildworld while loading web pages at the same time and observing the CPU core loading using gkrellm. In general the loads seemed to be more evenly distributed than without the patch. With the old ULE CPU0 seemed to be underutilized, now it's an equal partner. Web pages also loaded quite quickly despite the high load on the cores. I did notice some mouse pointer lag, but it was quite minor. The buildworld time also seemed to be pretty much the same as with 4BSD. Seems like a good start on improving ULE. -- Gary Jennejohn ___ 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: boot0.S empty #ifdef
On Mon, 5 Dec 2011 12:54:15 -0800 some body bsd.mh...@gmail.com wrote: I sent this to freebsd-drives too but I think that might not be the right list for it so here it is: I am starting to learn how the kernel works and have started by going through the boot loader and I've noticed that between lines 21-32 in boot0.S there are some empty #ifdef statements. I was wondering a) where are these paramaters defined and if they are defined, what difference does it make since it looks like it doesn't change anything since they're empty? #ifdef SIO #endif #ifdef CHECK_DRIVE #endif #ifdef ONLY_F_KEYS #endif These seem to be there to act as reminders for command line options which can be used to build boot0. They're also documented in Makefile. These are actually used later in the code. -- Gary Jennejohn ___ 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: who is in swap?
On Fri, 20 May 2011 15:30:34 -0700 Julian Elischer jul...@freebsd.org wrote: On 5/20/11 2:57 PM, Sean C. Farley wrote: On Fri, 20 May 2011, Julian Elischer wrote: On 5/20/11 5:32 AM, Bill Moran wrote: In response to Daniel Branissda...@cs.huji.ac.il: no, Who's on 3rd No. I Don't Know is on 3rd. Who's on 1st. I don't KNOW who's on 1st! Natcherly -- Gary Jennejohn ___ 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: [RELEASE] New Boot-Loader Menu
On Sun, 24 Apr 2011 18:53:11 -0700 Devin Teske dte...@vicor.com wrote: I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Here's a detailed discussion of the release complete with pictures: http://devinteske.com/new-freebsd-boot-loader-menu Here's the download: http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz The download is a FreeBSD package. You can execute: fetch [aboveURL] pkg_add loader_menu-1.0.tgz reboot And upon your next boot will use the new loader menu. A feature-complete sophisticated boot menu designed from the ground up. Although I personally never use the boot menu it's nice to see someone trying to make it more usable for the average FreeBSD user. -- Gary Jennejohn ___ 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: machdep.hlt_cpus not safe with ULE?
On Sat, 19 Feb 2011 12:36:57 - Steven Hartland kill...@multiplay.co.uk wrote: I'm trying to debug a possibly failing CPU, so I thought it would be easy just disable the cores using machdep.hlt_cpus and see if we see the panic's we've been seeing. The problem is it seems ULE doesnt properly support machdep.hlt_cpus and still schedules processes onto the halted cpus which obviously causes problems. Can anyone confirm this behaviour? Should machdep.hlt_cpus and I assume the logical counterpart never be used with ULE? Looking at the kernel source it appears that only sched_4bsd.c makes use of hlt_cpus_mask. -- Gary Jennejohn ___ 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: memstick.img is bloated with 7% 2K blocks of nulls
On Tue, 15 Feb 2011 01:19:45 +0100
Julian H. Stacey j...@berklix.com wrote:
Could author p...@freebsd.org cc'd (or someone else if they are clear)
please explain what cmdline is ?
Possibly commit an appended // comment after int cmdline = 0;
(in line 76 of 8.1 current src/sbin/mdconfig/mdconfig.c) wgat it's for ?
(cmdline seems in most places to maybe be an enum { 1
2 3 } for { a d l } alternate forms of command mdconfig,
... yet case 'd': sets cmdline = 3 not 2 ?
( 't' 'f' sets cmdline=2 ; not 1.Puzzling.
It's simply a state machine to ensure that mutually exclusive options
aren't used together. See the manpage; it's pretty clear from it that
only certain combinations of options are allowed.
--
Gary Jennejohn
___
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: [maybe spam] Re: linux PF_PACKET compatibility
On Fri, 11 Feb 2011 17:19:17 -0800 Julian Elischer jul...@freebsd.org wrote: On 2/11/11 4:03 PM, Da Rock wrote: Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. Ther's a sendarp() routine which uses PF_PACKET to directly access the network driver and bypass the stack. Lazy Linuxers who have no idea or don't care that other operating systems exist. -- Gary Jennejohn ___ 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: empty function macros
On Sun, 30 Jan 2011 17:29:41 +
Alexander Best arun...@freebsd.org wrote:
hi there,
i noticed freebsd has a few of the following macros:
#define FUNC(sb)
when you do something like
if (cond)
FUNC(i)
the compiler complains about an if statement with an empty body. any sensible
way of dealing with this issue?
i saw some reiserfs code which does the following to silence compilers:
#define FUNC(sb) do { } while (0)
What happens if you treat it like a real function call and put ';'
after it?
--
Gary Jennejohn (gj@)
___
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: rtld optimizations
On Wed, 26 Jan 2011 11:40:13 -0500 John Baldwin j...@freebsd.org wrote: On Wednesday, January 26, 2011 10:25:27 am Mark Felder wrote: On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. It's really not my place to say, but it seems strange that if an optimization is available people would ignore it because they don't think it's important enough. I don't understand this mentality; if it's not going to break anything and it obviously can improve performance in certain use cases, why not merge it and make FreeBSD even better? Many things that seem obvious aren't actually true, hence the need for actual testing and benchmarks. I can't claim to have rigorously benchmarked this, but I am running with a patched ld-elf.so.1 right now and can state that *subjectively* there is absolutely no difference in the perceived performance. firefox, opera and OpenOffice still seem to be dogs the first time they start up. Since this is all about perception I see no benefit in applying the patch, although it doesn't seem to have broken anything either. -- Gary Jennejohn (gj@) ___ 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: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE
On Thu, 06 Jan 2011 19:15:35 -0800 Craig Leres le...@ee.lbl.gov wrote: I recently upgraded my desktop from 7.2-RELEASE to 8.1-RELEASE and noticed that I no longer get biff messages in my console xterm window. I traced this to: xterm: cannot open console: Operation not permitted and see that the TIOCCONS code in tty_generic_ioctl() is checking for PRIV_TTY_CONSOLE. So far so good. But I don't *any* code that ever grants PRIV_TTY_CONSOLE! As far as I can tell it's now totally impossible to ever set a terminal as a console TTY (even for root). This ioctl has been effectively disabled. Shouldn't PRIV_TTY_CONSOLE be granted when a user logs onto /dev/ttyvX? See the reply I just posted to current. If your xterm is setuid root it does work, because the privilege checking code doesn't look at the credential passed in. It's still a bug, but you can work around it. -- Gary Jennejohn ___ 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: Inappropriate ioctl for device
On Fri, 24 Dec 2010 18:17:18 +0330
Mohammad Hedayati hedayati...@gmail.com wrote:
I'm writing a simple char device. So far everything went so good
(read/write), but here I'm going to add support for ioctl.
int
ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thread
*td)
{
int error = 0;
uprintf(Here...\n);
return(error);
}
and I'm calling it here:
len = ioctl(cd, 0);
perror(ioctl);
but when runnig it says:
ioctl: Inappropriate ioctl for device
Carefully read ioctl(2) and consider that you're passing in 0 as the cmd.
If you still don't understand your error, post again.
Hint: look at /sys/kern/sys_generic.c:^ioctl
--
Gary Jennejohn
___
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: Inappropriate ioctl for device
On Fri, 24 Dec 2010 19:37:37 +0330
Mohammad Hedayati hedayati...@gmail.com wrote:
On Fri, Dec 24, 2010 at 7:31 PM, Gary Jennejohn
gljennj...@googlemail.comwrote:
On Fri, 24 Dec 2010 18:17:18 +0330
Mohammad Hedayati hedayati...@gmail.com wrote:
I'm writing a simple char device. So far everything went so good
(read/write), but here I'm going to add support for ioctl.
int
ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct
thread *td)
{
int error = 0;
uprintf(Here...\n);
return(error);
}
and I'm calling it here:
len = ioctl(cd, 0);
perror(ioctl);
but when runnig it says:
ioctl: Inappropriate ioctl for device
Carefully read ioctl(2) and consider that you're passing in 0 as the cmd.
If you still don't understand your error, post again.
Hint: look at /sys/kern/sys_generic.c:^ioctl
--
Gary Jennejohn
It was a misspelling, I'm doing as bellow, if you mean the u_long.
unsinged long cmd = 0;
len = ioctl(cd, cmd);
No, that isn't what I meant. Read the kernel code - cmd = 0 is not
legal.
--
Gary Jennejohn
___
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: new cpuid bits
On Fri, 19 Nov 2010 17:39:53 +0200 Andriy Gapon a...@freebsd.org wrote: Guys, I would like to add definitions for couple more useful CPUID bits, but I am greatly confused about how to name them. I failed to deduce the naming convention from the existing definitions and I am not sure how to make the names proper and descriptive. The bits in question are returned by CPUID.6 in EAX and ECX. CPUID.6 block is described by both AMD and Intel as Thermal and Power Management (Leaf). Bits in EAX are defined only for Intel at present, the bit in ECX is defined for both. Description/naming of the bits from the specifications: EAX[0]: Digital temperature sensor is supported if set EAX[1]: Intel Turbo Boost Technology Available EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. ECX[0]: Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT MSRs). AMD: EffFreq: effective frequency interface. How does the following look to you? I will appreciate suggestions/comments. Thanks! Index: sys/amd64/include/specialreg.h === --- sys/amd64/include/specialreg.h(revision 215524) +++ sys/amd64/include/specialreg.h(working copy) @@ -136,6 +136,15 @@ #define CPUID2_AESNI0x0200 /* + * Important bits in the Thermal and Power Management flags + * CPUID.6 EAX and ECX. + */ +#define CPUTPM1_SENSOR 0x0001 +#define CPUTPM1_TURBO 0x0002 +#define CPUTPM1_ARAT0x0004 +#define CPUTPM2_EFFREQ 0x0001 + +/* * Important bits in the AMD extended cpuid flags */ #define AMDID_SYSCALL 0x0800 Maybe add a comment in which register the bits are to be found, like in the text? -- Gary Jennejohn ___ 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: [CFT+RFC] patch to buildworld with heimdal from ports
On Mon, 15 Nov 2010 22:54:40 -0600 Brandon Gooch jamesbrandongo...@gmail.com wrote: On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper gcoo...@freebsd.org wrote: Not according to another person that commented on the patch (and it sounds like the experience is positive, not negative). Who's the maintainer of the component? Garrett, where would one look for such an important detail? Source file somewhere? libgssapi doesn't have an official maintainer. Usually the committers who touch it the most are deemed responsible. Seems that dfr@ and uqs@ fit the bill. -- Gary Jennejohn ___ 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: [PATCH] Simplify uart_bus_pci_probe
On Sat, 6 Nov 2010 11:22:53 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Some of the logic could have been simplified in the probe. The proposed patch makes the detection process a tad bit more straightforward. Comments, review (and maybe a commit :P) are more than welcome :). Thanks! -Garrett This is definitely much less convoluted and easier to understand than the old code! I'd commit it, if I still had my src commit bit :) -- Gary Jennejohn ___ 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: csup or svn
On Mon, 27 Sep 2010 04:28:30 -0400 jhell jh...@dataix.net wrote: Just as much as top-posting I would say ;) On 09/27/2010 00:13, Aryeh Friedman wrote: Isn't that a step backwards? On Sun, Sep 26, 2010 at 11:55 PM, Greg Lewis gle...@eyesbeyond.com wrote: On Sun, Sep 26, 2010 at 11:34:34PM -0400, jhell wrote: On 09/26/2010 22:47, Aryeh Friedman wrote: I currently use: csup -h cvsup9.us.freebsd.org /usr/share/examples/cvsup/cvs-supfile and when I just ran it I got: Append to CVSROOT-src/access Edit CVSROOT-src/access,v Segmentation fault (core dumped) (8.1-STABLE #0) Should I be using SVN instead and if so what is the repo URL I need to use? You can safely remove that file and continue to do what you do... or Yes you can use SVN ports/devel/subversion-freebsd Or you can use cvsup (it doesn't segfault on that file). I just updated my CVS tree with csup - no problems. The suggestion to delete src/access,v and try again is probably the way to go. -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
On Wed, 01 Sep 2010 00:27:36 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. Too bad. I'd say that systems which are limited to C1 don't benefit much (or not at all) from your changes. I've solved it! :) Yup, this definitely reduces the number of inerrupts on my C1-only system :) Now I'm seeing on the order of 100 to 200 interrupts/s instead of around 2300. I'll run this new kernel some more and see how stable it is. Thanks, mav! -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
On Wed, 01 Sep 2010 13:44:26 +0300 Alexander Motin m...@freebsd.org wrote: Alexander Motin wrote: Gary Jennejohn wrote: On Mon, 30 Aug 2010 12:11:48 +0200 OK, this is purely anecdotal, but I'll report it anyway. I was running pretty much all day with the patched kernel and things seemed to be working quite well. Then, after about 7 hours, everything just stopped. I had gkrellm running and noticed that it updated only when I moved the mouse. This behavior leads me to suspect that the timer interrupts had stopped working and the mouse interrupts were causing processes to get scheduled. Unfortunately, I wasn't able to get a dump and had to hit reset to recover. As I wrote above, this is only anecdotal, but I've never seen anything like this before applying the patches. One-shot timers have one weak side: if for some reason timer interrupt getting lost -- there will be nobody to reload the timer. Such cases probably will require special attention. Same funny situation with mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX CPU goes to C3 state. I have reproduced the problem locally. It happens more often when ticks are not stopped on idle, like in your original case (or if explicitly enabled by kern.eventtimer.idletick sysctl). I've made some changes to HPET driver, which, I hope, should fix interrupt losses there. Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. OK, I'll give it a try, althought your previous patch seems to be working quite well. BTW I've also been using tm6292_idle.patch. Do I really need it? -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
On Wed, 1 Sep 2010 14:15:41 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Wed, 01 Sep 2010 13:44:26 +0300 Alexander Motin m...@freebsd.org wrote: Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. OK, I'll give it a try, althought your previous patch seems to be working quite well. This has changed the behavior of the HPET timers somewhat. With patch5 I was seeing approximately equal interrupt counts from hpet0 and hpet1. Now the majority of interrupts are on hpet0 by a factor of 6 to 10. Not a show stopper, just thought I'd mention it. One difference is that I didn't apply tm6292_idle.patch this time. -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
On Mon, 30 Aug 2010 12:11:48 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: Hmm. I applied your patches and am now running the new kernel. But I only installed the new kernel and didn't do make buildworld installworld. Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 interrupts per second and most of those are coming from the hpet timers: 1122 hpet0:t0 1124 hpet0:t1 It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock (stathz) events. HPET timer here works in one-shot mode handling it. So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. Too bad. I'd say that systems which are limited to C1 don't benefit much (or not at all) from your changes. OK, this is purely anecdotal, but I'll report it anyway. I was running pretty much all day with the patched kernel and things seemed to be working quite well. Then, after about 7 hours, everything just stopped. I had gkrellm running and noticed that it updated only when I moved the mouse. This behavior leads me to suspect that the timer interrupts had stopped working and the mouse interrupts were causing processes to get scheduled. Unfortunately, I wasn't able to get a dump and had to hit reset to recover. As I wrote above, this is only anecdotal, but I've never seen anything like this before applying the patches. -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
On Sun, 29 Aug 2010 16:10:00 +0300 Alexander Motin m...@freebsd.org wrote: I have actively tested this code for a few days on my amd64 Core2Duo laptop and i386 Core-i5 desktop system. With C2/C3 states enabled systems experience only about 100-150 interrupts per second, having HZ set to 1000. These events mostly caused by several event-greedy processes in our tree. I have traced and hacked several most aggressive ones in this patch: http://people.freebsd.org/~mav/tm6292_idle.patch . It allowed me to reduce down to as low as 50 interrupts per system, including IPIs! Here is the output of `systat -vm 1` from my test system: http://people.freebsd.org/~mav/systat_w_oneshot.txt . Obviously that with additional tuning the results can be improved even more. Hmm. I applied your patches and am now running the new kernel. But I only installed the new kernel and didn't do make buildworld installworld. Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 interrupts per second and most of those are coming from the hpet timers: 1122 hpet0:t0 1124 hpet0:t1 So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: Hmm. I applied your patches and am now running the new kernel. But I only installed the new kernel and didn't do make buildworld installworld. Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 interrupts per second and most of those are coming from the hpet timers: 1122 hpet0:t0 1124 hpet0:t1 It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock (stathz) events. HPET timer here works in one-shot mode handling it. So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. Too bad. I'd say that systems which are limited to C1 don't benefit much (or not at all) from your changes. -- Gary Jennejohn ___ 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: disassembler
On Fri, 27 Aug 2010 02:53:53 -0400
Aryeh Friedman aryeh.fried...@gmail.com wrote:
No the issue is a drive that has roughly 10 years of work on it died
and I was asked to see if it is readable/reviable... I already know
the format of the MBR but I need to also read the code to see if
something is wakey (I have written MBR's {with inline assemble in GCC)
for an OS I am working on but never disambled one)
On Fri, Aug 27, 2010 at 2:50 AM, Jim Bryant kc5vdj.free...@gmail.com wrote:
umm, dude
you writing a boot sector virus or something?
funny though
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/boot-boot0.html
given your skill and goals are questionable, you can find it in the source
tree yourself.
Aryeh Friedman wrote:
On Thu, Aug 26, 2010 at 11:36 PM, Aryeh Friedman
aryeh.fried...@gmail.com wrote:
On Thu, Aug 26, 2010 at 10:46 PM, Dirk Engling erdge...@erdgeist.org
wrote:
On 27.08.10 04:17, Aryeh Friedman wrote:
Is there a disassembler in the base system if not what is a good
option from ports?
Try objdump -d,
__erdgeist
flosoft# objdump -d /dev/da0
objdump: Warning: '/dev/da0' is not an ordinary file
There are quite a few diassemblers under ports but I doubt they're
designed to work on raw disks.
If you just want to save the data then why not plug the disk into
a different box and save them?
--
Gary Jennejohn
___
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: disk I/O, VFS hirunningspace
On Tue, 13 Jul 2010 15:34:12 -0700
Jerry Toung jryto...@gmail.com wrote:
Hello List,
I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2
separate
controllers.
My I/O throughput tests jumped by ~100MB/sec on both channels, when I
commented out the
following piece of code from kern/vfs_bio.c
void
waitrunningbufspace(void)
{
/*
mtx_lock(rbreqlock);
while (runningbufspace hirunningspace) {
++runningbufreq;
msleep(runningbufreq, rbreqlock, PVM, wdrain, 0);
}
mtx_unlock(rbreqlock);
*/
}
so far, I can't observe any side effects of not running it. Am I on a time
bomb?
Rather than commenting out the code try setting the sysctl
vfs.hirunningspace to various powers-of-two. Default seems to be
1MB. I just changed it on the command line as a test to 2MB.
You can do this in /etc/sysctl.conf.
--
Gary Jennejohn
___
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: 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. --- Gary Jennejohn ___ 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: 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 10:30:26 +0200 Alban Hertroys dal...@solfertje.student.utwente.nl wrote: On 24 Jun 2010, at 9:23, Gary Jennejohn wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Wouldn't it be easier to alias those commands instead of physically replacing them? In my .tcshrc I have: alias lp/usr/local/bin/lp alias lpq /usr/local/bin/lpq alias lpr /usr/local/bin/lpr alias lprm /usr/local/bin/lprm I only have /usr/local/bin/lpoptions on my system (7-STABLE), so I guess that's exclusive to CUPS, hence no need for me to alias it. That's a valid option, of course. My thought was that the base lp isn't being installed anyway so it's just as simple to use symbolic links. -- Gary Jennejohn ___ 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: Checksum mismatch -- will transfer entire file
On Mon, 21 Jun 2010 08:45:17 +0700 Victor Sudakov suda...@sibptus.tomsk.ru wrote: Christian Weisgerber wrote: csup already has a CVS mode, at least in 9-current. I don't use older versions of FreeBSD so I don't know whether it supports CVS there. It does at least down to 7.x. High time to fix this botheration, isn't it? This has been discussed in some mailing list (don't remember which) before. IIRC the problem is caused by the mechanism used to check commits from svn into CVS. I doubt it's easy to fix and IMO not worth the bother. -- Gary Jennejohn ___ 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: Checksum mismatch -- will transfer entire file
On Tue, 15 Jun 2010 09:28:37 +0700 Victor Sudakov sudakov+free...@sibptus.tomsk.ru wrote: Jonathan Noack wrote: But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. How do others deal with this noise? Do you grep cvsup output or what? Seems like newer versions of CVS break assumptions made by CVSup on the ordering of branch revisions: http://lists.freebsd.org/pipermail/freebsd-hubs/2009-August/002083.html So, in short I don't see any easy solutions to this, and especially given the fact that in the long run CVS/CVSup will probably be replaced by something else for distributing FreeBSD source, I don't think it will be that easy to find someone to fix either CVSup or CVS. Thanks for the link. Somebody wrote here that the problem was perhaps in the svn2cvs script, but Simon's post gives a different outlook. Maybe nobody is going to fix CVSup (is it not actively developed already?), but csup is relatively recent and alive. Once it has a CVS mode, maybe it could be adjusted? csup already has a CVS mode, at least in 9-current. I don't use older versions of FreeBSD so I don't know whether it supports CVS there. -- Gary Jennejohn ___ 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: Checksum mismatch -- will transfer entire file
On Mon, 14 Jun 2010 11:43:08 +0700 Victor Sudakov sudakov+free...@sibptus.tomsk.ru wrote: Victor Sudakov wrote: [dd] But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. How do others deal with this noise? Do you grep cvsup output or what? I just ignore these errors. I've never seen a problem as a result. -- Gary Jennejohn ___ 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: GSoC: registration of optional kernel features via sysctl: a question to the community
On Wed, 9 Jun 2010 10:12:54 -0700 Garrett Cooper yaneurab...@gmail.com wrote: On Jun 9, 2010, at 6:25 AM, Kostik Belousov wrote: On Wed, Jun 09, 2010 at 09:13:56AM -0400, jhell wrote: On 06/09/2010 04:14, Ilya Bakulin wrote: Hi hackers! While discussing my project's implementation details with my mentor, Alexander Leidinger, we've found that one of the ideas needs to be discussed with community, to find out possible use cases. That is, if it should be possible to spoof non-existing features. For example, if currently running kernel doesn't support FreeBSD 5.0 compat layer, kern.features.compat_freebsd5 will be absent when querying features list. The question is -- are there any cases when we want kern.features.compat_freebsd5 be present? If some feature is not in kernel, then presenting its existence to the userland is useless and may be even harmful, if, for example, some application relies on this feature. Or there are some scenarios where such cheat is useful? I can not think of any viable reason why one would want to spoof this when it is not available. Many ports are doing wrong thing there, checking for run-time features at the build-time, turning on/off some functionality depending on its presence on the build host. It's present in the ports Makefiles as well as in many autoconf scripts. It's bad because it causes problems with cross-build and other related scenarios, where you can't assume that the host system is going to match the target system. I don't find one single file in the ports tree which uses kern.features. But I just checked what's in the tree, not what may be in the ports themselves, i.e., I didn't extract/configure any ports. -- Gary Jennejohn ___ 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: How to Include Headers for siginterrupt() and vsnprintf()
On Wed, 19 May 2010 12:52:04 +0200 Gabor PALI p...@freebsd.org wrote: Hello there, I have some sources developed on non-FreeBSD systems (the sources of the run-time system for the Glasgow Haskell Compiler [1]) which try to #include signal.h to use siginterrupt() and stdio.h to use vsnprintf(). The problem is that they #define (or not) some constants which makes them hidden so the prototypes are not seen by the compiler. How to cope with this kind of sources? My naive solution is to do something like that (rts/posix/Signals.c): #if defined(HAVE_SIGNAL_H) # if defined(freebsd_HOST_OS) extern int siginterrupt(int,int); # endif # include signal.h #endif and that (rts/eventlog/EventLog.c): #ifdef freebsd_HOST_OS int vsnprintf(char * __restrict, size_t, const char * __restrict,__va_list) __printflike(3, 0); #endif Thank you for the hints in advance. Try moving stdlib.h and string.h up near the top. stdlib.h includes sys/cdefs.h which defines (most) of these macros, like __XSI_VISIBLE. -- Gary Jennejohn ___ 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: utimes(2): changing the birth time
On Wed, 12 May 2010 17:53:38 + Knowledge Seeker knosee...@googlemail.com wrote: Hi, Is there a way to set birth time to a value greater(newer) than the actual birth time (not in the future, but not the current time)? The man page utimes(2) says that is only possible to change to an older value. I saw a way to do this by opening a new file, coping the data, setting the other attributes, then calling utimes 2 times to set the birth and the modification time. Is there a way to change it without creating a new file? Not with the current code. vfs_syscalls.c:setutimes() explicitly checks that the new time is less than va_birthtime. Interestingly enough, there's code in the routine to handle what this comment in utimes(2) mentions, but it's not implemented yet. Ideally a new system call will be added that allows the setting of all three times at once. -- Gary Jennejohn ___ 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: ioctl, copy string from user
On Thu, 29 Apr 2010 23:23:28 +0200 (CEST)
Lukas Czerner czerner.lu...@gmail.com wrote:
On Thu, 29 Apr 2010, Ryan Stone wrote:
Date: Thu, 29 Apr 2010 17:19:41 -0400
From: Ryan Stone ryst...@gmail.com
To: Lukas Czerner czerner.lu...@gmail.com
Cc: freebsd-hackers@freebsd.org
Subject: Re: ioctl, copy string from user
Apparently I need to tell ioctl how big is the variable I am
providing to it ([MAXLEN]). The odd thing is, when I have a structure
like this:
struct lrfs_attach_info {
char *name;
int priority;
};
and I pass the pointer to that structure to the ioctl, it just
works. I can even use the 'name' string from the structure without
any problems, apparently it translates the pointer properly, but I
did not expect this...
I think that you'll find that what actually happens is that you're
reading from the userspace pointer. That will work as long as the
pointer is mapped, but you'll panic if what it points to gets swapped
out or is invalid.
Hmmm, I can prevent the pointer to be invalidated, but I doubt I can
prevent to the pointer to been swapped out. Is there some better way
? Allocate it statically (char name[MAXLEN]), then it gets copied
as whole to the kernel space, isn't it ?
Look at the definition of _IOW() in /sys/sys/ioccom.h. It should become
obvious what's going on.
--
Gary Jennejohn
___
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: What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
On Fri, 23 Apr 2010 16:27:12 -0700 Ted Mittelstaedt t...@mittelstaedt.us wrote: Setting aside the question of why do we break software that a lot of people use (these chips are in use on a lot of laptops) is there a document somewhere that explains what changes need to be made in code for this new tty setup? Or, is there a set of magic include files or a conversion shim library that will allow these kinds of programs to build without much work? Or is porting these drivers just so non-trivial that the only way is to just delve into the system manuals and delve into the driver code and try to figure out what is going on in each? If that's the case that's probably beyond my ability but I'd be happy to serve as a testbed. The guy to ask about this would be Ed Schouten (ed@). AFAICR he did the new TTY stuff. I don't know whether he reads these lists. AFAIK there is no easy way to fix this and there are no backwards compati- bilty shims or magic header files. The fundamental problem with ltmdm is that it's a KLD and has to grovel around in the guts of the kernel. That makes fixing it decidely non- trivial. -- Gary Jennejohn ___ 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: there is a way to avoid strict libraries linking?
On Thu, 22 Apr 2010 15:38:14 -0700 Steve Franks bahamasfra...@gmail.com wrote: It's much safer to just leave the libraries alone. __Just because you upgraded libpng doesn't mean that your old gtk binary will stop working (assuming you are using portupgrade or portmaster -w which preserves old About to get flamed, I know Untrue. Portupgrade deletes the old version of the port by default. The PNG upgrade was a major PITA, because I installed one new port that thought it had to have it. I'm sure 98% of the ports I then had to upgrade would have still worked just fine even if rebuilt against the old libpng. I think the complaint here is that the port dependencies system frequently gives the impression/enforces the rule that new ports will depend on whatever the most current version of everything is in the ports tree at the time they were built, forcing sort of a perpetual upgrade cycle. IMHO this is probably due to naive port maintainers (such as myself) incorrectly pointing a port at libpng.5 instead of any libpng, or libpng = 5. Once the ports tree is 'poisoned' in this fashion, there's really no going back. I'd sure vote for an audit of this behavior as a summer of code project. Long story short, anything that sounds fundamental gets bumped (png, jpeg, tcl, python, gtk, etc, etc), I just sit back and get ready to spend two or three days retrying portupgrade -akOf -mBATCH=yes until everything sticks. If you've got OO or KDE4 installed, you might just want to forget it and pkg_delete -f *, then start over. Setting FORCE_PKG_REGISTER in /etc/make.conf should mitigate such problems. I actually have both png-1.2.43 and png-1.4.1_1 installed and the old /usr/local/lib/libpng.so.5 is still there along with the new /usr/local/lib/libpng.so.6. -- Gary Jennejohn ___ 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: /sys/amd64/conf/GENERIC COMPAT_FREEBSD7 a prerequisite for COMPAT_IA32
On Wed, 21 Apr 2010 20:57:59 +0200 Julian H. Stacey j...@berklix.com wrote: Hi hack...@freebsd.org with amd64, but not with i386, /sys/amd64/conf/GENERIC COMPAT_FREEBSD7 is an undocemneted pre-requisite for COMPAT_IA32 (so those who enable COMPAT_IA32 for ports/emulators, but disable COMPAT_FREEBSD7 as they compile all binaries on upgrade, will trip up on it as I did). Currently I see: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror ../../../compat/freebsd32/freebsd32_misc.c cc1: warnings being treated as errors ../../../compat/freebsd32/freebsd32_misc.c: In function 'freebsd32_semsys': ../../../compat/freebsd32/freebsd32_misc.c:1420: warning: implicit declaration of function 'freebsd7_freebsd32_semctl' ../../../compat/freebsd32/freebsd32_misc.c:1420: warning: nested extern declaration of 'freebsd7_freebsd32_semctl' ... ../../../compat/freebsd32/freebsd32_misc.c:1845: error: dereferencing pointer to incomplete type *** Error code 1 It could be documented in GENERIC, but better to fix it. I could dig through sources, but I think there's people closer to config who would prefer to commit their own fix, rather than me write a patch ? (Does that translate as I'm lazy ? ;-) The switch is documented in /usr/src/UPDATING on my box. This is the usual place for this kind of heads-up. -- Gary Jennejohn ___ 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: /sys/amd64/conf/GENERIC COMPAT_FREEBSD7 a prerequisite for COMPAT_IA32
On Thu, 22 Apr 2010 11:54:29 +0200 Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Gary Jennejohn gary.jennej...@freenet.de Reply-to: gary.jennej...@freenet.de Date: Thu, 22 Apr 2010 11:14:40 +0200 Message-id: 20100422111440.69a01...@ernst.jennejohn.org Gary Jennejohn wrote: On Wed, 21 Apr 2010 20:57:59 +0200 Julian H. Stacey j...@berklix.com wrote: Hi hack...@freebsd.org with amd64, but not with i386, /sys/amd64/conf/GENERIC COMPAT_FREEBSD7 is an undocemneted pre-requisite for COMPAT_IA32 (so those who enable COMPAT_IA32 for ports/emulators, but disable COMPAT_FREEBSD7 as they compile all binaries on upgrade, will trip up on it as I did). Currently I see: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror ../../../compat/freebsd32/freebsd32_misc.c cc1: warnings being treated as errors ../../../compat/freebsd32/freebsd32_misc.c: In function 'freebsd32_semsys': ../../../compat/freebsd32/freebsd32_misc.c:1420: warning: implicit declaration of function 'freebsd7_freebsd32_semctl' ../../../compat/freebsd32/freebsd32_misc.c:1420: warning: nested extern declaration of 'freebsd7_freebsd32_semctl' ... ../../../compat/freebsd32/freebsd32_misc.c:1845: error: dereferencing pointer to incomplete type *** Error code 1 It could be documented in GENERIC, but better to fix it. I could dig through sources, but I think there's people closer to config who would prefer to commit their own fix, rather than me write a patch ? (Does that translate as I'm lazy ? ;-) The switch is documented in /usr/src/UPDATING on my box. This is the usual place for this kind of heads-up. Thanks Gary, It seems COMPAT_FREEBSD7 has more scope than [456] ( /usr/src/UPDATING I should read more often. ) But /usr/src/UPDATING is a transition log, as new things occur, the entry re COMPAT_FREEBSD7 will get buried deeper. Requirement from COMPAT_IA32 for COMPAT_FREEBSD7 applies with amd64 but not i386, so I'd suggest that could be documented in /sys/amd64/conf/GENERIC , eg From options COMPAT_FREEBSD7 # Compatible with FreeBSD7 To options COMPAT_FREEBSD7 # Compatible with FreeBSD7, req. by COMPAT_IA32 You're right. It's also in /sys/amd64/conf/NOTES, which is actually the place where valid flags are supposed to be documented. GENERIC actually has a different role. Note that I'm running -current, but it should also be there on other releases. -- Gary Jennejohn ___ 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: there is a way to avoid strict libraries linking?
On Wed, 14 Apr 2010 12:23:16 -0400 Leinier Cruz Salfran salfrancl.lis...@gmail.com wrote: hello all fbsd devs i want to know if there is a possibility to avoid current strict libraries linking .. i will explain myself for example .. i have installed 'gtk' (2.18) that depends on library 'libpng.so.5' (png) .. and i will upgrade 'png' port to a superior version that install the library 'libpng.so.6' BUUU 'gtk' will not be upgraded, so it will still depending on 'libpng.so.5' .. so here is my question: there is a way to avoid this?? i means that 'gtk' load 'libpng.so' (that is a symbolic link to 'libpng.so.6') instead of 'libpng.so.5' at runtime i think this is a VERY VERY strict rule because in linux programs load 'lib*.so' instead 'lib*.so.#' except if that program was linked to 'lib*.so.#' at compilation time You might be able to do this with /etc/libmap.conf. See the man page for libmap.conf(5). -- Gary Jennejohn ___ 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: random FreeBSD panics
On Sat, 3 Apr 2010 12:51:46 + Masoom Shaikh masoom.sha...@gmail.com wrote: On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras ivo...@freebsd.org wrote: On 28 March 2010 16:42, Masoom Shaikh masoom.sha...@gmail.com wrote: lets assume if this is h/w problem, then how can other OSes overcome this ? is there a way to make FreeBSD ignore this as well, let it result in reasonable performance penalty. Very probably, if only we could detect where the problem is. Try adding options __ __ PRINTF_BUFR_SIZE=128 to the kernel configuration file if you can, to see if you can get a less mangled log outout. ok, after few days of silence I am back with more questions this time system feels little better, it is able to sustain for more time that what 7.3-RELEASE could FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64 I am using KDE4, and when OS freezes, well it freezes, means I cannot change to tty0 and see the panic text, if any it might possibly have spit. the stuck frozen GUI keeps staring there. So the question is how to I capture that panic text ? unfortunately I am not getting core files too, so there is nothing I can pick up hints is there some option (KDB, DDB), so that on panic system drop to debugger ? [trimmed Cc - no need to send this to 3 MLs] There's no code in the kernel to switch back out of graphics mode (i.e. what X uses) when a panic happens. You probably can switch to v0, but you won't be able to see it. The only sure-fire way is to hook up a screen (terminal, laptop or another computer) to a serial port. -- Gary Jennejohn ___ 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: Newbie question: kernel image a dynamically linked binary?
On Thu, 1 Apr 2010 15:53:50 +0530 Daniel Rodrick daniel.rodr...@gmail.com wrote: Hello List, I'm a newbie and coming from Linux background, and am trying to learn FreeBSD now. The first thing I find a little confusing is that the final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary: $ $ pwd /boot/kernel $ $ file kernel kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped $ How can the kernel image use shared libraries? And which ones does it use, if any? Also, I cannot find out the libraries the image uses using the traditional ldd command: $ ldd kernel kernel: kernel: signal 6 $ Can some please throw some light? file is confused. FreeBSD uses a monolithic kernel and no shared libraries are involved. However, it is possible to dynamically load modules using kldload. See the appropriate man page. -- Gary Jennejohn ___ 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: Problems understanding this piece of code...
On Mon, 29 Mar 2010 00:06:49 -0400 Sergio Andr__s G__mez del Real sergio.g.delr...@gmail.com wrote: Hi. I can't seem to understand this piece of i386 boot code: What I understand is that BIOS loads MBR at 0x7c00, then jumps to the code there, code that relocates itself to and jumps to 0x600, but what does movw $main-EXEC+LOAD,%si mean? if it's the source address to copy from, why is it $main (0x7c00) - EXEC (0x600) + LOAD (0x7c00) above main? then, movw $main,%di is the address to copy to... wasn't 0x600 the address to copy to? then jump to jmp main-LOAD+EXEC (0x600)? I guess I am really missing something here, but I can't get to understand what's happening. start:cld # String ops inc xorw %ax,%ax# Zero movw %ax,%es# Address movw %ax,%ds# data movw %ax,%ss# Set up movw $LOAD,%sp # stack # # Relocate ourself to a lower address so that we are out of the way when # we load in the bootstrap from the partition to boot. # movw $main-EXEC+LOAD,%si# Source movw $main,%di # Destination movw $0x200-(main-start),%cx# Byte count rep # Relocate movsb # code # # Jump to the relocated code. # jmp main-LOAD+EXEC # To relocated code The boot loader was linked to run at EXEC, so main is actually EXEC plus the offset to main from EXEC. So main-EXEC+LOAD results in calculating the offset to main at the place where the BIOS loaded it == LOAD+offset_to_main. This must be used as the source address for the movsb. -- Gary Jennejohn ___ 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: random FreeBSD panics
On Sun, 28 Mar 2010 11:18:59 + Masoom Shaikh masoom.sha...@gmail.com wrote: On Sun, Mar 28, 2010 at 10:32 AM, Ivan Voras ivo...@freebsd.org wrote: Masoom Shaikh wrote: Hello List, I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since then, system randomly just freezes, and there is no option other than hard boot. I guessed this will get solved in 8.0-RELEASE, but it was not :( I wild shot - did you try disabling superpages? ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org umm, how do I do that ? Add this to /boot/loader.conf vm.pmap.pg_ps_enabled=0 -- Gary Jennejohn ___ 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: ntfsprogs
On Thu, 18 Mar 2010 10:54:14 +0100 Samuel Mart__n Moro faus...@gmail.com wrote: I made two patches for ntfsprogs. (and btw, I don't know: who's the port mainter? who should I give these patches?) There isn't a maintainer. The best thing is to file a PR with your patches attached so they won't get lost in the noise. --- Gary Jennejohn ___ 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: How to slow down SATA to 1.5 GBit/s ?
On Sat, 13 Mar 2010 14:37:34 +0100 Thomas Schmitt scdbac...@gmx.net wrote: So even if i get ahci running i would still need a solution for ata. (If there is none, then i will have to put the drive into the computer and use SATA without e. No easy switch to USB then.) I'm using ahci with two ATA/IDE DVD drives and they work as long as I have device ata in my kernel config. That's all I need. They appear as /dev/cd0 and /dev/cd1. --- Gary Jennejohn ___ 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: tty or script(1) weirdness?
On Wed, 10 Mar 2010 21:04:10 +0100 Ed Schouten e...@80386.nl wrote: * Ed Schouten e...@80386.nl wrote: Hmmm... It seems this is a TTY bug. When you close a TTY, the final close() call should get stuck until all data is actually drained. This doesn't seem to happen properly. Some further research: it's not a TTY bug, but a bug in script(1). The script parent process leaves a file descriptor open, which means output is never properly drained. I can't reproduce this issue after applying this patch: %%% Index: script.c === --- script.c (revision 204965) +++ script.c (working copy) @@ -158,6 +158,8 @@ } if (child == 0) doshell(argv); + else + close(slave); if (flushtime 0) tvp = tv; %%% Looks very convincing. I say commit it. --- Gary Jennejohn ___ 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: bus_space_tag, bus_space_handle
On Thu, 11 Mar 2010 11:04:52 +0200 Cole c...@opteqint.net wrote: Hi. Im currently needing to write to a few registers for a PCI device. The driver is provided, but it does not contain support for writing specific registers itself. I also do not with to modify the driver. I would like to know what the best method would be for writing to these registers, the best way to go about getting bus_space_tag, and handle for the connected pci device. Im currently using FreeBSD 7.x. Take a look at pciconf(8). Might help. --- Gary Jennejohn ___ 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: Automated kernel crash reporting system
On Thu, 4 Mar 2010 08:06:50 -0500 jhell jh...@dataix.net wrote: On Thu, 4 Mar 2010 07:09, dan.naumov@ wrote: Hello I noticed the following on the FreeBSD website: http://www.freebsd.org/projects/ideas/ideas.html#p-autoreport Has there been any progress/work done on the automated kernel crash reporting system? The current ways of enabling and gathering the information required by developers for investigating panics and similar issues are unintuitive and user-hostile to say the least and anything to automate the process would be a very welcome addition. - Sincerely, Dan Naumov Hi Dan, I am assuming that the output of crashinfo_enable=YES is not what you are talking about is it ? are you aware of it ? The info contained in the crashinfo.txt.N is pretty informative for developers, maybe your talking about another way of submitting it ? This feature is mentioned as a mechanism which could be used as part of the automatic reporting functionality. So it's not quite the same thing. --- Gary Jennejohn ___ 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: namei() returns EISDIR for / (Re: svn commit: r203990 - head/lib/libc/sys)
On Sun, 28 Feb 2010 18:26:05 -0800
Garrett Cooper yanef...@gmail.com wrote:
On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best alexbes...@wwu.de wrote:
i have a small test app to check {rm|mk}dir()'s errnos with certain args
like
/, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
also add testcases for syscalls like rename(), unlink(), etc.
most of the errno codes returned after applying your patch look correct. i
wonder however why rmdir(/proc) returns EACCESS as unprivileged user.
wouldn't it make more sense to also return EBUSY? why complain about
permission related matters when even root won't be able to perform the
operation.
Hmm.. good question. POSIX doesn't fully expound on this case
(http://www.opengroup.org/onlinepubs/009695399/functions/rmdir.html),
and either seem possible...
This maybe from rmdir(2)?
[EACCES] Write permission is denied on the directory containing
the link to be removed.
ls -ldo /
drwxr-xr-x 44 root wheel - 1536 Feb 28 18:36 /
ls -ldo /proc
dr-xr-xr-x 2 root wheel - 512 Sep 7 2008 /proc
---
Gary Jennejohn
___
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: `make cleanworld` and /usr/obj/lib32/usr/src
On Sat, 27 Feb 2010 14:49:58 +0100 (CET) Alexander Best alexbes...@wwu.de wrote: how about something like this? Based on a quick look it seems OK to me. Have you tested it? --- Gary Jennejohn ___ 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: VirtualBox and vtophys
On Wed, 24 Feb 2010 13:41:31 +0200 Jacques Fourie jacques.fou...@gmail.com wrote: I've noticed that my virtualbox vboxdrv.ko started crashing after updating my 8.0-stable install. The crash occurs when vboxdrv calls vtophys() on a userland virtual address. Prior to r202894 this was working fine. Modifying pmap_kextract() to use vtopte() for non-kernel virtual adresses fixes the problem. Is it intended for vtophys() to still work on userland virtual addresses? This was recently (yesterday and today) discussed on freebsd-emulation with subject Virtualbox. See there for suggested actions. --- Gary Jennejohn ___ 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: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, 22 Feb 2010 00:20:14 +0100 (CET) Alexander Best alexbes...@wwu.de wrote: hi there, anybody fancy the idea of including /usr/obj/lib32/usr/src in the cleanworld target on amd64? Seems like a reasonable thing to do. --- Gary Jennejohn ___ 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: Spin down HDD after disk sync or before power off
On Tue, 26 Jan 2010 20:17:23 +0100 (CET) Alexander Best alexbes...@wwu.de wrote: hi there, because of kern/140752 i looked through a discussion back in 2009 (http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027879.html) concerning freebsd's hdd spin down procedure. right now ATA_FLUSHCACHE is being used although the hitachi hdd specs referenced in the pr say that this will not cause proper load/unload and thus an emergency unload will occur which reduces the life expectancy of hdds dramatically (20.000 shutdowns vs. 600.000 shutdowns). unfortunately the discussion back then didn't come up with any sort of decision/patch. attached you'll find a very simple patch which issues ATA_STANDBY_IMMEDIATE instead of ATA_FLUSHCACHE during hdd spin down. could somebody with hdd knowledge comment on this? this matter seems quite important since there may be a chance that the current spin down mechanism in freebsd damages hdds! What if the disk doesn't support ATA_STANDBY_IMMEDIATE? Your patch then negates the benefit of calling ad_shutdown(), namely flushing the cache, if possible. I suggest putting your new code at the top and leaving the old code in an else-if clause. --- Gary Jennejohn ___ 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: Leaks in libc?
On Wed, 27 Jan 2010 08:18:43 -0600
Brandon Falk falk...@gamozo.org wrote:
The simple program:
#include stdlib.h
#include stdio.h
int main()
{
puts(Apple cider);
return 0;
}
Yields the following result in valgrind:
==4703== Memcheck, a memory error detector
==4703== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4703== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4703== Command: ./a.out
==4703==
Apple cider
==4703==
==4703== HEAP SUMMARY:
==4703== in use at exit: 4,096 bytes in 1 blocks
==4703== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==4703==
==4703== LEAK SUMMARY:
==4703==definitely lost: 0 bytes in 0 blocks
==4703==indirectly lost: 0 bytes in 0 blocks
==4703== possibly lost: 0 bytes in 0 blocks
==4703==still reachable: 0 bytes in 0 blocks
==4703== suppressed: 4,096 bytes in 1 blocks
==4703==
==4703== For counts of detected and suppressed errors, rerun with: -v
==4703== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Any ideas why the standard libraries are leaking like this? Is it
perhaps a bug with valgrind, or maybe FreeBSD automatically cleans up so
they took the cleanup out of their libc?
FreeBSD 8.0 x86_64
From the valgrind FAQ
suppressed means that a leak error has been suppressed. There are some
suppressions in the default suppression files. You can ignore suppressed
errors.
AFAIK all variants of U*X recover memory used by applications when the
applications exit. This is not a real leak.
---
Gary Jennejohn
___
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: [PATCH] linprocfs dofilesystems
On Fri, 8 Jan 2010 18:19:29 +0100 Fernando Apestegu__a fernando.apesteg...@gmail.com wrote: Hi all, This patch implements the filesystems file in the linux proc fs. I have used it for some time without seeing any problems. Let me know in case this is useful. Tested against 8.0-RELEASE-p1 Thanks You should file a PR with this, if you haven't done so already. Patches which are only sent to mailing lists tend to get lost. --- Gary Jennejohn ___ 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: Suggestion: rename killall to fkill, but wait five years to phase the new name in
On Mon, 21 Dec 2009 23:18:43 -0800 Xin LI delp...@gmail.com wrote: On Mon, Dec 21, 2009 at 10:31 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Craig, and hackers, are you both willing to do this? No. killall is not part of standard, and, just because System V choose to implement that way, does not warrant that FreeBSD has to. Moreover, user can always alias /sbin/killall to 'fkill' and 'kill -15 -1' to 'killall' if they really want the System V behavior. I'm wondering why we even need killall when pkill seems to have the same basic functionality and is located in /bin (and /rescue) rather than /usr/bin? --- Gary Jennejohn ___ 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: old/unupdated xterm entries in termcap db
On Thu, 10 Dec 2009 13:42:22 +0100 Ed Schouten e...@80386.nl wrote: But if someone is interested in updating the entries in the termcap file to something newer (but no 256 colors), please do! Patches welcome! I will even MFC it! Our current entry for xterm isn't entirely compatible with Apple's Terminal.app either. I've noticed that an Erase Line (EL, ^[[K) with xterm uses the terminal's selected attributes to blank the terminal, while Apple's implementation uses the default terminal attributes (i.e. black background). IIRC there was a patch in the original post which may be a good starting point. --- Gary Jennejohn ___ 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: [Patch] Updated termcap entries for xterm
On Thu, 10 Dec 2009 14:25:54 +0100 Ed Schouten e...@80386.nl wrote: * Ed Schouten e...@80386.nl wrote: I just tried the patch, but when I run `make' in share/termcap, I get the following: | gzip -cn termcap.5 termcap.5.gz | TERM=dumb TERMCAP=dumb: ex - /store/home/ed/projects/freebsd-head/share/termcap/termcap.src /store/home/ed/projects/freebsd-head/share/termcap/reorder | script, 36: Pattern not found | script, 36: Ex command failed: pending commands discarded | *** Error code 1 | | Stop in /store/home/ed/projects/freebsd-head/share/termcap. The attached patch should bring the entries up-to-date. Unfortunately it still seems the issue with Apple's Terminal.app is present, but that's just Apple's fault. Because of that, I don't see a reason (yet) to MFC this. Any testers, before I commit this patch to HEAD? I tried it with a real xterm and mrxvt and see no regressions. However, I didn't try it with a VT as xterm. --- Gary Jennejohn ___ 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: old/unupdated xterm entries in termcap db
On Wed, 09 Dec 2009 01:12:04 +0200 Leonidas Tsampros ltsamp...@upnet.gr wrote: Why aren't these entries updated in order to match the ones that ship with xterm? Am I missing something? Probably because xterm is under ports and termcap under src and it would not be easy to track changes in ports under src. The only practical way to keep termcap up to date would be for the committer updating the port to also check and update termcap under src. The problem with this is that most ports committers aren't authorized to make commits under src. --- Gary Jennejohn ___ 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: acl_from_text leaking memory
On Sun, 15 Nov 2009 11:47:28 -0500 Jim Wilcoxson pri...@gmail.com wrote: I've been working on a new backup program, HashBackup, and believe I have found a memory leak with ACLs in PCBSD/FreeBSD 7.1 and OSX (Leopard). acl_from_text is a function that takes a text string as input, and returns a pointer to a malloc'd acl. This acl is then freed with acl_free. I noticed that acl_from_text appears to leak memory. This is not used during the backup of a filesystem, but is needed to do a restore. After looking at the acl_from_text source in /usr/src/lib/libc/posix1e (from PCBSD7.1), I believe the problem is that the duplicate text string, mybuf_p, is not freed on normal return of this function. Here is the end of this function: [snip code] Looks to me like you're right. Have you tried applying the suggested change and testing it for regressions? Reporting that it works without side effects would definitely be convincing and increase the chances of getting it committed. --- Gary Jennejohn ___ 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: acl_from_text leaking memory
On Mon, 16 Nov 2009 21:12:47 +0100 vol...@vwsoft.com wrote: you may want to have a look at the manpage acl_from_text(3): ...This function may cause memory to be allocated. The caller should free any releasable memory, when the new ACL is no longer required, by calling acl_free(3) with the (void *)acl_t as an argument. Please use an acl_free(void *obj_p) call afterwards to avoid leaking memory. The suggested fix was appplied to HEAD today. Apparently, the man page should now be updated. --- Gary Jennejohn ___ 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: NUMA support; tweaking TCP for GPRS
On Thu, 12 Nov 2009 18:08:35 -0800 Sean Hamilton s...@bel.bc.ca wrote: Second, I am using a FreeBSD server to talk to equipment which has a GPRS internet connection. This is fairly high latency (approximately one second RTT) and is prone to bursts of packet loss, or bursts of extremely high latency -- perhaps up to a minute. These intervals cause many retransmissions, which I presume is a good strategy over the internet, but not so good for GPRS. For my application, latency is mostly irrelevant. However, data over GPRS is very expensive, so I would like to reduce as much as possible the number of TCP retransmissions made on the FreeBSD side, possibly at the expense of latency. So, I am looking for suggestions on how to achieve this, via sysctl, setsockopt, etc. There seems to be a lot of literature regarding TCP tuning, but usually the focus is on improving performance, not reducing network traffic. The rexmit_min and rexmit_sop sysctls mentioned in tcp(4) seem interesting, but it's not clear to me exactly how they might be adjusted for this purpose. Thanks in advance, Highjacking this thread. This won't help you, but it would be interesting to have the new Delay Tolerant Networking protocol developed by Vint Cerf for NASA in FreeBSD. Supposedly it's already in Android. --- Gary Jennejohn ___ 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: Why is default value of NKPT so small? mfsroot
On Fri, 6 Nov 2009 11:19:51 -0800 (PST) Trever anti_spam...@yahoo.com wrote: Does anyone know what the thinking is behind the default value of NKTP in /usr/src/sys/i386/include/pmap.h? Seems to be based on the maximum amount of usable memory. If you define PAE then it's set to 240. For AMD64 it's set to 32. Which leads me to two more questions: - is it possible to change the NKTP value without recompiling the kernel? I think there isn't but I'll ask. No. - is it possible to change the NKTP value without editing pmap.h (can I pass a variable into the kernel build process)? Well, the header files all semm to have #ifndef NKPT in them. Try doing NKPT=xxx;export NKPT before compiling the kernel and see what happens. --- Gary Jennejohn ___ 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: rmdir(2) and mkdir(2) both return EISDIR for argument /
On Fri, 06 Nov 2009 22:09:49 +0100 (CET) Alexander Best alexbes...@math.uni-muenster.de wrote: here's a completely new patch. all the changes are in kern/vfs_syscall.c. so kern/vfs_lookup.c now stays just the way it is (please revert any changes from the previous patches i posted). after applying the patch this is the output from a slightly modified version of the test app i attached in my very first post: rmdir errno: 16 (EBUSY) - EBUSY is required by POSIX mkdir errno: 17 (EEXIST) rename errno: 22 (EINVAL) these are the results when called with / as arg. the output doesn't differ if run with or without superuser privileges. when run with . as arg this is the output as regular user: rmdir errno: 22 (EINVAL) mkdir errno: 17 (EEXIST) rename errno: 13 (EACCES) and as superuser: rmdir errno: 22 (EINVAL) mkdir errno: 17 (EEXIST) rename errno: 22 (EINVAL) does this look reasonable? would be nice if mkdir and rmdir would also check privileges at first like rename, but that's a different story i guess. ;) The only problem I see with this is that vfs_syscall.c now has knowledge about the internal details of vfs_lookup.c Maybe just mention in the comments that this is the case and could be a problem if vfs_lookup.c is changed for some reason? That's what I do when I have to use something like this. But we don't want to turn this into a gigantic bikeshed - we already have enough of those. --- Gary Jennejohn ___ 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: [patch] add pwait utility
On Fri, 6 Nov 2009 23:24:46 +0100 Jilles Tjoelker jil...@stack.nl wrote: I propose adding a small new utility to /usr/bin: pwait. Similar to the Solaris utility of the same name, it waits for any process to terminate. Why not /bin so it can be used before /usr is mounted? --- Gary Jennejohn ___ 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: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
On Fri, 23 Oct 2009 12:58:43 +0400 pluknet pluk...@gmail.com wrote: 2009/10/23 Antony Mawer li...@mawer.org: On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best alexbes...@math.uni-muenster.de wrote: hi everyone, together with hugh mahon (the author of ee) i've been trying to fix a nasty bug in ee. for some reason ee exits (not crashes) and leaves the console corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all running ee instances). I noticed this the other day when working on a new 8.0-RC1 system... in my case I was using putty (Windows ssh client) to access the system and maximised the window I had ee running in, and noticed ee just dumped me straight to the prompt. I am wondering if this has anything to do with the new tty subsystem in 8.0, as this wasn't a problem I've experienced before under 7.x... No, that's a regression appeared in (FreeBSD'ish? version of) ee 1.5.0. SIGWINCH is handled in new_curse.c, but it's not being compiled/linked. --- Gary Jennejohn ___ 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: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
On Fri, 23 Oct 2009 13:50:24 +0200 Gary Jennejohn gary.jennej...@freenet.de wrote: On Fri, 23 Oct 2009 12:58:43 +0400 pluknet pluk...@gmail.com wrote: 2009/10/23 Antony Mawer li...@mawer.org: On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best alexbes...@math.uni-muenster.de wrote: hi everyone, together with hugh mahon (the author of ee) i've been trying to fix a nasty bug in ee. for some reason ee exits (not crashes) and leaves the console corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all running ee instances). I noticed this the other day when working on a new 8.0-RC1 system... in my case I was using putty (Windows ssh client) to access the system and maximised the window I had ee running in, and noticed ee just dumped me straight to the prompt. I am wondering if this has anything to do with the new tty subsystem in 8.0, as this wasn't a problem I've experienced before under 7.x... No, that's a regression appeared in (FreeBSD'ish? version of) ee 1.5.0. SIGWINCH is handled in new_curse.c, but it's not being compiled/linked. Never mind - I see that new_curse.c is supposed to be a substitute for ncurses if it's not available on the system. Sorry for the noise. --- Gary Jennejohn ___ 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: Running a program through gdb without interfering
On Fri, 9 Oct 2009 01:16:59 +0200 Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net wrote: On Friday 09 October 2009 00:38:32 Paul B Mahol wrote: On 10/9/09, Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net wrote: Hi, is there a way to have a program run through gdb and gdb only record a segfault, but otherwise let the program run? Why I'd like this is the following: I've got a i386 jail on an amd64 box, running 7.2-p4. UNAME_p and UNAME_m have been set to i386 as well as ARCH in /etc/make.conf. Running portmaster[1] to build ports under my uid and PM_SU_CMD, sudo *sometimes* segfaults. It's only sudo, so at present I don't have a reason to doubt memory. However, it doesn't dump core, so I'm at a loss what the culprit could be. Tried 'sysctl kern.sugid_coredump=1' ? Hmm, no. Enabled now and waiting for the next segfault. I actually looked at the sysctl -d, but it didn't register that this could be the main cause. Perhaps that sentence could be more clear: -kern.sugid_coredump: Enable coredumping set user/group ID processes +kenr.sugid_coredump: Allow setuid/setgid processes to dump core See the info file for gdb, section 5.3 Signals. It's possible to tell gdb how to handle signals, e.g. stop vs. nostop, etc. --- Gary Jennejohn ___ 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: DDB capture buffer
On Sat, 12 Sep 2009 15:53:59 +0200 Dag-Erling Sm__rgrav d...@des.no wrote: The default maximum size of the DDB capture buffer is 48 kB. This is ridiculously low; it's not even nearly enough to capture the output from the first example in textdump(4): script kdb.enter.panic=textdump set; capture on; show allpcpu; bt; ps; alltrace; show alllocks; call doadump; reset Would anyone object to increasing it to 1 MB? DDB is opt-in, so it will only affect people who compile it into their kernel (or -CURRENT users who don't compile it out; they have it coming). I'd say it's a good idea, as long as you put a warning in UPDATING for people using e.g. embedded devices with little memory. It's reasonable to expect such users to customize their kernel configs. --- Gary Jennejohn ___ 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: ral0 interface hangs with the message No buffer space available
On Mon, 24 Aug 2009 01:54:39 -0700 Yuri y...@rawbw.com wrote: Almost every time when I leave system to download a large file I get ral device inoperable after a while. Pinging the other peer causes these messages: ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available I don't believe that TCP buffer is legitimately filled up to the max because after I bring it down and back up it works fine for a long while. So why didn't this data go through before down/up? If TCP connections are slow buffers shouldn't just fill up: system can and should be preventing this letting apps to hold data streams. Something isn't quite right. Why would network device hang in a steady download scenaio? 7.2-STABLE The buffers aren't full, it's the send queue used by whichever driver it is which you are using. The down/up frees it up because all queued transmits are discarded. This should never happen in normal operation. You haven't really provided any useful information to allow further analysis. --- Gary Jennejohn ___ 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: concurrent sysctl implementation
On Sat, 25 Jul 2009 00:29:16 +0300 Kostik Belousov kostik...@gmail.com wrote: Below is the prototype that seems to work for me both with patched and old rtld on i386. Patch also contains bits for amd64 that I did not tested yet. All other arches are not buildable for now. [patch deleted] I'm currently running the patch under AMD64 and haven't noticed any regressiosn yet. --- Gary Jennejohn ___ 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: diagnosing freezes (DRI?)
On Thu, 16 Apr 2009 22:18:36 +0300 Kostik Belousov kostik...@gmail.com wrote: On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: Gary Jennejohn wrote: deeptec...@gmail.com wrote: This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Is there any reason this shouldn't be the default? This is becoming an increasingly common FAQ. The only reason I am aware of is that the buffer is allocated on the stack. 128 bytes is not so small for our kernel stacks. True, but it still seems like this could be put into GENERIC, commented out, with a good comment about stack size, so that users have a reasonable chance of finding out about it. --- Gary Jennejohn ___ 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: diagnosing freezes (DRI?)
On Thu, 16 Apr 2009 17:04:55 +0200 deeptec...@gmail.com wrote: [snip a whole bunch of stuff] This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. --- Gary Jennejohn ___ 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: diagnosing freezes (DRI?)
On Sat, 11 Apr 2009 11:15:59 +0100 xorquew...@googlemail.com wrote: On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? It's definitely in 8-current. Seems to be set to 0 as default. --- Gary Jennejohn ___ 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: some questions about 32 bit / 64 bit
On Fri, 3 Apr 2009 15:27:53 +0200 Harald Servat redcr...@gmail.com wrote: Hi again, 2009/4/3 Ivan Voras ivo...@freebsd.org Harald Servat wrote: My first issue is, I'm currently working with Linux and I'm planning to switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., i386 or amd64). If I switch to the 32 bit version, which is the memory limit On a server, switch to 64 bit. On a desktop machime, go with 32-bit. You will only be able to address slightly over 3 GB no matter which graphics card you use but on the other hand you'll have better supported drivers and 3rd party software. I've just seen this topic also being mentioned in http://www.freebsd.org/doc/en/books/faq/compatibility-memory.html And what about the second issue? Thank you very much. All I can say is that I've been using 64-bit FreeBSD as my desktop for years and never had any real problems. Of course, this is _not_ a laptop, so YMMV. But several people have reported in various MLs that they're using their laptops in 64-bit mode with success. Try it in 64-bit mode. If you have problems, then consider 32-bit mode. --- Gary Jennejohn ___ 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: Google SoC 2009 Idea
On Thu, 26 Feb 2009 17:53:48 +0530 Siddharth Prakash Singh sps...@gmail.com wrote: Do you use FreeBSD? __How long have you used it? What do you do with it? No, I haven't really used FreeBSD much. I have been using Linux since long! Have you read Kirk McKusick's book on FreeBSD internals? No. But I have sound knowledge of Linux and Minix Kernel. Having done development on both FreeBSD and Linux I can authoritatively state that they're totally different animals. But just because you only have Linux knowledge doesn't exclude you from doing FreeBSD development. It will just take a while to get up to speed. --- Gary Jennejohn ___ 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: /var/log/messages logs appear in the output of sysctl -a
On Wed, 7 Jan 2009 13:30:20 +0200 Eitan Shefi eit...@mellanox.co.il wrote: I am testing a NIC driver. I found it's logs and /var/log/messages logs in the output of sysctl -a: I run sysctl -a | less, and there I find: kern.devstat.version: 6 kern.devstat.generation: 137 kern.devstat.numdevs: 1 kern.kobj_methodcount: 143 kern.log_wakeups_per_second: 5 kern.msgbuf_clear: 0 kern.msgbuf: ound file system checks in 60 seconds. 118 mtnic0: FW version:2.6.0 mtnic0: Board ID: mtnic0: Using 1 tx rings for port:1 [4096] mtnic0: Using 4 rx rings for port:1 [1024] mtnic0: Using 1 tx rings for port:2 [4096] mtnic0: Using 4 rx rings for port:2 [1024] mtnic0: Initializing MSIX mtnic0: Enabling MSI-X (11 vectors) mtnic0: Board ID:MT_0BD0110004 mtnic0: [ITHREAD] mtnic0: Activating port:1 mtnic0: Ethernet address: 00:02:c9:03:35:20 mtnic0: Activating port:2 mtnic1: Ethernet address: 00:02:c9:03:35:21 mtnic0: [ITHREAD] mtnic0: [ITHREAD] mtnic0: mtnic0: mtnic0: mtnic0: Port 1 - link up mtnic0: [ITHREAD] mtnic0: [ITHREAD] mtnic0: [ITHREAD] Limiting icmp ping response from 300 to 200 packets/sec Limiting icmp ping response from 300 to 200 packets/sec Limiting icmp ping response from 1497 to 200 packets/sec Limiting icmp ping response from 1500 to 200 packets/sec Limiting icmp ping response from 1498 to 200 packets/sec Limiting icmp ping response from 1500 to 200 packets/sec Any idea how can such logs apear in sysctl -a ? If you were viewing this as root on the console then you were simply seeing kernel output interleaved with the output from sysctl. --- Gary Jennejohn ___ 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: Watchdog for Boser (HS-7001)
On Mon, 01 Dec 2008 09:38:51 +0100 Christoph Mallon [EMAIL PROTECTED] wrote: Won De Erick schrieb: Hello, I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box. http://www.boser.com.tw/manual/HS-7001v1.1.pdf I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning. section .text global _start _start: I did assemble, link (ld) and got no error. But when I run, I got the following error: # ./watchdog.out Bus error (core dumped) MOV DX, 2EH MOV AL, 87H OUT DX, AL OUT DX, AL Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault. See io(4), i386_get_ioperm(2), i386_set_ioperm(2), mem(4). --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dd if=/dev/mem can hang a machine?
On Fri, 28 Nov 2008 15:28:35 +0200 Andriy Gapon [EMAIL PROTECTED] wrote: I have a new machine with DG33TL mainboard (ICH9/G33). In a course of some hacking I ran dd if=/dev/mem ... to scan all memory, this caused the machine to hang. I tried to reproduce and this is 100% reproducible. I am not used to such behavior. In older days I could scan all the memory without any issues. Could this be related to some modern form of memory-mapped IO? Or to Intel Management Engine (that seems t bite into DRAM)? Or something else? Just wondering. That's what I would assume. With some hardware just reading a register can be harmful. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is difference between /etc/rc called programs and ones called after login prompt shows up
On Sat, 23 Aug 2008 06:34:23 -0400 Aryeh Friedman [EMAIL PROTECTED] wrote: What is difference between /etc/rc.d called programs and ones called after login prompt shows up? The reason for asking is sysutils/fusefs-kmod gives an error if any mounts are attempted in /etc/rc but if the exactly the same command is issued by a user's .login/.xsession/etc. it works without problem (assuming proper permissions of course). a) Can anyone think of a reason why this would happen (the maintainer is non-responive) I suspect that fuse.ko is loaded by one of the scripts under /etc/rc.d since it seems to be installed under $PREFIX/modules where PREFIX is normally /usr/local. Until that happens you can't use mount_fusefs. b) Is it possible to force something to run after /etc/rc exits but before init calls getty? Well, there are ways to force dependencies in the rc.d scripts, but I don't know the setup well enough to be helpful. I have no idea which script handles modules installed by ports and when it is invoked. You could try moving fuse.ko to /boot/modules and modify loader.conf to load fuse.ko at boot time. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
On Thu, 17 Jul 2008 09:30:17 -0700 Randy Bush [EMAIL PROTECTED] wrote: I think the best route to that is to have a separate utility for managing disk partitioning. The installer can then use that utility, and sysadmins can also use it later after the system is installed. i often invoke sysinstall on a running system to slice/partition/etc a new drive [radically trimmed Cc list] sade(8) is supposed to take the place of sysinstall for disk operations. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel HEAD userland 7.0-REL?
On Fri, 4 Jul 2008 14:42:27 +0200 Matthias Apitz [EMAIL PROTECTED] wrote: I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my laptops; I've been asked to check if a given driver problem in RELENG_7 is as well with HEAD... can I update the kernel to HEAD and let the userland (and all my compiled ports) as 7.0-REL; I know that this is not the intention, but it would cost me a lot of work if I should compile as well ~200 ports Theoretically it should work. It's not necessary to overwrite your current kernel. You can do something like this, which is what I do to test kernels. cd /usr/src;make -s installkernel KODIR=/boot/test;cd nextboot -k test reboot This does a one-time start using the test kernel under /boot/test. Your other option is to describe the problem and ask if anyone using 8-current has encountered it. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: setting up a local cvsup server
On Wed, 02 Jul 2008 22:13:23 -0400 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Currently I keep a local cvs/svn mirror of the public repo I update my sources via cvs not c(v)sup... I just got a laptop and I want it to use my desktop (where the local repo is) as a cvsup server what do I need to do (I manually update my local repo and want to continue with that practice so no need for cvsup-mirror or the method suggested in development(8)) advice? Actually it's no big deal to keep your CVS repository up-to-date with cvsup and in my experience it's the simplest way to do it. Anyway, in my experience here are the two most important things needed on the server: 1) you _absolutely must_ have these symbolic links set correctly! garyj:peedub:~:-bash:10 ll /usr/local/etc/cvsup/prefixes/ total 0 lrwx-- 1 root wheel 8 May 16 2007 FreeBSD-crypto.cvs - /u2/ncvs lrwx-- 1 root wheel 8 May 16 2007 FreeBSD.cvs - /u2/ncvs 2) then just start cvsupd with reasonable command line options. I use -C 2. Then just create supfiles on the client and point them at your server. It's really rather trivial. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 with SSD reducing writes
On Tue, 24 Jun 2008 06:24:12 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 03:11:50PM +0200, Matthias Apitz wrote: Hello, I have installed FreeBSD 7.0R on that eeePC 900 and because of the limited life time of the SSD (see http://en.wikipedia.org/wiki/Wear_levelling ) I disabled some logging stuff which I don't need on that tiny laptop, ... any other ideas how to reduces unnecessary often-writes? Why bother? http://www.storagesearch.com/ssdmyths-endurance.html I've also seen test results in c't magazine where they did millions of writes to the same physical sector and never saw any errors. The manufacturers have really good internal wear leveling algorithms which are totally transparent to the user. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for *cheap* embedded platform w- 2 ethernets
On Sun, 22 Jun 2008 11:58:32 +0200 Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: I'm looking for a cheap and small embedded platform to use as a portable vpn endpoint. It doesn't have to be fast, it just has to run *BSD. Any suggestions?? We build our own ARM9 based board: http://www.small-control.de/FSB-A920-1.html http://www.small-control.de/FSB-A920-1-APG.html Looks like it's soldered by hand. Is it? --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Introduction
On Thu, 24 Apr 2008 19:46:02 -0400 David Forsythe [EMAIL PROTECTED] wrote: My name is David Forsythe and I'll be working on allowing parallel builds in the ports collection for Summer of Code this year. This would definitely be of benefit! Good luck. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new SATA chipsets support
On Thu, 13 Mar 2008 17:51:15 +0200 __ [EMAIL PROTECTED] wrote: I am going to build my new file- and gateway server and i wish to use any of brand new motherboards for it, such as ASUS M2N-SLI deluxe (nforce 570 SLI chipset) or Gigabyte MA790X-DS4 (AMD 790X / AMD SB600 chipset), but i can't find any information of supporting that chipsets in your current 7.0 release. Are you going to include support of that chips to your next releases, and if yes, when? Or maybe i can find that drivers somewhere else? Try hitting CR once in a while. This is all one long line! I can't speak to this, but why not use a board which is already known to work? I'm using a Gigabyte M61P-S3 myself. I think that drivers from ASUS (http://support.asus.com/download/download.aspx?SLanguage=en-enmodel=M2N-SLI%20Deluxe) may not work with FreeBSD? These are guaranteed not to work, unless you want to port the Linux drivers. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new SATA chipsets support
On Thu, 13 Mar 2008 14:49:52 -0400 Alexander Sack [EMAIL PROTECTED] wrote: On Thu, Mar 13, 2008 at 2:16 PM, Gary Jennejohn [EMAIL PROTECTED] wrote: I can't speak to this, but why not use a board which is already known to work? I'm using a Gigabyte M61P-S3 myself. I think that drivers from ASUS ( http://support.asus.com/download/download.aspx?SLanguage=en-enmodel=M2N-SLI%20Deluxe) may not work with FreeBSD? These are guaranteed not to work, unless you want to port the Linux drivers. I see that 7.0-RELEASE has ATA Nvidia chipset support. Does that not cover the SATA nvidia chipsets of their unified MCP chipset? I'm just curious if this could be fixed by adding this particular chipset PCI information to struct ata_nvidia_ident in sys/dev/ata/ata-chipset.c. It looks MCP55 is certainly supported but again I'm stabbing slightly in the dark since I don't know SATA NV. Sorry if this is totally off. I'm new to the FreeBSD kernel but not SATA driver development in general. Its just a thought... Well, according to man ata the nforce[23] MCP (among other nvidia chipsets) are supported. My motherboard has MCP61 which works just fine. But I'm no expert on nvidia chip sets and can't really evaluate whether just adding the PCI information will work. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: insufficient power for Xcraft HD enclosure
On Fri, 18 Jan 2008 21:21:52 -0800 (PST) KAYVEN RIESE [EMAIL PROTECTED] wrote: it comes with a silly barebones manual that tells you to slide it in and screw the screw or some such, not very helpful. it also with a USB connector that has one junction fitting the device coupled to what i am calling a daisy chain of two USB connectors. What you really mean is that you have a Y-cable. A Y-cable is used because USB only supports max. 500 mA per port. What you're expected to do is plug both connectors of the Y-cable into your laptop and the other, single connector into the HD case. This should allow your laptop to provide enough juice to start the disk spinning without violating the USB specification. If your laptop has only one USB port then you're SOL. The case seems to have no provision for attaching an external power supply. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux executable picks up FreeBSD library over linux one and breaks
On Wed, 12 Dec 2007 22:33:18 -0500 Chuck Robey [EMAIL PROTECTED] wrote: [lots of discussion snipped] I really wish that ports management would go on the record and make a definite ruling, that all linux images should install to the /compat/linux tree. If this would be the case, then nI would myself go about fixing the horde of software that violates this. I said horde, and I sure meant it. I agree with this whole-heartedly. Interestingly, there's already a LINUXBASE which points at /compat/linux. Why all Linux-based ports aren't required to or automatically use this is a mystery to me. Just my 2 Euro-cents. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: handling pdfs?
On Sun, 02 Dec 2007 13:09:14 -0500 Chuck Robey [EMAIL PROTECTED] wrote: Gary Jennejohn wrote: xpdf allows printing of page ranges. I use it all the time. I'm not sure why, maybe I have too poor a font selection here, but the fonts, I mean, the onscreen fonts that xpdf seems to choose, always seems to run characters together, so it gets hard to read them. So, xpdf wouldn't be my first choice. I use kpdf to view pdfs for that particular reason, and onthe same document, kpdf does a distinctly better job, If kpdf uses xpdf's engine, then it must find some way to pick better fonts for itself, it actually does look better. I personally find that xpdf looks OK. I avoid things like kpdf because I don't use KDE and don't really need all the bloat associated with it. But that's just me. -- Gary Jennejohn * DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [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: handling pdfs?
On Wed, 28 Nov 2007 13:05:18 -0500 Bill Moran [EMAIL PROTECTED] wrote: In response to Giorgos Keramidas [EMAIL PROTECTED]: On 2007-11-27 21:27, Chuck Robey [EMAIL PROTECTED] wrote: I need to read about 4 tons of some really sparse pdf specs. I also have a rather inconvenient throwback: I feel hugely more at home-reading documents in paper. What I'd kind of like to do would be able to perform cut'n'paste among different pdfs, 5 pages here, 10 pages there, until I put together maybe 100-200 pages, and sit back and read it. What I can't do is print just a few pages out of several 800-plus page specs, and perform paper cut'n'pasting. If you find a way to 'save' only parts of a PDF document, i.e. pages 5-10, 17 and 25 in a separate file, then the ``pdfjam'' port includes a utility called ``pdfjoin'' :) You could print the desired pages to .ps files, use ps2pdf to convert them and then pdfjam to combine them. It's enough of a roundabout that I don't know if it's worth it or not. xpdf allows printing of page ranges. I use it all the time. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
