Re: cvsup broken on amd64?
2011/9/19 Alexander Zagrebin al...@visp.ru: I've tried this patch. Now csup hangs before handling fixups. So there is no message Applying fixups... at all. Wow. Hm. Where's the author when one needs them.. Adrian ___ 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: 9.0 beta2 the new bsdinstaller
on 18/09/2011 23:18 Kevin Oberman said the following: On Sun, Sep 18, 2011 at 2:55 AM, Thomas Mueller mueller6727@bellsouth.net wrote: Some more ideas on the new bsdinstaller cross my mind. Since the way the bsdinstaller would make partitions is unpredictable, at least to the uninitiated, and in all likelihood at variance with how much space the user wants to allocate, it might be better to offer a roadmap to help guide the user to allocating space for FreeBSD using gpart or Rod Smith's gdisk. Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). The 64KB freebsd-boot partition is to contain the GPT boot code which is used by UEFI BIOS in place of the old MBR used by legacy BIOS. You need to use gpart(8) to write the GPT boot code to that partition, but I don't know if bsdinstall does so. It might just write the PMBR that is used for booting with legacy BIOS. I'll admit that I have not checked. (See the gpart(8) man page for details on writing the pmbr and gptboot.) I assume bsdinstall writes both so that AMD64 machines with EFI and 32-bit systems will both work. This is very different from the old traditional slice/partition system. I don't think that we create a GPT boot partition that is going to be used by UEFI BIOS. We use specific freebsd-boot partition type, which, I am sure, is unknown to BIOSes. So, as you say, we install PMBR, which will be booted by BIOS, and which will then load the main boot code from the boot partition. -- 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: 9.0 beta2 the new bsdinstaller
On 09/19/11 02:52, Fbsd8 wrote: Kevin Oberman wrote: On Sun, Sep 18, 2011 at 2:55 AM, Thomas Mueller mueller6727@bellsouth.net wrote: Some more ideas on the new bsdinstaller cross my mind. Since the way the bsdinstaller would make partitions is unpredictable, at least to the uninitiated, and in all likelihood at variance with how much space the user wants to allocate, it might be better to offer a roadmap to help guide the user to allocating space for FreeBSD using gpart or Rod Smith's gdisk. Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). The 64KB freebsd-boot partition is to contain the GPT boot code which is used by UEFI BIOS in place of the old MBR used by legacy BIOS. You need to use gpart(8) to write the GPT boot code to that partition, but I don't know if bsdinstall does so. It might just write the PMBR that is used for booting with legacy BIOS. I'll admit that I have not checked. (See the gpart(8) man page for details on writing the pmbr and gptboot.) I assume bsdinstall writes both so that AMD64 machines with EFI and 32-bit systems will both work. This is very different from the old traditional slice/partition system. The above info is another example of the type of information that should be added to a help option on the dialog screen for the bsdinstall disk configuration function. I also think that the bsdinstaller should offer the user an option to select between using the old MBR configuration used by legacy BIOS that sysinstall uses and the new gpart configuration which bsdinstall offers now. You absolutely can do new MBR installs, as well as new straight bsdlabel installs (dangerously dedicated). You just have to use the partition editor instead of the autopartitioner, and then choose to use the appropriate partition type. -Nathan ___ 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: truss
On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG Could you please run ktrace with -i option? The behavior is like if MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG does not check this. ktrace -i for truss sleep 5 http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt -- Anton Yuzhaninov ___ 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: 9.0 beta2 the new bsdinstaller
On 18/09/2011 10:55, Thomas Mueller mueller6727@bellsouth.net wrote: Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). I seem to remember (perhaps incorrectly) there was a discussion about bumping the default to 128 kB or more for the freebsd-boot partition. Will 64 kB be enough for 9.x? -- 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: Very imprecise watchdogd(8) timeout
on 16/09/2011 23:59 Arnaud Lacombe said the following: in which case the current notifier-based architecture is broken. You may want to have a soft-watchdog triggering after 5s, and a fallback hardware watchdog triggering after 60s. So let's start with the real problem, FreeBSD watchdog infrastructure doesn't expose an API to do what you described above. I think that it would be a rather small part to change the representation of timeouts from current form to, say, value + unit encoding. -- 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: 9.0 beta2 the new bsdinstaller
Nathan Whitehorn wrote: On 09/19/11 02:52, Fbsd8 wrote: Kevin Oberman wrote: On Sun, Sep 18, 2011 at 2:55 AM, Thomas Mueller mueller6727@bellsouth.net wrote: Some more ideas on the new bsdinstaller cross my mind. Since the way the bsdinstaller would make partitions is unpredictable, at least to the uninitiated, and in all likelihood at variance with how much space the user wants to allocate, it might be better to offer a roadmap to help guide the user to allocating space for FreeBSD using gpart or Rod Smith's gdisk. Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). The 64KB freebsd-boot partition is to contain the GPT boot code which is used by UEFI BIOS in place of the old MBR used by legacy BIOS. You need to use gpart(8) to write the GPT boot code to that partition, but I don't know if bsdinstall does so. It might just write the PMBR that is used for booting with legacy BIOS. I'll admit that I have not checked. (See the gpart(8) man page for details on writing the pmbr and gptboot.) I assume bsdinstall writes both so that AMD64 machines with EFI and 32-bit systems will both work. This is very different from the old traditional slice/partition system. The above info is another example of the type of information that should be added to a help option on the dialog screen for the bsdinstall disk configuration function. I also think that the bsdinstaller should offer the user an option to select between using the old MBR configuration used by legacy BIOS that sysinstall uses and the new gpart configuration which bsdinstall offers now. You absolutely can do new MBR installs, as well as new straight bsdlabel installs (dangerously dedicated). You just have to use the partition editor instead of the autopartitioner, and then choose to use the appropriate partition type. -Nathan I think you missed the point here. What is being requested is the partitioning dialog from sysinstall to be included in bsdinstall. The bsdinstall partitioning dialog should inform users about the differences between older and newer PCs and offer options to auto-configure the H.D appropriately. Or better yet have bsdinstall check the hardwares bios to determine if the bios are UEFI aware and what methods can be used to partition. The key here is that bsdinstall should provide at least the same level of automation as sysinstall has on this subject. ___ 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: truss
On Mon, 19 Sep 2011 12:13:56 + (UTC) Anton Yuzhaninov wrote to Mikolaj Golub: AY On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG Could you please run ktrace with -i option? The behavior is like if MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG does not check this. AY ktrace -i for truss sleep 5 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after execve() and wait4() in parent (which was actually waiting for this stop) returned only after the child exit. No I idea why so far :-). -- Mikolaj Golub ___ 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: bsdgrep-20110912: -F/fgrep enbug
On 2011.09.19. 3:40, poyop...@puripuri.plala.or.jp wrote: Hi, I found another issue, this time in bsdgrep-20110912 in port. Thanks for using BSD grep and reporting bugs! I've checked and confirmed these issues. In my development branch I have already committed a partial fix. It will be fixed shortly in the development version and in ports and I'll also try to get it fixed in 9.0 before it is released. Gabor ___ 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: truss
On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote: AY ktrace -i for truss sleep 5 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt MG MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after MG execve() and wait4() in parent (which was actually waiting for this stop) MG returned only after the child exit. No I idea why so far :-). MG As I understand SIGTRAP used to stop child process after execve(), but this signal ignored: citrin:~ sleep 300 citrin:~ procstat -i 1991 | fgrep TRAP 1991 sleepTRAP -I- Under FreeBSD 8, where ptrace works for me, this signal is not ignored: x:~ sleep 300 x:~ procstat -i 78716 | fgrep TRAP 78716 sleepTRAP --- -- Anton Yuzhaninov ___ 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
Dtrace: type mismatch in sys/kern/kern_sig.c
In the file sys/kern/kern_sig.c defined DTrace probe proc:::signal-discard SDT_PROBE_DEFINE(proc, kernel, , signal_discard, signal-discard); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 0, struct thread *); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 1, struct proc *); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 2, int); Then latter this proble called as: SDT_PROBE(proc, kernel, , signal_discard, ps, td, sig, 0, 0 ); type for var ps is struct sigacts* =! struct thread * (bug?) type for var td is struct thread * =! struct proc * (bug?) type for var sig is int == int (ok) To match solaris DTrace probe shuild called as: SDT_PROBE(proc, kernel, , signal_discard, td, p, sig, 0, 0 ); -- Anton Yuzhaninov ___ 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: Crashes in world built w/ clang: FP registers?
On Mon, Sep 19, 2011 at 05:46:54PM +0200, Roman Divacky wrote: On Sun, Sep 18, 2011 at 11:05:55AM -0500, Jason Harmening wrote: Can you try building just tcsh ? I wonder if -O0 makes any difference... in either case, can you give me preprocessed (clang -E) source that exhibits this bug (check with objdump -d that the unaligned sse read is there) and show me how to reproduce that... I'll try that here. To be honest, I am not sure why others are not seeing this behaviour :( roman Building w/ -O0 eliminated the crash in csh at least. In that case, tw_collect() isn't even using the SSE registers. I've attached the objdump output for csh for both the -O2 and -O0 cases, along w/ the preprocessor output for tw.parse.c. it doesnt build for me.. with tons of errors like pes ~$ clang tw.parse.cpp In file included from ../../contrib/tcsh/tw.parse.c:1: In file included from ../../contrib/tcsh/tw.parse.c:36: In file included from ../../contrib/tcsh/sh.h:38: /usr/include/stddef.h:57:19: error: cannot combine with previous 'type-name' declaration specifier typedef __wchar_t wchar_t; ^ how did you get the preprocessed file? and/or how do you compile it? Nevermind... I managed to save the file as a .cpp file :) But I am not seeing any misaligned SSE reads/writes: pes ~$ clang -O2 -c tw.parse.c objdump -d tw.parse.o | grep movaps 23: 0f 29 85 60 ff ff ffmovaps %xmm0,0xff60(%rbp) 3f6: 0f 29 85 10 ff ff ffmovaps %xmm0,0xff10(%rbp) 6b6: 0f 29 85 f0 fe ff ffmovaps %xmm0,0xfef0(%rbp) 85b: 0f 29 45 c0 movaps %xmm0,0xffc0(%rbp) 867: 0f 29 45 a0 movaps %xmm0,0xffa0(%rbp) 873: 0f 29 45 80 movaps %xmm0,0xff80(%rbp) b37: 0f 29 85 d0 fe ff ffmovaps %xmm0,0xfed0(%rbp) e2c: 0f 29 85 c0 fe ff ffmovaps %xmm0,0xfec0(%rbp) e3e: 0f 29 85 a0 fe ff ffmovaps %xmm0,0xfea0(%rbp) e50: 0f 29 85 80 fe ff ffmovaps %xmm0,0xfe80(%rbp) 1a4b: 0f 29 45 c0 movaps %xmm0,0xffc0(%rbp) 21e3: 0f 29 45 d0 movaps %xmm0,0xffd0(%rbp) 2647: 0f 29 85 50 fe ff ffmovaps %xmm0,0xfe50(%rbp) 2659: 0f 29 85 30 fe ff ffmovaps %xmm0,0xfe30(%rbp) How exactly are you compiling it? roman ___ 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: truss
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop
after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG
AY
AY As I understand SIGTRAP used to stop child process after execve(), but
AY this signal ignored:
AY
AY citrin:~ sleep 300
AY citrin:~ procstat -i 1991 | fgrep TRAP
AY 1991 sleepTRAP -I-
AY
AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
AY x:~ sleep 300
AY x:~ procstat -i 78716 | fgrep TRAP
AY 78716 sleepTRAP ---
SIGTRAP is ignored by X window manager used by me, and this is inherited across
forks/execs up to the truss.
IMHO truss should restore default signal handler for SIGTRAP.
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
--
Anton Yuzhaninov
___
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: Crashes in world built w/ clang: FP registers?
On Sun, Sep 18, 2011 at 11:05:55AM -0500, Jason Harmening wrote: Can you try building just tcsh ? I wonder if -O0 makes any difference... in either case, can you give me preprocessed (clang -E) source that exhibits this bug (check with objdump -d that the unaligned sse read is there) and show me how to reproduce that... I'll try that here. To be honest, I am not sure why others are not seeing this behaviour :( roman Building w/ -O0 eliminated the crash in csh at least. In that case, tw_collect() isn't even using the SSE registers. I've attached the objdump output for csh for both the -O2 and -O0 cases, along w/ the preprocessor output for tw.parse.c. it doesnt build for me.. with tons of errors like pes ~$ clang tw.parse.cpp In file included from ../../contrib/tcsh/tw.parse.c:1: In file included from ../../contrib/tcsh/tw.parse.c:36: In file included from ../../contrib/tcsh/sh.h:38: /usr/include/stddef.h:57:19: error: cannot combine with previous 'type-name' declaration specifier typedef __wchar_t wchar_t; ^ how did you get the preprocessed file? and/or how do you compile it? roman ___ 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
USB Keyboard doesn't work
Hi.. in a new installation of freebsd 8.2 (amd64) if the machine doesn't have a PS2 port to use keyboard... and have only USB port its impossible to use an keyboard on mountroot prompt ___ 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: truss
On Mon, Sep 19, 2011 at 04:03:42PM +, Anton Yuzhaninov wrote:
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop
after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG
AY
AY As I understand SIGTRAP used to stop child process after execve(), but
AY this signal ignored:
AY
AY citrin:~ sleep 300
AY citrin:~ procstat -i 1991 | fgrep TRAP
AY 1991 sleepTRAP -I-
AY
AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
AY x:~ sleep 300
AY x:~ procstat -i 78716 | fgrep TRAP
AY 78716 sleepTRAP ---
SIGTRAP is ignored by X window manager used by me, and this is inherited
across
forks/execs up to the truss.
IMHO truss should restore default signal handler for SIGTRAP.
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
This is quite a hack. The proper fix should go in kernel, otherwise
we cannot debug programs that decided to ignore SIGTRAP. The reason
there is that tdsendsignal() does nothing for attempt to deliver ignored
signal, and kern_execve() simply tries to send a signal to self.
BTW, it seems we might also have similar issues for threads that masks
SIGTRAP, now because issignal() does nothing in that case too. But lets
handle it by small steps.
Could you, please, test the change below ? For me, I still can truss(1)
or debug with gdb after the change applied. Does truss work for you
with only this change, without resetting SIGTRAP handler in truss process ?
commit 2ae586c039a55399edc3b34cd40410e0d690a16c
Author: Konstantin Belousov kos...@pooma.home
Date: Tue Sep 20 00:25:07 2011 +0300
Do not deliver SIGTRAP on exec as the normal signal, use ptracestop()
on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal()
do not want to deliver, and debugger never get a notification of exec.
Found by: Anton Yuzhaninov cit...@citrin.ru
diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index fe01142..4545848 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -777,16 +777,6 @@ interpret:
KNOTE_LOCKED(p-p_klist, NOTE_EXEC);
p-p_flag = ~P_INEXEC;
- /*
-* If tracing the process, trap to the debugger so that
-* breakpoints can be set before the program executes. We
-* have to use tdsignal() to deliver the signal to the current
-* thread since any other threads in this process will exit if
-* execve() succeeds.
-*/
- if (p-p_flag P_TRACED)
- tdsignal(td, SIGTRAP);
-
/* clear fork but no exec flag, as we _are_ execing */
p-p_acflag = ~AFORK;
diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c
index cb0d929..bba4479 100644
--- a/sys/kern/subr_syscall.c
+++ b/sys/kern/subr_syscall.c
@@ -204,9 +204,17 @@ syscallret(struct thread *td, int error, struct
syscall_args *sa __unused)
* is not the case, this code will need to be revisited.
*/
STOPEVENT(p, S_SCX, sa-code);
- PTRACESTOP_SC(p, td, S_PT_SCX);
if (traced || (td-td_dbgflags (TDB_EXEC | TDB_FORK)) != 0) {
PROC_LOCK(p);
+ /*
+* If tracing the execed process, trap to the debugger
+* so that breakpoints can be set before the program
+* executes. If debugger requested tracing of syscall
+* returns, do it now too.
+*/
+ if (traced ((td-td_dbgflags TDB_EXEC) != 0 ||
+ (p-p_stops S_PT_SCX) != 0))
+ ptracestop(td, SIGTRAP);
td-td_dbgflags = ~(TDB_SCX | TDB_EXEC | TDB_FORK);
PROC_UNLOCK(p);
}
pgpF2yup3qKFJ.pgp
Description: PGP signature
Re: USB Keyboard doesn't work
On 20/09/2011, at 4:50, Alisson wrote: in a new installation of freebsd 8.2 (amd64) if the machine doesn't have a PS2 port to use keyboard... and have only USB port its impossible to use an keyboard on mountroot prompt Try typing this in the loader prompt.. set kern.cam.boot_delay=1 Or putting kern.cam.boot_delay=1 in /boot/loader.conf. Stolen from http://lists.freebsd.org/pipermail/freebsd-usb/2010-July/008847.html ___ 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 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: 9.0 bata2 keymap
Now I must point out that I tested hitting the cancel button in the
kbdmap command. It worked in that no keymap= statement was inserted into
/etc/rc.conf but it must also make some other changes some where else in
the system because if you do select an entry from the kbdmap database
and them remove the keymap= statement that was inserted into
/etc/rc.conf and then reboot the system, it will hang on reboot.
Another point of interest is when selecting cancel for the default
keyboard still results in the block of 9 keys above the arrow keys to
not function. Issuing the man cmd_name command does display the man
page, but the {Page up, Page down keys } don't work. Also when using the
ee edit command the {delete, Page up, Page down don't work. There may
be more system utility commands with the same flaw.
This may indicate that the default keyboard map in kbdmap command has
changed, is not the same as in previous releases or some thing else in
the 9.0 system has changed. In either case this needs research.
Joe
I continued to research this problem and found the cause.
The content of 9.0 /etc/ttys has changed, (IE; cons25 is now xtern).
I have some changes in ttys on 8.2 and I just copied that file over to
9.0 without looking at the content. The block of 9 keys above the arrow
keys now work correctly.
___
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: USB Keyboard doesn't work
On Monday 19 September 2011 20:20:18 Alisson wrote: if the machine doesn't have a PS2 port to use keyboard... and have only USB port its impossible to use an keyboard on mountroot prompt Hi Alisson, I dont know the complete ins and outs of this, but I think it has a lot to do with the BIOS on your machine and/or how it is configured (IE: PS2 emulation). I have a machine that used to work just fine during the boot-loader and mountroot part of booting, but after a BIOS upgrade, it would no longer work; only the PS2 keyboard was active until the machine had booted far enough to bring up the USB stack. Check your BIOS settings and see if any of them mention something about USB keyboards. Ta Peg ___ 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: 9.0 bata2 keymap
I continued to research this problem and found the cause. The content of 9.0 /etc/ttys has changed, (IE; cons25 is now xtern). I have some changes in ttys on 8.2 and I just copied that file over to 9.0 without looking at the content. The block of 9 keys above the arrow keys now work correctly. I saw the keyboard layout and there are many :(, I don't even know if I have a standard 101/105 US keyboard. When I press up arrow, I get an 8 on the screen :( I was going to ask on another thread/create a new thread, but I guess this one is the correct one to ask? Regards, Antonio ___ 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: How does one install kernel sources and base
But my question is as follows, How do I get kernel sources and base installed? You can download them via csup with a config file similar to this: *default host=cvsup5.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default compress delete use-rel-suffix src-all Save your config file (or so called supfile) someplace and run it as: # csup your.supfile csup will download the latest source tree for kernel and base OS. Also, see FreeBSD Handbook for more information on using csup (or the older, but functionally identical cvsup), and for many other questions regarding general FreeBSD installation and maintenance: http://www.freebsd.org/doc/handbook/cvsup.html m. -- Michal Varga, Stonehenge (Gmail account) Michal, Thank you very much for your detailed instruction. I was able to get all of the sources and built nvidia driver successfully :) However, when I run kldload nvidia, I get a mismatch with the running kernel and an incompatible ?. I cannot post exact error as the machine gives me no X :(, I checked to see if enabling hald and dbus at /etc/rc.conf would make a difference and they have not :(, I have also tried nouveau and it also does not work. No working X on FreeBSD 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, ... I will post in the thread I created on this issue. Regards, Antonio ___ 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: no X after installing xorg + xfce
I added this to /etc/rc.conf hald_enable=YES dbus_enable=YES but machine still gives no working X :( This seems like more of a question@ issue. I doubt that the above claim is at fault, given past experience. What does /var/log/Xorg.0.log say, and what does your xorg.conf contain? I would like to return this, but have no way of saving output :( I have updated via ports to latest tree available and have used csup to get kernel sources to install nvidia-driver, but kldload nvidia, returns a mismatch another type of error, I recompiled xorg-server and no hal was in configuration, but X does not work. with nv, nvidia(after compilation), and noveau no working X :( What can I do? I have two machines with nvidia chipsets one integrated in the motherboard and another nvidia Gforce card and amd64 8.2 works great. This is an integrated motherboard. As I am not an expert, I ask for advice/suggestions/comments to get this going. Regards, Antonio ___ 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: How does one install kernel sources and base
On Sep 19, 2011, at 5:22 PM, Antonio Olivares wrote: *default host=cvsup5.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default compress delete use-rel-suffix src-all Save your config file (or so called supfile) someplace and run it as: # csup your.supfile csup will download the latest source tree for kernel and base OS. Also, see FreeBSD Handbook for more information on using csup (or the older, but functionally identical cvsup), and for many other questions regarding general FreeBSD installation and maintenance: http://www.freebsd.org/doc/handbook/cvsup.html Michal, Thank you very much for your detailed instruction. I was able to get all of the sources and built nvidia driver successfully :) However, when I run kldload nvidia, I get a mismatch with the running kernel and an incompatible ?. I cannot post exact error as the machine gives me no X :(, I checked to see if enabling hald and dbus at /etc/rc.conf would make a difference and they have not :(, I have also tried nouveau and it also does not work. No working X on FreeBSD 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, ... I will post in the thread I created on this issue. A not very well documented hint.. $ grep PORTS_MODULES= /etc/src.conf PORTS_MODULES= emulators/virtualbox-ose-kmod x11/nvidia-driver You'll also need to boot with the new kernel. Be sure to read the complete handbook chapter on how to update your system from source if you plan to go that route. Once things go release you might be able to update your binaries via freebsd-update. If this seems really complicated and you want a simplified desktop experience, there's also PCBSD. HTH, -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: USB Keyboard doesn't work
On Sep 19, 2011, at 4:39 PM, Pegasus Mc Cleaft wrote: On Monday 19 September 2011 20:20:18 Alisson wrote: if the machine doesn't have a PS2 port to use keyboard... and have only USB port its impossible to use an keyboard on mountroot prompt Hi Alisson, I dont know the complete ins and outs of this, but I think it has a lot to do with the BIOS on your machine and/or how it is configured (IE: PS2 emulation). Many BIOS vendors label this as legacy keyboard emulation, etc. You might want to play with the plug-n-play settings as well (but I doubt that that would help). HTH, -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: How does one install kernel sources and base
However, when I run kldload nvidia, I get a mismatch with the running kernel and an incompatible ?. I cannot post exact error as the machine gives me no X :(, I checked to see if enabling hald and dbus at /etc/rc.conf would make a difference and they have not :(, I have also tried nouveau and it also does not work. No working X on FreeBSD 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, ... I will post in the thread I created on this issue. A not very well documented hint.. $ grep PORTS_MODULES= /etc/src.conf PORTS_MODULES= emulators/virtualbox-ose-kmod x11/nvidia-driver Garrett, I had installed from 9.0-amd64-BETA2-dvd1 iso, but the bsdinstall flew so fast and I could not use arrow keys to select the src for the kernel, I updated the whole system via ports using portmaster -a, and no matter what I try X does not work. You'll also need to boot with the new kernel. Be sure to read the complete handbook chapter on how to update your system from source if you plan to go that route. It takes a great while to build the system like this, but since it is a BETA, it might not be worth it and then to figure out that X does still not work. Might have to wipe disk clean and reinstall? Once things go release you might be able to update your binaries via freebsd-update. If this seems really complicated and you want a simplified desktop experience, there's also PCBSD. Nah, prefer native FreeBSD as PCBSD will make it too easy :( + I would like to help out in testing and learn more about FreeBSD. I have tested linux distros before, but they work differently than FreeBSD, and there is not as much fun*, things to try* as they are in FreeBSD beta2? HTH, -Garrett Regards, Antonio ___ 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: How does one install kernel sources and base
On Mon, 2011-09-19 at 19:22 -0500, Antonio Olivares wrote: Michal, Thank you very much for your detailed instruction. I was able to get all of the sources and built nvidia driver successfully :) However, when I run kldload nvidia, I get a mismatch with the running kernel and an incompatible ?. I cannot post exact error as the machine gives me no X :(, I checked to see if enabling hald and dbus at /etc/rc.conf would make a difference and they have not :(, I have also tried nouveau and it also does not work. No working X on FreeBSD 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, ... I will post in the thread I created on this issue. Regards, Antonio Some details about the incompatible ? error would be quite useful as without an actual (and exact) error message it's only guessing... But it is possible that your downloaded (latest -HEAD) sources are no longer compatible with your currently running OS, though there being like about a week difference, I find it somewhat unlikely (but always possible). If that's the case, you have two possible routes to take: You can either bring your system up to date corresponding to the latest sources; that is, rebuilding and installing new FreeBSD kernel and world. That should get rid of any incompatibilities you currently experience. It's a pretty straightforward process which in your case amounts to just about - # cd /usr/src # make buildworld installworld kernel - but note that the above mentioned IS NOT an officially supported procedure and you are first REQUIRED to read FreeBSD Handbook and understand the basics of building and updating FreeBSD. I just mention it to illustrate how simple the procedure generally is. But again, don't run it blindly. When unsure, always use the officially supported, while somewhat lenghtier, procedure described in FreeBSD Handbook. Now the other possible route that doesn't involve building and updating FreeBSD at all, is to download the sources that closely match your currently running system. As far as I know (and I wasn't able to find), there is no CVS tag for BETA2, so you can't pull the exact sources that way, but you should be able to get very close with: $ uname -a - and notice when the kernel was built, which was hopefully very close to the time when the sources were pulled from CVS (this is more or less only a guess, so someone involved in release engineering might be of more help with this issue, if there even is any). To do this, you just need to edit your supfile and include the specific date from when to pull the sources: That is, replacing the line: *default release=cvs tag=. With: *default release=cvs tag=. date=2011.09.??.??.??.?? (Just fill in the missing dd, hh, mm, ss values based on the date you already know from uname.) This modified supfile will let you pull sources that should be a very close - if not perfect - match to your current system. You can then rebuild your drivers (i.e. that non-working nvidia module) the regular way. By my humble estimate, that should be enough to fix your issue. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: USB Keyboard doesn't work
On 20/09/2011, at 10:05, Garrett Cooper wrote: On Sep 19, 2011, at 4:39 PM, Pegasus Mc Cleaft wrote: On Monday 19 September 2011 20:20:18 Alisson wrote: if the machine doesn't have a PS2 port to use keyboard... and have only USB port its impossible to use an keyboard on mountroot prompt Hi Alisson, I dont know the complete ins and outs of this, but I think it has a lot to do with the BIOS on your machine and/or how it is configured (IE: PS2 emulation). Many BIOS vendors label this as legacy keyboard emulation, etc. You might want to play with the plug-n-play settings as well (but I doubt that that would help). I think you would need legacy emulation for the keyboard to work in the loader. However that will have no effect at mountroot (and after) as the kernel has taken over by then. The kern.cam.boot_delay=1 work around helps by giving the USB stack some time to find devices before mountroot. Unfortunately I believe the USB stack is effectively frozen once the mountroot prompt appears hence the need for the work around. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: How does one install kernel sources and base
On Tue, 20 Sep 2011, Michal Varga wrote: On Mon, 2011-09-19 at 19:22 -0500, Antonio Olivares wrote: Michal, Thank you very much for your detailed instruction. I was able to get all of the sources and built nvidia driver successfully :) However, when I run kldload nvidia, I get a mismatch with the running kernel and an incompatible ?. I cannot post exact error as the machine gives me no X :(, I checked to see if enabling hald and dbus at /etc/rc.conf would make a difference and they have not :(, I have also tried nouveau and it also does not work. No working X on FreeBSD 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, ... I will post in the thread I created on this issue. Regards, Antonio Some details about the incompatible ? error would be quite useful as without an actual (and exact) error message it's only guessing... But it is possible that your downloaded (latest -HEAD) sources are no longer compatible with your currently running OS, though there being like about a week difference, I find it somewhat unlikely (but always possible). It is in fact quite likely, as a bunch of kernel functions corresponding to system calls have been renamed in the interim by kmacy, around r225617. I believe the quoted text below to be accurate, for the OPs choice of actions. -Ben Kaduk If that's the case, you have two possible routes to take: You can either bring your system up to date corresponding to the latest sources; that is, rebuilding and installing new FreeBSD kernel and world. That should get rid of any incompatibilities you currently experience. It's a pretty straightforward process which in your case amounts to just about - # cd /usr/src # make buildworld installworld kernel - but note that the above mentioned IS NOT an officially supported procedure and you are first REQUIRED to read FreeBSD Handbook and understand the basics of building and updating FreeBSD. I just mention it to illustrate how simple the procedure generally is. But again, don't run it blindly. When unsure, always use the officially supported, while somewhat lenghtier, procedure described in FreeBSD Handbook. Now the other possible route that doesn't involve building and updating FreeBSD at all, is to download the sources that closely match your currently running system. As far as I know (and I wasn't able to find), there is no CVS tag for BETA2, so you can't pull the exact sources that way, but you should be able to get very close with: $ uname -a - and notice when the kernel was built, which was hopefully very close to the time when the sources were pulled from CVS (this is more or less only a guess, so someone involved in release engineering might be of more help with this issue, if there even is any). To do this, you just need to edit your supfile and include the specific date from when to pull the sources: That is, replacing the line: *default release=cvs tag=. With: *default release=cvs tag=. date=2011.09.??.??.??.?? (Just fill in the missing dd, hh, mm, ss values based on the date you already know from uname.) This modified supfile will let you pull sources that should be a very close - if not perfect - match to your current system. You can then rebuild your drivers (i.e. that non-working nvidia module) the regular way. By my humble estimate, that should be enough to fix your issue. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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
ACPI battery problem and solution
Hello, I'm running 9.0-CURRENT on a MacbookPro 5,5. Following a recent update, I found that the acpi battery functionality had stopped working. I suspect, given the nature of it, that other people may have seen this problem as well. I did some work, and traced the problem to its source. The driver (in dev/acpica/acpi_cmbat.c) attempts to dispatch a call to acpi_cmbat_init_battery() via the AcpiOsExecute() mechanism. However, it seemed that the queue was filling up during kernel initialization, and the call was getting dropped on the floor. The cmbat driver reads part of the battery info (the bif structure) into its own structures at initialization, and then uses it, rather than querying the battery directly. Because AcpiOsExecute was dropping the initialization request on the floor, the bif information was left uninitialized, which caused the driver to mistakenly report the battery as not present when queried from sysctl/ioctl. I was able to workaround the problem by setting debug.acpi.max_tasks to a higher value, which restored functionality. Several possible solutions come to mind: 1) keep track of whether or not acpi_cmbat_init_battery (and possibly other initialization routines) have actually been successfully queued and run, to distinguish genuine failures, rather than failures resulting from a full queue 2) run acpi_cmbat_init_battery (and possibly other initialization routines) directly, rather than sending them through the queue. 3) something else But I'll leave the decision of what to do up to people with more knowledge of the acpi system. Hope this helps someone. signature.asc Description: OpenPGP digital signature
Re: ACPI battery problem and solution
Would you mind filing a PR? This kind of thing is important and best not to get lost. :) Adrian ___ 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: ACPI battery problem and solution
On 09/19/11 23:46, Adrian Chadd wrote: Would you mind filing a PR? This kind of thing is important and best not to get lost. :) Done. Identifier is kern/160838. signature.asc Description: OpenPGP digital signature
