NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Marek Salwerowicz

Hi,

1. I have a NFSv4-enabled server with /etc/exports like:
V4: / -sec=sys
/home/stud -sec=sys

/etc/rc.conf:

nfs_server_enable=YES
nfsv4_server_enable=YES
nfsuserd_enable=YES

Is it possible to run ONLY NFSv4 server (without NFSv3 compatibility) ?

2. On a client station I installed pam_mount module in order to mount home directory from server automatically during logging in to 
station.

I would like to mount it via NFSv4.

In pam_mount.conf.xml I inserted:
volume fstype=nfs server=free pgrp=stud path=/home/stud/%(USER) 
mountpoint=/home/stud/%(USER) /
volume fstype=nfs server=free pgrp=prac path=/home/prac/%(USER) 
mountpoint=/home/prac/%(USER) /
nfsmountmount_nfs -o nfsv4 %(SERVER):%(VOLUME) %(MNTPT)/nfsmount

And it  works, but:

On a client station every user can be root, and I don't want even root to be able to mount user's home directories without giving a 
password (via mount_nfs command)- is it possible?


After mounting there is a strange UID and GID:

ls -la
total 472
drwxr-xr-x  10 32767  32767   1024  8 sty 23:00 ./
drwxr-xr-x   9 root   wheel512  1 wrz  2009 ../
-rw---   1 32767  32767  0 12 cze  2010 .Xauthority
drwxr-xr-x   3 32767  32767512 12 cze  2010 .cache/
-rw---   1 32767  32767  68693  8 sty 21:11 .hist
-rw---   1 32767  32767  0 11 cze  2010 .history

the UID should be 700.

--
Marek Salwerowicz 


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


lockup with vidcontrol VESA_800x600

2011-01-09 Thread Marc UBM Bocklet

Hiho! :-)

Yesterday I upgraded to 

FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan  8
17:05:30 CET 2011

and vidcontrol VESA_800x600 stopped working (again). I exchanged emails
with jkim about a similar problem in February 2010 (vidcontrol
VESA_800x600 would mangle the screen output), there was no definitive
resolution, but it started working again sometime around July 2010.

Now however, when I try to set VESA_800x600, my machine seems to 
lockup. It no longer responds to any input, I cannot ping it and I
cannot drop to the debugger.

I've tried setting other modes, but trying to set them results in:

obtaining new video mode parameters: operation not supported by device.

graphics card is a:

vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002
rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro
Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)'
class  = display
subclass   = VGA

Any clues what might have changed?


Bye
Marc

-- 
Marc UBM Bocklet ubm.free...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


lockup with vidcontrol VESA_800x600

2011-01-09 Thread Marc UBM Bocklet

Hiho! :-)

Yesterday I upgraded to 

FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan  8
17:05:30 CET 2011

and vidcontrol VESA_800x600 stopped working (again). I exchanged emails
with jkim about a similar problem in February 2010 (vidcontrol
VESA_800x600 would mangle the screen output), there was no definitive
resolution, but it started working again sometime around July 2010.

Now however, when I try to set VESA_800x600, my machine seems to 
lockup. It no longer responds to any input, I cannot ping it and I
cannot drop to the debugger.

I've tried setting other modes, but trying to set them results in:

obtaining new video mode parameters: operation not supported by device.

graphics card is a:

vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002
rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro
Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)'
class  = display
subclass   = VGA

Any clues what might have changed?


Bye
Marc

-- 
Marc UBM Bocklet ubm.free...@gmail.com
-- 
Marc UBM Bocklet ubm.free...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Marek Salwerowicz


What I am missing ?

/etc/sysctl.conf is applied before rc.d/nfs* ?


