Re: Machine is 'hanging'.
It is rumoured that Stefan Schmidt had the courage to say: > i have got a problem with a router running FreeBSD 3.4-REL: > Every three days or so it hangs, whiche means that the console is not > responding any more, open tcp ports don't respond == are timing-out just > like they're filtered. I guess the machine is just unable to start a > shell. Oh and well it is appearently able to route as the machines behind > it are reachable, and it does repond to pings. Are you by any chance running SMP? I am having very similar problems with -current (time to die is approx 10 days) on a box which does firewalling and nat. And by the way, I do have DDB in my kernel, but the hang is really hard. The box just freezes and there's no way to get to the debugger. Even serial console is dead. Regards, Dave Boers. -- Dave Boers < djb @ relativity . student . utwente . nl > Don't let your schooling interfere with your education. (Mark Twain) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current hangs HARD
Hi all, I have been having HARD -current hangs recently and they don't seem to be going away by cvsupping. I've been having two complete lockups (i.e. no response from X, network or serial terminal; no crashdump no whatsoever), which occured both times after approximately 10 days of uptime. The two hangs occurred with differently dated -currents. It seems to be repeatable... My configuration is an Abit BP6 with two 400 Mhz celerons (NO overclocking), and an ATA66 disk. FreeBSD relativity.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb 7 22:46:30 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RELATIVITY5 i386 I have no idea what is causing the lockups, does anyone have similar experiences (so far I only read about lockups that occurred more often than once every 10 days or so). I can provide access to the machine and its logfiles, though I doubt that they are very useful (don't contain any obvious hints to what's causing these lockups). One last note: I didn't have these lockups before January 2000. Please, can someone shed some light on this? Regards, Dave Boers. -- Dave Boers < djb @ relativity . student . utwente . nl > Don't let your schooling interfere with your education. (Mark Twain) > DMESG < Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Mon Feb 7 22:46:30 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RELATIVITY5 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127033344 (124056K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc02fe000. Preloaded elf module "vesa.ko" at 0xc02fe09c. VESA: v3.0, 7936k memory, flags:0x1, mode table:0xc02fb102 (122) VESA: NVidia Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: mem 0xe600-0xe6ff,0xe400-0xe4ff irq 16 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 ata-pci0: port 0xf000-0xf00f at device 7.1 on pci0 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 7.2 intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 ed0: port 0xa400-0xa41f irq 19 at device 9.0 on pci0 ed0: address /* deleted */, type NE2000 (16 bit) ahc0: port 0xa800-0xa8ff mem 0xeb00-0xeb000fff irq 18 at device 11.0 on pci0 ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs pci0: unknown card (vendor=0x10b7, dev=0x9055) at 13.0 irq 17 ata-pci1: port 0xb800-0xb8ff,0xb400-0xb403,0xb000-0xb007 irq 18 at device 19.0 on pci0 ata2 at 0xb000 irq 11 on ata-pci1 ata-pci2: port 0xc400-0xc4ff,0xc000-0xc003,0xbc00-0xbc07 irq 18 at device 19.1 on pci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0: at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: on sbc0 unknown0: at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0 unknown1: at port 0x100 on isa0 unknown2: at port 0x200-0x207 on isa0 unknown3: at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 unknown4: at port 0-0xf,0x81-0x83,0x87,0x89-0x8b,0x8f-0x91,0xc0-0xdf drq 4 on isa0 unknown5: at port 0x40-0x43 irq 0 on isa0 unknown6: at port 0x70-0x71 irq 8 on isa0 unknown: can't assign resources unknown: can't assign resources unknown7: at port 0xf0-0xff irq 13 on isa0 unknown8: at iomem 0-0x9,0xfffe-0x,0xfec0-0xfec0,0xfee0-0xfee0,0x10-0x7ff on isa0 unknown9: at iomem 0xf
Unknown panic in yesterday's -current
Hi everyone, I just had a strange panic with yesterday's current: FreeBSD relativity.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Fri Jan 28 16:15:13 CET 2000 root@:/usr/src/sys/compile/RELATIVITY5 i386 A backtrace seems impossible (but I'm inexperienced with kgdb and I'm also currently at work): djb@relativity:RELATIVITY5# gdb -k kernel /var/crash/vmcore.2 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... SMP -1071755716 cpus IdlePTD 146061567 initial pcb at 291320 panic messages: --- dmesg: cannot read PTD --- cannot read proc pointer at ff84 (kgdb) bt #0 0x0 in ?? () (kgdb) where #0 0x0 in ?? () (kgdb) up No stack. (kgdb) The number of cpu's is supposed to be 2. If some more experienced/enlightened individual wishes to look into this, I have the crashdump on my system and I can provide (ssh) access. Please contact me. The panic seems to have been triggered by the killall command (executed as a user). Regards, Dave Boers. -- Dave Boers < djb @ relativity . student . utwente . nl > Don't let your schooling interfere with your education. (Mark Twain) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
It is rumoured that Devin Butterfield had the courage to say: > I too notice these problems of mpg123 skipping during disk activity or X > graphics ops but I have always had these problems, both with -STABLE and > -CURRENT. I notice this with xmms too. So this is nothing new. Isn't this simply a typical issue of IDE hardware? I too notice xmms skipping on heavy disk activity (typically the find command that runs from cron at 01:59). This happens even though I have two processors and a disk that can do 16 Mb/sec on UDMA66. One would expect such a system to be able to do a find and play mp3's simultaneously. However, AFAIK the IDE hardware typically handles only one request at a time and handles all requests sequentially, contrary to scsi. It may thus happen that the read requests from xmms, small as they may be, get delayed too long and unnecessary. I'm not an expert on this, but I believe scatter/gather is the way scsi handles this problem in hardware. Perhaps the ata driver could be made to do something similar on the driver level. I have experienced significantly better responsiveness during high disk usage of much slower systems that are running with scsi disks only. In fact, I have a 486 that has better response times (it has an EISA bus and adaptec 2740 scsi with a disk that can do -- and does! -- 8 Mb/sec disk->memory) than my Abit BP6 dual celeron UDMA66 system during the cron job at 1:59. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: softupdates still broken!
It is rumoured that Peter Wemm had the courage to say:
> Warning: softupdates is still falling over quite easily:
> (I run with INVARIANTS)
>
> initial pcb at 31f9e0
> panicstr: softdep_lock: lock held by 412
> panic messages:
> ---
> panic: softdep_disk_write_complete: lock is held
>
> syncing disks... panic: softdep_lock: lock held by 412
> Uptime: 3m17s
I second that. Same panic, system can't even stay alive for more than 3
minutes after booting. Same version of ffs_softdep.c: 1.49.
Regards,
Dave Boers.
Backtrace is below. Can someone please confirm that I did this the
right/wrong way? This _is_ a first time experience for me ;-)
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.1
(kgdb) core-file /var/crash/vmcore.1
SMP 2 cpus
IdlePTD 3125248
initial pcb at 27ea80
panicstr: from debugger
panic messages:
---
panic: softdep_disk_write_complete: lock is held
mp_lock = 0101; cpuid = 1; lapic.id = 0100
panic: from debugger
mp_lock = 0102; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 2m1s
dumping to dev #ad/0x20001, offset 786432
dump ata2: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110
109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88
87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62
61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10
9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
#1 0xc0150a01 in panic (fmt=0xc0225df4 "from debugger") at
../../kern/kern_shutdown.c:554
#2 0xc012e219 in db_panic (addr=-1071679891, have_addr=0, count=-1, modif=0xff80dd8c
"")
at ../../ddb/db_command.c:433
#3 0xc012e1b9 in db_command (last_cmdp=0xc025261c, cmd_table=0xc025247c,
aux_cmd_tablep=0xc027abc8)
at ../../ddb/db_command.c:333
#4 0xc012e27e in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc0130307 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc01f73b4 in kdb_trap (type=3, code=0, regs=0xff80de94) at
../../i386/i386/db_interface.c:158
#7 0xc0209c98 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi =
-1019691216, tf_esi = 256,
tf_ebp = -8331556, tf_isp = -8331584, tf_ebx = -1071415552, tf_edx =
-1071028128, tf_ecx = 16777217,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071679891, tf_cs = 8,
tf_eflags = 582,
tf_esp = -1071362429, tf_ss = -1071469038}) at ../../i386/i386/trap.c:531
#8 0xc01f766d in Debugger (msg=0xc022ae12 "panic") at machine/cpufunc.h:64
#9 0xc01509f8 in panic (fmt=0xc0237f00 "softdep_disk_write_complete: lock is held")
at ../../kern/kern_shutdown.c:552
#10 0xc01b01d8 in softdep_disk_write_complete (bp=0xc338bf30) at
../../ufs/ffs/ffs_softdep.c:2993
#11 0xc0172776 in vfs_backgroundwritedone (bp=0xc338bf30) at ../../kern/vfs_bio.c:710
#12 0xc0174ba3 in biodone (bp=0xc338bf30) at ../../kern/vfs_bio.c:2712
#13 0xc01d8582 in ad_interrupt (request=0xc0b83900) at ../../dev/ata/ata-disk.c:624
#14 0xc01d590e in ataintr (data=0xc09ca100) at ../../dev/ata/ata-all.c:624
#15 0xc02127fd in intr_mux (arg=0xc07329c0) at ../../i386/isa/intr_machdep.c:569
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Still system hangs, but different
It is rumoured that Dave J. Boers had the guts to say: > I'll leave the system running for a few more hours and then I will enable > softupdates again to try if I can reproduce the problems and take a look > with DDB. The system has been running with softupdates enabled and DDB in the kernel for 18 hours now without a single problem. I'm sorry to say that no matter how hard I try, I can't seem to reproduce the hang (make -j 30 buildworlds while doing du -ks / on 16 Gb of files work flawlessly). Pascal Hofstee informed me that he is also unable to reproduce the hang since he put DDB in his kernel (he had one occurence of the hang the day before yesterday). Since version 1.49 of ffs_softdep.c has been committed, I will move on to that and leave DDB in my kernel just in case. I guess this ends the thread. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still system hangs, but different
Matt, Like I said, I disabled softupdates on all my filesystems (and added DDB to the kernel). The system has been running 7 hours smoothly now, that's the longest uptime I've had so far with version 1.47 of ffs_softdep.c. I even recreated the directory that I couldn't delete previously and now I don't have any problems with it any more. I guess this proves that the problems I was having _were_ softupdates related. I'll leave the system running for a few more hours and then I will enable softupdates again to try if I can reproduce the problems and take a look with DDB. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still system hangs, but different
On Tue, Jan 11, 2000 at 07:54:33PM -0800, Matthew Dillon wrote: > Wait a sec. I've reviewed all the messages from you and I think something > got mixed together. I'm not convinced that your particular problems > are softupdates related. I recommend turning off softupdates entirely > for a few days to find out. Hmmm, interesting. I wonder what makes you think that. Could you elaborate? > I recommend enabling DDB in the kernel config. The next time it locks > up switch to the console (if you were in X) - which should work - and > then ctl-alt-esc into DDB. From there do a 'ps' and see if any processes > are stuck in weird states. Allright. I've included options DDB and KTRACE in my kernel. I will disable softupdates on all my filesystems and let the system run for a while. We'll see what happens. Besides, if the SCSI problem and these latest system hangs seem related to you, then please note that the SCSI related hang was of an altogether different nature (complete system hang instead of just i/o) and (important) I've removed the SCSI disk from the system (and put in into another system for separate testing) before I ever had version 1.47 of ffs_softdep.c. I've not seen any log messages from the scsi driver since I removed the drive. My system is and has always been running primarily from my IDE disk, though /usr/src and /usr/obj used to reside on the scsi disk. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still system hangs, but different
On Tue, Jan 11, 2000 at 10:21:48AM -0800, Matthew Dillon wrote: > Everyone, make sure you are using at least version 1.47 of > ffs_softdep.c. I have. > I think there may still a problem but I haven't been able to reproduce > it yet. Don't know if this helps, but the problem seems to occur only after a certain uptime or a certain amount of i/o operations for that matter. My uptimes are typically about 6 hours before it happens. I've had two occurences of it and both times it happend while mutt was working on some large mailfiles (20 Mb or so). Once it was sorting a file and the other time it was sending a message and immediately afterward rereading the "outbox" file. It's a bit difficult to do anything like gdb or ps once it happens, because disk i/o is impossible. Once I had a running top and saw that mutt remained in the "wait" state. I have noticed that other i/o related things go awry sometimes also with version 1.47 of ffs_softdep.c. I once couldn't "rm -fR" a build tree no matter how hard or often I tried. The rm process just hung. I had to reboot an old kernel just to delete the build tree. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still system hangs, but different
On Tue, Jan 11, 2000 at 01:10:10PM +0100, Dave J. Boers wrote: > So I guess some problems still remain. replying to self here I have had the second occurence of the hang and I can provide some more information this time. The thing that hang's is disk i/o. The system continues to work correctly but does not repond to any form of i/o. Therefore, logins, top, kill, incoming mail, whatever requires disk i/o doesn't work. I left the system in this state for 15 minutes, but no error messages, nor kernel panic. The disk drive light was OFF. The only thing that helps is the reset button. Is there something in some sort of infinite loop here? This is an SMP system with the ATA driver and with Kirk's latest softupdates changes included. See my previous mail for more uname -a. Regards, Dave Boers. P.S. I have to go now, but I will try if I can compile a kernel with debugging in it and see if I can make a backtrace (would be my first one ever) this evening. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Still system hangs, but different
Hi All, After cvsup last night: FreeBSD relativity.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Ja n 11 04:48:17 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compi le/RELATIVITY4 i386 which includes the latest softupdates changes, I still experience random system hangs, however not the same as I used to have. While the hang occured there was X11 running and mutt was in the middle of saving its mailfile (it was at 99%) and stopped responding. I killed mutt (which worked!) and reran it, closed it, ran tin and then everything hung completely. Strangely enough X continued working (things like mouse pointer, moving windows etc) but I couldn't open or close xterms. Logging in by telnet or on serial console was also impossible. After a few minutes I decided I had to do a hard reset. So I guess some problems still remain. Regards, Dave Boers. P.S. FWIW: I'm _not_ running vinum, I _am_ running softupdates and I use the ahc SCSI driver and ATA driver. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
On Mon, Jan 10, 2000 at 03:35:47PM +0100, Christian Carstensen wrote: > this is funny: > the system operates well, even when on heavy load (especially disk load), > until i want a little more 8). to become more precisely, a cvs checkout or > make world is no problem, if - and that's really interesting - nothing > else requests the system's attention. i've had some successfully reproducable > crashes when generating much i/o usage (cvs, buildworld), which in fact > caused no problem, and then simply starting pine. at the moment, pine > opened the mail folder, all my noisy hard disks stopped and it was > perfectly quiet apart from cpu fans. That sounds exactly like the very dead state I found my system in when it hang (I only have one occurence, so far, but my system isn't under very heavy load lately). Make -j 9 buildworld completes fine. The hang seems to have occured during a simple 20 Mb transfer of email data from my ide to my scsi disk (which is a very short but i/o intensive operation). There might have been an incoming email at the same time. I will try an idiotic buildworld -j 30 this evening just to see wether I can hang the system reproducibly. Have to go now, however. Regards, Dave Boers. -- Fatal error: replace user and try again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
On Mon, Jan 10, 2000 at 04:48:08AM +0100, Christian Carstensen wrote: > i'm using a ahc 7895 onboard on a tyan thunder 100. i've seen my cdrom > occasionally not coming up until power cycling. is this a known bug with > that controller? Mine is an AIC 7860 (i.e. 2940UA). I see my hard disk failing to come up occasionally, but only after I turn my power on after the system had been turned completely off (which is not often). > scsi performance is very bad on my system for a long time now. operating > on many small files, for example, my IBM DCAS-34330W is 100% busy with > only 1.2 MB/s. > i don't know why, but i suspect vinum in combination with some old scsi > devices to cause that. What I'm going to say here may be complete crap, but it has been on my mind for some time now, so I may just as well speak up with my suspicions. I have read on several occasions that people find -current performing very poorly lately. I recall someone comparing -current's network performance to that of 3.4 and finding almost a factor 2 difference. I myself have found the following facts lately: 1) scsi performance is down to 4 Mb/sec MAX, writing simply zero's (this used to be around 12 Mb/sec) 2) network performance (NIC = 3COM 3C905B-TX 100Mbit) is 5 Mb/sec MAX instead of the 8 Mb/sec I'm used to. 3) IDE UDMA66 performance is down to 12 Mb/sec writing zero's (this used to be near 16 Mb/sec). 4) buildworlds are at an all time slow. I haven't been able to compile a current in less than an hour for many weeks now. This used to be more like 40 minutes or so (make buildworld -j 9 on my smp system). Add to this the strange lockups we've been having recently that somehow seem i/o or load dependent. I'm no expert on this at all, but it seems legitimate to conclude that something is seriously wrong somewhere. It seems to me that this should _definitely_ get sorted out to the bottom before release time. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
On Mon, Jan 10, 2000 at 04:10:37AM +0100, Christian Carstensen wrote: > this runs stable for 3 hours now... > try a current kernel (checked out 4 hours ago), using a version of the > file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok, maybe it's not by any > means stable, but works better than everything else within the last 24 > hours. Actually, I've booted a kernel from just before newyear (28 december) which works _reasonably_ fine (although it's the same kernel that gave me the lockup earlier) with a userland of today. Problem is that the lockups (I think) are ahc-related and my SCSI hard drive did refuse to come online on one or two occasions while booting the system cold... I therefore concluded that it might be a problem with the hardware. Now (with the new kernel) I find the scsi system unstable and I have doubts again. One piece of information might also be useful in this context. After the system lockup I sort of benchmarked the scsi performance by doing "dd if=/dev/zero of=./testfile bs=100 count=128" (actually I varied the blocksize) and got a _very poor_ performance of only 4 Mb/sec (which is usually around 10 to 12 Mb/sec). I isolated my drive to be the only scsi device and I even clocked the SCSI bus down from 20 Mhz to 8 Mhz, but to no avail. In the mean time, I disconnected my scsi hard drive and I am running from my IDE disk. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
On Mon, Jan 10, 2000 at 12:43:49AM -, Joao Pedras wrote: > it just... freezes! Can any of you tell me wether you have SCSI in your system (the ahc driver, perhaps)? I too had one of these strange lockups today (see earlier post) and it seems SCSI related. The lockup occured during an I/O operation. Now I cvsupped and I find the ahc driver panic-ing on boot time with a parity error as well. I was actually on the verge of concluding that it had to be a hardware error, but doubts begin to raise again... Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange SCSI related system hang
Hi all, This morning I had a very strange (at least I've never seen it before) SCSI related system hang. The system simply stopped responding at 9:30:03 am this morning. I found it in this state at 13:20. It had been hanging _hard_. No response to console, serial terminal or network. After a hard reset the system came back online normally and is working normally again. Note that the machine had an uptime of 4 days, 14 hours before the problem occured and it never happened before. Could this be a hardware problem? > uname -a: FreeBSD relativity.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Dec 30 21:42:21 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/RELATIVITY3 i386 > Here's the relevant system log messages: Note that all these messages occur at xx:30:00 or xx:30:01. That's probably related to a cron job which runs every half hour and copies some files (about 20 Mb) from my IDE disk to my SCSI disk. When the system is idle, there's usually no other SCSI activity. Jan 9 04:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 04:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 04:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 04:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 04:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 04:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 04:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 04:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 04:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 04:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 04:30:01 relativity /kernel: ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET Jan 9 06:30:00 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 06:30:00 relativity /kernel: SEQADDR == 0x151 Jan 9 07:30:00 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 07:30:00 relativity /kernel: SEQADDR == 0x151 Jan 9 07:30:00 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 07:30:00 relativity /kernel: SEQADDR == 0x151 Jan 9 07:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 07:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 07:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 07:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 07:30:01 relativity /kernel: ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET Jan 9 07:30:01 relativity /kernel: SAVED_TCL == 0x0, ARG_1 == 0x9, SEQ_FLAGS == 0x0 Jan 9 07:30:01 relativity /kernel: ahc0: Bus Device Reset on A:0. 1 SCBs aborted Jan 9 08:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 08:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 08:30:01 relativity /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 9 08:30:01 relativity /kernel: SEQADDR == 0x151 Jan 9 09:30:03 relativity /kernel: (da0:ahc0:0:0:0): Invalidating pack > Here's my complete dmesg output: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Thu Dec 30 21:42:21 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/RELATIVITY3 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Celeron (450.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127238144 (124256K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc02d2000. Preloaded elf module "vesa.ko" at 0xc02d209c. VESA: v3.0, 7936k memory, flags:0x1, mode table:0xc02cf102 (122) VESA: NVidia Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 16 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 ata-pci0: at device 7.1 on pci0 ata-pci0: Busmastering DMA supported pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 7.2 intpm0: at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 ed0: irq 19 at device 9.0 on pci0 ed0: address 00:20:18:2d:d5:2b, type NE2000 (16 bit) ahc0: irq 18 at device 11.0 on pci0 ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs pci0: unknown card (vendor=0x10b7, dev=0x9055) at 13.0 irq 17 ata-pci1: irq 18 at device 19.0 on pci0 ata-pci1: Busmastering DMA supported ata2 at 0xb000 irq 11 on ata-pci1 ata-pci2: irq 18 at device 19.1 on pci0 ata-pci2: Busmastering DMA supporte
Re: compiling libF77/libI77
On Tue, Jan 04, 2000 at 10:23:37PM +0100, Dave J. Boers wrote: > Can anyone tell me how to compile and install libF77/libI77 from > /usr/src/contrib/libf2c please? Or, for that matter, the whole libf2c? (reply to self...) It's funny how I tend to find things out only just _after_ I asked someone else (not that I didn't spend an hour going through /usr/src _before_ I sent in my email). Just found out that they are combined into /usr/lib/libf2c.a. So, never mind my question. Regards, Dave Boers. -- True Music was born with Johann Sebastian Bach. It died with Anton Bruckner while he was working on his nineth symphony. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
compiling libF77/libI77
Hi, Can anyone tell me how to compile and install libF77/libI77 from /usr/src/contrib/libf2c please? Or, for that matter, the whole libf2c? I need the libraries and the ones from netlib won't compile. Is there some way to include building the libraries in a standard make buildworld? Thanks a lot, Dave Boers -- True Music was born with Johann Sebastian Bach. It died with Anton Bruckner while he was working on his nineth symphony. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: troubles with X
On Thu, Dec 30, 1999 at 04:43:47PM -0600, Thomas T. Veldhouse wrote: > Here is the answer I was given by somebody on this list last week. > > #/etc/pam.conf > # tricky tricky forgive me > xserver authsufficient pam_permit.so no_use > # If we don't match anything else, default to using getpwnam(). > other authrequiredpam_unix.so > try_first_pass > other account requiredpam_unix.so > try_first_pass Great! That fixed it. Thanks a lot, Dave Boers. P.S. Sorry for not picking this up from the list myself. -- [EMAIL PROTECTED] be afraid, . . . be *very* afraid To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: troubles with X
On Mon, Dec 27, 1999 at 06:28:02PM -0600, Steve Price wrote: > For some reason now I can't startx(1) as either myself or root. > I type startx and the PAM auth routines loop forever printing > out 'Password:'. I comment out the last two lines in /etc/pam.conf > and I get an authentication failure (as I should). I'm having the same problem. Cvsupped and recompiled -current just a few hours ago. Then I recompiled X 3.3.5 and installed it. Now I can't start X anymore either. Lines containing "Password:" just keep scrolling over my terminal. The password lines are being generated by xinit. Just plain "X" works. > Anyone have any ideas what I'm doing wrong? What is the correct > method to start X on -current nowadays? AFAIK you're doing it correctly. Can someone PLEASE help out here? It's getting a bit annoying. Regards, Dave Boers. -- [EMAIL PROTECTED] be afraid, . . . be *very* afraid To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
On Tue, Dec 21, 1999 at 11:22:12PM +0100, Thierry Herbelot wrote: > Let's start a thread on the BP6 ? (the release of the board was > carefully synchronized with stable SMP releases of FreeBSD : kudos to > the FreeBSD release engineering team ;-)) I second that! Running -current since October and never had a serious SMP problem. > I've also got one of these babies (dual 460 @ 2.1V) and I'm wondering if > I should buy a new PSU (300W, instead of the present 250W) - the > reliability is not yet up to par with my ancient (??) P-II (I've got a > crash after a row of "make buildworld"s). Hmm, I only had one nasty kernel panic once during installworld, but I don't think that was hardware related. I must have done at least 50 buildworld's or so since beginning of October; no crashes. My main system is running dual 450 Mhz. Like I said earlier in the thread, it's running on a 300 Watt PS with a couple of extra fans to cool the hard drives, two 7200 RPM disks, 2 network i/f's, scsi, CD reader and writer, tape unit and zipdrive. I think the PS is pressed to its limits because if I add just one more drive (5400 RPM IDE disk) it's over the edge. Those Celeron's must be eating lot's of power (they are 400 Mhz ones running at 75 Mhz bus speed). > Is it possible to directly boot from the HPT-366 controller ? (I know > the BIOS is ok, but is there any problem with the new ata driver ?) I'm doing it currently. The HPT-366 controller is a completely separate device. On my bootup, the system doesn't detect any "normal" ide devices (you can't autotype them in the bios either), then the screen goes blank and the HPT comes up with its disk detection. Next is the Adaptec detection and the boot proceeds. In the BIOS you can choose EXT=[ATA,SCSI] and I have the boot sequence set to EXT,C,A. EXT=ATA. The ATA driver nicely autodetects (from dmesg): ata-pci1: irq 18 at device 19.0 on pci0 ata-pci1: Busmastering DMA supported ata2 at 0xb000 irq 11 on ata-pci1 ata-pci2: irq 18 at device 19.1 on pci0 ata-pci2: Busmastering DMA supported ad0: ATA-4 disk at ata2 as master ad0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, UDMA66 I would like to know how HOT other people's processors get. In the stationary situation I have a system core (= processor average) temperature of 46 and a case temperature of 50 degrees Celcius/Centigrade. Don't ask why case temperature is higher than core temperature! I don't get it either. The hard drives are not even above 30 degrees. Maybe it's the graphics board (viper 550 agp): it's doing 1600x1200@85Hz. I once clocked the system at 500 Mhz (83 Mhz bus), which runs fine but then things get way too hot. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Sat, Dec 18, 1999 at 08:44:42PM +0100, Soren Schmidt wrote: > There is no way to see if the disk was in suspend mode, you can > give it a command and se how long it takes before it comes back :) > > The problem here is that it takes the command and OK's it, but it > takes the spinuptime + overhead before the answer comes, and then > the driver already timed out. I am under the impression that the drive does not need to do ADM if it is shutdown once every six days. So can't we go with phk's solution: make a cron job that shuts down and powers up the drive once every six days? Regards, Dave. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
On Sat, Dec 18, 1999 at 07:27:16AM +0100, Thierry Herbelot wrote: > Do you boot from the UDMA66 drive ? Yes. Bios boot sequence is EXT,C,A; where EXT is set to UDMA66, not SCSI. The SCSI disk is a 4.3 Gb WD Enterprise on an Adaptec 2940AU board. > What is your BIOS revision ? Award Bios v. 4.51PG Revision line (bottom of screen) sais: 06/08/1999-i440BX-W83977-2A69KA1SC-LP Highpoint Bios: HPT 366 v. 1.07 > How many SDRAM DIMMs do you use ? Currently there is one 128 Mb DIMM in the first slot. In a few weeks I will add a 256 Mb DIMM in the second slot, if I can get my hands on one (memory prices are going down again). > What is the rating of your Power supply ? Not quite high enough :-( It's a 300 Watt power supply. > Do you use an AGP graphics board ? Yes. It's a diamond Viper 550 with 8 Mb RAM. > (I also have a BP6 and I'm mildly satisfied by its stability up to now, > I'm looking for ways to upgrade it and hints to increase the > reliability) I haven't got any complaints about the BP6, actually. It runs quite nicely here. Exactly what are your complaints about it (i.e. why do you say "mildly" instead of "wildly")? Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Success with ATA drivers and UDMA66
Hi all, I just wanted to let you know that I enabled UDMA66 (by plugging in an 80 conductor cable) on my WDC AC418000D today. The mainboard is an ABit BP6 with builtin Highpoint HPT366 ATA controller. The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). If someone wants me to do some specific testing, let me know. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 04:50:55PM -0600, Richard Seaman, Jr. wrote: > Check http://www.storage.ibm.com/techsup/hddtech/prodspec/djna_spw.pdf > If a command is received during spin down of ADM, the drive quits the spin down > and tries to complete the command as soon as possible. > In case the spin down of ADM is disturbed by a command, it is retried 12 hours > later. That sure sounds like my 12 hours. I guess this more or solves the mystery. There is still one thing which keeps me wondering, though. How exactly does the ata driver react to the drive doing ADM? Whenever I hear it spinning down, I immediately hear it spinning up again. Does this mean that the ATA driver won't allow the drive to do _any_ ADM at all? Is that a bad thing? Regards, Dave Boers -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 03:02:24PM +0100, Soren Schmidt wrote: > Uhm, that wont be new WD drives, as they are exactly the same as > IBM drives give or take the label :) Huh? That I didn't know. So you're saying that WD and IBM 18 Gb disks are the same hardware? My disk: ad0: ATA-4 disk at ata0 as master ad0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, UDMA33 I would *love* to hear more about that. Can you point me to some info? Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 07:10:46AM -0600, Richard Seaman, Jr. wrote: > Dec 15 19:01:02 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting > Dec 15 19:01:02 test /kernel: ata0: resetting devices .. done > Dec 16 07:01:24 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting > Dec 16 07:01:24 test /kernel: ata0: resetting devices .. done ...and again there is almost precisely 12 hours in between... That's the same as I find time and again. I noticed that you are using IBM disks, whil my disk is a WD. The only common denominator seems to be the fact that we are both using -current with ATA drivers and that we are both running UDMA33. Regards, Dave Boers -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 03:29:30PM +0600, Max Khon wrote: > hi, there! > same here, dmesg output: > > ata_command: timeout waiting for interrupt > Mounting root from ufs:/dev/ad0s2a > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done > ata0-master: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. done Could you tell met the exact time on which these messages occurred? Anywhere near 10:15 or 9:15 ? Regards, Dave Boers. -- God, root, what's the difference? [djb,bofh,coredump,root]@relativity.student.utwente.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 09:36:42AM +0100, Soren Schmidt wrote: > One more thing, do you have SMART enabled in your BIOS ??, if so > turn it off, and see if that changes anything... I don't recall having it enabled; but I will check to make sure as soon as I get home from work (which is still some 10 hours away ). Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 08:29:14AM +0100, Soren Schmidt wrote: > It seems Devin Butterfield wrote: > > I just recently compiled a kernel with the new ATA driver and have > > discovered a problem: if I run sysinstall, right when it says "probing > > devices, please wait (this can be a while)" error messages saying... > [snip] > > and after printing these messages a number of times, sysinstall will > > finally come up. If I quit sysinstall and then run it again, probing > > goes well and there are no timeouts. The interesting thing is that I can > > reproduce this problem by rebooting and running sysinstall. So, this > > only happens when running sysinstall for the first time after a boot. > > > Hmm, I'd put my disks on different channels, but thats just for > performance sake. I'm currently trying every wierd setup I can > imagine with the HW I have for testing, but I havn't been able > to get any of my test setups to exhibit this behavior... > > But I'm working on it... I am still having "disc contact lost messages" regularly too. I've been posting about them on several occasions some time ago. I haven't been able to pinn it down, however. IF they occur, they occur somewhere between 9:15 and 9:20 a.m. OR p.m. But they don't always. This used to be 10:15, but that changed _some weeks after_ the change of daylight saving time. I can't seem to relate it to anything. It is unlikely that it's a power glitch, because the system has been displaying the problem with two different UPS's. The machine is running current current's which are regularly updated. It's an ABIT BP6 and the disk causing problems is a WD 7200 RPM 18,2 Gb disk running UDMA33. It's the only IDE disk in the system; the other disks are all SCSI. The system is running 24/7. Other details were posted earlier. There are two important aspects of the problem: 1. The problem does not always occur: it's unpredictable 2. When it occurs, I can actually hear the disk spinning down and then up again. I haven't been able to find any relevant information at www.wdc.com. I am also not sure if it is a hardware problem, however since I never noticed the problem with the wd0 driver (which I used some months ago). Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata - disk "contact" lost....
On Thu, Oct 21, 1999 at 05:41:40PM +0200, Erik H. Bakke wrote: > Here is the patch as I got it. > I can't give you any guarantees of anything, though, but it should be worth > a try. > If it solves your problem, drop a message on -current and let us know. Thanks for the patch. I applied it, recompiled this morning and for the occasion I copied my /usr/src to my ide disk (it usually resides on my scsi disk) and I did a "make -j 12 buildworld" to put some strain on the disk. I haven't seen the problem again, so I guess this solves the problem. The patch doesn't seem to have any negative side effects on my system. Thanks again, Dave. -- Dave J. Boers [EMAIL PROTECTED] I will *NOT* read email sent to Graduate student of Theoretical Physics [EMAIL PROTECTED] -> FreeBSD: The Power to Serve .http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata - disk "contact" lost....
I've been having strange problems with the ata drivers (again). At seemingly random moments "disk contact" seems to be lost. I've been seeing these messages before a few weeks ago. The problem is *not* there if I use the wd drivers. Also the problem seems only to appear after a few days of uptime. Below follows the info. Any help would be much appreciated. Should I worry about disk integrity? If you need more info, please let me know. Best regards, Dave Boers. -- Dave J. Boers [EMAIL PROTECTED] I will *NOT* read email sent to Graduate student of Theoretical Physics [EMAIL PROTECTED] -- *** uname -a: FreeBSD relativity.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #1: Mon Oct 18 10:53:01 CEST 1999 root@:/usr/src/sys/compile/RELATIVITY1 i386 *** uptime: 10:33AM up 3 days, 1:37, 7 users, load averages: 0.04, 0.03, 0.00 NOTE: the messages below are the *only* ones since the boot of the system three days ago. Also, the messages are (to within a minute) twelve hours apart. It is unlikely that there is some sort of power glitch; the system is hooked up to an ups. Finally, the messages appeared when the machine was idle. Power management is turned off of course. *** /var/log/messages: Oct 20 22:06:39 relativity /kernel: ata0-master: ad_timeout: lost disk contact - resetting Oct 20 22:06:51 relativity /kernel: ata0: resetting devices .. done Oct 20 22:06:51 relativity /kernel: ata0-master: ad_timeout: lost disk contact - resetting Oct 20 22:06:51 relativity /kernel: ata0: resetting devices .. done Oct 20 22:06:51 relativity /kernel: ata0-master: ad_timeout: lost disk contact - resetting Oct 20 22:06:51 relativity /kernel: ata0: resetting devices .. done Oct 20 22:06:51 relativity /kernel: ata0-master: ad_timeout: lost disk contact - resetting Oct 20 22:06:51 relativity /kernel: ata0: resetting devices .. done Oct 20 22:06:51 relativity /kernel: ata0-master: ad_timeout: lost disk contact - resetting Oct 20 22:06:51 relativity /kernel: ata0: resetting devices .. done Oct 21 10:07:24 relativity /kernel: ata0-master: ad_timeout: lost disk contact - resetting Oct 21 10:07:24 relativity /kernel: ata0: resetting devices .. done *** bootup: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Fri Oct 15 14:33:44 CEST 1999 root@:/usr/src/sys/compile/RELATIVITY1 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Celeron (450.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 134152192 (131008K bytes) avail memory = 126935040 (123960K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc030e000. Preloaded elf module "vesa.ko" at 0xc030e09c. VESA: v3.0, 7936k memory, flags:0x1, mode table:0xc030b102 (122) VESA: NVidia Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 16 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 ide_pci0: at device 7.1 on pci0 chip1: at device 7.2 on pci0 intpm0: at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 ed0: irq 19 at device 9.0 on pci0 ed0: address 00:20:18:2d:d5:2b, type NE2000 (16 bit) ahc0: irq 18 at device 11.0 on pci0 ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs pci0: unknown card (vendor=0x10b7, dev=0x9055) at 13.0 irq 17 pci0: unknown card (vendor=0x1103, dev=0x0004) at 19.0 irq 18 pci0: unknown card (vendor=0x1103, dev=0x0004) at 19.1 irq 18 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): wd0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE Prob
Re: Abit's BP6 and 'lmmon' or 'chm'
On Mon, Oct 11, 1999 at 06:44:50PM +0700, Nickolay Dudorov wrote:
> Does anybody successfully use ports/sysutils/{lmmon|chm}
> with the Abit's BP6 motherboard ?
> II only receive:
> IOCTL: device not configured
> from lmmon and chm.
I have the same problem with the 'wmhm' port. I also have Abit BP6 with two
450 Mhz Celerons.
Dave.
--
Dave J. Boers
[EMAIL PROTECTED] I will *NOT* read email sent to
Graduate student of Theoretical Physics [EMAIL PROTECTED]
-> FreeBSD: The Power to Serve .http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm oddity
On Fri, Sep 24, 1999 at 11:52:26PM -0400, Wes Morgan wrote: > I noticed a little quirk in the pcm driver -- it is reversing the channels > in my sb16! The first couple times I play a certain mp3 that starts out > (normally) in the left channel, it plays correctly in the left channel. > Then suddenly it will switch, and start out in the right channel. > My kernel is -current as of late sept 22. Can anyone else duplicate this? Hi, I can reproduce your findings. I run regular buildworld every few days. I have been having this problem for at least two weeks (and possibly before, I have been away for a few months and was stuck with Irix). An easy way to reproduce the problem is to start x11amp and hit play several times. I also found several other "quirks" in the pcm driver while I was programming: 1. If I read() from /dev/dsp in 16 bits single channel mode, I get rubbish even if the mic and igain mixers are set to zero. If I read some 8 bits single channel data just before you read the 16 bits data, the problem disappears. Seems to be an initialization problem. 2. Reading large blocks from /dev/dsp (like 8192 bytes), generates a kernel panic (uiomove failed). Cutting down the blocksize to 256 bytes appears to solve the problem. Maybe something overflowing or a timing problem. 3. If I change the mixer setttings using ioctl() calls for /dev/dsp, then the settings for /dev/mixer do not change accordingly. I have an original Sb16 PnP. I am running smp for dual celeron on an Abit mainboard. Maybe someone wants to look into this, as I don't have any device driver programming experience (and little time to learn also). Best wishes, Dave. -- Dave J. Boers [EMAIL PROTECTED] I will *NOT* read email sent to Graduate student of Theoretical Physics [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
