On Tue, Oct 4, 2011 at 2:19 AM, Adrian Chadd wrote:
> On 4 October 2011 05:53, Maxime Henrion wrote:
>
>> Great, that's a relief. I knew the pthread library was free to wake a
>> thread up even if it hadn't been signaled, which is why one always has
>> to ca
On Mon, Oct 3, 2011 at 11:30 PM, Jilles Tjoelker wrote:
> On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
>> Knowing all that, what's happening seems quite clear. If
>> fixups_close() is called while there was still fixup requests pending,
>> those
On Mon, Sep 19, 2011 at 8:26 AM, Adrian Chadd wrote:
> 2011/9/19 Alexander Zagrebin :
>
>> I've tried this patch. Now csup "hangs" before handling fixups.
>> So there is no message "Applying fixups..." at all.
>
> Wow. Hm. Where's the author when one needs them..
Well that's quite a strange coinc
Mathew Kanner wrote:
[patch ripped]
>
> Maxime,
> I think it would be better to isolate the changes (DUP_OK flag
> and lock creation) to just the channel code, no need to touch every
> driver.
Yes, but to do this I'd need either to make the channel code use
mtx_init() directly, which
Jesse Guardiani wrote:
> Jesse Guardiani wrote:
>
> > I get this every time I `startx`. I didn't see it in
> > the archive either:
> >
> >
> > acquiring duplicate lock of same type: "pcm channel"
> > 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:144
> > 2nd pcm0:virtual:0 @ /usr/src/sys
Terry Lambert wrote:
> Stefan Farfeleder wrote:
> > On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
> > > From: "Jacques A. Vidrine" <[EMAIL PROTECTED]>
> > > > The application is broken. You must only check errno if you get an
> > > > error indication from the library call.
> > >
>
Sean McNeil wrote:
> Yes, thanks for the clarification. I still am inclined to believe,
> though, that the disk driver is what is fragmenting the physical memory
> with disk cacheing. It is only a theory, but it sounded plausible.
Maybe, but the root cause is not the disk caching. It may be tha
Sean McNeil wrote:
> Hi everyone,
>
> I was wondering if there is a way to flush out pages in memory that
> might not be required. I have a device driver that allocates 16 distict
> buffers each 32K in size. This is done with a bus_dma call as they will
> be accessed by a PCI device. The proble
Christian Laursen wrote:
> Maxime Henrion <[EMAIL PROTECTED]> writes:
>
> > Christian Laursen wrote:
> > > By accident, I tried to mount a CD as UDF, and got the follwoing panic:
>
> [snip]
>
> > Can you try the attached patch and tell me if it fixes y
Christian Laursen wrote:
> By accident, I tried to mount a CD as UDF, and got the follwoing panic:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer =
Eirik Oeverby wrote:
> As a side note/question:
> Is there any way to figure out which ULE version I'm running in a
> precompiled kernel? I just nuked my src tree by accident, and am not
> sure if i'm on 1.65 or something older..
>
> If there is no way, is this perhaps an idea?
Try "ident /boot
[EMAIL PROTECTED] wrote:
> After successful cvsup of complete system sources on 08.20.2003 around
> 04:00, and a successful make buildworld, make builkernel failed with the
> following:
>
> cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric
> t-prototypes -Wmissing-p
Tinderbox wrote:
> TB --- 2003-07-11 16:00:01 - starting CURRENT tinderbox run for alpha/alpha
> TB --- 2003-07-11 16:00:01 - checking out the source tree
> TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
> TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
> TB --- 2003-07-11 16:08:43 -
Mark Murray wrote:
> Maxime Henrion writes:
> > > Can you have a look at this please?
> > >
> > > The symptoms are an ep0 that works for a few packets and then
> > > completely stops working. It doesn't respond to pings, nothing.
> >
> > I
Mark Murray wrote:
> Hi
>
> Since your last round of changes to if_ep.c (up to 1.117), the pccard ep0
> on my ToPIC97 based laptop is broken.
>
> I've chatted to Warner about this, and I have a local hack where I back
> out a fix of his, and this allows the ep0 device to work (I think he said
> t
Wilko Bulte wrote:
> On Sat, Jul 05, 2003 at 04:07:26PM +0200, Maxime Henrion wrote:
> > Wilko Bulte wrote:
> > >
> > > Could it be there is something fishy with mbuf handling?
> >
> > Could you please try the attached patch? It's absolutely untested
Hi all,
I've been converting the dc(4) driver to the busdma API, which is a
necessary step before having it working on sparc64. Given that this
driver supports many different chipsets, and that I only have one of
these cards, it would be very helpful if people could test this patch
and r
Sergey A. Osokin wrote:
> On Sat, Jun 28, 2003 at 04:41:13PM +0200, Maxime Henrion wrote:
> > Sergey A. Osokin wrote:
> > > On Sat, Jun 28, 2003 at 10:09:13AM -0400, Justin Ma wrote:
> > > > This is what I did for a quick fix:
> > > >
> > &
Sergey A. Osokin wrote:
> On Sat, Jun 28, 2003 at 10:09:13AM -0400, Justin Ma wrote:
> > This is what I did for a quick fix:
> >
> > In sys/dev/ray/if_ray.c, comment out the line:
> >
> > #include
> >
> > and add the lines
> >
> > #include
> > #include
> >
> > Just like Sam did
walt wrote:
> Poul-Henning Kamp wrote:
>
> >I have uploaded a proof of concept patch:
> >
> > http://phk.freebsd.dk/patch/fd_dev.patch
>
>
> >...And with this code enabled, it is possible to go from userland to
> >device driver without touching Giant underway.
>
> I'm sorry, I can't parse t
Pawel Jakub Dawidek wrote:
> On Sat, Jun 14, 2003 at 02:28:33AM -0400, Robert Watson wrote:
> +> If you have the kernel.debug for this kernel, could you send the gdb -k
> +> output of:
> +>
> +> l *in6_pcbbind+0x2a7
>
> I've looked at objdump -d kernel, and it looks like this is somewhere here:
Hi all,
I was finally able to reproduce the problems people have been reporting.
That is, the fxp(4) card works but there are many odd "unknown: DMA
timeout" and "unknown: device timeout" messages. This was due to a bug
in fxp(4) which was harmless unless you used DEVICE_POLLING. These
Conrad Sabatier wrote:
>
> On 04-Apr-2003 Maxime Henrion wrote:
> > Conrad Sabatier wrote:
> >> Having had the same experiences as others described here recently with
> >> the
> >> fxp stuff, I'm just wondering if it's safe now to cvsup and try
Hi all,
Robin P. Blanchard wrote:
> Following sources still yield unresponsive fxp interface. The same behavious
> occurs on both of my test boxes (dell 4350 and home-grown athlon xp), each
> having identical Intel Pro 100+M nics with v4.1.0.9 intel PXE rom.
>
> # fgrep -h \*\ \$FreeBSD
Conrad Sabatier wrote:
> Having had the same experiences as others described here recently with the
> fxp stuff, I'm just wondering if it's safe now to cvsup and try it again.
> I only have one machine here and if my net interface fails, I'm totally
> screwed. :-)
It should. If it doesn't, I'm
Nate Lawson wrote:
> I have gotten fxp running with MPSAFE and did a large scp transfer. It
> ran for a few minutes and then paniced. It was trap 12 (page fault) at
> address 0x24. Here is where it crashed:
>
> fxp_start+0xcc
> 0xc0194a4c is in fxp_start (../../../dev/fxp/if_fxp.c:1263).
> 1258
Pete Carah wrote:
> This may be just my infamous vaio acting up again, but since the
> recent commit to fxp driver (Monday?) I get a panic on device probe
> (page fault in kernel mode).
This should be fixed in revision 1.30 of if_fxpreg.h that I committed
some time ago. Sorry for the inconvenien
Daniel C. Sobral wrote:
> Peter Wemm wrote:
> >"Daniel C. Sobral" wrote:
> >
> >>It seems recent current doesn't like my fxp. A current from some 10
> >>hours ago keeps complaining about device timeout and dma timeout. I
> >>don't *know* it's fxp fault (for one thing, because it says "unknown"),
Andrew Gallatin wrote:
>
> I'm seeing the following panic under heavy NFS client usage on an SMP
> w/kernel sources from Weds. evening. Has this been fixed?
If I'm not mistaken, this is the problem Jeff fixed in revision 1.134 of
vfs_cluster.c.
Cheers,
Maxime
To Unsubscribe: send mail to [EMAI
Garance A Drosihn wrote:
> At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote:
> >
> >By adding that #warning, you are going to have a compile-time error
> >on some compilers, whether or not you want it. Hiding it inside of
> >an #if/#endif will help for some compilers, but not on all of them.
>
>
Maxime Henrion wrote:
> walt wrote:
> > My mini 'disaster' of earlier today was caused by the nvidia kernel
> > module being autoloaded at boot, which causes an immediate kernel panic.
> >
> > The newest kernel seems fine until I try to load the module manual
walt wrote:
> My mini 'disaster' of earlier today was caused by the nvidia kernel
> module being autoloaded at boot, which causes an immediate kernel panic.
>
> The newest kernel seems fine until I try to load the module manually,
> at which time I still get the kernel panic even after re-compilin
Hi all,
I've updated the patch for the nVidia drivers to fix the VM locking
issues. It makes it possible (at least for me) to use this driver even
when I compiled the assertions check in my kernel with the INVARIANTS
option. I doubt this fixes other bugs than the assertions failing
beca
Jake Burkholder wrote:
> Apparently, On Tue, Feb 25, 2003 at 10:49:16PM +0100,
> Maxime Henrion said words to the effect of;
>
> > Morten Rodal wrote:
> > > On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
> > > [snip a lot of the
Morten Rodal wrote:
> On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
> [snip a lot of the patch]
> > @@ -1431,7 +1442,8 @@
> > SLIST_FOREACH(at, &sc->alloc_list, list) {
> > if (offset >= at->address &&
> &g
Hi all,
Recent interface changes made the nVidia driver unbuildable on -CURRENT.
The attached patch should make it work as it used to. Please let me
know if it doesn't.
Cheers,
Maxime
diff -u NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.h nvidia/src/nv-freebsd.h
--- NVIDIA_FreeBSD-1.0-3203/sr
Nick H. -- Technical Support Engineer wrote:
> Ive run into the exact same problem on about 8 machines now, all running
> different network cards. The network will just simply not work if I have
> IPFILTER built into the kernel. On some of the machines, I started getting
> "No route to host". Th
Hiten Pandya wrote:
> Hello everyone. This not something major, but I recently experienced
> panics in some of my old QNX4 filesystem porting code, and an old 5.0
> kernel with UNIONFS problems.
>
> The kernel will panic if vfs_get/copyopt() was passed 'opts' as NULL.
> It would be good to add KA
Josef Karthauser wrote:
> On Wed, Jan 15, 2003 at 10:58:04PM +0100, Thomas Moestl wrote:
> >
> > DMAADDR is:
> >
> > #define DMAADDR(dma, o) ((dma)->block->map->dm_segs[0].ds_addr + (dma)->offs +
>(o))
> >
> > struct usb_dma_block starts like:
> >
> > typedef struct usb_dma_block {
> >
Josef Karthauser wrote:
> I've partially ported the NetBSD busdma code for USB to FreeBSD, but
> it doesn't compile, probably for a trivial reason.
>
> Anyone fancy helping me out?
I didn't look at the patches yet, but could you give me the compilation
error you are getting ?
Cheers,
Maxime
To
Nate Lawson wrote:
> Attached is a diff that fixes a "could sleep" problem where
> ether_ifattach() does a malloc and dc(4) is holding a lock in its softc.
> It uses a cleaner exit strategy with only one call to DC_UNLOCK and no
> multiple return statements as well as fixing one place where "erro
Pawel Jakub Dawidek wrote:
> Hello.
>
> Initiated mutex for prison isn't destroyed on error.
> Kernel will on every error.
I just committed your patch, thanks!
Cheers,
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Matthew Dillon wrote:
> :I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
> :at module load time using a kernel environment variable. Looks to me
> :that it would do what you want.
>
> No, this isn't what I want. I want something that can be articulated
> without
Matthew Dillon wrote:
>
> :
> :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
> :> then, as usual, IPFW with the new kernel and
> :> old world fails utterly and now the fragging machine can't access the
> :
> :Hear hear!! I am >< tempted to have /sbin/ipfw moved to src/sy
Doug Barton wrote:
> The native nvidia drivers work great in RELENG_4 with my geforce 4 mmx,
> but in -current they hate me. I just upgraded to the latest -current and
> I'm using XFree compiled on -current, no joy. It's always the same error:
>
> panic: bremfree: bp 0xc7751bb8 not locked
This is
Craig Reyenga wrote:
> Yesterday I installed 5.0-DP2 without problems, however my 100mbit link
> to my desktop computer goes extremely slowly using HTTP, FTP or SMB and
> proabably others. I used to be able to tranfer files using FTP at over
> 7.9MB/sec in 4.7 but now the best that I can do is 8
Emiel Kollof wrote:
> * Emiel Kollof ([EMAIL PROTECTED]) wrote:
> > > There were stupid mistakes in this patch. Can you try this one instead ?
> >
> > Yes, this one seems to work.
>
> Hold on.. now remote hosts _see_ the ext2fs share, but mounting will not
> work. Yes it will mount without fail
Emiel Kollof wrote:
> * Maxime Henrion ([EMAIL PROTECTED]) wrote:
> >
> > There were stupid mistakes in this patch. Can you try this one instead ?
>
> Yes, this one seems to work.
I'm also interested in the panic you got with the previous broken patch.
What was th
Maxime Henrion wrote:
> Emiel Kollof wrote:
> > * Juli Mallett ([EMAIL PROTECTED]) wrote:
> >
> > > > kernel: ext2fs doesn't support the old mount syscall
> > > > mountd[344]: could not remount /storage: Operation not supported
> > >
> &
Emiel Kollof wrote:
> * Juli Mallett ([EMAIL PROTECTED]) wrote:
>
> > > kernel: ext2fs doesn't support the old mount syscall
> > > mountd[344]: could not remount /storage: Operation not supported
> >
> > I have the same problem, more or less, with UFS :( I can no longer set up
> > an NFS server,
John Baldwin wrote:
>
> On 22-Nov-2002 Juli Mallett wrote:
> > * De: Robert Watson <[EMAIL PROTECTED]> [ Data: 2002-11-21 ]
> > [ Subjecte: Re: VM locking problem... And doscmd(8) ]
> >> On Thu, 21 Nov 2002, Juli Mallett wrote:
> >>
> >> > I'm getting a giant owned assertion failure in the
Mike Barcroft wrote:
> --
> >>> Kernel build for GENERIC started on Fri Nov 15 14:04:21 GMT 2002
> --
> ===> ipfilter
> cc1: warnings being treated as errors
> /tinderbox/sparc64/
Marcel Moolenaar wrote:
> On Tue, Nov 05, 2002 at 03:46:24PM -0800, Maxime Henrion wrote:
> [snip]
> > > > That's arguably bad, sys/uuid.h shouldn't have any !_KERNEL prototypes
> > > > in it.
> > >
> > > If there's a better place,
Marcel Moolenaar wrote:
> On Tue, Nov 05, 2002 at 03:17:24AM -0800, Maxime Henrion wrote:
> > Juli Mallett wrote:
> > > * De: Maxime Henrion <[EMAIL PROTECTED]> [ Data: 2002-11-05 ]
> > > [ Subjecte: Re: uuid.h is not C++ safe ]
> > > > Maxime He
Juli Mallett wrote:
> * De: Maxime Henrion <[EMAIL PROTECTED]> [ Data: 2002-11-05 ]
> [ Subjecte: Re: uuid.h is not C++ safe ]
> > Maxime Henrion wrote:
> > > Patrick Hartling wrote:
> > > > I was just about to put the new DCE 1.1 UUID functions
Maxime Henrion wrote:
> Patrick Hartling wrote:
> > I was just about to put the new DCE 1.1 UUID functions into use in some
> > C++ code, but linking fails because the function prototypes in uuid.h
> > are not protected with the __cplusplus/extern "C" bits. It&#
Patrick Hartling wrote:
> I was just about to put the new DCE 1.1 UUID functions into use in some
> C++ code, but linking fails because the function prototypes in uuid.h
> are not protected with the __cplusplus/extern "C" bits. It's easy
> enough for me to fix my local copy, but I'm sure this s
Lars Eggert wrote:
> Hi,
>
> just got this when trying to umount a media from an USB CF reader:
>
> /usr/src/sys/kern/kern_synch.c:146: sleeping with "mountlist" locked
> from /usr/src/sys/kern/vfs_mount.c:1321. I have a core dump, but it's of
> the second panic.
Could you tell us what's the r
Matthias Schuendehuette wrote:
> Hi,
>
> I updated my kernel now just like told in the last HEADSUP and hesitate
> to do a 'make installworld' as also mentioned there...
>
> Now, during boot 'ipfw' complaines:
>
> ipfw: size mismatch (have 64 want 1064)
> ipfw: size mismatch (have 52 want 40)
>
Terry Lambert wrote:
> Brooks Davis wrote:
> > This isn't going to have an effect on the ability to use kernel ppp for
> > other things. The tty orientation of pppd and the outdated, unmodular
> > design on ppp(4) have taken care of that. This patch gives people
> > the functionality they want (p
Dennis Kristensen wrote:
> Hi!
>
> Looks like kernel is broken without the bellow patch.
The below patch is incorrect, I just forgot to commit changes to
ip_fw.h. This should be fixed now.
Cheers,
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the b
Vitaly Markitantov wrote:
> When i tries to copy a file from smbfs share mounted by mount_smbfs
> i get an error:
> cp: ./filename: Bad address
>
> But when i copy a file to share i get kernel panic like this:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address=
Hello all,
I got ipfw2 apparently working on my sparc64 box. I simply added
new fields in the structure of the rules to avoid the evil casting.
Of course, it breaks the ABI, so ipfw(8) must be rebuilt. Also,
this may be considered bloat since I didn't use unions or anything,
but I think
Dag-Erling Smorgrav wrote:
> ===> vinum
> cc1: warnings being treated as errors
> /h/des/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
> /h/des/src/sys/ufs/ffs/ffs_snapshot.c:531: warning: int format, different type arg
>(arg 2)
> *** Error code 1
Should be fixed now.
Maxime
To U
Bruce Evans wrote:
> On Wed, 9 Oct 2002, Maxime Henrion wrote:
>
> > What I meant in my previous mail is that you could malloc() these
> > objects instead of putting them on the stack. Also, you don't need
> > buffers that big since the size you need
Maxime Henrion wrote:
[...]
> > > > - There is a TOK_STRING_SIZE macro which defines the size of the the
> > > > db_tok_string variable. Use it instead of declaring several 1k
> > > > variables on the stack.
> > >
> > > It is not tok
Vladimir B. Grebenschikov wrote:
> ? Wed, 09.10.2002, ? 01:03, Vladimir B. Grebenschikov ???:
> > ? Tue, 08.10.2002, ? 22:25, Maxime Henrion ???:
> > > Vladimir B. Grebenschikov wrote:
> > > > Hi
> > > >
> > > > Attached diff int
Vladimir B. Grebenschikov wrote:
> Hi
>
> Attached diff introduces new ddb interface - access to sysctl interface
[...]
Looks like this would be very useful. I have a few comments, mainly
about style though.
- There is a TOK_STRING_SIZE macro which defines the size of the the
db_tok_strin
attila! wrote:
> Sent: Mon, 16 Sep 2002 20:39:05 -0700 by David O'Brien
> +
> + On Tue, Sep 17, 2002 at 12:17:14AM +, attila! wrote:
> + >
> + > The price is right on the 395U[W]: $41/52 and it is
> + > their newer series which uses a "TekRam 1040" chip.
> + > Has anyone used it on
Bruce Evans wrote:
> > cc1: warnings being treated as errors
> > /local0/src2/sys/dev/ccd/ccd.c: In function `ccdiodone':
> > /local0/src2/sys/dev/ccd/ccd.c:1181: warning: long long int format, daddr_t arg
>(arg 6)
> > *** Error code 1
>
> This is a routine printf format error. %lld format shou
Maxim Sobolev wrote:
> Maxime Henrion wrote:
> >
> > Maxim Sobolev wrote:
> > > Any ideas?
> >
> > Looks like some other processes was modifying the mountlist while
> > vfs_unmountall() was running. Is this an SMP box ?
>
> No, it's UP.
Maxim Sobolev wrote:
> Any ideas?
Looks like some other processes was modifying the mountlist while
vfs_unmountall() was running. Is this an SMP box ? It would be nice if
you could check in gdb which other process was holding the mountlist_mtx
mutex if any. The vfs_unmountall() function doesn'
Dag-Erling Smorgrav wrote:
> --
> >>> stage 4: building everything..
> --
> ===> sbin/fsck_ffs
> cc1: warnings being treated as errors
> /usr/home/des/tinderbox/sparc64/src/sbin/
Don Lewis wrote:
> I recently started seeing the warning message:
>
> /usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel linker" locked
> from /usr/src/sys/kern/kern_linker.c:1797
>
> at boot time on my -current box. It appears to be related to the
> changes in rev 1.90 of kern_linker.c.
Jeffrey Hsu wrote:
> Can you try this fix instead? It's based on a similar patch Jonathan Lemon
> sent to me for a similar spot in tcp_subr.c.
Well yes, this works too, since it produces the same code as with my
fix. But yours is more beautiful. :-)
Thanks,
Maxime
To Unsubscribe: send mail to
Maxime Henrion wrote:
> Hi all,
>
>
> I just fixed a bug that has been hitting me everytime I do a sysctl -a
> since inp locking was committed.
BTW, this bug probably only arises when the security.bsd.see_other_uids
sysctl is set to 0, otherwise the cr_canseesocket() call
Hi all,
I just fixed a bug that has been hitting me everytime I do a sysctl -a
since inp locking was committed. I would like to commit it as soon as
possible, so I'd like it if someone could review it.
Thanks,
Maxime
Index: udp_usrreq.c
===
Terry Lambert wrote:
> What exactly does this do, besides implying "-fno-builtin"?
>
> The documentation says "and implies main has no special requirements"...
>
> Neither the kernel nor modules have a "main", so the only thing that's
> relevent here is the "-fno-builtin", right?
IIRC, -ffreest
Hi all,
I recently noticed that we are adding the -ffreestanding flag twice for
kernel builds. It's added once if GCC3 is defined in
/usr/share/mk/bsd.kern.mk and another time inconditionally in
/sys/conf/kern.pre.mk. As a result, I have -ffreestanding once on my
x86 box still running
Ade Lovett wrote:
> Could we have a __FreeBSD_version bump for the diking out of perl from the
> base system please? A chunk of ports work needs to be done to conditionally
> use perl vs sed for in-line replacements on lots of Makefiles.
I agree that a __FreeBSD_version bump is appropriate, but
Szilveszter Adam wrote:
> Hello,
>
> src/sbin/savecore.c has been broken today, with the commit of rev 1.59
> by Bill Fenner.
This is fixed in revision 1.4 of src/sys/sys/kerneldump.h.
Cheers,
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body
the kernel since it tries mount() before nmount(). Once these commits
are done, I'll change the order of the calls to get rid of these
warnings. I will still keep the mount() call for some time, in the case
there are external filesystems using mount_std.
Thanks for your attention,
Maxime Henrion
Peter Wemm wrote:
> This turned out to be part of the problem. I committed your patch and
> another followup that got the rest of it. The outstanding problems were:
> 1) checkmethod caused use_kenv to be set only once and the next time it
> was called, use_kenv would stay at zero and static hint
Hi,
I think I may have found the bug. Could someone test the attached patch
and report if it fixes the problem or not ?
Thanks in advance,
Maxime
Index: subr_hints.c
===
RCS file: /space2/ncvs/src/sys/kern/subr_hints.c,v
Alexander Kabaev wrote:
>
> Hint: Now if only someone could commit it ...
Done, thanks.
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Alexander Kabaev wrote:
> Calling freeenv with the pointerm different from one received from
> getenv seldom is a good idea :)
[...]
Indeed. Sorry for this yet another freeenv() breakage ; this patch
looks good.
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cu
Hajimu UMEMOTO wrote:
> Hi,
>
> >>>>> On Sun, 17 Mar 2002 15:38:48 -0800
> >>>>> Maxime Henrion <[EMAIL PROTECTED]> said:
>
> mux> Actually, this patch is wrong because it won't ever compile des_enc.S.
> mux> Whatever I do, de
Hajimu UMEMOTO wrote:
> Hi,
>
> >>>>> On Sat, 16 Mar 2002 01:32:04 -0800
> >>>>> Maxime Henrion <[EMAIL PROTECTED]> said:
>
> mux> Since the addition of optimized 3DES encryption for x86, the build of the
> mux> smbfs kernel module
Hi,
Since the addition of optimized 3DES encryption for x86, the build of the
smbfs kernel module has been broken (on all platforms). This is because
new files are now needed (des_enc.S for x86, des_enc.c for other
archs). The attached patch fixes this problem.
Reviews would be apprec
Maxim Sobolev wrote:
>
> Bah, just completed `make world' after doing `make includes' and found
> that I can't login as *any* user, not only root!!! Login just
> hangs after entering password and nothing goes on. DES! PLEASE FIX
> THAT FSKING PAM - within a very short timeframe it's the second
Jan Stocker wrote:
> Sources from: Dec, 26 11:28 CET
>
> linking kernel
> procfs.o: In function `procfs_init':
> procfs.o(.text+0x1ac): undefined reference to `pfs_create_link'
> procfs.o(.text+0x1c0): undefined reference to `pfs_create_dir'
> procfs.o(.text+0x1db): undefined reference to `pfs_c
Joerg Wunsch wrote:
> Maxime Henrion <[EMAIL PROTECTED]> wrote:
>
> > I looked at the code a bit more closely and you're entirely right. I
> > think I figured out why my patch caused a core dump. Here is a more
> > correct patch that should fix the
Mikko Tyolajarvi wrote:
> In local.freebsd.current you write:
>
> >On Mon, Nov 26, 2001 at 12:07:22AM +0100, Maxime Henrion wrote:
> >> If my patch is exact, then the bug should manifest itself only if there
> >> are no network filesystems mounted. Do you have
440 100%/proc
> /dev/md10c 520140 24 478508 0%/tmp
[...]
If my patch is exact, then the bug should manifest itself only if there
are no network filesystems mounted. Do you have any network fs mounted
on your box ?
Thanks,
Maxime Henrion
--
filesystems but thinks all of them are non-local and
> ignores them.
> Using sysctl -a I could not find any entries which looked vaguely like
> describing a mount..
>
> Paul
Could you please test the attached patch ? I did it in a hurry but it
may fix the problem.
Thanks,
Maxime
.])..
First, locate the faulting part of code, then just modify it so that it
enforces the established lock order. The way to fix it is somewhat
obvious, but it may indeed be very hard in some cases.
Good luck,
Maxime Henrion
--
Don't be fooled by cheap finnish imitations ; BSD is the
h Vahalia to be a very good book on
this topic.
Hope this helps,
Maxime Henrion
--
Don't be fooled by cheap finnish imitations ; BSD is the One True Code
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ou do not want to see these
warnings, remove ``options WITNESS'' from your kernel conf or patch the
code to solve the problem :-)
Regards,
Maxime Henrion
--
Don't be fooled by cheap finnish imitations ; BSD is the One True Code
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &qu
Maxim Sobolev wrote:
> Alexander Leidinger wrote:
>
> > Hi,
> >
> > I can't access the audio hardware anymore.
> >
> > after a fresh boot:
> > ---snip---
> > % cat /dev/sndstat
> > FreeBSD Audio Driver (newpcm) Jun 27 2001 16:27:06
> > Installed devices:
> > pcm0: at io 0x220 irq 5 drq 1:5 (1p/1
99 matches
Mail list logo