That would be my guess. The sysctl's aren't setable until the modules
are loaded. If you build a kernel with options NFSD in its kernel
config file, then it should be setable as above, I think? (I always
use sysctl manually after booting, so I don't really know how /etc/sysctl.conf
works.




After manually setting:

salwe...@freebsd:/etc#sudo sysctl vfs.newnfs.server_max_nfsvers=4
vfs.newnfs.server_max_nfsvers: 4 - 4
salwe...@freebsd:/etc#sudo sysctl vfs.newnfs.server_min_nfsvers=4
vfs.newnfs.server_min_nfsvers: 4 - 4
salwe...@freebsd:/etc#

We are still able to mount via NFSv3 (even when those two lines are commented 
in sysctl.conf).
Any other idea.. ? 


--
Marek Salwerowicz
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Rick Macklem
  
 After manually setting:
 
 salwe...@freebsd:/etc#sudo sysctl vfs.newnfs.server_max_nfsvers=4
 vfs.newnfs.server_max_nfsvers: 4 - 4
 salwe...@freebsd:/etc#sudo sysctl vfs.newnfs.server_min_nfsvers=4
 vfs.newnfs.server_min_nfsvers: 4 - 4
 salwe...@freebsd:/etc#
 
 We are still able to mount via NFSv3 (even when those two lines are
 commented in sysctl.conf).
 Any other idea.. ?
 
It just worked for me. Try setting the sysctl before starting nfsd. If
you are starting the daemons manually for a kernel that doesn't have
options NFSD do:

# nfsuserd
# mountd -e -r
# sysctl vfs.newnfs.server_min_nfsvers=4
# nfsd -e -u -t -n 8

- mountd -e loads the module, so you can do the sysctl after that and before
  starting the nfsd. (Or build a kernel with options NFSD and do the sysctl
  anytime before starting the nfsd.)

rick
ps: I tested the FreeBSD-8 client. Other clients may not even talk to the NFS
   server during mounting. For those, the mount would succeed, but subsequent
   use of the mount won't work.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Loading uart module fails

2011-01-09 Thread Bruce Cran
Hi,

I removed uart from my kernel configuration - when I tried to load it
later as a module I got the following error:

acpi_timer0: couldn't allocate resource (port 0x4008)
driver bug: Unable to set devclass (devname: (null))

-- 
Bruce Cran
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Marek Salwerowicz



It just worked for me. Try setting the sysctl before starting nfsd. If
you are starting the daemons manually for a kernel that doesn't have
options NFSD do:

# nfsuserd
# mountd -e -r
# sysctl vfs.newnfs.server_min_nfsvers=4
# nfsd -e -u -t -n 8

- mountd -e loads the module, so you can do the sysctl after that and before
   starting the nfsd. (Or build a kernel with options NFSD and do the sysctl
   anytime before starting the nfsd.)

rick
ps: I tested the FreeBSD-8 client. Other clients may not even talk to the NFS
server during mounting. For those, the mount would succeed, but subsequent
use of the mount won't work.

I tested it on 8.1 Release (GENERIC) i386 (two VMs):

server:
/etc/rc.conf:
#nfsv4_server_enable=YES
#nfs_server_enable=YES
#nfsuserd_enable=YES

made modification in /etc/exports:
V4: /usr -sec=sys -network 192.168.183.0 -mask 255.255.255.0
/usr/home -sec=sys -network 192.168.183.0 -mask 255.255.255.0

nfs4-server# nfsuserd
nfs4-server# mountd -e -r
nfs4-server# sysctl vfs.newnfs.server_min_nfsvers=4
vfs.newnfs.server_min_nfsvers: 2 - 4
nfs4-server# nfsd -e -u -t -n 8
nfs4-server#

but now client is unable to mount both nfsv4 and nfsv3:

nfs4-client# mount_nfs -o nfsv4 192.168.183.131:/home /tmp/nfs4/
[tcp] 192.168.183.131:/home: nfsd: RPCPROG_NFS: RPC: Remote system error 
- Connection refused

^C
nfs4-client# mount_nfs 192.168.183.131:/usr/home /tmp/nfs3/
^C (hangs for a long time)
nfs4-client#


--
Marek Salwerowicz

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: lockup with vidcontrol VESA_800x600

2011-01-09 Thread Chris Brennan
Did you try http://www.freebsdwiki.net/index.php/High_Resolution_Console?

-- Sent from my Droid

On Jan 9, 2011 6:58 AM, Marc UBM Bocklet ubm.free...@googlemail.com
wrote:

 Hiho! :-)

 Yesterday I upgraded to

 FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan 8
 17:05:30 CET 2011

 and vidcontrol VESA_800x600 stopped working (again). I exchanged emails
 with jkim about a similar problem in February 2010 (vidcontrol
 VESA_800x600 would mangle the screen output), there was no definitive
 resolution, but it started working again sometime around July 2010.

 Now however, when I try to set VESA_800x600, my machine seems to
 lockup. It no longer responds to any input, I cannot ping it and I
 cannot drop to the debugger.

 I've tried setting other modes, but trying to set them results in:

 obtaining new video mode parameters: operation not supported by device.

 graphics card is a:

 vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002
 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro
 Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)'
 class = display
 subclass = VGA

 Any clues what might have changed?


 Bye
 Marc

 --
 Marc UBM Bocklet ubm.free...@gmail.com
 --
 Marc UBM Bocklet ubm.free...@gmail.com
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Lock-up with CPU busy at r217145; seems OK now at r217189

