Re: telsat satellite cards
"Adam Crawford" writes: 'lo everyone I was wondering if there was drivers around for a telsat card, I know there is linux drivers, located on ftp.ihug.com.au/pub/satnet/linux (i think) also ment to be on ftp.ihug.co.nz but ive yet to be able to log on to that server :) Is there fbsd drivers? I don't believe so. If not, will the linux drivers work or be able to port them across? no, yes - but you'll either have to do it yourself or find someone who's interested in doing the port. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telsat satellite cards
On 15-Mar-00 Adam Crawford wrote: Whats involved in doing it myself? Read the Linux source and find out how it talks to the card Read the FreeBSD source for an equivalent device Write the FreeBSD device. Simple! :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
changing probe order for scsi controllers (ncr0/ahc0)
hi. i have a production system with an ncr0 SCSI controller that's pretty weak. I would like to add an adaptec, which comes in as ahc0. The problem is that when I add the ahc0 in to the system, it comes up ahead of the ncr0, and so the system disk is labeled da1, and .. well .. there are ways to deal with this .. i thought, based on the admonition about ISA NIC probes, that order in the kernel conf file might predicate probe order, but even in GENERIC, ncr0 comes ahead of ahc0 .. so .. no dice. 1) Can I modify the order in which these devices are detected so that the ncr0 comes out first, making my life simpler? How? 2) Failing that, how the freak do I MAKEDEV the disk slices so I can mount the system slices on da1s1 instead of da0s1? Or will the OS dtrt when it sees that I've MAKDEVed da1s1 and create the slices automagically? I've managed to boot single-user by modifying boot device at the kernel prompt ... 3) TIA. :) Thanks, -danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telsat satellite cards
Read the Linux source and find out how it talks to the card Read the FreeBSD source for an equivalent device Write the FreeBSD device. Simple! :) If there was source for an equivalent device, why would i need to write another one? :) Cheers for the advice Gary Daniel All i need to do now is wait for them to install the dish on my roof next week! Regards, Adam. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telsat satellite cards
+[ Adam Crawford ]- | | 'lo everyone | | I was wondering if there was drivers around for a telsat card, | I know there is linux drivers, located on ftp.ihug.com.au/pub/satnet/linux | (i think) | also ment to be on ftp.ihug.co.nz but ive yet to be able to log on to that | server :) | | Is there fbsd drivers? | If not, will the linux drivers work or be able to port them across? I offered to port/develop the drivers for them, but, they didn't seem interested, and the Linux drivers were binary only at that stage. They said they were developing FreeBSD drivers, but this was over 12 months ago. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
Warner Losh wrote: The xe driver is close to working with current as it is. There is a minor problem with the pccard layer that I've not had the time to commit. I am waiting for the xe driver working with current for updating FreeBSD on my laptop, so... APPLAUSEgo Warner!/APPLAUSE :-) -- JMA * Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] * "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changing probe order for scsi controllers (ncr0/ahc0)
* Danny Howard [EMAIL PROTECTED] [000315 02:21] wrote: hi. i have a production system with an ncr0 SCSI controller that's pretty weak. I would like to add an adaptec, which comes in as ahc0. The problem is that when I add the ahc0 in to the system, it comes up ahead of the ncr0, and so the system disk is labeled da1, and .. well .. there are ways to deal with this .. i thought, based on the admonition about ISA NIC probes, that order in the kernel conf file might predicate probe order, but even in GENERIC, ncr0 comes ahead of ahc0 .. so .. no dice. Please read the section in LINT about "wired" scsi setups. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Why not gzip iso images?
After reading the announcement... Congratulations to the FreeBSD community another milestone! A great OS... But for the ISO images... IS it a problem to gzip them They take less space on the master site and the mirror sites and they take less bandwidth! Shouldn't be a problem I think! Less bandwidth and less time to download even economical a good thing! With regards, Arnout Boer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000 13:42:11 +0100, Arnout Boer wrote: But for the ISO images... IS it a problem to gzip them Well, I can think of at least one problem. Think of the extra disk space folks would need for the gunzip step. :-) They take less space on the master site and the mirror sites and they take less bandwidth! I'm pretty sure that the folks most affected by this sort of thing benefit from PPP / hardware compression anyway. Ciao Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000 13:42:11 +0100, Arnout Boer wrote: But for the ISO images... IS it a problem to gzip them Well, I can think of at least one problem. Think of the extra disk space folks would need for the gunzip step. :-) and compression ratio would not be that much. The tarballs are already compressed, and so are the packages. The only image to benefit from compression would be the live file system. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
* Luigi Rizzo [EMAIL PROTECTED] [000315 05:34] wrote: On Wed, 15 Mar 2000 13:42:11 +0100, Arnout Boer wrote: But for the ISO images... IS it a problem to gzip them Well, I can think of at least one problem. Think of the extra disk space folks would need for the gunzip step. :-) and compression ratio would not be that much. The tarballs are already compressed, and so are the packages. The only image to benefit from compression would be the live file system. And not that much even with that: -rw-r--r-- 1 bright staff 647815168 Dec 28 19:23 3.4-install.iso -rw-r--r-- 1 bright staff 625839147 Dec 28 19:23 3.4-install.iso.gz that's not gzip -9, but I think I've done that in the past to the disks and it still didn't help all that much. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000, Alfred Perlstein wrote: And not that much even with that: -rw-r--r-- 1 bright staff 647815168 Dec 28 19:23 3.4-install.iso -rw-r--r-- 1 bright staff 625839147 Dec 28 19:23 3.4-install.iso.gz I never thought I'd see the day that when considering sizes of downloads people would look at a saving of 22Mb, and would say 'that's not much'... Fair enough, as a percentage it's marginal... but in countries where internet access is not cheap, in fact is prohibitively slow and expensive (the majority of the planet), I think this saving shows a little respect and concern for the less fortunate home user stuck with a 56K modem paying $x/hour where x can be anywhere between 0.5 and 5... that's not gzip -9, but I think I've done that in the past to the disks and it still didn't help all that much. If you save 20Mb, over a reliable 56Kb modem, you've saved them somewhere in the region of one and a half hours... I think you guys are too used to your broadband... :) Let's also assume that a mirrored FTP site is limited to XGb/mth... all it would take is for a 100 downloads to cause an extra 2Gb of that to be taken up Personally, I feel that everything that can be compressed for download, should be. It would speed up downloads, would be more economical in terms of bandwidth, cost and time, and I think would be generally considered respectful for those users with crappy links. -- Paul Robinson - Developer/Systems Administrator @ Akitanet Internet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000 14:43:27 GMT, Paul Robinson wrote: If you save 20Mb, over a reliable 56Kb modem, you've saved them somewhere in the region of one and a half hours... I think you guys are too used to your broadband... :) And you're forgetting that, as I said in my original reply, people with 56K modems usually benefit from hardware compression over their link anyway. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000, Sheldon Hearn wrote: And you're forgetting that, as I said in my original reply, people with 56K modems usually benefit from hardware compression over their link anyway. But you're defeated by your own argument, as according to you the image doesn't compress very well, and I suspect (in fact I know) that hardware compression at the modem is not as efficient as gzip -9 ... at best you might be able to get that 22Mb we're talking about saving, down to a 10Mb saving... you're still leaving the guy with the modem sat there for around 45 minutes... -- Paul Robinson - Developer/Systems Administrator @ Akitanet Internet --- E-m: [EMAIL PROTECTED] | FreeBSD-4.0 Monopoly :- Tel: +44 (0) 161 228 6388 | Go directly to jail() ---| Do not pass /var/go http://www.akitanet.co.uk/ | Do not bind to 200.*.*.* IP addresses To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000 14:55:14 GMT, Paul Robinson wrote: But you're defeated by your own argument, as according to you the image doesn't compress very well No, you're not reading the thread properly. Someone else (who doesn't have the same bandwidth limitations that you and I do) said it doesn't compress well. If you're just replying to be involved in an argument, I have a few newsgroups for you to try. :-) Otherwise, this is pretty much asked and answered. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
* Paul Robinson [EMAIL PROTECTED] [000315 06:14] wrote: On Wed, 15 Mar 2000, Alfred Perlstein wrote: And not that much even with that: -rw-r--r-- 1 bright staff 647815168 Dec 28 19:23 3.4-install.iso -rw-r--r-- 1 bright staff 625839147 Dec 28 19:23 3.4-install.iso.gz I never thought I'd see the day that when considering sizes of downloads people would look at a saving of 22Mb, and would say 'that's not much'... Fair enough, as a percentage it's marginal... but in countries where internet access is not cheap, in fact is prohibitively slow and expensive (the majority of the planet), I think this saving shows a little respect and concern for the less fortunate home user stuck with a 56K modem paying $x/hour where x can be anywhere between 0.5 and 5... that's not gzip -9, but I think I've done that in the past to the disks and it still didn't help all that much. If you save 20Mb, over a reliable 56Kb modem, you've saved them somewhere in the region of one and a half hours... I think you guys are too used to your broadband... :) Let's also assume that a mirrored FTP site is limited to XGb/mth... all it would take is for a 100 downloads to cause an extra 2Gb of that to be taken up Personally, I feel that everything that can be compressed for download, should be. It would speed up downloads, would be more economical in terms of bandwidth, cost and time, and I think would be generally considered respectful for those users with crappy links. You're not going to get much sympathy from me... ~ % ftp ftp://ftp.freebsd.org/pub/FreeBSD/release/i386/ISO-IMAGES/ Connected to wizard.freesoftware.com. ... ftp get 3.4-install.iso local: 3.4-install.iso remote: 3.4-install.iso 227 Entering Passive Mode (209,155,82,20,112,101) 150 Opening BINARY mode data connection for '3.4-install.iso' (647815168 bytes). 100% |**| 617 MB00:00 ETA 226 Transfer complete. 647815168 bytes received in 147.34 seconds (4.19 MB/s) :) Seriously though, there's no reason not to have the ISOs up in compressed format though. I guess given a choice between _only_ compressed or _only_ uncompressed I think uncompressed is better, but if the space is available it would be nice to see compressed images available. Before anyone tries it here's bzipped (worse than gzip) results: -rw-r--r-- 1 bright staff 647815168 Dec 28 19:23 3.4-install.iso -rw-r--r-- 1 bright staff 629685893 Dec 28 19:23 3.4-install.iso.bz2 -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Why not gzip iso images?
-Original Message- From: Paul Robinson [mailto:[EMAIL PROTECTED]] Sent: 15 March 2000 14:55 you're still leaving the guy with the modem sat there for around 45 minutes... But given that he has probably been sat there for 2.5 days already, is that a major problem? Rich -- Rich Wood, Systems Manager, Royal United Hospital, Bath [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
WaveLAN/IEEE Turbo (Silver)
I'm trying to get a WaveLAN/IEEE Turbo (Silver) card working on a two month old -current system using the ISA bus card which comes with the PCMCIA WaveLAN unit. "pccardc dumpcis" says it wants IRQ 6, so I've made sure that that was included in the list of IRQs in pccard.conf. It's still unable to allocate I/O space, though: card insertion yields: pccard: card inserted, slot 0 wi0: No I/O space?! ... which is slightly demoralizing :-) The relevent bits of pccard.conf: io 0x240-0x3ff irq 3 5 6 10 11 13 15 memory 0xd4000 96k # Lucent WaveLAN/IEEE card "Lucent Technologies" "WaveLAN/IEEE" config 0x1 "wi0" ? insert echo WaveLAN/IEEE inserted insert /etc/pccard_ether $device remove echo WaveLAN/IEEE removed remove /sbin/ifconfig $device delete I'll attach the output of pccardc dumpcis. I saw something about this on -hackers or -current about two weeks ago, but I didn't have a WaveLAN card then, so it didn't occur to me to save it. I can't find any reference to it in the archives either, but I'm sure *someone* here knows an answer. I know the WaveLAN stuff is crap, and I'd rather be using Aironet at the moment (at least that works!), but we've thought it prudent to give the Lucent stuff a try (even if only to make sure our suppliers understand that we can change vendors easily, so they'd better give us a good price grin Cheers, - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000, Alfred Perlstein wrote: Seriously though, there's no reason not to have the ISOs up in compressed format though. I guess given a choice between _only_ compressed or _only_ uncompressed I think uncompressed is better, but if the space is available it would be nice to see compressed images available. How many FTP servers support on the fly gzipping and ungzipping? mirror.aarnet.edu.au does...perhaps a little note could be placed in .message to remind people to try it... Andrew (who is on 33.6 and dosnt even contemplate downloading ISO images) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
-On [2315 15:35], [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: On Wed, 15 Mar 2000, Alfred Perlstein wrote: Seriously though, there's no reason not to have the ISOs up in compressed format though. I guess given a choice between _only_ compressed or _only_ uncompressed I think uncompressed is better, but if the space is available it would be nice to see compressed images available. How many FTP servers support on the fly gzipping and ungzipping? mirror.aarnet.edu.au does...perhaps a little note could be placed in .message to remind people to try it... In all honesty, that's not a very intelligent option when discussing compressing ISO's. Compressing ISO's brings along a lot of cpu burn cycles as well as a large memory footprint. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] VIA NET.WORKS The Netherlands BSD: Technical excellence at its best http://www.bart.nl I may know many things, I may be ignorant... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
Paul Robinson wrote: I think this saving shows a little respect and concern for the less fortunate home user stuck with a 56K modem paying $x/hour where x can be anywhere between 0.5 and 5... Sorry, can't resist. Given (my) local call rates, if I started downloading the 3.4 ISO image and did a mail-order purchase of the CD at the same time, the CD would cost a lot less, and drop on my doormat before the download finished. 20MB doesnt make a difference for this 56K owner, cause I'm sensible enough not to use it to download ~640MB images! I'd rather give the money to FreeBSD than my Telco, anyway. Same goes for release candidates: there'll be a release before my download is done. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WaveLAN/IEEE Turbo (Silver)
On Thu, Mar 16, 2000 at 12:59:13AM +1030, Mark Newton wrote: I'll attach the output of pccardc dumpcis. Blurgh. Maybe I'll attach it this time. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 Configuration data for card in slot 0 Tuple #1, code = 0x1 (Common memory descriptor), length = 3 000: 00 00 ff Common memory device information: Device number 1, type No device, WPS = OFF Speed = No speed, Memory block size = 512b, 1 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 4 000: 67 5a 08 ff Attribute memory device information: Device number 1, type SRAM, WPS = OFF Speed = 5.0 x 100 ns, Memory block size = 512b, 2 units Tuple #3, code = 0x1d (Other conditions for attribute memory), length = 5 000: 01 67 5a 08 ff (MWAIT) Tuple #4, code = 0x15 (Version 1 info), length = 80 000: 05 00 4c 75 63 65 6e 74 20 54 65 63 68 6e 6f 6c 010: 6f 67 69 65 73 00 57 61 76 65 4c 41 4e 2f 49 45 020: 45 45 00 56 65 72 73 69 6f 6e 20 30 31 2e 30 31 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff Version = 5.0, Manuf = [Lucent Technologies],card vers = [WaveLAN/IEEE] Addit. info = [Version 01.01],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[] Tuple #5, code = 0x20 (Manufacturer ID), length = 4 000: 56 01 02 00 PCMCIA ID = 0x156, OEM ID = 0x2 Tuple #6, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #7, code = 0x22 (Functional EXT), length = 2 000: 01 07 Modem interface capabilities: Tuple #8, code = 0x22 (Functional EXT), length = 5 000: 02 40 42 0f 00 Data modem services available: Tuple #9, code = 0x22 (Functional EXT), length = 5 000: 02 80 84 1e 00 Data modem services available: Tuple #10, code = 0x22 (Functional EXT), length = 5 000: 02 60 ec 53 00 Data modem services available: Tuple #11, code = 0x22 (Functional EXT), length = 5 000: 02 c0 d8 a7 00 Data modem services available: Tuple #12, code = 0x22 (Functional EXT), length = 2 000: 03 07 Tuple #13, code = 0x22 (Functional EXT), length = 8 000: 04 06 00 60 1d 1e ac 5c Voice services available: Tuple #14, code = 0x22 (Functional EXT), length = 2 000: 05 01 Modem interface capabilities: Tuple #15, code = 0x1a (Configuration map), length = 7 000: 03 01 e0 03 00 00 01 Reg len = 4, config register addr = 0x3e0, last config = 0x1 Registers: X--- Tuple #16, code = 0x1b (Configuration entry), length = 15 000: c1 01 19 76 c5 4b d5 19 36 36 05 46 7f ff ff Config index = 0x1(default) Interface byte = 0x1 (I/O) Vcc pwr: Minimum operating supply voltage: 4 x 1V, ext = 0x4b Maximum operating supply voltage: 5 x 1V, ext = 0x19 Max current average over 1 second: 3 x 100mA Max current average over 10 ms: 3 x 100mA Power down supply current: 1 x 10mA Card decodes 6 address lines, limited 8/16 Bit I/O IRQ modes: Pulse IRQ level = 6 Tuple #17, code = 0xff (Terminator), length = 0 2 slots found
Re: telsat satellite cards
"Adam Crawford" writes: Read the Linux source and find out how it talks to the card Read the FreeBSD source for an equivalent device Write the FreeBSD device. Simple! :) If there was source for an equivalent device, why would i need to write another one? :) I assume Daniel meant "similar". The card probably looks like an ethernet card. There are tons of drivers in the tree. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
telsat satellite cards
'lo everyone I was wondering if there was drivers around for a telsat card, I know there is linux drivers, located on ftp.ihug.com.au/pub/satnet/linux (i think) also ment to be on ftp.ihug.co.nz but ive yet to be able to log on to that server :) Is there fbsd drivers? If not, will the linux drivers work or be able to port them across? Regards, Adam. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000 14:43:27 GMT, Paul Robinson wrote: If you save 20Mb, over a reliable 56Kb modem, you've saved them somewhere in the region of one and a half hours... I think you guys are too used to your broadband... :) And you're forgetting that, as I said in my original reply, people with 56K modems usually benefit from hardware compression over their link anyway. Har har. I have 33.6... compression? Har har. Better than gzip? :) But I *don't* need downloading 600Mb (jeee!)... Usualy there are ISPs who download such things and then sell some CDs (just the media:)). And they don't give a shXt about 20MB more or less... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
That's why [Re: Why not gzip iso images?]
* Paul Robinson [EMAIL PROTECTED] [000315 06:14] wrote: [snip snip] ~ % ftp ftp://ftp.freebsd.org/pub/FreeBSD/release/i386/ISO-IMAGES/ Connected to wizard.freesoftware.com. ... ftp get 3.4-install.iso local: 3.4-install.iso remote: 3.4-install.iso 227 Entering Passive Mode (209,155,82,20,112,101) 150 Opening BINARY mode data connection for '3.4-install.iso' (647815168 bytes). 100% |**| 617 MB00:00 ETA 226 Transfer complete. 647815168 bytes received in 147.34 seconds (4.19 MB/s) :) 200 PORT command successful. 150 Opening BINARY mode data connection for '3.4-install.iso' (647815168 bytes). 0% || 29200 73:54:02 ETA ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Buffer Problems and hangs in 4.0-CURRENT..
That's not spurprising. When I tried it, Solaris 2.6 x86 didn't support full-duplex 100Base-TX on very many devices. The DEC tulip cards were one of the few that had drivers that supported full-duplex. Charles -Original Message- From: Howard Leadmon [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 12, 2000 4:24 PM To: Alfred Perlstein Cc: [EMAIL PROTECTED] Subject: Re: Buffer Problems and hangs in 4.0-CURRENT.. ... I used the DEC based cards as I had seen so many people raving about them, and at least under Solaris they claim the DEC tulip based boards are the hot ticket. ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
Arnout Boer wrote: But for the ISO images... IS it a problem to gzip them They take less space on the master site and the mirror sites and they take less bandwidth! But, how much would the ISO be able to be compressed? The source is already a split, compressed tarball, for example... Less bandwidth and less time to download even economical a good thing! I think we should use bzip2 to compress the images. Someone should try to compress the images using gzip, and then bzip2, and compare the file sizes. Bzip2 is an awesome compression program, but I understand that gzip is better at compressing certain things for a small number of cases. Use the -v option to both, and see what it reports for the compression %'age. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Best NIC for FBSD (was: Buffer Problems and hangs in 4.0-CURRENT..)
I will attest to that, as I have several Solaris-x86 machines, some on 2.6. and some on 2.7, all running the DEC cards in 100T-FDX mode like a champ. As some are news servers, they run 20-30mpbs constantly almost 24/7 without a hitch, so they work well under Solaris. Guess it was dumb to assume they would work as well on FBSD, but I had hoped. I have piles of the DEC cards around. I wonder what really has the best driver under FBSD, as far as reliability and performance, and yes I also want 100T-FDX as my entire network is interconnected with Cisco Catalyst Switches. I got the inside scoop on the DEC cards for Solaris from some Sun engineers. Has anyone actually ever rated/tested the various NIC's for FBSD?? -Howard That's not spurprising. When I tried it, Solaris 2.6 x86 didn't support full-duplex 100Base-TX on very many devices. The DEC tulip cards were one of the few that had drivers that supported full-duplex. Charles -Original Message- From: Howard Leadmon [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 12, 2000 4:24 PM To: Alfred Perlstein Cc: [EMAIL PROTECTED] Subject: Re: Buffer Problems and hangs in 4.0-CURRENT.. ... I used the DEC based cards as I had seen so many people raving about them, and at least under Solaris they claim the DEC tulip based boards are the hot ticket. ... --- Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
I think people are forgetting that you do not necessarily need to download the entire ISO image in order to make a fresh install of FreeBSD. Back when I started using FreeBSD somewhere around version 2.1, I remember donwloading the boot floppies, then installing the whole deal over FTP, all on a 28.8 modem. When you install via FTP you only have to download what you need and nothing more. Sure this is a pain for installing/upgrading a bunch of machines, since you would be downloading the same things over and over again for each machine. If you have only one machine you're worried about, say a test machine, then install over FTP and if you like it... just buy the CD's :) -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
- Original Message - From: "Eric D. Futch" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 15, 2000 8:58 PM Subject: Re: Why not gzip iso images? I think people are forgetting that you do not necessarily need to download the entire ISO image in order to make a fresh install of FreeBSD. Back when I started using FreeBSD somewhere around version 2.1, I remember donwloading the boot floppies, then installing the whole deal over FTP, all on a 28.8 modem. When you install via FTP you only have to download what you need and nothing more. Sure this is a pain for installing/upgrading a bunch of machines, since you would be downloading the same things over and over again for each machine. Then download the individual parts (eg bin.aa to bin.bf) and then install from a local ftp-server. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
On Tue, Mar 14, 2000 at 04:14:50PM -0800, Don Wallwork wrote: Hi- I found a linux driver for my Xircom PCMCIA ethernet card at: http://pcmcia.sourceforge.org/ Which card was that? All of the recent Xircom PCMCIA cards are supported by the xe driver in 3.x Are there any pointers available on porting linux drivers to FreeBSD? I'm not aware of any, but for network drivers at least it's pretty easy regardless. To a certain level, a driver is a driver is a driver; they all have to do pretty much the same things in the same order, BSD and Linux just express that a little differently. I've typically found that figuring out how to make the d*mn badly documented hardware behave is way harder than glueing it into your OS of choice :-) Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
Scott Mitchell wrote: On Tue, Mar 14, 2000 at 04:14:50PM -0800, Don Wallwork wrote: Hi- I found a linux driver for my Xircom PCMCIA ethernet card at: http://pcmcia.sourceforge.org/ Which card was that? All of the recent Xircom PCMCIA cards are supported by the xe driver in 3.x RealPort CardBus Ethernet 10/100 (RBE-100). I'll give the xe driver a try. Are there any pointers available on porting linux drivers to FreeBSD? I'm not aware of any, but for network drivers at least it's pretty easy regardless. To a certain level, a driver is a driver is a driver; they all have to do pretty much the same things in the same order, BSD and Linux just express that a little differently. I've typically found that figuring out how to make the d*mn badly documented hardware behave is way harder than glueing it into your OS of choice :-) Agreed. Thanks for the info. -Don Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
On Wed, Mar 15, 2000 at 01:35:11PM -0800i, Don Wallwork wrote: RealPort CardBus Ethernet 10/100 (RBE-100). I'll give the xe driver a try. Dont even try, Cardbus (32-bit) isn't supported by FreeBSD yet. I made the mistake of buying that exact card :P -- _ Patrick Seal|"Microsoft isn't evil, they just make [EMAIL PROTECTED] | really crappy operating systems." Hyperhost - http://www.hyperhost.net| -Linus Torvalds To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WaveLAN/IEEE Turbo (Silver)
In message [EMAIL PROTECTED] Mark Newton writes: : "pccardc dumpcis" says it wants IRQ 6, so I've made sure that that : was included in the list of IRQs in pccard.conf. It's still unable : to allocate I/O space, though: card insertion yields: : :pccard: card inserted, slot 0 :wi0: No I/O space?! : : ... which is slightly demoralizing :-) Two items. First, boot -v (or break into the debugger before inserting the card and do 'w bootverbose 1'). Second add the following line to your pccard.conf file before the reboot: debuglevel 4 and pccardd will give you more information about what it is trying to do. Send me the results. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
Can I step in here for a moment? I'm not going to gzip the ISO images. Please just live with it. End of discussion. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Digital HiNote 433 and 3.X Installation Problems
I'm trying to (finally) upgrade my DEC HiNote Laptop from 2.2.8 to 3.4 by doing just a clean install. I can do all the hard disk stuff and select the installation method, but as soon as it starts unpacking "bin" it hangs. I thought it might be a networking problem and even tried installing from floppies...same thing. Any advice how do dance around possible hardware issues, or anything else? It's a i486/33, 8 MB, 250 MB. I also tried installing 3.0 and that couldn't get past the "probing hardware", and OpenBSD installs but hangs when making the devices. I can install FreeBSD 2.2.8, NetBSD 1.4.1, and DOS without any problems. -- Johh Heyer - [EMAIL PROTECTED] - http://www.jfive.com "Me fail English? That's unpossible!" -- Ralph Wiggam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: specifying probe order for scsi controllers
In message [EMAIL PROTECTED] dannyman writes: : or is there some way i can config things to keep da0 on the ncr and da1 on the : aha? You can look at the LINT kernel for ways to hardwire these devices. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Odd crash
I just got an odd crash:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d16ac
stack pointer = 0x10:0xc031e704
frame pointer = 0x10:0xc031e70c
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 = Idle
interrupt mask =
kernel: type 12 trap, code=0
Stopped at arpintr+0x9c: movl0x8(%ebx),%ecx
db trace
arpintr(c02a997b,0,10,10,c5d20010) at arpintr+0x9c
swi_net_next() at swi_net_next
db
I'm using the realtek driver with a RealTek 8139 built into the SBC
that I have sitting on my desk.
rl0: RealTek 8139 10/100BaseTX port 0x6000-0x60ff mem 0xf900-0xf9ff irq 11
at device 6.0 on pci0
rl0: Ethernet address: 00:60:e0:00:7f:c8
Looking at the disassembled output of ddb, I think that I'm crashing
at the following place.
if (m-m_len sizeof(struct arphdr)
(m = m_pullup(m, sizeof(struct arphdr)) == NULL)) {
log(LOG_ERR, "arp: runt packet -- m_pullup failed.");
continue;
}
ar = mtod(m, struct arphdr *);
== if (ntohs(ar-ar_hrd) != ARPHRD_ETHER
ntohs(ar-ar_hrd) != ARPHRD_IEEE802) {
log(LOG_ERR,
"arp: unknown hardware address format (%2D)",
(unsigned char *)ar-ar_hrd, "");
m_freem(m);
continue;
}
since ar is NULL for some reason. I have no clue at all why this
would happen. This means that m-m_data has to be NULL. But that
doesn't make sense because of the m_pullup just before this. If it
doesn't return NULL, then I thought that m-m_data was guaranteed to
be valid.
I think that there might be a bug in the code generation, but I don't
know for sure. If we look at the disassembled output:
arpintr+0x79: testl %eax,%eax
arpintr+0x7b: setz%al
arpintr+0x7e: movzbl %al,%ebx
arpintr+0x81: testl %ebx,%ebx
arpintr+0x83: jz arpintr+0x9c
arpintr+0x85: pushl $0xc02f5c60
arpintr+0x8a: pushl $0x3
arpintr+0x8c: calllog
arpintr+0x91: addl$0x8,%esp
arpintr+0x94: jmp arpintr+0x5
arpintr+0x99: leal0(%esi),%esi
arpintr+0x9c: movl0x8(%ebx),%ecx
arpintr+0x9f: movzwl 0(%ecx),%eax
arpintr+0xa2: xchgb %ah,%al
arpintr+0xa4: cmpw$0x1,%ax
arpintr+0xa8: jz arpintr+0xd8
arpintr+0xaa: movzwl 0(%ecx),%eax
arpintr+0xad: xchgb %ah,%al
arpintr+0xaf: cmpw$0x6,%ax
arpintr+0xb3: jz arpintr+0xd8
arpintr+0xb5: pushl $0xc02f5c0e
arpintr+0xba: pushl %ecx
arpintr+0xbb: pushl $0xc02f5ca0
arpintr+0xc0: pushl $0x3
arpintr+0xc2: calllog
So we're between the two log calls, which is good. Notice that we
effectively zero %ebx at 7e. We then jump to 9c if it isss zero, and
then dereference 3bx. Bang, we're dead.I think that the jz should
be a jnz, no?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000, Sheldon Hearn wrote: And you're forgetting that, as I said in my original reply, people with 56K modems usually benefit from hardware compression over their link anyway. But you're defeated by your own argument, as according to you the image doesn't compress very well, and I suspect (in fact I know) that hardware compression at the modem is not as efficient as gzip -9 ... at best you might be able to get that 22Mb we're talking about saving, down to a 10Mb saving... you're still leaving the guy with the modem sat there for around 45 minutes... Remember that our modem guy has spent the last 48 hours sitting there waiting for the download to complete. I'm sure that by now he's fallen asleep and the 45 minutes will not make a difference anyway. ;) In most places that are ``affected'' by that 20MB you're trying to save, bandwidth is so expensive that you'll never going to download the ISO image anyway. I've just calculated that it would cost me AUD 120 or so, compared to $20 for downloading just the distribution I need. If I was to download the ISO image over my modem, I'd order a CD today instead (or enroll at Uni ;) So I'm supporting uncompressed iso images. 99.99% of those who'd benefit from the compression would never consider downloading them anyway, and 99.99% of those who are going to use these images will find .gz a pain. Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd crash
On Wed, Mar 15, 2000 at 04:46:02PM -0700, Warner Losh wrote: I just got an odd crash: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d16ac stack pointer = 0x10:0xc031e704 frame pointer = 0x10:0xc031e70c 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 = Idle interrupt mask = kernel: type 12 trap, code=0 Stopped at arpintr+0x9c: movl0x8(%ebx),%ecx db trace arpintr(c02a997b,0,10,10,c5d20010) at arpintr+0x9c swi_net_next() at swi_net_next db I'm chasing a similiar bug since 2 weeks. The kernel crashed with a double page fault and access to a very low address (something like 0x0098). I eliminated the RealTek card (replaced by a 3Com) and things got better. But it kept crashing. Now I have disabled SMP and things happen even more rarely (once every 2 days instead of once every 3-4 hours). This is a very fast machine (733) potentially with chipsets not supported too well. I have a few crash dumps I could people have a look at, at least send the output of kdgb. If anyone is interested, I may be able to provide access to the machine and the crash dumps (you can't ftp them, they are 1GB+ in size, it would cost me NZ$250). Joerg -- Joerg B. MicheelEmail: [EMAIL PROTECTED] Waikato Applied Network DynamicsPhone: +64 7 8384794 The University of Waikato, CompScience Fax: +64 7 8384155 Private Bag 3105Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
Patrick Seal wrote: On Wed, Mar 15, 2000 at 01:35:11PM -0800i, Don Wallwork wrote: RealPort CardBus Ethernet 10/100 (RBE-100). I'll give the xe driver a try. Dont even try, Cardbus (32-bit) isn't supported by FreeBSD yet. You haven't been looking into 4.0, have you? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
On Wed, Mar 15, 2000 at 05:46:11PM -0700i, Wes Peters wrote: Patrick Seal wrote: On Wed, Mar 15, 2000 at 01:35:11PM -0800i, Don Wallwork wrote: RealPort CardBus Ethernet 10/100 (RBE-100). I'll give the xe driver a try. Dont even try, Cardbus (32-bit) isn't supported by FreeBSD yet. You haven't been looking into 4.0, have you? I *run* 4.0 on my laptop, have for months. Date: Sat, 29 Jan 2000 12:23:00 -0500 From: Peter Radcliffe [EMAIL PROTECTED] Patrick Seal [EMAIL PROTECTED] probably said: Has anyone had success with the Xircom CardBus Ethernet 10/100 on either CardBus is not yet supported. - -- _ Patrick Seal|"Microsoft isn't evil, they just make [EMAIL PROTECTED] | really crappy operating systems." Hyperhost - http://www.hyperhost.net| -Linus Torvalds To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NFS Panic Problem
Recently one of the FreeBSD machines where I work has been crashing on a semi-regular basis, once or twice a day. The dmesg for the machine is at the bottom of this post. These crashes started very recently, less than a week ago. Before that, the machine had been very reliable (several 100 day uptimes). The machine used to be running FreeBSD 3.1-STABLE as of mid-April 1999. Since I know many NFS bugs have been fixed since then, the box was on Tuesday upgraded to 3.4-STABLE (a completely fresh installation). This, however, did not fix the panics. I believe the problem to be related to one of these two PRs: [1998/06/23] kern/7028 http://www.freebsd.org/cgi/query-pr.cgi?pr=7028 panic in vinvalbuf when appending/looking at tail of NFS file [2000/03/08] misc/17272 http://www.freebsd.org/cgi/query-pr.cgi?pr=17272 deleting a file that a program has open causes vinvalbuf: flush failed Basically, it's: panic: vinvalbuf: flush failed And appears to be triggered by a 'tail -f' on a growing, very large log file over NFS. The NFS host on the other end is running Solaris 2.6 on a sparc. The actual mount is kind of weird; it is indirected through a different NFS mount off a NetApp through a symlink (the NetApp-mounted FS is basically a symlink farm with a few real directories). Basically: netapp:/home on /home sun:/logs on /sun/logs /home/logs@ - /sun/logs and we are doing 'tail -f /home/logs/largelogfile' (there are good historical reasons for this setup) We have made no significant changes to the other machines in this setup, although the logfile in question has been growing in size over time. We rotate the logfile on the Sun daily as well. No executable files for the BSD machine are stored on the Sun. I have compiled a debug kernel and will provide a traceback and/or dump to anyone who is interested once it happens again. If I find a way to reliably reproduce it, I will post that too. For the meantime, are there any quick patches or other solutions I could use? Thanks in advance for your time and advice, Doug Below is dmesg: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-STABLE #2: Tue Mar 14 23:21:39 CST 2000 doug@xxx:/usr/src/sys/compile/XXX Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 347664663 Hz CPU: Pentium II/Xeon/Celeron (347.66-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 536870912 (524288K bytes) avail memory = 519360512 (507188K bytes) Preloaded elf kernel "kernel" at 0xc0309000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc030909c. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x03 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x03 on pci0.1.0 chip2: PCI to PCI bridge (vendor=1011 device=0024) rev 0x03 on pci0.2.0 chip3: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0 chip4: Intel 82371AB Power management controller rev 0x02 on pci0.7.3 fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 14 on pci0.8.0 fxp0: Ethernet address 00:90:27:45:ee:ae Probing for devices on PCI bus 1: vga0: ATI model 4744 graphics accelerator rev 0x5c on pci1.0.0 Probing for devices on PCI bus 2: ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter rev 0x00 int a irq 11 on pci2.4.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7860 SCSI adapter rev 0x03 int a irq 11 on pci2.6.0 ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x30 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 lppps0: Pulse per second Timing Interface on ppbus 0 plip0: PLIP network interface on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 8 seconds for SCSI devices to settle chcd0 at ahc1 bus 0 target 5 lun 0 cd0: NEC CD-ROM DRIVE:465 1.03 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 1 lun 0 da1: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8715MB (1785 512 byte sectors: 255H
