Re: ad0: FAILURE - WRITE_DMA
On Saturday 09 October 2004 20:53, Dag-Erling Smørgrav wrote: > "Mikhail P." <[EMAIL PROTECTED]> writes: > > Well, there is no pattern. [...] > > Could be bad cables, could be bad drives. Environmental factors are a > more likely cause, though. Are all the failing disks in the same > machine? If they're in separate machines, are those rack-mount, or > are they standing on a table or shelf? If a shelf, what kind? What's > the ambient temperature in the machine room? Could be cables - I will get a replacement to verify that. I'm less sure it is drives. Yes, all 4 drives were in the same machine. Machine is a regular 2U rackmount chassis (one CPU), with proper airflow. Each drive has its individual aluminum fan as well. Chassis sits in a 47U cabinet, datacenter environment, with lots of free space around. So I'm quite sure it is not cooling/dust issues.. Well, unfortunately, I don't have access to hardware myself, so I can't do any hardware related tasks. As said, I will get those two drives shipped to me, and will then see myself if it is really hdd issue, or something else.. > > DES regards, M. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
"Mikhail P." <[EMAIL PROTECTED]> writes: > Well, there is no pattern. [...] Could be bad cables, could be bad drives. Environmental factors are a more likely cause, though. Are all the failing disks in the same machine? If they're in separate machines, are those rack-mount, or are they standing on a table or shelf? If a shelf, what kind? What's the ambient temperature in the machine room? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
Gotta love when you reply to your own posts... :)
On Sat, 9 Oct 2004, Doug Russell wrote:
> If it has a BIOS it should have the verify tool in there...
>
> All the verify tool does, though, is issue a verify command to each
> sector. You can do this yourself, even on a running system, also.
I meant to add a couple more notes about the modepages
The number (or maximum time -- it's drive dependent) of retries for
regular reads and writes are adjustable in modepage 1.
There are alternate settings for the VERIFY commands (like sent to the
drive in the BIOS verify utility) on the VERIFY page (modepage 7).
Reading the docs for the actual drive in question is the only way you can
tell EXACTLY what is done by each setting, and it does take a little
research to understand exactly what is going on, but there are LOTS of
nice knobs to twiddle on most disks.
You might have to add some things to /usr/src/share/misc/scsi_modes
(on freebsd) to be able to edit all the possible options on some disks
using the editor routines. For example, I created the following entry for
Seagate disks like all my ST19171WC (about 60) and ST15150W drives (20+)
that actually understands things like the cache segmentation size (how
many little chunks of cache it should hold, and therefore how big each
is, which is a VERY nice tuneable for a heavy-multi-user server versus
single user A/V RAID array disk tuning; multi-user, you want lots of
little cache segments... streaming use, you want a couple of huge
segments):
0x08 "Caching Page" {
{IC (Initiator Control enable)} t1
{ABPF (ABort Pre-Fetch on selection)} t1
{CAP (Caching Analysis Permitted)} t1
{DISC (DISContinuity)} t1
{SIZE (cache segmentation by SIZE enable)} t1
{WCE (Write Cache Enable)} t1
{MF (prefetch Multiplication Factor)} t1
{RCD (Read Cache Disable)} t1
{Demand Retention Priority} t4
{Write Retention Priority} t4
{Disable Pre-fetch Transfer Length} i2
{Minimum Pre-fetch} i2
{Maximum Pre-fetch} i2
{Maximum Pre-fetch Ceiling} i2
{FSW (Force Sequential Write)} t1
{LBCSS (Logical Block Cache Segment Size)} t1
{DRA (Disable Read-Ahead)} t1
{Reserved} *t5
{Number of Cache Segments} i1
{Cache Segment Size} i2
{Reserved} *i1
{Non-Cache Segment Size} i3
I turn off all retries, etc, and set the drive to do full error reporting
before I run any tests. (You don't want the drive correcting anything
itself, you want to report EVERYTHING...)
Modepages are fun. :)
Later..
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
On Sat, 9 Oct 2004, John Von Essen wrote: > The SCSI card is an old Adaptec, AIC-7880 and I believe it does not > support automatic bad block detection/redirection. If it has a BIOS it should have the verify tool in there... All the verify tool does, though, is issue a verify command to each sector. You can do this yourself, even on a running system, also. > This disk came from a spares kits, so even though it is "new" and never > used, it is still 5-6 years old. There were 6 bad blocks, once they > were put in the bad block table, everything was fine. Exactly. Most of my SCSI disks are old spares, or old surplus disks. They've likely been moved several times, bumped around, and time itself can make a marginal section of the magnetic coating stop holding data perfectly. > Is sformat the freebsd equivalent of the badtrk utility. I have always No, I don't believe so. I think badtrk is probably like the old bad144 system that was abandoned because it is unnecessary on all modern disks. All modern IDE disks have built-in re-allocation tables, similar to the way SCSI disks work, but you can't manipulate them manually as easily as you can on a SCSI disk. sformat is a handy formatting utility written by Joerg Schilling. It has special options for partitioning disks on SUN machines, but the format routines and defect scans will run on virtually any platform. It has full patern testing abilities. First it writes and verifies every byte on the drive as all 's then all 's... then 01010101 and 10101010, etc. etc... stressing the media in every possible combination. (Many, many, errors won't show up if you just write all zeros or ones, for example. It is much harder to store a zero next to a one, so trying every combination pre-tests anything that might be written.) This kind of testing is done at the factory, and limited pattern testing is generally done by the built-in low-level format routine on most drives. > used Ultra2 LVD SCSI and higher on FreeBSD and have never had this > issue of bad blocks. Is that because those newer SCSI disks and > controllers have better ECC handling and take care of the bad blocks > internally without notifying the user? If you play with the SCSI modepages, you can tell the drive to post an error or not under various conditions (a correctible ECC error, an uncorrectible error, a re-allocated block, etc.) You've probably never seen errors before because the drives were set with Automatic (Write / Read) Reallocation Enable (AWRE and ARRE) set in modepage 1. This disk you're working with now obviously has ARRE and probably AWRE disabled, so it isn't trying to re-allocate the blocks when it finds an error. I'd check that and turn it on. Then, the next time you try to read the bad block, the drive should remap it on its own. The exact behavior varies by drive and by settings in the modepages. Some drives may have AWRE and ARRE enabled, but not re-allocate a certain block because they can't get the data off the sector in the retry time allowed. Cranking up the retry timer (when available) might work, or else you have to do it manually by sending the re-allocate block command. I sure love SCSI disks... They let you do virtually ANYTHING to them if you know the technical details of how to send the commands. (The technical manuals for the disks are very handy in this regard.) On FreeBSD, you can see what was in the defect table at the factory by doing a camcontrol defects daX -f phys -P (I like phys, as it shows the actual physical head and cylinder number with a byte offset -- you can actually 'see' the areas that are defective). You can see the GROWN defect list (rather than the primary) with -G. VERY often the grown defects are simply the next sector or two to the sides of an existing defect. If a series of defects span several cylinders on the same head at about the same offset, it's probably a media defect 'scratch' across the disk. If it is on the same cylinder on several heads at about the same place, it is probably from a mini-head-crash due to the disk getting bumped, etc, where it actually damaged spots on several disks at once when the heads touched (or almost touched). etc. etc. Interestingly enough, the way sformat sends the block format commands, some disks add the new defects found to their PRIMARY defect list, instead of the GROWN list, as if they had been re-tested at the factory. There is a command to clear the GROWN list, but not the PRIMARY. (Some cheesy drives re-do their primary table when you send them the single low-level-format command, but most just add to the table. If you ever have LESS primary defects after sending a LLF command, it would be a VERY good idea to use sformat to better pattern test the drive before service) Here are some examples from a couple of disks here: Script started on Sat Oct 9 13:13:01 2004 ROOT mxb:/home/drussell 101 > camcontrol defects da0 -f phys -P /* This is the PRI
Re: ad0: FAILURE - WRITE_DMA
On Saturday 09 October 2004 18:26, Søren Schmidt wrote: > Hmm, that means that the drive couldn't find the sector you asked for. > Now, what has me wondering is that it is the exact sector where we > switch to 48bit adressing mode. Anyhow, I've just checked on the old > Maxtor preproduktion 48bit reference drive I have here and it crosses > the limit with no problems. > What controller are you using ? not all supports 48bit mode correctly.. There's VIA's motherboard (not sure about the model name). Here's info regarding ata controller from dmesg: atapci0: port 0xac00-0xac0f at device 17.1 on pci0 I will be able to test the drives (the ones which I thought of as "failed") on another board within 10 days or so. regards, M. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
I was able to use the badtrk utility in SCO to identify bad blocks and put them in the bad block table. The SCSI card is an old Adaptec, AIC-7880 and I believe it does not support automatic bad block detection/redirection. This disk came from a spares kits, so even though it is "new" and never used, it is still 5-6 years old. There were 6 bad blocks, once they were put in the bad block table, everything was fine. Is sformat the freebsd equivalent of the badtrk utility. I have always used Ultra2 LVD SCSI and higher on FreeBSD and have never had this issue of bad blocks. Is that because those newer SCSI disks and controllers have better ECC handling and take care of the bad blocks internally without notifying the user? -john On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: On Fri, 8 Oct 2004, Sergey Babkin wrote: Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
Mikhail P. wrote: Hi, This question probably has been discussed numerous times, but I'm somewhat unsure what really causes ATA failures.. I have pretty basic server here which has two IDE drives - each is 200GB. System is FreeBSD-5.2.1-p9 That server has been setup about 9 months ago, and just about 3 months ago my logs quickly filled up with: ad0: FAILURE - WRITE_DMA status=51 error=10 LBA=268435455 Hmm, that means that the drive couldn't find the sector you asked for. Now, what has me wondering is that it is the exact sector where we switch to 48bit adressing mode. Anyhow, I've just checked on the old Maxtor preproduktion 48bit reference drive I have here and it crosses the limit with no problems. What controller are you using ? not all supports 48bit mode correctly.. -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Saturday 09 October 2004 16:23, Dag-Erling Smørgrav wrote: > "Mikhail P." <[EMAIL PROTECTED]> writes: > > On Saturday 09 October 2004 15:01, Dag-Erling Smørgrav wrote: > > > A lot of them, or just one or two? Some ATA drives will spin down at > > > regular intervals to recalibrate, and you'll get a harmless timeout if > > > you try to write to the disk while it's doing that. > > > > Unfortunately, all the drives (so far - four 200GB drives). > > I meant "a lot of timeouts", not "a lot of drives". If you only get > one or two timeouts per drive at regular intervals (say, once a > month), they're just recalibrating and there's nothing to worry about. > Well, there is no pattern. Often it just happens by itself - system runs 3-10 days fine (no warnings, no timeouts), and after that time I start seeing lots of these. To be more exact, for example I have user who's home dir is /home/user; user uses FTP to upload/download files under that directory. Let's say he has 5k files in total (ranging in size from 1kb to 20mb), so what happens is that when user tries to access certain files (either to continue upload, or continue download of the file), system spews lots of these timeouts and basically "input/ourput error" occurs. For example, yesterday it showed 360 of these messages during 12 hour period, and unfortunately during the time I was sleeping system has locked itself - last message in /var/log/messages was regarding ad0 failure. I'm not exactly sure on which files it timed out yesterday, but I do know under which directory it happened - directory has 20k files in it (not in the single dir, but including subdirs). Maybe someone knows a quick way I could open every file in under that directory - this could probably help to identify exactly on which file timeouts happened. Before replacing the drives, I had that server up for 120 days, and it did spew these messages (more and more with every day, started on about 90th day of uptime count). After rebooting system, it asked for fsck, which I did run, but it showed some softupdates inconsistencies, and refused to mount /home in rw. By the way, I just ran fsck on rw mounted /home (that's where those timeouts occurred yesterday), and I have attached it's output. I also got another message off-list, where author suggested to play with UDMA values. I switched from UDMA100 to UDMA66. System's uptime is 12 hours, and no timeouts so far.. but I'm quite sure they will get back in few days. > BTW, are you using ataidle or anything similar? nope, nothing. > > DES regards, M. [EMAIL PROTECTED]:/usr/local/etc/rc.d> fsck /home ** /dev/ad0s1g (NO WRITE) ** Last Mounted on /home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT FILE I=8715003 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715004 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715005 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715006 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715007 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715008 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715009 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715010 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715016 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715017 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715080 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715086 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715087 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715093 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715094 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715100 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715101 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715107 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715129 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no LINK COUNT FILE I=8715142 OWNER=noc MODE=0 SIZE=0 MTIME=Oct 9 09:50 2004 COUNT 0 SHOULD BE -1 ADJUST? no
About the WARNS= knobs in our Makefiles
Hi folks, While traversing our code, I found that many of our code can survive WARNS=6 if they get some trivial changes. I think it would be beneficial if we have our code WARNS=6 clean because this will give better portability, and a more in-depth review of the code would be positive for better overral quality of them. Is there any efforts on this? Cheers, -- Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. pgpxJjybNSeSF.pgp Description: PGP signature
Re: ad0: FAILURE - WRITE_DMA
"Mikhail P." <[EMAIL PROTECTED]> writes: > On Saturday 09 October 2004 15:01, Dag-Erling Smørgrav wrote: > > A lot of them, or just one or two? Some ATA drives will spin down at > > regular intervals to recalibrate, and you'll get a harmless timeout if > > you try to write to the disk while it's doing that. > Unfortunately, all the drives (so far - four 200GB drives). I meant "a lot of timeouts", not "a lot of drives". If you only get one or two timeouts per drive at regular intervals (say, once a month), they're just recalibrating and there's nothing to worry about. BTW, are you using ataidle or anything similar? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Sat, 9 Oct 2004, Mikhail P. wrote: MP> > > I reloaded OS on the new drives, then restored all data from the old MP> > > drives. All seemed to be fine for 2 months now... but today I woke up, MP> > > and noticed these messages again. MP> > MP> > A lot of them, or just one or two? Some ATA drives will spin down at MP> > regular intervals to recalibrate, and you'll get a harmless timeout if MP> > you try to write to the disk while it's doing that. MP> MP> Unfortunately, all the drives (so far - four 200GB drives). MP> I'm having the previous two drives shipped here within two weeks. MP> Most likely these drives aren't corrupted actually.. will stress them locally MP> here. Well, I suppose Dag-Erling means 'lot of errors' as opposed to one or two raisen sporadically... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Saturday 09 October 2004 15:01, Dag-Erling Smørgrav wrote: > "Mikhail P." <[EMAIL PROTECTED]> writes: > > I reloaded OS on the new drives, then restored all data from the old > > drives. All seemed to be fine for 2 months now... but today I woke up, > > and noticed these messages again. > > A lot of them, or just one or two? Some ATA drives will spin down at > regular intervals to recalibrate, and you'll get a harmless timeout if > you try to write to the disk while it's doing that. Unfortunately, all the drives (so far - four 200GB drives). I'm having the previous two drives shipped here within two weeks. Most likely these drives aren't corrupted actually.. will stress them locally here. > > DES regards, M. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
"Mikhail P." <[EMAIL PROTECTED]> writes: > I reloaded OS on the new drives, then restored all data from the old drives. > All seemed to be fine for 2 months now... but today I woke up, and noticed > these messages again. A lot of them, or just one or two? Some ATA drives will spin down at regular intervals to recalibrate, and you'll get a harmless timeout if you try to write to the disk while it's doing that. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: please help with: warning: initialization makes integer from pointer
On Fri, Oct 08, 2004 at 12:25:45PM -0500, Sam wrote: > > Sick! > > > > Are there actually systems out there that don't have "all-zero" NULL pointers? > > > > You have officially shattered my previously held beliefs about the > > sacredness of memset :( > > If there are, I'd be interested to know of them. See the C Faq, question 1.14: http://www.lysator.liu.se/c/c-faq/c-1.html -Kurt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
On Fri, 8 Oct 2004, Sergey Babkin wrote: > Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries > to re-map the bad sectors (it tries to preserve data during this too, > unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. > > I do the full 14 pattern tests before I put a SCSI disk in service. > > When a disk starts losing blocks like this, usually they only multiply > over time. The best thing you can do is replace the disk and > move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hangups while using user-ppp.
Hello! I have an interesting problem. While I'm using user-ppp in about 2-3 minutes after start all system suddenly hangs up, but after 10-15 seconds it start running normally, and this hangup not repeat in this ppp session. What is can be? Bye. P.S. I'm using FreeBSD 5.2.1 on i386. Kernels are my own, and what is worse GENERIC. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hangups while using user-ppp.
Hello! I have an interesting problem. While I'm using user-ppp in about 2-3 minutes after start all system suddenly hangs up, but after 10-15 seconds it start running normally, and this hangup not repeat in this ppp session. What is can be? Bye. P.S. I'm using FreeBSD 5.2.1 on i386. Kernels are my own, and what is worse GENERIC. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