2011-01-09 Thread David Wolfskill
As usual, I have been tracking, building,  booting head daily on my
laptop for a while.

Yesterday, having built head at r217090, I had updated to r217145,
built, and booted it OK.  (I then booted from my stable/8 slice for the
rest of the day, as usual.)

This morning, I updated to r217189, but on 3 out of 3 attempts to
perform make -j4 buildworld while running head at r217145, the
machine became unresponsive (while the fans were at top speed and
the screen remained lit).  I have DDB in the kernel config, but was
unable to break to the debugger.

After the 3 tries, I booted from the r217090 kernel; the make -j4
buildworld was successful.

After booting head at r217189, I re-ran the make -j4 buildworld just
to see if it survived the attempt; it did.

So it *appears* that something after r217090 and before r217146 caused a
problem, and something after r217145 and before r217190 has fixed or
circumvented it.  Of course, this isn't an exhaustive test, so take it
with an appropriate grain of salt.

I've attached dmseg.boot for those iinterested.

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.
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #99 r217189: Sun Jan  9 08:17:44 PST 2011
r...@g1-222.catwhisker.org.:/usr/obj/usr/src/sys/CANARY i386
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xc700
MEMGUARD map limit: 0xc900
MEMGUARD map size: 32768 KBytes
CPU: Intel(R) Core(TM)2 Duo CPU T9600  @ 2.80GHz (2793.07-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x10676  Family = 6  Model = 17  Stepping = 6
  
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
  
Features2=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1
  AMD Features=0x2010NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 3656601600 (3487 MB)
Event timer LAPIC quality 400
ACPI APIC Table: DELL   M09
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 2
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: DELL M09 on motherboard
hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter HPET frequency 14318180 Hz quality 900
Event timer HPET frequency 14318180 Hz quality 450
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
Event timer HPET3 frequency 14318180 Hz quality 440
acpi0: reservation of 0, 9f000 (3) failed
acpi0: reservation of 10, df351c00 (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
acpi_ec0: Embedded Controller: GPE 0x11 port 0x930,0x934 on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xdf00-0xdf7f mem 
0xf500-0xf5ff,0xe000-0xefff,0xf200-0xf3ff irq 16 at 
device 0.0 on pci1
em0: Intel(R) PRO/1000 Network Connection 7.1.8 port 0xefe0-0xefff mem 
0xf6fe-0xf6ff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0
em0: Using an MSI interrupt
em0: Ethernet address: 00:21:70:d5:28:dd
uhci0: Intel 82801I (ICH9) USB controller port 0x6f60-0x6f7f irq 20 at device 
26.0 on pci0
uhci0: LegSup = 0x2f00
usbus0: Intel 82801I (ICH9) USB controller on uhci0
uhci1: Intel 82801I (ICH9) USB controller port 0x6f80-0x6f9f irq 21 at device 
26.1 on pci0
uhci1: LegSup = 0x2f00
usbus1: Intel 82801I (ICH9) USB controller on uhci1
uhci2: Intel 82801I (ICH9) USB controller port 0x6fa0-0x6fbf irq 22 at device 
26.2 on pci0
uhci2: LegSup = 0x2f00
usbus2: Intel 82801I (ICH9) USB controller on uhci2
ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xfed1c400-0xfed1c7ff irq 
22 at device 26.7 on pci0
usbus3: EHCI version 1.0
usbus3: Intel 82801I (ICH9) USB 2.0 controller on ehci0
hdac0: Intel 82801I High Definition Audio Controller mem 
0xf6fdc000-0xf6fd irq 21 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20100226_0142
pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0
pci11: ACPI PCI bus on pcib2
pcib3: ACPI PCI-PCI bridge at device 28.1 on pci0
pci12: ACPI PCI bus on pcib3
iwn0: 

Re: Lock-up with CPU busy at r217145; seems OK now at r217189

2011-01-09 Thread Michael Butler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/09/11 12:57, David Wolfskill wrote:
 As usual, I have been tracking, building,  booting head daily on my
 laptop for a while.
 
 Yesterday, having built head at r217090, I had updated to r217145,
 built, and booted it OK.  (I then booted from my stable/8 slice for the
 rest of the day, as usual.)
 
 This morning, I updated to r217189, but on 3 out of 3 attempts to
 perform make -j4 buildworld while running head at r217145, the
 machine became unresponsive (while the fans were at top speed and
 the screen remained lit).  I have DDB in the kernel config, but was
 unable to break to the debugger.

I too have been seeing *really* odd things - dump randomly stops in the
middle of a backup, automoc4 spawns a child during a KDE-4 build which
turns into a zombie but is never seen to return and the build stalls -
weird :-(

Having checked out and built SVN revision 217202 - I'll try again ..

imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk0qAEgACgkQQv9rrgRC1JL9xwCgyHO8V8EE2wEXYpVifE4WjWve
h/oAnjmJgG8GzJTF9v/mQxR3q+VllWZ7
=mMUo
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


R: lockup with vidcontrol VESA_800x600

2011-01-09 Thread Barbara


Hiho! :-)

Yesterday I upgraded to 

FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan  8
17:05:30 CET 2011

and vidcontrol VESA_800x600 stopped working (again). I exchanged emails
with jkim about a similar problem in February 2010 (vidcontrol
VESA_800x600 would mangle the screen output), there was no definitive
resolution, but it started working again sometime around July 2010.

Now however, when I try to set VESA_800x600, my machine seems to 
lockup. It no longer responds to any input, I cannot ping it and I
cannot drop to the debugger.

I've tried setting other modes, but trying to set them results in:

obtaining new video mode parameters: operation not supported by device.

graphics card is a:

vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002
rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro
Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)'
class  = display
subclass   = VGA

Any clues what might have changed?



I had to gave up with VESA.
Before all the changes (feb./mar. 2010) it was working perfectly with 
MODE_280.
Now I have to use MODE_30, because any other higher resolution isn't working 
or it's crashing the machine, as I've reported yet.
I would like to add that yesterday, I left  twice my pc running CURRENT turned 
on while doing other things. And both time on my return it was dead. Not even 
replying to ping.
I had to set blanktime=NO in /etc/rc.conf. I'm not sure if the problem has 
been introduced recently.
Did you noticed that too?

Barbara


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Rick Macklem


- Original Message -
  It just worked for me. Try setting the sysctl before starting nfsd.
  If
  you are starting the daemons manually for a kernel that doesn't have
  options NFSD do:
 
  # nfsuserd
  # mountd -e -r
  # sysctl vfs.newnfs.server_min_nfsvers=4
  # nfsd -e -u -t -n 8
 
  - mountd -e loads the module, so you can do the sysctl after that
  and before
 starting the nfsd. (Or build a kernel with options NFSD and do
 the sysctl
 anytime before starting the nfsd.)
 
  rick
  ps: I tested the FreeBSD-8 client. Other clients may not even talk
  to the NFS
  server during mounting. For those, the mount would succeed, but
  subsequent
  use of the mount won't work.
 I tested it on 8.1 Release (GENERIC) i386 (two VMs):
 
 server:
 /etc/rc.conf:
 #nfsv4_server_enable=YES
 #nfs_server_enable=YES
 #nfsuserd_enable=YES
 
 made modification in /etc/exports:
 V4: /usr -sec=sys -network 192.168.183.0 -mask 255.255.255.0
 /usr/home -sec=sys -network 192.168.183.0 -mask 255.255.255.0
 
 nfs4-server# nfsuserd
 nfs4-server# mountd -e -r
 nfs4-server# sysctl vfs.newnfs.server_min_nfsvers=4
 vfs.newnfs.server_min_nfsvers: 2 - 4
 nfs4-server# nfsd -e -u -t -n 8
 nfs4-server#
 
 but now client is unable to mount both nfsv4 and nfsv3:
 
 nfs4-client# mount_nfs -o nfsv4 192.168.183.131:/home /tmp/nfs4/
 [tcp] 192.168.183.131:/home: nfsd: RPCPROG_NFS: RPC: Remote system
 error
 - Connection refused

Again, it works for me (using a pretty current FreeBSD client). The
only difference is that I never run mount_nfs directly and would use
the following command:

# mount -t nfs -o nfsv4 192.168.183.131:/home /tmp/nfs4

Assuming the client is a FreeBSD8 box on the 192.168.183.0 subnet,
I don't know why it wouldn't work, except that I'd suggest trying
the command the way I type it, in case that runs it with somewhat
different options?

rick
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: HEADS UP: Merge of binutils 2.17

2011-01-09 Thread Pav Lucistnik
Erik Cederstrand píše v ne 09. 01. 2011 v 00:10 +0100:

 I was pretty sure I couldn't improve anything with 5 minutes of
 thinking. I'm glad the most obvious things have already been done, and
 I'm sure you and others have put a lot of effort into this. My
 question was more what, if anything, can be done to speed up the
 cluster.

Performance and numbers of build nodes is okay. What we really need here
is faster, more robust scheduling infrastructure (master node software),
linimon@ is working hard on this task.

 Also, how long does it take to complete an exp-run on the cluster?

If everything goes smoothly, 20 hours wall time.

-- 
-- 
Pav Lucistnik p...@oook.cz
  p...@freebsd.org
Do not meddle in the fashions of wizards, for they are seasonal and
quick to fall out of style!


signature.asc
Description: This is a digitally signed message part


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Rick Macklem
 
 Good to know if it will work with nfsv4 server started via rc.conf and
 sysctl values in sysctl.conf..
 
build a kernel with options NFSD in its config file and then try it
with that kernel, and then you'll find out...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


console freeze after ifconfig wlan0 scan with wi(4) pccard device

2011-01-09 Thread Anton Shterenlikht
On amd64 r217010 laptop (HP Compaq 6715s)
I'm trying to use this wi(4) device:

wi0: The Linksys Group, Inc. Instant Wireless Network PC Card
 at port 0x100-0x13f irq 20 function 0 config 1 on pccard0

I do

# ifconfig wlan0 create wlandev wi0
# ifconfig -a
bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTAT
E
ether 00:1a:4b:89:4b:4e
inet 192.168.1.102 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
wi0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:06:25:10:56:3b
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
wlan0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 00:06:25:10:56:3b
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid  channel 1 (2412 MHz 11b)
country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60
bintval 0

But after

# ifconfig wlan0 up scan

I get console freeze requiring cold reboot.
No panic, just a LOR:

 wi0: The Linksys Group, Inc. Instant Wireless Network PC Card at port 
0x100-0x13f irq 20 function 0 config 1 on pccard0
 wlan0: Ethernet address: 00:06:25:10:56:3b
 lock order reversal:
 1st 0xff80012be018 wi0_com_lock (wi0_com_lock) @ 
/usr/src/sys/net80211/ieee80211_scan.c:806
 2nd 0xfe0001b8d010 wi0 (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 _witness_debugger() at _witness_debugger+0x2e
 witness_checkorder() at witness_checkorder+0x807
 _mtx_lock_flags() at _mtx_lock_flags+0x79
 wi_raw_xmit() at wi_raw_xmit+0x68
 ieee80211_send_probereq() at ieee80211_send_probereq+0x3f7
 scan_curchan() at scan_curchan+0x49
 scan_task() at scan_task+0x2d5
 taskqueue_run_locked() at taskqueue_run_locked+0x93
 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f
 fork_exit() at fork_exit+0x12a
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff80d401ad00, rbp = 0 ---


In case it matters I've

hw.cbb.start_memory=0xf480

in /boot/loader.conf, according to
http://www.freebsd.org/cgi/query-pr.cgi?pr=115623


Please advise

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: lockup with vidcontrol VESA_800x600

2011-01-09 Thread Marc UBM Bocklet
On Sun, 9 Jan 2011 11:45:52 -0500
Chris Brennan xa...@xaerolimit.net wrote:

 Did you try
 http://www.freebsdwiki.net/index.php/High_Resolution_Console?

Yeah, those are the kernel settings that I've been using since approx.
2004 :-). But the wiki page yielded a new data point - trying to set
MODE_280 (which corresponds to 1024x...@24 on my system, too) locks
the system up just as well.

Thanks  bye,
Marc

-- 
Marc UBM Bocklet ubm.free...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: lockup with vidcontrol VESA_800x600

2011-01-09 Thread Chris Brennan
On Sun, Jan 9, 2011 at 1:22 PM, Marc UBM Bocklet ubm.free...@googlemail.com
 wrote:

 On Sun, 9 Jan 2011 11:45:52 -0500
 Chris Brennan xa...@xaerolimit.net wrote:

  Did you try
  http://www.freebsdwiki.net/index.php/High_Resolution_Console?

 Yeah, those are the kernel settings that I've been using since approx.
 2004 :-). But the wiki page yielded a new data point - trying to set
 MODE_280 (which corresponds to 1024x...@24 on my system, too) locks
 the system up just as well.

 Thanks  bye,
 Marc


