HPET broken on Dell 1950's?
I have an old Dell 1950 that I've rescued from Linux and tossed a copy of -STABLE on it, but am seeing a constant 0.5 load average. With the system completely idle, and kern.eventtimer.timer=LACPI, the load drops to the expected value of zero. This feels like it should be an FAQ, but short of noting that the load is non-zero, is there a programatic way to determine if the event timer is broken? The system was functioning just fine, but it always had a constant load even when doing absolutely nothing. ? FreeBSD ops05.internal 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Tue Jul 24 17:56:59 UTC 2012 root@ops05.internal:/usr/obj/usr/src/sys/GENERIC amd64 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.timer: HPET kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 749769877 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC(-1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) dev.hpet.0.%desc: High Precision Event Timer dev.hpet.0.%driver: hpet dev.hpet.0.%location: handle=\_SB_.HPET dev.hpet.0.%pnpinfo: _HID=PNP0103 _UID=0 dev.hpet.0.%parent: acpi0 -- Sean Chittenden se...@freebsd.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: NFS server not respnding!
Using FreeBSD 4.6.2-pl2 and FreeBSD 4.7-RC2 on our server system (one 4.7-RC experimental system) and utilizing AMD for mounting home space and other services via TCP protocol results in nfs server 134.93.180.216:/usr/homes: not responding nfs server 134.93.180.216:/usr/homes: is alive again very often, when load of the appropriate client is very high. That happens when on our number crunching systems utilization of CPU time is high or many users try copy from and to via SAMBA to the main NFS server system. There's one setup that I maintain where I see this a lot. If I mount the ports dir with rw perms over NFS, _AND_ am using CVSup to update the ports, I can reliably crash the NFS server. I'm not sure if this is because I'm taxing the IDE drives too much or because there's some glitch in NFS someplace. Tuning and TCP vs UDP hasn't made a difference. I'm going to give netdump_client a shot here sometime soon and see if I can't get some kind of debugging info out of the kernel. As it stands, the system has 2GB of RAM and I only allocated 1GB to swap (which isn't ever more than 1% used). FWIW, why isn't netdump_client a part of the standard distro? Seems like an invaluable tool in debugging. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
/dev/null permission change from 4.3 - 4.4...
Howdy. This question was originally framed as a why doesn't uptime work for users in 4.4, when it used to in 4.3, but after looking into things further, it's now a why is /dev/null set to mod 0600? On a 4.3 system that I have, the perms on dev/null are 666. I've chmod'ed all of my boxen back to 0666, but... I'm curious as to why this happened and the rationale behind the change. I've observed this difference on at least 15 other 4.4 systems. What gives? -sc PS Build processes was: cd /usr/src make update make world make kernel KERNCONF=KERNNAME mergemaster -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: problems building mod_ruby
Update your ports and see if the problem persists. A new version of mod_ruby came out earlier today. -sc I can't seem to get mod_ruby to build, do to some problem with eruby. No matter weither eruby is installed or not, it seems to attempt to build it as a dependency every time. any help appreciated jason -- Sean Chittenden PGP signature
Re: Continuing ahc problems - also cause fxp failure
PCI to ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 pcib2: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard pci2: PCI bus on pcib2 fxp1: Intel Pro 10/100B/100+ Ethernet port 0xdcc0-0xdcff mem 0xf610-0xf61f,0xf6201000-0xf6201fff irq 5 at device 6.0 on pci2 fxp1: Ethernet address 00:d0:b7:7e:75:c3 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2: Intel Pro 10/100B/100+ Ethernet port 0xdc80-0xdcbf mem 0xf600-0xf60f,0xf620-0xf6200fff irq 14 at device 8.0 on pci2 fxp2: Ethernet address 00:d0:b7:7e:77:31 inphy2: i82555 10/100 media interface on miibus2 inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: NEC 72065B or clone 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: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console 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 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging disabled IPsec: Initialized Security Association Processing. IP Filter: v3.4.16 initialized. Default = pass all, Logging = disabled Waiting 5 seconds for SCSI devices to settle pass4 at ahc0 bus 0 target 6 lun 0 pass4: DELL 1x4 U2W SCSI BP 5.35 Fixed Processor SCSI-2 device pass4: 3.300MB/s transfers da2 at ahc0 bus 0 target 2 lun 0 da2: QUANTUM ATLAS V 36 SCA 0201 Fixed Direct Access SCSI-3 device da2: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 34732MB (71132998 512 byte sectors: 255H 63S/T 4427C) da3 at ahc0 bus 0 target 3 lun 0 da3: QUANTUM ATLAS V 9 SCA 0201 Fixed Direct Access SCSI-3 device da3: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da3: 8683MB (17783249 512 byte sectors: 255H 63S/T 1106C) da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST336704LC 0004 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST336704LC 0004 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C) cd0 at ahc1 bus 0 target 5 lun 0 cd0: NEC CD-ROM DRIVE:466 1.06 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 Mounting root from ufs:/dev/da0s1a WARNING: / was not properly dismounted To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Sean Chittenden PGP signature
