Re: Limitations in FreeBSD
* Matthew Dillon | FreeBSD boxes can handle up to 4 Gigabytes of main memory. Is this true for the Alpha kernels too? -- Andreas Dobloug : email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing much slower than reading...
:well, I am working on writing a capture program to do 640x480x12bpp@30fps :to a raw disk, but writing to the raw device is SOOO slow... the reason :I say it's slow is the fact that it takes 8 times the system time writing :than reading... : :a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm, :VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge :WinCast/TV Model 61351 B226, 3.3-RELEASE... : :now the hard disk can push and pull around 20meg/sec w/o any problems.. :but when I time the disk I get: :$ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048 :2048+0 records in :2048+0 records out :134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec) :5.75 real 0.01 user 0.21 sys :$ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048 :2048+0 records in :2048+0 records out :134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec) :6.28 real 0.00 user 1.68 sys : :now, why does it cost SOOO much more processing time to write than :read?? are there plans to fix this slow down? is it possible? can't :we just dma write out of userland since we are blocking on the write? : :-- : John-Mark Gurney Voice: +1 408 975 9651 It doesn't necessarily, but your use of dd is causing the numbers to look skewed. It's real simple: when you read from the raw disk into a fixed buffer the system is DMAing directly into the buffer. dd then 'writes' the buffer to /dev/null, which is a NOP. There is no effect on the cpu's L1 and L2 caches because the cpu never reads or copies the data anywhere. When you write to a raw disk with your dd, it is reading a block from /dev/zero into its local buffer which involves a zeroing operation that the read code never had to do, then dd writes the buffer to disk. So the write test is doing an extra scan of the buffer *and* blowing up the cpu's L1 and L2 caches due to that scan while the read test is doing no buffer copies at all so the cpu isn't touching the buffer at all - leaving the L1 and L2 caches pretty much alone. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SIMPLELOCK_DEBUG and apause
Why trying to debug some locking code of my own I enabled SIMPLELOCK_DEBUG, only to find out that I was getting lots of `simple_unlock: lock not held' in lockmgr -> acquire -> apause. Looking closer at `apause' it seems rather clear that it can cause this. I proposed simple change is below. Comments? /assar --- kern_lock.c.origMon Nov 8 03:55:26 1999 +++ kern_lock.c Mon Nov 8 04:24:13 1999 @@ -116,9 +119,11 @@ simple_lock(&lkp->lk_interlock); if ((lkp->lk_flags & flags) == 0) return 0; + simple_unlock(&lkp->lk_interlock); break; } } + simple_lock(&lkp->lk_interlock); } return 1; } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SMP changes from 3.0 to 3.3?
At work we have 18 or so web servers runing FreeBSD 3.0 on daul PIIs. When they see very high loads (~300+) the SMP starts do get confused and things randomly fail. Were there signifigant SMP changes from 3.0-RELEASE to 3.3-RELEASE that may make SMP more stable at high loads? Are their any signifiant SMP changes at all from 3.0-RELEASE to 3.3-RELEASE? Or should I just go try and read the comit logs and see if I can make any sense of this my self? Last time I tried, I didn't get to far :( Thanks much. -- --Travis "Linux is something for Windows haters, BSD is something for Unix lovers" (Heike S., Febr. 98) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
On Sun, Nov 07, 1999 at 04:57:54PM +0100, Dag-Erling Smorgrav wrote: > Kevin Day <[EMAIL PROTECTED]> writes: > > The problem is that 'fsck -py' ignores the 'p' and will fsck every time, > > even if it's unneeded. This takes ages for me. I believe I submitted a PR > > with a 'fix' to fsck. > > 'fsck -p || fsck -y' should do the trick. What about at rc.conf knob, that make /etc/rc use this instead of the normal fsck -p ?? This could be useful for servers at remote sites. Should I submit a PR with a diff ? /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM support
Mike Smith wrote:
>
> > To whoever that may interest, I've now got a nearly working freebsd
> > loader for the NetWinder. It currently only uses the serial console and
> > miss internal hard driver support but work is underway for both these
> > issues.
>
> Cool! Does the NetWinder use OpenFirmware, or some other firmware
> interface?
Unfortunately no. It uses a stripped down linux kernel as firmware.
That's why I switched to work on the bootloader: the darn thing doesn't
seems to grok ufs right. It's bad because the disk/video support have to
be done from the ground up. Adding support to the Shark/acorn computers
will probably be a lot easier.
> > I'm making some progress too in getting world to compile but work in
> > this area is more slower as I've got no way to test what I compile and
> > I'm not that at ease with most of the code.
>
> If you're interested in sharing your work, I have a DNA ('shark') here
> that was loaned to the Project for just this purpose. I'd be really
> interested to see your cross-build bits integrated into our tree ASAP.
I'd really like this to happens too but right now I think that would be
near impossible. binutils 2.9.1 doesn't really support arm/elf so I'm
currently using a recent snapshot of binutils (2.9.5) with gcc 2.95.1.
I'm using a boatload of very ugly hacks to make this combitation work
with current...
As soon as the binutils crew releases something more official so that it
could be added into the tree I'll be more than happy to send pr's for
what I've got so far.
Steph
--
Stephane E. Potvin
InnoMediaLogic Inc. - http://www.multichassis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM support
> To whoever that may interest, I've now got a nearly working freebsd
> loader for the NetWinder. It currently only uses the serial console and
> miss internal hard driver support but work is underway for both these
> issues.
Cool! Does the NetWinder use OpenFirmware, or some other firmware
interface?
> I'm making some progress too in getting world to compile but work in
> this area is more slower as I've got no way to test what I compile and
> I'm not that at ease with most of the code.
If you're interested in sharing your work, I have a DNA ('shark') here
that was loaned to the Project for just this purpose. I'd be really
interested to see your cross-build bits integrated into our tree ASAP.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
On Sat, 6 Nov 1999, Warner Losh wrote: > There are ways that the user can see the code to execute it, but not > read it normally. procfs breaches this inability to read the file. > Also, there are many related problems which make a proper fix for this > that is more complicated than removing /proc/xxx/file nearly > impossible. "Proper" here means "A fix which will prevent the > disclosure of a file to unauthorized people which would normally not > be able to read the file." > > I'm convinced that it would be hard to codify all the security checks > needed to access the file originally into a single number which would > allow people that could read the original file to read /proc/xxx/file > and disallow people who couldn't read the file to also be disallowed > from reading /proc/xxx/file. It sounds to me that what you really want are the semantics of a symbolic link and not the semantics of a hard link. Is it just me, or does it seem as if the pathname of the executable being stored as a virtual symlink in procfs as "file" would solve these security problems? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
On Sun, 7 Nov 1999, Sean Eric Fagan wrote: > I don't, but what I like doesn't matter, it seems -- Warner knows everything. > So I'm sure he knows better than I do the overhead this will impose, and the > impracticality in a general system. > > Unix really isn't set up to carry around 'official pathnames,' due to the > existence of symlinks and other fun stuff. Other systems are set up for this > -- my favourite was EMBOS, by ELXSI -- and there are some _really_ nifty > things you can do, if you have it. (Watchdogs and program-based-access-lists > are my two favourite, the latter allowing you to get rid of SUID/SGID in many > cases. There is a paper available on implementing watchdogs under unix > [4.2bsd, I believe] that discusses some of this. If you're willing to cover > 60-80% of the cases, instead of 95-100%, it's considerably easier.) > The _REALLY_ obvious solution to this is to find the real path on exec() and store the pointer in proc. How is this full of "overhead" and "impractical"? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM support
On Sun, 7 Nov 1999, Stephane E. Potvin wrote: > To whoever that may interest, I've now got a nearly working freebsd > loader for the NetWinder. It currently only uses the serial console and > miss internal hard driver support but work is underway for both these > issues. > > I'm making some progress too in getting world to compile but work in > this area is more slower as I've got no way to test what I compile and > I'm not that at ease with most of the code. Hey, good work! If you have any questions on porting the kernel, don't hesitate to contact me. I also have a fair knowledge of ARM too, although its a bit dated (the last ARM machine I owned was an ARM3). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ARM support
To whoever that may interest, I've now got a nearly working freebsd loader for the NetWinder. It currently only uses the serial console and miss internal hard driver support but work is underway for both these issues. I'm making some progress too in getting world to compile but work in this area is more slower as I've got no way to test what I compile and I'm not that at ease with most of the code. -- Stephane E. Potvin InnoMediaLogic Inc. - http://www.multichassis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
Kevin Day <[EMAIL PROTECTED]> writes: > The problem is that 'fsck -py' ignores the 'p' and will fsck every time, > even if it's unneeded. This takes ages for me. I believe I submitted a PR > with a 'fix' to fsck. 'fsck -p || fsck -y' should do the trick. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ftpd feature: lock file being stored
On Sun, Nov 07, 1999 at 05:44:51PM +0900, Daniel C. Sobral wrote: > Actually, use fstat to check against ftpd, and lockf between the > scripts. :-) Good idea :) I think that I'll do just that. Cheers, -- Jos Backus _/ _/_/_/"Modularity is not a hack." _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
> >You can make hard links to > > No, you cannot. Yes you can - you just need to make sure the target directory is on the same filesystem as the *original* file. 11:30:gonzo 9% cp /bin/sleep /tmp 11:30:gonzo 10% ls -l /tmp/sleep* -r-xr-xr-x 1 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep 11:30:gonzo 11% /tmp/sleep 10 & [1] 636 11:31:gonzo 12% ln /proc/636/file /tmp/sleep2 11:31:gonzo 13% ls -l /tmp/sleep* -r-xr-xr-x 2 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep -r-xr-xr-x 2 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep2 11:32:gonzo 14% chmod u+s /tmp/sleep2 11:32:gonzo 15% ls -l /tmp/sleep* /proc/636/file -r-sr-xr-x 2 dwmalone wheel 45224 Nov 7 11:30 /proc/636/file -r-sr-xr-x 2 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep -r-sr-xr-x 2 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep2 David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
> Err... I don't see the problem. The permissions of the hardlink will > be different, so the user might be able to see the "code", but won't > be able to run the suid (because the hardlink won't have the suid > bit set). Suid bit is stored in the inode, not the directory entry, so it will be set. I've tested it - try running su in one window, don't type the password, and then run /proc/pid/file and typing the password. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
On Sun, 7 Nov 1999, Sean Eric Fagan wrote: > In article <[EMAIL PROTECTED]> you write: > >Brian Fundakowski Feldman wrote: > >> It sounds to me that what you really want are the semantics of a > >> symbolic link and not the semantics of a hard link. Is it just me, > >> or does it seem as if the pathname of the executable being stored as > >> a virtual symlink in procfs as "file" would solve these security > >> problems? > >M... I like that... > > I don't, but what I like doesn't matter, it seems -- Warner knows everything. > So I'm sure he knows better than I do the overhead this will impose, and the > impracticality in a general system. > > Unix really isn't set up to carry around 'official pathnames,' due to the > existence of symlinks and other fun stuff. Other systems are set up for this Linux is now one of them.. the file descriptor now (I was told) leads to a name cache entry, which is the name under which it was openned. THat in turn has a pointer to teh directory that it was in...etc. > -- my favourite was EMBOS, by ELXSI -- and there are some _really_ nifty > things you can do, if you have it. (Watchdogs and program-based-access-lists > are my two favourite, the latter allowing you to get rid of SUID/SGID in many > cases. There is a paper available on implementing watchdogs under unix > [4.2bsd, I believe] that discusses some of this. If you're willing to cover > 60-80% of the cases, instead of 95-100%, it's considerably easier.) > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ftpd feature: lock file being stored
Jos Backus wrote: > > Scanning the directory for new files, as the aforementioned script does. If > you have more than one script doing this at the same time, both may conclude > that a given file is ``available'' and try to act upon it. Inevitably, one of > those scripts will fail. Hence my solution. But maybe I don't quite understand > the problem :-) > > (Yes, I know you will say, "Don't run more than one script at a time then.". > But whether this is possible really depends on the application and moreover > seems to be an unecessary restriction.) Actually, use fstat to check against ftpd, and lockf between the scripts. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loader security problem
Alexey Zelkin wrote: > > IMHO, it would be nice to have password protected loader(8) (like linux lilo) > or just ACLs for loader(8)'s "more" command (like unavailable for viewing > files) cat >/boot/passwd.4th <> /boot/loader.rc Say... does LILO have a scripting language? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
In article <[EMAIL PROTECTED]> you write: >Brian Fundakowski Feldman wrote: >> It sounds to me that what you really want are the semantics of a >> symbolic link and not the semantics of a hard link. Is it just me, >> or does it seem as if the pathname of the executable being stored as >> a virtual symlink in procfs as "file" would solve these security >> problems? >M... I like that... I don't, but what I like doesn't matter, it seems -- Warner knows everything. So I'm sure he knows better than I do the overhead this will impose, and the impracticality in a general system. Unix really isn't set up to carry around 'official pathnames,' due to the existence of symlinks and other fun stuff. Other systems are set up for this -- my favourite was EMBOS, by ELXSI -- and there are some _really_ nifty things you can do, if you have it. (Watchdogs and program-based-access-lists are my two favourite, the latter allowing you to get rid of SUID/SGID in many cases. There is a paper available on implementing watchdogs under unix [4.2bsd, I believe] that discusses some of this. If you're willing to cover 60-80% of the cases, instead of 95-100%, it's considerably easier.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
