I upgraded to 4.1-RC1 today; attempted to fire up esound and my system hung.
I rebooted into X, fired up esound from text mode and system hung again
with a message that an NMI was caught.
I remember that the SBLive has some issues with ECC systems, resulting in
some NMIs being thrown. It would
Hmm... backing out to emu10k1.c version 1.6 did not fix my problem. Does
anyone else have a SBLive! in an ECC machine that is throwing an NMI
whenever you try to use xmms or esd? If not, I will try to binary search
the dates to see if I can find when the change that tickeled the NMI bug on
the
I used "tail -F /var/log/local3" in my little shell script
to scan log for some string.
When i change release from 3.X to 4.0
tail sometimes (may be once in a day or hours)
rescan log from begining and alarm me about problem
which has being occurred hours before.
It was coz " sb2.st_rdev !=
Mutt made be believe that Jason R Thorpe wrote:
> DONATE_COPY is not implemented in UVM. I'm not sure it was ever
> implemented anywhere. "Copy and delete" is really "move", right?
> Anyway, it's not clear those semantics are really useful at all.
Okay, so let's skip that one.
Any other commen
Mario Sergio Fujikawa Ferreira wrote:
>
> Besides, a failing malloc should return NULL, shouldn't
> it? I would have expected core if I had malloc_options="X" which
> I do not (in fact, I have no malloc_options).
IF the malloc fails, it should return NULL. But this only happens in the
ca
Hello!
Currently, I see the following:
root@parca /sys $ grep _BSD_TIME_T {alpha,i386}/include/ansi.h
alpha/include/ansi.h:#define_BSD_TIME_T_int /* time() */
i386/include/ansi.h:#define _BSD_TIME_T_long /* time()... */
I wonder if we want to change that to __int32_t in
On 23 Jul 2000, at 7:22, freebsd-hackers-digest wrote:
>
> freebsd-hackers-digest Sunday, July 23 2000 Volume 04 : Number 901
>
>
>
> In this issue:
> Re: Multiple ro mounts of vinum volume
> Re: Multiple ro mounts of vinum volume
> Re: Intel 840 Chipset Discontinue
> Re: sysutils
On Sun, Jul 23, 2000 at 04:09:12PM -0400, [EMAIL PROTECTED] wrote:
[.. 480 lines of spam snipped ..]
Why don't you remove yourself and save everybody else the bandwidth,
time, and money you just wasted by posting this cruft to this list??
--
Will Andrews <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
I have some code that does a sysctlbyname to pull in "kern.ipc.maxsockbuf",
I then use that value to setsockopt the SNDBUF to that amount, but
I get ENOBUFS back from the kernel. I think I'm failing here in
uipc_socket2.c" line 432 in the function sbreserve():
if ((u_quad_t)cc > (u_quad_
The first BETA version of the 'aac' driver for the Adaptec AAC-364
'Jalapeno' and AAC-3642 'Jalapeno II' RAID adapters is available from
http://people.freebsd.org/~msmith/RAID/index.html#adaptec
These adapters are OEMed by Dell as the PERC 2/QC and by HP as the HP
NetRAID-4m.
The driver has
On Sun, 23 Jul 2000, Alfred Perlstein wrote:
> Also, if sb_max is to remain a read/write sysctl we'll need to cap
> it so that kern.ipc.maxsockbuf is always true and we don't allow
> sysadmins to shoot thier feet by scaling it too high or low, the
> only problem is that I can't for the life of me
>
> The first BETA version of the 'aac' driver for the Adaptec AAC-364
> 'Jalapeno' and AAC-3642 'Jalapeno II' RAID adapters is available from
>
> http://people.freebsd.org/~msmith/RAID/index.html#adaptec
>
> These adapters are OEMed by Dell as the PERC 2/QC and by HP as the HP
> NetRAID-4m.
< said:
> if ((u_quad_t)cc > (u_quad_t)sb_max * MCLBYTES / (MSIZE + MCLBYTES))
> return (0);
I think the code here should clip the requested size into range rather
than failing the allocation. That way, a program could just specify a
ridiculously-large buffer size and get wh
[EMAIL PROTECTED] (Alexander Langer) writes:
> Currently, I see the following:
>
> root@parca /sys $ grep _BSD_TIME_T {alpha,i386}/include/ansi.h
> alpha/include/ansi.h:#define_BSD_TIME_T_int /* time() */
> i386/include/ansi.h:#define _BSD_TIME_T_long /* time()... */
>
>
14 matches
Mail list logo
