Re: ATA mkIII first official patches - please test!
Ben Stuyts wrote: On 3 Feb 2005, at 21:52, Søren Schmidt wrote: o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. Will RAID mirrors built using atacontrol on standard ata controllers still work? Specifically in my case on 5.3-stable: Not as is, but its easily added, uncomment line 597 in ata-raid.c and it will be picked up as before... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Søren Schmidt wrote: ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. Is this coming in 5.4-RELEASE? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
acd0: FAILURE - MODE_SENSE_BIG timed out
I have a problem when booting ,mounting cd's and installing freebsd. It has not been fixed since freebsd 5.3-beta6 and up to stable 5.3-RELEASE-p5 This problem comes when installing/mounting/booting with cd/dvd burners I have the same problem with my laptop. Dump of dmesg: *SNIP* ad0: 114473MB ST3120023A/3.33 [232581/16/63] at ata0-master UDMA100 acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out *SNIP* acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out *SNIP* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0: FAILURE - MODE_SENSE_BIG timed out
On Sat, 5 Feb 2005, ice wrote: I have a problem when booting ,mounting cd's and installing freebsd. It has not been fixed since freebsd 5.3-beta6 and up to stable 5.3-RELEASE-p5 You may want to try the recently posted atamkIII patches to see if they help -- these symptoms are among those the patch is believed to address. Robert N M Watson This problem comes when installing/mounting/booting with cd/dvd burners I have the same problem with my laptop. Dump of dmesg: *SNIP* ad0: 114473MB ST3120023A/3.33 [232581/16/63] at ata0-master UDMA100 acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out acd0: FAILURE - MODE_SENSE_BIG timed out *SNIP* acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - TEST_UNIT_READY timed out acd0: FAILURE - PREVENT_ALLOW timed out *SNIP* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
load values
Hi, I updated my system (5-STABLE) just today and now I get extraordinary load-values: 'top' says (e.g.): load averages: 443.73, 36.47, 60.50 I haven't running 400 processes at all! The man page for GETLOADAVG(3) says: The getloadavg() function returns the number of processes in the system run queue averaged over various periods of time. So - what's going on here? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adjusting time on a secured FreeBSD machine.
Thanks as well to both of you. I too learned something new. Scott Robbins wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 04, 2005 at 01:41:39PM -0800, Kevin Oberman wrote: Date: Fri, 4 Feb 2005 16:29:03 -0500 From: Scott Robbins [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 They do conflict with each other, I'm not sure what will happen if you have both in rc.conf. Hopefully ntpdate will run first, then ntpd. If ntpd is running then you will get an error message running ntpdate. On an unsecured box (the one that I mentioned, where ntpd choked because the BIOS clock was too far off, I simply stopped ntpd, ran ntpdate and then restarted ntpd. They do not conflict if you use the flags in defaults/rc.conf. ntpdate -b sets the time ONCE and is run before ntpd starts, the '-b' option will cause it to to set the time absolutely no matter hao far off the clock is at the time. This is exactly how ntpdate is intended to be used. That said, ntpdate is considered obsolete by the ntp folks and may disappear at some time in the future. Their recommendation is to use ntpd with the '-g' flag to force an unconditional clock set and to use the 'iburst' option on your servers in /etc/ntp.conf. I find this works well, but some have complained that it takes too long. Thank you. I have been using ntpd for awhile, and haven't read the man pages recently, which I should have done before posting. I only ran into the issue once and solved it as I mentioned. Thanks again. I just learned something. - -- Scott GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: No, but, see, Mom, that doesn't really work for me. We're just going to the magic shop, no school supplies there. Dawn: Yeah, Mom. I'm not going to Hogwarts. (chuckles) Hog- (looks at Buffy, who's not amused) Jeez, crack a book sometime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCA+81+lTVdes0Z9YRAhi5AKC9Y2EUCxlsj+m7fhxrM8R5q6v6MACfbzXZ f/Lt+igi9J8TVMwuJ+CX8hE= =GCnT -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: load values
Hello, I have had the same problem exactly today. Re cvsup your src tree and rebuild kernel and world solved this problem. Regards On Sat, 5 Feb 2005 16:58:58 +0100, Matthias Schuendehuette [EMAIL PROTECTED] wrote: Hi, I updated my system (5-STABLE) just today and now I get extraordinary load-values: 'top' says (e.g.): load averages: 443.73, 36.47, 60.50 I haven't running 400 processes at all! The man page for GETLOADAVG(3) says: The getloadavg() function returns the number of processes in the system run queue averaged over various periods of time. So - what's going on here? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- There's this old saying: Give a man a fish, feed him for a day. Teach a man to fish, feed him for life. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: load values [SOLVED]
Hello, Am Samstag, 5. Februar 2005 21:06 schrieb Dominique Goncalves: I have had the same problem exactly today. Re cvsup your src tree and rebuild kernel and world solved this problem. Yes, indeed. Thanks a lot! -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
stable 5.3 question about KVM connected Mouse?
Hello, I was hoping someone in the freebsd community would have the answer to this. I own a 2 computer connecting Trendnet TK-209i KVM swich and have had a problem with it with FreeBSD ever since I owned it. I can never seem to get my mouse to work when conneceted to my FreeBSD machine. Its an USB 5 button mouse connected to the KVM switch through a PS2 adapter. It than connects to the FreeBSD machine through a single USB connector for both the Keyboard and mouse. Freebsd 5.3 detects the keyboard fine through the USB connector, but moused never detects the mouse no matter what port I choose. I have tried both Windows and Linux with the single USB connector for the keyboard and mouse, and they detect the mouse just fine. My question is what the heck to I have to do to get my mouse detected in FreeBSD 5.3 with my current configuration? I would really appreciate any information people would have on what to try. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with migrating onto a gmirror slice.
I have a system that I set up to use a gmirror back in the 5.3beta days. It's running fine but I don't remember exactly how I set it up. It's a scsi system w/ two identical disks. I'd like to migrate the installation to a new box that uses ide disks, and am basing my attempts on the GEOM mirror Approach 2: Single Slice, Preferred, More Flexible portion of these instructions: http://people.freebsd.org/~rse/mirror/ Although the disk that I ended up with was bootable in the new system, I noticed that the slice table was messed up. After a couple of tries, here's what I've found: The machine is: FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MERLIN i386 Here's the series of commands that I've performed to illustrate the problem: 138 15:31 fdisk -v -B -I /dev/ad0 139 15:31 fdisk -s /dev/ad0 140 15:31 fdisk -s /dev/ad0 ~hartzell/fdisk-initial 141 15:32 gmirror label -v -n -b round-robin disk0 /dev/ad0s1 142 15:32 fdisk -s /dev/ad0 143 15:32 bsdlabel -w -B mirror/disk0 144 15:32 bsdlabel -e mirror/disk0 145 15:33 fdisk -s /dev/ad0 146 15:34 fdisk -s /dev/ad0 ~hartzell/fdisk-after 147 15:34 history 148 15:34 history ~hartzell/history After the fdisk at line 138, here's the slice table: /dev/ad0: 387621 cyl 16 hd 63 sec PartStartSize Type Flags 1: 63 390721905 0xa5 0x80 The fdisk at line 142 showed that the slice table was fine after the gmirror step. But after the bsdlabels at lines 143 and 144 the slice table looks like this: /dev/ad0: 387621 cyl 16 hd 63 sec PartStartSize Type Flags 4: 0 5 0xa5 0x80 Here's the output of bsdlabel /dev/mirror/disk0: # /dev/mirror/disk0: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 8336976 524288 swap c: 3907219040unused0 0 # raw part, don't edit d: 524288 88612644.2BSD 2048 16384 32776 e: 524288 93855524.2BSD 2048 16384 32776 f: 380812064 99098404.2BSD 2048 16384 28552 Anyone see what I'm missing? g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with migrating onto a gmirror slice.
On Sat, Feb 05, 2005 at 04:45:50PM -0800, George Hartzell wrote: I have a system that I set up to use a gmirror back in the 5.3beta days. It's running fine but I don't remember exactly how I set it up. It's a scsi system w/ two identical disks. I'd like to migrate the installation to a new box that uses ide disks, and am basing my attempts on the GEOM mirror Approach 2: Single Slice, Preferred, More Flexible portion of these instructions: http://people.freebsd.org/~rse/mirror/ Although the disk that I ended up with was bootable in the new system, I noticed that the slice table was messed up. After a couple of tries, here's what I've found: The machine is: FreeBSD merlin.alerce.com 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #9: Sat Dec 18 12:38:37 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MERLIN i386 Here's the series of commands that I've performed to illustrate the problem: 138 15:31 fdisk -v -B -I /dev/ad0 139 15:31 fdisk -s /dev/ad0 140 15:31 fdisk -s /dev/ad0 ~hartzell/fdisk-initial 141 15:32 gmirror label -v -n -b round-robin disk0 /dev/ad0s1 142 15:32 fdisk -s /dev/ad0 143 15:32 bsdlabel -w -B mirror/disk0 144 15:32 bsdlabel -e mirror/disk0 145 15:33 fdisk -s /dev/ad0 146 15:34 fdisk -s /dev/ad0 ~hartzell/fdisk-after 147 15:34 history 148 15:34 history ~hartzell/history After the fdisk at line 138, here's the slice table: /dev/ad0: 387621 cyl 16 hd 63 sec PartStartSize Type Flags 1: 63 390721905 0xa5 0x80 The fdisk at line 142 showed that the slice table was fine after the gmirror step. But after the bsdlabels at lines 143 and 144 the slice table looks like this: /dev/ad0: 387621 cyl 16 hd 63 sec PartStartSize Type Flags 4: 0 5 0xa5 0x80 Here's the output of bsdlabel /dev/mirror/disk0: # /dev/mirror/disk0: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 8336976 524288 swap c: 3907219040unused0 0 # raw part, don't edit d: 524288 88612644.2BSD 2048 16384 32776 e: 524288 93855524.2BSD 2048 16384 32776 f: 380812064 99098404.2BSD 2048 16384 28552 Anyone see what I'm missing? This is how I've done it. 1. Use sysinstall to do the slice table on the new disk, writing the FreeBSD Boot Manager. QUIT Sysisntall after this (do NOT label the slice) 2. gmirror label -b round-robin disk0 ad0s1 3. bsdlabel -e /dev/mirror/disk0 Edit the label. Subtract ONE from the c partition size, which will be one sector too long. Write it out. If you got it right, there should be no complaints on the write. When you read it in, there should be only one (the c) partition. 4. bsdlabel /dev/mirror/disk0 - insure that there are no complaints about the label. 5. newfs ... each filesystem 6. Copy your filesystems over (use dump/restore, or pax) 7. Edit the /etc/fstab entries appropriately, make sure swapoff is in the /etc/rc file, etc. The result should be bootable and run. A bit different than the instructions in that page, but after fiddling with it this is the procedure I came up with, and it works. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 - 5 : sshd multiple log entries login_getclass: unknown class 'root'
On Thu, Feb 03, 2005 at 09:11:07PM -0800, Doug White wrote:
On Tue, 1 Feb 2005, Andrew Konstantinov wrote:
I can't reproduce this on my systems, many of which started at 5.3 and
now
build 5-stable. Are you using the system ssh or one you built from
ports?
What is the output of 'ls -l /etc/login.conf*'?
I knew I wasn't hallucinating. When I rebuild and reinstall src/lib/libc
from RELENG_5_3 sources on RELENG_5 system, all of the above problems
disappear altogether. The bugs are in the dynamically linked library
that sshd relies on. Once the new library is in place and
/etc/rc.d/sshd restart is performed, the bugs disappear. I don't have
time to dig into that right now, but I'll be back with patches.
The simple fact stands that noone else can reproduce this, which leads me
to believe you took a non-standard approach to upgrading, and therefore
are getting what you asked for. :-)
If you can provide exact reproduction steps, starting from bare metal,
I'll follow them.
No algorithm for reproduction yet, but here is some additional information
regarding this issue:
First of all, I just rebuild everything in the system twice, following the
proper sequence each time. Here are the steps I've taken:
- cvsup /usr/src with RELENG_5
- cd /usr/src make buildworld buildkernel installkernel
- reboot into single user mode
- mount all
- cd /usr/src make installworld
- mergemaster
- find /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/libexec \
/usr/libdata /usr/include -ctime +1d -exec rm -rf {} \;
- reboot
- rm -rf /usr/include/*
- cd /usr/src make includes
- cd /usr/src make buildworld buildkernel installkernel
- reboot into single user mode
- mount all
- cd /usr/src make installworld
- mergemaster
- find /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/libexec \
/usr/libdata /usr/include -ctime +1d -exec rm -rf {} \;
- reboot
That sequence of steps should guarantee that none of the old libraries or old
includes in the /usr/include find their way into the upgraded system. Sadly,
this didn't change anything.
The other important thing that I've noticed is that when I set
UsePrivilegeSeparation in sshd_config to no, all those bugs disappear.
I'll try to come up with a recipe for reproduction once I have enough time.
Andrew
pgpQvS0ZAPFWN.pgp
Description: PGP signature
Re: 5.3 - 5 : sshd multiple log entries login_getclass: unknown class 'root'
On Sat, Feb 05, 2005 at 10:12:45PM -0800, Andrew Konstantinov wrote: On Thu, Feb 03, 2005 at 09:11:07PM -0800, Doug White wrote: On Tue, 1 Feb 2005, Andrew Konstantinov wrote: I can't reproduce this on my systems, many of which started at 5.3 and now build 5-stable. Are you using the system ssh or one you built from ports? What is the output of 'ls -l /etc/login.conf*'? I knew I wasn't hallucinating. When I rebuild and reinstall src/lib/libc from RELENG_5_3 sources on RELENG_5 system, all of the above problems disappear altogether. The bugs are in the dynamically linked library that sshd relies on. Once the new library is in place and /etc/rc.d/sshd restart is performed, the bugs disappear. I don't have time to dig into that right now, but I'll be back with patches. The simple fact stands that noone else can reproduce this, which leads me to believe you took a non-standard approach to upgrading, and therefore are getting what you asked for. :-) If you can provide exact reproduction steps, starting from bare metal, I'll follow them. The other important thing that I've noticed is that when I set UsePrivilegeSeparation in sshd_config to no, all those bugs disappear. Also, when I traced sshd in debug mode using gdb, I've found that /usr/src/lib/libc/gen/getcap.c lines 246 - 274 work properly and return the valid root entry from the login database and that code is enclosed in the else statement that is a part of if (fd = 0) construction. So, I apparently, something gets to getent around cgetent with already existing file descriptor which causes a different portion of code to be executed (instead of 246 - 274) which in its turn causes a problem. Perhaps the descriptor is poing to a wrong file? Andrew pgpPt89yqM7MF.pgp Description: PGP signature
