accesses needed in each iterations, that may already be the
cause of such a delay.
I have no hardware to test this, so all of the above is just a wild-
assed guess; but maybe it is of use (and sorry for the spam if it
is not).
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> ht
nately that would require changes to crt1, so it would pose a
compatibility problem.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
"Oh, great altar of passive entertai
On Fri, 2003/06/27 at 14:50:08 -0400, John Baldwin wrote:
> On 27-Jun-2003 Thomas Moestl wrote:
> > On Fri, 2003/06/27 at 14:01:45 -0400, John Baldwin wrote:
> >> On 27-Jun-2003 Thomas Moestl wrote:
> >> > On Fri, 2003/06/27 at 13:37:00 -0400, John Baldwin wrote:
On Fri, 2003/06/27 at 14:01:45 -0400, John Baldwin wrote:
> On 27-Jun-2003 Thomas Moestl wrote:
> > On Fri, 2003/06/27 at 13:37:00 -0400, John Baldwin wrote:
> >> On 13-Jun-2003 Thomas Moestl wrote:
> >> > This requires us to get this firmware property in the OF
On Fri, 2003/06/27 at 13:37:00 -0400, John Baldwin wrote:
> On 13-Jun-2003 Thomas Moestl wrote:
> > This requires us to get this firmware property in the OFW PCI bus
> > driver before routing the interrupt; that can't be done in the pcib
> > route_interrupt method, sinc
outines will want
to route an interrupt.
By moving the actual routing in a method which can be overridden, this
can be solved cleanly, while not complicating the generic PCI bus code
by much.
If there are no objections, I would like to commit this soonish.
Thoughts?
Thanks,
- Thomas
--
T
, I just noticed that, too. As far as I can tell, this is purely
historical, if I remember correctly mklocale did crash back then. I
will re-enable it.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http:
On Wed, 2002/01/30 at 07:02:25 -0800, User JHB wrote:
> When the DEADLKTREAT flag was added, uiomove() was broken. :) The
> problem is that a return() inside of a switch nested inside of a while
> loop was converted to a break leading to the following rather silly code:
>
>
On Fri, 2001/10/12 at 10:07:10 -0700, Matt Dillon wrote:
>
> :Mark,
> :
> :> I also placed some checks on vm_map_delete
> :
> :I did that also, and as far as I understand everything works fine.
> :The only thing I found was the fact that when contigmalloc() grabs the
> :contig pages it sets the v
Hi,
I've attached a patch that adds a functions for zone destruction to
the kernel zone allocator, which is needed to properly support the
unload case for modules that create zones (such as nfs.ko).
As a first application of this, it also patches the relevant nfs code
to destroy the internal nfs
Hi,
I want to add support for reading crash dumps to libdevstat. This will
allow iostat and vmstat to fully work on crashdumps (with some
additional patches).
To give this a reasonable interface, a kvm handle needs to be passed
to getnumdevs, getgeneration, getversion, checkversion and getdevs.
A
On Wed, 2001/07/11 at 11:04:56 -0700, Matt Dillon wrote:
>
> :
> :Thomas Moestl wrote:
> :>
> :> If it was an audio CD you were trying to mount: this is a known
> :> problem. The attached patch fixes it for me by disallowing reading of
> :...
>
> Tho
Hi,
I've just tripped over an obviously long-standing (since about
Jan. 1998) bug in vinvalbuf while looking into PR kern/26224. The
problematic code looks like (on -CURRENT):
/*
* Destroy the copy in the VM cache, too.
*/
mtx_lock(&vp->v_interlock);
if
On Sat, 2001/07/07 at 18:57:15 -0400, Paul Halliday wrote:
> FreeBSD dissent.p450.box 4.3-RC FreeBSD 4.3-RC #3: Sun Jun 10 22:27:47
> EDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/workstation
> i386
>
> FreeBSD useless.dell.box 4.3-STABLE FreeBSD 4.3-STABLE #6: Fri Jul 6
> 18:57:08 EDT 20
Hi,
the following is from sys/kern/kern_sysctl.c:
static int
sysctl_old_kernel(struct sysctl_req *req, const void *p, size_t l)
{
size_t i = 0;
if (req->oldptr) {
i = l;
if (i > req->oldlen - req->oldidx)
i = req->oldlen -
On Fri, Feb 02, 2001 at 02:28:29AM +0900, Hajimu UMEMOTO wrote:
> >>>>> On Thu, 1 Feb 2001 17:11:35 +
> >>>>> Tony Finch <[EMAIL PROTECTED]> said:
>
> dot> Thomas Moestl <[EMAIL PROTECTED]> wrote:
> >
> >Most kmem_read
On Tue, Jan 30, 2001 at 04:17:55PM -0800, Matt Dillon wrote:
>
> : VOP_SWAPACCOUNT(nbp->b_vp, nbp);
> : BUF_KERNPROC(nbp);
> : BUF_STRATEGY(nbp);
> :
> :Now, I have to define the vop in vm_swap.c, where I can get the area
> :index from the block number in a cle
On Tue, Jan 30, 2001 at 03:21:38PM -0800, Matt Dillon wrote:
> :vm.swapdev1.total (this is the one that is currently hard to get)
> You can't move swapinfo into the kernel as a sysctl unless you
> solve this problem. Traversing the radix tree is expensive enough
> that the entire sys
Hi,
I'm going to start working on making top work without setgid kmem.
Is anyone already doing this? I don't want to waste my time...
Most kmem_read calls are easy to replace (the variables are already
exported as sysctls), the only exception is nextproc (for which I might
add a sysctl, or ju
On Thu, Nov 30, 2000 at 08:25:15PM +0100, Frederik Meerwaldt wrote:
> I compiled my kernel with IPDIVERT IPFIREWALL and
> IPFIREWALL_DEFAULT_TO_ACCEPT and I set up only one rule:
> ipfw add divert natd all from any to any via isp0
> Then I started natd (at boot time):
> natd -unregistered_only -dy
X
On Mon, Nov 27, 2000 at 11:04:37AM +0600, Boris Popov wrote:
> On Sun, 26 Nov 2000, Thomas Moestl wrote:
>
> > Actually, the panic will occur after a simple forced unmount of the current
> > working directory and subsequent try to access "..". This is because
> :I think I have a sufficient fix for PR kern/19572. Could somebody please
> :Review/Comment this?
> :To quote:
>
> Looks reasonable to me! It certainly can't make things worse :-)
Could someone then please look into committing this?
TIA,
- Thomas
To Unsubscribe: send mail to [EM
Hi,
I think I have a sufficient fix for PR kern/19572. Could somebody please
Review/Comment this?
To quote:
> Description
> Executing cd ../cdrom from /cdrom directory after cycle of mount-umount-
> mount cycle causes trap 12 (page fault while in kernel mode) and hence
> causes kernel panic.
> I know, that x86 is big endian architecture
> but simple programm like this:
>
> #include
> #include
> main () {
> /* Are we little or big endian? From Harbison&Steele. */
> union
> {
> long l;
> char c[sizeof (long)];
> } u;
> u.l = 1;
> printf ("Litt
> As this is my first kernel patch, could someone please give it a quick
> look before I submit it, so that I can be sure that it contains no stupid
> glitches?
> [...]
> + bzero(&src, sizeof(src));
> + src.sin_family = AF_IN
Hi,
recently, I have written a kernel patch that makes sendmsg(2) honor
IP_RECVDSTADDR ancillary data on UDP sockets, so that the source address can
be set on a per-packet basis. This is very useful for servers that need to
use UDP and want to answer with the same source address a query went to.
26 matches
Mail list logo
