Matthew Dillon wrote:
> :Hmm, the current approach doesn't look all that "right" to me, because we are
> :retrying operation even though the upper-layer code that initiated it was
> :already notified about the failure (e.g. received EIO), so that it should not
> :assume that the data was actually w
On Fri, Oct 18, 2002 at 11:35:54AM -0700, Matthew Dillon wrote:
>
> :> :
> :> :There is a very easy way to trigger the problem: insert blank floppy
> :> :...
> :>
> :> Your patch looks slightly incomplete to me, but the concept is reasonable.
> :> The BIO_NORETRY test that sets B_INVAL sh
I have search the web trying to find info on vmware3 and FreeBSD as the
host os.
I noticed a post where someone said they got the modules working, but
were having problems with the binary part.
Any progress?
Looking for beta testers?
I upgraded my system to a Duron, and now all my guest os's
MD_ROOT_SIZE is only needed for write_mfs_in_kernel. When write_mfs_in_kernel was
removed the
code that used it was not though. I don't think it is still being used though. A
couple of files
still reference it: src/sys/dev/md/md.c has ifdefs for it, src/release/Makefile still
compiles it
on
On Fri, Oct 18, 2002 at 04:42:01PM -0700, David Yeske wrote:
> MD_ROOT_SIZE is only needed for write_mfs_in_kernel. When write_mfs_in_kernel was
>removed the
ok, sorry for the confusion, i misread the patch.
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd
from your patch i am a bit unclear, do you still depend on
having MD_ROOT_SIZE or you can get rid of it ?
cheers
luigi
On Fri, Oct 18, 2002 at 03:56:11PM -0700, David Yeske wrote:
> I am writing an article about a replacement for write_mfs_in_kernel, and I wanted to
>get some
> f
I am writing an article about a replacement for write_mfs_in_kernel, and I wanted to
get some
feedback on the article and the patch...
http://pigseye.kennesaw.edu/~dyeske/freebsd/article.html
It would be very helpful if people could download the kernel and boot it and give me
feedback.
I have
Can anyone here answer the implied question about recent BSD dump and
restore at the end of Chris's post below?
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FASTNET: NORTHERLY 4 OR 5 BECOMING VARIABLE 3 THEN SOUTHEASTERLY 4 OR 5.
SHOWERS. GOOD.
--- start of forwarded message --
:> :
:> :There is a very easy way to trigger the problem: insert blank floppy
:> :...
:>
:> Your patch looks slightly incomplete to me, but the concept is reasonable.
:> The BIO_NORETRY test that sets B_INVAL should probably be done in
:> brelse(), not in bufwait(). It is the code in
On Oct 16 at 15:43, Julian Elischer spoke:
> ctwm fails to find any fonts
>
> however xfontsel CAN find those fonts
Maybe you need to recall mkfontdir.
-Hanspeter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Thu, Oct 17, 2002 at 06:13:24PM -0400, Ramkumar Chinchani wrote:
+>
+> What would be the best way to *capture* the execv system call at its entry point
+> from user space? ptrace()?
+>
+> What would be a good way to inspect the command line args to execv *after* the
+> path, etc., has been res
Matthew Dillon wrote:
>
> :Hi folks,
> :
> :I noticed that FreeBSD buf/bio subsystem has one very annoying problem
> :- once the write request is ejected into it, and write operation
> :failed, there seemingly no way valid to tell the layer to drop the
> :buffer. Instead, it retries the attempt ov
On Oct 18 at 11:39, Soeren Schmidt spoke:
> It seems Hanspeter Roth wrote:
> > I have an Enmic installed which reports
> > atapci1: port [...]
> >
> > Is this reported literally by the controller or is it derived from a
> > table lookup?
>
> >From a table, seems I could use better glasses :)
:Hi folks,
:
:I noticed that FreeBSD buf/bio subsystem has one very annoying problem
:- once the write request is ejected into it, and write operation
:failed, there seemingly no way valid to tell the layer to drop the
:buffer. Instead, it retries the attempt over and over again, until
:reboot, eve
On Sun, Oct 13, 2002 at 11:00:26PM -0600, Scott Carmichael wrote:
> Can someone help me here? Is there a code change I can make somewhere?
>
> Please CC me on any replies, as I am not subscribed to -net or -hackers.
-net removed. -hackers left (although this might be more of a
-questions thread).
Hi folks,
I noticed that FreeBSD buf/bio subsystem has one very annoying problem
- once the write request is ejected into it, and write operation
failed, there seemingly no way valid to tell the layer to drop the
buffer. Instead, it retries the attempt over and over again, until
reboot, even thoug
Please enlighten us.
I would like to have more than ancient stuff running in my vmware2
[EMAIL PROTECTED] wrote:
is there anyway to lie to vmware2 about the processor installed? or a
patch to vmmon to have it lie to the guest os about the processor
installed?
yes
17.10.2002; 19:32:37
[SorAlx
Please enlighten us.
I would like to have more than ancient stuff running in my vmware2
[EMAIL PROTECTED] wrote:
is there anyway to lie to vmware2 about the processor installed? or a
patch to vmmon to have it lie to the guest os about the processor
installed?
yes
17.10.2002; 19:32:37
[SorAlx
+ Archie Cobbs wrote:
| Are you intending to have this hook into the normal FreeBSD TCP/IP
| stack or be truly standalone? I read your question as the latter but
| others seem to read it as the former.
I am very much a babe in the woods at this point. I have no plan aside
from reading as much
> The bktr supports the 848 family chipset as I recall. I have used the
> Xv extensions made for the GATOS and KATOS projects. They are Linux
> projects, but do some work on FreeBSD as well.
>
> Almost a year ago I had it working with an ATI Wonder which also has an
> BT878 chipset.
Yes..
I hav
The bktr supports the 848 family chipset as I recall. I have used the Xv
extensions made for the GATOS and KATOS projects. They are Linux projects,
but do some work on FreeBSD as well.
Almost a year ago I had it working with an ATI Wonder which also has an BT878
chipset.
Peter
On Friday 18 Oct
It seems Hanspeter Roth wrote:
> On Oct 11 at 09:01, Soeren Schmidt spoke:
>
> > The Sil 680 does support ATAPI DMA, I'll need to dig out the older
>
> I have an Enmic installed which reports
> atapci1: port [...]
>
> Is this reported literally by the controller or is it derived from a
> tabl
On Oct 11 at 09:01, Soeren Schmidt spoke:
> The Sil 680 does support ATAPI DMA, I'll need to dig out the older
I have an Enmic installed which reports
atapci1: port [...]
Is this reported literally by the controller or is it derived from a
table lookup?
It seems to me that on
http://www.sili
On Oct 11 at 12:32, Soeren Schmidt spoke:
> Yes, if its a Sil 0680 chip then it'll work, the one I've got
> is a Sunix SNX 3700, its a feature of the chip not the card
> (unless the maker really screwed up something)
An ENMIC ATA133-RAID Controller which also is based on th Sil 0680
chip ha
24 matches
Mail list logo
