Re: Where is FreeBSD going?
Matthew Dillon wrote: interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. My thoughts exactly. Every time I have this kind of argument, be it on irc or in a mailing list, I get told that Sun needed X years to do the fine grained locks in Solaris and other similar crap. Solaris was possible because Sun could throw more engineers at the problem if needed. FreeBSD is not in such situation. How many people have intimate knowledge of the VM subsystem? How many people besides John Baldwin have ever touched the SMPng code? I don't think anybody has doubts about your programming-fu, btw :) serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, Agreed. Like I've said, the main problem I see is complexity. It wouldn't matter as much if there were 5-10 people with deep knowledge of SMPng, but with 1 or 2 hackers working on it, the chance that everything will be ever fixed is quite small. but there are a lot of things in there that people are going to want to rewrite in coming years, and rewriting by people other then the original authors is one of the reasons why we had so much trouble in the 2.x and 3.x days. Look at how little VFS has been touched in the It depends whether we're talking about evolutionary changes or revolutionary changes. Are you talking about radical changes like e.g. moving from the BSD scheduler to ULE or more like interface and code refactorization? In the former, yes, new bugs will be introduced, which leads again to the problem of too complex code managed by too few people. I mean, I don't think anyone can honestly say that the scheduler is 'done', or even close to done. Look at how long the original 42 scheduler IMHO ULE is making progress quite fast. I wouldn't rely on it for production, but so far is looks very good. non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). Yes, that's the main problem I see, not much on the scheduler side, but on the 6-trillion-mutexes side. See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. Makes me wonder if some of the solutions proposed by DragonFly could be ported to FreeBSD, but I doubt it will be done, since it's more or less admitting that the current solution is wrong. Yes, I mentioned DragonFly (how dare he!). Feel free to flame, I've become extremely efficient at adding people to /etc/postfix/access :-P Cheers, -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Discussion on the future of floppies in 5.x and 6.x
All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. FreeBSD/i386 is the only port left that generates install floppies. Their primary purpose is to fascilitate installing FreeBSD on systems where a CDROM is either not available or is incompatible with the 'Non-Emulated El Torito' boot method that we use on our CDs. Systems that cannot boot these CDs are typically those that are also not certified for WinNT4, Win2K, or WinXP. Thus, nearly all machines produced after 1997 can boot our CDs. It is certainly possible to run FreeBSD 5.x on machines of this and prior vintage, and I certainly do not want to dispute or question any motives here. However, the number of machines in this category is steadily declining as time goes on, while the effort put into supporting install floppies seems to be on the rise. I certainly do not want to orphan these machines, so we need to find a compromise. One solution is to find a dedicated 'floppy maintainer' that will frequently assess the floppies during the normal developement periods and work closely with the Release Engineering team to ensure that there are few surprises when it's time to cut a release. I would expect this person to develop and execute a test plan that covers all of the common aspects of installing via floppy: basic sanity checks, loading drivers, installing via the various mechanisms, etc. This person should also be comfortable with modifying makefiles and the sysinstall source. The other solution is to replace install floppies with an 'Emulated El Torito' CD image. I'm not going to go into the differences between 'non-emulated' and 'emulated' except to say that 'emulated' is the method used on FreeBSD 4.x (and prior), Win95, and Win98. Virtually every system in existance that supports a CDROM supports this method. This image would contain the loader, kernel, and MFS root, just like the current 'bootonly.iso' image, but would be configured for emulated booting. Users could download this image, burn it, boot it, and then install FreeBSD just like they normally would. Of course this adds the requirement of needing a CD burner, but these devices are becoming common enough that it could be a reasonable expectation. Switching to this method doesn't entirely remove the headache of release floppies, but it does make it signficantly easier to deal with them. The 'emulated' method actually uses a 2.88MB floppy image that combines the first two 1.44MB floppies that we traditionally produce. By combining them, we have a bit more flexibility since the driver modules that are on the second floppy can go back into the kernel image and benefit from the compression that happens there. So, this is something to consider before 5.3. After that, we are stuck with the consequences of whatever we choose (or don't choose) for the entire 5.x lifespan. I do not cherish the thought of fighting floppies for another 2-3 years. I'm happy to work with someone who steps forward and is committed to maintaining the floppies as they are today. Otherwise, we need to seriously consider the alternative. Thanks, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. I agree the ports tree has not been completely open for as long as it should be recently. This is due to unforeseen problems that resulted in significant delays for both 4.9-RELEASE and 5.2-RELEASE. It's difficult to see how this could have been handled any better. Hopefully there will be fewer problems with future releases. Non-committers can help here by testing -STABLE and -BETA snapshots more extensively so that more problems are ironed out before the ports tags are laid down. (An alternative might be to delay the ports tagging until later in the release cycle, but I suspect that is just as likely to cause problems by having last minute ports breakages cause delays). Limitations of CVS don't exactly help either. The fact that you need direct access to the repository to be able to copy a tree with history (repocopy) as opposed to this operation being part of the interface[1], which means being lucky enough to find a committer, and get them commit the stuff within the blink of an eye ports is open, further constrains people's ability to work on FreeBSD with some satisfaction. I'm not sure what is meant by this paragraph. CVS doesn't support renaming files or directories - which can be a nuisance. As used within the Project, repocopy means manually copying parts of the repository to simulate file/directory duplication or renaming. This ability is restricted to a very small subset of committers - normal committers have to request repocopies as do non-committers. OTOH, replicating the complete FreeBSD CVS repository is trivial via either CVSup or CTM and both procedures are documented in the handbook. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: So, this is something to consider before 5.3. After that, we are stuck with the consequences of whatever we choose (or don't choose) for the entire 5.x lifespan. I do not cherish the thought of fighting floppies for another 2-3 years. I'm happy to work with someone who steps forward and is committed to maintaining the floppies as they are today. Otherwise, we need to seriously consider the alternative. Scott, While it is indeed true that most machines since 1997 will support this CD format, please take in to account: There are lots of machines with no CD drives: Slimline machines a la dell/compaq/hp/gateway Many corporate workstations Laptops Machines older than 1997 (this is mostly anything early PII chips and older, of which there are still a lot). Freebsd does work great on old hardware :) I'm sure there are others I can't think of at almost midnight.. :) I understand it is difficult to maintain the floppies. I wish I understood them better :-) Is it not possible to have ftp install floppies, which do nothing more than simple FTP installations? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
: See? I didn't mention DragonFly even once! Ooops, I didn't mention : DFly twice. oops! Well, I didn't mention it more then twice anyway. : :Makes me wonder if some of the solutions proposed by DragonFly could be :ported to FreeBSD, but I doubt it will be done, since it's more or less :admitting that the current solution is wrong. : :Yes, I mentioned DragonFly (how dare he!). Feel free to flame, I've :become extremely efficient at adding people to /etc/postfix/access :-P : :Cheers, :-- : Miguel Mendez [EMAIL PROTECTED] I think the correct approach to thinking about these abstractions would be to look at the code design implifications rather then just looking at performance, and then decide whether FreeBSD would benefit from the type of API simplification that these algorithms make possible. The best example of this that I have, and probably the *easiest* subsystem to port to FreeBSD (John could probably do it in a day), which I think would even wind up being exremely useful in a number of existing subsystems in FreeBSD (such as the slab allocator), would be DFly's IPI messaging code. I use the IPI messaging abstraction sort of like a 'remote procedure call' interface... a way to execute a procedure on some other cpu rather then the current cpu. This abstraction allows me to execute operations on data structures which are 'owned' by another cpu on the target cpu itself, which means that instead of getting a mutex, operating on the data structure, and releasing the mutex, I simply send an asynch (don't wait for it to complete on the source cpu) IPI message to the target cpu. By running the particular function, such as a scheduling request, in the target cpu's context, you suddenly find yourself in a situation where *NONE* of the related scheduler functions, and there are over a dozen of them, need to mess with mutexes. Not one. All they need to do to protect their turf is enter a critical section for a short period of time. The algorithm simplification is significant... you don't have to worry about crossing a thread boundary, you can remain in the critical section through the actual switch code which removes a huge number of special cases from the switch code. You don't have to worry about mutexes blocking, you don't have to worry about futzing the owner of any mutexes, you don't have to worry about the BGL, you don't have to worry about stale caches between cpus, the code works equally well in a UP environment as it does in an SMP environment... cache pollution is minimized... the list goes on an on. So looking at these abstractions just from a performance standpoint misses some of the biggest reasons for why you might want to use them. Algorithmic simplification and maintainability are very important. Performance is important but not relevant if the resulting optimization cannot be maintained. In anycase, I use IPIs to do all sorts of things. Not all have worked out... my token passing code, which I tried to use as a replacement for lockmgr interlocks, is pretty aweful and I consider it a conceptual failure. But our scheduler, slab allocator, and messaging code, and a number of other mechanisms, benefit from huge simplifications through their use of IPI messaging. Imagine... the messaging code is able to implement its entire API, including queueing and dequeueing messages on ports, without using a single mutex and (for all intents and purposes) without lock-related blocking. The code is utterly simple yet works between cpus, between mainline code and interrupts with preemption capabilities, and vise-versa. There are virtually no special cases. Same with the slab code, except when it needs to allocate a new zone from kernel_map, and same with the scheduler. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. It seems to me that we could split more out into modules, and/or add more disks of modules (maybe categorize a storage device modules disk, a network drivers modules disk, etc, keeping just the more common devices in the main kernel). Last I saw, the current system only created a single modules disk, which was a godsend to a kernel overflowing one disk, but as we add more and more stuff becomes another, albeit larger, noose. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 01:58:11AM -0600, Matthew D. Fuller wrote: On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. My personal descision was to use Compactflash Media in IDE mode. They are easy to modify with your notebook. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Well, using the emulated boot cd would only be about 3MB and would only contain the sysinstall environment, so you'd still be installing over the LAN or whatever. As someone else pointed out, it is apparently possible to use Compact Flash as the media instead of a CD, so that is something to consider also. It seems to me that we could split more out into modules, and/or add more disks of modules (maybe categorize a storage device modules disk, a network drivers modules disk, etc, keeping just the more common devices in the main kernel). Last I saw, the current system only created a single modules disk, which was a godsend to a kernel overflowing one disk, but as we add more and more stuff becomes another, albeit larger, noose. For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Hi, Matthew D. Fuller wrote on Thu, Jan 08, 2004 at 01:58:11AM -0600: [..] And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. That's no point, as you can use a CD-RW, so no media is wasted. Install over LAN is done anyway, as Scott mentioned only the basic boot/install-strap is put into the emulated image. However, I second the point, that there is recent hardware around which cannot have a CD-Drive attached, but a floppy drive, because of space constraints. On the other hand, I guess such systems are able to boot over the network. I'd love to see a integrated boot and installation procedure that utilizes PXE (or any other network boot method) and advocates it. (In this regard I just love Suns). my 0.02¤, Daniel -- IRCnet: Mr-Spock - Work is for people, who don't surf - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 05:23:30PM -0500, Garance A Drosihn wrote: I would add that I've been running almost exclusively on 5.x for over a year now (except for one machine which I have not rebooted in over a year...). There have been some *very* painful transitions at various times, but once I get past the transitions the system has been quite stable. (fwiw, in my case, I am only running on desktop systems). Well, what you've told me there is: - 5.x is a pain in the arse to make the transition to - You're not running FBSD in the same environment I am - But for you that's all OK, and I should agree :-) Which doesn't get us much further down the road, but thanks for the input. I have two boxes here that need to go into a co-lo tomorrow, and therefore need to be installed today. 5.2-RC2 does seem to be holding out better than expected now I've had it up for a week or so on a dev machine. I'm tempted to whirl it out on these boxes, but if they die I'm screwed. Dunno. I'm not sure if I can trust you, Des, and others when it's my cahunas on the line. So, once we stop making major API/ABI changes and the branch is truly stable (with a 6.x branch for new cutting-edge developments), I personally am quite confident that 5.x will be a stable, production-quality system. And there are a number of features in 5.x that I think are tremendous advantages -- especially for boxes in a production setting. It might be worth somebody getting those written up and sent out to -advocacy to start the ball rolling, as per another mail somewhere in this monstrous thread. My guess is you're going to have a large bar tab at the next BSDcon... Certainly I hope so! I've run tabs at the bar at conferences before, and I'm sure I'll do it again... -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Hi Matthew and others I think that we all can find reasons to (or not to) use floppies, but I don'tthink that was the issue in Scott's mail. The generational change from 4.x to 5.x where the majority of the code hasbeen rewritten (in my opinion an extremly healthy sign for any kind of serious development) has taken it's toll on the develepors and commiterstime and energy, which is why they need to fix some kind of order of priorityin their future work. Evolution has caught up beasts as mammuth's, Cherry Coke and floppies. I for one, won't miss them and would rather have the developer team spenttheir time on security, SMP, GEOM and other vital and important issues. Best regards /per [EMAIL PROTECTED] On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. It seems to me that we could split more out into modules, and/or add more disks of modules (maybe categorize a storage device modules disk, a network drivers modules disk, etc, keeping just the more common devices in the main kernel). Last I saw, the current system only created a single modules disk, which was a godsend to a kernel overflowing one disk, but as we add more and more stuff becomes another, albeit larger, noose. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Roman Neuhauser [EMAIL PROTECTED] writes: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. I strongly suspect that this could be at least partially alleviated by giving portmgr more package-building hardware to play with. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of Scott Long, and lo! it spake thus: For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Well, that's why I suggest more. Have a network cards floppy, and a mass storage devices floppy, etc. We should be able to fit the half-dozen most common network cards, the ata drivers, and a half dozen of the more common SCSI drivers on the boot kernel. That'll get us far enough to be able to load the drivers off the other disks, as well as install with just that on many systems. It won't necessarily be the prettiest process, but I'm in favor of letting the floppies be a bit ugly, or even explicitly moving them to experienced users only status. I just find them far too convenient, as well as ubiquitous, to see them sent into the Great Bitbucket In The Sky yet. If somebody wants pretty and not have to fudge around to find the driver to load for my RAID controller, THEN let 'em download the CD :) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of Scott Long, and lo! it spake thus: For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Well, that's why I suggest more. Have a network cards floppy, and a mass storage devices floppy, etc. We should be able to fit the half-dozen most common network cards, the ata drivers, and a half dozen of the more common SCSI drivers on the boot kernel. That'll get us far enough to be able to load the drivers off the other disks, as well as install with just that on many systems. It won't necessarily be the prettiest process, but I'm in favor of letting the floppies be a bit ugly, or even explicitly moving them to experienced users only status. I just find them far too convenient, as well as ubiquitous, to see them sent into the Great Bitbucket In The Sky yet. If somebody wants pretty and not have to fudge around to find the driver to load for my RAID controller, THEN let 'em download the CD :) Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with signal handling and threads (fbsd49R)
Hi,
I've got a problem with signal handling and threads.
I've reproduced the problem in a simple code.
Description of program:
install a signal handler SIGINT.
create a thread that do nothing except waiting.
main thread use poll to wait forever [ poll(,,-1) ].
user has too crtl-C to interrupt poll
after 5 ctrl-C, loop is over and main-thread signals sub-thread to
stops.
In fact, it appears not to work correctly: after one ctrl-C, user has to
press ctrl-C twice before poll returns with errno=EINTR !!
If the thread creation is removed from code, the expected behavior is
seen : the program works fine.
If I replace the poll by sigsuspend() the program works fine too.
Is there something wrong with poll function ?
Maybe something is wrong in the approach or in the source code !
Any suggstions are wellcome.
here is sample C code :
___
test_thread_signals.c
___
#define __EXTENSIONS__
#define _REENTRANT/* basic first 3-lines for threads */
#define _GNU_SOURCE
#define _THREAD_SAFE
#define _POSIX_PTHREAD_SEMANTICS
#include stdio.h
#include stdlib.h
#include pthread.h
#include errno.h
#include unistd.h
#include poll.h
pthread_mutex_t mutex;
pthread_t thread;
pthread_cond_t condition;
void *run(void *argp);
static void handler(int);
int main(int argc, char **argv)
{
pthread_attr_t attr;
register int i, res;
struct pollfd poll_fd;
sigset_t set;
signal(SIGINT, handler);
pthread_attr_init( attr );
pthread_attr_setdetachstate( attr, PTHREAD_CREATE_DETACHED);
pthread_mutex_init(mutex, 0);
pthread_cond_init(condition, 0);
/** comment the following line to see the normal behavior **/
pthread_create(thread, attr, run, 0);
pthread_attr_destroy( attr );
poll_fd.fd = -1;
poll_fd.revents=0;
poll_fd.events=0;
sigemptyset(set);
puts(main: begin loop);
for(i=0; i5; i++)
{
/** wait forever **/
res = poll( poll_fd, (unsigned long)1, -1 );
/** using sigsuspend ... **/
/* res = sigsuspend(set); */
if( res == -1 errno==EINTR )
{
puts(ctrl-C received);
}
printf(res = %d - errno = %d \n, res, errno );
}
puts(send sub thread term signal);
pthread_cond_signal(condition);
puts(main end);
return 0;
}
void *run(void *argp)
{
puts(begin sub thread and wait);
pthread_mutex_lock(mutex);
pthread_cond_wait(condition, mutex);
pthread_mutex_unlock(mutex);
puts(end sub thread);
return 0;
}
void handler(int signo)
{
}
___
compilation with
$ gcc -g2 -ansi -Wall -o test_thread_signals.o -c test_thread_signals.c
$ gcc -o test_thread_signals -pthread test_thread_signals.o
here is the results with the original code :
$ ./test_thread_signals
main: begin loop
begin sub thread and wait
^Cctrl-C received
res = -1 - errno = 4
^C^Cctrl-C received
res = -1 - errno = 4
^C^Cctrl-C received
res = -1 - errno = 4
^C^Cctrl-C received
res = -1 - errno = 4
^C^Cctrl-C received
res = -1 - errno = 4
send sub thread term signal
main end
and the trace with no sub thread :
$ ./test_thread_signals
main: begin loop
^Cctrl-C received
res = -1 - errno = 4
^Cctrl-C received
res = -1 - errno = 4
^Cctrl-C received
res = -1 - errno = 4
^Cctrl-C received
res = -1 - errno = 4
^Cctrl-C received
res = -1 - errno = 4
send sub thread term signal
main end
Regards.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:45:25PM -0600, Ryan Sommers wrote: On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: 1) Allow for paid development for a specific bug/feature - Setup some program that allows users like myself to pay for a developers time to fix a specific bug. The company I work for would easily pay serious dollars to fix our SMP problems with 4.X. Unfortunetly, getting someone's attention that has a great understanding of the OS is hard to find without rude remarks and what-not. You could even extend it as far as saying we will promote this PR to the top of the list of tasks if you pay us XX dollars. Or maybe, the more you pay the higher you go. This would reassure the user base that things CAN get done if needed and also let the developer/bug fixer feel like they can make money and have some fun. It will also bring in money for the project as part of that money could go back into the Project. You could easily setup a pool mailling list (like -requests) which someone like myself would email a request with the problem description (or PR). If a developer is interested in tackling the problem for money, we could privately negotiate a price. The same can be done for driver development and others. Make it a Donation for a specific request. I don't want to give money to some Foundation where money can be thrown around in the wrong areas. I want to pay the developer personally for their efforts. ( I feel the same should be done with our taxes as well ;-) I really don't like the idea of making this a policy, or even some official part of the project. I think this might discourage some from contributing in hopes to be paid for it. I think a better solution for companies looking for this would be to post to the jobs@ mailing list noting that it is a temp job. I don't think giving priority to paying entities is a path the project should tread down. If someone needs FreeBSD developer work they should look for someone to hire. Something like this might also jeopardize the project's not for profit status. I think the jobs@ mailing list would be a better start. Absolutely. At least in Britain, the Project could then be seen as working as an agent which has the potential to cause problems that we don't need and probably would find very hard to deal with. Ceri -- pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-08 18:33:40 +1100: On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: Limitations of CVS don't exactly help either. The fact that you need direct access to the repository to be able to copy a tree with history (repocopy) as opposed to this operation being part of the interface[1], which means being lucky enough to find a committer, and get them commit the stuff within the blink of an eye ports is open, further constrains people's ability to work on FreeBSD with some satisfaction. I'm not sure what is meant by this paragraph. CVS doesn't support renaming files or directories - which can be a nuisance. As used within the Project, repocopy means manually copying parts of the repository to simulate file/directory duplication or renaming. This ability is restricted to a very small subset of committers - normal committers have to request repocopies as do non-committers. I somewhat lumped two things together there: * general port updates from lot of people going through a handful of committers, which on one hand helps QA by adding eye balls, but OTOH slows the process down. * repocopies go through a fraction of the abovementioned handful Now, I'm by no means advocating everybody should get ssh login on [dnp]cvs.freebsd.org; I just can't wait for the day when FreeBSD uses a SCM that handles tags and branches efficiently (so that people can freely create branches of areas they hack), that has permissions model with file- or directory-level granularity (so that people can be granted commit e. g. in /ports/x11-wm/openbox and nowhere else), etc. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 03:43:55AM -0700, Scott Long wrote: Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. The other big problem with removing floppies, is that not everyone has a cd burner. I wouldn't even say the majority of FreeBSD users have CD burners. I think someone mentioned this. I would love to be the 'floppy maintainer', but I know very little about the actual process and sadly don't have the time either :( -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with signal handling and threads (fbsd49R)
On Thu, 8 Jan 2004, rmkml wrote: Hi, I've got a problem with signal handling and threads. I've reproduced the problem in a simple code. Description of program: install a signal handler SIGINT. create a thread that do nothing except waiting. main thread use poll to wait forever [ poll(,,-1) ]. user has too crtl-C to interrupt poll after 5 ctrl-C, loop is over and main-thread signals sub-thread to stops. In fact, it appears not to work correctly: after one ctrl-C, user has to press ctrl-C twice before poll returns with errno=EINTR !! If the thread creation is removed from code, the expected behavior is seen : the program works fine. If I replace the poll by sigsuspend() the program works fine too. Is there something wrong with poll function ? No, it's your program. Why do you think the signal will only be delivered to the main thread and not the other (run) thread? If you want a particular thread to receive a signal, then you had better set up signal masks for all threads appropriately (or use sigwait()). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
I'm going to propose a different solution that was brought up about two years ago (although I can't find it now). You start with something like the CD boot image mentioned, that is a 3-5 Meg iso image that basically contains what is now on the floppies (perhaps with a few more drivers/modules) and nothing more. Downloading and burning to CD would be the primary method of install. Then, to replace the current floppy process, a new floppy installer is created. It may or may not be based on FreeBSD, but what it needs to be able to do is boot, load a network driver, configure the network, and ftp the above mentioned iso into ram, and then jump into the kernel from the iso as if it had been loaded from a CD. Yes, I'm grossly oversimplifing the process, but it removes all of sysinstall from the floppy, all the need for crunchgen and all that, as it should be fairly easy (again, perhaps not with a full kernel) to support a number of network drivers and a basic FTP client on a single floppy. The only real direct freebsd issue is to make the kernel able to boot itself from memory, and then treat that memory as a ram disc on boot. It would require a whole new floppy booter setup, but I can see other OS projects using something like this as well, so perhaps some cross work with NetBSD or OpenBSD, or even the Linux camp could make an open source load an image floppy, that since it just loaded an ISO could load about anything. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
At 07:47 PM 1/6/2004, Avleen Vig wrote: Advocacy is NOT a race Yes, it is. Linux is where it is today because it grabbed more buzz, sooner, than BSD. --Brett Glass ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. That might be technically true, but it's misleading and doesn't support the point you're trying to make. During this period the ports collection has only been frozen for a couple of weeks, and the majority of commit activities were not restricted for the rest of the period in question. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: if you find that something is inadequately documented, or unclearly documented, then you need to make specific suggestions on what should be done to improve the documentation. We *need* this kind of feedback to figure out how to make the docs better from the point of view of the target audience. Kris pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Thu, Jan 08, 2004 at 11:09:49AM +0100, Dag-Erling Sm?rgrav wrote: Roman Neuhauser [EMAIL PROTECTED] writes: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. I strongly suspect that this could be at least partially alleviated by giving portmgr more package-building hardware to play with. It's certainly true that we're lacking in build hardware for some non-i386 platforms (particularly sparc64), and this made it pretty tricky to build packages for 5.2 on those architectures (a full sparc64 build takes at least a month). I've heard some rumours of donated equipment waiting to be installed, but I don't know what the status of that is. Likewise, a 5.2 i386 build takes about a week, which means that the freeze *cannot* be shorter than this, even if everything goes perfectly (which, in practise, never happens). This time around, the freeze started on 23 Nov and was lifted on 3 Dec. That's 10 days, which is about as good as you could hope for. If we could build packages in - say - a day, we'd be able to cut the freeze time down further, although I expect the duration would become limited by the speed at which problems can be corrected. Every now and then we get offers of access to a machine here or a machine there to help with building packages. The main problem with donating machine resources is that there's limited space in the freebsd.org equipment racks, and the package build system currently needs LAN-equivalent connectivity between the machines. To be useful we'd either need a full cluster of faster machines located somewhere, or to find time to rewrite the build scripts to work efficiently with remote build resources. Kris pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 04:14:51AM -0600, Matthew D. Fuller wrote: On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of Scott Long, and lo! it spake thus: For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Well, that's why I suggest more. Have a network cards floppy, and a mass storage devices floppy, etc. We should be able to fit the half-dozen most common network cards, the ata drivers, and a half dozen of the more common SCSI drivers on the boot kernel. That'll get us far enough to be able to load the drivers off the other disks, as well as install with just that on many systems. Ideas are cheap, but someone's going to have to write the sysinstall code to do that (or any other modified scheme people might be able to come up with). Kris pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
Scott Long wrote: FreeBSD/i386 is the only port left that generates install floppies. Their primary purpose is to fascilitate installing FreeBSD on systems where a CDROM is either not available or is incompatible with the 'Non-Emulated El Torito' boot method that we use on our CDs. Systems that cannot boot these CDs are typically those that are also not certified for WinNT4, Win2K, or WinXP. Thus, nearly all machines produced after 1997 can boot our CDs. Are you aware that the FreeBSD CD:s (both 4.9 5.2) are not bootable on a CD-ROM connected via USB? Both try to boot but hangs somewhere in the loader. This is on our P4 Supermicro serverboards. As usual Win2K, 2K3 RedHat just works. An external USB2.0 connected Asus CD-RW drive (52x/24x/52x) with power supply costs about $70 so this is really nothing expensive or fancy today. If anybody can give me directions on how to debug this I'm willing to help. /Martin -- Martin Nilsson, CTO Founder, Mullet Scandinavia AB, Malmö, SWEDEN E-mail: [EMAIL PROTECTED], Phone: +46-(0)708-606170, http://www.mullet.se Our business is well engineered servers optimized for FreeBSD and Linux. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Anyone working on cobalt code?
This is by now old news, but I ws wondering if anyone had allready taken a look at the RAQ code Sun released under a BSD licence just before christmas. The source is available at http://open.cobaltqube.org/ THe readme is which is in the tarball looks like this: 23 December 2003 Thank you for downloading the Sun Cobalt Open Source RaQ550 v1.0 Distribution. LICENSES: All software in this distribution, except files contained in the kernel/ directory tree, are subject to the terms of the license file sun_bsd.txt located in the directory root of this distribution. All files contained in the kernel/ directory tree are subject to the terms of the license file gpl.txt located in the directory root of this distribution. The RaQ550 distribution is composed of many publicly available RPM software packages that can be downloaded in source or binary form from: ftp://ftp.cobalt.sun.com/pub/products/raq550/ This Sun Cobalt Open Source RaQ550 Distribution is a collection of source code not previously available to the public. The ui/ directory contains a snapshot of the sustained RaQ550 appliance front and back-end code as of September 2003. Majordomo has been removed from base-maillist.mod/src/majordomo/ due to license issues. It is easiest to expand this archive on an existing RaQ550 as the root user. Install ui/devel-tools/ by running the following commands: cd ui/devel-tools make make install bluelinq/ is the BlueLinQ server software that hosts distributions to the embedded BlueLinQ clients in the Sun Cobalt RaQ XTR, Qube3 and RaQ550. kernel/bwmgmt is the source to the traffic shaping kernel module This source is is licensed under the terms of the file gpl.txt included in the directory root of this distribution. cce/ is the Cobalt Configuration Engine, a custom dispatching database used by most of the appliance code in ui/ cce-shell-tools/ is a command line interface toolset for CCE. Enjoy, Will DeHaan [EMAIL PROTECTED] TODO - port this to your general purpose OS of choice (Debian and Suse street please) - use this code to help out every shop that supported Cobalt back in the day ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Thursday 08 January 2004 07:01, Bernd wrote:
Im mostly worried about having more than a single device with address 0.
You can't do this as long as another device gets initialized.
Therefor I thought disabling/enabling the port would be better, but I'm
wrong as the result is be the same.
With the changes I have made, it is only possible to let the USB stack reset
the device from the ATTACH routine of a driver. This should garantee that
there is only one device with addr==0 , since the probe attach routines are
only called from one process.
For my device driver I have made a small change to the USB Stack and I
have introduced the return code USB_ATTACH_NEED_RESET for drivers to
tell the USB Stack thee device needs to be re-enumerated. The stack then
automatically re-assigns the device it's address, and re-probes for
drivers. This way even two seperate drivers could be made : one with the
firmware and one with the real driver.
Is anyone interrested in a patch maybe?
Sounds interesting.
Have a look at the patch attached to this mail.
My idea is to let a driver upload the firmware from it's ATTACH routine and
after that return with USB_ATTACH_NEED_RESET. Since some devices really
require a reset to be sent to it and others only need to be re-configured,
the USB stack doesn't send the reset itself. The ATTACH function is
responsible for sending the reset to the device.
After getting the NEED_RESET response, the USB stack assumes the device is
ready and listening at addr==0 again. The stack re-reads the device
descriptor, sets the address again and tries another round of attaching
drivers. We give up after 5 rounds of NEED_RESET.
If anyone knows a more elegant way to achieve the same functionality, I'm open
to ideas :)
grtz,
Daandiff -ur usb.org/usb_port.h usb/usb_port.h
--- usb.org/usb_port.h Wed Oct 2 09:44:20 2002
+++ usb/usb_port.h Wed Jan 7 20:26:55 2004
@@ -435,6 +435,7 @@
/* Returns from attach */
#define USB_ATTACH_ERROR_RETURN return ENXIO
#define USB_ATTACH_SUCCESS_RETURN return 0
+#define USB_ATTACH_NEED_RESET return EAGAIN
#define USB_ATTACH_SETUP \
sc-sc_dev = self; \
diff -ur usb.org/usb_subr.c usb/usb_subr.c
--- usb.org/usb_subr.c Wed Jan 15 00:07:43 2003
+++ usb/usb_subr.c Wed Jan 7 22:50:20 2004
@@ -86,6 +86,9 @@
Static int usbd_print(void *aux, const char *pnp);
Static int usbd_submatch(device_ptr_t, void *, void *);
#endif
+Static usbd_status usbd_new_device2(device_ptr_t parent, usbd_bus_handle bus,
+ int depth, int speed, int port,
+ struct usbd_port *up);
Static void usbd_free_iface_data(usbd_device_handle dev, int ifcno);
Static void usbd_kill_pipe(usbd_pipe_handle);
Static usbd_status usbd_probe_and_attach(device_ptr_t parent,
@@ -131,6 +134,7 @@
SHORT_XFER,
STALLED,
INTERRUPTED,
+ NEED_RESET,
XXX,
};
@@ -888,6 +892,14 @@
uaa.ifaceno = ifaces[i]-idesc-bInterfaceNumber;
dv = USB_DO_ATTACH(dev, bdev, parent, uaa, usbd_print,
usbd_submatch);
+
+ if (dev-address == USB_START_ADDR) {
+#if defined(__FreeBSD__)
+device_delete_child(parent, bdev);
+#endif
+return (USBD_NEED_RESET);
+ }
+
if (dv != NULL) {
dev-subdevs[found++] = dv;
dev-subdevs[found] = 0;
@@ -958,7 +970,7 @@
* and attach a driver.
*/
usbd_status
-usbd_new_device(device_ptr_t parent, usbd_bus_handle bus, int depth,
+usbd_new_device2(device_ptr_t parent, usbd_bus_handle bus, int depth,
int speed, int port, struct usbd_port *up)
{
usbd_device_handle dev;
@@ -1099,6 +,12 @@
err = usbd_probe_and_attach(parent, dev, port, addr);
if (err) {
+ if (err == USBD_NEED_RESET) {
+ DPRINTFN(1,(usbd_new_device: device needs reset\n));
+ /* must set address back to what it was */
+ dev-address = addr;
+ }
+
usbd_remove_device(dev, up);
return (err);
}
@@ -1106,6 +1124,27 @@
usbd_add_dev_event(USB_EVENT_DEVICE_ATTACH, dev);
return (USBD_NORMAL_COMPLETION);
+}
+
+usbd_status
+usbd_new_device(device_ptr_t parent, usbd_bus_handle bus, int depth,
+ int speed, int ports, struct usbd_port *up)
+{
+ int retry = 0;
+ usbd_status err;
+
+ err = usbd_new_device2(parent, bus, depth, speed, ports, up);
+ while ((err == USBD_NEED_RESET) (retry++ 5)) {
+ DPRINTFN(1,(usb_new_device: re-enumerating device\n));
+ err = usbd_new_device2(parent, bus, depth, speed, ports, up);
+ }
+
+ if (retry == 5) {
+ DPRINTFN(1,(usb_new_device: giving up after 5 tries...\n));
+ return (USBD_NOT_CONFIGURED);
+ }
+
+ return err;
}
usbd_status
diff -ur usb.org/usbdi.h usb/usbdi.h
--- usb.org/usbdi.h Mon May 6 20:23:36 2002
+++ usb/usbdi.h Wed Jan 7 21:45:11 2004
@@ -66,6 +66,7 @@
USBD_SHORT_XFER, /* 16 */
USBD_STALLED, /* 17 */
USBD_INTERRUPTED, /* 18 */
+ USBD_NEED_RESET, /* 19 */
USBD_ERROR_MAX /* must be last */
} usbd_status;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 09:39:34AM -0500, Leo Bicknell wrote: It would require a whole new floppy booter setup, but I can see other OS projects using something like this as well, so perhaps some cross work with NetBSD or OpenBSD, or even the Linux camp could make an open source load an image floppy, that since it just loaded an ISO could load about anything. If I understand you right.. A floppy boot, which loads the absolutely basic stuff (network drivers, and some easy way to config the network) and then goes and grabs the installer would otherwise be on the current floppies and boots it? This sounds like a good solution - they we wouldn't have to worry about: If people have cd burners or not The size of the installer (for most practical purposes as long as the installer itself doesn't hit 600Mb :P) Compatibility with CD drives ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 01:22:38PM +0100, Martin Nilsson wrote: Are you aware that the FreeBSD CD:s (both 4.9 5.2) are not bootable on a CD-ROM connected via USB? Both try to boot but hangs somewhere in the loader. This is on our P4 Supermicro serverboards. As usual Win2K, 2K3 RedHat just works. An external USB2.0 connected Asus CD-RW drive (52x/24x/52x) with power supply costs about $70 so this is really nothing expensive or fancy today. Please do not assume that because it costs $70 it is universally availible. There are a lot of people who cannot afford this: the unemployed school children retired persons (sometimes) people with families to support :) Unfortuantely I feel this does need to be taken in to account here. While I totally empathise with Scott's problem and the lack of time to do things the way we have been, we need to appreciate that telling everyone to burn a CD to install FreeBSD (thus incur costs if you don't have a CD burner, and wouldn't need one if not to install FreeBSD) is not far from the You must pay us to buy this on CD approach (openbsd) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Chello blocking FreshPorts service
On 6 Jan 2004 at 9:24, Dan Langille wrote: For some months Chello has denied smtp service from the FreshPorts mail server. All queries to Chello regarding this matter have gone unanswered. $ telnet smtpgate.chello.at 25 Trying 213.46.255.2... Connected to smtpgate.chello.at. Escape character is '^]'. 421 viefep12-int.chello.at connection refused from [66.154.97.250] Connection closed by foreign host. This happens for all Chello domains I have tried. This means that Chello users are unable to use the FreshPorts notification service. For what it's worth, this also affect the FreeBSD Diary announcement mailing list. If anyone has contacts at Chello, please ask them to look into this. All attempts to get this resolved have been blocked. I've heard many stories about Chello standards of service. This situation validates everything I've heard. I have had some information from a third party. It appears that Chello are using xbl.selwerd.cx as a RBL. My research indicates that xbl.selwerd.cx should not be used as an RBL: http://mla.libertine.org/tmda-users/2002-11/msg00049.html Anyone here using xbl.selwerd.cx? -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Which would obviously mean that there would be lots of volunteers for the position of floppy maintainer? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. Floppies can go as far as I'm concerned, with the one proviso that we start shipping a /boot.config containing '-P'. Without floppies, the only ways to do a headless install are PXE and cutting your own release with that /boot.config in place, and not all machines can do PXE. Ceri -- pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 04:36:47PM +, Ceri Davies wrote: On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. Floppies can go as far as I'm concerned, with the one proviso that we start shipping a /boot.config containing '-P'. Without floppies, the only ways to do a headless install are PXE and cutting your own release with that /boot.config in place, and not all machines can do PXE. Actually, I'd like to go one further and suggest that we do this anyway. Ceri -- pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 10:52:08AM +0100, Daniel Lang wrote: Hi, Matthew D. Fuller wrote on Thu, Jan 08, 2004 at 01:58:11AM -0600: [..] And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. That's no point, as you can use a CD-RW, so no media is wasted. Install over LAN is done anyway, as Scott mentioned only the basic boot/install-strap is put into the emulated image. However, I second the point, that there is recent hardware around which cannot have a CD-Drive attached, but a floppy drive, because of space constraints. On the other hand, I guess such systems are able to boot over the network. I'd love to see a integrated boot and installation procedure that utilizes PXE (or any other network boot method) and advocates it. (In this regard I just love Suns). PXE installs are fun and easy. I use them for the no removable media boxes on our cluster when I need a local install for testing. The process is roughly (See Alfred's PXE article for details. Just ignore the kernel mods.): mount an install cd (assuming /cdrom as mountpoint) export /cdrom via nfs point a tftpd server at /cdrom configure a dhcpd with the necessicary lines to boot from /boot/pxeboot boot and install (I think you may need to choose to do an nfs install in sysinstall, but I'm not 100% sure of that.) I think it would be really cool if someone would add a feature to disk 1 to become a PXE install server. It should be fairly straight forward other then dealing with sysinstall. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Thursday 08 January 2004 07:57 am, Roman Neuhauser wrote: Now, I'm by no means advocating everybody should get ssh login on [dnp]cvs.freebsd.org; I just can't wait for the day when FreeBSD uses a SCM that handles tags and branches efficiently (so that people can freely create branches of areas they hack), that has permissions model with file- or directory-level granularity (so that people can be granted commit e. g. in /ports/x11-wm/openbox and nowhere else), etc. Note that cvs_acls.pl and the avail files already allow directory-level (and possibly file-level) ACLs. They aren't very widely used at the moment, however. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Hi All, On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. ... What if the loader would be able to load a, potentially large, kernel split over two or more floppies? That would allow for the same kernel that goes on the CD-Rom to be used for floppy install, greatly simplifying the release process. Or are my thoughts to simplistic? Thanks, Scott Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 05:56:22PM +0200, Narvi wrote: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Which would obviously mean that there would be lots of volunteers for the position of floppy maintainer? How you made the jump from I don't want to buy a CD burner to install FreeBSD to I will be a floppy maintainer I'm not sure. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Need necessitates effort? - Original Message - From: Avleen Vig [EMAIL PROTECTED] How you made the jump from I don't want to buy a CD burner to install FreeBSD to I will be a floppy maintainer I'm not sure. :-) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 2004-01-07 at 20:19, Robert Watson wrote: On Wed, 7 Jan 2004, Roman Neuhauser wrote: [1] has core@ considered subversion (devel/subversion)? Everyone has their eyes wide open looking for a revision control alternative, but last time it was discussed in detail (a few months ago?) it seemed there still wasn't a viable alternative. On the src tree side, FreeBSD committers are making extensive use of a Perforce repository (which supports lightweight branching, etc, etc), but there's a strong desire to maintain the base system on a purely open source revision control system, and migrating your data is no lightweight proposition. Likewise, you really want to trust your data only to tried and true solutions, I think -- we want to build an OS, not a version control system, if at all possible :-). Subversion seems to be the current favorite to keep an eye on, but the public release seemed not to have realized the promise of the design (i.e., no three-way merges, etc). You can peruse the FreeBSD Perforce repository via the web using http://perforce.FreeBSD.org/ -- it contains a lot of personal and small project sandboxes that might be of interest. For example, we do all the primary TrustedBSD development in Perforce before merging it to the main CVS repository. I've been re-evaluating the current subversion over the last couple of weeks and its holding up pretty well so far. It still misses the repeated merge thing that p4 does so well but in practice, merging does seem to be a lot easier than with CVS due to the repository-wide revision numbering system - that makes it easy to remember when your last merge happened so that you don't merge a change twice. The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 7 Jan 2004, Ryan Sommers wrote: On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: 1) Allow for paid development for a specific bug/feature - Setup some program that allows users like myself to pay for a developers time to fix a specific bug. The company I work for would easily pay serious dollars to fix our SMP problems with 4.X. Unfortunetly, getting someone's attention that has a great understanding of the OS is hard to find without rude remarks and what-not. You could even extend it as far as saying we will promote this PR to the top of the list of tasks if you pay us XX dollars. Or maybe, the more you pay the higher you go. This would reassure the user base that things CAN get done if needed and also let the developer/bug fixer feel like they can make money and have some fun. It will also bring in money for the project as part of that money could go back into the Project. You could easily setup a pool mailling list (like -requests) which someone like myself would email a request with the problem description (or PR). If a developer is interested in tackling the problem for money, we could privately negotiate a price. The same can be done for driver development and others. Make it a Donation for a specific request. I don't want to give money to some Foundation where money can be thrown around in the wrong areas. I want to pay the developer personally for their efforts. ( I feel the same should be done with our taxes as well ;-) I really don't like the idea of making this a policy, or even some official part of the project. I think this might discourage some from contributing in hopes to be paid for it. I think a better solution for companies looking for this would be to post to the jobs@ mailing list noting that it is a temp job. The point was not to take away from contributing developers only to pay someone who is familiar with the problem. I don't want to have to hire someone that doesn't have a clue on the problem and takes 6 months to even become familiar with a specific PR. I don't see anything wrong with paying someone who is working on my PR. Even it is a small amount. I'm not a company and can't afford to hire a programmer to develop a driver for me personally. However, if someone is working on a driver already and is time contstrained, I would pay some money to help relieve some of the time stress involved. I gave suggestions for keeping developers happy and efficient. Money is the only REAL answer. Perhaps this could be done through a company that contracts just FreeBSD developers. I know of no such company. I guess I will have to be satisfied with -jobs for now. I don't think giving priority to paying entities is a path the project should tread down. If someone needs FreeBSD developer work they should look for someone to hire. Something like this might also jeopardize the project's not for profit status. I think the jobs@ mailing list would be a better start. (I'm going to be looking for a full time job in about 11 months and if I got one where I got to code/administer BSD I'd feel I was in Heaven.) :-) Agreed. -- Nick Rogness [EMAIL PROTECTED] - How many people here have telekenetic powers? Raise my hand. -Emo Philips ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-07 23:17:31 -0800: On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. That might be technically true, but it's misleading and doesn't support the point you're trying to make. During this period the ports collection has only been frozen for a couple of weeks, and the majority of commit activities were not restricted for the rest of the period in question. That might be technically true, but the precise semantics of (semi-)freeze aren't as widely known as you seem to think. E. g. yesterday or today I received an email from a committer in response to my two mails to ports@ (the first urging a repocopy requested in a PR some time ago, the other retracting the request because of the freeze) saying (paraphrased) to my surprise I was told repocopies are allowed during freeze. Some people just prefer to err on the safe side. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: The procedure really is obvious, but there's only so much time in a day. Also, I would have thought the Porter's handbook would e. g. contain info on preventing installation of .la files (I gathered from the ports@ list that they shouldn't be installed), isn't this lack quite obvious? -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In a message written on Thu, Jan 08, 2004 at 10:35:47AM -0700, Nick Rogness wrote: Perhaps this could be done through a company that contracts just FreeBSD developers. I know of no such company. I guess I will have to be satisfied with -jobs for now. https://www.rentacoder.com/ Maybe someone could get them to make a FreeBSD section, where only people with commit bits can apply for jobs or something -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Steven Hartland wrote: Need necessitates effort? Precicely. Or even more precicely - the RE team provided an alternative path to eliminating floppy support which they could cope with. It follows that people who want floppy support should work towards that because the other option: you tell RE team that they had better shut up and make it work is not workable becuase they have no compulsion to listen to your and could just walk away any minute they bloody well want anyways. It thus follows that some persons out of the we want floppy support to stay around had better start volunteering to be floppy maintainers. - Original Message - From: Avleen Vig [EMAIL PROTECTED] How you made the jump from I don't want to buy a CD burner to install FreeBSD to I will be a floppy maintainer I'm not sure. :-) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] Ryan Sommers [EMAIL PROTECTED] writes: : I really don't like the idea of making this a policy, or even some : official part of the project. It has been going on for years. I've been paid to fix FreeBSD bugs by my employer and as an independent contractor for years now. These fixes get into the FreeBSD system on their merrits, but likely wouldn't have happened if someone wasn't willing to foot the bill. : Something like this might also jeopardize the : project's not for profit status. The project is not a legally incorporated entity at this time, and never has been in the past. There is a FreeBSD Foundation, but that's a completely independent organization. Prior to that there was FreeBSD, Inc, which Joran ran as a clearing house for help to those working on the project, but FreeBSD, Inc never was the project. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : My offer for a 'floppy : maintainer' is quite sincere; I hope that someone takes an interest and : steps up to the challenge. I think people misunderstand Scott's call here. He's not saying that the project doesn't want to support floppies because they are floppies. It isn't a dislike of the technology. Scott is saying that they have become a burdon to the release engineering team. He's saying that he's looking for someone to volunteer to actively help care and feed for the floppies used in the installation process. This is a call for people who care about them to step forward and put some action behind their caring. The only way something stays working in FreeBSD is if enough developers care about it to monitor it constantly. There are many examples of formerly well supported items being less supported now because they impact fewer developers directly. This is one of them. We can all come up with better ideas on how to support these things. Ideas aren't the issue. Elbow grease and sweat are. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004-01-08 17:29 +, Doug Rabson wrote: [...] The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. Perfection (or as close as possible) of cvs2svn.py is scheduled for 1.0. They've entered beta now, but without scanning the lists I suppose that's sometime 2004. I've noticed some other projects having problems with repository conversion, but at least things seem to be getting better. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with signal handling and threads (fbsd49R)
please can you give me an example of mask to SET BLOCK ou UNBLOCK in both threads (main and run) in order to make this sample code working ? thanks a lot. On Thu, 8 Jan 2004, Daniel Eischen wrote: Date: Thu, 8 Jan 2004 08:48:34 -0500 (EST) From: Daniel Eischen [EMAIL PROTECTED] To: rmkml [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: problem with signal handling and threads (fbsd49R) On Thu, 8 Jan 2004, rmkml wrote: Hi, I've got a problem with signal handling and threads. I've reproduced the problem in a simple code. Description of program: install a signal handler SIGINT. create a thread that do nothing except waiting. main thread use poll to wait forever [ poll(,,-1) ]. user has too crtl-C to interrupt poll after 5 ctrl-C, loop is over and main-thread signals sub-thread to stops. In fact, it appears not to work correctly: after one ctrl-C, user has to press ctrl-C twice before poll returns with errno=EINTR !! If the thread creation is removed from code, the expected behavior is seen : the program works fine. If I replace the poll by sigsuspend() the program works fine too. Is there something wrong with poll function ? No, it's your program. Why do you think the signal will only be delivered to the main thread and not the other (run) thread? If you want a particular thread to receive a signal, then you had better set up signal masks for all threads appropriately (or use sigwait()). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, 2004-01-08 at 18:05, Munish Chopra wrote: On 2004-01-08 17:29 +, Doug Rabson wrote: [...] The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. Perfection (or as close as possible) of cvs2svn.py is scheduled for 1.0. They've entered beta now, but without scanning the lists I suppose that's sometime 2004. I've noticed some other projects having problems with repository conversion, but at least things seem to be getting better. There seems to be a reasonably common problem where a single branch point ends up with more than one branch name. This certainly happens in the FreeBSD cvs. If you ignore that error, it gets about 1000 commits into the conversion but then dies with an error in the branch handling code (probably caused by the first problem). There are outstanding problems with vendor branches which it looks like they will fix before 1.0. I've been using the scripts to convert another large repository and they are not quick - my current test has been going for 2.5 days now and it still has about six months worth of repository to convert (the cvs history goes back about seven years in total). I estimate that the complete conversion will take about 3 days and will contain about 15000 commits... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of Scott Long, and lo! it spake thus: For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Well, that's why I suggest more. Have a network cards floppy, and a mass storage devices floppy, etc. We should be able to fit the half-dozen most common network cards, the ata drivers, and a half dozen of the more common SCSI drivers on the boot kernel. That'll get us far enough to be able to load the drivers off the other disks, as well as install with just that on many systems. It won't necessarily be the prettiest process, but I'm in favor of letting the floppies be a bit ugly, or even explicitly moving them to experienced users only status. I just find them far too convenient, as well as ubiquitous, to see them sent into the Great Bitbucket In The Sky yet. This is exactly what Debian does. I was a bit ticked when I found I had to make 7 floppy images to get a machine installed, but the important part is that it worked. Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. I myself have 4 machines (out of the 6 in front of me) that are Pentium- or Pentium II-class machines that cannot boot from CD-ROM or PXE, thus floppies are my only choice. Thus, I am genuinely interested in the effort to maintain working floppy images and can help out -- but not to the point of being maintainer yet. However, I have no experience building releases at all, so someone from re@ will have to help me along. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with signal handling and threads (fbsd49R)
On Thu, 8 Jan 2004, rmkml wrote: please can you give me an example of mask to SET BLOCK ou UNBLOCK in both threads (main and run) in order to make this sample code working ? man pthread_sigmask sigset_t set; sigemptyset(set); sigsetadd(set, SIGINT); pthread_sigmask(SIG_BLOCK, set, NULL); will block SIGINT. Put that in all threads that you don't want to handle CTRL-C. sigprocmask() instead of pthread_sigmask() will work as well. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Brooks Davis wrote: I think it would be really cool if someone would add a feature to disk 1 to become a PXE install server. It should be fairly straight forward other then dealing with sysinstall. I presume the above means a PXE *client*. This would be cool, but by no means trivial. I looked at this in the past when I wanted to network boot FreeBSD on a couple of machines that did not support a boot ROM and reached a dead end; I ended up using PicoBSD and NFS-mounting most of the stuff. Following Brook's suggestion, I looked around to see how difficult a PXE client project would be. Here are some bullets and pointers: - What we would need is a PXE emulator. PXE stands for Portable Execution *Environment*, and it really does supply a (primitive) but not trivial environment used to bootstrap the code. - Microsoft supplies with its Remote Installation Server (RIS) a program (rbfg.exe) that creates such an emulation floppy. This PXE emulator only supports PCI cards. See http://support.microsoft.com/?kbid=242920 - Apparently the same product, but with additional functionality, is sold by Argon Technologies. See http://www.argontechnology.com/rbfg/index.shtml - An open-source project called pxe-toolkit aimed at providing examples of PXE client and server code. The project seems to have dissappeared from the face of the earth. Its homepage on freshmeat and a download page on savannah are dead; a page with links on http://savannah.nongnu.org/projects/pxe-toolkit does not contain any useful pointers. - The PXE specification (2.1) is freely available from Intel in PDF format (500K, 103 pages). See ftp://download.intel.com/labs/manage/wfm/download/pxespec.pdf - Implementing a PXE client from scratch is obviously doable, but not trivial. One problem is that the API is 16-bit, so we would have to use 16-bit development tools, libraries, and an execution environment. The client should support a DHCP client, preboot functionality, and an API. The API consists of 37 relatively high-level functions providing TFTP, UDP, and UNDI (Universal Network Driver Interface) functionality. Here is a list to give you a rough idea of the functionality that has to be provided: UNLOAD_STACK, GET_CACHED_INFO, RESTART_TFTP, START_UNDI, STOP_UNDI, START_BASE, STOP_BASE, TFTP_OPEN, TFTP_CLOSE, TFTP_READ, TFTP_READ_FILE, TFTP_GET_FSIZE, UDP_OPEN, UDP_CLOSE, UDP_WRITE, UDP_READ, UNDI_STARTUP, UNDI_CLEANUP, UNDI_INITIALIZE, UNDI_RESET_ADAPTER, UNDI_SHUTDOWN, UNDI_OPEN, UNDI_CLOSE, UNDI_TRANSMIT, UNDI_SET_MCAST_ADDRESS, UNDI_SET_STATION_ADDRESS, UNDI_SET_PACKET_FILTER, UNDI_GET_INFORMATION, UNDI_GET_STATISTICS, UNDI_CLEAR_STATISTICS, UNDI_INITIATE_DIAGS, UNDI_FORCE_INTERRUPT, UNDI_GET_MCAST_ADDRESS, UNDI_GET_NIC_TYPE, UNDI_GET_IFACE_INFO, UNDI_GET_STATE, UNDI_ISR. I hope this information helps if anyone wants to take it up from here. Diomidis -- Diomidis Spinellis Assistant Professor Department of Management Science and Technology (DMST) Athens University of Economics and Business (AUEB) http://www.dmst.aueb.gr/dds/ mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thursday 08 January 2004 11:36 am, Ceri Davies wrote: On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. Floppies can go as far as I'm concerned, with the one proviso that we start shipping a /boot.config containing '-P'. Without floppies, the only ways to do a headless install are PXE and cutting your own release with that /boot.config in place, and not all machines can do PXE. -P breaks machines with USB keyboards because it doesn't use a very smary keyboard probe check. That's why it was turned off in the first place. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 10:48:24PM +0200, Diomidis Spinellis wrote: Brooks Davis wrote: I think it would be really cool if someone would add a feature to disk 1 to become a PXE install server. It should be fairly straight forward other then dealing with sysinstall. I presume the above means a PXE *client*. This would be cool, but by no means trivial. I looked at this in the past when I wanted to network boot FreeBSD on a couple of machines that did not support a boot ROM and reached a dead end; I ended up using PicoBSD and NFS-mounting most of the stuff. No, I mean a server. The hard part about using PXE to install a box is setting up the other box to boot the box your are installing on. It's not all the difficult, but it require a bit of knowledge, some grunt work, and a reasionable UNIX-like machine to start from. What I propose is adding enough stuff to disk 1 that you can do pxe installs like this: - find a random box with a cdrom drive and a supported nic - boot the install cd - select the make me an install server option from the menu - select an interface and configure it (or take a nice 10-net default) - pxe boot the boxes you want to install on and install over the network - shutdown the server, returning it to its previous function -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 03:43:55AM -0700 I heard the voice of Scott Long, and lo! it spake thus: Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. My hope is that, with this piece taken care of, the amount of care and feeding necessary to maintain it will be minimized. When adding new drivers, you'd have to stick their names in a list somewhere to be split out, but that's pretty minimal. It should help avoid all the juggling we keep having to do to manage the size. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. I have some interest in this, to be sure. However, every time I've ventured into src/release/ in the past, I've come away with an intense desire for absinthe. I've never successfully built a release, and it's been my impression that you can't just build the floppies, you have to build the full release to have everything in place to build them. That takes a huge chunk of disk space (to say nothing of _TIME_! Just building the kernel and modules takes the better part of a half hour), which are two things in chronically short supply. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 07:36:10AM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: If I understand you right.. A floppy boot, which loads the absolutely basic stuff (network drivers, and some easy way to config the network) and then goes and grabs the installer would otherwise be on the current floppies and boots it? Many (most?) Linux dists do this for floppy installs. I've come around to thinking it a better and better idea lately. It makes it easy to have much more bloa... er, featureful installers, particularly more graphical ones, since you're no longer limited by the size of a floppy. And even cheap DSL is faster than a floppy drive for loading it, to boot (no pun ;). And you can even provide for loading it off a local CD, if you have a CD drive you can't boot from. The downside is that writing such a beast is a lot more work... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 2:27 AM -0800 2004/01/08, Kris Kennaway wrote: It's certainly true that we're lacking in build hardware for some non-i386 platforms (particularly sparc64), and this made it pretty tricky to build packages for 5.2 on those architectures (a full sparc64 build takes at least a month). I've heard some rumours of donated equipment waiting to be installed, but I don't know what the status of that is. I've got a SPARC64 box sitting downstairs, waiting for me to install it. Actually, I've got four of them. I was planning on using one for FreeBSD support, one for NetBSD, one for OpenBSD, and one for Solaris. I was also thinking about using the OpenBSD/sparc64 box as a primary firewall (until I can get something better), but I imagine that NetBSD really doesn't need much more sparc64 support right now -- maybe I could reconsider using that one for sparc64 package support. Likewise, a 5.2 i386 build takes about a week, which means that the freeze *cannot* be shorter than this, even if everything goes perfectly (which, in practise, never happens). This time around, the freeze started on 23 Nov and was lifted on 3 Dec. That's 10 days, which is about as good as you could hope for. If we could build packages in - say - a day, we'd be able to cut the freeze time down further, although I expect the duration would become limited by the speed at which problems can be corrected. Sounds to me like a reliable RAM disk for temporary files would be very helpful. There are at least one or two PCI card models that I think can take up to 8GB, and which I know work with Linux. If they don't already work with FreeBSD, I would imagine it shouldn't take too much work to fix that. Every now and then we get offers of access to a machine here or a machine there to help with building packages. The main problem with donating machine resources is that there's limited space in the freebsd.org equipment racks, and the package build system currently needs LAN-equivalent connectivity between the machines. To be useful we'd either need a full cluster of faster machines located somewhere, or to find time to rewrite the build scripts to work efficiently with remote build resources. Hmm. I would seriously consider donating one or two sparc64 boxes to the project (once I confirm they work ;-), but I would want to make sure that there is space to support them. Otherwise, I would be willing to run them from my basement. Of course, that's precisely the problem you already have. I've done a bit of script hacking in the past. Do you have any idea what would be required to hack these scripts to suit? Alternatively, I might be able to get you some additional build resources somewhere else. In fact, I think this other place is probably already quite familiar with FreeBSD, and they might be surprised to hear about this need -- should I contact them? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Sincerely FreeBSD developers have more important tasks than spending hours to fit an installable system on floppies. When FreeBSD used one floppy, it was tolerable to do floppy installs. With 2 or 3 floppies it is awfully slow, i have done once and will never do it again. There are so many workarounds for people who don't have a CD burner, including asking a friend to burn the CD, buying a cheap CD somewhere. For people who don't have a CD reader able to boot, the simplest solution by far is to remove the hard drive and install it on another machine, much faster than reading the 2 damned floppies :-) The technically dedicated people can also arrange a PXE boot which boots a live system, and then brutally install on hard disk bypassing the installer which is far from nice anyways. There are tons of ways of proceeding, including dd copying a series of identical disks for people who have to do large installs. By the way, what's the reason that it is impossible to have just one floppy which boots FreeBSD kernel, allows to see an unbootable cdrom and continue installation from here? During the holidays i have installed the Linux Knoppix distro this way on an old machine which doesn't allow to boot from CD. There is a 1.44M floppy image on the CD which allows to do just that. I am quite stunned that the same thing cannot be done for FreeBSD. -- Michel TALON ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Brooks Davis wrote: No, I mean a server. The hard part about using PXE to install a box is setting up the other box to boot the box your are installing on. It's not all the difficult, but it require a bit of knowledge, some grunt work, and a reasionable UNIX-like machine to start from. What I propose is adding enough stuff to disk 1 that you can do pxe installs like this: Nice idea! My mind was fixated on older machines that do not support PXE; as I always have a couple of FreeBSD servers around at work/home I failed to realise that setting up a PXE server could ever be a problem. Diomidis ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Matthew D. Fuller wrote: On Thu, Jan 08, 2004 at 03:43:55AM -0700 I heard the voice of Scott Long, and lo! it spake thus: Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. My hope is that, with this piece taken care of, the amount of care and feeding necessary to maintain it will be minimized. When adding new drivers, you'd have to stick their names in a list somewhere to be split out, but that's pretty minimal. It should help avoid all the juggling we keep having to do to manage the size. We already have this. It's at src/release/i386/drivers.conf. It can trivially be expanded to take care of more than just three floppies. However, the piece that is missing is the ability for 3rd, 4th, 5th, etc, floppies to be conveniently loaded and work seamlessly. Right now, the boot loader that comes on floppy on has some magic to ask the user for the second floppy, then load the mfsroot and .ko files off it automatically before the kernel boots. Unfortunatley, this magic is split between an interactive step in boot/loader.rc and a non-interactive step in the loader code. There is no easy way to expand this to handle multiple floppies; the non-interactive second step cannot recurse back to the interactive first step. The 3rd floppy is handled right now in a menu that is run when sysinstall starts. It's a nice menu; it gives you a list of the drivers on the floppy and asks which one you want to load. Unfortunately, there are two problems with this. The first is that it runs after the kernel has already booted, so SCSI devices that are handled by drivers on this floppy won't get probed. The second is that forcing the user to know which driver is appropriate for their hardware is not very good form. My preference would be to deprecate the sysinstall method and expand the boot loader to fully handle an arbitrary number of floppies. It would also be nice to build a method for manually excluding drivers that the user doesn't want to load. This would greatly help to support 3rd party vendor driver disks, something that SuSE and Redhat derive significant benefit from right now. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. I have some interest in this, to be sure. However, every time I've ventured into src/release/ in the past, I've come away with an intense desire for absinthe. I've never successfully built a release, and it's been my impression that you can't just build the floppies, you have to build the full release to have everything in place to build them. That takes a huge chunk of disk space (to say nothing of _TIME_! Just building the kernel and modules takes the better part of a half hour), which are two things in chronically short supply. There are several documents linked off of http://www.freebsd.org/releng that describe how to build a release. It's not nearly as arcane of a process as it used to be 5 years ago. The biggest barrier to entry is probably disk space. You'll need a good 5GB free to hold the CVS repo, chroot environment, and resulting bits. Yes, to build the floppies you need to build most of the release, but once you've built the release, you can back-step and rebuild the floppies at will. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A way to clean up PRs?
Just a thought: How about everything that hasn't been touched in 3 years gets put into a special state of closed-believed-dead, everything over 12 months (or 6?) gets the same AFTER an e-mail has been sent out to the originator to see if the problem still exists? It's just that way, I think a lot of PRs for obsolete hardware and versions will get closed up, thereby making it easier for those of us trying to pick our way through and see what is still new and relevant and in need of some love and care and attention. If somebody still has the problem and it's an issue, it just gets a new PR that comes back on the top of the queue, it's live and we can deal with PRs as they come in. Thoughts? Just a thought that might help clean up the DB on an idle Thursday evening. I'm sure it's been thought of before. Automated PR purging - it's the future! :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A way to clean up PRs?
On Thu, Jan 08, 2004 at 10:51:53PM +, Paul Robinson wrote: Just a thought: How about everything that hasn't been touched in 3 years gets put into a special state of closed-believed-dead, everything over 12 months (or 6?) gets the same AFTER an e-mail has been sent out to the originator to see if the problem still exists? It's just that way, I think a lot of PRs for obsolete hardware and versions will get closed up, thereby making it easier for those of us trying to pick our way through and see what is still new and relevant and in need of some love and care and attention. If somebody still has the problem and it's an issue, it just gets a new PR that comes back on the top of the queue, it's live and we can deal with PRs as they come in. Thoughts? Just a thought that might help clean up the DB on an idle Thursday evening. I'm sure it's been thought of before. Well, here's a extract from a mail I sent to another non-committer interested in doing the same thing, about two days ago. Note that we do already timeout PRs in feedback after a period of time without a reply (currently 3 months). Also note that there's a bugbusters@ list where this kind of discussion should live, but I think I may be the only person subscribed (although rousing the list is really my responsibility, I've yet to think up a good enough scheme). Forwarded mail: Thanks for the offer of help. Sending stuff to current could be considered useful, but committers interested in fixing bugs (which is hopefully all of them!) will all be subscribed to freebsd-bugs@, which means that by simply submitting a followup to the PR they'll get automatically notified. There a few ways for non-committers to help out though: if you think that a PR can be closed, then submit a followup to the PR with the reason why, and include the string This PR can be closed. The reason can be anything from this isn't a problem on later releases, this was fixed in revision x of src/foo/bar/quux.c to the user is at fault. Just because a PR can't be closed though, if you have information to add to a PR (an updated patch, cannot replicate here, etc.) then send it in as a followup. Of course, if you know of (or can code) a fix, send it! Ceri -- pgp0.pgp Description: PGP signature
Re: A way to clean up PRs?
Paul Robinson [EMAIL PROTECTED] writes: How about everything that hasn't been touched in 3 years gets put into a special state of closed-believed-dead, everything over 12 months (or 6?) gets the same AFTER an e-mail has been sent out to the originator to see if the problem still exists? The PR handling guidelines already address this. See section 4.3 in URL:http://www.freebsd.org/doc/en/articles/pr-guidelines/. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 04:10:38PM -0600, Matthew D. Fuller wrote: On Thu, Jan 08, 2004 at 07:36:10AM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: If I understand you right.. A floppy boot, which loads the absolutely basic stuff (network drivers, and some easy way to config the network) and then goes and grabs the installer would otherwise be on the current floppies and boots it? Many (most?) Linux dists do this for floppy installs. I've come around to thinking it a better and better idea lately. It makes it easy to have much more bloa... er, featureful installers, particularly more graphical ones, since you're no longer limited by the size of a floppy. And even cheap DSL is faster than a floppy drive for loading it, to boot (no pun ;). And you can even provide for loading it off a local CD, if you have a CD drive you can't boot from. The downside is that writing such a beast is a lot more work... Take what I'm babbling about with a huge grain of salt, since I probably have no idea what I'm talking about... How hard would it be to take something like etherboot and building a single install floppy from that? And have a FreeBSD kernel/installer hosted on a public nfs/tftp server? Ie., the user pops in the etherboot floppy, it asks for network setup info, we tell it to use ftp.freebsd.org, and it goes out and either nfs mounts or tftp the kernel and installer and drivers. Then proceed from there to installing FreeBSD onto the system. I suppose that's what you just said.. But was just thinking that it'd be easier modifying an existing system (ie., etherboot) than writing one from scratch.. Note: I just mentioned etherboot because that was the first thing that came to mind. I'm sure there are other systems better suited or licensed for what's needed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
In nuntio [EMAIL PROTECTED], Michel TALON divulgat: By the way, what's the reason that it is impossible to have just one floppy which boots FreeBSD kernel, allows to see an unbootable cdrom and continue installation from here? I agree. The boot floppy tries to do w a y too much. I think we should think of the boot floppy as way to implement an old-style console emulator: it boots and you tell it where to read the *real* boot image from. It should support all of the usual sources: CDs/DVDs, NFS mounts, FTP, and so on. The real boot image would know how to format drives, install distributions packages, and so on. This boot console floppy would only need to change to support new hardware, and there could even be boot-source-specific versions of it. Once you had one that worked on a specific type of PC, you could keep using it indefinitely. Greg Shenaut ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 03:36:42PM -0700 I heard the voice of Scott Long, and lo! it spake thus: Unfortunately, there are two problems with this. Now, The first is that it runs after the kernel has already booted, so SCSI devices that are handled by drivers on this floppy won't get probed. This I hadn't known. Why is that? I thought when you loaded a module it pulled up the driver and probed the hardware, which included scanning any busses on it. The second is that forcing the user to know which driver is appropriate for their hardware is not very good form. This is one of those things I list under the category of letting floppy installs be a bit ugly, or 'experienced-users only'-labelled. There are several documents linked off of http://www.freebsd.org/releng that describe how to build a release. It's not nearly as arcane of a process as it used to be 5 years ago. The biggest barrier to entry is probably disk space. You'll need a good 5GB free to hold the CVS repo, chroot environment, and resulting bits. Well, I've got the CVS repo, though boy, has *THAT* ever grown since I built this system; I had to trim it down to only src and ports, and even so: /dev/da1s1e 2032623 1769089 10092595%/usr/cvs Of course, I left out the ports and docs parts of the release last time I tried (which was in fact about 5 years ago ;), though I had all kinda of troubles with parts of THAT, too. But still, I don't have even a tenth that much hard drive space around. Yes, to build the floppies you need to build most of the release, but once you've built the release, you can back-step and rebuild the floppies at will. And building the whole release is quite an ordeal on a Pentium Pro :) Still, I'm willing to donate some time and brain to the problem, since apparently I kinda care about it. It seems to me that the probing problem above is the biggest problem from a real coding POV; the rest is mostly just a whole heck of a lot of implementation, and inconvenience from the usability standpoint. That's a breaking point. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LG 5350 cell phone
I don't know if anyone is still interested in this topic or not but I just
made some progress today (got sick of not being able to use my
straight through USB cable with FreeBSD). Here's what I've got at
the moment under 4.9-RELEASE.
I went tracing through /usr/src/sys/dev/usb/umodem.c (good old
printf statements) to see what exactly it was that was causing the
reboots of my cellphone. I came to the conclusion that it probably
wasn't something in umodem.c that needed tweaking so I went
nosing around in /usr/src/sys/dev/usb/usbdevs again.
As the phone doesn't start misbehaving until umodem attempts to
attach to it I was able to just leave it at ugen0 and ask usbdevs for
the vendor and product codes (usbdevs -v). I put those into
usbdevs and the diff looks like this:
*** usbdevs.origTue Sep 2 09:35:17 2003
--- usbdevs Thu Jan 8 15:12:03 2004
***
*** 341,346
--- 341,347
vendor AGATE 0x0c08 Agate Technologies
vendor DMI0x0c0b DMI
vendor LUWEN 0x0c76 Luwen
+ vendor QUALCOMM 0x1004 Qualcomm
vendor MOTOROLA 0x1063 Motorola
vendor PLX0x10b5 PLX
vendor ASANTE 0x10bd Asante
***
*** 648,653
--- 649,657
/* Fujitsu protducts */
product FUJITSU AH_F401U0x105b AH-F401U Air H device
+
+ /* Qualcomm products */
+ product QUALCOMM CDMA_MSM 0x6000 CDMA Technologies MSM phone
/* General Instruments (Motorola) products */
product GENERALINSTMNTS SB51000x5100 SURFboard SB5100 Cable modem
Having been down this route before without success (usbdevs itself notes
that simply adding IDs does not add any functionality at all) and noticing
a call to /usr/src/sys/dev/usb/usb_quirks.c from umodem.c during
initialization I took a look over there and added this:
*** usb_quirks.c.orig Wed Feb 12 08:05:57 2003
--- usb_quirks.cThu Jan 8 16:03:35 2004
***
*** 83,88
--- 83,90
{ USB_VENDOR_HP, USB_PRODUCT_HP_815C,ANY, { UQ_BROKEN_BIDIR
}},
{ USB_VENDOR_HP, USB_PRODUCT_HP_810C,ANY, { UQ_BROKEN_BIDIR
}},
{ USB_VENDOR_HP, USB_PRODUCT_HP_830C,ANY, { UQ_BROKEN_BIDIR
}},
+ { USB_VENDOR_QUALCOMM, USB_PRODUCT_QUALCOMM_CDMA_MSM,
+ ANY, { UQ_ASSUME_CM_OVER_DATA}},
/* YAMAHA router's ucdDevice is the version of farmware and often changes. */
{ USB_VENDOR_YAMAHA, USB_PRODUCT_YAMAHA_RTA54I,
ANY, { UQ_ASSUME_CM_OVER_DATA }},
After compiling a new kernel with these changes incorporated
(don't forget to run a make -f Makefile.usbdevs if you've got
old kernel compile stuff still around!!!) I now can use the phone as
a modem!!! I can set the speed up to 230400 (matching the
setting indicated in the phone's menu) and the transfer speeds are every
bit as good as on the iBook now. This is what dmesg now reports:
umodem0: Qualcomm CDMA Technologies MSM phone, rev 1.01/0.00, addr 2, iclass 2/2
umodem0: data interface 1, has CM over data, has break
The only issue remaining is when I try to bring the connection down.
When I do this ppp reports:
Warning: deflink: Unable to set physical to speed 0
and on the console I see this:
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
These messages appear to be harmless (ppp is down now and
I can reestablish a connection without problem), but obviously
it isn't the best behaved.
Would anyone care to chip in with suggestions and/or advice?
Sean
Delivered-To: [EMAIL PROTECTED]
Date: Mon, 16 Jun 2003 19:52:36 -0700 (PDT)
From: David Yeske [EMAIL PROTECTED]
To: Josef Karthauser [EMAIL PROTECTED], [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: LG 5350 cell phone
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Mobile computing with FreeBSD freebsd-mobile.freebsd.org
List-Unsubscribe: http://lists.freebsd.org/mailman/listinfo/freebsd-mobile,
mailto:[EMAIL PROTECTED]
List-Archive: http://lists.freebsd.org/pipermail/freebsd-mobile
List-Post: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Subscribe: http://lists.freebsd.org/mailman/listinfo/freebsd-mobile,
mailto:[EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
Should this get a new vendor entry in usbdevs?
--- Josef Karthauser [EMAIL PROTECTED] wrote:
Re: Where is FreeBSD going?
On Thu, Jan 08, 2004 at 06:36:42PM +0100, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2004-01-07 23:17:31 -0800: On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. That might be technically true, but it's misleading and doesn't support the point you're trying to make. During this period the ports collection has only been frozen for a couple of weeks, and the majority of commit activities were not restricted for the rest of the period in question. That might be technically true, but the precise semantics of (semi-)freeze aren't as widely known as you seem to think. E. g. yesterday or today I received an email from a committer in response to my two mails to ports@ (the first urging a repocopy requested in a PR some time ago, the other retracting the request because of the freeze) saying (paraphrased) to my surprise I was told repocopies are allowed during freeze. Some people just prefer to err on the safe side. Repo-copies are not allowed during the freeze, but are any other time. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: The procedure really is obvious, but there's only so much time in a day. Also, I would have thought the Porter's handbook would e. g. contain info on preventing installation of .la files (I gathered from the ports@ list that they shouldn't be installed), isn't this lack quite obvious? No, please raise this on the ports list. Kris pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thursday 08 January 2004 18:20, Avleen Vig wrote: I understand it is difficult to maintain the floppies. I wish I understood them better :-) Is it not possible to have ftp install floppies, which do nothing more than simple FTP installations? It wouldn't make it any easier. You still need the right drivers, ie which SCSI controller/network/... cards you have to get a minimal install is _more_ when you are doing FTP (you need a network). I think one possibility that wasn't mentioned is to have a floppy maintainer that generates several sets of floppies that are used for non-CD booting/no-CD installs which are available via download, and some are chucked on the CD. ie make it a separate part of the release, so it is not directly the install team's job. This would mean that the default 'make release' produces no floppy images. Instead they are built separately and bundled with 'official' releases. It would even be (fairly trivially) possible to setup a web site where you select what cards you want support for and it makes a floppy image for you. Even just having a page which tells you want card needs what KLD and where to get the KLD's would help, as you could download them on your other OS and put them on floppy yourself. Scott also said stuff like SCSI cards won't get probed if a module is loaded but I can't see why that is true.. The module will load, the device get detected, and then sysinstall is told to reprobe the hardware, so it should pick it up. I see the 'which kld goes with what device' problem as separate to this issue. The KLD load stuff DOES show a small description for each KLD so it isn't a total black box, and heck, you can just pick everything and cross your fingers :) -- 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 GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Friday 09 January 2004 10:04, Greg Shenaut wrote: In nuntio [EMAIL PROTECTED], Michel TALON divulgat: By the way, what's the reason that it is impossible to have just one floppy which boots FreeBSD kernel, allows to see an unbootable cdrom and continue installation from here? I agree. The boot floppy tries to do w a y too much. I think we should think of the boot floppy as way to implement an old-style console emulator: it boots and you tell it where to read the *real* boot image from. It should support all of the usual sources: CDs/DVDs, NFS mounts, FTP, and so on. *How* does it support all of those sources? CD/DVD drives need drivers (ATA optimisticly, but quite possibly SCSI), FTP/NFS need network card support, NFS needs nfsclient.ko ie this is the exact problem it has now :) You could save a little space with your idea because you wouldn't need sysinstall which is admittedly quite large, but it wouldn't address the fundamental issue. If you want floppy installs you need a way of putting arbitary drivers onto floppy disks easily so users can grab what they need and use it instead of having to second guess what sort of hardware they are likely to be using. IMHO of course 8-) -- 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 GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:04:34PM +1030, Daniel O'Connor wrote: *How* does it support all of those sources? CD/DVD drives need drivers (ATA optimisticly, but quite possibly SCSI), FTP/NFS need network card support, NFS needs nfsclient.ko ie this is the exact problem it has now :) You could save a little space with your idea because you wouldn't need sysinstall which is admittedly quite large, but it wouldn't address the fundamental issue. If you want floppy installs you need a way of putting arbitary drivers onto floppy disks easily so users can grab what they need and use it instead of having to second guess what sort of hardware they are likely to be using. IMHO of course 8-) Now you've got me thinking. A simple website which lets you choose what drivers you want (anyone seen the .muttrc config page? :) That should be really easy to do with a little perl CGI. I might take a crack at this in the next week or so. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : : Ryan Sommers [EMAIL PROTECTED] writes: : : Something like this might also jeopardize the : : project's not for profit status. : : The project is not a legally incorporated entity at this time, and : never has been in the past. : : And yet the Legal page carries a claim of copyright for The FreeBSD : Project It is a psudonymous work by The FreeBSD Project. : and the Copyright page has that plus a similar claim for : FreeBSD, Inc. (For 2004, even.) That should be changed. : I've not seen a US statute about : false copyright claims, but I think it would be less risky to say all : intellectual property is owned by its owners, in the manner of some : trademark statements. No, the above is perfectly legal under US and International Copyright law. : The Legal page could tell about using CVS to : determine who owns what so they can be tracked down and asked if the : copyright page is correct about what license they've got it under. :) That's likely overkill, but might not be a bad idea. : Whether the project is for profit depends upon the definition, if : the project is claiming copyright ownership, because gains of : intellectual property is considered (by US copyright law, at least) to : be a financial gain. But lots of organizations, formal and informal, : have financial gains without problems with being considered for : profit, so if someone sees for profit problems, they should be : specific about what the problems might be. For profit or not is irrelvant, given that there's no legally incorporated entity for the project. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Friday 09 January 2004 15:00, Avleen Vig wrote: onto floppy disks easily so users can grab what they need and use it instead of having to second guess what sort of hardware they are likely to be using. IMHO of course 8-) Now you've got me thinking. A simple website which lets you choose what drivers you want (anyone seen the .muttrc config page? :) That should be really easy to do with a little perl CGI. I might take a crack at this in the next week or so. Yep, I suspect mtools is the easiest way to do this.. -- 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 GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 03:28:11PM +1030, Daniel O'Connor wrote: On Friday 09 January 2004 15:00, Avleen Vig wrote: onto floppy disks easily so users can grab what they need and use it instead of having to second guess what sort of hardware they are likely to be using. IMHO of course 8-) Now you've got me thinking. A simple website which lets you choose what drivers you want (anyone seen the .muttrc config page? :) That should be really easy to do with a little perl CGI. I might take a crack at this in the next week or so. Yep, I suspect mtools is the easiest way to do this.. Something that was suggested in #FreeBSDHelp on EFnet just now: sysinstall already has the ability to dynamically load modules. If this is the case, I don't see where the problem is. Make the kernel on the floppy disk have few/no drivers built in, and have then all loaded from a third disk. Have the third disk generated dynamically from say, a website? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Friday 09 January 2004 15:48, Avleen Vig wrote: Yep, I suspect mtools is the easiest way to do this.. Something that was suggested in #FreeBSDHelp on EFnet just now: sysinstall already has the ability to dynamically load modules. If this is the case, I don't see where the problem is. Make the kernel on the floppy disk have few/no drivers built in, and have then all loaded from a third disk. Have the third disk generated dynamically from say, a website? Yeah, that was similar to what I was thinking. You could just get it to make a zip for you to put on a floppy after you select your hardware from a list. -- 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 GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SOLVED: ADMtek USB To LAN Converter and HomePNA
people,
the following patch solves this problem. according to the ADM8511
datasheet, a couple of registers need to be set with specific values to
enable the HomePNA PHY on the device. the current aue(4) driver does not
do this, and thus by default the device will only enable the Ethernet PHY.
you'd need to rebuild kernel or just kldunload/kldload if using the
if_aue.ko module.
--- CUT HERE ---
--- if_aue.c.orgThu Jan 8 19:29:27 2004
+++ if_aue.cThu Jan 8 19:29:27 2004
@@ -581,7 +581,7 @@
csr_write_1(sc, AUE_REG_81, 6);
else
#endif
- csr_write_1(sc, AUE_REG_81, 2);
+ csr_write_1(sc, AUE_REG_81, 6);
}
Static void
@@ -610,6 +610,7 @@
*/
csr_write_1(sc, AUE_GPIO0, AUE_GPIO_OUT0|AUE_GPIO_SEL0);
csr_write_1(sc, AUE_GPIO0, AUE_GPIO_OUT0|AUE_GPIO_SEL0|AUE_GPIO_SEL1);
+ csr_write_1(sc, AUE_GPIO1, 0x34);
/* Grrr. LinkSys has to be different from everyone else. */
if (sc-aue_info-aue_flags LSYS) {
---CUT HERE ---
On Wed, 7 Jan 2004, Dinesh Nair wrote:
hey,
i have one of the above. it's a usb device which connects to a HomePNA
network, with a 10/100Mbps ethernet port as well as a couple of RJ11s for
the HomePNA connection.
my problem is i am unable to utilize this device to connect to the HomePNA
network. upon plugging it in, the console says:
aue0: ADMtek USB To LAN Converter, rev 1.10/1.01, addr 2
aue0: Ethernet address: 00:08:54:d0:5d:2e
miibus1: MII bus on aue0
pnaphy0: Am79c978 HomePNA PHY on miibus1
pnaphy0: HomePNA
ifconfig aue0 response is:
aue0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 00:08:54:d0:5d:2e
media: Ethernet homePNA (none)
i run 'ifconfig aue0 10.1.105.26 netmask 0x media homepna' and the
device then gets to the following:
aue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.1.105.26 netmask 0x broadcast 10.1.255.255
ether 00:08:54:d0:5d:2e
media: Ethernet homePNA
status: active
however, i am unable to ping any ip address other than the interface's
address. obviously, no firewalls (ipfw/ipchains/ipf) are being run and
this is on FreeBSD 4.9-STABLE built as of a couple of weeks back.
i've played around with disabling the ethernet PHY on the device with the
following diff to /usr/src/sys/dev/usb/if_aue.c:
--- CUT HERE ---
--- if_aue.c.orgWed Jan 7 20:02:51 2004
+++ if_aue.cWed Jan 7 21:04:06 2004
@@ -434,6 +434,28 @@
#endif
}
+ /*
+* The Am79C978 HomePNA PHY actually contains
+* two transceivers: a 1Mbps HomePNA PHY and a
+* 10Mbps full/half duplex ethernet PHY with
+* NWAY autoneg. However, the HomePNA PHY is
+* not recognized, but the 10/100Mbps PHY is
+* though. This skips over the 10/100Mbps PHY
+* and only activates the 1Mbps HomePNA PHY
+*
+* Modified by Dinesh Nair [EMAIL PROTECTED]
+* Wed Jan 7 20:36:34 MYT 2004
+*
+*/
+ if (sc-aue_info-aue_vid == USB_VENDOR_ADMTEK
+ sc-aue_info-aue_did == USB_PRODUCT_ADMTEK_PEGASUSII) {
+ if (phy == 1)
+ return(0);
+ }
+ /*
+* End of modifications by Dinesh Nair
+*/
+
csr_write_1(sc, AUE_PHY_ADDR, phy);
csr_write_1(sc, AUE_PHY_CTL, reg|AUE_PHYCTL_READ);
--- CUT HERE ---
but to no avail. i've discovered that the ethernet PHY is phy==1, while
the two RJ11 PHYs are 2 and 3.
the ethernet PHY works fine and dandy, and i am able to connect it to my
local switch fine. however, i need to use it for a HomePNA application,
and thus need to HomePNA portion of this to work.
any ideas from anyone who's tried something like this before with some
measure of success ? any media types or mediaopts i should be passing to
ifconfig ?
this setup is used by a broadband provider in kuala lumpur, malaysia and
to date this has been the one barrier which prevents freebsd users from
utilizing their service.
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do
SOLVED: ADMtek USB To LAN Converter and HomePNA
use the following patch instead of earlier one. earlier patch hardcoded
use of HomePNA PHY and disabled Ethernet PHY. this patch corrects this
behaviour and allows switching between either PHY thru use of the ifconfig
command. this means that the USB dongle can either be used as an Ethernet
device (connect to switch/hub) or as a HomePNA access device, but not both
simultaneously.
ifconfig aue0 media homepna # activates HomePNA PHY/RJ11
ifconfig aue0 media auto # activates Ethernet PHY/RJ45
using auto as media type is synonymous with the following media types:
10baseT 10baseT-FDX 100baseTX 100baseTX-FDX
much apologies for not checking things correctly before submitting the
patch.
patch follows:
--- CUT HERE ---
--- if_aue.c.orgWed Jan 7 20:02:51 2004
+++ if_aue.cThu Jan 8 21:12:23 2004
@@ -118,7 +118,7 @@
{ USB_VENDOR_ACCTON, USB_PRODUCT_ACCTON_USB320_EC, 0 },
{ USB_VENDOR_ACCTON, USB_PRODUCT_ACCTON_SS1001,PII },
{ USB_VENDOR_ADMTEK, USB_PRODUCT_ADMTEK_PEGASUS, PNA },
-{ USB_VENDOR_ADMTEK, USB_PRODUCT_ADMTEK_PEGASUSII, PII },
+{ USB_VENDOR_ADMTEK, USB_PRODUCT_ADMTEK_PEGASUSII, PNA|PII },
{ USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_USB2LAN, PII },
{ USB_VENDOR_BILLIONTON, USB_PRODUCT_BILLIONTON_USB100,0 },
{ USB_VENDOR_BILLIONTON, USB_PRODUCT_BILLIONTON_USBLP100, PNA },
@@ -492,6 +492,17 @@
mii = device_get_softc(sc-aue_miibus);
AUE_CLRBIT(sc, AUE_CTL0, AUE_CTL0_RX_ENB|AUE_CTL0_TX_ENB);
+
+ if (IFM_SUBTYPE(mii-mii_media_active) == IFM_homePNA) {
+ if (sc-aue_info-aue_flags (PNA|PII)) {
+ csr_write_1(sc, AUE_GPIO1, 0x34);
+ csr_write_1(sc, AUE_REG_81, 6);
+ }
+ } else {
+ csr_write_1(sc, AUE_GPIO1, 0x26);
+ csr_write_1(sc, AUE_REG_81, 2);
+ }
+
if (IFM_SUBTYPE(mii-mii_media_active) == IFM_100_TX) {
AUE_SETBIT(sc, AUE_CTL1, AUE_CTL1_SPEEDSEL);
} else {
@@ -576,12 +587,10 @@
/* Magic constants taken from Linux driver. */
csr_write_1(sc, AUE_REG_1D, 0);
csr_write_1(sc, AUE_REG_7B, 2);
-#if 0
- if ((sc-aue_flags HAS_HOME_PNA) mii_mode)
- csr_write_1(sc, AUE_REG_81, 6);
- else
-#endif
+
+ if (sc-aue_info-aue_flags PNA) {
csr_write_1(sc, AUE_REG_81, 2);
+ }
}
Static void
--- CUT HERE ---
--dinesh
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
