On Sun, Aug 29, 1999 at 09:37:51PM -0700, John Polstra wrote:
>
> Expansion of RCS keywords occurs on check_out_, not on checkin. In
> other words, your cvs is responsible for expanding them.
>
Hmm... but what about if you're cvsup-ing the sources?
I'm cvsup-ing stable, not current, (cvsup fil
on 3.2-R gdb-4.18 will core dump without fail when I try to read a core
file generated by the C++ program I am developing - gdb-4.17 does not have
this problem.
-Kip
On Tue, 31 Aug 1999, Alex Zepeda wrote:
> On Sun, 22 Aug 1999, Richard Cownie wrote:
>
>
On Sun, 22 Aug 1999, Richard Cownie wrote:
> On Sat, 21 Aug 1999, David O'Brien wrote:
> > Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> > saying you didn't know FreeBSD comes with gdb:
>
> gdb-4.18 is badly broken on all platforms (at least for C++). You can't
> call
Kevin Street <[EMAIL PROTECTED]> writes:
> I'm getting a panic during an ifconfig on boot after building a kernel
> with the new xl driver.
The patch that Luoqi just posted works for me. I see Bill has just
committed a different fix as well.
--
Kevin Street
[EMAIL PROTECTED]
To Unsubscri
Of all the gin joints in all the towns in all the world, Peter Jeremy
had to walk into mine and say:
> Ian Whalley <[EMAIL PROTECTED]> wrote:
> >My card is identified as <3Com 3c905B-TX Fast Etherlink XL>.
>
> FWIW, I'm running a kernel about 30 hours old with a <3Com 3c905-TX
> Fast Etherlink
> Ian Whalley <[EMAIL PROTECTED]> wrote:
> >My card is identified as <3Com 3c905B-TX Fast Etherlink XL>.
>
> FWIW, I'm running a kernel about 30 hours old with a <3Com 3c905-TX
> Fast Etherlink XL> and I'm not seeing this problem.
>
> At a quick quess, something in the miibus support broke the 3
I'm getting a panic during an ifconfig on boot after building a kernel
with the new xl driver. This happens early in the boot so I don't have a
dump, but can probably arrange to get one if the dmesg output isn't
telling us something useful. System is current as of about 7pm EDT
08/31. The last
Ian Whalley <[EMAIL PROTECTED]> wrote:
>My card is identified as <3Com 3c905B-TX Fast Etherlink XL>.
FWIW, I'm running a kernel about 30 hours old with a <3Com 3c905-TX
Fast Etherlink XL> and I'm not seeing this problem.
At a quick quess, something in the miibus support broke the 3C905B
support.
[Niels Chr. Bank-Pedersen wrote:]
>>After the recent changes to ifconfig and the xl driver I am
>>getting a panic when rc.network runs ifconfig:
>Anybody else seeing this, or should I look somewhere else
>alltogether?
I am seeing exactly the same breakage -- cvsup as of today,
mid-evening EDT. T
> Bruce Evans wrote:
> > >"make buildworld" completes without a problem.
> > >
> > >"make -j 4 buildworld" gives:
> >
> > libncurses now has lots of internal utilities. Apparently the
> > dependencies for them are incomplete. The utilities are are also
> > built at the wrong time and break cros
Richard Cownie wrote:
>
> I managed to build gdb-4.17 in FreeBSD 4.0, here's how to do it:
>
> 1) gdb-4.17/configure --host=i386-unknown-freebsdelf4.0
> Have to specify the host explicitly, otherwise it doesn't realize
> it needs to use ELF.
>
> 2) in gdb-4.17/Makefile, add "-DSVR4_SHAR
I've got a -STABLE GENERIC kernel, cvsupped and built this evening, that
is all
alone on a UFS floppy, and kgzipped.
My P-133 boots the -STABLE kernel fine.
My AMD-K6/2 400 stops immediately after "Uncompressing kernel ... done".
The same systems both can boot a -CURRENT GENERIC kgzipped kernel
Bruce Evans wrote:
> >"make buildworld" completes without a problem.
> >
> >"make -j 4 buildworld" gives:
>
> libncurses now has lots of internal utilities. Apparently the
> dependencies for them are incomplete. The utilities are are also
> built at the wrong time and break cross compiling. Se
>"make buildworld" completes without a problem.
>
>"make -j 4 buildworld" gives:
libncurses now has lots of internal utilities. Apparently the
dependencies for them are incomplete. The utilities are are also
built at the wrong time and break cross compiling. See the old curses
(libmytinfo part
On 01-Sep-99 Daniel O'Connor wrote:
> Of course given the advent of CLV drives a speed rating is now usually the
> maximum read speed, not the average.
Oops.. I mean CAV drives..
Constant Angular Velocity not Constant Linear Velocity.
---
Daniel O'Connor software and network engineer
for Gene
On 31-Aug-99 Kevin Street wrote:
> > Well 2MB/sec == 14x CDRom drive. Is it a 14x CDRom drive? CDRom
> > drives are typically limited to how quickly they can get data off
> > the platter. A faster bus transfer will not improve that.
> I should have mentioned that ... it's a 32x cd
Hi,
(Sorry if this hits the list a couple of times, I had some problems with my mail
system)
I never thought I'd see "clear" break :-) Here's a fix.
It seems to be down to an ncurses change in tgetstr(). The implementation in ncurses
just ignores the "area" parameter, while the one in libtermc
> lineal velocity (and hence data rate) increases from the inside
> (start) to the outside (end) of the disk.
And consequently any CD that isn't completely full will *always*
be slower than the quoted ("guaranteed not to exceed") rate.
-- Richard
To Unsubscribe: send mail to [EMAIL PROTECTED]
> In message <[EMAIL PROTECTED]> Nate Williams writes:
> : > I think we need to set the interrupt mask to 0 in the PIC.
> :
> : I don't think makes any difference, since the APM Bios is in charge of
> : what happens at this point, and the BIOS is below the level of the OS.
> :
>
> The theory is
On Monday, 30 August 1999 at 7:53:12 +0200, Bernd Walter wrote:
> On Sun, Aug 29, 1999 at 04:48:32PM -0700, Matthew Dillon wrote:
>> :
>> :How similar? The trap above is extremely bad; it looks like a return
>> :on a corrupted stack or a jump through a null function vector.
>> :
>> :Make very su
In message <[EMAIL PROTECTED]> Kevin Street writes:
: I should have mentioned that ... it's a 32x cdrom. dmesg says it
: claims to be able to do 5515 KB/sec.
Is it a 32x cdrom or a 32x mamimum cdrom? There have been many of the
big-num speed max, smaller-num speed average drives on the market
David Scheidt <[EMAIL PROTECTED]> wrote:
>Almost all fast (>12X or so) CD-ROM drives are variable speed.
To put this a different way, the data on CD's is stored at a constant
lineal density (closely related to the wavelength of the laser).
Audio CDs are read using constant-linear-velocity, the an
In message <[EMAIL PROTECTED]> Nate Williams writes:
: > I think we need to set the interrupt mask to 0 in the PIC.
:
: I don't think makes any difference, since the APM Bios is in charge of
: what happens at this point, and the BIOS is below the level of the OS.
:
The theory is that no more in
Soren Schmidt writes:
>Depends.. There are many factors involved here, using DMA only lowers
>the CPU usage, and will enable faster transfers if the problem was
>that the CPU was saturated with the PIO transfer. It gave about
>double the transfer rate on my old P6 based maschine, because the
>CP
> : And it seems there still are other devices which wake your PC up in
> : 2-3 mins time.
> : Hmmm, anyone has ideas?
>
> I think we need to set the interrupt mask to 0 in the PIC.
I don't think makes any difference, since the APM Bios is in charge of
what happens at this point, and the BIOS is
I recently cvsupped to -CURRENT, did successful make world and updated the
kernel..
Now I get errors in zsh even after compiling the port.. I'm using the
zsh-devel port which is basically 0-day since I updated ports too
Errors:
(from startup)
zsh in free(): warning: malloc() has never been calle
It seems Kevin Street wrote:
> Two things I've noticed:
> 1) my cdrom delivers about 2M/s which is the same as before DMA. Is
> the improvement only in cpu usage or should I be seeing a speed
> improvement too?
Depends.. There are many factors involved here, using DMA only lowers
the CPU usage,
On 31 Aug 1999, Kevin Street wrote:
> Matthew Dillon <[EMAIL PROTECTED]> writes:
>
> I should have mentioned that ... it's a 32x cdrom. dmesg says it
> claims to be able to do 5515 KB/sec.
>
> I've played around with using dd ... skip=n to reposition which part
> of the cd I'm reading and I'v
I'm getting the same with -j 2 here.
-
Chris D. Faulhaber <[EMAIL PROTECTED]> | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to [EM
cvsup'd -current source at 0840 PST 31 Aug 99
"make buildworld" completes without a problem.
"make -j 4 buildworld" gives:
cc -o make_hash -O2 -pipe -mpentiumpro -I. -I/usr/src/lib/libncurses
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses
-I/usr/src/lib/libncurses/../../contrib/ncur
< said:
> All modern CDRom units have vibration sensors (actually I think they
> just use the error rate from the head) and will adjust the rotational
> speed based on that as well as on the rate the data is being requested
> at. So it will depend on the physical CD as well as ot
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:
:> :Two things I've noticed:
:> :1) my cdrom delivers about 2M/s which is the same as before DMA. Is
:> :the improvement only in cpu usage or should I be seeing a speed
:> :improvement too?
:> :
:> :speed tested with:
:> :dd if=/dev/racd0c of=/dev/n
Matthew Dillon <[EMAIL PROTECTED]> writes:
> :Two things I've noticed:
> :1) my cdrom delivers about 2M/s which is the same as before DMA. Is
> :the improvement only in cpu usage or should I be seeing a speed
> :improvement too?
> :
> :speed tested with:
> :dd if=/dev/racd0c of=/dev/null bs=64k
[ quoted section retained for context ]
On Thu, Aug 26, 1999 at 08:53:00PM +0100, Nik Clayton wrote:
> -stable, -current,
>
> On Sun, Aug 22, 1999 at 11:05:11AM +0100, Nik Clayton wrote:
> > [ cc'd to -current ]
> >
> > On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote:
> > >
> > > Will sup
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes:
: And it seems there still are other devices which wake your PC up in
: 2-3 mins time.
: Hmmm, anyone has ideas?
I think we need to set the interrupt mask to 0 in the PIC. Or at
least disable the interrupts that we know about from a driver p
:Two things I've noticed:
:1) my cdrom delivers about 2M/s which is the same as before DMA. Is
:the improvement only in cpu usage or should I be seeing a speed
:improvement too?
:
:speed tested with:
:dd if=/dev/racd0c of=/dev/null bs=64k count=320
:(I get it to spin up with another dd before t
Two things I've noticed:
1) my cdrom delivers about 2M/s which is the same as before DMA. Is
the improvement only in cpu usage or should I be seeing a speed
improvement too?
speed tested with:
dd if=/dev/racd0c of=/dev/null bs=64k count=320
(I get it to spin up with another dd before this test)
On 30-Aug-99 Justin T. Gibbs wrote:
>>I'm noticing some new output. What does it mean and is it going
>>to stay there? :-)
>
> Peter killed these last week.
>
I still get some messages, kernel as of saturday evening:
*** Relevant part of dmesg output ***
intpm0: PM I/O mapped e400
ahc0: ir
A little while ago I enabled DMA on atapi devices, and while this
generally is a good thing (CPU usage wise), there seems to be
some delicate problems with this on some chipsets and devices.
If you use the new ATA driver and has atapi devices that use DMA
could you please check that they are wor
> >> How about struct timeval instead?
>
> Timevals shouldn't be used in new interfaces. Use timespecs, which are
> both Standard and more future proof.
Agreed.
> >Firstly we are talking about time deltas, and on the sysctl side of things
> >it's very hard to set 'timevals (as you'd need to se
On Mon, 30 Aug 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Jonathan Lemon writes:
> >On Aug 08, 1999 at 11:36:30PM +0200, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, Jonathan Lemon writes:
> >> > I've just committed the revised TCP timer code. There are so
On Tue, Aug 31, 1999 at 02:09:00AM +0200, Pascal Hofstee wrote:
> I get the following errors when trying to run certain perl stuff ..
> like mirror:
> su-2.03# mirror /usr/local/lib/mirror/packages/daemonnews
> DynaLoader:/usr/libdata/perl/5.00503/DynaLoader.pm:188 Caught a SIGSEGV
> shutting d
42 matches
Mail list logo