After 7.3-8.1, moused on serial mouse draws 100% CPU
After upgrading from 7.3 to 8.1, moused has started drawing 100% CPU (even when the mouse is not used). moused -d -f doesn't output anything suspicious - in particular, it does not display anything when the mouse is not moved. root10833 100.0 0.1 1732 1100 v0 R+ 10:51AM 8:47.62 /usr/sbin/moused -d -F 200 -A 1.5 -a 0.5 -p /dev/cuau0 -t auto -d -f FWIW, I was using the uart serial driver even on 7.3. (Maybe this is also the time to mention that mouse movement got much slower after the move to uart - that's why the -F -A -a settings are in there.) Any help would be much appreciated! -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Just a thank you message for the v15 development, MFS and this fast fix. Maybe this is just noise on the lists, but I think that too little thanks get to the FreeBSD developers, so a little noise like this may be beneficial. -- Guido Falsi m...@madpilot.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
How to predict drive number change for 7.3-8.1 upgrade?
I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: After 7.3-8.1, moused on serial mouse draws 100% CPU
On Thu, Sep 16, 2010 at 11:02:38AM +0200, Michael Sperber wrote: After upgrading from 7.3 to 8.1, moused has started drawing 100% CPU (even when the mouse is not used). moused -d -f doesn't output anything suspicious - in particular, it does not display anything when the mouse is not moved. root10833 100.0 0.1 1732 1100 v0 R+ 10:51AM 8:47.62 /usr/sbin/moused -d -F 200 -A 1.5 -a 0.5 -p /dev/cuau0 -t auto -d -f FWIW, I was using the uart serial driver even on 7.3. (Maybe this is also the time to mention that mouse movement got much slower after the move to uart - that's why the -F -A -a settings are in there.) Any help would be much appreciated! Adding ed@ to CC list, since he maintains uart(4), which is now the default serial driver on 8.x. Michael, in the meantime can you provide dmesg details that pertain to your serial ports? uartXX devices would be sufficient, in addition the device its attached to (e.g. acpi0, etc.). Thanks. (Footnote: I wasn't even aware people still had/used serial mice any more, given the popularity of PS/2, and now USB...) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to predict drive number change for 7.3-8.1 upgrade?
Am 16.09.2010 um 11:05 schrieb Michael Sperber: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? If you have a serial console, you can always enter the root device at the prompt, so you can recover there. If you can figure out the new device name, you can simply change the fstab entry for /; that's where loader picks up the root device that it hands to the kernel. Long-term, the best option is to label your filesystems or partitions, and use the label entries in fstab instead of the device names. I don't remember what 7.3 offers in terms of labels, but glabel should be available. Check tunefs if it offers the -L volname option, that's even better. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to predict drive number change for 7.3-8.1 upgrade?
On Thu, Sep 16, 2010 at 11:05:06AM +0200, Michael Sperber wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? This has to do with ATA device naming schemes, and changes in the ATA driver, in addition to capabilities of the chipset. For example, FreeBSD 7.x may have seen only 2 PATA or SATA ports on your system, but with 8.x (and improved drivers) it may see 4, or possibly 2 of each (2 PATA, 2 SATA). The device numbers shift/change as a result. AFAIK, there is no failsafe way to predict what the device numbers will be. I've dealt with this problem many times, and this is how I do it: Print out or copy/paste the contents of /etc/fstab prior to upgrade. If you have serial console on your remote server, then you have little to worry about -- you know what drive name/model/size is associated with ad6 on 7.x. When you upgrade, boot the 8.x kernel and into single-user mode. While the kernel boots, you'll see the device names in the kernel output, and will then be prompted for the root filesystem. Enter the correct ufs reference string with the correct device number. After that, just mount the /usr, /tmp, and /var filesystems by hand using the correct device number. Once you have that, you should be able to edit /etc/fstab and change the device numbers (you might have to do mount -o rw -u / to make it read-writeable). Reboot the machine and go into single-user, and you should find that the root filesystem is mounted + mount -a should work fine + everything work going forward. If you find that the device numbers are changing randomly after every reboot, that's a separate problem and should be dealt with separately. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to predict drive number change for 7.3-8.1 upgrade?
On Thu, Sep 16, 2010 at 4:05 PM, Michael Sperber sper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. doesn't 7.3 have ufs label? -- O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to predict drive number change for 7.3-8.1 upgrade?
Michael Sperber wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? you may try to label your slices/labels and mount /dev/label/root instead of /dev/adXsYa see man 8 glabel -- SY, Marat
Re: How to predict drive number change for 7.3-8.1 upgrade?
Stefan Bethke s...@lassitu.de writes: Am 16.09.2010 um 11:05 schrieb Michael Sperber: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? If you have a serial console, you can always enter the root device at the prompt, so you can recover there. I know. But given the serial-console problems recently reported here, I was a bit reluctant to take the risk. Long-term, the best option is to label your filesystems or partitions, and use the label entries in fstab instead of the device names. I don't remember what 7.3 offers in terms of labels, but glabel should be available. Check tunefs if it offers the -L volname option, that's even better. That sounds like a good idea. Thanks! -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: After 7.3-8.1, moused on serial mouse draws 100% CPU
Jeremy Chadwick free...@jdc.parodius.com writes: Michael, in the meantime can you provide dmesg details that pertain to your serial ports? uartXX devices would be sufficient, in addition the device its attached to (e.g. acpi0, etc.). uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] acpi0: 080907 RSDT1802 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed (Footnote: I wasn't even aware people still had/used serial mice any more, given the popularity of PS/2, and now USB...) They don't make trackballs like the old Kensington models anymore :-) -- Regards, Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
On Thu, 16 Sep 2010 10:42:40 +0200, Guido Falsi m...@madpilot.net wrote: On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Just a thank you message for the v15 development, MFS and this fast fix. Maybe this is just noise on the lists, but I think that too little thanks get to the FreeBSD developers, so a little noise like this may be beneficial. Agreed to that! Thanks for all the efforts in bringing ZFS to FreeBSD. I'm running 8.1-Release with v15 without any problems. I just copied a 21GB MySQL datadir from a linux box to my FreeBSD/zfs workstation. Thanks to zfs compression the 21GB only consume 10GB on zfs. That's massive compression :-) So again: Thanks to all developers and keep up the good work! ./Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to predict drive number change for 7.3-8.1 upgrade?
On Thu, Sep 16, 2010 at 11:40:43AM +0200, Michael Sperber wrote: Stefan Bethke s...@lassitu.de writes: Am 16.09.2010 um 11:05 schrieb Michael Sperber: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? If you have a serial console, you can always enter the root device at the prompt, so you can recover there. I know. But given the serial-console problems recently reported here, I was a bit reluctant to take the risk. I assume you're referring to the issue reported by Oliver Fromme. That issue may -- not 100% certain at this point -- be related to the DCD line on a serial port being used/honoured by uart(4). We have numerous systems using RELENG_8 with reliable/working serial console, but as I stated in the other thread, our wiring/equipment and adapters differ from Oliver's. I still have not tested the patch Ed provided due to my day (night) job keeping me busy the past 24-48 hours. I'll see if I can get to testing it tonight. The only reason I'm testing the patch, by the way, is to see if *our* stuff suddenly breaks -- and if it does, I can still roll it back remotely (via serial console). Soapbox, for what it's worth: Serial console unreliability and OS installs are both reasons why I rent co-location space that's local to me (within driving distance). I cannot imagine having servers in another state or country which only have serial console (e.g. PXE is not configured in the BIOS, BIOS lacks serial redirection, no remote rebooter/power-cycle unit, no dial-in modem, etc.). Depending on how mission-critical your setup is, I would highly recommend investing the time and money into a setup that does allow access to the servers when serial console breaks -- an KVM-over-IP device would be ideal, since it gives you VGA console via VNC or a Java client. In my case I'm just a single guy with a bunch of servers, and run what I do as a (expensive) hobby. KVM-over-IP devices are unreasonably overpriced (like most enterprise-grade things), and I tend to shy away from HP/Compaq ProLiant hardware (which have LOM/LOM2) since over the years I've seen too many problems with them posted on the FreeBSD lists (mainly relating to storage device driver problems), not to mention the support contract costs... -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
On Thu, Sep 16, 2010 at 10:53:02AM +0100, Marian Hettwer wrote: On Thu, 16 Sep 2010 10:42:40 +0200, Guido Falsi m...@madpilot.net wrote: On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Just a thank you message for the v15 development, MFS and this fast fix. Maybe this is just noise on the lists, but I think that too little thanks get to the FreeBSD developers, so a little noise like this may be beneficial. Agreed to that! Thanks for all the efforts in bringing ZFS to FreeBSD. I'm running 8.1-Release with v15 without any problems. I just copied a 21GB MySQL datadir from a linux box to my FreeBSD/zfs workstation. Thanks to zfs compression the 21GB only consume 10GB on zfs. That's massive compression :-) Related to this, I have a question. Is it convenient to put databases on a compresed filesystem? Apart from the space advantage, does it give any speed advantage/penalty? Anyone has some benchmark or objective data about this? Also are we talking about MyISAM or InnoDB tables? Or a mix of those? -- Guido Falsi m...@madpilot.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
On 09/16/10 12:42, Guido Falsi wrote: Related to this, I have a question. Is it convenient to put databases on a compresed filesystem? Apart from the space advantage, does it give any speed advantage/penalty? It depends on what you do. It will not save you memory usage either since data needs to be decompressed when read. If the database is lightly loaded I don't think there will ever be problems. Also if the database is mostly read-only. If it's used in a heavy loaded read+write environment or if it is CPU-bound, it is probably a bad idea to put it on a compressed file system. Anyone has some benchmark or objective data about this? I know about this one: http://don.blogs.smugmug.com/2008/10/13/zfs-mysqlinnodb-compression-update/ But it only really measures copy (cp) speeds and compression, not database performance. Also are we talking about MyISAM or InnoDB tables? Or a mix of those? MyISAM would probably be faster to compress and manage :) http://www.scribd.com/doc/14603831/Optimizing-MySQL-Performance-with-ZFS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: After 7.3-8.1, moused on serial mouse draws 100% CPU
Hi all, I should really get myself subscribed to sta...@... Anyway, Michael, can you attach truss to the process to see what it's actually doing (truss -p $pid)? I'm interested in a single `iteration' of what it's doing. Thanks! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpcolJSxe3PO.pgp Description: PGP signature
Re: MFC of ZFSv15
On Thu, 16 Sep 2010 12:42:36 +0200, Guido Falsi m...@madpilot.net wrote: On Thu, Sep 16, 2010 at 10:53:02AM +0100, Marian Hettwer wrote: On Thu, 16 Sep 2010 10:42:40 +0200, Guido Falsi m...@madpilot.net wrote: On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Just a thank you message for the v15 development, MFS and this fast fix. Maybe this is just noise on the lists, but I think that too little thanks get to the FreeBSD developers, so a little noise like this may be beneficial. Agreed to that! Thanks for all the efforts in bringing ZFS to FreeBSD. I'm running 8.1-Release with v15 without any problems. I just copied a 21GB MySQL datadir from a linux box to my FreeBSD/zfs workstation. Thanks to zfs compression the 21GB only consume 10GB on zfs. That's massive compression :-) Related to this, I have a question. Related, but on its way to get off topic... Is it convenient to put databases on a compresed filesystem? Apart from the space advantage, does it give any speed advantage/penalty? At work we use Solaris 10 with zfs and compression enabled for our MySQL databases. All InnoDB. No speed penalty and only really slight advantages. I tend to say, it doesn't matter. It gives you more disk space by a wee bit of more CPU consumption. On the other hand, CPU is usually not your problem in a heavy load MySQL scenario. It's disc seek times... Anyone has some benchmark or objective data about this? No benchmarks and no time right now to come up with some fancy graphs. Also are we talking about MyISAM or InnoDB tables? Or a mix of those? InnoDB. ./Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
daily_scrub_zfs_enable is missing in /etc/defaults/periodic.conf
Hello Is there an actual reason why daily_scrub_zfs_enable is missing in /etc/defaults/periodic.conf? /etc/periodic/daily/800.scrub-zfs was mfc'ed two weeks ago: MFC r211800 Regards, Thomas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: After 7.3-8.1, moused on serial mouse draws 100% CPU
Ed Schouten e...@80386.nl writes:
I should really get myself subscribed to sta...@...
Anyway, Michael, can you attach truss to the process to see what it's
actually doing (truss -p $pid)? I'm interested in a single `iteration'
of what it's doing. Thanks!
The relevant bit is this, I think:
open(/dev/cuau0,O_RDWR|O_NONBLOCK,01001172450) = 2 (0x2)
ioctl(2,MOUSE_SETLEVEL,0x805004c)ERR#25 'Inappropriate ioctl
for device'
ioctl(2,MOUSE_GETLEVEL,0xbfbfe4cc) ERR#25 'Inappropriate ioctl
for device'
ioctl(2,MOUSE_GETHWINFO,0x8050088) ERR#25 'Inappropriate ioctl
for device'
ioctl(2,MOUSE_GETMODE,0x805009c) ERR#25 'Inappropriate ioctl
for device'
write(2,moused: ,8)= 8 (0x8)
write(2,PnP COM device rev 1.0 probe...,31)= 31 (0x1f)
write(2,\n,1) = 1 (0x1)
ioctl(2,TIOCMGET,0xbfbfe4c4) = 0 (0x0)
ioctl(2,TIOCMSET,0xbfbfe4c4) = 0 (0x0)
nanosleep({0.24000 })= 0 (0x0)
ioctl(2,TIOCMGET,0xbfbfe4c4) = 0 (0x0)
write(2,moused: ,8)ERR#5 'Input/output error'
write(2,\n,1) ERR#5 'Input/output error'
write(2,\n,1) ERR#5 'Input/output error'
ioctl(2,TIOCMGET,0xbfbfe4c4) = 0 (0x0)
ioctl(2,TIOCMSET,0xbfbfe4c4) = 0 (0x0)
nanosleep({0.24000 })= 0 (0x0)
ioctl(2,TIOCGETA,0xbfbfe2fc) = 0 (0x0)
ioctl(2,TIOCSETAW,0xbfbfe2fc)= 0 (0x0)
nanosleep({0.1 })= 0 (0x0)
ioctl(2,TIOCSETAW,0xbfbfe2fc)= 0 (0x0)
ioctl(2,TIOCFLUSH,0xbfbfe4c4)= 0 (0x0)
ioctl(2,TIOCMBIS,0xbfbfe4c4) = 0 (0x0)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
write(2,\n,1) ERR#5 'Input/output error'
nanosleep({0.24000 })= 0 (0x0)
read(2,3,1)= 1 (0x1)
write(2,\n,1) ERR#5 'Input/output error'
read(2,\b,1) = 1 (0x1)
write(2,\n,1) ERR#5 'Input/output error'
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^A,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^Z,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,+,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,-,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,,,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^P,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^P,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^P,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^Q,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,-,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,/,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,5,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,3,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,%,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,0,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,.,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,0,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,\^P,1) = 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,,1)= 1 (0x1)
select(1024,{2},0x0,0x0,{0.24 }) = 1 (0x1)
read(2,0xbfbfe4ec,1) ERR#35
fbsd8_stable nfsv3 sys=krb5 issue
Hi all, I re-decided to move my nfs server from solaris to fbsd. So I am using test machines to see if it works. I have my kerberos realm configured, and seems to work fine, both nfsserver and nfsclient have their host and nfs keytabs stored in /etc/krb5.keytab files, and I am following the configuration instructions from http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that rick was kind enough to write (thanx rick!). Before analyzing my problem and configuration steps further, let me state the reason for this email: I am not able to access an nfsv3 mounted filesystem when mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's instructions, whereas in the past I had no such problem. To be more specific: Last time I was playing with the configuration most things worked fine (Feb 2010), but now things seem a bit different, and I am not sure whether I have forgotten something fundamental on my configuration or something has changed since I updated both my machines (client and server) to the latest sources: nfs-server: # uname -a FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep 15 17:07:13 EEST 2010 r...@fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER i386 nfs-client: # uname -a FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep 10 13:08:06 EEST 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT amd64 I have my two usual test-users on my test-machines, mamalos and testakis, who both exist as kerberos principals too; their uids and gids are the same on all machines. I am able to kinit to any of them on my machines and acquire a valid kerberos ticket, which makes me assume that kdc runs nicely. fbsd-client's /etc/rc.conf reads: rpcbind_enable=YES mountd_enable=YES mountd_flags=-e nfs_server_enable=YES nfs_client_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES gssd_enable=YES and fbsd-server's /etc/rc.conf reads: rpcbind_enable=YES nfs_client_flags=-n 4 rpc_statd_enable=YES rpc_lockd_enable=YES #nfsd_flags=-e gssd_enable=YES nfsuserd_enable=YES nfsclient_enable=YES # nfs server nfs_server_enable=YES mountd_enable=YES #mountd_flags=-e Don't get confused that both machines have nfsd enabled (the client is used as an experimental nfsv4 server too), and I think that this should not be an issue with regard to my problem (on the other hand, nobody knows...). the server's kernel-config reads: options KGSSAPI device crypto options NFSCL and the client's kernel-config reads: options NFSD #(don't forget that the client works as an nfsv4 server too) options KGSSAPI device crypto Lastly, the server's /etc/exports reads: /exports-alldirs -sec=krb5 on the server: # ls -la /exports total 10 drwxr-xr-x 5 root wheel - 512 17 Feb 2010 ./ drwxr-xr-x 22 root wheel - 512 15 Sep 19:33 ../ drwxr-xr-x 3 root wheel - 512 5 Feb 2010 m/ drwxr-xr-x 2 mamalos wheel - 512 16 Sep 15:43 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 2010 testakis/ on the client: # klist klist: No ticket file: /tmp/krb5cc_0 # mount mount_nfs -onfsv3,sec=krb5 server:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server:/exports on /mnt (nfs) # ls -la /mnt total 0 ls: /mnt: Permission denied # exit $ id uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel) $ klist klist: No ticket file: /tmp/krb5cc_1001 $ ls -la /mnt total 0 ls: /mnt: Permission denied $ kinit mamalos mama...@example's Password: $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example $ ls -la /mnt total 0 ls: /mnt: Permission denied ... (dooea?!?!?!!?) ... $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example Sep 16 16:27:51 Sep 17 02:26:49 nfs/ser...@example And this is where I don't understand what I have done wrong... If I use sec=krb5:sys in my /etc/exports, and type mount_nfs -onsfsv3,sec=krb5 ...blabla... on the client, everything seems to work ok, but then again no kerberos protection is applicable (I am able to rw in /mnt/mamalos folders as mamalos without having obtained any ticket). I assume that I must have forgotten to include something very fundamental in my configs, but my head is stuck, so if someone has an idea... Thank you all for your time in advance, regards, mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___
Re: MFC of ZFSv15
Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. Regards, UPDATING should have anything else. -- jhell,v ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on i386/pc98
TB --- 2010-09-16 14:37:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-16 14:37:56 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-09-16 14:37:56 - cleaning the object tree TB --- 2010-09-16 14:38:40 - cvsupping the source tree TB --- 2010-09-16 14:38:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-09-16 15:21:02 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-16 15:21:02 - ERROR: unable to cvsup the source tree TB --- 2010-09-16 15:21:02 - 1.10 user 32.14 system 2586.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fbsd8_stable nfsv3 sys=krb5 issue
Hi all, I re-decided to move my nfs server from solaris to fbsd. So I am using test machines to see if it works. I have my kerberos realm configured, and seems to work fine, both nfsserver and nfsclient have their host and nfs keytabs stored in /etc/krb5.keytab files, and I am following the configuration instructions from http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that rick was kind enough to write (thanx rick!). Before analyzing my problem and configuration steps further, let me state the reason for this email: I am not able to access an nfsv3 mounted filesystem when mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's instructions, whereas in the past I had no such problem. To be more specific: Last time I was playing with the configuration most things worked fine (Feb 2010), but now things seem a bit different, and I am not sure whether I have forgotten something fundamental on my configuration or something has changed since I updated both my machines (client and server) to the latest sources: nfs-server: # uname -a FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep 15 17:07:13 EEST 2010 r...@fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER i386 nfs-client: # uname -a FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep 10 13:08:06 EEST 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT amd64 I have my two usual test-users on my test-machines, mamalos and testakis, who both exist as kerberos principals too; their uids and gids are the same on all machines. I am able to kinit to any of them on my machines and acquire a valid kerberos ticket, which makes me assume that kdc runs nicely. fbsd-client's /etc/rc.conf reads: rpcbind_enable=YES mountd_enable=YES mountd_flags=-e nfs_server_enable=YES nfs_client_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES gssd_enable=YES and fbsd-server's /etc/rc.conf reads: rpcbind_enable=YES nfs_client_flags=-n 4 rpc_statd_enable=YES rpc_lockd_enable=YES #nfsd_flags=-e gssd_enable=YES nfsuserd_enable=YES nfsclient_enable=YES # nfs server nfs_server_enable=YES mountd_enable=YES #mountd_flags=-e Don't get confused that both machines have nfsd enabled (the client is used as an experimental nfsv4 server too), and I think that this should not be an issue with regard to my problem (on the other hand, nobody knows...). the server's kernel-config reads: options KGSSAPI device crypto options NFSCL and the client's kernel-config reads: options NFSD #(don't forget that the client works as an nfsv4 server too) options KGSSAPI device crypto Lastly, the server's /etc/exports reads: /exports -alldirs -sec=krb5 on the server: # ls -la /exports total 10 drwxr-xr-x 5 root wheel - 512 17 Feb 2010 ./ drwxr-xr-x 22 root wheel - 512 15 Sep 19:33 ../ drwxr-xr-x 3 root wheel - 512 5 Feb 2010 m/ drwxr-xr-x 2 mamalos wheel - 512 16 Sep 15:43 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 2010 testakis/ on the client: # klist klist: No ticket file: /tmp/krb5cc_0 # mount mount_nfs -onfsv3,sec=krb5 server:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server:/exports on /mnt (nfs) # ls -la /mnt total 0 ls: /mnt: Permission denied # exit $ id uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel) $ klist klist: No ticket file: /tmp/krb5cc_1001 $ ls -la /mnt total 0 ls: /mnt: Permission denied $ kinit mamalos mama...@example's Password: $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example $ ls -la /mnt total 0 ls: /mnt: Permission denied ... (dooea?!?!?!!?) ... $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example Sep 16 16:27:51 Sep 17 02:26:49 nfs/ser...@example Normally the server will have a keytab entry for its fully qualified domain name like: nfs/fbsdclient.ee.auth...@example and if that is the case, the client is expected to use fbsdclient.ee.auth.gr as the server's name in the mount and not server (which I assume is an alias for the above). I'm definitely no kerberos wizard, but I'd guess that's where the problem is? (try kinit -k nfs/fbsdclient.ee.auth...@example on the server, to see that the keytab works.) The fully qualified domain name is used so that the keytab can't be moved to a different client and made to work easily, although a keytab entry is obviously weaker that a password based ccache entry. Beyond that, I'd suggest that you look in your KDC's logs to see what it thinks is going on when you try to access the mount point. rick ps: Btw, I haven't forgotten about the issue w.r.t. kdestroy not invalidating the handle in the client so that access
[releng_8 tinderbox] failure on ia64/ia64
TB --- 2010-09-16 14:50:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-16 14:50:13 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-09-16 14:50:13 - cleaning the object tree TB --- 2010-09-16 14:50:54 - cvsupping the source tree TB --- 2010-09-16 14:50:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-09-16 15:33:16 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-16 15:33:16 - ERROR: unable to cvsup the source tree TB --- 2010-09-16 15:33:16 - 0.89 user 33.59 system 2582.60 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: daily_scrub_zfs_enable is missing in /etc/defaults/periodic.conf
Quoting Thomas freebsdli...@bsdunix.ch (from Thu, 16 Sep 2010 14:01:05 +0200): Hello Is there an actual reason why daily_scrub_zfs_enable is missing in /etc/defaults/periodic.conf? Besides the fact that the authoritative source of information is the man-page: the 800.scrub-zfs is handling the defaults internally. More critical are entries in defaults/periodic.conf which are not described in the man-page. On my -current system: ---snip--- # for i in $(grep -v '^#' /etc/defaults/periodic.conf | grep = | tail +3 | head -94 | cut -d '=' -f 1); do grep -q $i periodic.txt|| echo $i not in man-page | egrep -v '_show_(success|info|badconfig)' done daily_status_zfs_enable not in man-page daily_status_mail_rejects_shorten not in man-page daily_status_ntpd_enable not in man-page daily_status_pkg_changes_enable not in man-page daily_status_security_logdir not in man-page daily_status_security_chkportsum_enable not in man-page daily_status_security_ipf6denied_enable not in man-page ---snip--- periodic.txt was generated via zcat /usr/share/man/man5/periodic.conf.5.gz | groff -Tascii -man -a ! periodic.txt Bye, Alexander. -- One reason why George Washington Is held in such veneration: He never blamed his problems On the former Administration. -- George O. Ludcke http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
At 11:18 AM 9/16/2010, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. Hi, I am booting off UFS right now so no bootcode updates for me :) I did look at UPDATING which does mention 20100915: A new version of ZFS (version 15) has been merged. This version uses a python library for the following subcommands: zfs allow, zfs unallow, zfs groupspace, zfs userspace. For full functionality of these commands the following port must be installed: sysutils/py-zfs ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
Dont forget to read the general ZFS notes section in UPDATING: ZFS notes - When upgrading the boot ZFS pool to a new version, always follow these two steps: 1.) recompile and reinstall the ZFS boot loader and boot block (this is part of make buildworld and make installworld) 2.) update the ZFS boot block on your boot drive The following example updates the ZFS boot block on the first partition (freebsd-boot) of a GPT partitioned drive ad0: gpart bootcode -p /boot/gptzfsboot -i 1 ad0 Non-boot pools do not need these updates. Dňa 16. 9. 2010 17:43, Mike Tancsa wrote / napísal(a): At 11:18 AM 9/16/2010, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. Hi, I am booting off UFS right now so no bootcode updates for me :) I did look at UPDATING which does mention 20100915: A new version of ZFS (version 15) has been merged. This version uses a python library for the following subcommands: zfs allow, zfs unallow, zfs groupspace, zfs userspace. For full functionality of these commands the following port must be installed: sysutils/py-zfs ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.1 + xorg + radeonhd hang
On Wed, 15 Sep 2010, Warren Block wrote: On Wed, 15 Sep 2010, Eivind E wrote: (WW) RADEONHD(0): !!! Option HPD is set !!! This shall only be used to work around broken connector tables. Please report your findings to radeo...@opensuse.org radeon doesn't have this option at all. (II) RADEONHD(0): Output VGA_1 using monitor section Skjerm Odd. Later on on it looks like it's using DVI-I_1/analog. See my xorg.conf for an example of tying monitors to specific outputs in the Device section. I tried your configuration file so both of these should be fine, however, I'm not quite sure what's correct for the Monitor-DVI-X when using the adaptor to vga which came with the card. The monitor is an old crt one. I'll try another card (not radeon) this evening, and if that works, I won't bother with the radeon anymore. This is my primary working machine and I need to be able to use it again. I do however wish to thank everybody for their hints and suggestions. -- _ _ // \\// Eivind Evensen \/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fbsd8_stable nfsv3 sys=krb5 issue
Hi Rick, glad to hearing from you, since we had a few relevant discussions in the past. On 16/9/2010 6:30 μμ, Rick Macklem wrote: Normally the server will have a keytab entry for its fully qualified domain name like: nfs/fbsdclient.ee.auth...@example and if that is the case, the client is expected to use fbsdclient.ee.auth.gr as the server's name in the mount and not server (which I assume is an alias for the above). I'm definitely no kerberos wizard, but I'd guess that's where the problem is? (try kinit -k nfs/fbsdclient.ee.auth...@example on the server, to see that the keytab works.) The aliases were written by me after copying the console's output on the email. I missed out the one you are stating in your email, and this is why I caused this confusion. All names mentioned in my email are in real called by their fqdn. The real machine names are fbsdclient.ee.auth.gr and filesrv.ee.auth.gr (but server and client are used the other way around) and my realm is EE.AUTH.GR. My /var/heimdal/kdc.log shows that all requests are handled without any problems (this is why I didn't mention it at all), and the configuration is the same as the one I was trying on Feb (subject: Kerberized NFSv3 incorrect behavior sent on Feb 5 2010) where everything seemed to work OK...or this is what I think it is, since probably I must be overseeing something important... The fully qualified domain name is used so that the keytab can't be moved to a different client and made to work easily, although a keytab entry is obviously weaker that a password based ccache entry. Beyond that, I'd suggest that you look in your KDC's logs to see what it thinks is going on when you try to access the mount point. rick ktutil -k /etc/krb5.keytab shows both keys on both servers. I haven't kinit'ed to the keytabs on the server, but when I do so I will inform you about my output (sadly I don't have access on my machines at the moment). The thing is that kdc.log shows that all keys are exchanged correctly and no exceptions are thrown... Hence, I am afraid that kerberos-config is not the problem for my case, but if you or anybody else cannot see anything wrong with the rest of my config, I will have to reconfigure both server and client from scratch, step-by-step to make it work again (I hoped to avoid this step through sending this email on the list) ps: Btw, I haven't forgotten about the issue w.r.t. kdestroy not invalidating the handle in the client so that access continues to work until the handle times out, but I haven't gotten around to fixing it. No problem!! I understand that everybody's time is precious. It is more than enough that you even remember it (I had forgotten it myself:-) ) Thanx again for the time and help. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 8.1 Stable Unreasanoble Rebooting
Today I've got a pretty strange event. It looks like a reboot but unreasonable as far as I see. Before server's uptime was over month, it's sometimes have to reboot for kernel updates or somethings like that. I've digen all logs and didn't find a reason, so here they all. auth.log Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating. Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port 22442. cron - nothing debug.log - nothing dmesg - nothing messages Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create socket: Protocol not supported (fdlimit.c:651) Sep 16 13:45:31 diablo last message repeated 5 times Sep 16 13:47:23 diablo last message repeated 13 times Sep 16 13:57:40 diablo last message repeated 51 times Sep 16 13:59:48 diablo last message repeated 12 times Sep 16 14:00:18 diablo named[1575]: stopping command channel on 127.0.0.1#953 Sep 16 14:00:18 diablo named[1575]: exiting Sep 16 14:00:18 diablo syslogd: exiting on signal 15 Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD Project. Sep 16 14:02:31 diablo kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Sep 16 14:02:31 diablo kernel: The Regents of the University of California. All rights reserved. Sep 16 14:02:31 diablo kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Sep 16 14:02:31 diablo kernel: FreeBSD 8.1-STABLE #1 r210501M: Sat Sep 4 11:08:44 MSD 2010 Sep 16 14:02:31 diablo kernel: amd_m...@diablo.miekoff.local:/usr/obj/usr/src/sys/DIABLO64 amd64 Sep 16 14:02:31 diablo kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Sep 16 14:02:31 diablo kernel: CPU: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz (2799.98-MHz K8-class CPU) Sep 16 14:02:31 diablo kernel: Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Sep 16 14:02:31 diablo kernel: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Sep 16 14:02:31 diablo kernel: Features2=0x408e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE Sep 16 14:02:31 diablo kernel: AMD Features=0x20100800SYSCALL,NX,LM Sep 16 14:02:31 diablo kernel: AMD Features2=0x1LAHF Sep 16 14:02:31 diablo kernel: TSC: P-state invariant Sep 16 14:02:31 diablo kernel: real memory = 2147483648 (2048 MB) Sep 16 14:02:31 diablo kernel: avail memory = 2051534848 (1956 MB) Sep 16 14:02:31 diablo kernel: ACPI APIC Table: A_M_I_ OEMAPIC Sep 16 14:02:31 diablo kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Sep 16 14:02:31 diablo kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Sep 16 14:02:31 diablo kernel: cpu0 (BSP): APIC ID: 0 Sep 16 14:02:31 diablo kernel: cpu1 (AP): APIC ID: 1 Sep 16 14:02:31 diablo kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard Sep 16 14:02:31 diablo kernel: wlan: mac acl policy registered Sep 16 14:02:31 diablo kernel: kbd1 at kbdmux0 Sep 16 14:02:31 diablo kernel: ichwd module loaded Sep 16 14:02:31 diablo kernel: cryptosoft0: software crypto on motherboard Sep 16 14:02:31 diablo kernel: acpi0: A_M_I_ OEMXSDT on motherboard Sep 16 14:02:31 diablo kernel: acpi0: [ITHREAD] Sep 16 14:02:31 diablo kernel: acpi0: Power Button (fixed) Sep 16 14:02:31 diablo kernel: acpi0: reservation of 0, a (3) failed Sep 16 14:02:31 diablo kernel: acpi0: reservation of 10, 7f70 (3) failed Sep 16 14:02:31 diablo kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Sep 16 14:02:31 diablo kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 Sep 16 14:02:31 diablo kernel: cpu0: ACPI CPU on acpi0 Sep 16 14:02:31 diablo kernel: ACPI Warning: Incorrect checksum in table [OEMB] - 0x3A, should be 0x2D (20100331/tbutils-354) Sep 16 14:02:31 diablo kernel: cpu1: ACPI CPU on acpi0 Sep 16 14:02:31 diablo kernel: acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Sep 16 14:02:31 diablo kernel: Timecounter HPET frequency 14318180 Hz quality 900 Sep 16 14:02:31 diablo kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Sep 16 14:02:31 diablo kernel: pci0: ACPI PCI bus on pcib0 Sep 16 14:02:31 diablo kernel: vgapci0: VGA-compatible display port 0x8800-0x8807 mem 0xdfd0-0xdfd7,0xe000-0xefff,0xdfd8-0xdfdb irq 16 at device 2.0 on pci0 Sep 16 14:02:31 diablo kernel: agp0: Intel 82945G (945G GMCH) SVGA controller on vgapci0 Sep 16 14:02:31 diablo kernel: agp0: detected 7932k stolen memory Sep 16 14:02:31 diablo kernel: agp0: aperture size is 256M Sep 16 14:02:31 diablo kernel: pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 Sep 16 14:02:31 diablo kernel: pci3: ACPI PCI bus on pcib1 Sep 16 14:02:31 diablo kernel: pcib2: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 Sep 16 14:02:31 diablo kernel: pci2: ACPI PCI bus on pcib2 Sep 16 14:02:31 diablo kernel: ae0: Attansic Technology Corp, L2 FastEthernet mem
Re: Strange video mode output with VESA
2010/9/16 David DEMELIER demelier.da...@gmail.com: 2010/7/19 Jung-uk Kim j...@freebsd.org: On Friday 16 July 2010 07:18 pm, Jung-uk Kim wrote: On Friday 16 July 2010 03:22 pm, Jung-uk Kim wrote: On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: 2010/6/19 paradox ddkp...@yahoo.com: On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all : the lines are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. �If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. �When you move the mouse onto the line, entire line is redrawn and restored. �That's what you are seeing. �Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- No, I didn't say that. What I meant was Ed may be a better qualified person to fix syscons vs. terminal emulator interaction issues. :-( Can you please try the attached patch? FYI, I just went ahead and committed a (slightly better) patch on head as r210248. It will be MFC'ed soon. Jung-uk Kim Sorry, I completely forgot this thread, I tried your patch, it didn't solved the problem but the offset is shorter now, only 2 or 3 characters per line are bad positionned. I will try the r210248 revision, this revision only applies to the file scvgarndr.c ? Thanks. -- Demelier David I tried the r210248 revision but it doesn't works, I still have a little offset but less than without the patch. Kind regards, -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1 Stable Unreasanoble Rebooting
On Thu, Sep 16, 2010 at 08:37:29PM +0400, Michael BlackHeart wrote:
Today I've got a pretty strange event. It looks like a reboot but
unreasonable as far as I see. Before server's uptime was over month,
it's sometimes have to reboot for kernel updates or somethings like
that. I've digen all logs and didn't find a reason, so here they all.
auth.log
Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating.
Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port 22442.
cron - nothing
debug.log - nothing
dmesg - nothing
messages
Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create
socket: Protocol not supported (fdlimit.c:651)
Sep 16 13:45:31 diablo last message repeated 5 times
Sep 16 13:47:23 diablo last message repeated 13 times
Sep 16 13:57:40 diablo last message repeated 51 times
Sep 16 13:59:48 diablo last message repeated 12 times
Sep 16 14:00:18 diablo named[1575]: stopping command channel on 127.0.0.1#953
Sep 16 14:00:18 diablo named[1575]: exiting
Sep 16 14:00:18 diablo syslogd: exiting on signal 15
Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel
Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD Project.
{...}
This sure looks like a legitimate reboot to me (e.g. shutdown -r now);
note how your system daemons (named, syslogd) are being shut down with
SIGTERM. You can check with last (shutdown/reboot vs. crash).
paranoid
I would highly recommend taking this machine offline and reinstalling
the OS, in addition to newfs'ing all existing filesystems (restore from
last known good backup). buildworld/installworld and
buildkernel/installkernel may not be enough depending on what the
individual did. It's likely the machine could be compromised in some
way, especially if there's any service on it which is public-facing,
regardless of authentication mechanisms you've deployed in front of it.
/paranoid
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on powerpc/powerpc
TB --- 2010-09-16 15:30:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-16 15:30:11 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-09-16 15:30:11 - cleaning the object tree TB --- 2010-09-16 15:30:37 - cvsupping the source tree TB --- 2010-09-16 15:30:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-09-16 15:48:06 - building world TB --- 2010-09-16 15:48:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-16 15:48:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-16 15:48:06 - TARGET=powerpc TB --- 2010-09-16 15:48:06 - TARGET_ARCH=powerpc TB --- 2010-09-16 15:48:06 - TZ=UTC TB --- 2010-09-16 15:48:06 - __MAKE_CONF=/dev/null TB --- 2010-09-16 15:48:06 - cd /src TB --- 2010-09-16 15:48:06 - /usr/bin/make -B buildworld World build started on Thu Sep 16 15:48:06 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Sep 16 16:52:48 UTC 2010 TB --- 2010-09-16 16:52:48 - generating LINT kernel config TB --- 2010-09-16 16:52:48 - cd /src/sys/powerpc/conf TB --- 2010-09-16 16:52:48 - /usr/bin/make -B LINT TB --- 2010-09-16 16:52:48 - building LINT kernel TB --- 2010-09-16 16:52:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-16 16:52:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-16 16:52:48 - TARGET=powerpc TB --- 2010-09-16 16:52:48 - TARGET_ARCH=powerpc TB --- 2010-09-16 16:52:48 - TZ=UTC TB --- 2010-09-16 16:52:48 - __MAKE_CONF=/dev/null TB --- 2010-09-16 16:52:48 - cd /src TB --- 2010-09-16 16:52:48 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Sep 16 16:52:48 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Thu Sep 16 17:12:30 UTC 2010 TB --- 2010-09-16 17:12:30 - building GENERIC kernel TB --- 2010-09-16 17:12:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-16 17:12:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-16 17:12:30 - TARGET=powerpc TB --- 2010-09-16 17:12:30 - TARGET_ARCH=powerpc TB --- 2010-09-16 17:12:30 - TZ=UTC TB --- 2010-09-16 17:12:30 - __MAKE_CONF=/dev/null TB --- 2010-09-16 17:12:30 - cd /src TB --- 2010-09-16 17:12:30 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Thu Sep 16 17:12:30 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/md5c.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/p1003_1b.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/posix4_mib.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -msoft-float -mno-altivec -ffreestanding
Re: MFC of ZFSv15
On 09/16/2010 17:18, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. I was bitten by this problem in a previous ZFS upgrade. To be sure, I have added this patch to zfsimpl.c so, at boot I know if zpool/zfs upgrade will be OK. Henri Regards, UPDATING should have anything else. Index: sys/boot/zfs/zfsimpl.c === --- sys/boot/zfs/zfsimpl.c (revision 212549) +++ sys/boot/zfs/zfsimpl.c (working copy) @@ -61,6 +61,8 @@ STAILQ_INIT(zfs_vdevs); STAILQ_INIT(zfs_pools); + printf(ZFS: supported version %u\n, (unsigned) SPA_VERSION); + zfs_temp_buf = malloc(TEMP_SIZE); zfs_temp_end = zfs_temp_buf + TEMP_SIZE; zfs_temp_ptr = zfs_temp_buf; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.1 + xorg + radeonhd hang
On Thu, 16 Sep 2010 18:20:35 +0200 (CEST), Eivind E eivi...@terraplane.org wrote: I'll try another card (not radeon) this evening, and if that works, I won't bother with the radeon anymore. This is my primary working machine and I need to be able to use it again. I do however wish to thank everybody for their hints and suggestions. I've had a similar (but not the same problem). My card is an RS880 [Radeon HD 4200] on an Asus M4A785-M motherboard. Problem here was that with either the radeonhd or the ati driver and the radeon.ko module loaded, performance was very slow indeed. One could see the windows being repainted, and xterm scroll was like a 1970's 1200 baud terminal! I found that renaming the radeon.ko module so that it would not be found when X.org goes to auto-load it, then unloading it and restarting X gave me normal performance. However, that came without the benefit of xvideo support. Finally I tried the radeonhd driver from the experimental port in x11-drivers/xf86-video-radeonhd-devel. This works perfectly for me: good performance AND xvideo support. Maybe this will help you too... -jr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1 Stable Unreasanoble Rebooting
2010/9/16 Jeremy Chadwick free...@jdc.parodius.com:
On Thu, Sep 16, 2010 at 08:37:29PM +0400, Michael BlackHeart wrote:
Today I've got a pretty strange event. It looks like a reboot but
unreasonable as far as I see. Before server's uptime was over month,
it's sometimes have to reboot for kernel updates or somethings like
that. I've digen all logs and didn't find a reason, so here they all.
auth.log
Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating.
Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port 22442.
cron - nothing
debug.log - nothing
dmesg - nothing
messages
Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create
socket: Protocol not supported (fdlimit.c:651)
Sep 16 13:45:31 diablo last message repeated 5 times
Sep 16 13:47:23 diablo last message repeated 13 times
Sep 16 13:57:40 diablo last message repeated 51 times
Sep 16 13:59:48 diablo last message repeated 12 times
Sep 16 14:00:18 diablo named[1575]: stopping command channel on 127.0.0.1#953
Sep 16 14:00:18 diablo named[1575]: exiting
Sep 16 14:00:18 diablo syslogd: exiting on signal 15
Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel
Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD Project.
{...}
This sure looks like a legitimate reboot to me (e.g. shutdown -r now);
note how your system daemons (named, syslogd) are being shut down with
SIGTERM. You can check with last (shutdown/reboot vs. crash).
paranoid
I would highly recommend taking this machine offline and reinstalling
the OS, in addition to newfs'ing all existing filesystems (restore from
last known good backup). buildworld/installworld and
buildkernel/installkernel may not be enough depending on what the
individual did. It's likely the machine could be compromised in some
way, especially if there's any service on it which is public-facing,
regardless of authentication mechanisms you've deployed in front of it.
/paranoid
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
That looks reasonable
last says:
reboot ~ th 16 sen 14:04
reboot ~ th 16 sen 14:03
shutdown ~ th 16 sen 13:59
and it's pretty good syncs with logs but there's no anybody access to
physical console 'cos it's not even plugged in. That's for the first.
Next, I've got, I believe, pretty strong passwords, and also root
can't log in directly, but wheel user also is in operators so he also
can reboot or shutdown, but there's no any attempts or successful
logins. All potentialy dangerous services run under their own
unprerileged users, and so on. Crontabs also doesn't contain scripts,
I prefer periodic system, and there's no anyway anything that cause
reboot.
Thing that worries me it that there were multiple reboots and shutdown
that goes up by itself without anyone pressing a button. And in
messages log there's fsck segment that indicates to unnormal shutdown
or reboot. It looks like it started to shutting down but was in some
case interrupted and after powering up it few times reboots itself.
But commonly FreeBSD doesn't reboot by it's own will.
The same hardware worked over a half a year under 8.0 stables without
such a problem. I just would like to understand from where this
problem comes up.
This machine doesn't contain any critical info so I'll wait for a bit.
Also I'd like to notice that recently I've tuned hdd's spindown exept
system hdd by atacontrol port, powerd and CPU frequency lowering in
idle, maybe something of this could cause this problem? And where
could I check this out?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.1 + xorg + radeonhd hang
On Thu, 16 Sep 2010, Eivind E wrote: On Wed, 15 Sep 2010, Warren Block wrote: On Wed, 15 Sep 2010, Eivind E wrote: (WW) RADEONHD(0): !!! Option HPD is set !!! This shall only be used to work around broken connector tables. Please report your findings to radeo...@opensuse.org radeon doesn't have this option at all. (II) RADEONHD(0): Output VGA_1 using monitor section Skjerm Odd. Later on on it looks like it's using DVI-I_1/analog. See my xorg.conf for an example of tying monitors to specific outputs in the Device section. I tried your configuration file so both of these should be fine, however, I'm not quite sure what's correct for the Monitor-DVI-X when using the adaptor to vga which came with the card. The monitor is an old crt one. The port names are specific to the driver. I'd guess it should be Option Monitor-DV-I_1 Skjerm ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.1 + xorg + radeonhd hang
On Thu, 16 Sep 2010, J.R. Oldroyd wrote: Finally I tried the radeonhd driver from the experimental port in x11-drivers/xf86-video-radeonhd-devel. This works perfectly for me: good performance AND xvideo support. I tried this driver aswell, it still locked up. I've replaced the card with an nvidia now which behaves almost as the radeon did a year ago; I can start X once, when starting it for a second time it freezes. For now, I will have to make do with that, I need the machine for regular use. All of these problems sure makes me miss the Amiga, where the hardware was known and worked good as long as it didn't have defects in the hardware itself. Whether you used the system libs or banged the hardware directly, there were simply not that many configurations to consider. -- _ _ // \\// Eivind Evensen \/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.1 + xorg + radeonhd hang
On Thu, 16 Sep 2010, Warren Block wrote: The port names are specific to the driver. I'd guess it should be Option Monitor-DV-I_1 Skjerm Thanks, I'll make a note of it if I put the card back to check it later on. -- _ _ // \\// Eivind Evensen \/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-stable Digest, Vol 374, Issue 5
Sweet. What were you doin'? On 09/16/2010 05:02 AM, freebsd-stable-requ...@freebsd.org wrote: Re: very stupid mistake: a part of /usr is deleted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: very stupid mistake: a part of /usr is deleted
On Wed, Sep 15, 2010 at 6:43 PM, Bartosz Stec ad...@kkip.pl wrote: On 2010-09-15 17:20, Ivan Voras wrote: uname -a - FreeBSD (XX).uni-tuebingen.de 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 That is actually an easy situation to recover, you can do it in at least these ways: 1) if you build/upgrade from source, you can either reinstall if you have working /usr/obj or try and rebuild them if you have working /usr/src (...) This is a solution I would recommend (if time isn't the problem), first csup fresh 8.X sources, rebuild, upgrade, and as a result you will get more than missing files, but 8.1-RELASE + STABLE patches :). Maybe installing the files from the live-CD in single-user mode is easier at this point... ... especially if some crucial files (/usr/bin/csup, /usr/bin/cc, /usr/bin/gcc, /usr/bin/install, /usr/bin/tar etc...) are missing (and thus preventing csup, build, install). THEN, with the old /usr/bin/* files reinstalled from media, source-upgrading with csup / make buildworld etc... is the way to go. But ivoras@ is right: restoring /usr/bin is pretty easy nonetheless. -- Bartosz Stec -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: very stupid mistake: a part of /usr is deleted
On Wed, 15 Sep 2010, Ivan Voras wrote:
[..]
That is actually an easy situation to recover, you can do it in at least
these ways:
1) if you build/upgrade from source, you can either reinstall if you have
working /usr/obj or try and rebuild them if you have working /usr/src
2) if you have another machine with the same FreeBSD version and
architecture, simply copy the missing files (with tar, scp, ftp, fetch/wget,
etc...)
3) if you have networking and at least working fetch / ftp / wget, cat and
tar, you can fetch the files at
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.0-RELEASE/base/ and use
install.sh to reinstall the base binaries
Remember that those files are not magical, you can restore them any way you
are able. You can even boot the live CD (from
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.0/), mount the
appropriate file system and copy the files from the CD.
1) and 3) look good, but 2) - except tar - or cp'ing files from the CD
won't preserve hard links, of which there are quite a few in /usr/bin,
that install.sh takes care of: tar --unlink -xpzf - -C ${DESTDIR:-/}
Apart from the few megs of extra space used, I wonder if that matters,
especially regarding later updates that may replace some of those files?
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
