cant compile with cpufunc.h, barfs.
Hi there. I have a simple prog that writes to a bit on the parallel port. It compiles fine under 2.2.x (tested on 2.2.5 and 2.2.8) BUT the compiler barfs over . with 3.1-release. I am trying to use outb(base,onoff). bash-2.02$ cc -o out1 outF.c In file included from outF.c:10: /usr/include/machine/cpufunc.h:155: parse error before `inbc' /usr/include/machine/cpufunc.h:155: parse error before `port' /usr/include/machine/cpufunc.h: In function `inbc': MUCH MORE :-) The prog is not a driver, it cheats by opening /dev/io first. Please help me, I would like to get this working under 3.1 as it did under 2.2.5 TIA Josh -- E-Mail: Josh2 Lists Date: 02-Jun-99 Time: 16:15:19 This message was sent by XFMail -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM: Undefined symbols at runtime
Matthew Hunt wrote: > If I add "-export-dynamic" to LDADD in usr.bin/login/Makefile, everything > is groovy. > > I've noticed that dynamic linking in Perl also doesn't work for me, > likely for the same reason. I haven't tried rebuilding perl with > "-export-dynamic" yet, though. > > So, the question now is: Why do I need "-export-dynamic", when > evidently nobody else does? I don't know. Maybe you have something unusual in your /etc/make.conf file? John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Extra text modes via vidcontrol...
>> 3. The video card doesn't support required graphics modes. >>Run 'vidcontrol -i mode' and see if the 320x200 256 color mode >>is supported. The vga driver in FreeBSD may not be able to support >>all video modes, if the video card's BIOS is not as compatible as >>it should be. > >I have a somewhat related question for you: I cannot set many extended text >modes (80x60, 80x50, 132x50, etc.) even though they are listed in the output >from `vidcontrol -i mode`. My card is a Matrox Millenium G200 AGP if that is >any help. Any suggestions for getting all those modes to work? These text modes with more than 25 lines require 8x8 font which is not loaded to the kernel by default. You can load one of 8x8 font files in /usr/share/syscons/fonts via `vidcontrol -f _font_file_name_'. You can automatically load font at boot time by editting /etc/rc.conf.local (3.1-RELEASE or later) or /rc/rc.conf (3.0-RELEASE or earlier includeing 2.2.X). >Also, do you know of any chipsets that just don't 'work' with the VESA support >for large splash screens? We have a bunch of ATI Rage3D cards at my school >that won't load any splash screen above 320x200 even though they support VESA >2.0 and contain lots of video modes in their tables. I don't have such list. It is "chipset", but "BIOS" that matters. Are you sure you enabled "options VM86" in the kernel configuration file and loaded the vesa module by the boot loader? Would you tell me more about the bitmap file you are attempting to load? Kazu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Extra text modes via vidcontrol...
> 3. The video card doesn't support required graphics modes. >Run 'vidcontrol -i mode' and see if the 320x200 256 color mode >is supported. The vga driver in FreeBSD may not be able to support >all video modes, if the video card's BIOS is not as compatible as >it should be. I have a somewhat related question for you: I cannot set many extended text modes (80x60, 80x50, 132x50, etc.) even though they are listed in the output from `vidcontrol -i mode`. My card is a Matrox Millenium G200 AGP if that is any help. Any suggestions for getting all those modes to work? Also, do you know of any chipsets that just don't 'work' with the VESA support for large splash screens? We have a bunch of ATI Rage3D cards at my school that won't load any splash screen above 320x200 even though they support VESA 2.0 and contain lots of video modes in their tables. > Kazu --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pv_table/pv_entry
:Going through the 4.4 BSD book, I learnt that the purpose of the pv_table :is to be able to locate all the mappings to a given physical page. : :However, comparing this to the Linux approach, which chains vm_area_struct :(analogous to vm_map_entry in FreeBSD) together to locate the shared :mappings, it appears to me that the Linux approach is more space efficient. : :So why not eliminate pv_table and chain vm_map_entries together to represent :the sharing information ? : : -Arun The primary difference between the FreeBSD method and the Linux method is that the linux method takes a heavy toll in cpu by requiring a test for the page in every VM map that *might* contain that page. Since most pages in the vast majority of objects are not mapped, the FreeBSD way of doing things is typically O(1) while the linux way is O(N). This may not seem expensive, but consider what happens when you have to manipulate a *range* of pages within an object. The FreeBSD way becomes O(N) and the linux way becomes O(N^2). ( Now I'm simplifying... the FreeBSD way isn't *precisely* O(N), but neither is it anywhere near O(N^2) ). Another big difference between Linux and FreeBSD is with how page tables are maintained. Under Linux, page-tables are SWAP-BACKED. This is because Linux maintains considerable state in its page tables which cannot be recreated from other sources. Under FreeBSD, page-tables are THROW-AWAY, which means that FreeBSD can throw away elements in page tables and even whole page tables at very low cost. The FreeBSD way makes it fairly trivial for the VM system to manage pages, especially when figuring out the type of activity being performed on pages. This gives FreeBSD a significant advantage in determining which pages are good candidates to swap out or throw away. The equivalent operation under Linux is a very expensive scan of all page tables in all processes. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script:
David Scheidt wrote:
>
> On Tue, 1 Jun 1999, Wes Peters wrote:
>
> > If you mean "lack of competition would make UNIX more homogenous and
> > more viable to every Tom, Dick, and Jane that comes down the pike,"
> > I will agree with that. I just disagree that this is success. UNIX
> > was never meant to be a word processor loader, and complete overkill
> > for such an application.
>
> I should point out that UNIX's suitably as a document processing
> enviornment is one of the reasons that UNIX received support from
> BTL management. The fact that it was stable, ran on cheap hardware,
> and a cool programing enviornment were bonuses.
According to PJ, you've got it exactly backwards. The people who
created it did so because they wanted to fix all the things that
went wrong with the Multics project. Once they'd essentially done
this, they wanted to continue to work on their new system, and looked
for a way to "sell" it to Lab management. Joe Ossana was looking
into document processing tools and talked to some of the UNIX people,
and history was made. The ongoing text processing work became one
of several projects that were developed at Bell Labs on UNIX, but
it was not the reason UNIX was created.
And, as far as *word processors* go, troff, nroff, and ed pretty
much suck. Don't get me wrong, I completely agree they are useful
tools, as borne out by the number of books that have been typeset
over the years using troff. But a word processor they DO NOT make.
> I strongly disagree that UNIX is overkill for any application.
> Why shouldn't the user be given a stable, flexible platform to do
> their work on? Especially if it is one that makes efficient use
> of the hardware the user has, so they needn't buy new hardware
> every six months?
They should, but you certainly don't need UNIX to do this. See,
for instance, a PalmPilot, or even a WinCE H/Pro. You sure as
hell don't need UNIX to run your car stereo or your sparkplugs.
There is a time and a place for everything. I think we agree that
the time and place for Windows is/was "in the garbage can, in
mid-August 1995. ;^)
It is (of course) true that MOST of the embedded operating systems
available these days are rather UNIX-like, either in their internal
structure or at least in their API model. This is a sure sign that
the original UNIX model was a very good model for providing services
to programmers. But UNIX systems, even stripped down ones, still
make a lot of assumptions about what a computer is that are terribly
unnecessary to a large range of applications.
> One of the machines I run -CURRENT on is a 4
> year-old Pentium. Other than build times being longer than I would
> like, I don't have noticable performance issues. The same machine
> is essentially unable to run NT, and do work at the same time.
But as a word processor, is it really any better than MacWrite on an
original Mac 128K? Or, to stack the deck a little more, a Mac Plus?
*I* don't think so. That was a system well suited to word processing,
except the tiny screen. Nothing since then has advanced the state of
the art in word processing, only in being able to do other things with
your word processor.
> {1} Anyone need a copy of the UNIX system V Release 2 User and Programmer
> Reference Manuals?
No thanks, I have the full, 5-volume set from CBS College Publications.
I still use it when I need to look up troff or nroff information. ;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr w...@softweyr.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Help with panic 12 using 3.1 on compaq prosignia 300
Hi there!
Apologies if I have selected the wrong list to post this question.
Advice is appreciate, and I've tried to do my homework first.
I am consistenly receiving a panic 12 (page not present) after
installing FreeBSD 3.1 from the Walnut Creek CD's on an old Compaq
Prosignia 300 I had laying around. Quick configuration (complete dmesg
output below);
onboard NCR SCSI controller
onboard AMD ethernet (using lnc driver)
ATI Mach64 video card
SCSI CD-ROM, 3 SCSI disks (1 int., 2 ext.)
158MB RAM, 300MB Swap
The system installed OK, and runs fine until I perform an operation that
involves a lot of disk access, at which time I receive a panic 12 (exact
text below). For example, untar-ing an archive or performing a cvs
checkout aways cause this problem (not immediately, but consistently).
I can rebuild the kernel, though, so I added debugging symbols, turned
on dumps and then took a look at the result using kgdb. It is lengthy,
but I have added a script of the kgdb output to this message, as well as
the dmesg output from boot time. This particular dump was from a cvs
-z6 co command.
The symptom is that the crfree() function is receiving a bad pointer,
but the actual problem is likely up the call chain. Unfortunatley, I'm
not very familiar with dealing in kernel code and was hoping someone out
there might be able to lend a hand.
One guess: why is getblk() being called with blkno=0? Just looks
suspicious to me.
Byron
p.s. I have read in the 3.2 FAQ that it does not support the NCR and AMD
drivers yet, so trying that version is out of the question for now.
-- kgdb session script ---
Script started on Tue Jun 1 17:23:46 1999
mink# gdb -k
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for
details.
GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software
Foundation, Inc.
(kgdb) symbol-file kernel
Reading symbols from kernel...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 2990080
initial pcb at 26ee84
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x69a2c6dc
fault code = supervisor write, page not present
instruction pointer = 0x8:0xf014c196
stack pointer = 0x10:0xf2eecce0
frame pointer = 0x10:0xf2eecce0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 253 (cvs)
interrupt mask = bio
trap number = 12
panic: page fault
syncing disks... 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47
47 47 giving up
dumping to dev 20401, offset 581632
dump 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xf014d3b4 in at_shutdown (
function=0xf024aecb <__set_sysinit_set_sym_memdev_sys_init+1115>,
arg=0xf2eb1f40, queue=-219457216) at ../../kern/kern_shutdown.c:446
#2 0xf020e005 in trap_fatal (frame=0xf2eecca4, eva=1772275420)
at ../../i386/i386/trap.c:942
#3 0xf020dce3 in trap_pfault (frame=0xf2eecca4, usermode=0,
eva=1772275420)
at ../../i386/i386/trap.c:835
#4 0xf020d95a in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 1,
tf_esi = -248389704, tf_ebp = -219231008, tf_isp = -219231028,
tf_ebx = 8192, tf_edx = 0, tf_ecx = -1073217472, tf_eax =
1772275420,
tf_trapno = 12, tf_err = 2, tf_eip = -267075178, tf_cs = 8,
tf_eflags = 66050, tf_esp = -219230960, tf_ss = -266951185})
at ../../i386/i386/trap.c:437
#5 0xf014c196 in crfree (cr=0x69a2c6dc) at ../../kern/kern_prot.c:802
#6 0xf016a5ef in getnewbuf (vp=0xf2f422c0, blkno=0, slpflag=0,
slptimeo=0,
size=1024, maxsize=8192) at ../../kern/vfs_bio.c:1116
#7 0xf016adfe in getblk (vp=0xf2f422c0, blkno=0, size=1024, slpflag=0,
slptimeo=0) at ../../kern/vfs_bio.c:1510
#8 0xf01d971a in ffs_balloc (ap=0xf2eecea8) at
../../ufs/ffs/ffs_balloc.c:170
#9 0xf01dd824 in ffs_write (ap=0xf2eecefc) at vnode_if.h:1015
#10 0xf01766e7 in vn_write (fp=0xf0768340, uio=0xf2eecf40,
cred=0xf075f880)
at vnode_if.h:331
#11 0xf0157f1e in write (p=0xf2eb1f40, uap=0xf2eecf94)
at ../../kern/sys_generic.c:270
#12 0xf020e247 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =
134884646,
tf_esi = 135032281, tf_ebp = -272639168, tf_isp = -219230236,
tf_ebx = 5, tf_edx = 0, tf_ecx = 0, tf_eax = 4, tf_trapno = 7,
tf_err = 2, tf_eip = 672165828, tf_cs = 31, tf_eflags = 582,
tf_esp = -272655984, tf_ss = 39}) at ../../i386/i386/trap.c:1100
#13 0xf0201e4c in Xint0x80_syscall ()
#14 0x805051b in ?? ()
#15 0x80515b8 in ?? ()
#16 0x8052cbc in ?? ()
#17 0x8052d6c in ?? ()
#18 0x804e109 in ?? ()
#19 0x80684b6 in
pv_table/pv_entry
Going through the 4.4 BSD book, I learnt that the purpose of the pv_table is to be able to locate all the mappings to a given physical page. However, comparing this to the Linux approach, which chains vm_area_struct (analogous to vm_map_entry in FreeBSD) together to locate the shared mappings, it appears to me that the Linux approach is more space efficient. So why not eliminate pv_table and chain vm_map_entries together to represent the sharing information ? -Arun To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Partitioning a freebsd partition on the fly
On Tue, 1 Jun 1999, Evan Tsoukalas wrote: > My question is, can I shrink my /usr partition down without losing what is on > it? It is a 3.8 gig partition that only has 900 meg or so on it. I would > like to trim about a gigabyte off of it so that I can install Windoze. Is > this going > to be possible, or should I start from scratch installing Winoze first? Resizing FFS filesystems is not possible. In addition, I find that windoze deals with dual-boot machines much better if windows is installed first. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system?
Darryl Okahata wrote: >Peter Jeremy wrote: >> How about storing each port as a single file in ar(5) format, which is >> unpacked into the directory structure when make'd? ar(5) is a text >> format, which means it can easily be managed by CVS, which includes >> a tool for manipulating its contents - ar(1). > > This isn't all that different from the existing *.tar.gz port >files. If you use those, you get all the advantages of your approach, >plus fewer disadvantages: I think you've misunderstood me. There are three distinct sets of files associated with a port: 1) The port-and-FreeBSD-specific config files which are stored under /usr/ports//. These files comprise a Makefile, various package files in pkg and various optional patches and scripts. 2) The original distribution file. This may be located anywhere on the internet (the location and name is in the port Makefile) and will be stored in /usr/ports/distfiles after download. These can be in any format, but .tar.gz is probably the most common. 3) Pre-built ports available as packaged from ftp.freebsd.org. I think these are all .tar.gz, but some might be bzip2 format. The discussions have all centered on 1) above. This is the area where there is the greatest wastage of resources (inodes and unused partial blocks). > - No need to CVS commit ar files. (BTW, CVS can also handle binary >files, so ASCII vs. binary is a non-issue.) The problem is that the diffs between 2 uuencoded .tar.gz files (which is how CVS would treat them) tend to contain the entire contents of both files. >> Disadvantages: - CVS files will bloat. - relatively difficult to examine the innards of the files for each port. Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
>The discussion started with a remark about the fact that 3Com cards have >problems under load, without a backing of that statement. That is the >thing that made people trip over. It is a statement that is not the >least helpful for anyone on the hackers mailing list and will not >trigger help from anyone, apart from responses from people being >frustrated about not being able to help (sounds silly but it is >true, their puppy is being attacked without them being able to >respond). > > > > You're wrong! I tried to participate but everybody just told me that I'm an > > idiot. Well perhaps they're right but if nobody wants to hear my bug report > > then I'll use another card. A card which driver has been better tested and > > where gifted programmers did the bug reports. > >You think along the lines of least resistance for solving your problems, >while developers think along the lines of highest resistance to get bugs >sorted out. Added to that was quite a bit of (justifiable) frustration >from Bill P. side. > >And I don't think people call you an idiot and if they did, they are >wrong. They are however entitled to express their opinion in a for them >suitable way and should be read with their background and a context, you >might not be fully aware of, in mind. Do not mistake this for people >being angry at you. If you are able to read emotions from an e-mail >accurately, you have a very special gift. A good developer knows that not everyone that uses his product is technically capable to help out when there is a problem. Sometimes you cant even get people to explain the basic symptoms. A developers job is to develop a test bed to recreate problems based on what users tell him. You can't expect users to spend their time debugging your code. If you get one your lucky...you cant *expect* people to work with you...people have things to do. Why should they struggle with one $58. card when for $49. they can get a different one that works? Thats common sense. Until you find someone with a truckload of 3com cards that doesnt want to have to toss them all you have to find the problems yourself. Most of my customers are internet service providers...if their net is down for 5 minutes the phones start ringing off the wall. They need something that works NOW. Bill, when you get out the last bug you can stand on your desk and beat your chest and everyone will applaud you. Until then, you have a headache. Dont be pissed at me...I have more headaches thnn I have heads without worrying about yours too. I find that a nice cold Bass Ale is soothing when Im working on a killer bug. Have a beer, watch the Knicks beat up on the Pacers. Very relaxing. Dennis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
pipe device driver changes up for review
My changes to kern/sys_pipe.c are now available for review. The read changes are already in the queue for Alan to commit. The write changes are undergoing testing. http://www.backplane.com/FreeBSD4/ It would probably be easiest just to review the post-patched file, the diffs are kinda messy. pipe_read(), pipe_write(), and pipe_direct_write() were modified. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script:
On Tue, 1 Jun 1999, Wes Peters wrote:
> If you mean "lack of competition would make UNIX more homogenous and
> more viable to every Tom, Dick, and Jane that comes down the pike,"
> I will agree with that. I just disagree that this is success. UNIX
> was never meant to be a word processor loader, and complete overkill
> for such an application.
I should point out that UNIX's suitably as a document processing
enviornment is one of the reasons that UNIX received support from
BTL management. The fact that it was stable, ran on cheap hardware,
and a cool programing enviornment were bonuses. My bookshelves at
work are kept from floating away by a bunch of elderly UNIX
documentation{1}, which spend a lot of space describing the tools
that let you write papers and books with the system. Of course,
much of what made UNIX suitable for this sort work also made it
adaptable for all the other things that UNIX boxes do to earn their
keep. Things like the pipe, which make it possible to quickly put
together useful programs, because you have to do so little besides
what you really need to do. Raise your hand if you have a two line
pipeline that replaced an expensive commercial application.
I strongly disagree that UNIX is overkill for any application.
Why shouldn't the user be given a stable, flexible platform to do
their work on? Especially if it is one that makes efficient use
of the hardware the user has, so they needn't buy new hardware
every six months? One of the machines I run -CURRENT on is a 4
year-old Pentium. Other than build times being longer than I would
like, I don't have noticable performance issues. The same machine
is essentially unable to run NT, and do work at the same time.
David Scheidt
{1} Anyone need a copy of the UNIX system V Release 2 User and Programmer
Reference Manuals?
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
>> The discussion started with a remark about the fact that 3Com >> cards have >> problems under load, without a backing of that statement. That is the >> thing that made people trip over. It is a statement that is not the >> least helpful for anyone on the hackers mailing list and will not >> trigger help from anyone, apart from responses from people being >> frustrated about not being able to help (sounds silly but it is >> true, their puppy is being attacked without them being able to >> respond). If it "had no backing" then how could it be a "fact"? replacing the cards with intels and having the problem go away is backing. It may not be *useful*, but it is backing. Dennis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
On Tue, 1 Jun 1999, Nik Clayton wrote: > On Sun, May 30, 1999 at 11:21:57PM -0400, Chuck Robey wrote: > > You guys should be aware that work is going on to change, in a rather > > major way, not just the config file, not just the configuration method, > > but the entire way that devices are detected and drivers added. > > Is this documented anywhere? Not the fact that things are going to change, > but what the user visible component of that change is? I'd hate for the > Handbook et al to suddenly be seriously out of date when a new config > mechanism is upon us. I don't think so, but I wouldn't press it right now. I'm answering this privately, because there is some controversy, and some really hurt feelings, over some of it. You see, some folks in Japan went off on their own and developed a "newconfig", which has a lot fo things in common with the work that Peter's gone and done, but also has some basic differences. They worked pretty much totally in silence. so when core told Peter to go ahead, the Japanese group *finally* opened their mouth, and there have been a lot of very hurt feelings, because of the large amount of work that was expended, and now is going to be lost. What was at the bottom of it was the idea of _communications_ itself, which Peter is/was doing, and the Japanese were not at all. They were just off on their own, assuming that they had a clear field, and that anything they developed would be accepted. There was no debate over features at all, which very correctly scared core. The thing that's finally been accepted is a pretty complete rewrite of the bus code, so things like devices that suddenly show up, like for plug in cards in portable machines, can announce themselves and get loaded dynamically. As much as possible, the entire idea of needing a config file is going to go away. Some of this is because of the success of the kld kernel loadable modules. There is more work on loadable modules, for dependency checking/loading, and better links between module file names, and module code names. This is a very fluid thing, and development sometimes takes a step backwards. Things are changing very quickly, which means that right now is an incredibly bad time to decide to make automated config tools, because the problem that automated config tools are intended to solve is going to be completely elminated, not just eased. Like I said, what's really needed now is a weekly summary of development of -current and -committers. In odoing it, tho, we *don't* want to add some huge extra mail load on Peter, Doug, Daniel, Mike, and others working towards all this. Many people who hang around hackers and are completely clueless, want to force folks to do it their way, because they won't spend the time to follow the lists and find out that *their* way is now obsolete. It gets complicated, doesn't it? +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Dennis wrote: > > At 08:00 AM 6/1/99 -0700, you wrote: > >On Tue, 1 Jun 1999 10:09:59 +0200 > > Alexander Maret wrote: > > > > > At first I tried my FreeBSD machine and I got about 800-900 collisions. > > > Second I booted on the same machine linux and I only got 4 (!) collisions. > > > >It's also possible that Linux isn't counting the collisions properly. > > > > > I have no problem with thousands or millions of collissions, as long as > > > they don't crash my computer. I just want a running system. > > > >Collisions don't cause your system to crash. If this is happening, > >something else is at fault (though that something else may be an > >unrelated problem in the Ethernet driver). > > If your nic driver chains packets (such that there is no time in between) > you will see good throughput from the box but your overall network > performance will suffer. Overall network performance will be much greater until the collision rate raises high enough to lower it. The only way to determine this is to try it, unless you have some pretty sophisticated network modelling tools. > A PCI card with continueous traffic can completely > hog your lan (particularly at 10Mb/s)... Even at 100Mb/s with good cards and moderatly fast computers. "Hogging your LAN" is spelled the same as "getting 100% throughput" around here, and is considered a GOOD thing. I fail to see how obtaining 200Mb/s (full-duplex) throughput on a $50 lan adapter is a bad thing. > which can cause a lot more > collisions on your network as other devices will not have access until the > hog is finished sending. For "Fairness" gaps in between frames are better > as you approach capacity of your wire. Or just do yourself a favor and buy a good switch, which avoids the collision problems neatly. Ethernet doesn't have to be a shared media system. I can help if you want suggestions. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
On Tue, 1 Jun 1999, Dennis wrote: > If your nic driver chains packets (such that there is no time in > between) you will see good throughput from the box but your overall > network performance will suffer. A PCI card with continueous traffic > can completely hog your lan (particularly at 10Mb/s)...which can cause > a lot more collisions on your network as other devices will not have > access until the hog is finished sending. For "Fairness" gaps in > between frames are better as you approach capacity of your wire. The ethernet spec defines the acceptable inter-frame gap. Some cards have been known to use the minimum or less in order to 'go faster'. I believe that this is tunable on some cards. (LANCE comes to mind.) If the card isn't using the correct IFG and doesn't provide a knob to fix it, then there isn't much we can do when the card captures the wire. Enabeling interrupt per packet isn't the answer either. If you're running an unswitched LAN and use rogue cards you aren't in a position to fuss when they do bad things. If you cared about speed you'd use a switch in full duplex mode. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing special device files
On Tue, 1 Jun 1999, Wes Peters wrote: > > dd verifies the behavior you report: > > r...@homer# dd if=/dev/rwd0s2b of=/dev/null bs=1 > dd: /dev/rwd0s2b: Invalid argument > ... > r...@homer# dd if=/dev/rwd0s2b of=/dev/null bs=512 > ^C18805+0 records in > ... > > w...@homer$ ls -l /dev/*wd0s2a > crw-r- 1 root operator3, 0x0003 Apr 1 11:10 /dev/rwd0s2a > brw-r- 1 root operator0, 0x0003 Apr 1 11:10 /dev/wd0s2a > > The rwd device is clearly a character-special device, the wd device a > block special. Character devices can always be read byte-at-a-time, > by definition. When did the semantics of this change? It's always been this way think of the devices as "RAW and buffered", rather than "character and block" RAW devices are limted by the hardware limtiations. Buffered devices use buffering to hide those limitations. > > -- >"Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > http://www.softweyr.com/~softweyr w...@softweyr.com > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing special device files
> From: Wes Peters > Date: 1999-06-01 11:50:23 -0700 > To: Julian Elischer > Subject: Re: Accessing special device files > Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG > X-Accept-Language: en > Delivered-to: freebsd-hackers@freebsd.org > X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) > X-Loop: FreeBSD.ORG > Organization: Softweyr LLC > > Julian Elischer wrote: > > > > Bzzzt! > > > > On Tue, 1 Jun 1999, Wes Peters wrote: > > > > > Zhihui Zhang wrote: > > > > > > > > I write a small program to read/write each FreeBSD partition via special > > > > device file names, e.g. /dev/wd0s2e, /dev/rwd0s2e, etc. I have two > > > > questions about doing this: > > > > > I know this is confusing but you are 100% backwards.. > > . > > ??? > > dd verifies the behavior you report: > > The rwd device is clearly a character-special device, the wd device a > block special. Character devices can always be read byte-at-a-time, > by definition. When did the semantics of this change? Don't let the name fool you. The term 'character device' doesn't mean "byte-at-a-time". It's just a name in opposition to "block device", which is buffered. The real distinction is buffered (block) v. un-buffered (character), and even that's a bit blurry. Raw (character) disk devices have always had this behavior. Back in The Good Old Days, physio() actually worked direct to user buffers, so the rule was "block size and granularity", was dictated by a combo of what physio() and the device driver were willing to do. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
m3socks and cvsup
Hi, I have some problems with m3socks and cvsup. The configuration files and output follows... m3socks.conf: findserver No sockd @=socks.student.uu.se 0.0.0.0 0.0.0.0 server socks.student.uu.se output: m3socks cvsup -g -L 3 cvs-stable Parsing supfile "cvs-stable" Looking up address of cvsup.se.freebsd.org Connecting to cvsup.se.freebsd.org can't resolve open-nameserver Unable to connect to a server: Connection refused Cannot connect to cvsup.se.freebsd.org: Connection refused - m3socks.conf: findserver No nameserver 172.17.1.2 sockd @=socks.student.uu.se 0.0.0.0 0.0.0.0 server socks.student.uu.se output: m3socks cvsup -g -L 3 cvs-stable Parsing supfile "cvs-stable" Looking up address of cvsup.se.freebsd.org Connecting to cvsup.se.freebsd.org Unable to connect to a server: Undefined error: 0 Cannot connect to cvsup.se.freebsd.org: TCP.Unexpected: 0 /Best regards Christian Murray To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing special device files
On Tue, 1 Jun 1999, Wes Peters wrote: > > ??? > > dd verifies the behavior you report: > > r...@homer# dd if=/dev/rwd0s2b of=/dev/null bs=1 > dd: /dev/rwd0s2b: Invalid argument > ... > r...@homer# dd if=/dev/rwd0s2b of=/dev/null bs=512 > ^C18805+0 records in > ... > > w...@homer$ ls -l /dev/*wd0s2a > crw-r- 1 root operator3, 0x0003 Apr 1 11:10 /dev/rwd0s2a > brw-r- 1 root operator0, 0x0003 Apr 1 11:10 /dev/wd0s2a > > The rwd device is clearly a character-special device, the wd device a > block special. Character devices can always be read byte-at-a-time, > by definition. When did the semantics of this change? > I have verified the requirement that character device must be read in multiples of 512 from the source code point of view (the disk involved in an IDE drive): When we call read(int d, void *buf, size_t nbytes) system call, the argument nbytes is passed on to the iov_len field of an iov structure (see file sys_generic.c). Later, the routine vn_read() in file vfs_vnops.c is called via the structure fileops, the uio structure is passed along. vn_read() will call spec_read() via VOP_READ() because we are talking about raw device file name. spec_read() will call wdread() via the cdevsw table. wdread() will call physio() where b_bcount of a buffer is set to be iov_len. The routine wdstrategy() invoked by physio() will check if bp->b_bcount % DEV_BSIZE != 0. If it detects an request size that is not a multiple of 512, it will set b_error = EINVAL. This error will be picked up by physio() and returned. Thanks for your help. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing special device files
Julian Elischer wrote: > > Bzzzt! > > On Tue, 1 Jun 1999, Wes Peters wrote: > > > Zhihui Zhang wrote: > > > > > > I write a small program to read/write each FreeBSD partition via special > > > device file names, e.g. /dev/wd0s2e, /dev/rwd0s2e, etc. I have two > > > questions about doing this: > > > > > > (1) If I try to read() on these files, the buffer size must be given in > > > multiples of 512 (sector size). Otherwise, I will get an EINVAL error. > > > Why is this the case? Does the same thing happen to the write() system > > > call? > > > > > > (2) I use lseek() on these device files, it returns the correct offset for > > > me. But actually it does not work. I read in a recent posting saying that > > > you can't expect lseek(fd, 0, SEEK_END) to work unless the file descriptor > > > is associated with a regular file because file size information is not > > > available at that level. Does this apply to all kinds of lseek(), include > > > SEEK_SET and SEEK_CUR? Or maybe the offset must also given in a multiple > > > of 512 for some reason. If I give lseek(fd, 8193, SEEK_SET), it will > > > actually do lseek(fd, 8192, SEEK_SET)? > > > > They're block devices, they can only be read, written, and seeked in > > terms of their native block size. The block size is typically 512 > > bytes for disks, other types of media (like CD-ROM) may vary greatly > > from this. > > > > If you want to read, write, or seek to arbitrary ranges, use the "raw" > > devices, i.e. rwd0s2e. These are character devices that will allow > > you to read, write, and seek to arbitrary byte locations on the device; > > the kernel handles the buffering and blocking for you. > > I know this is confusing but you are 100% backwards.. > > the RAW device can only be accesses in units supported by the hardware.. > i.e. usually 512 byte chunks.. > however the Buffered device (e.g. wd0s1a) may be accessed on any boundary > as it buffers the data, (at least for reads). > it accesses the device in 512 byte chunks but this is hidden from you.. > this is why it's a buffered device ??? dd verifies the behavior you report: r...@homer# dd if=/dev/rwd0s2b of=/dev/null bs=1 dd: /dev/rwd0s2b: Invalid argument ... r...@homer# dd if=/dev/rwd0s2b of=/dev/null bs=512 ^C18805+0 records in ... w...@homer$ ls -l /dev/*wd0s2a crw-r- 1 root operator3, 0x0003 Apr 1 11:10 /dev/rwd0s2a brw-r- 1 root operator0, 0x0003 Apr 1 11:10 /dev/wd0s2a The rwd device is clearly a character-special device, the wd device a block special. Character devices can always be read byte-at-a-time, by definition. When did the semantics of this change? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
At 11:03 AM 6/1/99 -0700, you wrote: > >> >> If your nic driver chains packets (such that there is no time in between) >> you will see good throughput from the box but your overall network >> performance will suffer. A PCI card with continueous traffic can completely >> hog your lan (particularly at 10Mb/s)...which can cause a lot more >> collisions on your network as other devices will not have access until the >> hog is finished sending. For "Fairness" gaps in between frames are better >> as you approach capacity of your wire. >> >> Dennis > > > the interframce gap will allow other hosts to contend for the >wire. the ethernet capture effect decreases as the number of hosts on >the segment increases. the interpacket gap is 9.6uS (or 96 bit >times). an ethernet card listens to the wire before >transmitting a card that is not able to transmit because the wire is >busy will begin transmitting as soon as the wire goes quiet. the max >length of an ethernet is 46 bit times. so a waiting card will alaways >get first crack at the wire. capture effect is due to stations >colliding in trying to access the wire. those that dont collide, are >immune to the capture effect and get the wire first. and if you have 2 cards waiting? or 3? or 10? Im not sure why, but with certain PCI drivers there are a lot more collisions. Dennis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: so_cred changes
On Mon, May 31, 1999 at 07:27:57AM -0400, Brian Feldman wrote: > On Mon, 31 May 1999, Chris Costello wrote: > > On Sun, May 30, 1999, Nik Clayton wrote: > > > Cheers, committed. > > > >Already? As the CVS tree (at least the one on > > anoncvs.freebsd.org) has it, the so_cred changes haven't been > > committed yet. > > *Laugh* I think that the doc was the only thing that was committed. Hey! People are always complaining that the docs lag the implementation. OK, so possibly I should have read the thread first. But I'd just committed 15 or 16 doc PRs -- as soon as I saw a patch the reflex action kicked in. . . N -- The trial continues tomorrow. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
On Sun, May 30, 1999 at 11:21:57PM -0400, Chuck Robey wrote: > You guys should be aware that work is going on to change, in a rather > major way, not just the config file, not just the configuration method, > but the entire way that devices are detected and drivers added. Is this documented anywhere? Not the fact that things are going to change, but what the user visible component of that change is? I'd hate for the Handbook et al to suddenly be seriously out of date when a new config mechanism is upon us. Cheers, N -- The trial continues tomorrow. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Review: Having aio.h include sys/time.h
Hi folks, docs/11589 says that programs that include aio.h also need to include sys/time.h. I've had a chat with Terry Lambert, who wrote the aio_read.2 manual page, who says > And here is a section from the aio.h manual page (from the > Single UNIX Specification): > > Inclusion of the header may make visible symbols > defined in the headers , , > and . > > Basically, this means that the aio.h header is *defined* as > including sys/types.h (because of off_t and size_t), and is > defined as either including the other headers as well (bad) > or as forward declaring some types as opaque: > Since the Single UNIX Specification make no note of a header > other than aio.h, I'm afraid that the answer is that the aio.h > must include these headers, or directly define the respective > types itself. > > While I dislike promiscuous headers, I believe it is better to > be able to compile and run standards compliant UNIX code. So I want to apply the following very trivial patch; Index: aio.h === RCS file: /home/ncvs/src/sys/sys/aio.h,v retrieving revision 1.9 diff -u -r1.9 aio.h --- aio.h 1999/01/17 22:33:08 1.9 +++ aio.h 1999/06/01 17:57:36 @@ -19,6 +19,7 @@ #ifndef _SYS_AIO_H_ #define_SYS_AIO_H_ +#include #include #include Any objections? I know nothing about the aio* stuff at all, which is why I'm checking first. N -- The trial continues tomorrow. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
> > If your nic driver chains packets (such that there is no time in between) > you will see good throughput from the box but your overall network > performance will suffer. A PCI card with continueous traffic can completely > hog your lan (particularly at 10Mb/s)...which can cause a lot more > collisions on your network as other devices will not have access until the > hog is finished sending. For "Fairness" gaps in between frames are better > as you approach capacity of your wire. > > Dennis the interframce gap will allow other hosts to contend for the wire. the ethernet capture effect decreases as the number of hosts on the segment increases. the interpacket gap is 9.6uS (or 96 bit times). an ethernet card listens to the wire before transmitting a card that is not able to transmit because the wire is busy will begin transmitting as soon as the wire goes quiet. the max length of an ethernet is 46 bit times. so a waiting card will alaways get first crack at the wire. capture effect is due to stations colliding in trying to access the wire. those that dont collide, are immune to the capture effect and get the wire first. http://wwwhost.ots.utexas.edu/ethernet/papers.html jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
> Dennis wrote: > > > For "Fairness" gaps in between frames are better > > as you approach capacity of your wire. > > Isn't there some ethernet requirement (implemented on the NIC) that a > transmitter holds off the wire a little to give other NICs enough time > to notice there's nothing being transmitted? > > The sequence of events would be something like: > > NIC1 NIC2time | >v > start xmit > host queues next packet > xmit finishes > start "back-to-back" delay > sense idle wire > start xmit > sense access from NIC2 > "back-to-back" delay ends > wait for wire idle > xmit finishes > sense idle > start xmit > > No, only when there is a collision, both sides then wait a random amount of time before trying again. Marc. Marc van Kempen BowTie Technology Email: m...@bowtie.nlWWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
At 02:50 PM 5/30/99 -0700, you wrote: >> >> I have no stake in 3com cards (they are >> >> problematic in LINUX as well)...maybe the cards are flawed? Its not my >> >> problem. >> > >> >It *is* your problem. Supposing you can't get Intel cards anymore. >> >Then what're you going to do. >> >> Use something else that works. If none of them work then FreeBSD is no >> longer a viable option. > >This is the core fallacy; you should restate this as: > > "If none of them work, then FreeBSD is no longer a viable option > because it will require me to do some work to help fix them". > >I'm sorry; the FreeBSD Project is dedicated to developing operating >system code, not wiping your ass. You've received abundant offers of >assistance requiring no more than minimal effort on your part, and >turned them all down. This kind of selfish laziness is something we >can all do without. hey mike, why dont you try to pay attention. This was a CUSTOMER who was UNWILLING to donate their network to the freebsd project. Get it? I dont have 3com cards, I dont like 3com. I just reported that someone had a problem. I already work 70 hours a week pal, so dont give me this "lazy" bullshit. Im supposed to fix the 3com driver and the dec driver and the nfs code and all the other things wrong with freebsd, right? Why doesnt someone who ACTUALLY USES 3com cards donate their time? If noone is having a problem, then why worry? So if you are saying that we shouldnt report problems if we are not willing to donate our time to fix them then so be it. If you think that every time one of my customers has some problem with something in FreeBSD I'm going to spend days trying to fix it, you have been out in the outback way too long. Im not on the core team, its not my driver, and I couldnt give a rats ass if the 3com driver ever works...next time I'll just quietly tell the customer and let every other poor sole who uses 3com cards find out for themselves. What a seflish guy I am. DB To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Dennis wrote: > For "Fairness" gaps in between frames are better > as you approach capacity of your wire. Isn't there some ethernet requirement (implemented on the NIC) that a transmitter holds off the wire a little to give other NICs enough time to notice there's nothing being transmitted? The sequence of events would be something like: NIC1NIC2time | v start xmit host queues next packet xmit finishes start "back-to-back" delay sense idle wire start xmit sense access from NIC2 "back-to-back" delay ends wait for wire idle xmit finishes sense idle start xmit Or did I just fall asleep reading the spec and dream this. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Partitioning a freebsd partition on the fly
Hello, I'm not quite sure if this is the right mailing list to post my particular problem too, and I apologize if it is not. I have a Sony VAIO psg-505ts running a -CURRENT SNAP from 032799 with a 4.3gig disk entirely devoted to FreeBSD. I now have a need to run Windoze on this laptop, and I do not wish to reload all of the things that I have setup under FreeBSD. My question is, can I shrink my /usr partition down without losing what is on it? It is a 3.8 gig partition that only has 900 meg or so on it. I would like to trim about a gigabyte off of it so that I can install Windoze. Is this going to be possible, or should I start from scratch installing Winoze first? Any help would be greatly appreciated. -- Regards, Evan Tsoukalas Systems Administrator Source Electronics Corporation e...@sourcee.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
At 08:06 PM 5/30/99 -0700, you wrote: > >It is kind of interesting that now the shoe is on the other foot... > >A few months ago I purchased some sync cards from ET, and had some (and am >still having) trouble getting them to work consistently. > >When I emailed their support dept for help, I got a few curt non-helpful >replies, then a message about how if I didn't understand every nuance of >HDLC, and couldn't read the debugging output of his cards/software, then >I was (my interpratation, not his words exactly) not worth of his effort, >nor his company's products. You had the cards connected back to back, which is not a normal configuratoin. > >I have offered access to the boxes for the trivially repeatable problem I >am having, in order so that he can improve his product, but the answer so >far is "Try a new version of the software". The shotgun approach to tech >support. Because your problem has been fixed, I believe. Your constantly email and simply said "it doesnt work"...if you do it correctly it works, and I cannot debug a back-to-back config for you. > >It is no wonder that he does not invest effort in helping the 3com driver >work better, he is unwilling to work with a customer with a significant >dollar amount invested in his boards make *his* product better, why would >he be worried about improving others product, he has little interest in >improving his own. We have thousands of boards installedmaking them work back to back in a non-standard configuration does not make the product *better*, particularly when working with someone who cant provide useful info on *why* it doesnt work. I wish I could stop what I was doing every time someone had a problem, but I dont have that kind of time. > >Which is too bad, because when it works, it (the ET board) works just >great. When it doesn't, don't ask ET for help. What you get is a lot of >talking down, what you don't get is real help. I told you that we fixed something recently that sounded like the problem you were having...did you try it, or is it too much trouble? I cant debug old versions of software. If you are not using the latest version then you MUST upgrade to get proper support. We cant spend hours debugging problems that have already been fixed. It took you 2 weeks to find provide any useful information. When someone calls and says "it doesnt work" there is not much I can do. Next time try calling on the phone when you are in front of the machine instead of emailing snippits of useless info. Of course now that you've publically badmouthed us Im sure your requests well get very high priority :-) Dennis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
On Mon, 31 May 1999, Andrew Kenneth Milton wrote: > +[ Spike ]- > | > | a good enough job. I think this because in the end FreeBSD is going to > | lose to Linux if only from the sheer momentum of twenty million rabid > | Linux fanatics. And realistically, we aren't doing a damn thing about it. > > Technical discussions aside, I think that in reality, that it's that > fanaticism that will be Linux' undoing. There are already reports of > people switching from Linux to something else, because they got flamed/mail > bombed/etc for daring to do/try/mention something else. > > It's not easy for any commercial vendor to work in that type of environment. > > I think some of FreeBSD's long term strengths are that it is centralised, > and a willingness (from the userbase) to work with vendors to get applications > ported. The rabid zealots of the church of GNU are not likely to want to > *pay* for commercial applications on their free OS. It is not going to take > long for vendors to realise this. > > The FreeBSD community seems (to me) to be more commerically oriented, and > friendlier to commercial entities and even to 'competitors'. One success > story is all it will take to get other vendors interested -- vendors don't > really care about technically superiority, they want 'untapped markets.' sure, you are right. there's no available MapleV, Nagware F90, Pacific Sierra F90, Pacific Sierra HPF for Linux, but you can easy get them for FreeBSD. and do not forget there's no plans of releasing StarOffice, Adobe Acrobat Reader, Word Perfect for Linux. They all are available for FreeBSD though ! That's what people call 'commercially oriented' ! I've forgotten couple more applications, sorry... > > -- > Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew > The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton > ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig > PO Box 837 Indooroopilly QLD 4068|a...@theinternet.com.au|Specialist > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
At 08:00 AM 6/1/99 -0700, you wrote: >On Tue, 1 Jun 1999 10:09:59 +0200 > Alexander Maret wrote: > > > At first I tried my FreeBSD machine and I got about 800-900 collisions. > > Second I booted on the same machine linux and I only got 4 (!) collisions. > >It's also possible that Linux isn't counting the collisions properly. > > > I have no problem with thousands or millions of collissions, as long as > > they don't crash my computer. I just want a running system. > >Collisions don't cause your system to crash. If this is happening, >something else is at fault (though that something else may be an >unrelated problem in the Ethernet driver). If your nic driver chains packets (such that there is no time in between) you will see good throughput from the box but your overall network performance will suffer. A PCI card with continueous traffic can completely hog your lan (particularly at 10Mb/s)...which can cause a lot more collisions on your network as other devices will not have access until the hog is finished sending. For "Fairness" gaps in between frames are better as you approach capacity of your wire. Dennis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
> You don't want FreeBSD to have more users? Do you think it already has > enough users? How many users is enough? What is the goal of the FreeBSD > project? To be the test platform for new kernel ideas exclusively? Why > do you tolerate the presence of the X on the FreeBSD CD-ROMs then? I think this point was somewhat ill-made and should be taken more as Mike being grumpy than as any statement of official policy. :) > Making the script is like making more documentation. Is the current > FreeBSD documentation so plentiful that making more documentation would > harm somebody? Go ahead and do it. Like I said, this gets talked about a lot but only a few people have ever tried to actually do it. I've seen a few shell scripts in the past, but all were somewhat simplistic and also abandoned quickly, which is not what you want. If you get users to start using a new kernel configuration mechanism, it MUST be maintained on a regular basis (as new options are added) or you'll just lull them into a false sense of security and insulate them from new features and options which exist in the "classic" config files but are not yet in the configuration front-end tool. As others have also said, the real goal is to have truly generic kernels and dispense with config(8) forever. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
> I think its useful if it gets linux people less afraid of FreeBSD. This is one of those reocurring threads.. Everyone to contribute to it so far has either had no better ideas for "front ending" the kernel configuration process or lots of ideas but no time to implement them, resulting in the same [lack of] results either way. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Alexander Maret had to walk into mine and say: > Hi, > > > Well maybe FreeBSD is transmitting packets much faster than Linux. :) > > You still haven't actually measured the transfer speed, so there's > > no way for us to know. > > Well, I'll do and report the results to you. Actually, there's another difference between the behavior of the FreeBSD and Linux drivers that could affect this. There may be a similar difference between the FreeBSD and LoseNT drivers too, but I'm only vaguely familiar with how LoseNT (or rather, NDIS miniport) drivers work so I can't be sure about that. Basically, the driver has one particular entry point for initiating packet transmission. In Linux, this entry point gets handed a single packet (stored in an skbuff) and a pointer to the device structure for that particular driver instance. In FreeBSD, the start routine gets handed a pointer to the ifnet structure for the interface (which is associated with the driver). The ifnet structure in turn contains the send queue which may have several packets queued for transmission in the form of mbufs (the maximum number depends on the size of ifq_maxlen, which the driver can set at initialization time). The difference is that in Linux, the driver sets up a single DMA/transmit sequence at a time, because the transmit routine only gets access to one packet at a time. In FreeBSD, the driver has access to the entire send queue, where there may be several packets waiting. The driver can then handle the send queue as it sees fit: it can pop the first packet off the queue and transmit it, then wait for it to complete before moving on to the next packet, or it can pop a whole series of packets off the send queue and set up a large DMA transfer where all of the packets will get transfered at once, rather than one at a time. (The driver may still program the NIC to signal successful transmission of each frame in the transfer just to make sure things are working right, but it may also choose just to have the NIC acknowledge the last packet in the transfer in order to reduce the number of interrupts. The xl driver requests an interrupt only for the last frame in a DMA transfer.) The FreeBSD driver also sets the transmit threshold for best performance. The transmit start threshold specifies how many bytes should be transfered to the NIC's memory before it will begin putting the data on the wire. The idea is that transfer of data from the host to the NIC can proceed simultaneously with transmission of data from the NIC to the wire: as new data arrives in the NIC, it gets dumped onto the network as soon as possible. Note however that this only works well if the host can keep up. With slower systems, you may see transmit underruns where the NIC wants to transmit but the data isn't ready yet. In this case, the driver will increase the transmit start threshold and generate a message telling what happened. Eventually, the threshold will be increased enough that the transmit underrun condition will not appear anymore. This means that it's possible for the FreeBSD driver to transmit a whole bunch of packets at once with very little time in between. If there's another host transmitting back at the same time, this also means that you're more likely to see collisions. However it also means that you get very fast transmissions, which is supposed to be a good thing. Can you throttle back the xl driver? Well, yes, if you want. There are two things you can do: - Use a different default for the transmit start threshold. In xl_init(), the driver initializes sc->xl_tx_thresh to XL_MIN_FRAMELEN, which is 60. You can change this to 120 or 512, or even 1536 if you want to disable the threshold entirely and have the NIC wait until the whole packet has been DMAed into its memory before it starts a transmission. - Make xl_start() only queue one packet at a time. This unforunately requires some code changes (not big ones, but it's more than just changing a setting somewhere). > > Grrr. I'm sorry, but I really don't think you're putting the pieces > > together correctly. Setting the NT machine to full duplex should have > > absolutely no effect on the FreeBSD host. It will completely screw up > > performance since the LoseNT host will then no longer be set to match > > the hub, but that's another problem. I strongly suspect that you're > > not making the proper observations when your problem manifests and > > just leaping to the conclusion that setting the LoseNT host to full > > duplex crashes the FreeBSD host. > > I just tell you what i experienced. Well, it's suspicious. It gives the impression that setting the LoseNT host to full duplex mode somehow angered the computer gods, prompting them to make your FreeBSD host spontaneously reboot. Also, there might be more to it. For example, if you were running the X Window system on the console at the time, then there may have been a panic
Re: Accessing special device files
Bzzzt! On Tue, 1 Jun 1999, Wes Peters wrote: > Zhihui Zhang wrote: > > > > I write a small program to read/write each FreeBSD partition via special > > device file names, e.g. /dev/wd0s2e, /dev/rwd0s2e, etc. I have two > > questions about doing this: > > > > (1) If I try to read() on these files, the buffer size must be given in > > multiples of 512 (sector size). Otherwise, I will get an EINVAL error. > > Why is this the case? Does the same thing happen to the write() system > > call? > > > > (2) I use lseek() on these device files, it returns the correct offset for > > me. But actually it does not work. I read in a recent posting saying that > > you can't expect lseek(fd, 0, SEEK_END) to work unless the file descriptor > > is associated with a regular file because file size information is not > > available at that level. Does this apply to all kinds of lseek(), include > > SEEK_SET and SEEK_CUR? Or maybe the offset must also given in a multiple > > of 512 for some reason. If I give lseek(fd, 8193, SEEK_SET), it will > > actually do lseek(fd, 8192, SEEK_SET)? > > They're block devices, they can only be read, written, and seeked in > terms of their native block size. The block size is typically 512 > bytes for disks, other types of media (like CD-ROM) may vary greatly > from this. > > If you want to read, write, or seek to arbitrary ranges, use the "raw" > devices, i.e. rwd0s2e. These are character devices that will allow > you to read, write, and seek to arbitrary byte locations on the device; > the kernel handles the buffering and blocking for you. I know this is confusing but you are 100% backwards.. the RAW device can only be accesses in units supported by the hardware.. i.e. usually 512 byte chunks.. however the Buffered device (e.g. wd0s1a) may be accessed on any boundary as it buffers the data, (at least for reads). it accesses the device in 512 byte chunks but this is hidden from you.. this is why it's a buffered device julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
Darryl Okahata wrote: > > David Scheidt wrote: > > > On Sun, 30 May 1999, Bill Huey wrote: > > > > > That's fundamentally disturbing especially coming from other fellow > > > Unix variant folks. > > > > Inter-UNIX rivalries are one of things that has kept unix healthy for so > > long. Linux tends to pick up most of the 3L1t3 dudez, who don't know > > Inter-Unix rivalries are one of the big things that's slowed down > Unix development and allowed Windows to thrive. If the rivalries didn't > exist, Unix would be *MUCH* better than it currently is. I'm not just > talking about FreeBSD vs Linux; I'm talking about all of the other major > Unix vendors, too. Better how? More scalable? More reliable? You completely fail to understand that the Sun StarFire, the SGI Origin 2000, HP and AIX clusters exist because these companies COMPETE with each other to create the biggest, fastest, and most reliable computers around. If you mean "lack of competition would make UNIX more homogenous and more viable to every Tom, Dick, and Jane that comes down the pike," I will agree with that. I just disagree that this is success. UNIX was never meant to be a word processor loader, and complete overkill for such an application. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
Bill Huey wrote: > > > Inter-UNIX rivalries are one of things that has kept unix healthy for so > > long. Linux tends to pick up most of the 3L1t3 dudez, who don't know > > You must be joking me. Just about every other systems person I've talked > to in past 5 years, (including me) would highly disagree with that citing > that Unix fragementation is the main reason why Unix isn't more successful > commericially. No, he isn't joking, and you are making the mistake of equating commercial success with health. That leads to systems like WinNT, which is obviously much more commercially successful than any UNIX. (This isn't true, by the way, but I defy you to learn that from the popular press.) > Linux can be cited as the main unifying force propelling > Unix's come back. This of course assumes that one buys into the notion > that NT would obsolete Unix in a few years, which I never did in the first > place. Linux can be cited as any damn thing you please, when you're quoting yourself or a bunch of Linux fanatics. That certainly doesn't make it so. > It's doing so by unifying various fragmented group of people and is the main > movement forcing folks like Apple release their source code publically to > other devs. It's doing so by the exact same mentality that Microsoft has brought us through the years: least common denominator functionality that runs on the widest array of garbage hardware. > This is a very powerfully set of indicator of the Linux phenomenom and it > *must* be respected. Only if you're in this for money. Again, you seem to be equating commercial popularity with success. This is an attitude not necessarily shared by many here. It is puzzling to watch this mindset overtake the Linux crowd, who two years ago completely shunned commercialism of any sort. I for one will be amused as the commercial success of Linux becomes its downfall. > > anything but how to follow a How-To. I don't have a problem with letting > > HOW-TOs are useful and I person don't see why FreeBSD folks still talk down > to Linux folks. Even kernel tweekers that I know find those things useable. You don't understand: we're happy that Linux exists to server those users. Every Linux user is a user who isn't being raped by Microsoft. Since Linux exists to serve the less technically sophisticated who want to opt out of the Microsoft treadmill, we don't feel ANY need to help them, because Linux fits their needs perfectly and their wants and desires are less interesting to us than the wants and desires of the "technical elite." FreeBSD and Linux have always co-existed, and this is a good thing. > > someone else deal with annoying lusers. When they get a clue, and realize > > that FreeBSD has substantial advantages over Linux, then we can deal with > > them. It would be nice if there were some migration documentation. (And > > Well, the claim above seems overstated to me at this time and won't be clear > until I monitor various kernel discussions and explore/test FreeBSD. Linux > and FreeBSD have more similarities than differences from what I can tell. You haven't looked that closely. They're both UNIX-like systems that run on small computers. Beyond that, they start diverging pretty quickly. > This debate seems to artificially create a difference between the 2 kernels > that I don't really see existing except possibly with kernel memory allocation > and management. The differences seem to be created out of something > emotionally > reactive than concretely tangible. You'll learn this is not true as you delve more deeply into the subject. The biggest overall difference between FreeBSD (or any BSD system) and Linux is in depth. Linux is a relatively new system, and has still had relatively few design cycles under it's belt, and still contains a lot of single positive-path coding. In other words, it works fine until you stress it, but when you really push it, it just returns errors instead of degrading performance reasonably. One of the beacons of the "Freenix" movement is the ability to turn castoff machines into workable computers again, but Linux often falls over with load when you try this, in situations where FreeBSD (or NetBSD) would still perform adequately. > That's what I firmly think at this time and is subject to change as I > experience > the FreeBSD community. > > Like with any technology, that'll just take time to fix like any other problem > that has a competent group maintaining it. > > > yes, that *is* an offer. Who do I talk to?) Someone used to have a .sig > > that summed the difference between Linux and *BSD pretty nicely: "Linux is > > for people that hate Microsoft. FreeBSD is for people who love Unix." > > You probably don't know this but that attitude above isn't helpful for FreeBSD > nor the Linux folks. Contrary to the derogatory point of view that FreeBSD > have > of Linux folks, Linux folks are *not* terribly stupid and see Linux as a > valued > and legit
Re: a two-level port system?
On Tue, 1 Jun 1999, Darryl Okahata wrote: > - No need to CVS commit ar files. (BTW, CVS can also handle binary > files, so ASCII vs. binary is a non-issue.) CVS handles binary files poorly. It is an issue. - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system?
Peter Jeremy wrote: > How about storing each port as a single file in ar(5) format, which is > unpacked into the directory structure when make'd? ar(5) is a text > format, which means it can easily be managed by CVS, which includes > a tool for manipulating its contents - ar(1). This isn't all that different from the existing *.tar.gz port files. If you use those, you get all the advantages of your approach, plus fewer disadvantages: > Benefits: > - The ports tree would become ~2500 inodes and ~~32MB. > - The entire ports tree is still available on the machine. - No need to change port process to handle ar files. - No need to CVS commit ar files. (BTW, CVS can also handle binary files, so ASCII vs. binary is a non-issue.) - Smaller size than ar files. > > Disadvantages: > - Unpacked ports will use about twice as much disk space (3 times if > you include the original CVS archive). -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UID Limits
Thanks for the answers on this. This certainly makes my life simpler. That 65K limit was about to become real annoying :) -Steve > From d...@flood.ping.uio.no Tue Jun 1 10:12:21 1999 > To: Steve Ames > Cc: a...@kiwi.datasys.net, freebsd-...@freebsd.org, > freebsd-hackers@FreeBSD.ORG > Subject: Re: UID Limits > From: Dag-Erling Smorgrav > Date: 01 Jun 1999 17:12:18 +0200 > > [gack, let's get the Cc: right this time around] > > Steve Ames writes: > > The question is "What is the maximum UID?". Its either a 2 or 4 > > byte unsigned integer. The filesystem seems to accept 4, pwd_mkdb > > complains about larger than 2 but lets you do it... > > pwd_mkdb warns about UIDs greater than USHRT_MAX because some old > (third-party) software stores UIDs in unsigned short ints instead of > uid_t and therefore does not grok large UIDs. The warning is harmless > (unless you run some of that old software) and should most certainly > not be changed or removed. > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UID Limits
[gack, let's get the Cc: right this time around] Steve Ames writes: > The question is "What is the maximum UID?". Its either a 2 or 4 > byte unsigned integer. The filesystem seems to accept 4, pwd_mkdb > complains about larger than 2 but lets you do it... pwd_mkdb warns about UIDs greater than USHRT_MAX because some old (third-party) software stores UIDs in unsigned short ints instead of uid_t and therefore does not grok large UIDs. The warning is harmless (unless you run some of that old software) and should most certainly not be changed or removed. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UID Limits
Ayan George writes: > Yes, pwd_mkdb compares the UID with USHRT_MAX. I wonder if there > is a macro that defines the maximum GID and UID like: It's just a warning which was put there because some software incorrectly stores UIDs in unsigned short ints rather than uid_ts and thus does not grok large UIDs. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
On Tue, 1 Jun 1999 10:09:59 +0200 Alexander Maret wrote: > At first I tried my FreeBSD machine and I got about 800-900 collisions. > Second I booted on the same machine linux and I only got 4 (!) collisions. It's also possible that Linux isn't counting the collisions properly. > I have no problem with thousands or millions of collissions, as long as > they don't crash my computer. I just want a running system. Collisions don't cause your system to crash. If this is happening, something else is at fault (though that something else may be an unrelated problem in the Ethernet driver). -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing special device files
Zhihui Zhang wrote: > > I write a small program to read/write each FreeBSD partition via special > device file names, e.g. /dev/wd0s2e, /dev/rwd0s2e, etc. I have two > questions about doing this: > > (1) If I try to read() on these files, the buffer size must be given in > multiples of 512 (sector size). Otherwise, I will get an EINVAL error. > Why is this the case? Does the same thing happen to the write() system > call? > > (2) I use lseek() on these device files, it returns the correct offset for > me. But actually it does not work. I read in a recent posting saying that > you can't expect lseek(fd, 0, SEEK_END) to work unless the file descriptor > is associated with a regular file because file size information is not > available at that level. Does this apply to all kinds of lseek(), include > SEEK_SET and SEEK_CUR? Or maybe the offset must also given in a multiple > of 512 for some reason. If I give lseek(fd, 8193, SEEK_SET), it will > actually do lseek(fd, 8192, SEEK_SET)? They're block devices, they can only be read, written, and seeked in terms of their native block size. The block size is typically 512 bytes for disks, other types of media (like CD-ROM) may vary greatly from this. If you want to read, write, or seek to arbitrary ranges, use the "raw" devices, i.e. rwd0s2e. These are character devices that will allow you to read, write, and seek to arbitrary byte locations on the device; the kernel handles the buffering and blocking for you. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
I found the question/answer kernel configuration maddening on Linux. Linux has a tk based script (xconfig) which is pretty good... Marty Leisner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system? (fwd)
On Tue, 1 Jun 1999, Eivind Eklund wrote: > There are a number of solutions available: > (1) Change 'make release' to scan the ports collection and create an > mtree file beforehand; apply the mtree file before extracting the > collection. This will make the inode layout more efficient. I think this is a very realistic, easy thing to do. Maybe I'll work on a patch.. - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system? (fwd)
On Tue, 1 Jun 1999, Max Khon wrote: > I have very (VERY!) bad link to anoncvs.freebsd.org. are there other > anoncvs servers? Not to my knowledge, though FreeBSD.org has a few co-located machines, I'm sure one could run an anoncvs mirror. - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ECC drive data recovery?
> > Hi, > >We're seeing the following message on one of the drives we have > mounted in a server system. > > (da23:ahc1:0:14:0): READ(10). CDB: 28 0 0 46 aa 50 0 0 40 0 > (da23:ahc1:0:14:0): RECOVERED ERROR info:46aa77 asc:18,7 > (da23:ahc1:0:14:0): Recovered data with ECC - data rewritten sks:80,1a > > >I've already got a replacement coming, but I was curious to know > if anyone knows if the above means the existing data was recovered > and written to the same, or different(spare) location? > > Thanks, > John I'd hazard a guess that "data rewritten" means it was written to a spare location... but, it's just a guess. - Dave R. - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
ECC drive data recovery?
Hi, We're seeing the following message on one of the drives we have mounted in a server system. (da23:ahc1:0:14:0): READ(10). CDB: 28 0 0 46 aa 50 0 0 40 0 (da23:ahc1:0:14:0): RECOVERED ERROR info:46aa77 asc:18,7 (da23:ahc1:0:14:0): Recovered data with ECC - data rewritten sks:80,1a I've already got a replacement coming, but I was curious to know if anyone knows if the above means the existing data was recovered and written to the same, or different(spare) location? Thanks, John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
Alexander Maret writes: > Hi, > > > -Original Message- > > From: Sheldon Hearn [mailto:sheld...@uunet.co.za] > > Sent: Dienstag, 1. Juni 1999 10:45 > > To: Alexander Maret > > Cc: hack...@freebsd.org > > Subject: Re: xl driver for 3Com > > > > FreeBSD _developers_ seem to be more concerned with producing a > > rock-solid operating system than producing a popular operating system. > > That is why most of the folks working on FreeBSD are more > > interested in > > meaningful problem reports than arm-waving fanatics. > > Sure, everybody likes the easy way. > > > If there's a choice between keeping happy 100 people who don't know > > what's going on, or working with 10 people who do, most folks > > are going > > to choose to ignore the 100 for the sake of the 10. Not because they > > despise people who don't know what's going on, but because > > they can get > > good results out of people who do. > > Sure you can get better results working with 10 people who do know > what's going on but if there are possible bugs and you just ignore > the 100 people and say "they're idiots who can't post real bug reports > and who can't configure their system" you won't get a rock-stable os. > Even if 99% of the "bug reports" are configuration errors you can't > ignore the 1%. Otherwise you won't get FreeBSD rock-stable. You have > to deal with every user and ignoring people is no solution. > > Alex > > > > Well, I've been subscribed to freebsd-questions for the last couple of weeks to see how things are going in the "user community", and, I must say, I do not remember seeing your name attached to any answers to questions over there. So the points are raised: If the 1% is so important, why do you not help them out in the forum where they are most prevalent? Are you not ignoring them? Bud Dodson -- M. L. Dodsonbdod...@scms.utmb.edu 409-772-2178FAX: 409-772-1790 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system?
Thus spake Mark Newton (new...@internode.com.au): > I think most novices probably don't even know the DESCR file > exists anyway. Exactly, when I was new I used lynx and the included .html-files for each package to find out what it is. Ok. if you can remove the buildenv-stuff when the package is not that what you want, this might be ok. But you should then have a build-env-distfile dir, because I often reinstall a port after a while i've not used it, and so the distfiles often are still there. If you have no buildenv-distfile-directory, you need a connection to the internet to build it :( Alex -- ** I doubt, therefore I might be. ** *** Send email to to get PGP-Key *** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
contract programer required
Hi All, Looking for someone to do part time contract work. All type of OS FreeBSD, DOS and WIN95 A good all round programer ? http://www.apcs.com.au/work.html Thanks Keith Anderson "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD." ** The thing I like most about Windows 98 is... ** You can download FreeBSD with it! -- E-Mail: Keith Anderson Australia Power Control Systems Pty. Limited. Date: 01-Jun-99 Time: 22:28:25 Satelite Service 64K to 2Meg This message was sent by XFMail -- What's the similarity between an air conditioner and a computer? They both stop working when you open windows. -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Library dysfunction in 3.2-STABLE
> Excuse my inattention and impertinence, but I've CVSUP'ed 3.2-STABLE a > couple of times in the last couple of weeks and it appears that at every > turn another set of applications don't run in the new environment. > > At first it appeared it was just the old a.out files that weren't happy, > but > now I'm seeing link/library-rot in files that I know where built ELF in > the > last month or so. > > Plus, some off-the-shelf stuff (e.g.: dnews 4.7 *and 5.x)) is broken. > I've searched the mailing list archives and the release notes / errata for 3.2, with no success. > Have I missed something in the lists? > > ...sjs... > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script
m...@smith.net.au said: :- there are certain classes of users that it's in our interests _not_ :- to attract. So, Mike, when will you be issuing the official FreeBSD Qualification Test (FQT), and issuing a License to Use FreeBSD (LUF)? Sheesh! :-( - Robert Withrow, R.W. Withrow Associates, Swampscott MA, w...@rwwa.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: a two-level port system?
> Disadvantages: > - Unpacked ports will use about twice as much disk space (3 times if > you include the original CVS archive). > - ar(1) may need some tweaks to allow pathnames (not just filenames) > as object names (and maybe to create directories). > - Updating ports is not as easy (the port needs to be > unpacked/repacked > in the same order, with modification times and gid/uid maintained > to stop the deltas bloating). > > Comments anyone? > [ML] That is exactly the same idea I had, using a pseudoshar (a Perl script, actually) I'm working on it :) The script is a 100-liner, and the pseudoshar format is chosen so that no ownership and time information is stored in it, thus keeping deltas minimal. Furthermore, the files are included in alphabetic order, again reducing the deltas. I will be adding port_info as well, capable of browsing embedded DESC, CONTENTS, etc files. port_make will automatically extract the files and create directories and then change the directory to the port top (and thus the current dependency build changes from cd make install to port_make make install port_make will take additional make targets, and if present do the make with targets as well. Thusly, port_make install will do the whole thing. /Marino > Peter > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
> Yes, I read this remark and then decided to write to the developer > because I had such a problem. I tried to post as many information > as I could. Well it was not enough for Bill, but instead everyone > just saying: "Provide information" people should ask questions. > You will only exactly get what you want if you ask exact questions. True. But you do have to know what the problem actually is when trying to ask questions. But let's get back to solving problems. Using two machines running 2.2.6 with Bill Paul's latest drivers for 2.2.x I've been able to make the machine go strange. It looks like it can't find DNS over the XL interface anymore (long timeouts on TAB in bash). The problem showed with ping -f from each machine to the other and a tcpblast with a packet size of 32768 and 10 packets (I will send the patch for tcpblast if the problem is reproducable). I don't know whether the problem is the packet size, but all of a sudden even the ping -f went down from 100kb a second to 4kb and the tcpblast was terminated. I also do not knw which machine actually went down (whether it was the one sending or receiving from tcpblast). I'll rig up two 3.2 machines this afternoon and see if I can reproduce the problem. If anyone has better suggestions on which programs to run to reproduce the problem, let me know. tcpblast was a first guess. Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system?
Thus spake Mark Newton (new...@internode.com.au): > > DESCR file? > /usr/ports/INDEX ? Isn't the DESCR much more detailed than this INDEX file? (compare mail/mutt/pkg/DESCR and the INDEX file) Alex -- ** I doubt, therefore I might be. ** *** Send email to to get PGP-Key *** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system?
Alexander Langer wrote: > Thus spake Mark Newton (new...@internode.com.au): > > > DESCR file? > > /usr/ports/INDEX ? > > Isn't the DESCR much more detailed than this INDEX file? > (compare mail/mutt/pkg/DESCR and the INDEX file) Use INDEX to work out whether the package *might* be appropriate, and use something like "make buildenv" to grab the DESCR file (and everything else) if you think it's useful to do so. I think most novices probably don't even know the DESCR file exists anyway. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
Hi, > -Original Message- > From: Nick Hibma [mailto:nick.hi...@jrc.it] > Sent: Dienstag, 1. Juni 1999 11:58 > To: Alexander Maret > Cc: 'hack...@freebsd.org' > Subject: RE: xl driver for 3Com > > > > The discussion started with a remark about the fact that 3Com > cards have > problems under load, without a backing of that statement. That is the > thing that made people trip over. It is a statement that is not the > least helpful for anyone on the hackers mailing list and will not > trigger help from anyone, apart from responses from people being > frustrated about not being able to help (sounds silly but it is > true, their puppy is being attacked without them being able to > respond). > Yes, I read this remark and then decided to write to the developer because I had such a problem. I tried to post as many information as I could. Well it was not enough for Bill, but instead everyone just saying: "Provide information" people should ask questions. You will only exactly get what you want if you ask exact questions. Alex. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
> > FreeBSD developers do things in their spare time and they want > > people to respect that. They want to see some investment from > > the other side as well to make it worthwhile. > > And if that trade off is not what > > you want, there are companies out there that solve problems for money > > (http://www.freebsd.org). > > Well what do you want then? You're on the one hand whining that people don't > post bug reports and on the other hand you say: "Go away and ask other > people". > I didn't want configuration support but wanted to show that there is an > ERROR!!! The discussion started with a remark about the fact that 3Com cards have problems under load, without a backing of that statement. That is the thing that made people trip over. It is a statement that is not the least helpful for anyone on the hackers mailing list and will not trigger help from anyone, apart from responses from people being frustrated about not being able to help (sounds silly but it is true, their puppy is being attacked without them being able to respond). > You're wrong! I tried to participate but everybody just told me that I'm an > idiot. Well perhaps they're right but if nobody wants to hear my bug report > then I'll use another card. A card which driver has been better tested and > where gifted programmers did the bug reports. You think along the lines of least resistance for solving your problems, while developers think along the lines of highest resistance to get bugs sorted out. Added to that was quite a bit of (justifiable) frustration from Bill P. side. And I don't think people call you an idiot and if they did, they are wrong. They are however entitled to express their opinion in a for them suitable way and should be read with their background and a context, you might not be fully aware of, in mind. Do not mistake this for people being angry at you. If you are able to read emotions from an e-mail accurately, you have a very special gift. Maybe we should revert to posting patches. They are easier to read. Nick. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system?
Alexander Langer wrote: > Thus spake Mark Newton (new...@internode.com.au): > > but for most people who just want to build a handful of ports, > > browse the tree to see if there's anything cool they want, and > > then forget the ports tree 'til the next upgrade, it'll cut > > How do you want to find out if the port fits your needs without a > DESCR file? /usr/ports/INDEX ? - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
Hi, > -Original Message- > From: Nick Hibma [mailto:nick.hi...@jrc.it] > Sent: Dienstag, 1. Juni 1999 11:01 > To: Alexander Maret > Cc: FreeBSD hackers mailing list > Subject: RE: xl driver for 3Com > > This comparison with Linux is completely off. The number of > knowledgable > people working on USB for example is equivalent to the ones > in FreeBSD. What do you want to tell me with this sentence? Don't you like to be compared with linux? Well, if the same configuration runs on linux and not on a FreeBSD system then it can be a configuration error or a bug. Well if there are difference people always will compare. I compared those system to show that it can't be a hardware error because it runs with other systems. > FreeBSD developers do things in their spare time and they want other > people to respect that. They want to see some investment from > the other > side as well to make it worthwhile. > And if that trade off is not what > you want, there are companies out there that solve problems for money > (http://www.freebsd.org). Well what do you want then? You're on the one hand whining that people don't post bug reports and on the other hand you say: "Go away and ask other people". I didn't want configuration support but wanted to show that there is an ERROR!!! > Skipping to another card is short-term thinking. You assume > that without > your participation a new driver will be developed for another card, or > another operating system will provide you with services. You're wrong! I tried to participate but everybody just told me that I'm an idiot. Well perhaps they're right but if nobody wants to hear my bug report then I'll use another card. A card which driver has been better tested and where gifted programmers did the bug reports. Alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
This comparison with Linux is completely off. The number of knowledgable people working on USB for example is equivalent to the ones in FreeBSD. Most of the people talking on linux-usb are talkers not do-ers. FreeBSD developers do things in their spare time and they want other people to respect that. They want to see some investment from the other side as well to make it worthwhile. And if that trade off is not what you want, there are companies out there that solve problems for money (http://www.freebsd.org). Skipping to another card is short-term thinking. You assume that without your participation a new driver will be developed for another card, or another operating system will provide you with services. Who is 'paying' for that development then? Cheers, Nick > Well this, I think, is the wrong way. You expect people to know as > much as you. I think you can rewrite code on the fly, but > many people can't and they need help from hackers like you. > There are so many FreeBSD-Hackers who are whining that Linux has so > many users and FreeBSD hasn't. If people don't get support because > people like you are ignoring them, they won't switch to FreeBSD even > if it is much better. > > > Alex > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: question about boot code
On Tue, 1 Jun 1999, fretre wrote: > 1. I try to learn something about boot code with version 3.0. I > wander whether I can begin with biosboot?(/usr/src/sys/i386/ > boot/biosboot) The 3.0 boot code is located in /usr/src/sys/boot > 2. The initialized data will be loaded into memory after kernel > text during boot stage. And where is the file that the > initialized data is defined in? and > 3. What's the file name? If you mean the 'initialized kernel data', then it's stored in the file /kernel itself (or whatever file you boot from) in section '.data' of the ELF file. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
Hi, > -Original Message- > From: Sheldon Hearn [mailto:sheld...@uunet.co.za] > Sent: Dienstag, 1. Juni 1999 10:45 > To: Alexander Maret > Cc: hack...@freebsd.org > Subject: Re: xl driver for 3Com > > FreeBSD _developers_ seem to be more concerned with producing a > rock-solid operating system than producing a popular operating system. > That is why most of the folks working on FreeBSD are more > interested in > meaningful problem reports than arm-waving fanatics. Sure, everybody likes the easy way. > If there's a choice between keeping happy 100 people who don't know > what's going on, or working with 10 people who do, most folks > are going > to choose to ignore the 100 for the sake of the 10. Not because they > despise people who don't know what's going on, but because > they can get > good results out of people who do. Sure you can get better results working with 10 people who do know what's going on but if there are possible bugs and you just ignore the 100 people and say "they're idiots who can't post real bug reports and who can't configure their system" you won't get a rock-stable os. Even if 99% of the "bug reports" are configuration errors you can't ignore the 1%. Otherwise you won't get FreeBSD rock-stable. You have to deal with every user and ignoring people is no solution. Alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
On Tue, 01 Jun 1999 10:31:21 +0200, Alexander Maret wrote: > There are so many FreeBSD-Hackers who are whining that Linux has so > many users and FreeBSD hasn't. No there are not. There are many FreeBSD enthusiasts who are whining that Linux has so many users and FreeBSD hasn't. FreeBSD _developers_ seem to be more concerned with producing a rock-solid operating system than producing a popular operating system. That is why most of the folks working on FreeBSD are more interested in meaningful problem reports than arm-waving fanatics. If there's a choice between keeping happy 100 people who don't know what's going on, or working with 10 people who do, most folks are going to choose to ignore the 100 for the sake of the 10. Not because they despise people who don't know what's going on, but because they can get good results out of people who do. This is natural and healthy given the objective of the FreeBSD project, which has never been to take over the world. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Mmap len
I have a question concerning the maximum length allowed to be mapped by the mmap? Is it still limited to 2GB as the manual pages say or the restriction has been overcome?
RE: xl driver for 3Com
Hi, > -Original Message- > From: Greg Black [mailto:g...@acm.org] > Sent: Dienstag, 1. Juni 1999 05:21 > To: Bill Paul > Cc: hack...@freebsd.org > Subject: Re: xl driver for 3Com > > This whole argument strikes me as a good wake up call for all of > us. It really is important to make sure that problems with > software are reported and that those reports are framed in a > useful manner, because that is the only way that software gets > improved. I'm sometimes guilty of not bothering to report bugs > that I can easily work around, even though I hate it when people > who use my software do the same. I'm re-motivated now to make > the effort to contribute meaningful reports whenever I find bugs. I think you're absolutely right but consider normal users like me. I try to provider as many information as I can, but for developpers this isn't enough. Instead of saying: "Provide information!". You should ask detailed questions. > As for Dennis, he's just not worth responding to. He has a bad > reputation as a total waste of space with an attitude problem as > big as Texas. Just ignore him. Well this, I think, is the wrong way. You expect people to know as much as you. I think you can rewrite code on the fly, but many people can't and they need help from hackers like you. There are so many FreeBSD-Hackers who are whining that Linux has so many users and FreeBSD hasn't. If people don't get support because people like you are ignoring them, they won't switch to FreeBSD even if it is much better. Alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Bill Paul writes: > If you have a real, detailed and accurate bug report to submit, then fine: > let's hear it. But if you just want to make vague and unsubstantiated > complaints, do me a favor and just keep it to yourself. This whole argument strikes me as a good wake up call for all of us. It really is important to make sure that problems with software are reported and that those reports are framed in a useful manner, because that is the only way that software gets improved. I'm sometimes guilty of not bothering to report bugs that I can easily work around, even though I hate it when people who use my software do the same. I'm re-motivated now to make the effort to contribute meaningful reports whenever I find bugs. As an aside, my experience with the xl driver (ever since I added it in to 2.2.7) has been completely positive, so I can't help with fixing any possible problems there. As for Dennis, he's just not worth responding to. He has a bad reputation as a total waste of space with an attitude problem as big as Texas. Just ignore him. -- Greg Black -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
Hi, > Collisions on half-duplex Ethernet are *normal*. Get used to it. > > Collisions is the standard flow control mechanism for > half-duplex Ethernet. > The amount of collisions you get depend on the cards used, > the amount of > traffic, and several other things. The amount of collisions > is also not > very interesting - the amount of *traffic* is. Well as i described in a previous mail to Bill Paul, i tried to transfer two times 30MB of data via samba: At first I tried my FreeBSD machine and I got about 800-900 collisions. Second I booted on the same machine linux and I only got 4 (!) collisions. Bill Paul said to me that the FreeBSD TCP/IP is probably much faster. Well I'm sure that he is right, but from my point of view it didn't take longer to tranfer the files with linux. Anyway, i promised Bill Paul to measure exact values. Then we will see. I have no problem with thousands or millions of collissions, as long as they don't crash my computer. I just want a running system. And as my NT machine didn't crash on transfering a huge amount of data from a linux-server I have to think that this is a bug in something FreeBSD related. The only difference I could see between the two configurations were the collissions and as somebody on the list said there were problems with the xl driver under high load i wrote a letter to Bill Paul. I think I will simply switch to another card. Someone on the list said that their customer didn't have any problems after switching to intel cards. I don't want to switch back to linux again, because FreeBSD is much smoother. > If you connect two hosts to a hub and run ttcp, to push a lot > of traffic > between them, you're very likely to get a 50% collision rate > - with only > two hosts. This is because *every* ack collides with a normal > full sized > packet. This is also perfectly fine and healthy. > > What you want to watch out for, is: > > - Late collisions (these are *not* normal) > - Collisions when you think that the link is in full duplex mode. I will do further investigation to get more detailed infos. Unfotunately I'm very busy at the moment but I'll post more information as soon i get some results. Alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: xl driver for 3Com
> I don't think that so many collisions are normal! I think there is a > problem, because at work we nearly only use 3COM 100 Mbit cards and > don't have much collisions. Even under high load! Collisions on half-duplex Ethernet are *normal*. Get used to it. Collisions is the standard flow control mechanism for half-duplex Ethernet. The amount of collisions you get depend on the cards used, the amount of traffic, and several other things. The amount of collisions is also not very interesting - the amount of *traffic* is. If you connect two hosts to a hub and run ttcp, to push a lot of traffic between them, you're very likely to get a 50% collision rate - with only two hosts. This is because *every* ack collides with a normal full sized packet. This is also perfectly fine and healthy. What you want to watch out for, is: - Late collisions (these are *not* normal) - Collisions when you think that the link is in full duplex mode. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using newbus to hang a custom bus off a device
On Mon, 31 May 1999, Bill Paul wrote:
> Well, after a bit of head scratching, I finally think I've gotten the
> hang of the new bus architecture stuff (in general that is, not just
> the new ISA and PCI stuff). I'm trying to create an miibus framework so
> that I can have an miibus attached to those PCI ethernet drivers which
> support MII-based transceivers, to which I can attach transceiver
> drivers. I'm still a little confused by something though, probably
> because I'm trying to do the development on 3.2-RELEASE (I don't have
> a machine that I can clobber with -current just at the moment).
>
> Basically what I have is this:
>
> - An miibus_if.m file which describes the methods implemented by miibus
> drivers. There are three methodes: a readreg method, which lets you
> read a given register from a given PHY on the MII bus, a writereg
> method, which lets you write a value to a given register on a given
> PHY on the MII bus, and a status change method, which lets you tell
> the driver which implements the miibus support that the status of a
> PHY has changed and that the controller needs to update some state to
> match it. (This is mainly to deal with controllers that have speed
> and duplex settings that operate independently of the PHY: if the
> PHY negotiates 100Mbps full duplex, then the controller chip to which
> the PHY is attached may also need to be explicitly programmed for
> 100Mbps full duplex to match the PHY.)
>
> - A stub mii PHY driver, which has its own probe and attach functions,
> and which uses the following DRIVER_MODULE() macro:
>
> DRIVER_MODULE(miigeneric, miibus, mii_driver, mii_devclass, 0, 0);
>
> - Some stub code to be inserted into a NIC driver which implements
> the miibus support. The code provides a probe routine (which checks
> for MII support on the controller) but uses bus_generic_attach for
> its attach routine. This, I believe, allows all of the mii driver
> probes to be invoked after the bus is attached. The NIC driver also
> uses a DRIVER_MODULE() macro like this:
>
> DRIVER_MODULE(miibus, ax, miibus_driver, miibus_devclass, 0, 0);
>
> (Here, "ax" represents the if_ax driver, which is what I used for
> testing since the ASIX chipset uses an MII-based transeiver.)
Sounds good so far.
>
> So, here's how I understand this: the MII driver is declared to be
> in the 'miibus' devclass. And the if_ax driver declares an miibus device
> which is attached to the ax devclass. Since this is 3.2-RELEASE,
> I manually attach the ax device to the root_bus devclass using
> device_add_child(). Then I do the following:
>
> miibus = device_add_child(sc->ax_device, "miibus", -1, NULL);
> if (device_probe_and_attach(miibus)) {
> device_delete_child(sc->ax_device, miibus);
> return(ENODEV);
> }
>
> Now, this is where I had to do some looking around: the fact that you
> need to use device_add_child() is not clearly spelled out in the man
> pages. Basically, the fact that the DRIVER_MODULE() modules declare
> the driver hierarchy does not mean than device instances are actually
> created. The DRIVER_MODULE() macros basically tell the system to expect
> that an miibus could be created as a child of an ax device instance, and
> that an miigeneric device could be created as a child of an miibus instance,
> but you actually need to use device_add_child() to call the device
> instance into existence.
Thats right. I needed to make a clear distinction between the device
instance and the driver since there can be many (or no) devices using a
single driver (e.g. sio[0-3]). It is normally the responsibility of a
parent device to decide if it has children and add them using
device_add_child() if appropriate.
For -current, I have added a mechanism so that drivers can be asked to
search for and add devices. I use this mechanism to populate the isa bus
through the isahint (and soon the pnp) driver.
If a parent device is using this mechanism to add its children, it must
call bus_generic_probe() from its probe method which will call the
DEVICE_IDENTIFY method (a static method, i.e. not specific to a device
instance) of each driver in the class. These drivers may call
BUS_ADD_CHILD to add devices to the parent device if any are found. The
parent device must implement BUS_ADD_CHILD, mainly to allow it to allocate
and initialise the ivars for the new device. I guess I could provide a
bus_generic_add_child() which used a NULL ivars.
>
> Similarly, in the miibus probe routine, you have to check for PHYs
> on the miibus and call device_add_child() to create a device node
> for each PHY on the bus. (I use device_add_child(dev, NULL, -1, NULL)
> for this, because you don't know ahead of time exactly which driver
> will be attached.) Then, bus_generic_attach() will call the probe
> routines of all the PHY drivers that are declared to be in the miibus
> devclass, and whichever driver supports the
Re: Problems with ALI chipset
It seems Andrij Korud wrote: >Hi, can you help me with problem with Aladdin V chipset and UDMA. >Here is my dmesg when UDMA in bios is off: >[snip snap] >wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa >wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 >wd0: 4892MB (10018890 sectors), 10602 cyls, 15 heads, 63 S/T, 512 B/S > >and all is working fine. When I turn on UDMA, i got messages >saying something like "irq timeout (DMA active)", sometimes it tell >"probable a portable system" and even "Last time I say: irq timeout" >And system does not working. Hmm, you could try the new "ata" driver instead that does work in UDMA mode on the ALI chipset. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
