Dose anybody install sound card Diamond Monster Sound II (based on Aurel
VORTEX chipset) and make it propertly work ?
Tell me how you did it, pls!
--
Mike Ju. Volkov AKA Commander
[EMAI
I think I'm up to date :) ... Unfortunately I won't be able to try out
your fix until this evening :( ...
Cheers,
Andrew.
--
$ ident swap_pager.c
swap_pager.c:
$Id: swap_pager.c,v 1.121 1999/07/16 05:11:35 alc Exp $
$ grep BUF_KERNPROC swap_pager.c
BUF_KERNPROC(bp);
[on IDE bus lockups]
I found that my IDE cdrom regularly caused lockups of FreeBSD in the
5-10 second variety. I would suspect that any misbehaving IDE device
can do this.
Dave.
--
|David Gilbert, Velocet Communicati
FWIW, I have a VIA chipset in my machine that is running -STABLE and I don't
have such problems. I don't know if I have the same chipset as you tho, as
I'm not at the machine to check my dmesg.
I put an decent about of stress on the drives and don't seem to have any
lockups at all, slowdowns yes
:Hi there,
:
: I recently had a crash on my SMP system. Actually, I have had a
:number of crashes over the past six months, but have just recently had
:time to configure the system to get the crash dumps. Like a good
:citizen, I filed a problem report (kern/12127). I have now gotten
:another cra
During the boot process I see
dumpon: crash dumps to /dev/da0s1b (4, 131073)
checking for core dump...savecore: can't find device 13/131073
Jul 20 10:18:00 troutmask savecore: can't find device 13/131073
Doing additional network setup: portmap.
My /etc/fstab file contains:
/dev/
In message <[EMAIL PROTECTED]>, "Steven G. Kar
gl" writes:
>
>During the boot process I see
> dumpon: crash dumps to /dev/da0s1b (4, 131073)
> checking for core dump...savecore: can't find device 13/131073
>It seems that the the major device number is reset from 4 to 13.
>troutmask:kargl[22
According to Poul-Henning Kamp:
> In message <[EMAIL PROTECTED]>, "Steven G. Kar
> gl" writes:
> >
> >During the boot process I see
>
> > dumpon: crash dumps to /dev/da0s1b (4, 131073)
> > checking for core dump...savecore: can't find device 13/131073
>
> >It seems that the the major device
:> > dumpon: crash dumps to /dev/da0s1b (4, 131073)
:> > checking for core dump...savecore: can't find device 13/131073
:>
:> >It seems that the the major device number is reset from 4 to 13.
:>
:> Yes, all dev_t's which make it out of the kernel have cmajor
:> numbers now.
:>
:> Try this c
According to Matthew Dillon:
> :> > dumpon: crash dumps to /dev/da0s1b (4, 131073)
> :> > checking for core dump...savecore: can't find device 13/131073
> :>
> :> >It seems that the the major device number is reset from 4 to 13.
> :>
> :> Yes, all dev_t's which make it out of the kernel have
Thanks to some help off the list I think that the problems with
amd hanging in 'siobi' state is solved. Now that it's been reliable enough
to put into production, I'm seeing some interesting problems. After it's
been running for 24 hours, then the web traffic is turned off I get some
mount
And how do you create dumps from a kernel that hasn't finished booting
(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel
config does not seem to do the job.
Nick
> A checklist for people who want kernel cores:
>
> * make sure that dumpdev is set to point to your swap
:And how do you create dumps from a kernel that hasn't finished booting
:(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel
:config does not seem to do the job.
:
:Nick
You can do it manually from /etc/rc. If it doesn't even get that far,
you used to be able to specify i
On Tue, 20 Jul 1999, Matthew Dillon wrote:
>
> * make sure your swap partition is large enough to hold the crash
> dump. If you have 256MB of ram, your swap partition must be
> at least 256MB in size.
Is there any reason that savecore(8) can't write compressed crashdumps?
(Oth
According to Matthew Dillon:
>
> :And how do you create dumps from a kernel that hasn't finished booting
> :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel
> :config does not seem to do the job.
> :
> :Nick
>
> You can do it manually from /etc/rc. If it doesn't even get t
On 20-Jul-99 Amancio Hasty wrote:
> Have you checked your syslog to see if you are getting disk errors?
>
> Also, I noticed that you have a VIA chipset and I know that
> at least with the Bt848 driver they have caused havoc. I would
> stick to Intel PCI chipsets.
>
> Not sure if your motherboa
In message <[EMAIL PROTECTED]>, Dav
id Scheidt writes:
>On Tue, 20 Jul 1999, Matthew Dillon wrote:
>
>>
>> * make sure your swap partition is large enough to hold the crash
>> dump. If you have 256MB of ram, your swap partition must be
>> at least 256MB in size.
>
>Is there any
:On Tue, 20 Jul 1999, Matthew Dillon wrote:
:
:>
:> * make sure your swap partition is large enough to hold the crash
:> dump. If you have 256MB of ram, your swap partition must be
:> at least 256MB in size.
:
:Is there any reason that savecore(8) can't write compressed crashdum
On Tue, Jul 20, 1999 at 10:40:03AM +0930, Kris Kennaway wrote:
> On Mon, 19 Jul 1999, Nik Clayton wrote:
>
> > docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to
> > (among other things) be consistent with ipfw(8).
> >
> > Anyone care to comment one way or the other?
>
> Defi
On Tue, 20 Jul 1999, Matthew Dillon wrote:
>
> A crash dump would have to uncopmressed to gdb it. If you have
> sufficient space to hold a crash dump, just point /var/crash at that
> space. If you compress it right off the bat then someone is going to
> have to uncompress it t
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Steven G. Kar
> gl" writes:
> >
> >During the boot process I see
>
> > dumpon: crash dumps to /dev/da0s1b (4, 131073)
> > checking for core dump...savecore: can't find device 13/131073
>
> >It seems that the th
In message <[EMAIL PROTECTED]>, "Bria
n F. Feldman" writes:
>> /ddname = find_dev/s/BLK/CHR/
>
>No, that's wrong. You cannot do buffered-type IO on a cdev. I committed
>a workaround, and now it works. There's no easy way around this, except
>possibly making kern.dumpdev a string (makes quite
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Bria
> n F. Feldman" writes:
>
> >>/ddname = find_dev/s/BLK/CHR/
> >
> >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed
> >a workaround, and now it works. There's no easy way around this,
Glad that is working out for you. I am not into PCI low level bugs they are
very
difficult to indentify and in certain cases impossible to fix.
To give you a little hint:
1.6825 May 1999 Roger Hardiman <[EMAIL PROTECTED]>
Due to differences in PCI bus implementations
In message <[EMAIL PROTECTED]>, "Bria
n F. Feldman" writes:
>On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, "Bria
>> n F. Feldman" writes:
>>
>> >> /ddname = find_dev/s/BLK/CHR/
>> >
>> >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:
> >Should I commit a similar workaround for the swap code too? Quite
> >simple to do...
>
> Please so, but I would appreciate if you would do me the favour of
> hiding the guts of this monstrosity in kern/kern_conf.c in a function
> called dev2budev(
On Tue, 20 Jul 1999, Matthew Dillon wrote:
>
> How old is your -CURRENT source tree ?Fixes to the pipe code
> have been made, though they are not 100% complete.
>
> If your -CURRENT source tree is more then a few days old I recommend
> updating it. A number of significant r
:On Tue, 20 Jul 1999, Matthew Dillon wrote:
:
:>
:> How old is your -CURRENT source tree ?Fixes to the pipe code
:> have been made, though they are not 100% complete.
:>
:...
:
:What's happing with regard to your pipe write locking fixes? I still
:apply those to my kernels...
:
: Br
Hi!
I'm currently having problems compiling my kernel:
...
...
...
sh ../../conf/newvers.sh STARFIRE
cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-nostdinc -I- -I. -I../.. -I../.
In article <[EMAIL PROTECTED]>,
Nik Clayton <[EMAIL PROTECTED]> wrote:
>
> Assuming I did this, what's the approved method?
>
> Myself, I'd just
>
> # mv ipf.1 ipf.8
> # cvs remove ipf.1
> # cvs add ipf.8
> # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8
> [... chec
In message <[EMAIL PROTECTED]> Tomi Vainio writes:
: My mouse is always detected as a MouseMan+. Here is couple dmesg logs
: from boots with and without monitor switch.
I had problems with the my Kensignton mouse in a box, but some fixes
were made to -current that fixed the problems. A workaro
On Tue, 20 Jul 1999, Warner Losh wrote:
> I had problems with the my Kensignton mouse in a box, but some fixes
> were made to -current that fixed the problems. A workaround is to set
> flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a
> plain old 2 button (or in my case 3 but
On Tue, 20 Jul 1999, Kazutaka YOKOTA wrote:
> One is Logitech mouse support in the psm driver. The psm driver had
> been unable to handle some wheel mice models, including Logitech
> M-S48, until recently.
Perhaps it's worth getting another mouse in this situation. My $30
Logitech wheeled mous
>Is there any support for the wheel in FreeBSD/X, the moused man page seems
>to suggest there is but I've not managed to get it to do anything yet.
>
>Paul.
You will find the following URL useful to utilize the wheel in
the X environment.
http://www.inria.fr/koala/colas/mouse-wheel-scro
>On Tue, 20 Jul 1999, Warner Losh wrote:
>
>> I had problems with the my Kensignton mouse in a box, but some fixes
>> were made to -current that fixed the problems. A workaround is to set
>> flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a
>> plain old 2 button (or in my cas
On Wed, 21 Jul 1999, Kazutaka YOKOTA wrote:
>
> >On Tue, 20 Jul 1999, Warner Losh wrote:
> >
> >> I had problems with the my Kensignton mouse in a box, but some fixes
> >> were made to -current that fixed the problems. A workaround is to set
> >> flags 0x20 (the NOIDPROBE) which forces it to b
I'm getting really annoyed with this dev_t stuff. I wish you people
would have tested a bit more before committing it all.
MFS is badly broken when used in a diskless configuration. I am trying
to track it all down but it is very, very frustrating.
Also BOOTP seems to be
In message <[EMAIL PROTECTED]> "Chris D. Faulhaber"
writes:
: > flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a
0x200 (one of these days I'll learn to shift by 9)
: For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill
: the out of sync messages
38 matches
Mail list logo
