At 13:34 19/10/2002, Ben Stuyts wrote:
At 04:15 19/10/2002, Alfred Perlstein wrote:
* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote:
> semop() leaks memory. An important free() was removed by alfred in
> rev 1.55. Try this.
Seriously, I just checked in slightly differen
At 04:15 19/10/2002, Alfred Perlstein wrote:
* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote:
> semop() leaks memory. An important free() was removed by alfred in
> rev 1.55. Try this.
Oh' c'mon, isn't MP-safeness a bit more important than a some
little memory leak, ram is cheap! pro
Terry,
At 23:07 18/10/2002, you wrote:
Ben Stuyts wrote:
> Furthermore, this might be interesting: the last vmstat -m log
> before the panic. Maybe someone can check if these values are reasonable?
> The system has 64 MB memory and has been up for about 24 hrs with almost
This is a repost. Forgive me if you see it twice, but it didn't turn up in
the -current list.
Hi,
Just had another panic, same kmem_malloc(). I did a trace but forgot to
write the traceback down. In any case, there was a semop() call in the
traceback. Furthermore, this might be interesting: th
he likes of new-midi.
# When used with 'device pcm' they also provide pcm sound services.
#
# sbc: Creative SoundBlaster ISA PnP/non-PnP
# Supports ESS and Avance ISA chips as well.
# gusc: Gravis UltraSound ISA PnP/non-PnP
# csa: Crystal Semiconductor CS461x/428x PCI
# For non-
Hello Alfred,
On Wed, Oct 16, 2002 at 02:26:19PM -0700, Alfred Perlstein wrote:
> * Ben Stuyts <[EMAIL PROTECTED]> [021016 14:05] wrote:
> >
> > No need to wait for tomorrow. :-) Just 1.5 hours later, vmstat -m says:
> >
> > < sem167344
At 22:00 16/10/2002, Jeff Roberson wrote:
>On Wed, 16 Oct 2002, Ben Stuyts wrote:
>
> > I'll also run your vmstat script that you posted in a similar thread. One
> > of the big memory users seems to be sem, and it's growing. Almost every
> > time I do a vmst
At 21:20 11/10/2002, Terry Lambert wrote:
>Please find a (relatively bogus) patch attached, which could cause
>things to block for a long time, but will avoid the panic.
Terry,
I just got the same panic without your patch. (I wanted to verify that it
was still panic-ing with the latest src tree
At 00:23 11/10/2002, Terry Lambert wrote:
>Robert Watson wrote:
> > I've run into this on a couple of boxes, but those boxes were diskless
> > root boxes, and used md backed ffs for /tmp and /var. Apparently if you
> > do that, you're likely to exceed the kernel's auto-tuned kmem map size.
> > Th
At 23:55 10/10/2002, Robert Watson wrote:
>On Thu, 10 Oct 2002, Ben Stuyts wrote:
>
> > panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
>I've run into this on a couple of boxes, but those boxes were diskless
>root boxes, and used md backe
Hi,
A couple of days ago I reported a panic, which I just got again:
panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
I don't know where to start looking for this, so I'd appreciate some help.
This is on a lightly loaded server. I've pasted the dmesg below. Latest
cvsup
Hello,
At 09:06 06/10/2002, Mikhail Teterin wrote:
>... 218222592 total allocated
>
>this machine has a total of 512Mb of RAM, and no swap.
>No X was running. Just ``cvs update''-ing.
I got this also a couple of times over the last week. It would panic every
few days with this same message. I c
Hi,
I updated my -current system yesterday, and I see a few lock order reversals.
This one happens during booting:
Apr 18 16:35:40 <0.2> terminus kernel: lock order reversal
Apr 18 16:35:40 <0.2> terminus kernel: 1st 0xc5ecbbb8 xl0 (network driver)
@ /var/src/sys/pci/if_xl.c:1260
Apr 18 16:35:
Hi,
Out of curiousity I plugged a webcam in my -current box. After browsing the
mailing lists and the net for a while I found that there has been talk here
about a usb driver for webcams based on this VLSI Vision CPiA chip. This is
the message the webcam generates after plugging it in:
Feb 28
On Sat, 13 Feb 1999, "Kenneth D. Merry" wrote:
> > (cd1:ahc0:0:5:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
> > (cd1:ahc0:0:5:0): NOT READY asc:4,0
> > (cd1:ahc0:0:5:0): Logical unit not ready, cause not reportable
> > cd1 at ahc0 bus 0 target 5 lun 0
> > cd1: Removable CD-ROM SCSI-
On Sat, 13 Feb 1999, "Chris D. Faulhaber" wrote:
> Interesting, this happens to both my CDR and regular CD:
>
> cd0 at ahc0 bus 0 target 3 lun 0
> cd0: Removable CD-ROM SCSI-2 device
> cd0: 10.0MB/s transfers (10.0MHz, offset 15)
> cd0: Attempt to query device size failed: NOT READY, Medium not p
On Sat, 13 Feb 1999, "Chris D. Faulhaber" wrote:
> > cd1: Attempt to query device size failed: NOT READY, Logical unit not
> > ready, cause not reportable
> There is no CD in the drive, which makes the device 'not ready' and therefore
> unable to query device size.
>
> If you put a CD in the driv
I've been getting the following message, usually within a minute or so after
booting. It shows up only once, and doesn't seem to interfere with normal
operation of the CDR:
(cd1:ahc0:0:5:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(cd1:ahc0:0:5:0): NOT READY asc:4,0
(cd1:ahc0:0:5:
Hello,
Would it be possible to add a "make update" target to the top Makefile in
ports and doc? Similar to the Makefile in /usr/src, so that it does something
like "cvs -q update -P -d".
It would keep the Makefiles more orthogonal, and in any case, make update
types easier than cvs -q updat
19 matches
Mail list logo