Weird because I have this working fine on my amd64 laptop w/ 8.1.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Marek Salwerowicz



Again, it works for me (using a pretty current FreeBSD client). The
only difference is that I never run mount_nfs directly and would use
the following command:

# mount -t nfs -o nfsv4 192.168.183.131:/home /tmp/nfs4

Assuming the client is a FreeBSD8 box on the 192.168.183.0 subnet,
I don't know why it wouldn't work, except that I'd suggest trying
the command the way I type it, in case that runs it with somewhat
different options?

rick


So, I added in /etc/rc.conf:

rpcbind_enable=YES

reboot and again typed the commands above.

and now it seems to WORK ;) :

nfs4-client# mount -t nfs -o nfsv4 192.168.183.131:/home /tmp/nfs4
nfs4-client# mount -t newnfs
192.168.183.131:/home on /tmp/nfs4 (newnfs)
nfs4-client# umount /tmp/nfs4
nfs4-client# mount -t nfs 192.168.183.131:/usr/home /tmp/nfs3
[tcp] 192.168.183.131:/usr/home: NFSPROC_NULL: RPC: Program/version 
mismatch; low version = 4, high version = 4


^C
nfs4-client#

with mount_nfs command it behaves the same.


Good to know if it will work with nfsv4 server started via rc.conf and 
sysctl values in sysctl.conf..



--
Marek Salwerowicz

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: NFSv4 and pam_mount - mounting user home directories.

2011-01-09 Thread Marek Salwerowicz

Good to know if it will work with nfsv4 server started via rc.conf and
sysctl values in sysctl.conf..


build a kernel with options NFSD in its config file and then try it
with that kernel, and then you'll find out...



How about patching the /etc/rc.d/nfsd script like this:


[..]
nfsd_precmd()
{
   if checkyesno nfs_server_newnfs_only; then
   echo 'NFS server serving only newnfs (NFSv4)=YES'
   sysctl vfs.newnfs.server_min_nfsvers=4  /dev/null
   fi
[..]

It checks if there is a 
nfs_server_newnfs_only=YES 
set in rc.conf, and if so, it runs the sysctl command.


But, after testing, it is too late (nfsd starts with NFSv3 support). Any idea 
where to put that patch  ?

--
Marek Salwerowicz
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org