From: Jacob Myers [mailto:ja...@whotookspaz.org]
Jaime Bozza wrote:
From: Arnaud Houdelette [mailto:arnaud.houdele...@tzim.net]
I haven't tried larger files - Maybe the boundary is different on amd64?
Doing some quick tests
right now, I was able to upload a 100MB file without
From: Jacob Myers [mailto:ja...@whotookspaz.org]
Arnaud Houdelette wrote:
I had the same issue using 7.1 amd64, with ZFS, no SMP.
Not really sure what is the size boundary. I can't really test
either,
as the machine is remote.
But I confirm that each tentative upload of certain
Sincerely,
Jaime Bozza
MindSites Group, LLC
From: Dylan Cochran [mailto:heliocent...@gmail.com]
Superficially, this seams identical to a deadlock I reported for
7.1-RC1. Would you mind compiling a kernel with these options:
snip
KDB: stack backtrace:
db_trace_self_wrapper(c0b55b52
From: Kostik Belousov [mailto:kostik...@gmail.com]
Can you look up the source line for kern_sendfile+0x90d in your
kernel ? Do kgdb kernel.debug, then execute list *(kern_sendfile+0x90d).
In my case, it was kern_sendfile+0x6ad (rebuilt with RELENG_7 this weekend).
Here's the output:
(kgdb)
From: Arnaud Houdelette [mailto:arnaud.houdele...@tzim.net]
I haven't tried larger files - Maybe the boundary is different on amd64?
Doing some quick tests
right now, I was able to upload a 100MB file without a problem, but this is
an AMD64 system with SMP,
plus the filesystem is all ZFS,
The additional information I have (over the PR) is that:
1) Files over 64K cause the problem, not just larger files
I thought it was over 1 MB or so. But maybe I'm wrong. ISTR that I
couldn't trigger it with some images of around 70K.
I discovered it originally with a 72K file. After some
I believe I found a problem with the ULE scheduler - At least the fact that
there is a problem, but I'm not sure where to go from here. The system locks
all processes, but doesn't panic, so I have no output to give.
I was able to duplicate this on three different machines and solved it by
Try adding this or changing these items in lighttpd.conf:
## FreeBSD!
server.event-handler = freebsd-kqueue
server.network-backend= writev
Scott,
Lighttpd was already using freebsd-kqueue, but I added the writev
network-backend and the problem went away. With this additional
for the nfs.c file.
Jaime Bozza
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
of the PCI Express boards
(or Server boards) at this point in time.
Jaime Bozza
Qlinks Media Group
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
that would work just fine for you.
Jaime Bozza
Qlinks Media Group
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
for them in FreeBSD though.
Jaime Bozza
Qlinks Media Group
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
with 3ware wasn't good. :(
Jaime Bozza
Qlinks Media Group
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
tests.
Running additional tests and leaving an array in a degraded state is
(again, my opinion) asking for trouble.
Hope that helps!
Jaime Bozza
Qlinks Media Group
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
is just software RAID, I switched over to
gmirror but kept AHCI on so I'd still have hotplug support. After that
I wasn't able to kill the system.
Jaime Bozza
Qlinks Media Group
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
a format/verify I wasn't able to duplicate the problem no
matter what I tried.
So, RAM is definitely the easiest thing to test but keep in mind that
there are other areas that may also cause an issue.
Jaime Bozza
___
freebsd-stable@freebsd.org mailing list
6.0, everything shows up fine.
I'd be happy to forward additional information as needed. Please let me
know.
Thanks,
Jaime Bozza
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send
interface that would not allow dvd+rw-mediainfo to access the
drive correctly when the firewire/sbp interface would.
Thanks,
Jaime Bozza
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send
and used the BIOS menu to expand (since it would
have been a foreground process), but it's nice to be able to keep the
system in used while I was running the processes.
Jaime Bozza
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman
of
filesystem corruption that would be fixed easily, so I just reworked our
partitions so that I had multiple smaller partitions and removed
softupdates for now. I've crashed the system a few times since then
and fsck worked just fine.
Any other questions you have, feel free to ask.
Jaime Bozza
are similar enough that
the restore just worked.
Jaime Bozza
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
timeout errors again.
Could it be possible that these drives need some sort of workaround when
in PIO mode?
Jaime Bozza
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Bruce A. Mah
Sent: Monday, June 17, 2002 11:33 PM
To: John Prince
Cc: [EMAIL
22 matches
Mail list logo
