8, sp 0x7fdf161
> pc 0x133560, sp 0x7fdf3f1
> pc 0x405d3f94, sp 0x7fdf4b1
> done
I believe that the attached patch should fix that; the panic is not
sparc64-specific, and should occur on all file systems that do not
define a vop_getwritemount method.
- Thomas
--
On Mon, 2003/07/28 at 03:59:00 +0200, Thomas Moestl wrote:
> Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
> workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
> implementation:
>
> #define
violates the C99 aliasing rules.
An alternative is to type-pun via a union, which is also a bit ugly,
but explicitly allowed by C99. Patch attached (but only superficially
tested).
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
&l
s to the sparc64 build -
> > the same machine runs all the other -CURRENT tinderboxen except
> > powerpc.
>
> It does not only happen to sparc64. I've seen it fail for all but
> i386 and pc98, I think.
i386 and pc98 have failed too (random example: July 5).
- Thoma
On Wed, 2003/06/11 at 08:34:39 -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Thomas Moestl <[EMAIL PROTECTED]> writes:
> : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote:
> : > Thomas Moestl wrote this message on Wed,
On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote:
> Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200:
> > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote:
> > There's a similar problem with hme devices in some Netra models, and
&g
locations that aren't available.
> Some chipsets nerver trap, others only trap for type2 access (behind
> Bridges) and some always trap.
I don't have the standard handy, but from my reading of the Shanley
book, it seems that for the vendor ID register, a host bridge is
required to r
this why pciconf -r is returning 0x when reading the ebus
> and firewire parts of the SME2300BGA? Simply because it isn't in
> the ofw tree?
Could be. We just cannot handle devices without firmware nodes - we
don't know whether we can safely access them, cannot as
return (bus_generic_attach(dev));
> } else
This one looks good, please commit. The comment above is outdated, so
it might be better to just remove it completely.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y
ctually looks correct to me (but I could easily be wrong, since the
signal behaviour of pthreads seems to be quite complex).
The propagate test failure is due to problems in libc (failing to
use the underscored versions of functions overridden in libc_r). The
attached patch should fix that; Dani
27;re right; if allproc_lock happens to be contested in
fork1() (which can happen because it it is locked without Giant held
in some places, and because sleeping with an sx lock is allowed),
we'll go to sleep there, dropping Giant. This opens up a race, since
wait1() can now proceed until
my notebook, too - in my case, it was a
problem in the radeon driver which could be worked around by adding an
explicit "Modes" line in the used Display subsection in XF86Config,
like:
Section "Screen"
[...]
DefaultColorDepth 24
[...]
SubSection "Display&q
On Sun, 2003/02/09 at 14:39:36 +1100, Tim Robbins wrote:
> On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote:
>
> > On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
> >
> > > addr2line will usually point to the first line of a statement if it
n struct session is 0x14.
I haven't yet found out how that could happen though, this field is
never legitimatly NULL and the locking seems to be tight so that it
cannot be freed from under fork1().
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
Ms (so these are broken again by this patch).
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492
issing some very fast klicks. Since I do not
use the glidepoint overly much, I can live with that.
If your notebook has that problem too, I can supply a patch.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://pe
psycho_iommu_init(sc, 3);
} else {
/* Just copy IOMMU state, config tag and address */
sc->sc_is = osc->sc_is;
--
If that still doesn't help, you can further increase the constant to 4
or 5 (at the expense of another 64kB or 192kB of me
s mmu miss
> cpuid = 0;
> Debugger("panic")
> Stopped at Debugger+0x1c: ta %xcc, 1
Can you please cvsup again to pick up some changes that were made
yesterday and try again?
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de
On Sat, 2003/01/18 at 13:22:45 +0100, Thomas Moestl wrote:
> None of the two could have caused this panic. I would guess that it
> was caused by the alpha uma_small_alloc() implementation trying less
> hard to allocate a page than kmem_alloc() (i.e. it does not sleep at
> all). This
lementation trying less
hard to allocate a page than kmem_alloc() (i.e. it does not sleep at
all). This problem does also affect the ia64 and sparc64
uma_small_alloc() versions it seems.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<
> POSIX also specifies the errors EDESTADDRREQ, EACCES, another EINVAL for
> shut down sockets, and ENOBUFS. The last 3 "may" cause listen() to fail
> and the others (including the first EINVAL) "shall" cause it to fail.
EDESTADDRREQ seems to not be generated, inste
n appropriate callback
routine to process them and passing it to bus_dmamap_load().
The usb_mem.c will need some other changes to work on FreeBSD, since
our busdma code has diverged from NetBSD's quite a bit.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/
using a
> call other than listen()?
>
> That it causes a panic when the SYN cache is enabled isn't really
> a technical reason, it's a circumstantial reason.
The manpage change does not reflect the change in the patch :)
It should be:
[EINVAL]The sock
yncache however, a panic can be triggered
by normal ACK packets.
In your example, the listen is buried in the bowels of the RPC code.
The solution should be to reject the listen() with EINVAL (which seems
to be that standard-mandated error for connected sockets); patch
attached.
Any thought
> ${.TARGET} || \
+ [ $$? -ne 1 ] ; }
ex_noperl.c: ex_perl.c
- -unifdef -UHAVE_PERL_INTERP ${SRCDIR}/ex/ex_perl.c > ${.TARGET}
+ ! { unifdef -UHAVE_PERL_INTERP ${SRCDIR}/ex/ex_perl.c > ${.TARGET} || \
+ [ $$? -ne 1 ] ; }
CLEANFILES+= ex_notcl.c ex_noperl.c
-
nel pointer instead of a correctly formed
udev_t
- watch(8) assumed that FIONREAD takes a size_t *, when it really
takes just an int *
The last patch updates the manpage accordingly.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<
On Tue, 2002/09/03 at 20:32:48 +0200, Thomas Moestl wrote:
> On Tue, 2002/09/03 at 11:21:05 -0700, Matthew Dillon wrote:
> > I am also still somewhat worried about the data segment start address
> > and I am wondering if I should remove the if (data_addr == 0)
>
On Tue, 2002/09/03 at 15:11:06 -0400, John Baldwin wrote:
>
> On 03-Sep-2002 Thomas Moestl wrote:
> > On Tue, 2002/09/03 at 09:37:14 -0700, Peter Wemm wrote:
> >> Bernd Walter wrote:
> >> > On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote:
> >>
start because vm_dsize counts all data segments.
However, it has the advantage of making this real (non-workaround) fix
easy to implement, since no bookkeeping problems would occur when
shrinking just bss away (as no holes can be crossed).
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]
t the heap size
including holes which could then be used by obreak(), while vm_dsize
would only be used for statistics (which is however difficult to
maintain when shrinking below the initial size with brk()).
Can somebody who is feeling adventurous and has an alpha box please
test whether this fixe
between the first and last member of two struct foo's
immediately following each other must be _included_ in struct foo,
after the last element.
- thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people
zeof() and once in cmd_len.
So, sizeof(struct ip_fw) is no different between userland and kernel,
but the problem is that you don't use sizeof(struct ip_fw) in userland
to compute the sizes (but pointer arithmetic), but you do use it for
the checks in the kernel.
- thomas
--
Thomas Moes
On Sun, 2002/07/14 at 23:08:21 -0400, Mike Barcroft wrote:
> Thomas Moestl <[EMAIL PROTECTED]> writes:
> > (Disclaimer: my solution below is untested, so it may all be bogus)
>
> As request, here are the test results.
>
> Most rules work, except my final one:
> %
h other, so the total
structure size is a multiple of 8 (48 bytes). Because of that, no
padding after 'cmd' is required, and the effect is gone.
- thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> htt
((struct ip_fw *)(rule))->cmd_len * 4)
It also removes the explicit 4 for sizeof(ipfw_insn).
- thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E49
On Fri, 2002/03/08 at 11:23:36 -0800, Doug Barton wrote:
> 3. xconsole causes periodic panics. The problem (according to BDE) is "a
> well-know bug in printf(9)," caused by "The TIOCCONS ioctl ... panics when
> printf() is called while sched_lock is held." I reported this bug in
> October 2001, if
On Sun, 2001/10/14 at 21:38:26 +0100, Ian Dowse wrote:
> >
> >The last one is a know problem. There is a (unfinished) patch available to
> >solve this problem. Thomas Moestl <[EMAIL PROTECTED]> is still working on
> >some issues of the patch. Please contac
On Tue, 2001/05/29 at 09:39:42 -0700, John Baldwin wrote:
>
> On 28-May-01 Doug Barton wrote:
> > I forgot something:
> >
> > IdlePTD 4734976
> > initial pcb at 3b5f80
> > panicstr: mutex sched lock recursed at /usr/src/sys/kern/kern_synch.c:858
> > panic messages:
>
> I would need a traceback
On Sat, 2001/05/26 at 11:07:36 -0500, Michael Harnois wrote:
> I finally got this much. I hope it helps.
>
> lock order reversal
> 1st 0xc03af0a0 mntvnode @ ../../ufs/ffs/ffs_vnops.c:1007
> 2nd 0xc8b539cc vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
>
> recursed on non-recursive lock (sleep
On Wed, Apr 04, 2001 at 07:23:18PM +0200, Thomas Moestl wrote:
> src/lib/libposix1e was repocopied to src/lib/libc/posix1e, and I'll
> start to commit the necessary patches now and will then activate the
> build.
>
> World may be broken during a short interval due to the swi
src/lib/libposix1e was repocopied to src/lib/libc/posix1e, and I'll
start to commit the necessary patches now and will then activate the
build.
World may be broken during a short interval due to the switch. You
will also need to rebuild anything that uses libposix1e. In the base
system, those are
On Fri, Mar 30, 2001 at 06:36:51PM -0400, The Hermit Hacker wrote:
>
> how does one fix this? *puzzled look* there is no ssl(8) that I can seem
> to find to See, and nothing apparent in the UPGRADING file ... system
> uptodate as of last night, and mergemaster just finished completing ...
>
> s
On Fri, Mar 30, 2001 at 07:38:30PM +0200, Falco Krepel wrote:
> I have implemented good ideas from Mike Smith in my
> rc.diskless{1,2} files and make some other changes:
>
> 1. Now I use the kernel flag "vm.nswapdev" to determine if swap is
> available.
Just a note - this might go away soon beca
On Wed, Feb 28, 2001 at 01:55:15AM +0100, Thomas Moestl wrote:
> On Wed, Feb 28, 2001 at 01:17:12AM +0100, Martin Blapp wrote:
> > Thomas Moestl and I tried to fix linux_connect. Most of this patch
> > is from Thomas Moestl. I did only a little part of it and testing.
> >
On Wed, Feb 28, 2001 at 01:17:12AM +0100, Martin Blapp wrote:
> Thomas Moestl and I tried to fix linux_connect. Most of this patch
> is from Thomas Moestl. I did only a little part of it and testing.
>
> Staroffice5.2 has been broken about one year now, and it needs
> a fi
45 matches
Mail list logo
