Re: Unusable PS/2 mouse
Greg Lehey writes: ISTR there was a fix for this committed recently. Have you tried updating to a really recent -CURRENT? I'm using current cvsupped on last Sunday. Kazutaka YOKOTA writes: One is Logitech mouse support in the psm driver. The psm driver had been unable to handle some wheel mice models, including Logitech M-S48, until recently. It was fixed about a week ago both in -CURRENT and -STABLE. So, you should now be able to use your Logitech mouse, detected as MouseMan+, without the flags 0x100. My mouse works very well without the switch box. 2/3 button PS/2 mouse. If you don't switch between computers, I guess you won't have a problem. (But, this defeats the reason why you want to have the switch box in the first place!) If I don't switch between computers mouse won't work either. Probably this switch is just badly designed so it will drain all needed voltage from wire. Tomppa -- Sun Microsystems Oy PL 102, Niittymäentie 9, 02201 Espoo, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soft-updates feedback
Have you checked your syslog to see if you are getting disk errors? Also, I noticed that you have a VIA chipset and I know that at least with the Bt848 driver they have caused havoc. I would stick to Intel PCI chipsets. Not sure if your motherboard supports or not do you have the latest microcode for your VIA chipset? Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Aurel VORTEX Sound Card
Dose anybody install sound card Diamond Monster Sound II (based on Aurel VORTEX chipset) and make it propertly work ? Tell me how you did it, pls! -- Mike Ju. Volkov AKA Commander [EMAIL PROTECTED] tel.: 232-3644 ICQ# 5173328 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lockmanager panic
I think I'm up to date :) ... Unfortunately I won't be able to try out your fix until this evening :( ... Cheers, Andrew. -- $ ident swap_pager.c swap_pager.c: $Id: swap_pager.c,v 1.121 1999/07/16 05:11:35 alc Exp $ $ grep BUF_KERNPROC swap_pager.c BUF_KERNPROC(bp); BUF_KERNPROC(bp); On Mon, 19 Jul 1999, Kirk McKusick wrote: Date: Mon, 19 Jul 1999 21:59:51 -0700 From: Kirk McKusick [EMAIL PROTECTED] To: "Atrens, Andrew (A.B.) [EXCHANGE:SKY:1U33:BNR]" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: lockmanager panic Please be sure that you are running with vm/swap_pager.c at version 1.120 or later. In particular, you should have two calls to the macro BUF_KERNPROC in that file. If you are missing those two calls, you will get the panic. If you do have those two calls in that code, then (and *only* then) try the following patch to see if it helps. It is making use of BUF_KERNPROC for cases in which it is not intended, but if it gets around your current problem, then gives a good indication of what to look for as a real fix. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Soft-updates feedback
FWIW, I have a VIA chipset in my machine that is running -STABLE and I don't have such problems. I don't know if I have the same chipset as you tho, as I'm not at the machine to check my dmesg. I put an decent about of stress on the drives and don't seem to have any lockups at all, slowdowns yes, lockups no. I have the VIA MVP3 chipset, and my 2 of my drives are in DMA mode and one is in PIO mode. -Chris -Original Message- From: Amancio Hasty [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, July 20, 1999 3:13 AM To: [EMAIL PROTECTED] Cc: Julian Elischer; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Soft-updates feedback Have you checked your syslog to see if you are getting disk errors? Also, I noticed that you have a VIA chipset and I know that at least with the Bt848 driver they have caused havoc. I would stick to Intel PCI chipsets. Not sure if your motherboard supports or not do you have the latest microcode for your VIA chipset? Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panics on my SMP system
:Hi there, : : I recently had a crash on my SMP system. Actually, I have had a :number of crashes over the past six months, but have just recently had :time to configure the system to get the crash dumps. Like a good :citizen, I filed a problem report (kern/12127). I have now gotten :another crash. I have attached the backtrace from the crash dump. If :you refer to kern/12127, you will get all of the gory details about my :setup.I would like to know two things. Should I file a separate :problem report for this crash? Second, is there somewhere that I :should upload the vmcores and the kernel.debug for the relevant :developer to examine? : :Thanks, : -Reggie How old is your -CURRENT source tree ?Fixes to the pipe code have been made, though they are not 100% complete. If your -CURRENT source tree is more then a few days old I recommend updating it. A number of significant reliability fixes have gone in, including fixes to the pipe code and fixes to certain atomic operations that weren't atomic. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message [EMAIL PROTECTED], "Steven G. Kar gl" writes: During the boot process I see dumpon: crash dumps to /dev/da0s1b (4, 131073) checking for core dump...savecore: can't find device 13/131073 It seems that the the major device number is reset from 4 to 13. troutmask:kargl[225] swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/#B13:0x200015118720 511872 0%Interleaved Yes, all dev_t's which make it out of the kernel have cmajor numbers now. Try this change to savecore: /ddname = find_dev/s/BLK/CHR/ -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
According to Poul-Henning Kamp: In message [EMAIL PROTECTED], "Steven G. Kar gl" writes: During the boot process I see dumpon: crash dumps to /dev/da0s1b (4, 131073) checking for core dump...savecore: can't find device 13/131073 It seems that the the major device number is reset from 4 to 13. Yes, all dev_t's which make it out of the kernel have cmajor numbers now. Try this change to savecore: /ddname = find_dev/s/BLK/CHR/ Thanks, Poul. I forgot to mention that this is after a "make world" and new kernel from today (1000 PST). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
:dumpon: crash dumps to /dev/da0s1b (4, 131073) :checking for core dump...savecore: can't find device 13/131073 : : It seems that the the major device number is reset from 4 to 13. : : Yes, all dev_t's which make it out of the kernel have cmajor : numbers now. : : Try this change to savecore: : : /ddname = find_dev/s/BLK/CHR/ : : :Thanks, Poul. : :I forgot to mention that this is after a "make world" and new kernel :from today (1000 PST). : :-- :Steve A checklist for people who want kernel cores: * make sure that dumpdev is set to point to your swap partition in your /etc/rc.conf * make sure your swap partition is large enough to hold the crash dump. If you have 256MB of ram, your swap partition must be at least 256MB in size. * make sure /var/crash has sufficient space to hold the dump (note: /var/crash *can* be a softlink to a directory in some other partition if /var does not have sufficient space) /var/crash must nominally have sufficient space to hold the crash dump (a file of the same size as the amount of memory you have), *and* the kernel image. Normally you give it a lot more space so you store several crash dumps in it at once. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
According to Matthew Dillon: :dumpon: crash dumps to /dev/da0s1b (4, 131073) :checking for core dump...savecore: can't find device 13/131073 : : It seems that the the major device number is reset from 4 to 13. : : Yes, all dev_t's which make it out of the kernel have cmajor : numbers now. : : Try this change to savecore: : :/ddname = find_dev/s/BLK/CHR/ : : :Thanks, Poul. : :I forgot to mention that this is after a "make world" and new kernel :from today (1000 PST). : A checklist for people who want kernel cores: [Matt's check list deleted which I meet] /var/crash must nominally have sufficient space to hold the crash dump (a file of the same size as the amount of memory you have), *and* the kernel image. Normally you give it a lot more space so you store several crash dumps in it at once. Matt, AFAICT, the problem is due to the translation of /dev/da0s1b to major and minor numbers. dumpon takes /dev/da0s1b and translates it to (4,131073) in my case. savecore uses sysctl kern.dumpdev to determine the dump device. kern.dumpdev is set to (13,131073). Thus, dumpon uses bmajor and savecore uses cmajor device numbers. I also note that savecore grovels around in /dev/kmem which scares the heck out of me as far as my hacking abilities go ;-) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
:And how do you create dumps from a kernel that hasn't finished booting :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel :config does not seem to do the job. : :Nick You can do it manually from /etc/rc. If it doesn't even get that far, you used to be able to specify it in the kernel config but I do not know if that is possible any more. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soft-updates feedback
On 20-Jul-99 Amancio Hasty wrote: Have you checked your syslog to see if you are getting disk errors? Also, I noticed that you have a VIA chipset and I know that at least with the Bt848 driver they have caused havoc. I would stick to Intel PCI chipsets. Not sure if your motherboard supports or not do you have the latest microcode for your VIA chipset? Huh? Excerpt from my dmesg: Probing for devices on PCI bus 0: chip0: VIA 82C597 (Apollo VP3) system controller rev 0x04 on pci0.0.0 chip1: VIA 82C598MVP (Apollo MVP3) PCI-PCI bridge rev 0x00 on pci0.1.0 chip2: VIA 82C586 PCI-ISA bridge rev 0x41 on pci0.7.0 ide_pci0: VIA 82C586x (Apollo) Bus-master IDE controller rev 0x06 on pci0.7.1 chip3: VIA 82C586B ACPI interface rev 0x10 on pci0.7.3 bktr0: BrookTree 848 rev 0x01 int a irq 9 on pci0.9.0 bti2c0: bt848 Hard/Soft I2C controller iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 Hauppauge WinCast/TV, Philips NTSC tuner, dbx stereo. What types of havoc should I be looking for? Haven't had any since December when I bought the new motherboard. Oh, and here's uname -a: FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1 21:08:59 EDT 1999 [EMAIL PROTECTED]:/usr/source/src/sys/compile/JOHN i386 More info available on request. Cheers -- Amancio Hasty [EMAIL PROTECTED] --- John Baldwin [EMAIL PROTECTED] -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use 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: is dumpon/savecore broken?
In message [EMAIL PROTECTED], Dav id Scheidt writes: On Tue, 20 Jul 1999, Matthew Dillon wrote: * make sure your swap partition is large enough to hold the crash dump. If you have 256MB of ram, your swap partition must be at least 256MB in size. Is there any reason that savecore(8) can't write compressed crashdumps? (Other than no one haveing ever written the the code, of course.) In other words, if I wrote this would it get committed? I'm pretty sure it would. I think the lack of libz has prevented it in the past. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
:On Tue, 20 Jul 1999, Matthew Dillon wrote: : : : * make sure your swap partition is large enough to hold the crash : dump. If you have 256MB of ram, your swap partition must be : at least 256MB in size. : :Is there any reason that savecore(8) can't write compressed crashdumps? :(Other than no one haveing ever written the the code, of course.) In :other words, if I wrote this would it get committed? : :David Scheidt A crash dump would have to uncopmressed to gdb it. If you have sufficient space to hold a crash dump, just point /var/crash at that space. If you compress it right off the bat then someone is going to have to uncompress it to look at it. I sometimes compress crash dumps if I want to save them after I'm through gdb'ing them. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Moving ipf(1) to ipf(8)?
On Tue, Jul 20, 1999 at 10:40:03AM +0930, Kris Kennaway wrote: On Mon, 19 Jul 1999, Nik Clayton wrote: docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to (among other things) be consistent with ipfw(8). Anyone care to comment one way or the other? Definitely. Assuming I did this, what's the approved method? Myself, I'd just # mv ipf.1 ipf.8 # cvs remove ipf.1 # cvs add ipf.8 # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8 [... check for any other man pages that refer to ipf(1) and update them accordingly ...] which properly reflects that (until the change) ipf.8 didn't exist. I *would not* use a repository copy for this. I'm aware that some people's opinions of when you repository copy and when you don't are different, however. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Matthew Dillon wrote: A crash dump would have to uncopmressed to gdb it. If you have sufficient space to hold a crash dump, just point /var/crash at that space. If you compress it right off the bat then someone is going to have to uncompress it to look at it. savecore saving compressed crash dumps is handy on production machines with lots of memory. I run a bunch of HP/UX boxes that don't have 4 gigs in /var/crash, because they never crash, except of course when they do. It is very useful to be able to save the dump, even if I have to analyze it somewhere else. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Steven G. Kar gl" writes: During the boot process I see dumpon: crash dumps to /dev/da0s1b (4, 131073) checking for core dump...savecore: can't find device 13/131073 It seems that the the major device number is reset from 4 to 13. troutmask:kargl[225] swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/#B13:0x200015118720 511872 0%Interleaved Yes, all dev_t's which make it out of the kernel have cmajor numbers now. Try this change to savecore: /ddname = find_dev/s/BLK/CHR/ No, that's wrong. You cannot do buffered-type IO on a cdev. I committed a workaround, and now it works. There's no easy way around this, except possibly making kern.dumpdev a string (makes quite a bit of sense there...) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [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: is dumpon/savecore broken?
In message [EMAIL PROTECTED], "Bria n F. Feldman" writes: /ddname = find_dev/s/BLK/CHR/ No, that's wrong. You cannot do buffered-type IO on a cdev. I committed a workaround, and now it works. There's no easy way around this, except possibly making kern.dumpdev a string (makes quite a bit of sense there...) Indeed. a dev_t should never be exported as such from the kernel anymore, in particular not for bdevs. dumps and swap are the two offenders left. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Bria n F. Feldman" writes: /ddname = find_dev/s/BLK/CHR/ No, that's wrong. You cannot do buffered-type IO on a cdev. I committed a workaround, and now it works. There's no easy way around this, except possibly making kern.dumpdev a string (makes quite a bit of sense there...) Indeed. a dev_t should never be exported as such from the kernel anymore, in particular not for bdevs. dumps and swap are the two offenders left. Should I commit a similar workaround for the swap code too? Quite simple to do... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [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: Soft-updates feedback
Glad that is working out for you. I am not into PCI low level bugs they are very difficult to indentify and in certain cases impossible to fix. To give you a little hint: 1.6825 May 1999 Roger Hardiman [EMAIL PROTECTED] Due to differences in PCI bus implementations from various motherboard chipset manufactuers, the Bt878/Bt879 has 3 PCI bus compatibility modes. These are NORMAL PCI 2.1 for proper PCI 2.1 compatible chipsets. INTEL 430 FXfor the Intel 430 FX chipset. SIS VIA CHIPSET for certain SiS and VIA chipsets. Older Intel and non-Intel chipsets may also benefit from either 430_FX or SIS/VIA mode. Usually, the kind of problems that I have heard of is systems hanging hard for instance with the Bt848 driver. The bottom line is that if it is working for you great. -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panics on my SMP system
On Tue, 20 Jul 1999, Matthew Dillon wrote: How old is your -CURRENT source tree ?Fixes to the pipe code have been made, though they are not 100% complete. If your -CURRENT source tree is more then a few days old I recommend updating it. A number of significant reliability fixes have gone in, including fixes to the pipe code and fixes to certain atomic operations that weren't atomic. What's happing with regard to your pipe write locking fixes? I still apply those to my kernels... -Matt Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [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
kernel compilation problems
Hi! I'm currently having problems compiling my kernel: ... ... ... sh ../../conf/newvers.sh STARFIRE cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf vers.c linking kernel vfs_init.o: In function `vfs_register': vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)' *** Error code 1 1 error Exit 2 Any ideas? Ciao, Thomas. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unusable PS/2 mouse
On Tue, 20 Jul 1999, Kazutaka YOKOTA wrote: One is Logitech mouse support in the psm driver. The psm driver had been unable to handle some wheel mice models, including Logitech M-S48, until recently. Perhaps it's worth getting another mouse in this situation. My $30 Logitech wheeled mouse (M-C48) works great with FreeBSD and has for as long as I've owned it. This seems to be the going attitude WRT CD-ROMS :^) - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unusable PS/2 mouse
Is there any support for the wheel in FreeBSD/X, the moused man page seems to suggest there is but I've not managed to get it to do anything yet. Paul. You will find the following URL useful to utilize the wheel in the X environment. http://www.inria.fr/koala/colas/mouse-wheel-scroll/ Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kensington mouse (was: Re: Unusable PS/2 mouse)
On Wed, 21 Jul 1999, Kazutaka YOKOTA wrote: On Tue, 20 Jul 1999, Warner Losh wrote: I had problems with the my Kensignton mouse in a box, but some fixes were made to -current that fixed the problems. A workaround is to set flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a plain old 2 button (or in my case 3 button) mouse. For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill the out of sync messages. The only side effect I've seen is that the cursor speed is faster [than with using the serial port connector]. Which model is it? Kensington sells quite a number of mouse/trackball products. The model Warner talked about is "Kensington Mouse in a Box Scroll". It has a wheel between two buttons. Is that the one you are talking about? (The problem regarding "Kensington Mouse in a Box Scroll" was fixed in both -CURRENT and -STABLE about a week ago.) If not, would you give -v option to the boot command when you boot the kernel and send me /var/run/dmesg.out, so that I can diagnose what the psm driver is doing to the mouse? My apologies, I was inferring that I also had a "Kensington Mouse in a Box Scroll" (Model: MOSUI) ... After removing the flags from psm, the mouse is working great. This is stable cvsupped last weekend (July 15th or so). Excellent work! Thanks, Chris - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
