Re: panic: zone: entry not free
There are many potential problems with SMP kernels. Many of the inline functions in machine/cpufunc.h 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? That would mean that KLDs would be different depending on the options used to build the kernel and that KLDs would need some way of figuring out the these options. How should that be done? By installing opt_global.h after building the kernel? I think global options should be avoided if possible. When they can't be avoided, KLDs should probably extern versions of some functions that are normally static inline, and whatever else it takes for them to be to be independent of kernel options. The kernel proper must provide the uninlined versions (compiled with its options). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make world broken for a day. some NFS stuff as well.
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 the -N command-line option. If you're submitting diffs against a CVS repo, do cvs -qR diff -udRN :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
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 potential for deadlock exists in the old grow code too, but is less likely. I've attached a patch that addresses the issue, though there is a question if this is the best solution. With the old grow code, if the map lock is already held, one of the following will be true a) the grow code doesn't get executed because the va is not in the stack region, which is equivalent to grow returning success b) the grow code returns success because there's no need to grow the region because the va is aready in the mapped region. c) the grow code returns false if the va is within the stack region and there's no room left, which normally will result in a SIGSEGV d) the grow code attempts to grow the stack via vm_map_find and will then deadlock at the vm_map_lock call With this patch, if the map lock is already held, by always returning success, cases a) and b) will be the same as before. For case c) the code will attempt to continue to execute, generally calling vm_fault, which should, I think, generate a SIGSEGV, essentially the same result as the old code, but via a different path. Case d) will now continue executing in a manner equivalent to the new case c). The question is whether there is a way to do the autogrow function if the map lock is already held. I think it shouldn't work. Copying to and from user space must not generate SIGSEGV if the application could access its memory directly. The easiest way to implement this is to never lock maps before accessing user memory. Atomic copies won't get any easier to do after you've backed out of a deadlock. I think mincore() should just unlock the map while calling subyte() and restart if the map changes significantly underneath it. Some critical examples: 1. mincore(addr, 0xfff0, vec) at rtprio 0 (in only process with this priority). vec[] only needs to have size 1MB (for 4K pages). It's barely reasonable for the application to expect vec[] to be all mapped and to perfectly represent the current state. To implement this, mincore() would have to prefault vec[] (or backtrack to give the equivalent) so that it doesn't block. 2. mincore(vec, len, vec). This is quite likely to change the incore'ness of vec[]. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Request for review: changes to if_vlan.c
On Sat, 27 Feb 1999 23:37:10 -0500 (EST), Bill Paul
wp...@skynet.ctr.columbia.edu 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
for configuring vlan interfaces (ifconfig doesn't seem to have any
vlan-specific code that I could see, and is no vlanconfig).
I stopped development on vlan(4) when the switch we had that spoke
802.1Q was returned to the vendor at the end of our demo period. I
have 28 on order right now, and should resume work on the driver after
I get those switches deployed. For interfaces like yours, I would
have preferred a subinterface mechanism, but I never had the time to
implement that. Care to implement GVRP while you're at it?
There also is no vlan(4) man page.
See above.
otherwise I'm going to take it upon myself to hack up ifconfig and
write the man pages myself.
I believe ifconfig is the wrong program for the task. There should be
a separate vlanconfig program. (I wrote one, but it's on my
laptop where I can't conveniently get to it right now.)
There are a couple of areas where vlan(4) needs to get some help from
the underlying driver:
- Promiscuous mode doesn't work at all. It ought to be possible to
put just a specific VLAN into promiscuous mode, without affecting all
the others. This probably involves repeating all of the BPF
does-this-packet-look-like-mine? gluck from the physical interface
drivers.
- Multicast is similarly broken (and a more serious weakness). There
needs to be a mechanism to pass multicast group membership down to the
underlying driver. It may also be necessary to do duplicate
suppression, which is a real challenge.
+ * XXX It's incorrect to assume that we must always kludge up
+ * headers on the physical device's behalf: some devices support
+ * VLAN tag insersion and extraction in firmware.
My theory, as explained above, was that such devices would implement
subinterfaces.
! * 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 no longer
using IFF_LINK1 for that purpose?
/*
* Set up our ``Ethernet address'' to reflect the underlying
! * physical interface's.
*/
ifa1 = ifnet_addrs[ifv-ifv_if.if_index - 1];
ifa2 = ifnet_addrs[p-if_index - 1];
--- 315,321
/*
* Set up our ``Ethernet address'' to reflect the underlying
! * physical interfaces.
*/
Grammar fault -- core dumped.
(The wording was correct as it was.)
* Set the interface MTU.
+ * This is bogus. The underlying interface might support
+ * jumbo frames.
*/
if (ifr-ifr_mtu ETHERMTU) {
error = EINVAL;
I belong to the religion which as that if the interface is doing
``jumbo frames'' than it's not doing ``Ethernet''. There are all
sorts of crocks which were perpretrated to allow bridging of FDDI and
Ethernet, and I have no intention of supporting the same crocks here.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: 3.1 upgrade problems
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: I have tried 3 times to make upgrade from 3.0-RELEASE to 3.1-CURRENT. The first time it coredumped while working on the lex stuff. The next 2 times it died in libexec someplace at roughly the same spot. Below is the result of make upgrade 2 filename on Sunday pm and Monday I had similiar problems. (Non-overclocked machine) What eventually worked was: -- rebuild kernel and install it, reboot -- 'make most' and 'make installmost' at the top level -- go into gnu/usr.bin/cc, 'make', 'make install' After that I was able to 'make world' just fine. Of course you have aout binaries, so that may make the whole thing a lot harder. Good luck. -- John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In article 31122.920241...@zippy.cdrom.com, Jordan K. Hubbard j...@zippy.cdrom.com 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-object-format OS. That means we _must_ be willing to abandon a.out support for new code. We will keep the legacy a.out libraries for old applications to link against, but we don't have to keep the ability to generate new ones. To do so would hold us back (_is_ holding us back) with very little to show for it. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In article 19990228152909.e2...@relay.nuxi.com, David O'Brien obr...@nuxi.com 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 desperately need to upgrade our compiler, and egcs looks like it's definitely the way to go. 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 are problems, don't jump to the conclusion that they are caused by compiler bugs. Linux also had problems building working kernels at first, but the problems turned out to be caused by incorrect clobber specs in asm statements. Such errors have also been found in the FreeBSD kernel. Some of them have been fixed, but maybe not all of them. In any case, the problems should be fixed at their source, not kludged around in the compiler. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In article pine.bsf.4.05.9902281913540.14644-100...@janus.syracuse.net, Brian Feldman gr...@unixhelp.org 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 Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In message 199903011709.jaa48...@vashon.polstra.com, John Polstra writes: In article 31122.920241...@zippy.cdrom.com, Jordan K. Hubbard j...@zippy.cdrom.com 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-object-format OS. That means we _must_ be willing to abandon a.out support for new code. We will keep the legacy a.out libraries for old applications to link against, but we don't have to keep the ability to generate new ones. To do so would hold us back (_is_ holding us back) with very little to show for it. 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 ? -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In article 19990228233542.a4...@relay.nuxi.com, David O'Brien obr...@nuxi.com 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 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 certainly unmaintained, and uncompilable with modern C++ compilers. (I.e., it does not conform to the C++ standard.) Libg++ is _ancient_. It pre-dated templates even. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
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
Re: gcc
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 j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Request for review: changes to if_vlan.c
!* 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 no longer using IFF_LINK1 for that purpose? I believe the old isa devices do not use if_media, but I could be wrong. (if_ep comes to mind) Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Request for review: changes to if_vlan.c
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 pass Are we certain that all drivers are now doing if_media and no longer using IFF_LINK1 for that purpose? I believe the old isa devices do not use if_media, but I could be wrong. (if_ep comes to mind) And some new PCI devices doesn't either because if_media is hopelessly narrowtrack for real world devices :-( -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
egcs and gcc
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++ 118829954776792
eg++ seems to produce faster executables.
tomdean
== the code ==
#! /bin/sh
doit() {
echo # $1
$1
}
== the output ==
# g++ --version
2.7.2.1
# g++ -m486 -O2 -c hello.cc
# ls -l hello.o
-rw-r--r-- 1 tomdean users 972 Mar 1 09:33 hello.o
# g++ -m486 -O2 hello.cc -o hello
# ls -l hello
-rwxr-xr-x 1 tomdean users 7150 Mar 1 09:33 hello
# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), \
dynamically linked, not stripped
# strip hello
# ls -l hello
-rwxr-xr-x 1 tomdean users 5464 Mar 1 10:02 hello
# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), \
dynamically linked, stripped
# time hello
Hello, world.
0.07 real 0.05 user 0.02 sys
# eg++ --version
egcs-2.91.60
# eg++ -m486 -O2 -c hello.cc
# ls -l hello.o
-rw-r--r-- 1 tomdean users 1188 Mar 1 09:33 hello.o
# eg++ -m486 -O2 hello.cc -o hello
# ls -l hello
-rwxr-xr-x 1 tomdean users 299547 Mar 1 09:33 hello
# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), \
dynamically linked, not stripped
# strip hello
# ls -l hello
-rwxr-xr-x 1 tomdean users 76792 Mar 1 10:02 hello
# 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
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
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 to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Request for review: changes to if_vlan.c
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 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 no longer using IFF_LINK1 for that purpose? I believe the old isa devices do not use if_media, but I could be wrong. (if_ep comes to mind) 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 ways. I'm fairly sure that once you get over the grotty mess of code needed to use it in a given driver it will offer a much better solution than the IFF_LINK[0-2] in terms of interface media selection. The fact that ifconfig can present a standard interface to the user without them having to reference manual pages to determine the semantics of the various link flags in the context of each different driver is an obvious win.
Re: gcc
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 are problems, don't jump to the conclusion that they are caused by compiler bugs. I hope I wasn't giving the impression there were compiler bugs. I was trying to say, I don't know what we'll find. The EGCS gcc I was working on would't compile src/bin/cat due to printf0 issues, and wouldn't compile a kernel due to -fformat-extension. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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 file for each executable. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
mangled top?
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 Free Swap: 99M Total, 99M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 65280 /+'+(0.+ -22 -52 1863M 528K ? -64 0 0:00 82292418.16% 82292418.16% -170012768 operator -22 -52 0K 1052K ? -120 0 0:00 9709.72% 1354.00% 40910088 63126 3944M28K CPU0 0 0:00 3.00% 0.15% rpreter 0 40 -22 61505 0K44K ? 96 0 0:00 0.00% 0.00% 1852400240 /*'''0/) -22 65556 3850M *)''*00*,K ? 24 0 0:00 0.00% 20141420 1 daemon -22 -52 0K 23148K ? -120 0 0:00 0.00% 196979612.50% To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Request for review: changes to if_vlan.c
In message pine.bsf.4.02.9903011332370.15262-100...@sasami.jurai.net, 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 ways. Yes, but considering the low age of the interface, the fact that it was made so narrow-scope is a disgrace. Try to implement a E1 line with the full complement of options, including international bits and crc4 and what have you :-( It should have been done with a simple ascii string instead. The drivers are much better at chewing on it than the generic code, it would be simpler to understand, simpler to implement, you wouldn't need to rebuild ifconfig all the time and it would be vastly more flexible. Anyone who thinks this sounds like a replay from when I stuck my fingers in sysctl some years back are right. GRUMBLE For some reason, some people around our camp-fire, have a hard time understanding that compiletime enumeration of potential options is a concept that died with the VAX Handbook 1978 edition. /GRUMBLE Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Request for review: changes to if_vlan.c
Of all the gin joints in all the towns in all the world, Garrett Wollman had to walk into mine and say: On Sat, 27 Feb 1999 23:37:10 -0500 (EST), Bill Paul wp...@skynet.ctr.columbia.edu 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 other thing while playing around today: when calling SIOCSETVLAN to disassociate a vlan interface with a real interface, the code should probably be removing the MAC address in addition to everything else. (The parent interface's address is added when the association is made, but not removed when the association is broken.) Also, I should point out that while if_vlan provides the necessary kernel hackery to implement VLANs, there isn't any user space utility for configuring vlan interfaces (ifconfig doesn't seem to have any vlan-specific code that I could see, and is no vlanconfig). I stopped development on vlan(4) when the switch we had that spoke 802.1Q was returned to the vendor at the end of our demo period. I have 28 on order right now, and should resume work on the driver after I get those switches deployed. For interfaces like yours, I would have preferred a subinterface mechanism, but I never had the time to implement that. Well... correct me if I'm wrong, but the current code looks like it does implement subinterfaces of a fashion. I could hack the driver to do what if_vlan.c does, but why do that if if_vlan.c already exists and does almost exactly what I need it to do. Care to implement GVRP while you're at it? Care to tell me what that is? :) (No, I don't really want to do it now, whatever it is.) There also is no vlan(4) man page. See above. I could probably write them myself, if you like. otherwise I'm going to take it upon myself to hack up ifconfig and write the man pages myself. I believe ifconfig is the wrong program for the task. There should be a separate vlanconfig program. (I wrote one, but it's on my laptop where I can't conveniently get to it right now.) I don't know about that. It seems to me ifconfig is precisely the right program to use for this task. I already hacked up a local copy of ifconfig to support it: router3# ./ifconfig vlan0 vlan 1234 vlandev ti0 router3# ./ifconfig vlan0 vlan0: flags=1843UP,BROADCAST,RUNNING,SIMPLEX,LINK0 mtu 1496 ether 00:60:08:21:53:6c vlan: 1234 parent interface: ti0 Took me only about an hour or so to do it (and I was watching TV at the time). Tell me why a separate program is preferable. There are a couple of areas where vlan(4) needs to get some help from the underlying driver: - Promiscuous mode doesn't work at all. It ought to be possible to put just a specific VLAN into promiscuous mode, without affecting all the others. This probably involves repeating all of the BPF does-this-packet-look-like-mine? gluck from the physical interface drivers. Hm. Well, it seems to me that the real problem is that to get promiscuous mode for the vlan interface, you have to put the parent in promiscuous mode too. You can do that, but then the parent interface driver gets hit with extra traffic that it doesn't want. - Multicast is similarly broken (and a more serious weakness). There needs to be a mechanism to pass multicast group membership down to the underlying driver. It may also be necessary to do duplicate suppression, which is a real challenge. It may not be that hard. I could probably do it, if you wanted me to. I wouldn't enjoy it, but I could do it. !* 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 no longer using IFF_LINK1 for that purpose? I think you may have missed the point (or maybe I didn't explain it well). I want to set the LINK1 bit on the _VLAN_ interface (vlan0, etc...), _NOT_ the parent interface. The problem is that the parent doesn't want packets with the ethernet vlan header on them, and we need some way to tell the vlan intertface Don't bother with rewriting the packet header; the parent interface will do it for you. Using the LINK1 (actually, I probably should have said LINK0; LINK1 was just the first thing that popped into my mind last night). The vlan interfaces don't use ifmedia so there is no conflict. The idea is, the user (er, admin) knows that he's going to be attaching to a parent device that can handle vlan header mangling internally, so he configures the vlan interfaces attached to this particular parent with a LINK flag that tells it skip the header mangling. Nothing gets changed on the parent interface. Grammar fault -- core dumped. (The wording was correct as it was.) That's why I didn't commit anything yet.
Re: Request for review: changes to if_vlan.c
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 with the full complement of options, including international bits and crc4 and what have you :-( True, but try restricting yourself to using only the permutations available with IFF_LINK[0-2]. I'm sure that your E1 line driver will have a subset of options that are valid in the context if ifconfig. Other options are probably not necessary to present to the user via ifconfig and should be presented via some other means (sysctl?). It should have been done with a simple ascii string instead. The drivers are much better at chewing on it than the generic code, it would be simpler to understand, simpler to implement, you wouldn't need to rebuild ifconfig all the time and it would be vastly more flexible. Indeed. My initial reply was rebuting your implied 'if_media sucks so we shouldn't attempt to convert the legacy code that uses IFF_LINK[0-2] to if_media'. While your are correct in your analysis of the shortcomings of if_media, shooting down this idea on those merits is not productive. Until a better solution for if_media is available, the if_media code does work and is a viable solution for a fairly specific class of problems. IFF_LINK[0-2] is even more broken than if_media. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
John Polstra said: In article 19990228152909.e2...@relay.nuxi.com, David O'Brien obr...@nuxi.com 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 desperately need to upgrade our compiler, and egcs looks like it's definitely the way to go. 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 are problems, don't jump to the conclusion that they are caused by compiler bugs. Linux also had problems building working kernels at first, but the problems turned out to be caused by incorrect clobber specs in asm statements. Such errors have also been found in the FreeBSD kernel. Some of them have been fixed, but maybe not all of them. In any case, the problems should be fixed at their source, not kludged around in the compiler. 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 FreeBSD uses, the kernel will most often build and work. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 to act more like the version of GCC that FreeBSD uses, the kernel will most often build and work. I'd like to experiment ... Next time you go to the trouble of making a kernel with egcs, could you make a few notes on those changes, and post them? Thanks. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 this topic so far and what I ended up releasing as compat22 was just a snapshot of hub's a.out libraries. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CALL FOR TESTERS of new ATA/ATAPI driver..
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 well as ISA devices without all the hackery in ide_pci.c to make PCI devices look like ISA counterparts. It doesn't have the excessive wait problem on probe, in fact you shouldn't notice any delay when your devices are getting probed. Probing and attaching of devices are postponed until interrupts are enabled (well almost, not finished yet for disks), making things alot cleaner. Improved performance, although DMA support is still WIP and not in this pre alpha release, worldstone is faster with the new driver compared to the old even with DMA. So what does it take away: There is NO support for old MFM/RLL/ESDI disks. There is NO support for bad144, if your disk is bad, ditch it, it has already outgrown its internal spare sectors, and is dying. For you to try this out, you will have to modify your kernel config file to use the ata controller instead of all wdc? entries. example: # for a PCI only system (most modern machines) controller ata0 device atadisk0# ATA disks device atapicd0# ATAPI CDROM's device atapist0# ATAPI tapes #You should add the following on ISA systems: controller ata1at isa? port IO_WD1 bio irq 14 controller ata2at isa? port IO_WD2 bio irq 15 You can leave it all in there, the system knows how to manage. For now this driver reuses the device entries from the old system (that will probably change later), but remember that disks are now numbered in the sequence they are found (like the SCSI system) not as absolute positions as the old system. Although I have tested this on all the systems I can get my hands on, there might very well be gremlins in there, so use AT YOU OWN RISK!! This is still WIP, so there are lots of rough edges and unfinished things in there, and what I have in my lab might look very different from whats in CVS at any given time. So please have all eventual changes go through me, or chances are they just dissapears... I would very much like to hear from you, both good and bad news are very welcome. Enjoy!! -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 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: # 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/cc # cd /usr/src remove cc from /usr/src/gnu/usr.bin/Makefile SUBDIR list remove libstdc++ and libobjc from /usr/src/gnu/lib/Makefile SUBDIR list Then make the world and the kernel. I also haven't noticed that the executables are any smaller or larger either way, and I've captured a fair amount of cc -v output to ensure that egcs is, in fact, the compiler being used. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 drop-in egcs. I expect to put it up for FTP this evening. (libstdc++ still needs a little bit more work) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 unsubscribe freebsd-current in the body of the message
Re: gcc
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 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: Okay, I guess I have been missing something :-). -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 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: Okay, I guess I have been missing something :-). Keep in mind that a whole bunch of stuff connected with kernel initialization has been changed lately. It may be simply that you're dealing with an older vintage kernel. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 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. I'd like to experiment ... Next time you go to the trouble of making a kernel with egcs, could you make a few notes on those changes, and post them? Okay, but JKH isn't having troubles... Hmmm... I do work with the latest CVS checkout on egcs, so there could be a minor difference there. I might play with it tonight, and I do have a generally working copy of egcs-current right now... If it isn't tonight, will be tomorrow. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 the initialization 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: Okay, I guess I have been missing something :-). Keep in mind that a whole bunch of stuff connected with kernel initialization has been changed lately. It may be simply that you're dealing with an older vintage kernel. Ahhaaa... That must be it -- I have a parallel track VM system project going. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In article local.mail.freebsd-current/15359.920308...@critter.freebsd.dk you write: In message 199903011709.jaa48...@vashon.polstra.com, John Polstra writes: In article 31122.920241...@zippy.cdrom.com, Jordan K. Hubbard j...@zippy.cdrom.com 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-object-format OS. That means we _must_ be willing to abandon a.out support for new code. We will keep the legacy a.out libraries for old applications to link against, but we don't have to keep the ability to generate new ones. To do so would hold us back (_is_ holding us back) with very little to show for it. 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 ? How about getting profiling working for ELF kernels before before completely abandoning a.out? -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 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: # 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/cc # cd /usr/src remove cc from /usr/src/gnu/usr.bin/Makefile SUBDIR list remove libstdc++ and libobjc from /usr/src/gnu/lib/Makefile SUBDIR list Then make the world and the kernel. I also haven't noticed that the executables are any smaller or larger either way, and I've captured a fair amount of cc -v output to ensure that egcs is, in fact, the compiler being used. :) Didn't realize that was all there was. Thanks a lot, Jordan, I will start doing egcs testing tonight, and from now on, using the latest egcs port (fetching now). +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: mangled top?
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.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
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 kernel. : :Is it not possible in such cases to simply detect the deadlock, and kill :one of the user processes involved in the deadlock, thus releasing one :of the resources involved in the deadlock? Then you would log :diagnostic information and let the system continue normally Most of the deadlocks remaining in the kernel are more complex and often cannot be detected without significant new work Detecting the loop is the hard part. This is known as 'deadlock detection'... ... In FreeBSD's case, the issue is somewhat more complex due to things that are not strictly locks causing deadlocks - such as a low memory condition causing a process holding an inode lock to block and then the syncer blocking on the same inode. The syncer is thus unable to run and thus unable to sync the dirty buffers clogging memory to disk. Things like that. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
controllerata0 deviceatadisk0# ATA disks deviceatapicd0# ATAPI CDROM's After (fastest(!!!)) boot: $ dmesg .. chip1: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.7.0 ata-pci0: Intel PIIX4 IDE controller rev 0x01 on pci0.7.1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ... ad0: FUJITSU MPA3026AT/9147 ATA-3 disk at ata0 as master ad0: 2503MB (5126964 sectors), 5086 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue ad1: WDC AC21200H/05.01E05 ATA-? disk at ata1 as master ^ ad1: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 0 depth queue acd0: MATSHITA CR-581-M/106A CDROM drive at ata1 as slave acd0: drive speed 689KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked changing root device to ad0s1a . ATA-? ??? ^ Does it right? How i can create ad0s1a etc. slises? i can't find anythink in /usr/src/etc/etc.i386/MAKEDEV... Rgdz, Sergey A. Osokin, o...@etrust.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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/lib/libstdc++.so.2 (0x28093000) libm.so.2 = /usr/lib/libm.so.2 (0x280ce000) libc.so.3 = /usr/lib/libc.so.3 (0x280e9000) # eg++ -m486 -O2 hello.cc -o hello # ldd hello hello: libm.so.2 = /usr/lib/libm.so.2 (0x2805e000) libc.so.3 = /usr/lib/libc.so.3 (0x28079000) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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 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. tomdean == # g++ -m486 -O2 hello.cc -o hello # ldd hello hello: libg++.so.4 = /usr/lib/libg++.so.4 (0x28051000) libstdc++.so.2 = /usr/lib/libstdc++.so.2 (0x28093000) libm.so.2 = /usr/lib/libm.so.2 (0x280ce000) libc.so.3 = /usr/lib/libc.so.3 (0x280e9000) # eg++ -m486 -O2 hello.cc -o hello # ldd hello hello: libm.so.2 = /usr/lib/libm.so.2 (0x2805e000) libc.so.3 = /usr/lib/libc.so.3 (0x28079000) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Still NFS Problems
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 problem. .nfs798798 files appearing on server, program on client locks up in STAT 'D' according to top. The problem only occurs on read / write mounts (duh..). I only have my home partition writable as of right now. The easiest way to replicate it is to compile something large. i.e. make world from the client machine. Soon I'll just make my home directory read only too :) Any ideas? fixes? things I can show you? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
# 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*crtbeginS.o include/libobjc.a No shared libs! My Makefile has 'enable_shared = no'
Re: egcs and gcc
.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 thinks that eg++ should like against /usr/lib/libstdc++.so.2 which is plain WRONG. eg++ is totally incompatable with g++ 2.7.x. So what happens when you move an eg++ produced binary to a machine that doesn't have EGCS installed? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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/o EGCS installed? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
... 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
RE: mangled top?
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 :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
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? -- David Kelly N4HHE, dke...@nospam.hiwaay.net = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
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 _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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 then installs. Because people like a previous poster thinks that eg++ should like against /usr/lib/libstdc++.so.2 which is plain WRONG. eg++ is totally incompatable with g++ 2.7.x. So what happens when you move an eg++ produced binary to a machine that doesn't have EGCS installed? OK, but listing from my gcc-lib/i386-unknown-freebsd4.0/egcs-2.91.62 gives: SYSCALLS.c.XcrtbeginS.o libiberty.a cc1*crtend.olibobjc.a cc1obj* crtendS.o libstdc++.a cc1plus*f771* libstdc++.so@ collect2* include/libstdc++.so.2.9@ cpp*libg2c.alibstdc++.so.2.9.0* crtbegin.o libgcc.aspecs (I compiled this with the WANT_SHAREDLIBS on). It seems to make a libstdc++.so.2.9 my first guess is, we'd want to bump the number so that it fits the form for our loader (one rev number, not two) and use it like the old one. It's the new form, done for egcs, it should work, right? If you move it to a machine without version 3 installed, it'll complain, right? 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. That seems kind of a shame, doesn't it? I tried taking the gcj part out of the latest egcs snap, and dropping it inplace in the prerelease version. Cygnus supplies the tarball for the gcc/java directory separately (if you want it), bless them! It configures ok (I *think*) with --enable-java, but it won't finish compiling. It's Makefile isn't correct, doesn't have a rule for an object file gcj needs (lost the error listing, I just had a freezeup). I'm out of time tonight. I think you're telling me to redo my egcs install with the WANT_SHAREDLIBS off, right? And you're going to have the libstdc++ ported (I read that, right?) so I should just maybe be patient? +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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. I peroidically make a egcs-devel port just to keep up on things and see what changes I've submitted have made it into their tree. I'm out of time tonight. I think you're telling me to redo my egcs install with the WANT_SHAREDLIBS off, right? Either way should be ok for testing. And you're going to have the libstdc++ ported (I read that, right?) so I should just maybe be patient? Yep. :-) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 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: # 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/cc # cd /usr/src remove cc from /usr/src/gnu/usr.bin/Makefile SUBDIR list remove libstdc++ and libobjc from /usr/src/gnu/lib/Makefile SUBDIR list Then make the world and the kernel. I also haven't noticed that the executables are any smaller or larger either way, and I've captured a fair amount of cc -v output to ensure that egcs is, in fact, the compiler being used. :) - Jordan Doesn't this just rebuild the standard gcc compiler in /usr/obj/usr/tmp/bin as part of the tools build, then use that compiler to build world. The first builds are done with egcs then it moves over to gcc to build the world. by removing the above from the Makfiles just prevents them from getting built and installed in the final build. when I do /usr/obj/usr/src/tmp/bin/cc --version it comes out gcc 2.7.2.1 Or am I missing something here ?? = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
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 majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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 broken? I'm trying to rebuild it now to see what it then installs. Because people like a previous poster thinks that eg++ should like against /usr/lib/libstdc++.so.2 which is plain WRONG. eg++ is totally incompatable with g++ 2.7.x. So what happens when you move an eg++ produced binary to a machine that doesn't have EGCS installed? OK, but listing from my gcc-lib/i386-unknown-freebsd4.0/egcs-2.91.62 gives: SYSCALLS.c.XcrtbeginS.o libiberty.a cc1*crtend.olibobjc.a cc1obj* crtendS.o libstdc++.a cc1plus*f771* libstdc++.so@ collect2* include/libstdc++.so.2.9@ cpp*libg2c.alibstdc++.so.2.9.0* crtbegin.o libgcc.aspecs (I compiled this with the WANT_SHAREDLIBS on). It seems to make a libstdc++.so.2.9 my first guess is, we'd want to bump the number so that it fits the form for our loader (one rev number, not two) and use it like the old one. It's the new form, done for egcs, it should work, right? If you move it to a machine without version 3 installed, it'll complain, right? 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. That seems kind of a shame, doesn't it? I tried taking the gcj part out of the latest egcs snap, and dropping it inplace in the prerelease version. Cygnus supplies the tarball for the gcc/java directory separately (if you want it), bless them! It configures ok (I *think*) with --enable-java, but it won't finish compiling. It's Makefile isn't correct, doesn't have a rule for an object file gcj needs (lost the error listing, I just had a freezeup). You're not concerned about the freezeup? I'm out of time tonight. I think you're telling me to redo my egcs install with the WANT_SHAREDLIBS off, right? And you're going to have the libstdc++ ported (I read that, right?) so I should just maybe be patient? +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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-building phase. I want to continue to deal with that privately. I don't have enough data yet (it doesn't panic, it stops dead in the water about once every month for 2 months now). +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Still NFS Problems
: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 problem. .nfs798798 files appearing on server, program on client :locks up in STAT 'D' according to top. The problem only occurs on read / :write mounts (duh..). I only have my home partition writable as of right :now. : :The easiest way to replicate it is to compile something large. i.e. make :world from the client machine. Soon I'll just make my home directory read :only too :) Any ideas? fixes? things I can show you? When this happens, run 'dmesg' on the client. Does it report any problems near the end of the system messages? -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
vm_mmap.c change gives strange behavior
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_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 the make world, but nothing I could *obviously* see suggested that any magic like this was happening. If I have missed the obvious somewhere, mea culpa - I'll add some -v's to my CFLAGS and see what sort of compiler version output I get! - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 long. Kris - (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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 certainly unmaintained, and uncompilable with modern C++ compilers. (I.e., it does not conform to the C++ standard.) Libg++ is _ancient_. It pre-dated templates even. Netscape still uses libg++ /usr/local/netscape/netscape: [...] -lg++.4 = /usr/lib/aout/libg++.so.4.0 (0x10c5c000) -lm.2 = /usr/lib/aout/libm.so.2.0 (0x10c98000) -lstdc++.2 = /usr/lib/aout/libstdc++.so.2.0 (0x10cb2000) -lc.3 = /usr/lib/aout/libc.so.3.1 (0x10ce8000) And most will imho agree on the fact, that Netscape is in some ways useful :) -- # /AS/ a...@psa.at / PGP key available on request and from keys.pgp.com # # If jesus was never born, we would not have a Y2K problem.# To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs and gcc
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. For a while the port was based
on the EGCS devel tree so you would have seen the java bits in the past,
but not in a while. When a released version came out, so I changed the
port to use that one.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
Jonathan Lemon jle...@americantv.com 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-current in the body of the message
Re: gcc
On Mar 03, 1999 at 06:02:37AM +0100, Assar Westerlund wrote: Jonathan Lemon jle...@americantv.com 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 them, they allow the kernel to compile, but they don't seem to work. In particular, the entries made in the flat profile section are all out of whack. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
3.0-STABLE - 4.x ...
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.o: In function `lpt_release_ppbus':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x3c): undefined
reference to `ppb_release_bus'
lpt.o: In function `lptread':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x6b6): undefined
reference to `ppb_1284_negociate'
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x6f0): undefined
reference to `ppb_1284_read'
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x726): undefined
reference to `ppb_1284_terminate'
lpt.o: In function `lptwrite':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x7bb): undefined
reference to `ppb_write'
ioconf.o(.data+0x2ac): undefined reference to `lptdriver'
*** Error code 1
1 error
first thought was newer version of 'config', but results are the same...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: 3.0-STABLE - 4.x ...
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 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.o: In function `lpt_release_ppbus':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x3c): undefined
reference to `ppb_release_bus'
lpt.o: In function `lptread':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x6b6): undefined
reference to `ppb_1284_negociate'
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x6f0): undefined
reference to `ppb_1284_read'
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x726): undefined
reference to `ppb_1284_terminate'
lpt.o: In function `lptwrite':
/usr/src/sys/compile/thelab/../../dev/ppbus/lpt.c(.text+0x7bb): undefined
reference to `ppb_write'
ioconf.o(.data+0x2ac): undefined reference to `lptdriver'
*** Error code 1
1 error
first thought was newer version of 'config', but results are the same...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary:
scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
lptdriver undefined in kernel compile...
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../../../include
-DKERNEL -DVM_STACK -include opt_global.h -elf vers.c
loading kernel
ioconf.o(.data+0x2f0): undefined reference to `lptdriver'
*** Error code 1
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
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) ^^ Netscape uses a *A.OUT* libg++. We are an *ELF* system now. If you want to run Netscape (also a piece of a.out code) you would install the compat22 distribution bits. What we are talking about here has nothing to do with Netscape. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
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/cc
# cd /usr/src
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 the makefiles and then
define CC=/usr/bin/egcc
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
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.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
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 the makefiles and then
define CC=/usr/bin/egcc
I did this for a make buildworld, ie
make CC=egcc CFLAGS=-nostdinc -I/usr/include buildworld
Which worked, but blew up doing ld :-/
[ ... ]
printf '#include SYS.h\nRSYSCALL(clock_gettime)\n' clock_gettime.S
egcc -I/usr/include -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale
-DBROKEN_DES
-DYP -I/usr/obj/usr/src/tmp/usr/include -I/usr/src/lib/libc/i386 -c
clock_gettime.S -o
clock_gettime.o
printf '#include SYS.h\nRSYSCALL(clock_settime)\n' clock_settime.S
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:1215:
`FNM_FILE_NAME' undeclared (first use this
function)/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:1215:
(Each undeclared identifier is reported only once
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:1215:
for each
function it appears in.)*** Error code 1Stop.
*** Error code 1
Stop.
etc
I haven't looked at it any further though.
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
the current kernel
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 what caused the crashes, but they don't happen with my 3 day old kernel, and they happen with my 5 minute old kernel. Thanks Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
It seems oZZ!!! wrote: controller ata0 device atadisk0# ATA disks device atapicd0# ATAPI CDROM's After (fastest(!!!)) boot: $ dmesg .. chip1: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.7.0 ata-pci0: Intel PIIX4 IDE controller rev 0x01 on pci0.7.1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ... ad0: FUJITSU MPA3026AT/9147 ATA-3 disk at ata0 as master ad0: 2503MB (5126964 sectors), 5086 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue ad1: WDC AC21200H/05.01E05 ATA-? disk at ata1 as master ^ ad1: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 0 depth queue acd0: MATSHITA CR-581-M/106A CDROM drive at ata1 as slave acd0: drive speed 689KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked changing root device to ad0s1a . ATA-? ??? ^ Does it right? Yup, that because the drive doesn't report what version the of the ATA spec its conformant to. How i can create ad0s1a etc. slises? i can't find anythink in /usr/src/etc/etc.i386/MAKEDEV... Thats because the are not there yet, just use wd0 wd1 etc etc that will work fine , and makes it easier fot people to test the new setup without too much changing around. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
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.T. stuff that some vendors advertise? There is work underways to standardise a log function on ATA drives, I'm not sure if any has it yet. I plan to support some of what all this gives you. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
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 well.. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
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... Good work, no more stinky delay :-) Thanks!, and I hate delays too :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
