Re: bugs in mpt(4) and mptutil(8)
On Wed, 10 Feb 2010 08:53:18 -0500 John Baldwin j...@freebsd.org wrote about Re: bugs in mpt(4) and mptutil(8): JB This output is definitely wrong, because the drives are split up on JB mpt0 and mpt1 (and the USB stick is not connected to mpt at all :-) JB as can be seen with camcontrol: JB Hmm, I asked the previous reporter to debug this by examining the JB results that CAM returns from the bus scan using gdb, but I haven't JB heard back. Unfortunately I do not have access to any hardware with JB this sort of setup to debug this. I will do some debugging work here, if you can tell me what to do. cu Gerrit ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Martin Kristensen pciconf.out Description: Binary data ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... While that would make sense... And it might work more like that once I implement TTM/KMS (actually the whole memory requirements will change as pages will then get mapped in and out of the gart), but currently, the allocation of scatter gather memory to populate the gart is driven by userland. The only memory that is pre-allocated by the driver is the sarea, and the register maps are pre-allocated, but that is just address mapping. For everything else, userland tells us when and how much memory to allocate. On radeon (and Intel for that matter) most if not all cards can reference anything that the cpu can, (up to at least 36 bits, iirc, or maybe 40) so I might drop the 4GB limit. However, since all of this is done in the generic drm code, I don't actually know what card I'm allocating memory for when I do it, so I won't change that part until I need to. I'll try and get a cleaned up patch of the scatter gather rework out this weekend. I've abandoned the use of bus_dma entirely for allocating SG pages and interact with the VM directly, thus avoiding the contiguous requirements of bus_dma. robert. But it's your call, you obviously know more about this than me anyway :) Bye, Uli -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. Sorry, I did not understand what you wanted, here is sysctl hw.dri: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags addressmtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 00 00 hw.dri.0.debug: 0 If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Martin Kristensen ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On Wednesday 10 February 2010 1:38:37 pm Ivan Voras wrote: On 10 February 2010 19:35, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:26 Ivan Voras said the following: On 10 February 2010 19:10, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. I haven't said that those OSes do not use large pages. I've said what I've said :-) Ok :) Is there a difference between large pages as they are commonly known and superpages as in FreeBSD ? In other words - are you referencing some specific mechanism, like automatic promotion / demotion of the large pages or maybe something else? Yes, the automatic promotion / demotion. That is a far-less common feature. FreeBSD/i386 has used large pages for the kernel text as far back as at least 4.x, but that is not the same as superpages. Linux does not have automatic promotion / demotion to my knowledge. I do not know about other OS's. -- John Baldwin ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
on 11/02/2010 06:37 Alan Cox said the following: Here is what I know. Several of us, myself included, have been able to reproduce either lockups or machine check exceptions when BOTH the machine check driver and superpages are enabled on AMD family 10h processors. There have been no reports of this problem on either Intel or earlier AMD processors. Moreover, there is no evidence of instability in AMD family 10h processors until the machine check driver is enabled. By default, FreeBSD 8.0 enables superpages but disables the machine check driver. So, running natively, i.e., without virtualization, you shouldn't experience a problem, unless you explicitly enable the machine check driver. However, running on top of a hypervisor, like vSphere 4, you might face a problem because the hypervisor might enable machine check exceptions, regardless of what the FreeBSD guest does. I really don't know whether vSphere 4 enables machine check exception or not. If it does, then either you disable the use of superpages in the FreeBSD guest, or you find a way to disable the machine check driver in the hypervisor. I'd like to mention another possibility, just in case: machine check might be enabled/done by firmware (e.g. BIOS). This typically could be the case for high-end-ish/server systems. -- Andriy Gapon ___ 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: numeric sort(1) is broken on -STABLE
On Thu, Feb 11, 2010 at 08:40:51AM +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 15:00:07 -0600, Dan Nelson wrote: In the last episode (Feb 10), Ulrich Spörlein said: On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: not sure if this is a pilot error, but it seems to me that gnu sort -n is broken on at least -STABLE (couldn't test -CURRENT yet). It somehow does not manifest when using a simple list and sorting on a specific column, but it always happens to me when using it in combination with find(1). % truncate -s10m a; truncate -s5m b; truncate -s800k c % find a b c -ls|sort -nk7,7 8 64 -rw-r--r--1 uqs wheel 10485760 Feb 10 09:13 a 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c I bet you're using some non-C locale for LC_NUMERIC. What does locale output tell you? Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as there are no non-ASCII symbols in that output it shouldn't matter, right? For me, 819200 is smaller than 10485760 in pretty much all locales. Why the hell is a numeric gnusort locale dependant? Why is -g working anyway? Try adding a 'b' to your sort flags. I bet the leading spaces in front of your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 and C have different ideas of what is whitespace? Indeed, 'b' is working too. So I've stocked up on the number of workarounds for this problem. What amazes me, is that no one seems to be as shocked as I to find out something basic like sorting on a number is not DTRT. It is a long standing issue with Russian locales as well, but there the problem manifests itself only with LC_NUMERIC, not LC_CTYPE. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen m...@pc.dk wrote: On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. Sorry, I did not understand what you wanted, here is sysctl hw.dri: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags address mtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 00 00 hw.dri.0.debug: 0 If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. Alas, I have crashed it a couple of times and left it for ~30 min. There was no change, and I got no core dump. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Martin Kristensen
Re: Kerberized NFSv3 incorrect behavior
On 6 Feb 2010, at 09:44, George Mamalakis wrote: Rick Macklem wrote: On Fri, 5 Feb 2010, George Mamalakis wrote: Dear all, I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My configuration is based on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is to share filesystems securely through kerberos authentication. Everything works fine, until I try to kdestroy my tickets or kinit to some other user, where the system insists to think that I am the user that initially obtained their ticket. To be more extensive, my story is as follows: [good stuff snipped] and both client and server have the correct entries about each other (and themselves) in their /etc/hosts, so heimdal works just fine. Both client and server have their respective keytabs stored in /etc/krb5.keytab, and I use two users in my example (that both exist in both systems with the same uid,gid): mamalos and testakis. Unless you have applied the experimental patch, a keytab entry is meaningless in the client. Without that, it was assumed that root would never kinit as anyone. Basically, it was assumed that root would only do the mount and a user, like mamalos or testakis would be logged in and kinit'd as that user. The short answer is that any principal with TGT in the credentials cache for uid==N will be used to authenticate that user. Once authenticated, that handle for the user can be used until it expires (up to the server, but usually set to when the TGT that it found in the credential cache is due to expire). So, when I mount the exported filesystem on the client giving: # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server.example.com:/exports on /mnt (nfs) and try to access the share: # ls /mnt ls: mnt: Permission denied I get the error I am expecting, since root does not have any kerberos tickets assigned, yet. Let's see what happens when I kinit as mamalos: Yep, as expected. # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: mama...@example.com Issued Expires Principal Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/exapmle@example.com # ls -la /mnt/ total 8 drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ drwx-- 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 19:06 testakis/ # touch /mnt/mamalos/myfile # ls -la /mnt/mamalos/myfile rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile Which is the exact behavior that is expected. Now when I kdestroy: # kdestroy # klist klist: No ticket file: /tmp/krb5cc_0 # touch /mnt/mamalos/myfilethatshouldnotbe # ls -la /mnt/mamalos/myfilethatshouldnotbe -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 /mnt/mamalos/myfilethatshouldnotbe Yes, this is a bug/limitation in the current implementation. I believe that kdestroy should do some sort of system call to inform the NFS client that credentials for uid==N should be invalidated. This is not implemented in FreeBSD8 (or Linux for that matter, last I checked). I don't know if dfr@ was planning on doing this and whether or not he thinks it is appropriate to do so? Without that implemented, the handle continues to work until the server expires it, normally when the TGT for mamalos would have expired if you hadn't kdestroy'd it. And I can do everything in that share as if I were still mamalos, even though I kdestroyed my kerberos ticket. The same thing will happen even if I kinit to testakis after that. klist shows testakis' ticket this time, but I am not allowed to access (rwx) tetakis' files/folders, and I still have full control over mamalos' files and folders. In order to be able to do something as testakis, I have to unmount the share and remount it while having testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). Actually, logging in as testakis should allow that user to access the mount as testakis once kinit'd as testakis. The trick is that the credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the uid assigned to testakis). Same would apply to mamalos if that user were logged in with a non-0 uid. I am not an NFS expert, but I suppose that this behavior is not the one to be expected, except if I am missing some fundamental information about kerberized NFS that explains it. Even so, it would be quite unwise to behave so, since even if the users kdestroys their tickets, they have still all permissions as when they obtained their ticket. Yes, as noted above, I believe that kdestroy should get rid of the Kerberized NFS handles for the corresponding uid. It's on my to discuss with dfr and maybe do list, but unfortunately not near the top of it. (I'd also like to come up with a good way to do
Re: 7.3-P r203700: what can I do about psm0: the aux device is gone!
On Tue, 9 Feb 2010 17:41, david@ wrote: I normally run X11 (via xdm) on my laptop. Today, running FreeBSD 7.3-PRERELEASE as of r203700, the mouse stopped moving. Logging in from a pty checking the last bit of /var/log/messages showed: Feb 9 14:30:27 localhost kernel: kbdc: TEST_AUX_PORT status: Feb 9 14:30:27 localhost kernel: kbdc: RESET_AUX return code:00fa Feb 9 14:30:27 localhost kernel: kbdc: RESET_AUX status: Feb 9 14:30:27 localhost kernel: kbdc: DIAGNOSE status:0055 Feb 9 14:30:27 localhost kernel: kbdc: TEST_KBD_PORT status: Feb 9 14:30:27 localhost kernel: psm0: failed to reset the aux device. Feb 9 14:30:27 localhost kernel: psm0: the aux device has gone! (reinitialize). uname output: FreeBSD localhost 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #56 r203700: Tue Feb 9 05:31:36 PST 2010 r...@g1-136.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY i386 So far, the least disruptive form of evasive action I've found is a reboot, which is quite a bit more disruptive than I'd prefer. Help? Thanks! Peace, david High David, I'm assuming that you've checked to make sure that moused is running after psm has disappeared ?. As a somewhat workaround until the cause of this problem can be determined you could setup a cronjob as root to check for moused and if not found restart it. Add moused_port=/dev/ums? to /etc/rc.conf and replace ? with corresponding device number. Add the following to /etc/crontab pgrep moused ||service moused restart Of course this does not detect which moused is running and for what device so some adjustment might be needed there if you have more then one moused running at a time usually. Good Luck. -- jhell ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 17:41 +0100, Martin Kristensen wrote: On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen m...@pc.dk wrote: On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. Sorry, I did not understand what you wanted, here is sysctl hw.dri: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags address mtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 00 00 hw.dri.0.debug: 0 If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. Alas, I have crashed it a couple of times and left it for ~30 min. There was no change, and I got no core dump. Hrm, ok... I'll try to dig into it this weekend... robert. If it will help, I can switch to
Re: 7.3-P r203700: what can I do about psm0: the aux device is gone!
On Thu, Feb 11, 2010 at 12:05:45PM -0500, jhell wrote: ... Feb 9 14:30:27 localhost kernel: psm0: failed to reset the aux device. Feb 9 14:30:27 localhost kernel: psm0: the aux device has gone! (reinitialize). ... So far, the least disruptive form of evasive action I've found is a reboot, which is quite a bit more disruptive than I'd prefer. Help? ... I'm assuming that you've checked to make sure that moused is running after psm has disappeared ?. I have verifies that it is not, in fact, running: it exits when its device disappears. As a somewhat workaround until the cause of this problem can be determined you could setup a cronjob as root to check for moused and if not found restart it. Except that it won't start without a (detectable) device. Add moused_port=/dev/ums? to /etc/rc.conf and replace ? with corresponding device number. No USB rodents on my laptop. :-} Add the following to /etc/crontab pgrep moused ||service moused restart Of course this does not detect which moused is running and for what device so some adjustment might be needed there if you have more then one moused running at a time usually. The touchpad/trackpoint show up as a single /dev/psm0, as far as I can tell: d254(7.3-P)[1] ls -lT /dev/psm* crw-rw-rw- 1 root wheel0, 56 Feb 11 08:03:06 2010 /dev/psm0 d254(7.3-P)[2] grep -C 5 psm /var/run/dmesg.boot pcm0: clone manager: deadline=750ms flags=0x801e pcm0: sndbuf_setmap 7db4, 4000; 0xc527d000 - 7db4 pcm0: sndbuf_setmap 7db44000, 4000; 0xc5281000 - 7db44000 pci0: simple comms, generic modem at device 31.6 (no driver attached) acpi_tz0: Thermal Zone on acpi0 psmcpnp0: PS/2 mouse port irq 12 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:, flags:0008, packet size:3 psm0: syncmask:c0, syncbits:00 speaker0: PC speaker port 0x61,0x63,0x65,0x67 on acpi0 fdc0: floppy drive controller (FDE) port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [FILTER] sio0: irq maps: 0x201 0x211 0x201 0x201 d254(7.3-P)[3] Good Luck. ... Thanks. :-} Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpLTW6gUfHRg.pgp Description: PGP signature
Problem with USB wireless keyboard/mouse (7-STABLE / GENERIC)
Some additional information Same problem now with latest 7-STABLE (two days ago) compiled with GENERIC kernel settings. instead of Unknown USB device I now get the dreaded SHORT_XFER-Error. Apart from that still same behaviour. Anything else I can do? On Tue, Feb 09, 2010 at 07:20:05PM +0100, Holger Kipp wrote: My son bought a wireless USB deskset (keyboard and mouse) from TRUST. Of course it does not work with freebsd 7.1 (I am currently updating to 7-STABLE just in case). Anyway, here the problem with TRUST Wireless Deskset: Feb 8 22:00:32 TheSimpsons root: Unknown USB device: vendor 0x04fc product 0x05d8 bus uhub3 Feb 8 22:00:37 TheSimpsons kernel: uhub3: port 2, set config at addr 2 failed Feb 8 22:00:37 TheSimpsons kernel: uhub3: device problem (TIMEOUT), disabling port 2 any ideas? There is nothing else showing up. Interestingly, the keyboard is working within BIOS without problems. Same problem with and without ACPI and switching on legacy mode in BIOS does not help either. Keyboard is the german version, Item number 16595. If I can provide anything else, please let me know. Best Regards, Holger ___ 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: zpool vdev vs. glabel
Use gpart and add created partition to your raidz- for example [code] backupstorage# gpart create -s GPT ad0 backupstorage# gpart add -b 34 -s 1953525101 -i 1 -t freebsd-zfs -l disk0 ad0 backupstorage# gpart show =34 1953525101 da0 GPT (932G) 34 19535251011 freebsd-zfs (932G) backupstorage# gpart show -l =34 1953525101 da0 GPT (932G) 34 19535251011 disk0 (932G) backupstorage# ls /dev/gpt disk0 backupstorage# zpool status -v pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storageONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 gpt/disk6 ONLINE 0 0 0 gpt/disk7 ONLINE 0 0 0 [code] Try to remove and insert disks- all it should happy =) PS: sorry for my english =) Gerrit Kühn пишет: Hi, I have created a raidz2 with disk I labeled with glabel before. Right after creation this pool looked fine, using devices label/tank[1-6]. I did some tests with replacing/swapping disks and so on. After doing a zpool offline tank label/tank6 remove disk camcontrol rescan all insert disk camcontrol rescan all zpool online tank label/tank6 I got the disk back, but not under the requested label, but under the da device name: pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/tank1 ONLINE 0 0 0 8.50K resilvered label/tank2 ONLINE 0 0 0 7.50K resilvered label/tank3 ONLINE 0 0 0 8.50K resilvered label/tank4 ONLINE 0 0 0 7.50K resilvered label/tank5 ONLINE 0 0 0 9K resilvered da6 ONLINE 0 0 0 13.5K resilvered errors: No known data errors Why does this happen? Is there any way to get zfs to use the label again? After the device is in use, the label in /dev/label disappears. When taking the device offline again, the label is there, but cannot be used: pigpen# zpool offline tank da6 pigpen# zpool status pool: system state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:49:14 2010 config: NAME STATE READ WRITE CKSUM system ONLINE 0 0 0 mirror ONLINE 0 0 0 label/system1 ONLINE 3 617 0 126K resilvered label/system2 ONLINE 0 0 0 41K resilvered errors: No known data errors pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 label/tank1 ONLINE 0 0 0 8.50K resilvered label/tank2 ONLINE 0 0 0 7.50K resilvered label/tank3 ONLINE 0 0 0 8.50K resilvered label/tank4 ONLINE 0 0 0 7.50K resilvered label/tank5 ONLINE 0 0 0 9K resilvered da6 OFFLINE 038 0 13.5K resilvered errors: No known data errors pigpen# ll /dev/label/ total 0 crw-r- 1 root operator0, 104 Feb 9 14:04 lisacrypt1 crw-r- 1 root operator0, 112 Feb 9 14:04 lisacrypt2 crw-r- 1 root operator0, 113 Feb 9 14:04 lisacrypt3 crw-r- 1 root operator0, 134 Feb 9 14:48 system1 crw-r- 1 root operator0, 115 Feb 9 14:04 system2 crw-r- 1 root operator0, 116 Feb 9 14:04 tank1 crw-r- 1 root operator0, 117 Feb 9 14:04 tank2 crw-r- 1 root operator0, 118 Feb 9 14:04 tank3 crw-r-
ping: sendto: Can't assign requested address
Hello my friends! Help me please with its problem. I`m don`t what it is
problem...
*mx# uname -a*
FreeBSD mx.taricat.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Jan 25 09:28:38
UTC 2010 r...@mx.taricat.ru:/usr/obj/usr/src/sys/GENERIC i386
mx#
*mx# ping 127.0.0.1*
PING 127.0.0.1 (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
*mx# ping localhost*
PING localhost (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- localhost ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
*mx# ping `hostname`*
ping: cannot resolve mx.taricat.ru: Host name lookup failure
*mx# ping google.com*
PING google.com (74.125.87.103): 56 data bytes
64 bytes from 74.125.87.103: icmp_seq=0 ttl=56 time=188.367 ms
64 bytes from 74.125.87.103: icmp_seq=1 ttl=56 time=180.537 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 180.537/184.452/188.367/3.915 ms
*mx# ping 10.10.0.113*
PING 10.10.0.113 (10.10.0.113): 56 data bytes
^C
--- 10.10.0.113 ping statistics ---
193 packets transmitted, 0 packets received, 100.0% packet loss
mx#
*mx# netstat -rn*
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default10.10.0.126UGS 2 97xl0
10.10.0.112/28 link#1 U 2 465xl0
10.10.0.114link#1 UHS 00lo0
Protocol Family 28:
DestinationGatewayFlagsNetif Expire
(28) 0001 (28)
0001 UH
lo0
(28) fe80 0003
link#3 U lo0
(28) fe80 0003 0001
link#3 UHS lo0
(28) ff01 0003 (28)
fe80 0003 0001 U
lo0
(28) ff02 0003 (28)
fe80 0003 0001 U
lo0
mx#
*mx# less /etc/rc.conf*
hostname=mx.taricat.ru
#ifconfig_xl0=inet 91.198.171.167 netmask 91.198.171.128
#defaultrouter=91.198.171.129
#ifconfig_ste0=inet 10.10.11.100 netmask 255.255.255.0
#pf_enable=YES
#pf_rules=/etc/pf/conf
#named_enable=YES
ifconfig_xl0=DHCP
sshd_enable=YES
#pflog_enable=YES
#clear_tmp_enable=YES
#smartd_enabled=YES
#samba_enable=YES
#nmbd_enable=YES
#smbd_enable=YES
#samba_config=/usr/local/etc/smb.conf
#zfs_enable=YES
/etc/rc.conf (END)
___
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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On Thu, Feb 11, 2010 at 7:13 AM, John Baldwin j...@freebsd.org wrote: On Wednesday 10 February 2010 1:38:37 pm Ivan Voras wrote: On 10 February 2010 19:35, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:26 Ivan Voras said the following: On 10 February 2010 19:10, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. I haven't said that those OSes do not use large pages. I've said what I've said :-) Ok :) Is there a difference between large pages as they are commonly known and superpages as in FreeBSD ? In other words - are you referencing some specific mechanism, like automatic promotion / demotion of the large pages or maybe something else? Yes, the automatic promotion / demotion. That is a far-less common feature. FreeBSD/i386 has used large pages for the kernel text as far back as at least 4.x, but that is not the same as superpages. Linux does not have automatic promotion / demotion to my knowledge. I do not know about other OS's. A comparison of current large page support among Unix-like and Windows operating systems has two dimensions: (1) whether or not the creation of large pages for applications is automatic and (2) whether or not the machine administrator has to statically partition the machine's physical memory between large and small pages at boot time. For FreeBSD, large pages are created automatically and there is not a static partitioning of physical memory. In contrast, Linux does not create large pages automatically and does require a static partitioning. Specifically, Linux requires the administrator to explicitly and statically partition the machine's physical memory at boot time into two parts, one that is dedicated to large pages and another for general use. To utilize large pages an application has to explicitly request memory from the dedicated large pages pool. However, to make this somewhat easier, but not automatic, there do exist re-implementations of malloc that you can explicitly link with your application. In Solaris, the application has to explicitly request the use of large pages, either via explicit kernel calls in the program or from the command line with support from a library. However, there is not a static partitioning of physical memory. So, for example, when you run the Sun jdk on Solaris, it explicitly requests large pages for much of its data, and this works without administrator having to configure the machine for large page usage. To the best of my knowledge, Windows is just like Solaris. Alan ___ 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: ping: sendto: Can't assign requested address
Hi-- On Feb 11, 2010, at 9:13 AM, GLADtr GLADtr wrote: Hello my friends! Help me please with its problem. I`m don`t what it is problem... Do you have a lo0 interface? Is it up and using IP 127.0.0.1? # ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 Regards, -- -Chuck ___ 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: ntpd struggling to keep up - how to fix?
Hi-- On Feb 11, 2010, at 10:06 AM, Torfinn Ingolfsen wrote: [ ... ] Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: r...@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter == kg-omni1.kg4.no 129.240.64.3 3 u 13 64 370.162 703.094 444.681 The rate at which this machine is losing time is probably exceeding the ~50 seconds per day that NTPd is willing to correct without extreme measures (ie, it has to step time rather than drift-correct). You might help it maintain a more sane idea of time by using at least 4 timeservers. You might take a look at 'vmstat -i' and look out for an interrupt storm, but it's possible your hardware's clock is simply busted. Regards, -- -Chuck ___ 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: NFS write corruption on 8.0-RELEASE
On Wednesday 10 February 2010 12:43:38 pm Dmitry Marakasov wrote: Hi! I think I've reported that before, the I thought it's been fixed, however I still get data corruptions when writing on NFS volumes. Now I wonder - is nobody really using NFS, or do I have that much of uncommon setup, or this is some kind of local problem? Client: 8.0-RELEASE i386 Server: 8.0-RELEASE amd64 mount options: nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd Server has ZFS, but the same thing happens when sharing UFS placed on md(4). I've prepared a special 1GB file to determine the details of corruption: it's filled with 32-bit numbers each equal to it's own offset in the file. That is, like that: 00 00 00 00 04 00 00 00 08 00 00 00 0c 00 00 00 || 0010 10 00 00 00 14 00 00 00 18 00 00 00 1c 00 00 00 || 0020 20 00 00 00 24 00 00 00 28 00 00 00 2c 00 00 00 | ...$...(...,...| 0030 30 00 00 00 34 00 00 00 38 00 00 00 3c 00 00 00 |0...4...8..| I've copied that file over NFS from client to server around 50 times, and got 3 corruptions on 8th, 28th and 36th copies. Case1: single currupted block 3779CF88-3779 (12408 bytes). Data in block is shifted 68 bytes up, loosing first 68 bytes are filling last 68 bytes with garbage. Interestingly, among that garbage is my hostname. Is it the hostname of the server or the client? Case2: single currupted block 2615CFA0-2615 (12384 bytes). Data is shifted by 44 bytes in the same way. Case3: single currepted block 3AA947A8-3AA97FFF (14424 bytes). Data is shifted by 36 bytes in the same way. Any ideas? PS. Diffs of corrupted blocks in a text format are here: http://people.freebsd.org/~amdmi3/diff.1.txt http://people.freebsd.org/~amdmi3/diff.2.txt http://people.freebsd.org/~amdmi3/diff.3.txt Can you reproduce this using a non-FreeBSD server with a FreeBSD client or a non-FreeBSD client with a FreeBSD server? That would narrow down the breakage to either the client or the server. -- John Baldwin ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
The next public revision guide from AMD will contain an errata (383) that documents the bug. However, it doesn't really tell us anything that we didn't already know. Alan ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
on 11/02/2010 20:38 Alan Cox said the following: The next public revision guide from AMD will contain an errata (383) that documents the bug. However, it doesn't really tell us anything that we didn't already know. Pity. I sort of hoped for more, like a workaround, some magic MSR. -- Andriy Gapon ___ 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
openldap client GSSAPI authentication segfaults in fbsd8stable i386
Dear all, I am facing many instabilities in FBSD8 with openldap-client and sasl authentication (GSSAPI in particular). I have setup an openldap 2.4.1 server with gssapi support (through cyrus-sasl-2.1.23) on a fbsd8-stable amd64 latest sources, in a esxi host. In the same host I have setup two fbsd8-stable i386 clients; one has latest sources, the other one is installed via the iso-image of January's fbsd snapshot; on both systems openldap client and sasl is installed (all ldap/cyrus versions on all hosts mentioned in this email are the same). My laptop has fbsd8-i386 stable (sources 25 January 2010), and on my laptop I have setup an fbsd8-stable i386 (snapshot iso image) on a virtualbox client. Lastly, on the esxi host I have setup another fbsd8-stable amd64 system, to act as an ldap client (latest sources). To summarize, and put a label-number on each host, we have: 1 - esxi: fbsd8(latest) amd64 openldap server 2 - esxi: fbsd8(latest) i386 openldap client 3 - esxi: fbsd8(snapshot) i386 openldap client 4 - esxi: fbsd8(latest) amd64 openldap client 5 - laptop: fbsd8(jan 25) i386 openldap client 6 - laptop/vbox: fbsd8(snapshot) i386 openldap client The openldap server is installed in a jail, and the client is tested in the same jail. Kerberos works on all machines (same /etc/krb5.conf), and ldap as well. In all machines, line 96 of /usr/bin/krb5-config is changed to read: lib_flags=$lib_flags -lgssapi -lgssapi_spnego -lgssapi_krb5 -lheimntlm instead of: lib_flags=$lib_flags -lgssapi -lheimntlm which was the default, since without these lines I couldn't get gssapi authentication to work for cyrus (and spnego). This change was made after recommendations given from this very mailing list, and I was very happy to see that the ldap server worked as I expected. On all system, cat /usr/local/etc/openldap/ldap.conf: BASEdc=ee,dc=auth,dc=gr URIldap://ldap.ee.auth.gr SASL_MECHGSSAPI without kiniting in any client I get the following outcomes when I give ldapwhoami (with no arguments): 1: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is expected. 2: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) which is not rational at all 3: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is the same as 1 (as expected) 5: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 6: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) if I kinit to mamalos, ldapwhoami returns: 1: SASL/GSSAPI authentication started SASL username: mama...@ee.auth.gr SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is super! 2: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) which is dramatic. 3: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2529638919 for mech unknown) which is very strange, since mech-code seems unnaturally large. 5: SASL/GSSAPI authentication started SASL username: mama...@ee.auth.gr SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is super, but without kinit the same command segfaulted on this machine 6: SASL/GSSAPI authentication started SASL username: mama...@ee.auth.gr SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is the exact same behavior as 5 above. All this means that there is no single pattern!!! If I gdb ldapwhoami in the clients that segfault, I get: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... (gdb) run -d0 Starting program: /usr/local/bin/ldapwhoami -d0 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols
Re: numeric sort(1) is broken on -STABLE
On 2010/02/10 17:58, Ulrich Spörlein wrote: Hi guys, not sure if this is a pilot error, but it seems to me that gnu sort -n is broken on at least -STABLE (couldn't test -CURRENT yet). It somehow does not manifest when using a simple list and sorting on a specific column, but it always happens to me when using it in combination with find(1). % truncate -s10m a; truncate -s5m b; truncate -s800k c % find a b c -ls|sort -nk7,7 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c % find a b c -ls|sort -gk7,7 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a Hi, here is a patch I've submitted about 4 years ago... http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/93566 -- Kazuaki ODA ___ 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: ping: sendto: Can't assign requested address
I can add output by strace for ping localhost if it is necessary
2010/2/11 GLADtr GLADtr my.nws...@gmail.com
Hello my friends! Help me please with its problem. I`m don`t what it is
problem...
*mx# uname -a*
FreeBSD mx.taricat.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Jan 25
09:28:38 UTC 2010 r...@mx.taricat.ru:/usr/obj/usr/src/sys/GENERIC
i386
mx#
*mx# ping 127.0.0.1*
PING 127.0.0.1 (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
*mx# ping localhost*
PING localhost (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- localhost ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
*mx# ping `hostname`*
ping: cannot resolve mx.taricat.ru: Host name lookup failure
*mx# ping google.com*
PING google.com (74.125.87.103): 56 data bytes
64 bytes from 74.125.87.103: icmp_seq=0 ttl=56 time=188.367 ms
64 bytes from 74.125.87.103: icmp_seq=1 ttl=56 time=180.537 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 180.537/184.452/188.367/3.915 ms
*mx# ping 10.10.0.113*
PING 10.10.0.113 (10.10.0.113): 56 data bytes
^C
--- 10.10.0.113 ping statistics ---
193 packets transmitted, 0 packets received, 100.0% packet loss
mx#
*mx# netstat -rn*
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default10.10.0.126UGS 2 97xl0
10.10.0.112/28 link#1 U 2 465xl0
10.10.0.114link#1 UHS 00lo0
Protocol Family 28:
DestinationGatewayFlagsNetif Expire
(28) 0001 (28)
0001 UH
lo0
(28) fe80 0003
link#3 U lo0
(28) fe80 0003 0001
link#3 UHS lo0
(28) ff01 0003 (28)
fe80 0003 0001 U
lo0
(28) ff02 0003 (28)
fe80 0003 0001 U
lo0
mx#
*mx# less /etc/rc.conf*
hostname=mx.taricat.ru
#ifconfig_xl0=inet 91.198.171.167 netmask 91.198.171.128
#defaultrouter=91.198.171.129
#ifconfig_ste0=inet 10.10.11.100 netmask 255.255.255.0
#pf_enable=YES
#pf_rules=/etc/pf/conf
#named_enable=YES
ifconfig_xl0=DHCP
sshd_enable=YES
#pflog_enable=YES
#clear_tmp_enable=YES
#smartd_enabled=YES
#samba_enable=YES
#nmbd_enable=YES
#smbd_enable=YES
#samba_config=/usr/local/etc/smb.conf
#zfs_enable=YES
/etc/rc.conf (END)
___
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: ping: sendto: Can't assign requested address
On Thu, Feb 11, 2010 at 08:13:04PM +0300, GLADtr GLADtr wrote:
Hello my friends! Help me please with its problem. I`m don`t what it is
problem...
*mx# uname -a*
FreeBSD mx.taricat.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Jan 25 09:28:38
UTC 2010 r...@mx.taricat.ru:/usr/obj/usr/src/sys/GENERIC i386
mx#
*mx# ping 127.0.0.1*
PING 127.0.0.1 (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
*mx# ping localhost*
PING localhost (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- localhost ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
*mx# ping `hostname`*
ping: cannot resolve mx.taricat.ru: Host name lookup failure
*mx# ping google.com*
PING google.com (74.125.87.103): 56 data bytes
64 bytes from 74.125.87.103: icmp_seq=0 ttl=56 time=188.367 ms
64 bytes from 74.125.87.103: icmp_seq=1 ttl=56 time=180.537 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 180.537/184.452/188.367/3.915 ms
*mx# ping 10.10.0.113*
PING 10.10.0.113 (10.10.0.113): 56 data bytes
^C
--- 10.10.0.113 ping statistics ---
193 packets transmitted, 0 packets received, 100.0% packet loss
mx#
*mx# netstat -rn*
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default10.10.0.126UGS 2 97xl0
10.10.0.112/28 link#1 U 2 465xl0
10.10.0.114link#1 UHS 00lo0
Protocol Family 28:
DestinationGatewayFlagsNetif Expire
(28) 0001 (28)
0001 UH
lo0
(28) fe80 0003
link#3 U lo0
(28) fe80 0003 0001
link#3 UHS lo0
(28) ff01 0003 (28)
fe80 0003 0001 U
lo0
(28) ff02 0003 (28)
fe80 0003 0001 U
lo0
mx#
*mx# less /etc/rc.conf*
hostname=mx.taricat.ru
#ifconfig_xl0=inet 91.198.171.167 netmask 91.198.171.128
#defaultrouter=91.198.171.129
#ifconfig_ste0=inet 10.10.11.100 netmask 255.255.255.0
#pf_enable=YES
#pf_rules=/etc/pf/conf
#named_enable=YES
ifconfig_xl0=DHCP
sshd_enable=YES
#pflog_enable=YES
#clear_tmp_enable=YES
#smartd_enabled=YES
#samba_enable=YES
#nmbd_enable=YES
#smbd_enable=YES
#samba_config=/usr/local/etc/smb.conf
#zfs_enable=YES
/etc/rc.conf (END)
Your routing table *does not* match what you have in rc.conf. In fact,
your IPs are no where near what's in rc.conf. Did you modify rc.conf
and not reboot the box?
Here's an example machine which works with dual interfaces. I've
included relevant rc.conf pieces as well as the routing table.
$ ifconfig -a
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
ether 00:30:48:bd:46:7c
inet 72.20.98.122 netmask 0xffc0 broadcast 72.20.98.127
media: Ethernet autoselect (1000baseT full-duplex)
status: active
em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
ether 00:30:48:bd:46:7d
inet 10.72.0.122 netmask 0xff00 broadcast 10.72.0.255
media: Ethernet autoselect (1000baseT full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet 127.0.0.1 netmask 0xff00
$ netstat -rn
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default72.20.98.65UGS 241750em0
10.72.0.0/24 link#2 U 114265em1
10.72.0.122link#2 UHS 00lo0
72.20.98.64/26 link#1 U 0 102em0
72.20.98.122 link#1 UHS 00lo0
127.0.0.1 link#3 UH 00lo0
$ head -4 /etc/rc.conf
hostname=ra.parodius.com
ifconfig_em0=inet 72.20.98.122 netmask 255.255.255.192
ifconfig_em1=inet 10.72.0.122 netmask 255.255.255.0
defaultrouter=72.20.98.65
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/
Re: ntpd struggling to keep up - how to fix?
On Thu, Feb 11, 2010 at 07:06:52PM +0100, Torfinn Ingolfsen wrote: Hi, One of my machines, the fileserver-with-zfs-to-be[1] has trouble keeping correct time. Or rather, ntpd is struggling. In /var/lkog/messages I see this: Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.46 s Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: r...@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter == kg-omni1.kg4.no 129.240.64.3 3 u 13 64 370.162 703.094 444.681 Note: all machines on my LAN use my firewall as the ntp server. The ntp server runs FreeBSD, none of the other machines have any trouble keeping time. My workstation for example: ti...@kg-v2$ ntpq -p remote refid st t when poll reach delay offset jitter == *kg-omni1.kg4.no 129.240.64.3 3 u 44 64 3770.1384.018 0.338 (my workstatuion also runs FreeBSD 8.0-stable / amd64) The machine runs FreeBSD 8.0-stable / amd64: r...@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 r...@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 So, how can I get the machine to keep time / get ntpd synchronised? References: 1) hw info: http://sites.google.com/site/tingox/ga-ma74gm-s2h 2) FreeBSD info: http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd Your machine has a rapidly drifting clock, usually an indicator of a hardware problem (crystal gone bad is a common one -- seen this at work quite a few times), or possibly a bad time counter source chosen by the kernel. Can you please provide the output of: sysctl kern.timecounter Finally, was this OS installation used on different hardware in the past? Meaning: was the hard disk previously installed on another machine? Why I'm asking: /var/db/ntpd.drift could be from an old computer (the previous hardware), and the clock drift rate would be different than that of your newer[1] hardware. If that's the case, please stop ntpd, rm /var/db/ntpd.drift, and restart ntpd. Be aware it will take up to 72 hours for the clock drift to be calculated correctly. -- | 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: ntpd struggling to keep up - how to fix?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 2010/02/11 11:25, Jeremy Chadwick wrote: On Thu, Feb 11, 2010 at 07:06:52PM +0100, Torfinn Ingolfsen wrote: Hi, One of my machines, the fileserver-with-zfs-to-be[1] has trouble keeping correct time. Or rather, ntpd is struggling. In /var/lkog/messages I see this: Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.46 s Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: r...@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter == kg-omni1.kg4.no 129.240.64.3 3 u 13 64 370.162 703.094 444.681 Note: all machines on my LAN use my firewall as the ntp server. The ntp server runs FreeBSD, none of the other machines have any trouble keeping time. My workstation for example: ti...@kg-v2$ ntpq -p remote refid st t when poll reach delay offset jitter == *kg-omni1.kg4.no 129.240.64.3 3 u 44 64 3770.1384.018 0.338 (my workstatuion also runs FreeBSD 8.0-stable / amd64) The machine runs FreeBSD 8.0-stable / amd64: r...@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 r...@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 So, how can I get the machine to keep time / get ntpd synchronised? References: 1) hw info: http://sites.google.com/site/tingox/ga-ma74gm-s2h 2) FreeBSD info: http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd Your machine has a rapidly drifting clock, usually an indicator of a hardware problem (crystal gone bad is a common one -- seen this at work quite a few times), or possibly a bad time counter source chosen by the kernel. Can you please provide the output of: sysctl kern.timecounter Finally, was this OS installation used on different hardware in the past? Meaning: was the hard disk previously installed on another machine? Why I'm asking: /var/db/ntpd.drift could be from an old computer (the previous hardware), and the clock drift rate would be different than that of your newer[1] hardware. If that's the case, please stop ntpd, rm /var/db/ntpd.drift, and restart ntpd. Be aware it will take up to 72 hours for the clock drift to be calculated correctly. I think this looks like the same problem I had with another AMD system, which may be related to some HPET stuff (I no longer have access to that system, though :( Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLdF9LAAoJEATO+BI/yjfBqacH/jreDlSiX9YCZqOSo22Dx0oW KGxuqUk6ViBTBEMOHJzpqNn37u/cbBQ7qlXaDfhg1LY825lCvx782mFGPH3J67qT IQZyLeWKGn/2BW/mhyQ9qOkEZKfifuwGmvvhxOwmnPyG2o1opFYiNxtLcJj0hPbs qqhf7wE2YzY4Khx7bTVsbclUz6kaXnusUF09Kg2F4LJ7WUilkAvFYwuG/J4sx7UN qKbw/F2bS1suyAt3cOmcb73rHN8MAbIyzjv0HOc4LUMnS6btFPUe5pqa7ghRNf7o 4wIoeGXQ6zupkjpHULIjU9hfu8uwKnTiDJ2xfJ6HjLvawsvOu/VUYvgqQM6cMd8= =Wy4x -END PGP SIGNATURE- ___ 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
Hello and a small problem with 8.0-RELEASE (amd64)
Hello, freebsd-stable folks! I sincerely hope I am in the correct place to inquire about a small problem I am having implementing FreeBSD 8.0-RELEASE on my AMD Athlon-64 machine. This machine runs FreeBSD 7.2 (amd64 version) without the slightest problem; but when I attempt to load 8.0 onto the machine, I can't even get sysinstall to put the kernel on to boot it. Attempting to compile and install the 8.0 kernel from source code results in a kernel which locks up at boot time after emitting a message stating attempting to mount volumes; a reboot of this system results in a bootloader prompt and an error message stating that no bootable kernel can be found. Any ideas? Thank You! Garrett Cooper of the freebsd-bugs list recommended I ask the above questions here: Hi Sean, Could you try the stable@ mailing list please? Thanks! -Garrett Any ideas as to how to get the 8.0-RELEASE running on my amd64 machine would be appreciated greatly. If I need to ask elsewhere, please recommend accordingly. Thank You again, Sean McCullough ___ 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: ntpd struggling to keep up - how to fix?
Hi, One of my machines, the fileserver-with-zfs-to-be[1] has trouble keeping correct time. Or rather, ntpd is struggling. In /var/lkog/messages I see this: Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.46 s Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s [snip] I think this looks like the same problem I had with another AMD system, which may be related to some HPET stuff (I no longer have access to that system, though :( I have the some problem on my machine (also AMD, running 8.0 + patches), after a while ntpd gives up sync'ing and then the time is off by minutes (roughly 80sec after.. say 10 hours) :( I switched to opentnpd (you can find it in ports) and the clock stays in sync now, so you might want to consider that, too PS: I had a spare disk so I tried Linux on the same machine, and ntpd is running fine for 2 days without any problems; so I guess it's not a hw fault HTH ___ 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: ntpd struggling to keep up - how to fix?
--On Thursday, February 11, 2010 10:49 PM +0100 Stefan Krueger stadtki...@gmx.de wrote: snip PS: I had a spare disk so I tried Linux on the same machine, and ntpd is running fine for 2 days without any problems; so I guess it's not a hw fault It is a HW fault. FreeBSD and Linux are just picking different time sources, Linux is guessing right, FreeBSD is guessing wrong. AMD actually has pretty widely known issues with this. I've had problems mostly in Solaris/OpenSolaris though, a few with FreeBSD, and only rarely with Linux. I don't know the details, just that at least the Opteron HPET apparently isn't reliable. ___ 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: em(4) + ALTQ broken
Anyone else get a chance to review this? On Fri, Feb 5, 2010 at 8:44 PM, Nick Rogers ncrog...@gmail.com wrote: I applied drbr_altq.diff to the e1000 driver (sys/dev/e1000) from HEAD on top of 8.0-RELEASE kernel sources. It appears to have fixed the immediate problem where queues simply don't work on em interfaces. Thanks a bunch. I suppose further review and testing by others would be greatly appreciated from my point of view. I am trying to decide on a relatively stable 8.0 kernel with working em(4) + ALTQ to put into production on 100 or so installations. Are you guys more comfortable with the HEAD sys/dev/e1000 + this patch on top of 8.0-RELEASE, or e1000 from 7.2 on top of 8.0-RELEASE? So far I am having good luck with the later. Thanks again for your contributions! On Thu, Feb 4, 2010 at 6:51 PM, Max Laier m...@love2party.net wrote: Okay ... attached is a patch to fix this for em(4) (and lay the groundwork to fix it for other drbr_* consumer as well). I have tested it in VirtualBox, but don't have real hardware to check for non-ALTQ performance or other regressions. Test, comments and review appreciated. -- Max ___ 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: Hello and a small problem with 8.0-RELEASE (amd64)
Hello, nicholasbug! On 2/11/2010 4:34 PM, nickolas...@gmail.com wrote: 2010/2/11 Sean McCullough wo...@frii.com: Any ideas as to how to get the 8.0-RELEASE running on my amd64 machine would be appreciated greatly. If I need to ask elsewhere, please recommend accordingly. Try binary update (use freebsd-update). Thank you for the suggestion. Unfortunately, the machine in question has no access to highspeed internet service and has dialup only. I need to be able to install the new OS from CD/DVD successfully. No disrespect intended, but I'd like to be able to live to see the solution implemented. :-) thank you again -- Sean ___ 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: Hello and a small problem with 8.0-RELEASE (amd64)
On Thu, 11 Feb 2010, Sean McCullough wrote: Thank you for the suggestion. Unfortunately, the machine in question has no access to highspeed internet service and has dialup only. I need to be able to install the new OS from CD/DVD successfully. Posting the make and model of the machine or at least the motherboard might be helpful. CPU and RAM, too. Are you certain the CPU is amd64? -Warren Block * Rapid City, South Dakota USA ___ 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
ZFS on root, serial console install
Any hints on that one? I finally got around to getting dhcp/tftp/nfs setup on an internal network to perform normal installs (and with some pxelinux hackery, the ability to boot a DOS disk or memtest86 disk images). Sysinstall in general is kind of an unweildy beast over serial, but one thing I was not able to accomplish was to get a shell (no extra virtual consoles on serial) or attempt any mounting of fixit media. From my last install that put ZFS on root, I had to do quite a bit of tapdancing since I had no DVD or bootable USB media - lots of switching from the install disk to fixit, which brought me to many chicken and egg moments. I did it though... But remotely, I'm not seeing a good way to do this. If mfsroot were larger and had more tools, then I'd be in business. This is probably the direction I need to get shoved in. I've looked at some other options with pxelinux and perhaps booting the mini ISO, but I'm not sure that gets me anywhere. Any tips? This isn't a make or break situation, I live 15 minutes from the colo... It's more of a quest. :) Thanks, Charles ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On Thu, 11 Feb 2010 13:45, mamalos@ wrote: Dear all, I am facing many instabilities in FBSD8 with openldap-client and sasl authentication (GSSAPI in particular). I have setup an openldap 2.4.1 server with gssapi support (through cyrus-sasl-2.1.23) on a fbsd8-stable amd64 latest sources, in a esxi host. In the same host I have setup two fbsd8-stable i386 clients; one has latest sources, the other one is installed via the iso-image of January's fbsd snapshot; on both systems openldap client and sasl is installed (all ldap/cyrus versions on all hosts mentioned in this email are the same). My laptop has fbsd8-i386 stable (sources 25 January 2010), and on my laptop I have setup an fbsd8-stable i386 (snapshot iso image) on a virtualbox client. Lastly, on the esxi host I have setup another fbsd8-stable amd64 system, to act as an ldap client (latest sources). To summarize, and put a label-number on each host, we have: 1 - esxi: fbsd8(latest) amd64 openldap server 2 - esxi: fbsd8(latest) i386 openldap client 3 - esxi: fbsd8(snapshot) i386 openldap client 4 - esxi: fbsd8(latest) amd64 openldap client 5 - laptop: fbsd8(jan 25) i386 openldap client 6 - laptop/vbox: fbsd8(snapshot) i386 openldap client The openldap server is installed in a jail, and the client is tested in the same jail. Kerberos works on all machines (same /etc/krb5.conf), and ldap as well. In all machines, line 96 of /usr/bin/krb5-config is changed to read: lib_flags=$lib_flags -lgssapi -lgssapi_spnego -lgssapi_krb5 -lheimntlm instead of: lib_flags=$lib_flags -lgssapi -lheimntlm which was the default, since without these lines I couldn't get gssapi authentication to work for cyrus (and spnego). This change was made after recommendations given from this very mailing list, and I was very happy to see that the ldap server worked as I expected. On all system, cat /usr/local/etc/openldap/ldap.conf: BASEdc=ee,dc=auth,dc=gr URIldap://ldap.ee.auth.gr SASL_MECHGSSAPI without kiniting in any client I get the following outcomes when I give ldapwhoami (with no arguments): 1: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is expected. 2: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) which is not rational at all 3: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is the same as 1 (as expected) 5: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 6: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) if I kinit to mamalos, ldapwhoami returns: 1: SASL/GSSAPI authentication started SASL username: mama...@ee.auth.gr SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is super! 2: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) which is dramatic. 3: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2529638919 for mech unknown) which is very strange, since mech-code seems unnaturally large. 5: SASL/GSSAPI authentication started SASL username: mama...@ee.auth.gr SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is super, but without kinit the same command segfaulted on this machine 6: SASL/GSSAPI authentication started SASL username: mama...@ee.auth.gr SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is the exact same behavior as 5 above. All this means that there is no single pattern!!! If I gdb ldapwhoami in the clients that segfault, I get: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... (gdb) run -d0 Starting program: /usr/local/bin/ldapwhoami -d0 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols
