This is a HEADS UP.
The recent increase in MLEN from 128 to 256 bytes led to very surprising
problems with the latest, so called developers', version of isdn4bsd.
The new version uses slcompress by default. The change in MLEN makes
struct slcompress 2KB larger than it used to be. BTW the entry
On Sat, 1 Apr 2000, Nikolai Saoukh wrote:
> On Fri, Mar 31, 2000 at 08:55:37PM +0100, Doug Rabson wrote:
>
> > I will try to tackle these issues soon. Due to other commitments, this
> > won't happen for a few days though.
>
> Can I halp somehow?
After I get the basics working, I'll contact you
On Sat, 1 Apr 2000, Pierre Y. Dampure wrote:
>
> Since revision 1.5 of the above, my kernel is giving me a "too many dependant
> configs (8)" when probing PNP resources.
>
> Problem is, it looks like the SoundBlaster AWE 64 Gold advertises 8 different
> PNP configurations (at least, that's what
* Gary Jennejohn <[EMAIL PROTECTED]> [000402 01:43] wrote:
> This is a HEADS UP.
>
> The recent increase in MLEN from 128 to 256 bytes led to very surprising
> problems with the latest, so called developers', version of isdn4bsd.
>
> The new version uses slcompress by default. The change in MLE
==
$B%"%$%I%k#2#0#0#1%*!<%W%s!*!*(B
==
$B"##R#e#a#l#G#2!!%i%$%V%A%c%C%H?74k2h2q0wBgJg=8!*!*(B
$B!!K\%5%$%H$O!"7n!9$NDj3[NA6b#1#0#0#0#0
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
> struct slcompress is now in struct sppp, which is passed by ispppcontrol
> as part of an ioctl call. Eventually the kernel lands in sppp_params,
> which does a copyin to a struct spppreq (which contains struct sppp) on
> the kernel stack. Because struct
Thus spake Andrew MacIntyre ([EMAIL PROTECTED]):
> they weren't particularly reliable, particularly when multiple jobs were
> queued simultaneously. I hope their more recent stuff is better behaved.
It is now.
A further thing is: If your LaserJet doesn't understand PostScript,
you have to use
Jeremiah Gowdy wrote:
>
> Does anyone have any experiance or information about using HP JetDirect 500X
> Printer Hubs with FreeBSD ? This is mission critical for my company, so any
> information greatly appriciated.
Ah...printers...my next to modems, my least favorite periphial to deal
with.
On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter <[EMAIL PROTECTED]> wrote:
> > Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on
> > 7x 200M disks - it does not hang for me since a long time.
> > The latest current I tested R5 well is from 19th March on alpha. Th
Just went through a few logfiles:
Checking for rejected mail hosts:
-1d: Cannot apply date adjustment
usage: date [-nu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f f
I converted the amd and adv drivers to new-bus. But, as I am not
familiar with these drivers and new-bus, maybe I have mistaken.
Will somebody please review these changes?
For amd driver:
http://home.jp.FreeBSD.org/~nyan/patches/amd.diff.gz
For adv driver:
http://home.jp.FreeBSD.org/~nyan/patch
> I wonder how wise it was to change MLEN without more testing. But hey,
> this is -current, that's what it's there for.
I've been running with MLEN set to 256 bytes for more than a year for
reasons unrelated to this commit, and haven't seen any problems at all.
(Of course, I don't use sppp..)
Hi,
I've tried to track down sound issues of the SDL (Simple Direct Layer)
library and found that current pcm buffering behaviour inconsistent with
OSS specifications, which cause applications that require sophisticated
sound control to misbehave on FreeBSD.
There is two different buffers implem
On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste <[EMAIL PROTECTED]>
wrote:
> I hook up serial console to get full traceback next time, but I don't
> have any knowledge for further analysis.
Here's full traceback, environment is all same, except the filesystem is
mounted with async (bef
On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste wrote:
> I got now crash under 4.0-RELEASE, with syncer and bufdaemon in the same
> vrlock state, pax in flswait. I was in single-user mode using pax to
> extract usr archive to newly created raid5 volume. I'm using NFS mount
> with flags -3
It seems Vallo Kallaste wrote:
> On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste <[EMAIL PROTECTED]>
>wrote:
>
> > I hook up serial console to get full traceback next time, but I don't
> > have any knowledge for further analysis.
>
> Here's full traceback, environment is all same, exce
On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter wrote:
> On Sun, Apr 02, 2000 at 01:15:39AM +0200, Bernd Walter wrote:
> >
> > Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on
> > 7x 200M disks - it does not hang for me since a long time.
> > The latest current
On Sun, Apr 02, 2000 at 05:37:30PM +0200, Bernd Walter wrote:
> Are you for any chance running the NFS Server without nfsd?
> I expect them to be needed if you are serving vinum volumes.
Sometimes I'm to stupid - the NFS case was a different thread.
--
B.Walter COSMO-Project
On Sun, Apr 02, 2000 at 05:38:01PM +0200, Soren Schmidt wrote:
> It seems Vallo Kallaste wrote:
> > On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste <[EMAIL PROTECTED]>
>wrote:
> >
> > > I hook up serial console to get full traceback next time, but I don't
> > > have any knowledge for fu
It seems Bernd Walter wrote:
> On Sun, Apr 02, 2000 at 05:38:01PM +0200, Soren Schmidt wrote:
> > It seems Vallo Kallaste wrote:
> > > On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste
><[EMAIL PROTECTED]> wrote:
> > >
> > > > I hook up serial console to get full traceback next time, but
Ciao.
As stated in gdb mlist, gdb 5.0 is on the way but it hasn't support for
freebsd-elf in
the package. Is there anyone that could explain me why ?
Thanks.
---
Bye,
Mirko <[EMAIL PROTECTED]> (NeXTmail, MIME)
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMA
On Sun, 2 Apr 2000, Mirko Viviani wrote:
> Ciao.
>
> As stated in gdb mlist, gdb 5.0 is on the way but it hasn't support for
> freebsd-elf in
> the package. Is there anyone that could explain me why ?
You're more likely to get an answer by asking the gdb developers on the
gdb "mlist" :-)
Kri
Bruce Evans writes:
>On Sun, 2 Apr 2000, Gary Jennejohn wrote:
>> Moving the struct spppreq into global address space solves the problem,
>> but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be
>> 128 also fixes the problem, even with the struct spppreq on the stack.
>
>Big stru
On Sun, Apr 02, 2000 at 05:37:30PM +0200, Bernd Walter <[EMAIL PROTECTED]> wrote:
> > I hook up serial console to get full traceback next time, but I don't
> > have any knowledge for further analysis.
>
> You don't need a serial console to get further informations.
> You should compile the kerne
On Sun, Apr 02, 2000 at 06:16:43PM +0200, Bernd Walter <[EMAIL PROTECTED]> wrote:
> Do you see it only with R5 or also with other organisations?
I don't have any problems with my own -current system which has striped
volume over three UW SCSI disks. SCSI-only system, SMP.
Sources from March 14.
On Sun, Apr 02, 2000 at 08:02:54PM +0200, Vallo Kallaste wrote:
> Yes, but I don't have space for crashdump and I can't build new kernel
> with limited memory usage because I don't have /usr filesystem up and
> running. Is there a way to limit memory usage without recompiling
> kernel? I can store
It seems Bernd Walter wrote:
> On Sun, Apr 02, 2000 at 08:02:54PM +0200, Vallo Kallaste wrote:
> > Yes, but I don't have space for crashdump and I can't build new kernel
> > with limited memory usage because I don't have /usr filesystem up and
> > running. Is there a way to limit memory usage with
* Soren Schmidt <[EMAIL PROTECTED]> [000402 12:42] wrote:
> It seems Bernd Walter wrote:
> > On Sun, Apr 02, 2000 at 08:02:54PM +0200, Vallo Kallaste wrote:
> > > Yes, but I don't have space for crashdump and I can't build new kernel
> > > with limited memory usage because I don't have /usr filesy
It seems Alfred Perlstein wrote:
> > > Just to clearify the things...
> > > Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?
> >
> > I have the problem with 4.0-RELEASE, STABLE and 5.0-current but it
> > might only occur with RAID5...
>
> I've never seen it with just a s
Hi Jim,
On 0, Jim Bloom <[EMAIL PROTECTED]> wrote:
> A similar patch was added for the USA version of RSA for the same basic reason.
> Your patch is almost correct. It should add the line:
>
> LDADD+= -L$[.OBJDIR]/../libcrypto -lcrypto
^ ^
>
> Your version woul
On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
> I dont think vinum is/was usable under -current at least not the
> RAID5 stuff, its broken, and some of it is because greg is not
> up to date with what -current looks like these days.
Can you please explain what have massivly chan
It seems Bernd Walter wrote:
> On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
> > I dont think vinum is/was usable under -current at least not the
> > RAID5 stuff, its broken, and some of it is because greg is not
> > up to date with what -current looks like these days.
>
> Can y
Are there any plans to merge perl-5.6.0 into current? I don't have any
plans for using it currently, but I curious.
Thanks,
Tom Veldhouse
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sun, 2 Apr 2000, Thomas T. Veldhouse wrote:
> Are there any plans to merge perl-5.6.0 into current? I don't have any
> plans for using it currently, but I curious.
Hmm. What with the nightmarish build structure of perl, I'm sure that
reading this is just going to wreck Mark's day. In light
* Soren Schmidt <[EMAIL PROTECTED]> [000402 13:05] wrote:
> It seems Alfred Perlstein wrote:
> > > > Just to clearify the things...
> > > > Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?
> > >
> > > I have the problem with 4.0-RELEASE, STABLE and 5.0-current but it
> >
On Sunday, 2 April 2000 at 22:22:39 +0200, Søren Schmidt wrote:
> It seems Bernd Walter wrote:
>> On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
>>> I dont think vinum is/was usable under -current at least not the
>>> RAID5 stuff, its broken, and some of it is because greg is not
On Sunday, 2 April 2000 at 17:42:16 +0200, Bernd Walter wrote:
> On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter wrote:
>> On Sun, Apr 02, 2000 at 01:15:39AM +0200, Bernd Walter wrote:
>>>
>>> Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on
>>> 7x 200M disks -
:>> to vinum?
:>
:> The changes done by phk to seperate out the io stuff from struct
:> buf.
:
:Alfred and Bernd came up with fixes that seem to work. I still need
:to review them, but I'm in the process of installing an up-to-date
:-CURRENT on my test box. Watch this space.
:
:Greg
I won'
On Mon, Apr 03, 2000 at 07:41:54AM +0930, Greg Lehey wrote:
> On Sunday, 2 April 2000 at 22:22:39 +0200, Søren Schmidt wrote:
> > It seems Bernd Walter wrote:
> >> On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
> >>> I dont think vinum is/was usable under -current at least not the
On Mon, Apr 03, 2000 at 07:43:00AM +0930, Greg Lehey wrote:
> I found a potentially serious bug in the RAID calculations yesterday:
> it assumed that sizeof (int) == 4. I suspect that it would just slow
> down the calculations, but in any case I've fixed it.
That's generaly not good but allways
In attempting to test out Cameron's emu10k1 support, one quickly notices that
the build dies in $SUBJECT due to unresolved constants.
The attached patch fixes the problem. I'm happy to report that mpg123 is
playing mp3's quite fine. There's a little burst of static when it first
starts up, but ot
* Matt Dillon <[EMAIL PROTECTED]> [000402 11:18] wrote:
> dillon 2000/04/02 10:52:44 PDT
>
> Modified files:
> sys/i386/i386support.s
> sys/kern init_sysent.c kern_prot.c kern_sig.c
> Log:
> Make the sigprocmask() and geteuid() system calls MP SAFE. E
:Along with snagging the "easy ones" for MP safeness, shouldn't getpid
:be MP safe? The struct proc is allocated from the proc_zone, and
:afaik zalloc allows for stable storage meaning it's safe to dereference
:the ppid pointer once the entire struct proc is populated, which needs
:to happen bef
* Matthew Dillon <[EMAIL PROTECTED]> [000402 16:37] wrote:
>
> :Along with snagging the "easy ones" for MP safeness, shouldn't getpid
> :be MP safe? The struct proc is allocated from the proc_zone, and
> :afaik zalloc allows for stable storage meaning it's safe to dereference
> :the ppid pointer
:I did look at the code, struct proc is allocated from a zone,
:meaning it won't "go away" once allocated, there's no danger in
:dereferencing p_pptr, I don't get it.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
:"I have the heart of a child; I keep it in a jar on my desk."
* Matthew Dillon <[EMAIL PROTECTED]> [000402 17:04] wrote:
>
> :I did look at the code, struct proc is allocated from a zone,
> :meaning it won't "go away" once allocated, there's no danger in
> :dereferencing p_pptr, I don't get it.
> :
> :--
> :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PRO
Dirk Roehrdanz wrote:
>
> Thanks for the modification.
> I have replaced the "[]" with "{}" . A run of "make buildworld" with
> the patch finished without errors.
Sorry about that. I did it quickly and the font I was using has the characters
looking identical. Time to change fonts :-)
> The
In message <[EMAIL PROTECTED]> Takahashi Yoshihiro writes:
: For adv driver:
: http://home.jp.FreeBSD.org/~nyan/patches/advansys.diff.gz
I took a look at this change. For the most part it looks good.
However, I have a question. Why did you move the adv_isa into the md
files file and then commen
:Good call.
:
:Ugh, I should think about this more, but i'll just grasp at straws
:and suggest that p_pptr is set to volatile variable, and we re-read
:it after we snarf the pid from the pointer and make sure it hasn't
:changed out from under us.
:
:Either that or store it in the child's proc str
I'm not sure if this is -current fodder or not, but since it's still
happening in -current, I'll ask.
We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
on 5.0-current, too). Before, with the exact same load, we'd see load
averages from between 0.20 and 0.30. Now, we're g
> :We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
> :on 5.0-current, too). Before, with the exact same load, we'd see load
> :averages from between 0.20 and 0.30. Now, we're getting:
> :
> :load averages: 4.16, 4.23, 4.66
> :
> :Top shows the same CPU percentages, ju
I tried this, and the buffer size of 16k doesn't work too well with
the ESS 1868 isa. The fist .3 seconds or so of the beginning of the
clip plays in an infinite loop. I bumped down the buffer size to 12k,
and it seems to work pretty well. Actually, I tried experimenting
with various buffer siz
On Sun, Apr 02, 2000 at 11:10:59PM -0500, Kevin Day wrote:
> > :We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
> > :on 5.0-current, too). Before, with the exact same load, we'd see load
> > :averages from between 0.20 and 0.30. Now, we're getting:
> > :
> > :load averag
> > > I believe the load average was changed quite a while ago to reflect not
> > > only runnable processes but also processes stuck in disk-wait. It's
> > > a more accurate measure of load.
> >
> > Ahh, and since nearly everything is done on this system via NFS, I can
> > imagine th
It seems Greg Lehey wrote:
> > Unfortunately I don't have a toy i386 system ready and testet on alpha.
> > There may be some differences how data corruptions efects on this platform.
>
> I found a potentially serious bug in the RAID calculations yesterday:
> it assumed that sizeof (int) == 4. I
In article <[EMAIL PROTECTED]>
Warner Losh <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]> Takahashi Yoshihiro writes:
> : For adv driver:
> : http://home.jp.FreeBSD.org/~nyan/patches/advansys.diff.gz
>
> I took a look at this change. For the most part it looks good.
Thanks.
> Ho
In message <[EMAIL PROTECTED]> Takahashi Yoshihiro writes:
: Because, adv_isa.c is not required by PC-98, PC-98 requires only PCI
: frontend. Then it contains isa_dmacascade function which does not
: exist and is not needed for PC-98.
Is that because there's not isa bus on a pc-98? Or that the a
On Sun, Apr 02, 2000 at 05:56:22PM -0400, Chuck Robey wrote:
> On Sun, 2 Apr 2000, Thomas T. Veldhouse wrote:
>
> > Are there any plans to merge perl-5.6.0 into current? I don't have any
> > plans for using it currently, but I curious.
>
> Hmm. What with the nightmarish build structure of perl
:I'm not sure if this is -current fodder or not, but since it's still
:happening in -current, I'll ask.
:
:We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
:on 5.0-current, too). Before, with the exact same load, we'd see load
:averages from between 0.20 and 0.30. Now, w
59 matches
Mail list logo
