microuptime() went backwards?
I have dual pentium, and started lately to come to the console. microuptime() went backwards. I went over the list (hackers) and saw the last discussion on microuptime() which suggested to remove apm0. I have it disabled in my config (by default), but still I see these. APM is disabled in the bios. I had some problems 1 month ago, when this system didn't want to boot, and always was freesing at USBxx at the boot process, nomatter that usb?x didn't existed in the config??? and the usb devices were disabled by the bios. Any ideas on what should I do? Thank you very much for your time. Zvezdelin Vladov --dmesg-boot- Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6.2-RELEASE #0: Mon Aug 26 12:00:32 EEST 2002 [EMAIL PROTECTED]:/usr/src/obj/usr/src/sys/FIX-GW Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (548.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387fbff real memory = 536805376 (524224K bytes) avail memory = 518836224 (506676K 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 0xc032d000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 7 entries at 0xc00fdd10 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #0 intpin 18 -> irq 2 IOAPIC #0 intpin 19 -> irq 16 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pc i0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 Timecounter "PIIX" frequency 3579545 Hz chip1: port 0x5000-0x500f at devic e 7.3 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe400-0xe47f mem 0xe6001000-0xe6 00107f irq 2 at device 10.0 on pci0 xl0: Ethernet address: 00:50:da:51:16:d9 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xe800-0xe87f mem 0xe600-0xe6 7f irq 16 at device 11.0 on pci0 xl1: Ethernet address: 00:50:da:51:18:d1 miibus1: on xl1 xlphy1: <3Com internal media interface> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: at iomem 0xc-0xc7fff on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 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 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IP packet filtering initialized, divert enabled, rule-based forwarding enabled , default to accept, logging limited to 100 packets/entry by default DUMMYNET initialized (011031) SMP: AP CPU #1 Launched! ad0: 8063MB [16383/16/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s1a - config: - machine i386 #cpuI386_CPU #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident FIX-GW maxusers128 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options MAXDSIZ=(1024UL*1024*1024) options NMBCLUSTERS=65535 options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking #optionsINET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this! ] options MFS #Memory Filesystem #optionsMD_ROOT #MD is a potential root device #optionsNFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS requir ed options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 require d options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in
Re: microuptime() went backwards?
On Fri, Sep 20, 2002 at 10:50:34AM +, zvezdi wrote: > I went over the list (hackers) and saw the last discussion > on microuptime() which suggested to remove apm0. > > I have it disabled in my config (by default), but still I see these. > APM is disabled in the bios. Removing apm has a slightly different effect to disabeling it. I think if it is disabled it still has an effect on what timers are used. Try compiling it out of the kernel and see if that helps. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel ICC
On Thu, 19 Sep 2002 23:16:51 +0900 Hiroharu Tamaru <[EMAIL PROTECTED]> wrote: > Is this problem solved? I am now in the same situation. Just today. > It used to work fine for me before, when I run it on > PentiumII-450MHz/440BX. A few weeks ago, I upgraded the CPU and the > M/B to Pentium4-1.8GHz/i845, and now it stalls just as you describe. Add "options CPU_ENABLE_SSE" and it should work (it seems only P4s have this problem). Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: microuptime() went backwards?
David Malone writes: > On Fri, Sep 20, 2002 at 10:50:34AM +, zvezdi wrote: >> I went over the list (hackers) and saw the last discussion >> on microuptime() which suggested to remove apm0. >> >> I have it disabled in my config (by default), but still I see these. >> APM is disabled in the bios. > > Removing apm has a slightly different effect to disabeling it. I > think if it is disabled it still has an effect on what timers are > used. Try compiling it out of the kernel and see if that helps. > > David. I understand your point, but maybe there is some missunderstanding. I disabled in my BIOS and in my config file, as you can see in my previous e-mail. This as far as I can tell leaves no code for power management in the kernel. (via strings /kernel|grep -i apm, or strings /kernel | grep -i power ). It leaves however a code that detects the pci chipset. I don't if that is what you're talking about (detecting it at the pci level), but if it is that, I really don't know how to disable it. - One more thing, my HZ is set by default. I have heavy usage of DUMMYNET subsystem, and in the LINT it is said that I should make it more granullar(HZ=1000), but my expectaions are, this may worsen the situation. Am I right on my expectations? - Zvezdelin Vladov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel ICC
On Fri, 20 Sep 2002 13:20:30 +0200 Alexander Leidinger <[EMAIL PROTECTED]> wrote: > Add "options CPU_ENABLE_SSE" and it should work (it seems only P4s > have this problem). Ooops... add it to your kernel config of course... Bye, Alexander. -- Yes, I've heard of "decaf." What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libc_r in stable
Andriy, First of all thank you for your detailed reports, they could be very useful. Unfortunately, currently I am a bit busy due to participation in first Ukrainian OSS Conference, therefore it might be better to submit those reports to someone else - I'd recommend either Daniel Eischen <[EMAIL PROTECTED]> or Julian Elischer <[EMAIL PROTECTED]> (both CC'ed), who are FreeBSD libc_r gurys, and see if they could help you. Thanks! -Maixim Andriy Gapon wrote: > > Maxim, > > sorry if my English is not perfect, but I've decided to use it as more > offcial language of FreeBSD. > > I have recently been involved into debugging a complex program on FreeBSD > 4.6.2 (multiprocessed, multithreaded, signal handling, pipes and fifos for > communication) and based on that I've developed several concerns and ideas > about pthreads in 4.6.2. I'll start with the most obvious and proceed to > the ones that I'm not quite sure about. > > 1. write() doesn't set errno to EINTR if thread receives a signal while > being on a queue waiting for a data on a descriptor > > 2. in the case above, write() always returns -1 regardless of wheather it > was able to write part of data on previous attempts, I believe it should > return number of bytes written thus far > > 3. likewise, in the case "real" write() system call returns value < 0, > libc_r write() retruns the same value, although some data might have been > written on the previous attempts. > > 4. libc_r execve() sets all descriptors that were not set expicitely to > non-blocking mode to blocking mode before doing "real" execve, which is > good and done with non-multithreaded programs possibly being exec'ed in > mind. However, it has a painful effect if this is done as part of spawning > another process (fork+exec), obviously all descriptors in a parent become > blocking that effectively kills multithreading during IO. I think there is > no other option if a programmer really means to share descriptors between > a multithreaded and a singlethreaded program. However, in the case > close-on-exec flag is set on the descriptor, I think, it's better to leave > the descriptor as is, in the non-blocking mode. > > 5. I see that on SIGCHLD received descriptors are reset back to the > non-blocking mode with a comment that this is to undo possible setting > them to blocking state by a child. There is a number of concerns about > that: > a. what if not all of the singlethreaded child processes that > share descriptors with a multithreaded parent exited ? > b. SIGCHLD may be generated when a child process stops e.g. by ^Z > on a controlling terminal, when it continues the shared descriptors > will remain in the non-bloking state. > c. descriptor flags are reset to union of a saved explicitely set > value and O_NONBLOCK block flag. This may erase changes performed > by fcntl() in a child process, which in some exotic case may have > been ment to persist after the child exits. > > Frankly, I have no good ideas about 5, and obviously all problems with 4 > and 5 are there only if one mixes programs linked with libc and libc_r > into parent-child relationships and obviously there seems to be no perfect > solution for such situation, but maybe some improvements can still be > made. > > -- > Andriy Gapon > * > Hang on tightly, let go lightly. Andriy Gapon wrote: > > Maxim, > > in addition to my previous report: > > 6. open() from libc_r should add O_NONBLOCK to flags before executing > open() system call, but after saving actual flags value. > Otherwise, in the situations where system open() > blocks a whole calling process is blocked, where only a calling thread > should actually be blocked. Necessary retries (similiar to read() and > write()) should obviuosly be added too. Andriy Gapon wrote: > > -- Forwarded message -- > Date: Tue, 17 Sep 2002 13:29:08 -0400 (EDT) > From: Andriy Gapon <[EMAIL PROTECTED]> > To: Maxim Sobolev <[EMAIL PROTECTED]> > Subject: libc_r in stable (fwd) > > Maxim, > > in addition to my previous report: > > 6. open() from libc_r should add O_NONBLOCK to flags before executing > open() system call, but after saving actual flags value. > Otherwise, in the situations where system open() > blocks a whole calling process is blocked, where only a calling thread > should actually be blocked. Necessary retries (similiar to read() and > write()) should obviuosly be added too. > > -- End of forwarded message -- > > sorry about this one, didn't think it through. Looks like, although > current behaviour is not good enough, it is the only thing that can be > implemented non-intrusively, by userland means only. It's impossible to > properly emulate blocking open() via non-blocking open() for all possible > scenariosn alltogether: regular files, fifos/pipes, devices. > > -- > Andriy Gapon > * > Hang on tightly, let go lightly. To Unsubscribe: send mail to [EMAIL
Power Off and Ati Xpert 2000
Hello, I have an ATI Xpert 2000 Pro (Rage 128 Pro) installed. Once X windows had been started, power off (shutdown -p) doesn't work anymore. The system becomes idle after the uptime message. If shutdown -p is called without X had been started power off works. Also zzz works and the machine can be woken up by hitting a key. After once running X and then calling zzz the system can only be reset by the reset key. Superprobe yields: First video: Super-VGA Chipset: ATI (chipset unknown) (Port Probed) Signature data: 3f3f (please report) Memory: 0 Kbytes RAMDAC: Generic 8-bit pseudo-color DAC (with 6-bit wide lookup tables (or in 6-bit mode)) XFree is complaining about unresolved symbol drmFreeBufs and drmR128TextureBlit but is running somehow anyway. Symbol drmFreeBufs from module /usr/X11R6/lib/modules/drivers/r128_drv.o is unresolved! Symbol drmR128TextureBlit from module /usr/X11R6/lib/modules/drivers/r128_drv.o is unresolved! Is this essential? I have 4.6.2-RELEASE, XFree86-4.1.0_12,1, XFree86-Server-4.2.0_6 and XFree86-libraries-4.1.0_1. The kernel has: device apm0at nexus? flags 0x20 What are these apm flags for? Should I select a differnt flag combination? Which one? Or can I expect upgrading XFree86 and/or XFree86-libraries to solve the problem? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How can I access the special disk sector in kernel?
On Sep 17 at 18:25, kai ouyang spoke: > I want to read the 48th sector in ad0. in kernel space, if I use the > 'open' , 'lseek' , 'read' and 'close', it is wrong! Does `open' fail? How does it fail? NB: you're using charset=gb2312. Why not something like us-ascii? (This list is English.) -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for Review: syslogd
I made a small patch that extends the "!program" syntax so that you can
also specify not-this-program, in a manner similar to what is already
possible for hosts ("!+program" and "!-program"). Syslogd really ought
to be extended to support sets of programs and hosts, but this small
change should do for now (for me, at least).
The patch is at http://people.freebsd.org/~dcs/syslogd.diff, and a patch
for stable's present syslogd is at
http://people.freebsd.org/~dcs/syslogd.diff.stable.
(please cc me to any discussion on this, or I'll probably miss the message)
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
A work project expands to fill the space available.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
¢Íú¡Ç¹ mail ¢Í§¤Ø³ ªèÇ·ÓẺÊͺ¶ÒÁ ¢Íº¤Ø³ÁÒ¡¤èÐ
ẺÊͺ¶ÒÁà¡ÕèÂǡѺá¹Çâ¹éÁ¡ÒÃ·Ó§Ò¹ã¹»Õ 2002 1.¢³Ð¹Õé¤Ø³ ? ?¡ÓÅѧÈÖ¡ÉÒÍÂÙè ? ·Ó§Ò¹»ÃÐ¨Ó ?¡ÓÅѧËÒ§Ò¹ ? ¡ÓÅѧÈÖ¡ÉÒáÅÐ·Ó §Ò¹ä»´éÇ µÍº ... 2.¤Ø³¾Í㨡Ѻ§Ò¹ã¹»Ñ¨¨ØºÑ¹à¾Õ§㴠?? ¾Íã¨ÁÒ¡ ? »Ò¹¡ÅÒ§ ? àº×èͧҹ·Õè·ÓÍÂÙè µÍº ... 3. ¤Ø³¾Í㨡ѺÃÒÂä´é ³ »Ñ¨¨ØºÑ¹ËÃ×ÍäÁè ?? ¾Í㨠? äÁè¾Í㨠µÍº ... 4.¤Ø³µéͧ¡ÒÃÃÒÂä´éÊÙ§ÊØ´µèÍà´×͹㹪ÕÇÔµ¡Ò÷ӧҹà·èÒã´ ? ___ºÒ·/ à´×͹ µÍº ... 5.§Ò¹»Ñ¨¨ØºÑ¹ÊÒÁÒöãËéÃÒÂä´éµÒÁ¢éÍ 4 ËÃ×ÍäÁè ?? ä´é ? äÁèä´é µÍº ... 6.¤Ø³¤Ô´ÇèҤس(ËÃ×ͤÃͺ¤ÃÑÇ)ä´éÃѺ¼ÅµÍºá·¹¤ØéÁ¤èҡѺáç§Ò¹ËÃ×ÍäÁè ?? ¤ØéÁ¤èÒ ? ¤ÇÃä´éÃѺÁÒ¡¡ÇèÒ¹Õé µÍº ... 7.§Ò¹»Ñ¨¨ØºÑ¹¢Í§¤Ø³ (ËÃ×ͤÃͺ¤ÃÑÇ) ÁÕ¤ÇÒÁÁÑ蹤§ÁÒ¡¹éÍÂà¾Õ§㴠?? ÁÒ¡ ? ¹éÍ ? äÁèÁÑ蹤§ µÍº ... 8.¤Ø³µéͧãªéàÇÅÒ㹡ÒÃà´Ô¹·Ò§ä»·Ó§Ò¹ /àÃÕ¹à·èÒã´ (ä»áÅСÅѺ) ?? ·Ó§Ò¹·Õè ºéÒ¹ ? ¹éÍ¡ÇèÒ 1 ªÁ. ? 1-2 ªÁ. ? 2-3 ªÁ. ? ÁÒ¡¡ÇèÒ 3 ªÁ µÍº ... 9.¤Ø³¡ÓÅѧÁͧËÒÅÙè·Ò§ã¹¡ÒÃËÒÃÒÂä´é¾ÔàÈÉ·Õè¶Ù¡µéͧáÅÐÁÑ蹤§ÍÂÙèãªèäËÁ ?? ãªè ? äÁèãªè µÍº ... 10.¤Ø³µéͧ¡ÒÃÁÕ¸ØáԨÊèǹµÑÇËÃ×ÍäÁè ?? µéͧ¡Òà ? äÁèµéͧ¡Òà ? ÁÕ¸ØáԨÍÂÙèáÅéÇ µÍº ... 11.¤Ø³ÁÕ¤ÇÒÁÃÙé·Ò§´éÒ¹ Internet ËÃ×ÍäÁè ?? ÁÕ¤ÇÒÁÃÙéà»ç¹ÍÂèÒ§´Õ ? ÁÕ¤ÇÒÁÃÙéºéÒ§ ? äÁèÁÕ¤ÇÒÁÃÙéàÅ µÍº ... 12.¤Ø³ÃÙé¨Ñ¡Ãкº¡Ò÷ӧҹ¨Ò¡·ÕèºéÒ¹ ËÃ×ÍäÁè ?? äÁèÃÙé¨Ñ¡ ? ÃÙé¨Ñ¡ 0¨Ò¡_ µÍº ... 13.¤Ø³Ê¹ã¨¡ÒÃͺÃÁáÅÐàÃÕ¹ÃÙé "ÇÔ¸Õ¡ÒÃÊÃéÒ§ÃÒÂä´é¨Ò¡¡Ò÷ӧҹ·ÕèºéÒ¹" â´ÂäÁèàÊÕ ¤èÒãªé¨èÒÂËÃ×ÍäÁè ?? ʹ㨠..¡ÃسÒàÅ×Í¡àÇÅÒ·Õè¤Ø³Êдǡ㹢éÍ 14 ? äÁèʹ㨠. .¢Íº¤Ø³¤èÐ ·ÕèãËé¤ÇÒÁÃèÇÁÁ×Í㹡ÒõͺẺÊͺ¶ÒÁ¢Í§àÃÒ µÍº ... 14.àÇÅÒã´µèÍ仹ÕéÊдǡ·ÕèÊش㹡Ò÷Õè¤Ø³¨Ðà¢éÒÃѺ¡ÒÃͺÃÁ¢Í§àÃÒ ? ? Íѧ¤Òà - 18:30 ¹. - 20:00 ¹.? ¾ÄËÑʺ´Õ - 18:30 ¹. - 20:00 ¹. ? àÊÒÃì - 12:30 ¹. - 14:00 ¹.? Í×è¹æ â»Ã´ÃкØ__ 15. ¤Ø³¾Ñ¡ÍÂÙè㹡ÃØ§à·¾Ï ËÃ×ͨѧËÇÑ´__ µÍº ... ª×èÍ ÍÒÂØ »Õ ÍÒªÕ¾ ..â·Ã àÇÅÒÊдǡ㹡ÒõԴµèÍ Please unsubscribe sent mail to [EMAIL PROTECTED]
poweroff_delay, kproc_shutdown_wait
Hello, what do kern.shutdown.poweroff_delay and kproc_shutdown_wait affect? Do they have something to do with APM poweroff? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: poweroff_delay, kproc_shutdown_wait
On 20-Sep-2002 Hanspeter Roth wrote: > Hello, > > what do kern.shutdown.poweroff_delay and kproc_shutdown_wait affect? > Do they have something to do with APM poweroff? My guess is that the poweroff_delay applies to APM/ACPI power off delay. kproc_shutdown_wait determines how long we wait for the various system processes to shut down. When you shut down the machine and it says "Waitinf 60 seconds for blah-blah to shutdown...", that 60 seconds is what kproc_shutdown_wait sets. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poweroff_delay, kproc_shutdown_wait
On Sep 20 at 16:37, John Baldwin spoke: > My guess is that the poweroff_delay applies to APM/ACPI power off delay. It seems these are the number of miliseconds after the uptime message. Default seems to be 5000. But why not 1000 or less? Or can it be that even 5000 is too few? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libfetch bug.
On Mon, Sep 16, 2002 at 09:37:21PM -0700, Alfred Perlstein wrote: > libfetch seems to have a bug such that if a disconnect happens at > a particular point it spins in a tight loop. > > I tracked it down to this fix: I'm still seeing this. Have you heard anything from DES? If not, please go ahead and commit the fix. Kris msg36967/pgp0.pgp Description: PGP signature
Re: libfetch bug.
* Kris Kennaway <[EMAIL PROTECTED]> [020920 14:46] wrote: > On Mon, Sep 16, 2002 at 09:37:21PM -0700, Alfred Perlstein wrote: > > libfetch seems to have a bug such that if a disconnect happens at > > a particular point it spins in a tight loop. > > > > I tracked it down to this fix: > > I'm still seeing this. Have you heard anything from DES? If not, > please go ahead and commit the fix. committed, thanks! -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
temperature monitoring
This is probably common question, but I was wondering if there is any temperature monitoring mechanisms out there; specifically for ABit motherboard (KG7). I found a "consolehm" project in sysutils, but it seems to require a /dev/smb0 device... ConsoleHM uses the SMBus Driver for PIIX4 provided by Takanori Watanabe to gather information from hardware sensors to provide motherboard temperature, fan speeds and voltage readings on the console. Thanks... Clark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: temperature monitoring
I've has a lot of luck with (x)mbmon from uh, misc I think (or is it sysutils?) He has a new version out that you should also check out.. not sure if there is a port yet.. On Fri, 20 Sep 2002, Clark C. Evans wrote: > This is probably common question, but I was wondering if there > is any temperature monitoring mechanisms out there; specifically > for ABit motherboard (KG7). > > I found a "consolehm" project in sysutils, but it seems to > require a /dev/smb0 device... > > ConsoleHM uses the SMBus Driver for PIIX4 provided by > Takanori Watanabe to gather information from hardware > sensors to provide motherboard temperature, fan > speeds and voltage readings on the console. > > > Thanks... > > Clark > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel ICC
At Fri, 20 Sep 2002 13:20:30 +0200, Alexander Leidinger wrote: > > On Thu, 19 Sep 2002 23:16:51 +0900 Hiroharu Tamaru > <[EMAIL PROTECTED]> wrote: > > > Is this problem solved? I am now in the same situation. > > Just today. > > > It used to work fine for me before, when I run it on > > PentiumII-450MHz/440BX. A few weeks ago, I upgraded the CPU and the > > M/B to Pentium4-1.8GHz/i845, and now it stalls just as you describe. > > Add "options CPU_ENABLE_SSE" and it should work (it seems only P4s have > this problem). Oh, brilliant! I'll reconfig the kernel and try it out as soon as I can have this system down for maintenance. Thanks for the tip! Maintainer of icc port added to CC. A message in the post-install target should be nice.. Here is the preceeding message for your reference. At Thu, 19 Sep 2002 23:16:51 +0900, Hiroharu Tamaru wrote: > > Hello, > > Is this problem solved? I am now in the same situation. > It used to work fine for me before, when I run it on PentiumII-450MHz/440BX. > A few weeks ago, I upgraded the CPU and the M/B to Pentium4-1.8GHz/i845, > and now it stalls just as you describe. AFAIR, I haven't cvsuped the src > nor the ports in between. I deinstalled linux_base and icc and > reinstalled them via the ports, but nothing changed. > > linux_base-7.1_1 > icc-6.0.139_1 > > Please keep me in the CC. I'm not subscribed to this list. > > On Wed, 31 Jul 2002 13:15:46 -0600 (MDT), > Barkley Vowk <[EMAIL PROTECTED]> wrote to [EMAIL PROTECTED]: > > > I've got a demo system from intel, and I'd really like to see how much of > > an improvement I can get from the intel compiler. However, after > > installing the port, running ICC gets me this: > > > > icc -o hello hello.c > > > > 4601 bvowk 64 0 8984K 6812K RUN3 10:17 98.08% 56.20% mcpcom > > > > Which tells me that we're going wrong somewhere. I've heard of people > > having good luck with this compiler, I don't know where we're broken. Any > > ideas? > > > > I'm running a fresh 4.6-R, Dual Xeon with the multithreaded magic. > > -- > Hiroharu Tamaru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Hey Baby!
Free Adult Entertainment http://www.xrah.com 18+ only To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel - Modules and Compiled in
In message: <20020915203835.GA3497@gallium> Dominic Marks <[EMAIL PROTECTED]> writes: : disadvantages: : some drivers need to be able to allocate a large chunk of contiguous : memory to operate correctly, this means some drivers cant work when not : compiled in to the kernel (because they dont get their request for a : block of memory in early enough). this is false. If you load the module from the boot loader there is no difference between that and having it be actually compiled into the kernel in terms of resource allocation. However, this is true if you intend to load the drivers at some time later than boot. : I was thinking about this recently, : perhaps if the kernel allocated a chunk of memory early on in the boot : process (amount configurable via sysctl) then this could be chopped up : and handed to modules specifically, there is probably a good reason why : this isnt possible (?) which has not occured to me, because it seems like : the common sense solution. Actually, this issues get gross in a hurry, which is why no one has done it. :-( I have very few drivers actually compiled into my kernel on my laptop. I run everything else via loadable drivers. This works mostly well, although sometimes I hit the driver issue that you alluded to above when I load them at run time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Direct video access
Greetings, I have been doing graphics programming in Windows for a few years, and am interested in broadening my horizons. I'm interested in attempting to get FreeBSD to switch video modes and gain access to video memory, perhaps to attempt a simple OpenGL-like implementation or the like, entirely foregoing xfree86 and mesa. Which card would I be best off using? I currently have an nvidia geforce256, but understand nvidia is fairly hush-hush about how their hardware works. I know nvidia is about to release an xfree86 module, but I'm not too interested in using xf86. I hear ATI is somewhat more open about the technical details of their cards. For this card, where should I look to get details of the interface? I really know nothing about talking directly to hardware, but am eager to learn. I am assuming all cards have a standard set of commands to do things like set video modes and possibly even things like hardware accelerated lines and such, but I imagine things like matrix multiplications and transformations, blitting, etc, are all proprietary. I know DOS uses a set of interrupts to change video modes, and a static address for the framebuffer, but I'm assuming this isn't the case with FreeBSD. If it *is* a static address, would I then have to be running in kernel mode to access such an address? Is this the inappropriate list for questions like this? freebsd-multimedia looks more like userland type stuff... thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
