I'm tryingeto do a "make release" via
time make release CHROOTDIR=/local/GenRelease BUILDNAME=3.2.0.-rel-wkb
RELEASETAG=RELENG_3_2_0_RELEASE
Making docs...
===> Extracting for docproj-1.0
>> No MD5 checksum file.
===> Patching for docproj-1.0
===> Configuring for docproj-1.0
===> Installing
I have two boxes with ATAPI Zip Drives:
Box1:
wdc1: unit 1 (atapi): ,
removable, intr, iordis
wfd0: medium type unknown (no disk)
Box2:
wdc1: unit 0 (atapi): , removable, intr,
iordis
wfd0: medium type unknown (no disk)
wfd0: buggy Zip drive, 64-block transfer limit set
The drive on Box1 gets ti
>
> For more info about maxcontig, you can refer to the well-known
> paper of McKusic et al about Fast File System. It is a parameter
> that is hardware dependent. You can't get performance just by
> increasing its value. Unfortunately, I don't have on-line version
> of that paper.
>
>
> --F
> I've seen references to people writing Towers of Hanoi in troff, but
> I don't have a pointer to the actual code.
Can't help you there, but here's something for you:
/hanoi{/x{{exit}}def /e{exch}def /d{dup}def /l{loop}def /n exch def /m 2 n 1
sub exp cvi def[m{d 0 eq x if d[e d 0{1 add e 2 div
Wilko Bulte writes:
> >> sgmlformat-1.7.tar.gz doesn't seem to exist on this system.
> >> Attempting to fetch from
> http://fallout.campusview.indiana.edu/ports/distfiles/.
> fetch: reading reply from fallout.campusview.indiana.edu: Operation timed
> out
> >> Attempting to fetch from
> ftp://ftp.f
The following code should obviously segfault:
#include
#include
char buffer[4028];
void main() {
int i;
for (i=0; i<=4028; i++)
buffer[i]='A';
syslog(LOG_ERR, buffer);
}
Now here's the problem:
When compiling with "gcc file.c", the program segfaults.
Whe
On Sun, 6 Jun 1999, Marc Tardif wrote:
> The following code should obviously segfault:
Nope. There is no requirement that code segfault. C does not make any
promises that accessing memory that you have not allocated will do
anything.
> #include
> #include
>
> char buffer[4028];
>
> void ma
ECOTECH TECHNOLOGIES, L.L.C.
4001 E., Broadway Road, Suite 7, Phoenix, AZ 85040, USA
Tel: (602) 437 8000, Fax: (602) 437 4033
E-mail: ecotech...@yahoo.com
http://www.ecotech
In the long-standing tradition of deadlocks, I present to you all a new one.
This one locks in getblk, and causes other processes to lock in inode. It's
easy to induce, but I have no idea how I'd go about fixing it myself
(being very new to that part of the kernel.)
Here's the program which ind
In message <199905281615.jaa32...@whistle.com> Doug Ambrisko writes:
: I wondering if I'm missing something here. I had PCMCIA stuff working
: for a NE2000 ethernet card but not for serial ports.
That is correct, at least for -current.
: Does anyone have
: serial ports working (ie. modems or se
Zhihui Zhang wrote:
> My feeling is that if we allocate ALL the data blocks of a big file
> contiguously, this will lead to "too much localization" as described in
> the paper (or the book). However, this may be good for this big file if
> the system buffering capability and hardware allow it
Brian Feldman writes:
> In the long-standing tradition of deadlocks, I present to you all
> a new one. This one locks in getblk, and causes other processes to
> lock in inode. It's easy to induce, but I have no idea how I'd go
> about fixing it myself (being very new to that part of the
>
Christopher Sedore wrote:
>
> One other thing which should be noted in the docs, or fixed in the kernel.
> The aiocb struct should be bzeroed before an aio_read or aio_write because
> if you happen to have garbage in the private part of the structure, the io
> can be synchronous (look at the first
Arun Sharma said:
> bread
> ffs_read
> ffs_getpages
> vnode_pager_getpages
> vm_fault
> ---
> slow_copyin
> ffs_write
> vn_write
> dofilewrite
> write
> syscall
>
> getblk finds that the buffer is marked B_BUSY and sleeps on it. But I
> can't figure out who marked it busy.
>
This looks l
14 matches
Mail list logo
