Re: Cursor (trackpoint) creep with moused?
Barney Wolff writes: On Thu, Aug 29, 2002 at 04:52:42PM -0400, Andy Sparrow wrote: I'm just curious as to why this might be - the trackpoint creep, that is - does anyone have any ideas? :-) I've experienced the same effect on a Toshiba laptop running W2k, so perhaps it's the device, not anything fbsd-specific. Some of my colleagues have seen this on their Dell notebooks running W2K Win XP. One of them has had the entire keyboard assembly replaced, twice, because of this problem. S, I would say it's likely to be a hardware problem. -- Raymond WikerMail: [EMAIL PROTECTED] Senior Software Engineer Web: http://www.fast.no/ Fast Search Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Problems with FreeBSD - causing zalloc to return 0 ?!
Hiya all, We've been troubled by Fatal trap 12's for a little while now. The machine was running 4.6 perfectly, until I decided to try a cvs up to RELENG_4_6 about a week ago. Then it started to crash alot, we went back to RELENG_4. And there were no problems there. But then we decided to send in an error report http://www.freebsd.org/cgi/query-pr.cgi?pr=42046 and went back to RELENG_4_6 After going through alot of testing, kernel testing, and other funny things we decided to end the testing and go back to RELENG_4... Voila... The problems where now resident in that CVS Tag also. We have found a working workaround by adding the following to the kernel config: options INVARIANTS options INVARIANT_SUPPORT running the kernel with GENERIC instead of our custom kernel makes the system panic alot faster. It would seem that zalloc return's 0 when it shouldn't be able to do that. There are more incidents like this at several other machines that were upgraded at the same time. Anyone know of a better workaround than using INVARIANTS? Mvh/Best regards, Arnvid L. Karstad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
/etc/fstab - uid=?
Hi! I apologize for this rather stupid question, but mount on FreeBSD is a bit different comparing to mount on Linux. I need to mount one filesystem with the ownership of some UID other than root. On Linux I could put uid=xx, gid=yy in /etc/fstab after 'rw' option, but FreeBSD doesn't seem to have that option. Can someone give me a hint how it's done under FreeBSD. Mario Pranjic, dipl.ing. sistem administrator Knjiznica, Institut Rudjer Boskovic - e-mail: [EMAIL PROTECTED] ICQ: 72059629 tel: +385 1 45 60 954 (interni: 1293) - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Updating world with least downtime
Thus spake Kevin Oberman [EMAIL PROTECTED]: For a modern system and a reasonable disk, this is trivial. I have a system which MUST not be down for over 15 minutes and I can do it quite easily unless I really fumble something in mergemaster. I do always merge a few files later and tend to install most changes very quickly, having ode the same upgrade on a non-critical system just before I do the critical one so I know what to expect. The actual installworld time on my 1GHZ system is about 5 minutes (5:34 last time). Nice record. There ought to be a better solution than ``run mergemaster really fast and hope nothing goes wrong,'' though. For example, you could use mergemaster with -D on a copy of /etc and commit the copy in single user mode. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Cursor (trackpoint) creep with moused?
Toshiba trackpoints will ocasionally recalibrate themselves, which manifests as about 5 seconds of creep - longer if you try and fight it :). Exactly - this in fact, was what I was doing, which I've only realised since I understood the underlying mechanism. As soon as I noticed the creep, I'd both become acutely aware of it, and try to compensate for it - which made it persist. When I first saw this, I thought that the trackpoint hadn't correctly returned to a neutral position, so I'd try to provide input and hope that it would, in fact, center itself (and at least I'd keep the mouse near where I wanted it to be). I seem to have never lost this habit - which is, of course, precisely what you /shouldn't/ do, if the hardware is to compensate for some bias. Now, in fact, I'm having fun with it. I can provoke it at will by gently applying pressure in a single direction. After a few seconds, it notices that there's an inbuilt bias, and the creep will stop - at which point, releasing the pressure gives a creep in the opposite direction, which similarly lasts for a few seconds before it corrects again. At least on toshiba my porteget 300CT and 320CT laptops lthis is so, and I hear from many other toshiba users that this is 'normal'. As for minutes of creep (the original poster mentioned it fixing itself after 45 seconds...) Heh. This would appear to be some kind of time dilation effect due to irritation. It certainly doesn't take that long now... Thanks all! AS msg49235/pgp0.pgp Description: PGP signature
Periodic: support for non-sendmail MTAs
Hi, I noticed that /etc/periodic/daily/500.queuerun uses a sendmail-specific command line -Ac. Some installations use Postfix and it does not understand this command line. --- francis a. vidal [bitstop network services] | http://www.bitstop.ph streaming media + web hosting | http://www.keystone.ph v(02)330-2871,(02)330-2872; f(02)330-2873 | http://www.kuro.ph To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Periodic: support for non-sendmail MTAs
francisv I noticed that /etc/periodic/daily/500.queuerun uses a francisv sendmail-specific command line -Ac. Some installations use francisv Postfix and it does not understand this command line. Set: daily_submit_queuerun=NO in /etc/periodic.conf. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Periodic: support for non-sendmail MTAs
francisv Some installations use Postfix and it does not understand francisv this command line. I don't think MTAs except sendmail use this script. Instead, create your own periodic scripts under /usr/local/etc/periodic or some other places. It would be better ports/mail/postfix does that, but it's just a ports issue. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: OpenOffice problems on 4.6.2
On Sat, 2002-08-31 at 02:34, Jerry A! wrote: : $ ./soffice : ELF interpreter /compat/svr4/lib/ld-linux.so.2 not found : Abort trap : ELF interpreter /compat/svr4/lib/ld-linux.so.2 not found : [1] 1256 Abort trap ./soffice : $ Uhh, SVR4?! Looks like brandelf is needed to mark the binaries as the right type. I haven't had any problems building OO 1.0.1_3. Remember you need a valid DISPLAY variable set to install though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Periodic: support for non-sendmail MTAs
in message [EMAIL PROTECTED], wrote Gregory Neil Shapiro thusly... Set: daily_submit_queuerun=NO in /etc/periodic.conf. ah, i was wondering about that that setting it in /etc/rc.conf doesn't do much. thanks. - parv -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Latest kernel panic, second server ...
Aug 30 23:39:41 jupiter /kernel: Fatal trap 12: page fault while in kernel mode Aug 30 23:39:41 jupiter /kernel: mp_lock = 0002; cpuid = 0; lapic.id = Aug 30 23:39:41 jupiter /kernel: fault virtual address = 0xdf9c Aug 30 23:39:41 jupiter /kernel: fault code = supervisor read, page not present Aug 30 23:39:41 jupiter /kernel: instruction pointer= 0x8:0xc01e6bab Aug 30 23:39:41 jupiter /kernel: stack pointer = 0x10:0xf9b3ed7c Aug 30 23:39:41 jupiter /kernel: frame pointer = 0x10:0xf9b3ed84 Aug 30 23:39:41 jupiter /kernel: code segment = base 0x0, limit 0xf, type 0x1b Aug 30 23:39:41 jupiter /kernel: = DPL 0, pres 1, def32 1, gran 1 Aug 30 23:39:41 jupiter /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Aug 30 23:39:41 jupiter /kernel: current process= 71960 (gzcat) Aug 30 23:39:41 jupiter /kernel: interrupt mask = none - SMP: XXX Aug 30 23:39:41 jupiter /kernel: trap number= 12 Aug 30 23:39:41 jupiter /kernel: panic: page fault Aug 30 23:39:41 jupiter /kernel: mp_lock = 0002; cpuid = 0; lapic.id = Aug 30 23:39:41 jupiter /kernel: boot() called on cpu#0 Aug 30 23:39:41 jupiter /kernel: Aug 30 23:39:41 jupiter /kernel: syncing disks... 159 8 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 Aug 30 23:39:41 jupiter /kernel: giving up on 3 buffers Aug 30 23:39:41 jupiter /kernel: Uptime: 2d10h19m18s Aug 30 23:39:41 jupiter /kernel: amr0: flushing cache...done jupiter# nm -n /kernel | grep c01e6bab jupiter# nm -n /kernel | grep c01e6ba jupiter# nm -n /kernel | grep c01e6b c01e6b24 t vm_map_entry_create c01e6b68 T vm_map_lookup_entry c01e6bd4 T vm_map_insert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Problems with FreeBSD - causing zalloc to return 0 ?!
Okay, I've setup this script on both my (un)STABLE servers, and will report after the next crash ... which shouldn't take long :) On Fri, 30 Aug 2002, Matthew Dillon wrote: :Is there any definite way of determining this? From what I can find int :he man page, VNODES have to do with the file system and directory lists :... my last two crashes look to be related to the file system itself, so :have started to watch the VNODE numbers to, but is there some way of :determining what I should raise, and where? If you can get to a DDB prompt on the crash (kernel config w/ DDB) do this: ddb print *kernel_vm_end And tell me what you get. Also note the fault address. In order to really track down the cause I need a vmcore and kernel.debug to play with, but baring that you might be able to dump memory statistics to a file like once a second until the machine crashes. while (1) sleep 1 date stats.log vmstat -m stats.log vmstat -z stats.log netstat -m stats.log fsync stats.log end :I'm running 4Gig of RAM and Dual CPU over here, so having a swap device :large enough to 'dump core' is kinda out of the question, so I can't :provide any more infomration that i have so far in other messages :( If you can reproduce the crash with less memory you may be able to generate a core. To boot the machine with less memory add a line to your /boot/loader.conf file: hw.physmem=768m I usually always keep such a line in my loader.conf file, commented out (e.g. #hw.physmem=...) until I need it, because I always forget the name of the variable :-) :And, also, should any 'server class' operating system be more graceful :about such things? Some sort of soft limit that triggers it to refuse new :processes or something when its hit, so that it doesn't actually crash? :Kinda like the NMBCLUSTERS warning/error message when its set too low? FreeBSD-current will be far more graceful, but FreeBSD-stable is still using algorithms based on circa 1990 system memory capacities. As memory capacities have grown larger then available KVM the algorithms have been less able to cope with the massive number of resources that can now be cached. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
