Re: Atomic updates of NFS export lists
Andrey Simonenko wrote: [Lots of good stuff] Now mountd does not work if there is some error in exports file. I think this is correct behaviour and I'm ready to explain this. Hello Andrey, I hope these 'errors' in the exports file only mean syntactical errors? For example, I have a /vol partition mounted on my NFS server, which is exported via NFS. Now, sometimes /vol is mounted, sometimes it is not mounted (on the server). This will generate some warnings from mountd, as it can't export the /vol filesystem, but mountd still works the same. Once /vol becomes available, I don't even need to restart mountd, it will simply pick up /vol and make it available. I hope these semantics will remain? (No sorry, I didn't not test your patch yet). Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgpgo3MCQM24c.pgp Description: PGP signature
Re: Per CPU cpu-statistics under SMP
On Mon, Apr 24, 2006 at 12:58:57PM +, Marco van Tol wrote: On Mon, Apr 24, 2006 at 08:23:48AM -0400, John Baldwin wrote: [...] If I can address the performance problems though this is the interface that would be presented to userland. OK, I'll keep an eye on this list and /usr/src/UPDATES, assuming it will end up in either if it were added. Meanwhile, I'll see if gkrellm likes my changes sufficiently to commit them to their CVS tree after I got things to work in client/server mode as well. If anything should change for whatever reason it should be fairly trivial to make the necessary changes. The client/server issue got fixed as well. Just needed a recompile. (Doh!) :( Anyway, gkrellm is ready to review/commit my changes as soon as this ends up in the BSD tree. :) Marco -- Gisteren is het niet gelukt. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atomic updates of NFS export lists
On Mon, Apr 24, 2006 at 01:56:31PM +0200, Ulrich Spoerlein wrote: Andrey Simonenko wrote: [Lots of good stuff] Now mountd does not work if there is some error in exports file. I think this is correct behaviour and I'm ready to explain this. Hello Andrey, I hope these 'errors' in the exports file only mean syntactical errors? For example, I have a /vol partition mounted on my NFS server, which is exported via NFS. Now, sometimes /vol is mounted, sometimes it is not mounted (on the server). This will generate some warnings from mountd, as it can't export the /vol filesystem, but mountd still works the same. Once /vol becomes available, I don't even need to restart mountd, it will simply pick up /vol and make it available. I hope these semantics will remain? (No sorry, I didn't not test your patch yet). In general ignoring lines is not safe, since this can give wrong access rights. For example if second line is ignored and /usr/local is in the same filesystem as /usr, then 10.1.2.3 will match 10.1.2.0/24 and will get r/w access for /usr: /usr -network 10.1.2.0/24 /usr/local -ro 10.1.2.3 Output from mountd -t: Filesystem /usr, type ufs, fsid 0x43d21dca:0x0225d70c Exported directories: /usr -network 10.1.2.0/24 /usr/local -ro 10.1.2.3 I disallowed duplicated export specifications: /var 10.1.2.3 /var/vol 10.1.2.3 parsing error: exports4:2: duplicated IPv4 address specification 10.1.2.3 was found for /var filesystem But this can be solved with -quiet option as in your case: /var 10.1.2.3 /var/vol -quiet 10.1.2.3 parsing error: exports4:2: duplicated IPv4 address specification 10.1.2.3 was found for /var filesystem parsing error: exports4:2: this line is ignored Filesystem /var, type ufs, fsid 0x43d21dcb:0x22fc3751 Exported directories: /var 10.1.2.3 When another filesystem is mounted on /var/vol, then: Filesystem /var, type ufs, fsid 0x43d21dcb:0x22fc3751 Exported directories: /var 10.1.2.3 Filesystem /var/vol, type ufs, fsid 0x444de7a4:0x96b6cba3 Filesystem options: -quiet Exported directories: /var/vol 10.1.2.3 There is no need to restart mountd as you said, if filesystem is mounted with mount(8), then mount(8) sends SIGHUP signal to mountd and it reloads exports file, so it is self-restarted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[ANN] unionfs patchset-11 release
It is my pleasure and honor to announce the availability of the unionfs patchset-11. Patchset-11: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p11.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p11.diff Changes in unionfs-p11.diff - Changed a few implementations around the lock/unlock mechanism. Because of this, you can use both the unionfs and the nullfs together without LK_CANRECURSE. - Fixed a bug that sometimes does not unlock if it cannot create shadow file. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Heads Up: Fabian Keil gave me a good patch to fix my broken English. Above English text is good rather than pre one. Heads Up: Above English text contains some Japanese text. If you are interested in translating the Japanese text into English, please do it and send it to me. ATTENTION: If someone knows the details of vnode's lock status via VOP_GETWRITEMOUNT, Please teach us (daichi, ozawa). We want to know the details. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
gmirror with hot spare
Hi hackers, is there a way to assign a hot spare disk/partition to a gmirror -ed disks/partitions ? Regards, Vladimir ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror with hot spare
On Tue, April 25, 2006 9:19 am, Vladimir Terziev said: Hi hackers, is there a way to assign a hot spare disk/partition to a gmirror -ed disks/partitions ? That's a good question. From the man pages there doesn't seem to exist anything to mark a insert disk as disabled. Atacontrol has a addspare option. Just in case, to replace a faulty (SCSI) disk: gmirror remove gm0 da1 camcontrol stop da1 camcontrol rescan all camcontrol rescan all (after inserting replacement) gmirror insert gm0 da1 The same procedure in atacontrol would be similar to: atacontrol detach 3 atacontrol attach 3 atacontrol addspare ar0 ad6 atacontrol rebuild ar0 Good luck, -- Giovanni P. Tirloni http://www.tirloni.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ANN] unionfs patchset-11 release
On Tue, 25 Apr 2006, Daichi GOTO wrote: Changes in unionfs-p11.diff - Changed a few implementations around the lock/unlock mechanism. Because of this, you can use both the unionfs and the nullfs together without LK_CANRECURSE. - Fixed a bug that sometimes does not unlock if it cannot create shadow file. First off, thanks again for working on this! If someone knows the details of vnode's lock status via VOP_GETWRITEMOUNT, Please teach us (daichi, ozawa). We want to know the details. Basically, file systems supporting full file system snapshots (UFS) provide a mechanism to lock out writers before they enter VFS so that they don't end up holding write locks for long periods, leading to deadlock. vn_start_write() is called to notify the file system that a thread is about to enter the file system for a write, and vn_write_finished() is called to notify the file system it is done. In effect, it's a giant reader-writer lock, which allows multiple readers and multipler writers, except during snapshot generation, when it blocks new writers until the snapshot is generated. In general, you'll notice two sorts of logic around calls to vn_start_write(): a first set, where vn_start_write() is called once holding a vnode reference, is acquired, and then things continue as normal, with a final vn_finished_write() call at the end. In this situation, vnode locks are acquired after the vn_start_write() call, but vnode references are held before (since vn_start_write() takes a vnode so that it can find the file system). The other circumstance is where vnode locks may already be held, in which case a non-sleeping acquire is performed, since in effect this is a violation of lock order. If it fails, the vnode lock is released, the reference is acquired, and then the whole operation is restarted so that we can try again to acquire the vnode lock under circumstances where file system snapshot lock can be safely acquired. So basically, it has deadlock detection and recovery logic. The V_XSLEEP lock basically says Sleep until the snapshot lock would be available, then return, which loops back so we can re-try the acquires. So according to the above, the file system snapshot lock is *before* the vnode locks in the lock order, although in practice we acquire in any order as long as it won't lead to deadlock (in which case we recover). The logic here is a little shaky in practice -- among other things, it looks like potentially the mount point could go away during the call to vn_start_write() once the vnode is released in the deadlock detection code, but in practice this probably never happens. Notice that the above is all couched in terms of a single file system, not stacking. This is probably because it was all written with UFS and not stacking in mind. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ANN] unionfs patchset-11 release
Hi Goto-san, From: Daichi GOTO daichi-at-freebsd.org Date: Tue, 25 Apr 2006 21:19:06 +0900 ::It is my pleasure and honor to announce the availability of ::the unionfs patchset-11. snip :: Heads Up: Above English text contains some Japanese text. :: If you are interested in translating the Japanese :: text into English, please do it and send it to me. How about this? =-- On creating a hardlink, due to VOP_GETWRITEMOUNT() called right after lookup(), if only files exist in the underlying filesystem, VOP_GETWRITEMOUNT() cannot be process on the vnode for the layer above. Thus creating hardlink fails. A complete fix is to change VOP_GETWRITEMOUNT() to create a shadowfile, but its not possible due to the fact that, locking status of vnode passed as argument to VOP_GETWRITEMOUNT() is not stable. In the current kernel code base, filesystems using vop_stdgetwritemount() simply aquire mount point vnode, thus using vnode for directory above seems to suffice and used for the current implementation. But this logic cannot be considered safe and may cause problems in the future. Also, when mounting a directory containing multiple mount points using unionfs, becomes evil. Thus, it is dangerous to mount directories containing multiple mount points, using the current implementation of unionfs. =-- Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: haro-at-kgt.co.jp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ANN] unionfs patchset-11 release
On Tue, Apr 25, 2006 at 09:19:06PM +0900, Daichi GOTO wrote: It is my pleasure and honor to announce the availability of the unionfs patchset-11. Patchset-11: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p11.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p11.diff Changes in unionfs-p11.diff - Changed a few implementations around the lock/unlock mechanism. Because of this, you can use both the unionfs and the nullfs together without LK_CANRECURSE. - Fixed a bug that sometimes does not unlock if it cannot create shadow file. I still get a panic immediately upon use: KDB: stack backtrace: vfs_badlock(cdef7540,ee22b9c4,c07a60e0,cdef7540,0) at vfs_badlock+0x76 assert_vop_locked(cdef7540,c0765a3d,220,cdef7540,d12ed380) at assert_vop_locked+0x60 VOP_OPEN_APV(c077acc0,ee22ba1c,d0456c28,0,c68a2510) at VOP_OPEN_APV+0x87 union_open(ee22ba74,c0765a3d,ee22bbfc,47ec,cdf1a690) at union_open+0xa2 VOP_OPEN_APV(c077b6a0,ee22ba74,c07a5f60,cdf1a690,1) at VOP_OPEN_APV+0x94 exec_check_permissions(ee22bba8,0,c073c75f,143,d1921000) at exec_check_permissions+0x107 kern_execve(c68a2510,ee22bc60,0,bfbfe910,bfbfea0c,e87b9000,e87b9000,e87b9038,e87b94e9,e87f9000,3fb17,4,39) at kern_execve+0x214 execve(c68a2510,ee22bd04,c,ee22bd38,3) at execve+0x52 syscall(3b,3b,3b,bfbfe90c,bfbfecc7) at syscall+0x163 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d493b, esp = 0xbfbfe37c, ebp = 0xbfbfe828 --- VOP_OPEN: 0xcdef7540 is not locked but should be db show lockedvnods Locked vnodes 0xd0456bd0: tag ufs, type VREG usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcf9c1960 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc68a2510 (pid 5593)#0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc04ff967 at union_lock+0xda #6 0xc071541a at VOP_LOCK_APV+0x76 #7 0xc05b793a at vn_lock+0x67 #8 0xc05ab84b at vget+0x77 #9 0xc04fab14 at union_nodeget+0x682 #10 0xc04fd98a at union_lookup+0x5e6 #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc05a1588 at lookup+0x343 #13 0xc05a21f3 at namei+0x330 #14 0xc0522983 at kern_execve+0x1e4 #15 0xc05236ee at execve+0x52 #16 0xc06fc295 at syscall+0x163 #17 0xc06e5fdf at Xint0x80_syscall+0x1f ino 2805716, on dev da0s1e 0xcdf1a690: tag unionfs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_TEXT) v_object 0xcf9544b0 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc68a2510 (pid 5593)#0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc04ff967 at union_lock+0xda #6 0xc071541a at VOP_LOCK_APV+0x76 #7 0xc05b793a at vn_lock+0x67 #8 0xc05ab84b at vget+0x77 #9 0xc04fab14 at union_nodeget+0x682 #10 0xc04fd98a at union_lookup+0x5e6 #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc05a1588 at lookup+0x343 #13 0xc05a21f3 at namei+0x330 #14 0xc0522983 at kern_execve+0x1e4 #15 0xc05236ee at execve+0x52 #16 0xc06fc295 at syscall+0x163 #17 0xc06e5fdf at Xint0x80_syscall+0x1f union_vp=0xcdf1a690, uppervp=0xd0456bd0, lowervp=0xcdef7540 union: upper 0xd0456bd0: tag ufs, type VREG usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcf9c1960 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc68a2510 (pid 5593)#0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc04ff967 at union_lock+0xda #6 0xc071541a at VOP_LOCK_APV+0x76 #7 0xc05b793a at vn_lock+0x67 #8 0xc05ab84b at vget+0x77 #9 0xc04fab14 at union_nodeget+0x682 #10 0xc04fd98a at union_lookup+0x5e6 #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc05a1588 at lookup+0x343 #13 0xc05a21f3 at namei+0x330 #14 0xc0522983 at kern_execve+0x1e4 #15 0xc05236ee at execve+0x52 #16 0xc06fc295 at syscall+0x163 #17 0xc06e5fdf at Xint0x80_syscall+0x1f ino 2805716, on dev da0s1e union: lower 0xcdef7540: tag null, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () v_object 0xcf9544b0 ref 0 pages 5 #0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc05b793a at vn_lock+0x67 #6 0xc05ab84b at vget+0x77 #7 0xc059c93c at cache_lookup+0xe7 #8 0xc059d28f at vfs_cache_lookup+0xad #9 0xc0712034 at VOP_LOOKUP_APV+0x76 #10 0xc04f50a1 at null_lookup+0x6c #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc04fd762 at union_lookup+0x3be #13 0xc0712034 at VOP_LOOKUP_APV+0x76 #14 0xc05a1588 at lookup+0x343 #15 0xc05a21f3 at namei+0x330 #16 0xc0522983 at kern_execve+0x1e4 #17 0xc05236ee at execve+0x52 vp=0xcdef7540,
Keyboard Boot Disable
Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? Regards /Cole ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard Boot Disable
On Tue, Apr 25, 2006 at 10:10:55PM +0200, Cole wrote: Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? What version of FreeBSD are you running? This hasn't been the case by default for ages. As a warning, PS2 keyboards are not electricaly designed to be hotplug so you may blow your machine up by doing this (says someone who does it all the time). -- Brooks pgp0CCTylEQf2.pgp Description: PGP signature
RE: Keyboard Boot Disable
Hi. I realised I forgot the version after I mailed. Im speaking about FreeBSD 4.11. Also by blowing the machine up, what exactly do you mean? You end up blowing the motherboard? Or the keyboard? Or specifically what? Regards /Cole -Original Message- From: Brooks Davis [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 10:13 PM To: Cole Cc: freebsd-hackers@freebsd.org Subject: Re: Keyboard Boot Disable On Tue, Apr 25, 2006 at 10:10:55PM +0200, Cole wrote: Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? What version of FreeBSD are you running? This hasn't been the case by default for ages. As a warning, PS2 keyboards are not electricaly designed to be hotplug so you may blow your machine up by doing this (says someone who does it all the time). -- Brooks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard Boot Disable
On Tuesday 25 April 2006 16:10, Cole wrote: Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? Just take out the 'flags 0x1' part from the 'device atkbd' line in your kernel config line. Alternatively, make sure you have this in /boot/loader.conf: userconfig_script_load=YES And then put these lines in /boot/kernel.conf: enable atkbd0 irq atkbd0 1 flags atkbd0 0 quit -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard Boot Disable
On Tue, Apr 25, 2006 at 10:22:01PM +0200, Cole wrote: I realised I forgot the version after I mailed. Im speaking about FreeBSD 4.11. Also by blowing the machine up, what exactly do you mean? You end up blowing the motherboard? Or the keyboard? Or specifically what? On 4.x you can remove the default flags from they atkbd entry and I think that will do it. See the atkbd(4) manpage for details. Hot plugging or unplugging they keyboard can damage the motherboard or keyboard. -- Brooks Regards /Cole -Original Message- From: Brooks Davis [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 10:13 PM To: Cole Cc: freebsd-hackers@freebsd.org Subject: Re: Keyboard Boot Disable On Tue, Apr 25, 2006 at 10:10:55PM +0200, Cole wrote: Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? What version of FreeBSD are you running? This hasn't been the case by default for ages. As a warning, PS2 keyboards are not electricaly designed to be hotplug so you may blow your machine up by doing this (says someone who does it all the time). -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpkoxW0H1b73.pgp Description: PGP signature
RE: Keyboard Boot Disable
Hi. Thanks to both you and John Baldwin for the reply. This really does help. Thanks for all the effort. Regards /Cole -Original Message- From: Brooks Davis [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:06 PM To: Cole Cc: 'Brooks Davis'; freebsd-hackers@freebsd.org Subject: Re: Keyboard Boot Disable On Tue, Apr 25, 2006 at 10:22:01PM +0200, Cole wrote: I realised I forgot the version after I mailed. Im speaking about FreeBSD 4.11. Also by blowing the machine up, what exactly do you mean? You end up blowing the motherboard? Or the keyboard? Or specifically what? On 4.x you can remove the default flags from they atkbd entry and I think that will do it. See the atkbd(4) manpage for details. Hot plugging or unplugging they keyboard can damage the motherboard or keyboard. -- Brooks Regards /Cole -Original Message- From: Brooks Davis [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 10:13 PM To: Cole Cc: freebsd-hackers@freebsd.org Subject: Re: Keyboard Boot Disable On Tue, Apr 25, 2006 at 10:10:55PM +0200, Cole wrote: Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? What version of FreeBSD are you running? This hasn't been the case by default for ages. As a warning, PS2 keyboards are not electricaly designed to be hotplug so you may blow your machine up by doing this (says someone who does it all the time). -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard Boot Disable
I worked with someone once that said they blew out the ps/2 port on the motherboard. As an alternative, maybe you could consider a kvm switch? Luke On Apr 25, 2006, at 4:22 PM, Cole wrote: Hi. I realised I forgot the version after I mailed. Im speaking about FreeBSD 4.11. Also by blowing the machine up, what exactly do you mean? You end up blowing the motherboard? Or the keyboard? Or specifically what? Regards /Cole -Original Message- From: Brooks Davis [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 10:13 PM To: Cole Cc: freebsd-hackers@freebsd.org Subject: Re: Keyboard Boot Disable On Tue, Apr 25, 2006 at 10:10:55PM +0200, Cole wrote: Hi. I have a large amount of servers, and the problem is, that when I need to plug a keyboard into them, the keyboard is disabled since they werent booted with a keyboard. I was wondering if anyone has some idea of how to disable the keyboard probe at boot and make it so that the OS thinks that the keyboard is present even if its not plugged in, so that a keyboard can be plugged in at any stage, and will function normally. Im speaking specifically for ps2 keyboards. Is this even possible, or are there architecture problems or something else relating to this that would make this impossible? If this is possible, could someone please point me in the correct direction as to which code I would need to look at to make this possible? What version of FreeBSD are you running? This hasn't been the case by default for ages. As a warning, PS2 keyboards are not electricaly designed to be hotplug so you may blow your machine up by doing this (says someone who does it all the time). -- Brooks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
