It seems Tugrul wrote:
>
> The new driver fails to build when devfs is also in the config. I
> made a simple change of "static void *devfs_token" to "void *devfs_token"
> on line 183 in ata-all.h and all seems good.
I know, I was thi close to ripping all the devfs stuff out, but...
>
It seems Brian Feldman wrote:
> Do you have any plans to move the wfd(4) driver to the new ATA framework?
> I'd
> be glad to test it all out, as long as I don't lose my LS-120's functionality.
> Thanks in advance!
I'm, waiting for my ZIP drive to arrive, then there will be an atapi-fd
driver as
It seems David Kelly wrote:
> S ren Schmidt writes:
> > There is NO support for bad144, if your disk is bad, ditch it, it has
> > already outgrown its internal spare sectors, and is dying.
>
> Speaking of which, is there any portable way to monitor bad block lists
> on ATA drives? And the S.M.A.R
It seems oZZ!!! wrote:
>
> > controller ata0
> > device atadisk0# ATA disks
> > device atapicd0# ATAPI CDROM's
> >
> After (fastest(!!!)) boot:
> $ dmesg
> ..
> chip1: rev 0x01 on pci0.7.0
> ata-pci0: rev 0x01 on pci0.7.1
> ata0 at 0x01f0 irq 14 on
with the latest kernel, I have had some problems:
The first occured when I tried to use the arla AFS client. Everything
loads ok, but then after it is loaded, if I try to use it, the system
crashes.
Second occured when I tried to start x11amp. The system crashed when I did
that. I have no idea wh
On 02-Mar-99 Richard Wackerbarth wrote:
> > >remove cc from /usr/src/gnu/usr.bin/Makefile SUBDIR list
> > >remove libstdc++ and libobjc from /usr/src/gnu/lib/Makefile SUBDIR list
> Although this approach works, IMHO, the more appropriate approach
> would be to use "${CC}" rather than "cc" in ALL
> Although this approach works, IMHO, the more appropriate approach
> would be to use "${CC}" rather than "cc" in ALL the makefiles and then
> define "CC=/usr/bin/egcc"
There will be troubles compling C++ code (groff) if our Makefiles add
-I/usr/include/g++ to CXXFLAGS, which I'll bet it does.
--
> At 01:28 PM 3/1/99 -0800, Jordan K. Hubbard wrote:
> >It really does appear to be a simple matter of first making egcs "take over"
> >the system compiler:
> >
> ># cd /usr/ports/lang/egcs
> ># make all install PREFIX=/usr
> ># ln -fs /usr/bin/eg++ /usr/bin/c++
> ># ln -fs /usr/bin/egcc /usr/bin/c
> >> Just make libg++ a port. :-)
> > Yes, or abandon it entirely. We surely don't need it in our base
...
> Netscape still uses libg++
...
> And most will imho agree on the fact, that Netscape is in some ways useful :)
> -lg++.4 => /usr/lib/aout/libg++.so.4.0 (0x10c5c000)
this one I *can't* seem to figure out...looked through GENERIC and swear
I've added everything I need:
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../
Ignore, sorry...started scanning through the GENERIC file and found hte
missing ppbus stuff that didn't exist in 3.x :(
On Tue, 2 Mar 1999, The Hermit Hacker wrote:
>
> Trying to get upgraded, especially with all this talk of moving to egcs,
> and trying to compile the kernel, at the load sta
Trying to get upgraded, especially with all this talk of moving to egcs,
and trying to compile the kernel, at the load stage, I get:
loading kernel
lpt.o: In function `lpt_request_ppbus':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x1c): undefined
reference to `ppb_request_bus'
lpt.
On Mar 03, 1999 at 06:02:37AM +0100, Assar Westerlund wrote:
> Jonathan Lemon writes:
> > How about getting profiling working for ELF kernels before
> > before completely abandoning a.out?
>
> There are patches for that in kern/9413 but I haven't got any feedback
> on them at all.
I did try the
Jonathan Lemon writes:
> How about getting profiling working for ELF kernels before
> before completely abandoning a.out?
There are patches for that in kern/9413 but I haven't got any feedback
on them at all.
/assar
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-
> I'm learning here, don't get upset if I'm all wet. Another thing I note
> is that, unlike all the rest of the snapshots of egcs, the pre-release
> version (and seemingly only the prerelease version) that the port uses
> has gcj, the java tool, cut out.
egcs-1.{0,1}.x never had the java bits. F
Monday, March 01, 1999, 6:20:06 PM, you wrote:
>> Just make libg++ a port. :-)
> Yes, or abandon it entirely. We surely don't need it in our base
> system. Even for ports, I'd be surprised to find anything useful that
> still relied on libg++. Any software that still uses libg++ is almost
>
> Count me among that list - although last time I tried was about 6 months ago.
> The only problem I noticed was the format extensions, although admittedly I
I'm running a kernel built with my contrib'ifed EGCS. Format extensions
and all. libstdc++ is still a problem though.
--
-- David(ob
On Mon, 1 Mar 1999, John Polstra wrote:
> Hang on. Others have reported success building kernels with egcs.
Count me among that list - although last time I tried was about 6 months ago.
The only problem I noticed was the format extensions, although admittedly I
didn't run with the kernel for lon
> Doesn't this just rebuild the standard gcc compiler in /usr/obj/usr/tmp/bin a
s
> part of the tools build, then use that compiler to build world.
Hmmm. You may have an embarassing point here; I was wondering how/if
the native compiler got used during the build process if you commented
it out of
With the latest change of sys/vm/vm_mmap.c, the behavior of that lovely
fincore.c program changes to a lockmgr panic to a "thrd_sleep", which never
is woken up, in the fincore process. I'm just making sure that this is now
known...
Brian Feldman_ __ ___ ___
:In the past 3 weeks I've upgraded from 3.0-release, to 3-stable to 4-current
:(as of 4 days ago). I've tried nfs v2 and nfs v3. In all of those
:circumstances I end up with programs locking due to write problems.
:
:I'm no good a debugging, so if someone could hold my hand through this
:one...
:
On Mon, 1 Mar 1999, Brian Feldman wrote:
> You're not concerned about the freezeup?
The freezeup had nothign whatsoever to do with the subject at hand. I'm
concerned, but this is the *wrong* time to raise it. I am not running a
new kernel, not doing any egcs testing at all yet, still in
tool-bu
On Mon, 1 Mar 1999, Chuck Robey wrote:
> On Mon, 1 Mar 1999, David O'Brien wrote:
>
> > > .if defined(WANT_SHAREDLIBS)
> > > CONFIGURE_ARGS+= --enable-shared
> > > .endif
> > >
> > > in it. That's not particularly friendly, I wonder why it was put in
> > > there, unless the feature is somehow b
The new driver fails to build when devfs is also in the config. I
made a simple change of "static void *devfs_token" to "void *devfs_token"
on line 183 in ata-all.h and all seems good.
Good work, no more stinky delay :-)
Tugrul Galatali
To Unsubscribe: send mail to majo
At 01:28 PM 3/1/99 -0800, Jordan K. Hubbard wrote:
I can generally build a kernel with EGCS, if I change how the .text and
.data are laid out for initialized data. It seems that the initialization
code makes assumptions about the order or layout of the initialization
data. Once the stuff is mad
On Mon, Mar 01, 1999 at 10:10:34PM -0500, Chuck Robey wrote:
> I tried taking the gcj part out of the latest egcs snap, and dropping it
> inplace in the prerelease version.
Grab ftp://ftp.nuxi.com/pub/FreeBSD/egcs-devel-port-990228.tar.gz if you
want a portball for the latest snapshot of EGCS.
On Mon, 1 Mar 1999, David O'Brien wrote:
> > .if defined(WANT_SHAREDLIBS)
> > CONFIGURE_ARGS+= --enable-shared
> > .endif
> >
> > in it. That's not particularly friendly, I wonder why it was put in
> > there, unless the feature is somehow broken? I'm trying to rebuild it
> > now to see what it
Do you have any plans to move the wfd(4) driver to the new ATA framework? I'd
be glad to test it all out, as long as I don't lose my LS-120's functionality.
Thanks in advance!
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __
S ren Schmidt writes:
> There is NO support for bad144, if your disk is bad, ditch it, it has
> already outgrown its internal spare sectors, and is dying.
Speaking of which, is there any portable way to monitor bad block lists
on ATA drives? And the S.M.A.R.T. stuff that some vendors advertise?
Nope, new kernel.
On Tue, 2 Mar 1999, Daniel O'Connor wrote:
>
> On 01-Mar-99 Matthew Jacob wrote:
> > I mean, I *did* do a complete world build but I still get:
> Your kernel is old?
> ie a new world and an old kernel give the same weirdness as an old world and
> a new kernel
> :)
>
> ---
>
...
> eg++ is totally incompatable with g++ 2.7.x.
...
> -- David(obr...@nuxi.com -or- obr...@freebsd.org)
Aha!
Thanks,
tomdean
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> As suspected, eg++ is using libstdc++.a, not libstdc++.so.2, as it
> should.
NO it should NOT! libstdc++.so.2 is matched to g++ 2.7.2.x, NOT egcs.
This point is why I won't make the EGCS port have a shared libstdc++ by
default. What happens when you move an eg++ produced binary to a machine
w/
> .if defined(WANT_SHAREDLIBS)
> CONFIGURE_ARGS+= --enable-shared
> .endif
>
> in it. That's not particularly friendly, I wonder why it was put in
> there, unless the feature is somehow broken? I'm trying to rebuild it
> now to see what it then installs.
Because people like a previous poster th
# pwd; ls
/usr/local/lib/gcc-lib/i386-unknown-freebsd4.0/egcs-2.91.60
SYSCALLS.c.Xcollect2* crtend.olibg2c.alibstdc++.a
cc1*cpp*crtendS.o libgcc.aspecs
cc1obj* crtbegin.o f771* libiberty.a
cc1plus*crtbegi
In the past 3 weeks I've upgraded from 3.0-release, to 3-stable to 4-current
(as of 4 days ago). I've tried nfs v2 and nfs v3. In all of those
circumstances I end up with programs locking due to write problems.
I'm no good a debugging, so if someone could hold my hand through this
one...
Basic
On Mon, 1 Mar 1999, Thomas Dean wrote:
> As suspected, eg++ is using libstdc++.a, not libstdc++.so.2, as it
> should.
>
> How does this get fixed?
I just noticed that the egcs Makefile has a buried:
.if defined(WANT_SHAREDLIBS)
CONFIGURE_ARGS+= --enable-shared
.endif
in it. That's not particu
As suspected, eg++ is using libstdc++.a, not libstdc++.so.2, as it
should.
How does this get fixed?
tomdean
==
# g++ -m486 -O2 hello.cc -o hello
# ldd hello
hello:
libg++.so.4 => /usr/lib/libg++.so.4 (0x28051000)
libstdc++.so.2 => /usr
> controllerata0
> deviceatadisk0# ATA disks
> deviceatapicd0# ATAPI CDROM's
>
After (fastest(!!!)) boot:
$ dmesg
..
chip1: rev 0x01 on pci0.7.0
ata-pci0: rev 0x01 on pci0.7.1
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-
Admittedly detecting deadlock is not trivial in general. But if we are
about to panic because of deadlock, then we have already detected
something. The question now is: Do we crash the whole system, or just
one or two user processes?
Rahul
> :Since bugs do happen, deadlock can occur in the ker
On 01-Mar-99 Matthew Jacob wrote:
> I mean, I *did* do a complete world build but I still get:
Your kernel is old?
ie a new world and an old kernel give the same weirdness as an old world and a
new kernel
:)
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gso
On Mon, 1 Mar 1999, Jordan K. Hubbard wrote:
> > I can generally build a kernel with EGCS, if I change how the .text and
> > .data are laid out for initialized data. It seems that the initialization
> > code makes assumptions about the order or layout of the initialization
> > data. Once the stu
In article you
write:
>In message <199903011709.jaa48...@vashon.polstra.com>, John Polstra writes:
>>In article <31122.920241...@zippy.cdrom.com>,
>>Jordan K. Hubbard wrote:
>>>
>>> I'd personally be happy with an egcs that just did sensible things
>>> with ELF,
>>
>>Me too. We _must_ not let
John Polstra said:
> John S. Dyson wrote:
> > Jordan K. Hubbard said:
> >> > I can generally build a kernel with EGCS, if I change how the .text and
> >> > .data are laid out for initialized data. It seems that the
> >> > initialization
> >> > code makes assumptions about the order or layout of t
Chuck Robey said:
> On Mon, 1 Mar 1999, John S. Dyson wrote:
>
> > I can generally build a kernel with EGCS, if I change how the .text and
> > .data are laid out for initialized data. It seems that the initialization
> > code makes assumptions about the order or layout of the initialization
> > d
John S. Dyson wrote:
> Jordan K. Hubbard said:
>> > I can generally build a kernel with EGCS, if I change how the .text and
>> > .data are laid out for initialized data. It seems that the initialization
>> > code makes assumptions about the order or layout of the initialization
>> > data. Once th
Jordan K. Hubbard said:
> > I can generally build a kernel with EGCS, if I change how the .text and
> > .data are laid out for initialized data. It seems that the initialization
> > code makes assumptions about the order or layout of the initialization
> > data. Once the stuff is made to act more
> I have the bmake framework that will allow us to properly drop-in egcs.
> I expect to put it up for FTP this evening.
> (libstdc++ still needs a little bit more work)
VERY useful! Thanks, I look forward to seeing that.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubsc
> > data. Once the stuff is made to act more like the version of GCC that
> > FreeBSD uses, the kernel will most often build and work.
>
> It really does appear to be a simple matter of first making egcs "take over"
> the system compiler:
I have the bmake framework that will allow us to properly
> I can generally build a kernel with EGCS, if I change how the .text and
> .data are laid out for initialized data. It seems that the initialization
> code makes assumptions about the order or layout of the initialization
> data. Once the stuff is made to act more like the version of GCC that
>
Finally!!
The much roumored replacement for our current IDE/ATA/ATAPI is
materialising in the CVS repositories around the globe.
So what does this bring us:
A new reengineered ATA/ATAPI subsystem, that tries to overcome
most of the deficiencies with the current drivers.
It supports PCI as wel
> Wouldn't the first logical step be to stop generating the a.out libs
> in make world, and check in the "final version" like with the rest
> of the compat libs ?
Yes, I was sort of hoping that the same person who did the other
compat* dists would jump in with that, but he's ignored my broad
hints
On Mon, 1 Mar 1999, John S. Dyson wrote:
> I can generally build a kernel with EGCS, if I change how the .text and
> .data are laid out for initialized data. It seems that the initialization
> code makes assumptions about the order or layout of the initialization
> data. Once the stuff is made t
John Polstra said:
> In article <19990228152909.e2...@relay.nuxi.com>,
> David O'Brien wrote:
> > > I keep on hearing about how we're losing because we don't have the 3
> > > month old latest feature
> >
> > With EGCS the issue isn't having the latest 3 mo. feature, but we have a
> > totally BROK
On Mon, 1 Mar 1999, Poul-Henning Kamp wrote:
> Yes, but considering the low age of the interface, the fact that it
> was made so narrow-scope is a disgrace.
True. It appears that it was a fairly focused solution for a very
specific case of problem. (as you said)
> Try to implement a E1 line wit
Of all the gin joints in all the towns in all the world, Garrett Wollman
had to walk into mine and say:
> < said:
>
> > Interested persons should review the diffs and pipe up if they have
> > some passionate argument argument against them.
>
> Patches look mostly fine.
Okay. I noticed one oth
In message , "Matthe
w N. Dodd" writes:
>On Mon, 1 Mar 1999, Poul-Henning Kamp wrote:
>>
>> And some new PCI devices doesn't either because if_media is hopelessly
>> narrowtrack for real world devices :-(
>
>As much as if_media sucks, it does have the ability to be extended in a
>fariety of useful
I mean, I *did* do a complete world build but I still get:
last pid: 409; load averages: 0.00, 0.00, 0.00up 0+01:37:10 11:16:54
6 processes: 1 running
CPU states: % user, % nice, % system, % interrupt, % idle
Mem: 7344K Active, 33M Inact, 22M Wired, 5795K Buf, 61M
Thomas Dean wrote:
> # file hello
> hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), \
>dynamically linked, stripped
> # time hello
> Hello, world.
> 0.02 real 0.00 user 0.02 sys
Please add to that list the output of "ldd " for each executable.
M
> > What I have won't build kernels yet. I could hack our system Makefiles
> > to use different compile options, but I don't like that approach. So
> > I'm working on adding our compiler flags and such.
>
> Hang on. Others have reported success building kernels with egcs.
> But even if there ar
On Mon, 1 Mar 1999, Poul-Henning Kamp wrote:
> In message <199903011751.kaa03...@mt.sri.com>, Nate Williams writes:
> >> > ! * If the LINK1 flag is set, it means the underlying
> >> > interface
> >> > ! * can do VLAN tag insertion itself and doesn't require
> >> >
Until you modify the map, an exclusive lock on the map is overkill. Try
using read locks. (See vm_map_lookup.)
In the meantime, I can't see any reason why mincore acquires an
exclusive lock either. (It never modifies the map.) I'm going
to remedy that.
Alan
To Unsubscribe: send mail
I installed egcs from the port.
eg++ produces larger binaries than g++. From this trivial example, I
would expect these files to be very similar in size.
obj_size exe_size strip_exe_size
--
g++ 972 7150 5464
eg++ 118829
In message <199903011751.kaa03...@mt.sri.com>, Nate Williams writes:
>> > ! * If the LINK1 flag is set, it means the underlying interface
>> > ! * can do VLAN tag insertion itself and doesn't require us to
>> > ! * create a special header for it. In this case, we just
> > !* If the LINK1 flag is set, it means the underlying interface
> > !* can do VLAN tag insertion itself and doesn't require us to
> > !* create a special header for it. In this case, we just pass
>
> Are we certain that all drivers are now doing if_media and
Poul-Henning Kamp wrote:
> Wouldn't the first logical step be to stop generating the a.out libs
> in make world, and check in the "final version" like with the rest
> of the compat libs ?
Yes! And it is long past the time when we should have done exactly
that.
John
---
John Polstra
> The question is whether there is a way to do the autogrow function if
> the map lock is already held.
>
Allow lock recurse?
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
In article <19990228233542.a4...@relay.nuxi.com>,
David O'Brien wrote:
> > guess we shoot for libstdc++ as the "minimum requirements" and perhaps
> > provide libg++ as well (not necessarily initially) just for the
>
> Just make libg++ a port. :-)
Yes, or abandon it entirely. We surely don't nee
In message <199903011709.jaa48...@vashon.polstra.com>, John Polstra writes:
>In article <31122.920241...@zippy.cdrom.com>,
>Jordan K. Hubbard wrote:
>>
>> I'd personally be happy with an egcs that just did sensible things
>> with ELF,
>
>Me too. We _must_ not let a.out become a ball and chain.
In article
, Brian
Feldman wrote:
> How about this, which noone has suggested: Why don't we, for now,
> import EGCS and libstdc++, getting those working? Of course, here's
> the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2.x like
> they are now.
Ick! No way!
John
--
John Polstr
In article <19990228152909.e2...@relay.nuxi.com>,
David O'Brien wrote:
> > I keep on hearing about how we're losing because we don't have the 3
> > month old latest feature
>
> With EGCS the issue isn't having the latest 3 mo. feature, but we have a
> totally BROKEN C++ compiler.
Yes. We desper
In article <31122.920241...@zippy.cdrom.com>,
Jordan K. Hubbard wrote:
>
> I'd personally be happy with an egcs that just did sensible things
> with ELF,
Me too. We _must_ not let a.out become a ball and chain. We have
stressed over and over all along that we were not going to become a
dual-ob
This is 3.0-RELEASE I'm coming from.
I have elf binaries (except some ports?).
The kernel is aout.
If I rebuild the kernel with the new sources without doing a "make
upgrade", won't
something break?
Would I set KERNELFORMAT=elf in make.conf first?
John Irwin wrote:
>
> Bill Hamilton wrote:
>
> >
< said:
> Interested persons should review the diffs and pipe up if they have
> some passionate argument argument against them.
Patches look mostly fine.
> Also, I should point out that while if_vlan provides the necessary
> kernel hackery to implement VLANs, there isn't any user space utility
>
>> mincore() locks the vmspace map, and initialises vec[] a byte at a time
>> using subyte(). When vec[] is sufficiently large, it is not all in core
>> initially and a page fault occurs in subyte(). The new stack growing
>> code locks the vmspace map early and panics.
>
>It appears to me the pot
On Sun, 28 Feb 1999 20:06:33 EST, Alfred Perlstein wrote:
> Lastly i'm interested in writing a man page for kernel.conf i know
> how to submit diffs, but what about totally new files? just send-pr
> with it attached? or a url?
Send-pr(1). For new files, see the diff(1) manpage description of t
>> There are many potential problems with SMP kernels. Many of the inline
>> functions in depend on SMP. We've already pessimised
>> the usual (non-SMP) case by uninlining a few too many spl-related
>> functions.
>
>So you think it would be bad to have zalloc and zfree as non-inline
>functions?
76 matches
Mail list logo
