Re: MFC'ing new md(4) functionality?
On Tue, Jun 05, 2001 at 07:43:38PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], David O'Brien writes: On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote: Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. Can you expand on this? I assume you know we are not talking about disabling vn(4). We already have a previous form of md(4) in stable, -current's md(4) is not compatible with that older version. And that older version doesn't even work (at least when loaded as the module): # kldload md # disklabel -r -w md0 auto ^C^C^C^C^C^C^C^C^C Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
In message [EMAIL PROTECTED], Ruslan Ermilov writes: On Tue, Jun 05, 2001 at 07:43:38PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], David O'Brien writes: On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote: Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. Can you expand on this? I assume you know we are not talking about disabling vn(4). We already have a previous form of md(4) in stable, -current's md(4) is not compatible with that older version. And that older version doesn't even work (at least when loaded as the module): While true, it is not really relevant to the issue of API/ABI breakage in -stable... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
vm_object question/verification
I'm confused (and probably wrong), but does the 'shadow_head' field of the vm_object structure really refer to a list of objects that the object shadows (as mentioned in the comment)? Looking at the vm_object_shadow() function (vm/vm_object.c, line 894 in 4.3), it looks like it's the other way around; ie. shadow_head refers to a list of objects which shadow the object. Thank you to anyone who could verify this for me. -Marvin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to disable software TCP checksumming?
Louis A. Mamakos wrote: It seems to me to be kind of moot to check the same value twice, unless you suspect hardware problems. Aren't you talking about two different checks over the same data instead of checksum off-loading? Suspect hardware problem? Of course you should! That's why memory systems have parity or ECC, and I/O buses are similarlly protected. At least on real computers. The link-level CRC only protects the data as it goes over the link ^^ After reading the rest of his messages, I'm not so sure, but I would think he was talking about _transport_ level check sum, and verifying that with hardward (NIC) instead of software (IP stack). between the link-level hardware which generates the CRC and the box on the other end that receives it. It does not protect the data end-to-end, so if it's gets corrupted whilst sitting in memory in an intermediate node, you won't detect that. Why would it get corrupted? 1. Software. Random unrelated other software does a random store in the buffer containing your packet sitting in memory. Fancy device drivers that do scatter-gather I/O gets it wrong every now and then and points off into space. mbuf cluster which should be treated as read-only isn't, and some other code hoses it. (See PR kern/27782 at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27782 for an example of this.) 2. Hardware. I found broken UNIBUS hardware 15 or 20 years ago this way. I had some broken hardware which took frame relay frames on a HSSI interface and turned them into AAL5 ATM cells that would get the cell reassembly wrong if you pushed too hard. Or just plain broken memory that results in packet corruption. I've personally experienced all these problems. Maybe I'm just unluckly. One common thread of my experiences is being close to the bleeding edge of technology where stuff isn't as mature as many people are used to. This end-to-end issue is not a theoretical consideration. While the 1's complement internet checksum isn't that strong, it does detect a bunch of bug-like behavior like this. Louis Mamakos -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] wow regex humor... I'm a geek To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: newbussifying drivers
| You manually set the correct I/O port in the hints file and then you Sorry if i misunderstand, but isn't the hints file only for -current? I was under the impression it was only to simplify driver development. Since my goal is to clean up the driver under the newbus system, how would this port address issue be handled under -stable? Hints aren't appropriate in this situation; please see the lengthy response I posted to your code question. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
no more 'root' account on my machine...
Hi, First of all, sorry for my bad english skills. As the newbie I am on FreeBSD (4.3), I did a very stupid thing while using vipw : I deleted the root account. I tryed to correct my problem using the fix it floppy, but changing the /etc/passwd file is not enough. Really I am sorry to bother you with that, but I don't know that much about the master.passwd and the way FreeBSD does to authentify users. Anybody has an idea about the way I shall follow to resolve my problem? Thank you indeed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IEEE P1394
Mike Smith wrote: At this point in time, if you're not up to coding on this project, there's not much to be done, I'm afraid. It needs a lot of development work before it'll be ready for anything resembling testing. Regards, Mike Thanks, Mike. It's a matter of knowing my limitations, including time to apply to learning. -- Don Wilde http://www.Silver-Lynx.com Silver Lynx Embedded Microsystems Architects 2218 Southern Bl. Ste. 12 Rio Rancho, NM 87124 505-891-4175 FAX 891-4185 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: no more 'root' account on my machine...
Hello there! First, did you edit /etc/passwd or /etc/master.passwd ? passwd does not hold any passwords and serves only for resolving name/uid/fullname references, while master.passwd holds actual passwords. Second, did you run pwd_mkdb(8) after editing that file? This should be enough IMHO. Regards, Alexey. -+-- Does the fish swallow the stone? | Regards, Alexey V. Neyman Perhaps, but that is not the point. |mailto: [EMAIL PROTECTED] -(Pkunk, SC2)+-- On Wed, 6 Jun 2001, Franck LEVESQUE wrote: Hi, First of all, sorry for my bad english skills. As the newbie I am on FreeBSD (4.3), I did a very stupid thing while using vipw : I deleted the root account. I tryed to correct my problem using the fix it floppy, but changing the /etc/passwd file is not enough. Really I am sorry to bother you with that, but I don't know that much about the master.passwd and the way FreeBSD does to authentify users. Anybody has an idea about the way I shall follow to resolve my problem? Thank you indeed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Sat, Jun 02, 2001 at 02:03:38AM -0400, Garance A Drosihn wrote: It also strikes me that this might be another topic to send thru [EMAIL PROTECTED], as Posix might have something to say about what's appropriate. How much traffic does this list produce and how many people are on it? The first I heard of it's existance was a few days ago on one of the lists. May I propose that we make this an offical list so that it can be utilised by the wider community? Joe PGP signature
Re: How to disable software TCP checksumming?
Louis A. Mamakos wrote: It seems to me to be kind of moot to check the same value twice, unless you suspect hardware problems. Aren't you talking about two different checks over the same data instead of checksum off-loading? Suspect hardware problem? Of course you should! That's why memory systems have parity or ECC, and I/O buses are similarlly protected. At least on real computers. The link-level CRC only protects the data as it goes over the link ^^ After reading the rest of his messages, I'm not so sure, but I would think he was talking about _transport_ level check sum, and verifying that with hardward (NIC) instead of software (IP stack). If I'm not mistaken the message that started this thread inquired about adding an option to prevent TCP from doing a checksum, since the fancy gigabit hardware performed reliable link-level error detection itself. I argue that since TCP is an end-to-end transport protocol that individual error detection on a per-hop basis is not sufficient either theoretically or practically. My last message illustrated a number of cases where the transport of the packet over a link was reliably done, but the contents of the packet were corrupted by malfunctioning software or hardware which the end-to-end TCP checksum detected. I have less of an issue with the endpoints of the TCP connection offloading checksum computation to the NIC card, though you're still exposed to a certain class of error, like the PR I referenced. The problem is what happend to your data in intermediate network elements (routers, etc.) between the endpoints of the TCP connection. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Tue, Jun 05, 2001 at 07:04:47PM +0100, Josef Karthauser wrote: On Sat, Jun 02, 2001 at 02:03:38AM -0400, Garance A Drosihn wrote: It also strikes me that this might be another topic to send thru [EMAIL PROTECTED], as Posix might have something to say about what's appropriate. How much traffic does this list produce and how many people are on it? The first I heard of it's existance was a few days ago on one of the lists. Not too much, wish it'd be higher. May I propose that we make this an offical list so that it can be utilised by the wider community? Bug wollman. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: no more 'root' account on my machine...
Thank you very much for your help. I could finally create my root account with your guide lines :) I booted into single user mode, added a correct entry into the /etc/master.passwd file, and used pwd_mkdb -p /etc/master.passwd before changing the root password. Sorry again for my newbie question. Now I know a little bit more about the way FreeBSD manages its accounts :) Have a very good day ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
On-Line Kernel Debugging Using Remote GDB
Hi: I am trying to debug a kernel using the steps specified in the Handbook. I follow the steps to compile the kernel, reboot with -d option, and in the other machine, I run gdb -k kernel and so... I have both machines joined with a serial null-modem cable, but when I try: (kgdb) target remote /dev/cuaa0 Remote debugging using /dev/cuaa0 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote target Malformed response to offset query, timeout (kgdb) I am newbie with this topics, I don know where is the problem. How can I test the communication? Do I have to change some specs of device /dev/cuaa0 to communicate with the target box ? Any suggestion will be very appreciated. -- * Juan F. Rodriguez Hervella Universidad Carlos III de Madrid To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: On-Line Kernel Debugging Using Remote GDB
I'm not sure if you're already doing this but, on the machine being debugged, you must switch to gdb mode by typing 'gdb' at the DDB prompt. Then, after running gdb -k on your debugging box, go back to the machine being debugged and type 's'. If you're already doing this, then it looks like you've got a communication problem. Let me know and I'll send you more information about my setup. -Marvin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
In message 70325.991758797@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], David O'Brien writes: : On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: : Is there any reason not to MFC the new md(4) functionality : : Zero reason not to. : : Others see it differently, it would seriously break a lot of : people who are using -stable in embedded applications. : : If we have abandoned the no changes to API or ABI in -stable : paradigm, it would be a good idea, but it serious rains on that : rule... I've stated in the past that removing mfs from stable is going to cause me some grief. However, the addition of md won't so long as mfs remains intact. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: newbussifying drivers
In message [EMAIL PROTECTED] j mckitrick writes: : The newbus routines use a certain amount of overhead, but once done, you : forget about it. In some device drivers, the probe methods often need to : try a variety of hardware ports. In the past, inb/outb was used, along with : an often hardcoded port address. : : Does it make sense to call bus_allocate_resource for every hardware port we : probe? What is the best way to handle this so NO inb/out is used, even for : probing? Most of the drivers in the past that have done the soul searching for hardware have been convereted to not do the soul searching but instead rely strictly on the hints. I think that's what we need to do for the parallel drivers as well. If it must do the soul searching, and I see no reason why it should be special as it causes other problems for wiring when you have multiple parallel ports, then you should likely bus_alloc_resource for every hardware address. This gives you a modest probability that those addresses are not used by another device and you won't hork hardware that otherwise resides there. Warenr To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: newbussifying drivers
In message [EMAIL PROTECTED] j mckitrick writes: : How would you recommending fixing this, taken from the ex driver? By deleting it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: newbussifying drivers
In message [EMAIL PROTECTED] j mckitrick writes: : | You manually set the correct I/O port in the hints file and then you : : Sorry if i misunderstand, but isn't the hints file only for -current? I was : under the impression it was only to simplify driver development. Hints will be in -stable by the end of this week unless the world explodes at work. In which case they will be in by the end of next week. They are optional in stable. Also, in stable now the hints are codified in the config file for those attributes that we're talking about in this conversation. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: newbussifying drivers
In message [EMAIL PROTECTED] Warner Losh writes: : In message [EMAIL PROTECTED] j mckitrick writes: : : How would you recommending fixing this, taken from the ex driver? : : By deleting it. Let me expand a little. The reason I advocate deleting it is because there are too many old hunks of random hardware that interact badly with this probe. I've often had to delete the ex driver so that they start working due to this probe. I'd keep the meat of the routine but require -current users to specify an address for cards that aren't in plug and play mode. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
need help: gdb -k 4.16/7
Hi- Please cc: me on any answer as I am not subscribed! Thx! Also, if this is the wrong list please redirect me! Thx! I am experimenting with porting an application from the FreeBSD 2.2.x series to a more modern release, and as such I have occaision to debug kernel core files under the old release using the gdb -k option (saved via savecore). The problem is the old kernel has been customized with a different load address (new style 0xC000 vs. old style 0xF000). This change involves updating the include file environment. I have made those changes coherent between the kernel build tree and /usr/include, then rebuilt gdb. The problem is the resulting gdb -k sessions are not fully functional. I would like to know if anyone knows anything about this can help me with some clues. Specifically, the kernel stack frames are fine, sources are fine, data/bss access is fine, but attempts to access kernel malloc'ed memory fail. The debugger reports that the address is not accessible. The implementation of gdb -k in 4.16 uses a file kvm-fbsd.c which mimics a real kvm access by reading from the core file instead. My understanding is the core file is a physical image of memory, so this kvm emulation has some knowledge of the virtual memory system. I am worried that there are some hidden dependencies on the original memory layout that were not handled when the KERNBASE move was reflected in the include files. After debugging this for some time, in desperation I attempted to port 4.17 and 4.18 back into the old FreeBSD environment, hoping to find a bug fix. What I got instead was a build failure in 4.17: gdb 4.17 build log excerpt Graph cycles through config.h `all' not remade because of errors. make all-recursive Making all in doc rm -f gdb gcc -g -O2 -o gdb init.o version.o blockframe.o breakpoint.o findvar.o stack.o thread.o source.o values.o eval.o valops.o valarith.o valprint.o printcmd.o symtab.o symfile.o symmisc.o infcmd.o infrun.o command.o expprint.o environ.o gdbtypes.o copying.o i386-tdep.o i387-tdep.o solib.o ser-tcp.o ser-unix.o fork-child.o infptrace.o inftarg.o corelow.o core-aout.o i386b-nat.o remote.o dcache.o remote-utils.o tracepoint.o mem-break.o target.o parse.o language.o c-exp.tab.o jv-exp.tab.o f-exp.tab.o m2-exp.tab.o buildsym.o exec.o bcache.o objfiles.o minsyms.o maint.o demangle.o dbxread.o coffread.o elfread.o dwarfread.o dwarf2read.o mipsread.o stabsread.o corefile.o c-lang.o ch-exp.o ch-lang.o f-lang.o jv-lang.o jv-valprint.o jv-typeprint.o m2-lang.o scm-exp.o scm-lang.o scm-valprint.o complaints.o typeprint.o c-typeprint.o ch-typeprint.o f-typeprint.o m2-typeprint.o c-valprint.o cp-valprint.o ch-valprint.o f-valprint.o m2-valprint.o nlmread.o serial.o mdebugread.o os9kread.o top.o utils.o annotate.o main.o inflow.o gnu-regex.o ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ../libiberty/libiberty.a -ltermcap-lm../libiberty/libiberty.a gcc: ../libiberty/libiberty.a: No such file or directory gcc: ../libiberty/libiberty.a: No such file or directory *** Error code 1 Stop. end gdb 4.17 build log excerpt The 4.18 baseline built fine, but gdb -k is no longer supported! Interestingly, the 4.16 distribution archived at ftp://www.gnu.org does not exactly match the version in the FreeBSD 2.2.x release, and doesn't build cleanly either. The build error from 4.16 is here: gdb 4.16 build log excerpt if [ -n ]; then gcc -O2 -c -DTRAD_CORE -I. -I. -I./../include -g trad-core.c -o pic/trad-core.o; else true; fi gcc -O2 -c -DTRAD_CORE -I. -I. -I./../include -g trad-core.c trad-core.c: In function `trad_unix_core_file_p': trad-core.c:108: `NBPG' undeclared (first use this function) trad-core.c:108: (Each undeclared identifier is reported only once trad-core.c:108: for each function it appears in.) *** Error code 1 Stop. end gdb 4.16 build log excerpt Anyone who has any clues as to how to overcome any of these problems, and properly access the old kernel core files using any of the 4.16, 4.17, or 4.18 baselines, please email. Thanks, -Dorr H. Clark School of Engineering Santa Clara University To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Softupdates not syncing
On one of our servers, deleted space is not being freed and causing is to run out of disk space. To test this, I copied a 200 meg file to the /usr partition and then deleted it. I checked df before copying, after copying, and after deleting it. After deleting it, the space never became available. I waited atleast 24 hours just to make sure. 4.2-STABLE FreeBSD 4.2-STABLE #0: Mon Jan 29 10:18:20 PST 2001 I checked the disk space just a minute ago: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a125983384057750033%/ /dev/da0s1e 8229668 74897638153299%/usr procfs 440 100%/proc Notice how /usr is almost full. There should actually be quite a bit of space available. I mounted /usr2 and then when I umount'd /usr2, the missing space on /usr magically came back. Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a125983384057750033%/ /dev/da0s1e 8229668 6702791 86850489%/usr procfs 440 100%/proc That is almost 800Mb that was locked up. Am I doing something wrong? or is this a bug? I didn't see anything in a quick search of the mailing lists. CC me I'm not on the list. Chris Coleman Editor in Chief Daemon News E-Zine http://www.daemonnews.org Print Magazine http://magazine.daemonnews.org Open Packages http://www.openpackages.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Making support for ADSL interface ??
Hi Everybody, I would like to inquire about what it would take to make a driver for a specific ADSL board with direct PCI interface to FreeBSD First, lets assume that I will supply boards, and that all necessery documentation will be available. How good is FreeBSD current structures for running ADSL, I'm thinking about the ATM support already present, and probably using netgraph ? I would need support for the most common protocols used worldwide, t.ex PPPoATM, IPoATM Next, is there any takers for doing the actual work ? I would probably need somebody who has some knowledge about ADSL and ATM, and have access to some equipment and/or lines for testing. I will probably be able to offer some limited payment for the work, the driver will probably be possible to release under BSD license, and the resulting hardware will be available at low cost. Regards, Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making support for ADSL interface ??
How good is FreeBSD current structures for running ADSL, I'm thinking about the ATM support already present, and probably using netgraph ? I would need support for the most common protocols used worldwide, t.ex PPPoATM, IPoATM You'd also need to support PPPoE, which on most ADSL systems appears as PPP on Ethernet as RFC-1490 bridged encapsulation of the ethernet frames in AAL5 ATM cells. It's unclear that this is worth doing at the ATM level since the CPE devices with an Ethernet are fairly inexpensive; the existing Ethernet interface might be the most cost effective. There's also limited standardization on management interfaces for ADSL CPE equipment. It's been a couple of years since I've been involved with the ADSL forum, but there were proposes to have some management channel to the CPE device (perhaps using ILMI? I don't recall). Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making support for ADSL interface ??
Louis, Thanks for your reply. Louis A. Mamakos wrote: You'd also need to support PPPoE, which on most ADSL systems appears as PPP on Ethernet as RFC-1490 bridged encapsulation of the ethernet frames in AAL5 ATM cells. It's unclear that this is worth doing at the ATM level since the CPE devices with an Ethernet are fairly inexpensive; the existing Ethernet interface might be the most cost effective. I will need to support PPPoE, but netgraph can probably take care of that But directly, as the point is to have one single low cost box with everything, that why I'm working on doing an ADSL board with PCI interface And I might even put the ADSL interface on the mainboard. There's also limited standardization on management interfaces for ADSL CPE equipment. It's been a couple of years since I've been involved with the ADSL forum, but there were proposes to have some management channel to the CPE device (perhaps using ILMI? I don't recall). The configuration and management have moved forward, take a look at the DSL Forum TR-037 Regards, Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
make installworld hacking
I have a problem, I installed a bunch of machines with a very stripped down set of distributions (bin, man, dict, krb5). I'd like to update the machines, but when I do an installworld, it's going to install a bunch more than that. Is there some way of only upgrading only the bin distribution (a la make distribute)? If not, would people be interested in me attempting such a feat? -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making support for ADSL interface ??
Louis, Thanks for your reply. Louis A. Mamakos wrote: You'd also need to support PPPoE, which on most ADSL systems appears as PPP on Ethernet as RFC-1490 bridged encapsulation of the ethernet frames in AAL5 ATM cells. It's unclear that this is worth doing at the ATM level since the CPE devices with an Ethernet are fairly inexpensive; the existing Ethernet interface might be the most cost effective. I will need to support PPPoE, but netgraph can probably take care of that But directly, as the point is to have one single low cost box with everything, that why I'm working on doing an ADSL board with PCI interface And I might even put the ADSL interface on the mainboard. What I'm not sure is if the netgraph code currently has hooks into the ATM network interfaces, and if it knows about ethernet frame bridge encapsulation. I'm guessing that the netgraph platform would make the most sense to support this kind of application. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
cloning network interfaces
I'm working on a project that will be using a whole lot of gif(4) devices. Since I'd written an almost-clone patch for snp and gif's current lack of cloning annoyed me, I figured I'd take a look at writing a patch for it. Unfortunately, it appears to be rather more complicated then I had hoped. With network devices that are also normal devices the way tun is, you do this by just implementing a dev_clone event handler so when the user attempts to open a non-existent instance it's created. The problem with gif is that there's no device in /dev to open. Since most network devices at attached to hardware this usually doesn't matter, but in this case it does. In Solaris the ip.tunX devices have the same problem, but they have a solution of sorts. With them you simply call ifconfig ip.tun0 plumb to create ip.tun0. Is this the sort of solution we'd like to use in FreeBSD? Do we instead want to make the network interface name space work like the devfs name space so ifconfig gifnew blah works? How would this work anyway? Comments, thoughts, ideas? -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: How to disable software TCP checksumming?
As the originator of this thread (sorry), I thought I'd clear up some of the speculation as to what I'm trying to do. :-) Our adapter card is a GSN adapter, focused on the ST protocol over a hippi-6400 link. We support IP on this adapter as well but that's not its expected primary use. In asking the original question, I was trying to find out how to disable the IP/TCP software checksums and rely on the link layer LCRC and ECRC (I think that's what they're called) checks. The LCRC is a hop to hop CRC that is applied to each 32 byte micropacket that is transmitted. The ECRC is an overll message CRC that covers all micropackets of the message. It is my expectation that these two CRCs will be adaquate to catch any errors that occur within the GSN network. Note that our card has no IP specific checksum support (it does for ST) so for packets originating from, or destined to, outside of the GSN network we _must_ do the software checksuming. I understand this. My purpose in being able to turn software checksums off was strictly to measure the performance advantage of doing so. In any real network environment the software checksums are required with this card. Thanks, Bob On Wed, Jun 06, 2001 at 05:15:40PM -0300, Daniel C. Sobral wrote: Louis A. Mamakos wrote: If I'm not mistaken the message that started this thread inquired about adding an option to prevent TCP from doing a checksum, since the fancy gigabit hardware performed reliable link-level error detection I do not recall he ever mentioning link-level. Either my mind removed it, or yours inserted it. :-) itself. I argue that since TCP is an end-to-end transport protocol that individual error detection on a per-hop basis is not sufficient either theoretically or practically. My last message illustrated a number of cases where the transport of the packet over a link was reliably done, but the contents of the packet were corrupted by malfunctioning software or hardware which the end-to-end TCP checksum detected. I have less of an issue with the endpoints of the TCP connection offloading checksum computation to the NIC card, though you're still exposed to a certain class of error, like the PR I referenced. The problem is what happend to your data in intermediate network elements (routers, etc.) between the endpoints of the TCP connection. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ... if the church put in half the time on covetousness that it does on lust, this would be a better world. -- Garrison Keillor, Lake Wobegon Days -- Bob Willcox All men profess honesty as long as they can. [EMAIL PROTECTED]To believe all men honest would be folly. Austin, TX To believe none so is something worse. -- John Quincy Adams To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making support for ADSL interface ??
On Wed, 6 Jun 2001, Soren Kristensen wrote: If you will give all neccessary documentation and microcode (for chipsets), then it is definitely interesting. I have unsuccessfully discussed writing drivers for ADSL cards with several vendors (alcatel, adi, efficient) but no one have not had courage to give out real information. Even released linux drivers are mostly fakes - some kernel modules providing ioctl interface for binary only userland parts. When driver for hardware is available, I believe, that then freebsd community has enough people to develop surrounding infrastructure further. I would like to inquire about what it would take to make a driver for a specific ADSL board with direct PCI interface to FreeBSD First, lets assume that I will supply boards, and that all necessery documentation will be available. How good is FreeBSD current structures for running ADSL, I'm thinking about the ATM support already present, and probably using netgraph ? I would need support for the most common protocols used worldwide, t.ex PPPoATM, IPoATM Next, is there any takers for doing the actual work ? I would probably need somebody who has some knowledge about ADSL and ATM, and have access to some equipment and/or lines for testing. best regards, taavi PS. If only someone would provide microcode and little bit additional information for compleating driver for efficient 3060/3061 pci cards (http://home.uninet.ee/~taavi/lanai/) :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
4.3-RELEASE/src/usr.sbin/pkg_install/sign/ needs src/crypto not on CD
4.3-RELEASE/src/usr.sbin/pkg_install/sign/ from cdrom needs to include: openssl/err.h openssl/evp.h openssl/objects.h openssl/pem.h openssl/rsa.h openssl/sha.h openssl/ssl.h openssl/x509.h They are not on cdrom src/, But are in src/ from CVS. src/crypto/heimdal/lib/roken/err.h src/crypto/kerberosIV/lib/roken/err.h src/crypto/openssh/rsa.h src/crypto/openssl/crypto/err/err.h src/crypto/openssl/crypto/evp/evp.h src/crypto/openssl/crypto/objects/objects.h src/crypto/openssl/crypto/pem/pem.h src/crypto/openssl/crypto/rsa/rsa.h src/crypto/openssl/crypto/sha/sha.h src/crypto/openssl/crypto/x509/x509.h src/crypto/openssl/ssl/ssl.h src/include/err.h src/lib/libmd/sha.h src/sys/i386/isa/ic/rsa.h It compiles OK after: (cd /src.cvsup ; tar cf - crypto kerberos5 kerberosIV secure ) | tar xf - Whoever builds BSDI CDs these days (jkh ? cc'd) may want to check the `munitions stripped' CD src/ versions can compile on binary systems that also have only a `munition stripped' /usr/include/ ? Hopefully soon all this stripping for USA Munitions Patents etc may be history. An analysis of the content of src/ for 3 versions: CD From the ISO image of the cdrom on ftp.freebsd.org CTM As extracted from a cvs tree built from cvs-cur.7200xEmpty.gz + deltas to cvs-cur 7323 CVSUP As extracted from a cvs tree built from a cvsup tree For both CTM CVSUP, the subsequent cvs commands were: cvs -R export -r RELENG_4_3_0_RELEASE src Result: src/ COMPONENT CD CTM CVSUP COMMENT CVS/1 0 0 5K Entries Repository Root Tag crypto/ 0 0 1 27 Meg kerberos5/ 0 1 1 120 K kerberosIV/ 0 1 1 125 K secure/ 0 0 1 274 K sys/crypto/ 1 0 1 236 K 0 = Missing, 1 = In src/ PS Chuck R. is looking at things missing from CTM CVS version of src/, so need to alert him. - Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/ Ihr Rauchen = mein allergischer Kopfschmerz ! Kau/Schnupftabak probieren ! Like Linux ?Then also look at FreeBSD with its 5000+ packages ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Resource reservation idea
I appear to have missed some of this thread. Dang. :- Some dummy driver which grabs the resource. The dummy driver would : need to be unloaded when the actual driver needs the resources. : : This sounds attractive, but it's hard to find the dummy driver when : you want to open the bidding for one or more devices again. You also end : up with the ugly case where the device has more resources than the driver : uses; you end up needing a placeholder of some sort for these as well, so : you might as well just built it into the way the bus thinks about child : devices and be done with it. : : It was suggested some time ago to do this by having a priority value : that indicates a dummy, say -1. When a driver is loaded, all dummies : are detached and the probe is restarted. The dummies are quiet if not : cold booting to avoi a storm of dummies announcing themselves again and : again. There are some subtle problems with this approach. Specifically, if I have a card in a bus that can live at any address. I load a driver for this card, so the bus reprobes. If all I have to go by is these drivers that have reserved resources, then if we detach them all before doing this, we could have a situation where order matters and the device could get one of the other device's resources. Nick's point is that you only kick off the dummies. In reality, all this is bickering about is, what is the container object for resources? The approach that requires a dummy driver asserts that the container object is the driver instance. This is a much, much harder approach than asserting that the container object is the device instance. In practise, if you want a driver instance holding the resources, you have to do this: - create a device for every child on the bus. - attach drivers to as many children as possible. Force them to allocate *all* their resources, not just the ones they want (this is difficult). - attach a dummy driver to the rest of the children, and force it to allocate all the resources the child has. The second step is actually more common (and more irritating) than you think. It almost forces you to take the other approach anyway: - create a device for every child on the bus. - allocate all the child's resources and attach them to the device's ivars (using eg. a resource list). - attach drivers to children. When a child asks for a resource, just hand them the resource you've already allocated. I've coded this second approach, and it works well. Note that all of this is really only relevent to busses like PCI where the existence of a resource forcibly implies that it's enabled (with some special cases). With something like pccard where you can move the mapping windows around in the bridge, it's less of an issue. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: need help: gdb -k 4.16/7
On Wed, Jun 06, 2001 at 10:32:39AM -0700, Dorr H. Clark wrote: Interestingly, the 4.16 distribution archived at ftp://www.gnu.org does not exactly match the version in the FreeBSD 2.2.x release, and doesn't build cleanly either. Not sure why you find this so surprising. Install the 2.2.x sources and you will have the gdb sources that built the original gdb. If you want to update that to 4.17 or higher, use CVS to find the changes from the vendor branch and you will then have our modifications. Alternately, you could get the RCS files for 2.2.x's GDB and do a vendor import of 4.17 and fix the merge conflicts. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: Is there any reason not to MFC the new md(4) functionality Zero reason not to. Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. If we have abandoned the no changes to API or ABI in -stable paradigm, it would be a good idea, but it serious rains on that rule... I don't think it would be much of a practical problem for anyone since the old behvior can be emulated with the new md pretty easily, but you're right that it isn't appropriate to break compatibility in -stable. It's probably possible to retrofit the old behavior into the new code, but I think that's too much evil for too little gain. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
Warner Losh [EMAIL PROTECTED] writes: In message 70325.991758797@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], David O'Brien writes: : On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: : Is there any reason not to MFC the new md(4) functionality : : Zero reason not to. : : Others see it differently, it would seriously break a lot of : people who are using -stable in embedded applications. : : If we have abandoned the no changes to API or ABI in -stable : paradigm, it would be a good idea, but it serious rains on that : rule... I've stated in the past that removing mfs from stable is going to cause me some grief. However, the addition of md won't so long as mfs remains intact. I don't think anybody is even remotely suggesting that MFS be removed, but someone (other than you) might get bitten by a change of this sort. I guess it's just a matter of whether the new functionality (and giving people a head start integrating the new behavior into their systems) is worth burning however many people depend on the old behavior. Dima Dorfman [EMAIL PROTECTED] Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
XFree86 4.1.0 and i810
Many have had problems with the XFree86 and i810 or i815 chipsets under FreeBSD. Specifically, the server crashes after switching to a text console and switching back to the console X is running on. Unlike versions 4.0.2 and 4.0.3 (4.0.1 magically works for me), 4.1.0 prints an error message: xf86BindGARTMemory: binding of gart memory with key %d at offset 0x%x failed (%s), where %d, %x, and %s all have their standard C interpretations. %s is the string produced by interpreting the global variable errno as set by ioctl. The file where the error occurs is in (relative to the xc directory) programs/Xserver/hw/xfree86/os-support/bsd/lnx_agp.c (a link to ../linux/lnx_agp.c), line 257. The problem is a failed AGPIOC_BIND ioctl call. The variable errno is set to 2, or No such file or directory. The biggest problem with the crashing server is that it will not restart properly until the machine is shutdown; it seems the GART is not cleared after the crash. However, I have not investigated this at all. I submit this here in the hopes that somebody who understands ioctl (specifically AGPIOC_BIND, defined in /usr/include/sys/agpio.h) might be able to explain why I'm getting errno=2. I can't see why this specific problem would occur, unless the ioctl is trying to access the AGP GART at some device node other than /dev/agpgart. I hope somebody can provide more information. I am in the process of fetching and extracting the XFree86 4.0.1 sources, I will take a look at how they handled the ioctl. Unfortunately, I do not know enough about the design of the FreeBSD kernel to go poking in there; if XFree86 4.0.1 can't offer some hints on the right way to handle things, I'm fresh out of ideas. -- Andrew Hesford [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
rpc.statd
Jun 6 18:48:10 www rpc.statd: invalid hostname to sm_stat: ^XF7FFBF^XF7FFBF^ZF7FF BF^ZF7FFBF%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM -^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^P M-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^ PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM -^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^P M-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^ PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^P this is a message in messages before a kernel paniced on freebsd 4.3. I have token liberty of disabling, what does this look like to you guys. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rpc.statd
On Wed, 6 Jun 2001, Dan Phoenix wrote: Jun 6 18:48:10 www rpc.statd: invalid hostname to sm_stat: ^XF7FFBF^XF7FFBF^ZF7FF BF^ZF7FFBF%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- [ snip ] It's some l33t h4x0r attemting to use a Linux RPC exploit against your FreeBSD machine. From what I've been told, It's harmless (since FreeBSD never had the hole that Linux did), and I see it quite often on some of the public boxes that I run. Are you absolutely sure that this was the cause of your kernel panic? -- Matt Emmerton GSI Computer Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: XFree86 4.1.0 and i810
On Wed, Jun 06, 2001 at 11:20:45PM -0500, Andrew Hesford wrote: I hope somebody can provide more information. I am in the process of fetching and extracting the XFree86 4.0.1 sources, I will take a look at how they handled the ioctl. Unfortunately, I do not know enough about the design of the FreeBSD kernel to go poking in there; if XFree86 4.0.1 can't offer some hints on the right way to handle things, I'm fresh out of ideas. The XFree86 4.0.1 sources *did* offer a helpful hint. I have posted another email which includes a patch to fix the buggy i810 driver. -- Andrew Hesford [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
On Wed, 6 Jun 2001, Dima Dorfman wrote: I don't think anybody is even remotely suggesting that MFS be removed, but someone (other than you) might get bitten by a change of this sort. I guess it's just a matter of whether the new functionality (and giving people a head start integrating the new behavior into their systems) is worth burning however many people depend on the old behavior. Dima Dorfman [EMAIL PROTECTED] Ok, silly question from the peanut gallery time. If md is different than md used to be, could the name be changed to something other than md which wouldn't conflict with the old md? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
In message [EMAIL PROTECTED], Dima Dorfman write s: Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: Is there any reason not to MFC the new md(4) functionality Zero reason not to. Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. If we have abandoned the no changes to API or ABI in -stable paradigm, it would be a good idea, but it serious rains on that rule... I don't think it would be much of a practical problem for anyone since the old behvior can be emulated with the new md pretty easily, but you're right that it isn't appropriate to break compatibility in -stable. It's probably possible to retrofit the old behavior into the new code, but I think that's too much evil for too little gain. Well, I see that we just ripped out the wd compat bits, so I guess we don't care about ABI/API stability that much in -stable any more... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
I don't think it would be much of a practical problem for anyone since the old behvior can be emulated with the new md pretty easily, but you're right that it isn't appropriate to break compatibility in -stable. It's probably possible to retrofit the old behavior into the new code, but I think that's too much evil for too little gain. Well, I see that we just ripped out the wd compat bits, so I guess we don't care about ABI/API stability that much in -stable any more... We being who? Your Danish henchman? 8) Actually, I do recall discussion over 'wd' being end-of-lifed in 4.x. I suspect that it would make sense to EOL 'mfs' in a similar fashion. I don't think there's a lot of good sense in pulling it out at an arbitrary point, though, any more than there was in pulling 'wd' like it was. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
