/ auto-sizing (Was: 9.0-BETA1 installer glithcies (i386))
Hi Nathan Whitehorn! On Sun, 21 Aug 2011 11:53:22 -0500; Nathan Whitehorn wrote about 'Re: 9.0-BETA1 installer glithcies (i386)': (3) Auto creates one big / partition + SWAP. It looks very not-BSD way (disk is only 8Gb, it is virtual machine). This is designed to ease resizing on VMs as well as to kill the default-/-is-too-small problem forever. There was a great deal of discussion about this several months ago; no one made a final proposal for changing it. Actually, it's simple: make / be able to survive 5 years from now (a reasonable age before major upgrade). So, the size needs to be predicted. http://en.wikipedia.org/wiki/File:Hard_drive_capacity_over_time.svg says that hard disks sizes grow according to Moore's Law, 10 times per 5 years. The FreeBSD kernel sizes grow slower, though. As of src/usr.sbin/sysinstall/label.c CVS log: rev 1.161: / 1 Gb in Jul 2010 rev 1.149: / 512 Mb in Aug 2005, formulas for other pertitions provided, / 256 Mb if RAMsize/harddisk size gives another value rev 1.106: / 120 Mb in Apr 2001 ...added by tens of Mbs before, not doubled So it doubles or fourths every 5 years, thus, to reserve, let's set / to 2 or 4 Gb in 2011. Also don't create /tmp partition but rather do: lrwxr-xr-x 1 root wheel -12 9 Jan 2010 /tmp - /var/tmp/tmp drwxrwxrwt 9 root wheel sunlnk 1024 23 Aug 16:55 /var/tmp/tmp Actually, this is just most simple short-term solution for auto-sizing. For long-term, it should be considered to merge / and /usr with separate partitions for ports, local, and so on, that's easy on ZFS. I have on 7.x: Filesystem SizeUsed Avail Capacity Mounted on /dev/ad0s1a1.4G1.1G253M81%/ devfs 1.0K1.0K 0B 100%/dev /dev/ad0s1f4.4G3.9G 66M98%/home /dev/ad0s1e6.8G4.4G1.9G70%/usr/local /dev/ad0s1d1.9G1.4G412M77%/var devfs 1.0K1.0K 0B 100%/var/named/dev lrwxr-xr-x 1 root wheel 13 29 дек 2009 /usr/obj - local/BSD/obj lrwxr-xr-x 1 root wheel 15 29 дек 2009 /usr/ports - local/BSD/ports lrwxr-xr-x 1 root wheel 13 29 дек 2009 /usr/src - local/BSD/src but that will cause another long boring bikesched without clear final proposal :-) So for 9.0R it is simpler to take short-term approach. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.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
Panic with 9.0 Beta 1 (arcmsr.c)
Hi, i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a kernel panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 A screenshot from the panic can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png Chers, Uwe ___ 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
LOR 9.0 beta1
Maybe already seen... This is within Parallels 6.0 VM on a Mac with OS 10.6.8 Aug 23 09:11:54 tramp kernel: lock order reversal: Aug 23 09:11:54 tramp kernel: 1st 0xff803d3d08b8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 Aug 23 09:11:54 tramp kernel: 2nd 0xfe0002b6c800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 Aug 23 09:11:54 tramp kernel: KDB: stack backtrace: Aug 23 09:11:54 tramp kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Aug 23 09:11:54 tramp kernel: kdb_backtrace() at kdb_backtrace+0x37 Aug 23 09:11:54 tramp kernel: _witness_debugger() at _witness_debugger+0x2e Aug 23 09:11:54 tramp kernel: witness_checkorder() at witness_checkorder+0x807 Aug 23 09:11:54 tramp kernel: _sx_xlock() at _sx_xlock+0x55 Aug 23 09:11:54 tramp kernel: ufsdirhash_acquire() at ufsdirhash_acquire+0x33 Aug 23 09:11:54 tramp kernel: ufsdirhash_add() at ufsdirhash_add+0x19 Aug 23 09:11:54 tramp kernel: ufs_direnter() at ufs_direnter+0x8c9 Aug 23 09:11:54 tramp kernel: ufs_makeinode() at ufs_makeinode+0x25b Aug 23 09:11:54 tramp kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0x8d Aug 23 09:11:54 tramp kernel: vn_open_cred() at vn_open_cred+0x46a Aug 23 09:11:54 tramp kernel: kern_openat() at kern_openat+0x17f Aug 23 09:11:54 tramp kernel: syscallenter() at syscallenter+0x1aa Aug 23 09:11:54 tramp kernel: syscall() at syscall+0x4c Aug 23 09:11:54 tramp kernel: Xfast_syscall() at Xfast_syscall+0xdd Aug 23 09:11:54 tramp kernel: --- syscall (5, FreeBSD ELF64, open), rip = 0x801348e2c, rsp = 0x7fffd658, rbp = 0x8 --- Aug 23 09:18:44 tramp kernel: lock order reversal: Aug 23 09:18:44 tramp kernel: 1st 0xfe0015459278 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:501 Aug 23 09:18:44 tramp kernel: 2nd 0xff803d4889b8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:261 Aug 23 09:18:44 tramp kernel: 3rd 0xfe00154b5db8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 Aug 23 09:18:44 tramp kernel: KDB: stack backtrace: Aug 23 09:18:44 tramp kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Aug 23 09:18:44 tramp kernel: kdb_backtrace() at kdb_backtrace+0x37 Aug 23 09:18:44 tramp kernel: _witness_debugger() at _witness_debugger+0x2e Aug 23 09:18:44 tramp kernel: witness_checkorder() at witness_checkorder+0x807 Aug 23 09:18:44 tramp kernel: __lockmgr_args() at __lockmgr_args+0xd42 Aug 23 09:18:44 tramp kernel: ffs_lock() at ffs_lock+0x8c Aug 23 09:18:44 tramp kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b Aug 23 09:18:44 tramp kernel: _vn_lock() at _vn_lock+0x47 Aug 23 09:18:44 tramp kernel: vget() at vget+0x7b Aug 23 09:18:44 tramp kernel: vfs_hash_get() at vfs_hash_get+0xd5 Aug 23 09:18:44 tramp kernel: ffs_vgetf() at ffs_vgetf+0x48 Aug 23 09:18:44 tramp kernel: softdep_sync_buf() at softdep_sync_buf+0x547 Aug 23 09:18:44 tramp kernel: ffs_syncvnode() at ffs_syncvnode+0x299 Aug 23 09:18:44 tramp kernel: ffs_truncate() at ffs_truncate+0x463 Aug 23 09:18:44 tramp kernel: ufs_direnter() at ufs_direnter+0x6ff Aug 23 09:18:44 tramp kernel: ufs_makeinode() at ufs_makeinode+0x25b Aug 23 09:18:44 tramp kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0x8d Aug 23 09:18:44 tramp kernel: vn_open_cred() at vn_open_cred+0x46a Aug 23 09:18:44 tramp kernel: kern_openat() at kern_openat+0x17f Aug 23 09:18:44 tramp kernel: syscallenter() at syscallenter+0x1aa Aug 23 09:18:44 tramp kernel: syscall() at syscall+0x4c Aug 23 09:18:44 tramp kernel: Xfast_syscall() at Xfast_syscall+0xdd Aug 23 09:18:44 tramp kernel: --- syscall (5, FreeBSD ELF64, open), rip = 0x800dc6e2c, rsp = 0x7fffd2d8, rbp = 0x1 --- Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ 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: Panic with 9.0 Beta 1 (arcmsr.c)
On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: Hi, i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a kernel panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 A screenshot from the panic can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png Looks like this was fixed after BETA1 was released. -- John Baldwin ___ 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: Panic with 9.0 Beta 1 (arcmsr.c)
On 23 August 2011 14:57, Uwe Grohnwaldt u...@grohnwaldt.eu wrote: Hi, i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a kernel panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 A screenshot from the panic can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png HI, that should be fixed in head (and in forthcoming BETA2). You can apply this patch from head to fix panic: http://svnweb.freebsd.org/base/head/sys/dev/arcmsr/arcmsr.c?view=patchr1=224905r2=224904pathrev=224905 -- wbr, pluknet ___ 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: fsid change of ZFS?
On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote: Hiroki, could you please test the attached patch. One problem with this patch is that I don't know how to create a fixed table that matches what systems would already have been getting. (I got the first 6 entries by booting a GENERIC i386 kernel with a printf in vfs_init(), so I suspect those don't change much, although I'm not sure if ZFS will usually end up before or after them?) Do you guys know what ZFS gets assigned typically? (I realize that changes w.r.t. when it gets loaded, so the question also becomes do you know how it typically gets loaded so the table can have that vfc_typenum value assigned to it?) Maybe you could boot a system with a printf like: printf(%s, %d\n, vfc-vfc_name, vfc-vfc_typenum); just after vfc-vfc_typenum = maxvfsconf++; in vfs_init() and then look in dmesg after booting, to see what your tables look like? (Without the attached patch installed.) Rick, I'm sorry to arrive so late, but in my opinion hardcoding list of file systems in the kernel is a step in wrong direction, really. We are trying to keep things modularized, so there are no such things laying around that have to be cleaned up when file system goes away or updated when new file system arrives. I remember for example fts code where I found that it keeps list of file systems that can be handled faster. ZFS could have been handled faster, but I found this after few years. For this case there should be VFCF_* flag that fts shuld recognize and not hardcore file system names. This was also the reason that when I added support for jail-friendly file systems and support for file systems with delegated administration I haven't created list of file system types that support it, but added VFCF_JAIL and VFCF_DELEGADMIN flags. Here you cannot use those flags to solve the problem, but hardcoding file system types in an array is really not the way to go. I much prefer Ben's idea of calculating a hash from file system name and detecting collisions. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpJBiqW9g9eb.pgp Description: PGP signature
skipping locks, mutex_owned, usb
Yes, the subject sounds quite hairy, so please let me try to explain it.
First, let's consider one concrete function:
static int
ukbd_poll(keyboard_t *kbd, int on)
{
struct ukbd_softc *sc = kbd-kb_data;
if (!mtx_owned(Giant)) {
/* XXX cludge */
int retval;
mtx_lock(Giant);
retval = ukbd_poll(kbd, on);
mtx_unlock(Giant);
return (retval);
}
if (on) {
sc-sc_flags |= UKBD_FLAG_POLLING;
sc-sc_poll_thread = curthread;
} else {
sc-sc_flags = ~UKBD_FLAG_POLLING;
ukbd_start_timer(sc); /* start timer */
}
return (0);
}
This XXX cludge [sic] pattern is scattered around a few functions in the ukbd
code and perhaps other usb code:
func()
{
if (!mtx_owned(Giant)) {
mtx_lock(Giant);
func();
mtx_unlock(Giant);
return;
}
// etc ...
}
I have a few question directly and indirectly related to this pattern.
I. [Why] do we need this pattern?
Can the code be re-written in a smarter (if not to say proper) way?
II. ukbd_poll() in particular can be called from the kdb context (kdb_trap -
db_trap - db_command_loop - etc). What would happen if the Giant is held by a
thread on some other CPU (which would be hard-stopped by kdp_trap)? Won't we
get
a lockup here?
So shouldn't this code actually check for kdb_active?
III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite chains
of 'infinite' recursion because mtx_owned() always returns false. This is
because
I skip all lock/unlock/etc operations in the post-panic context. I think that
it's a good philosophical question: what operations like mtx_owned(),
mtx_recursed(), mtx_trylock() 'should' return when we actually act as if no
locks
exist at all?
My first knee-jerk reaction was to change mtx_owned() to return true in this
lock-less context, but _hypothetically_ there could exist some symmetric code
that does something like:
func()
{
if (mtx_owned(Giant)) {
mtx_unlock(Giant);
func();
mtx_lock(Giant);
return;
}
// etc ...
What do you think about this problem?
Should we re-write ukbd_poll() (and possibly usb code) or should mutex_owned()
be
adjusted?
That question III actually brings another thought: perhaps the whole of idea of
skipping locks in a certain context is not a correct direction?
Perhaps, instead we should identify all the code that could be legitimately
executed in the after-panic and/or kdb contexts and make that could explicitly
aware of its execution context. That is, instead of trying to make _lock,
_unlock, _owned, _trylock, etc do the right thing auto-magically, we should try
to
make the calling code check panicstr and kdb_active and do the right thing on
that
level (which would include not invoking those lock-related operations or other
inappropriate operations).
Thank you very much in advance for your insights and help!
--
Andriy Gapon
___
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: skipping locks, mutex_owned, usb
On Tuesday 23 August 2011 14:09:15 Andriy Gapon wrote:
Yes, the subject sounds quite hairy, so please let me try to explain it.
First, let's consider one concrete function:
static int
ukbd_poll(keyboard_t *kbd, int on)
{
struct ukbd_softc *sc = kbd-kb_data;
if (!mtx_owned(Giant)) {
/* XXX cludge */
int retval;
mtx_lock(Giant);
retval = ukbd_poll(kbd, on);
mtx_unlock(Giant);
return (retval);
}
if (on) {
sc-sc_flags |= UKBD_FLAG_POLLING;
sc-sc_poll_thread = curthread;
} else {
sc-sc_flags = ~UKBD_FLAG_POLLING;
ukbd_start_timer(sc); /* start timer */
}
return (0);
}
This XXX cludge [sic] pattern is scattered around a few functions in the
ukbd code and perhaps other usb code:
func()
{
if (!mtx_owned(Giant)) {
mtx_lock(Giant);
func();
mtx_unlock(Giant);
return;
}
// etc ...
}
I have a few question directly and indirectly related to this pattern.
Hi Andriy,
Thanks for bringing up this topic.
I. [Why] do we need this pattern?
Can the code be re-written in a smarter (if not to say proper) way?
Unless that API's surrounding ukbd change, we are stuck with auto-magic Giant
locking inside ukbd. The USB stack itself does not require that Giant is used
for the USB keyboard driver. It is some times since I touched this topic. From
what I remember some interfacing layers of ukbd are using Giant. Some are not.
Much of the existing non-USB keyboard code is written to get/put key-presses
directly through legacy PCI/ISA registers. This approach is deferred in the
USB stack, hence it would cause blocking delays of 1ms per polling operation.
Another corner case:
When you are scrolling the console having scroll lock locked, then the first
printf on that console will directly call an IOCTL in the ukbd to switch off
the scroll lock led. As you might be aware this can be dangerous. The ukbd is
also sometimes printing stuff. The chance of deadlock and LOR is increasing.
Without having to push for multiple changes outside ukbd, this problem is
simply hidden in UKBD by checking if Giant is locked, which is required for
starting the USB transfers in UKBD. I think it would be a very bad idea to
lock another lock in a sub-function of printf. See!
A multithread / taskqueue interface is needed for postponing keyboard events.
And what about polling and UKBD? This needs a separate calling path I think.
II. ukbd_poll() in particular can be called from the kdb context (kdb_trap
- db_trap - db_command_loop - etc). What would happen if the Giant is
held by a thread on some other CPU (which would be hard-stopped by
kdp_trap)? Won't we get a lockup here?
So shouldn't this code actually check for kdb_active?
III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite
chains of 'infinite' recursion because mtx_owned() always returns false.
This is because I skip all lock/unlock/etc operations in the post-panic
context. I think that it's a good philosophical question: what operations
like mtx_owned(), mtx_recursed(), mtx_trylock() 'should' return when we
actually act as if no locks exist at all?
My first knee-jerk reaction was to change mtx_owned() to return true in
this lock-less context, but _hypothetically_ there could exist some
symmetric code that does something like:
func()
{
if (mtx_owned(Giant)) {
mtx_unlock(Giant);
func();
mtx_lock(Giant);
return;
}
// etc ...
What do you think about this problem?
Should we re-write ukbd_poll() (and possibly usb code) or should
mutex_owned() be adjusted?
I think you've brought an interesing problem. I would suggest to change
mtx_owned or make a new function to take an integer value to handle the case
of SCHEDULER_STOPPED:
mtx_owned_default(struct mtx *, int return value in case of
SCHEDULER_STOPPED);
That question III actually brings another thought: perhaps the whole of
idea of skipping locks in a certain context is not a correct direction?
Perhaps, instead we should identify all the code that could be legitimately
executed in the after-panic and/or kdb contexts and make that could
explicitly aware of its execution context. That is, instead of trying to
make _lock, _unlock, _owned, _trylock, etc do the right thing
auto-magically, we should try to make the calling code check panicstr and
kdb_active and do the right thing on that level (which would include not
invoking those lock-related operations or other inappropriate operations).
Thank you very much in advance for your insights and help!
--HPS
___
freebsd-current@freebsd.org mailing list
AW: Panic with 9.0 Beta 1 (arcmsr.c)
Ah, thanks for your fast reply. :) -Ursprüngliche Nachricht- Von: Sergey Kandaurov [mailto:pluk...@gmail.com] Gesendet: Dienstag, 23. August 2011 13:18 An: Uwe Grohnwaldt Cc: curr...@freebsd.org Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) On 23 August 2011 14:57, Uwe Grohnwaldt u...@grohnwaldt.eu wrote: Hi, i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a kernel panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 A screenshot from the panic can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png HI, that should be fixed in head (and in forthcoming BETA2). You can apply this patch from head to fix panic: http://svnweb.freebsd.org/base/head/sys/dev/arcmsr/arcmsr.c?view=patc hr1=224905r2=224904pathrev=224905 -- wbr, pluknet ___ 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: fsid change of ZFS?
Pawel Jakub Dawidek wrote: On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote: Hiroki, could you please test the attached patch. One problem with this patch is that I don't know how to create a fixed table that matches what systems would already have been getting. (I got the first 6 entries by booting a GENERIC i386 kernel with a printf in vfs_init(), so I suspect those don't change much, although I'm not sure if ZFS will usually end up before or after them?) Do you guys know what ZFS gets assigned typically? (I realize that changes w.r.t. when it gets loaded, so the question also becomes do you know how it typically gets loaded so the table can have that vfc_typenum value assigned to it?) Maybe you could boot a system with a printf like: printf(%s, %d\n, vfc-vfc_name, vfc-vfc_typenum); just after vfc-vfc_typenum = maxvfsconf++; in vfs_init() and then look in dmesg after booting, to see what your tables look like? (Without the attached patch installed.) Rick, I'm sorry to arrive so late, but in my opinion hardcoding list of file systems in the kernel is a step in wrong direction, really. We are trying to keep things modularized, so there are no such things laying around that have to be cleaned up when file system goes away or updated when new file system arrives. I remember for example fts code where I found that it keeps list of file systems that can be handled faster. ZFS could have been handled faster, but I found this after few years. For this case there should be VFCF_* flag that fts shuld recognize and not hardcore file system names. This was also the reason that when I added support for jail-friendly file systems and support for file systems with delegated administration I haven't created list of file system types that support it, but added VFCF_JAIL and VFCF_DELEGADMIN flags. Here you cannot use those flags to solve the problem, but hardcoding file system types in an array is really not the way to go. I much prefer Ben's idea of calculating a hash from file system name and detecting collisions. Ok, I'll admit I wasn't very fond of a fixed table that would inevitably get out of date someday, either. I didn't think hashing for the cases not in the table was worth the effort, but doing a hash instead of a table seems reasonable. I see that ZFS only uses the low order 8 bits, so I'll try and come up with an 8bit hash solution and will post a patch for testing/review soon. I don't think the vfs_sysctl() is that great a concern, given that it appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum won't be that sparse.) I'll also make sure that whatever hash I use doesn't collide for the current list of file names (although I will include code that handles a collision in the patch). Thanks for the comments, rick -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.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: LOR 9.0 beta1
On Tue, Aug 23, 2011 at 4:29 AM, Holger Kipp holger.k...@alogis.com wrote: Maybe already seen... This is within Parallels 6.0 VM on a Mac with OS 10.6.8 ... This is a well known LOR. Thanks, -Garrett ___ 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: fsid change of ZFS?
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: Ok, I'll admit I wasn't very fond of a fixed table that would inevitably get out of date someday, either. I didn't think hashing for the cases not in the table was worth the effort, but doing a hash instead of a table seems reasonable. I see that ZFS only uses the low order 8 bits, so I'll try and come up with an 8bit hash solution and will post a patch for testing/review soon. I don't think the vfs_sysctl() is that great a concern, given that it appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum won't be that sparse.) I'll also make sure that whatever hash I use doesn't collide for the current list of file names (although I will include code that handles a collision in the patch). Sounds great. Thanks! -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpDcE0skKKef.pgp Description: PGP signature
Re: kldload uhci, system grinds to halt
After filling sticks with zeros, and writing data again on them, cannot replicate. Maybe usb sticks were to blame. One was brand new, possibly loaded with some helpful software, and other contained broken OpenBSD install. Thanks for attention. best regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/kldload-uhci-system-grinds-to-halt-tp4723962p4727173.html Sent from the freebsd-current mailing list archive at Nabble.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
login problem after update.
This morning I updated an amd64 machine which had been running -CURRENT from April 18 to last night's version. The build/build/install/install process seemed to go as usual. However, when I tried to log in (any user) I get: login: tac_config: cannot open /etc/tacplus.conf Login: pam_authenticate(): error in services module and at a different point: su: in openpam_dispatch(): pam_unix.so: no pam_sm_acct_mgmt() I have checked, and there is no /etc/tacplus.conf; but there wasn't one in the full backup done MOnday either, at which point everything was working. The file is in the man pages, but with no mention of how it is created. What have I mangled, and how to I fix it? Robert Huff ___ 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: login problem after update.
On Tue, Aug 23, 2011 at 11:12 AM, Robert Huff roberth...@rcn.com wrote: This morning I updated an amd64 machine which had been running -CURRENT from April 18 to last night's version. The build/build/install/install process seemed to go as usual. However, when I tried to log in (any user) I get: login: tac_config: cannot open /etc/tacplus.conf Login: pam_authenticate(): error in services module and at a different point: su: in openpam_dispatch(): pam_unix.so: no pam_sm_acct_mgmt() I have checked, and there is no /etc/tacplus.conf; but there wasn't one in the full backup done MOnday either, at which point everything was working. The file is in the man pages, but with no mention of how it is created. What have I mangled, and how to I fix it? make -C /usr/src/lib/libpam/ all install Maybe? I can't find tacplus.conf anywhere on my system in /usr/src or /usr/obj , and it isn't installed in /etc either, so it seems optional at least (assuming that you don't use the tacacs login class in /etc/login.conf?). Thanks, -Garrett ___ 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: login problem after update.
On 8/23/2011 2:57 PM, Garrett Cooper wrote: What have I mangled, and how to I fix it? make -C /usr/src/lib/libpam/ all install Maybe? That _seems_ to have fixed things. If so, I have to wonder why this didn't happen during the installworld. Oh well THanks, Robert Huff ___ 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[2]: Kernel panic rtfree 2
17 августа 2011, 04:02 от Li, Qing qing...@bluecoat.com: Hi, Could you please let me know if the patch fixes your crash problem ? Thanks, --Qing -Original Message- From: Li, Qing Sent: Friday, August 12, 2011 6:29 PM To: Li, Qing; Luiz Otavio O Souza; Andrey Smagin Cc: freebsd-current@freebsd.org Subject: RE: Kernel panic rtfree 2 Hi, Please re-enable RADIX_MPATH option in your kernel config file, and try the following patch: http://people.freebsd.org/~qingli/radix_mpath.c.diff and let me know if it works out for you. I performed very limited testing. Thanks, --Qing Thanks, Your patch resolve problem, I have 3 day uptime without panic ___ 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: fsid change of ZFS?
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a fixed table that would
inevitably
get out of date someday, either.
I didn't think hashing for the cases not in the table was worth the
effort,
but doing a hash instead of a table seems reasonable.
I see that ZFS only uses the low order 8 bits, so I'll try and come
up
with an 8bit hash solution and will post a patch for testing/review
soon.
I don't think the vfs_sysctl() is that great a concern, given that
it
appears to be deprecated already anyhow. (With an 8bit hash,
vfs_typenum
won't be that sparse.) I'll also make sure that whatever hash I use
doesn't collide for the current list of file names (although I will
include
code that handles a collision in the patch).
Sounds great. Thanks!
Here's the patch. (Hiroki could you please test this, thanks, rick.)
ps: If the white space gets trashed, the same patch is at:
http://people.freebsd.org/~rmacklem/fsid.patch
--- kern/vfs_init.c.sav 2011-06-11 18:58:33.0 -0400
+++ kern/vfs_init.c 2011-08-23 15:55:30.0 -0400
@@ -39,6 +39,7 @@ __FBSDID($FreeBSD: head/sys/kern/vfs_in
#include sys/param.h
#include sys/systm.h
+#include sys/hash.h
#include sys/kernel.h
#include sys/linker.h
#include sys/mount.h
@@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc)
struct sysctl_oid *oidp;
struct vfsops *vfsops;
static int once;
+ struct vfsconf *tvfc;
+ uint32_t hashval;
if (!once) {
vattr_null(va_null);
@@ -152,7 +155,27 @@ vfs_register(struct vfsconf *vfc)
if (vfs_byname(vfc-vfc_name) != NULL)
return EEXIST;
- vfc-vfc_typenum = maxvfsconf++;
+ /*
+* Calculate a hash on vfc_name to use for vfc_typenum. Unless
+* a collision occurs, it is limited to 8bits since that is
+* what ZFS uses from vfc_typenum and that also limits how sparsely
+* distributed vfc_typenum becomes.
+*/
+ hashval = hash32_str(vfc-vfc_name, 0);
+ hashval = ((hashval 0xff) + ((hashval 8) 0xff) +
+ ((hashval 16) 0xff) + (hashval 24)) 0xff;
+ do {
+ /* Look for and fix any collision. */
+ TAILQ_FOREACH(tvfc, vfsconf, vfc_list) {
+ if (hashval == tvfc-vfc_typenum) {
+ hashval++; /* Can exceed 8bits, if needed. */
+ break;
+ }
+ }
+ } while (tvfc != NULL);
+ vfc-vfc_typenum = hashval;
+ if (vfc-vfc_typenum = maxvfsconf)
+ maxvfsconf = vfc-vfc_typenum + 1;
TAILQ_INSERT_TAIL(vfsconf, vfc, vfc_list);
/*
___
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: fsid change of ZFS?
On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: Pawel Jakub Dawidek wrote: On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: Ok, I'll admit I wasn't very fond of a fixed table that would inevitably get out of date someday, either. I didn't think hashing for the cases not in the table was worth the effort, but doing a hash instead of a table seems reasonable. I see that ZFS only uses the low order 8 bits, so I'll try and come up with an 8bit hash solution and will post a patch for testing/review soon. I don't think the vfs_sysctl() is that great a concern, given that it appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum won't be that sparse.) I'll also make sure that whatever hash I use doesn't collide for the current list of file names (although I will include code that handles a collision in the patch). Sounds great. Thanks! Here's the patch. (Hiroki could you please test this, thanks, rick.) ps: If the white space gets trashed, the same patch is at: http://people.freebsd.org/~rmacklem/fsid.patch The patch is fine by me. Thanks, Rick! -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpsuJPptDK8Q.pgp Description: PGP signature
