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
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
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
>
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
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
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
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
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
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
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
> 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
>
> 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 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
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
14 matches
Mail list logo
