Re: recommendations for laptop and desktop [SEC=UNCLASSIFIED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 0n Thu, Jul 14, 2011 at 04:08:48PM +0200, Julian H. Stacey wrote: Zoran Kolic wrote: Zoran's comments that http://laptop.bsdgroup.de/freebsd/ is 'obsolete' are a bit misplaced regarding older kit that some of us use by choice or necessity (eg my 2.5 Thinkpad T23s :) Sorry for the word chosen in this case. I use one even older lapper, HP nx9020, with real 4:3 screen, matte. I'm ready to write about it. The only problem is that it is not possible to find anymore. So, no use. Theres a difference between have / find / buy / receive a laptop ;-) So it's still nice to docu. older hardware if they supports BSD, because sometimes people get old laptops thrust upon them :-) Here take this thing, I'm not using, I've heard you say BSD is more efficient than MS, so maybe'll get some use out of it Then you get home with it look it up on the web ... :-) There is always iXsystems invincibook - at least it should just work http://www.ixsystems.com/ix/servers/home-and-office/invincibook-freebsd-laptop -Alex -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOHvqEAAoJEMv3KTBtKivP590H/ipNA4d7EBp+LdBBOby0qwWR F2k4ORP084IyXYkUCI/NG6LadrHggsdZ34pbOIM3ZkS25PgFCvxDo4pJuhTWoGR/ Bn6W1zsFXCNyAKiyB/YR0AtNymNKYYvhJPg7t1IIJbHWZepmSorfK560Z8Y01EfE epSPtGXxrvBZz2Ej/69AGnh3+LP3wx4dOC5JM+E9fCwy+56lOkpcjeyrKEWtPasp ADr56ofRLQbUIL8q1ehOTs6Cw7ZBhO/4Bk2YN5zZV7rAz2afv7z1qfSByWHp5KD5 fSLQKZHrtJ/hFcrbfe8FKLqZWZ+wklV7FhjVmaq+hOimp8BZg4YgY/gmKM2R1rE= =kW53 -END PGP SIGNATURE- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: www/chromium ignores proxy settings [SEC=UNCLASSIFIED]
0n Mon, Nov 22, 2010 at 02:19:32PM +, Tom Evans wrote: On Mon, Nov 22, 2010 at 2:00 PM, Alexander Logvinov a...@logvinov.com wrote: ??Use ??chrome --proxy-server=http://proxy:3128/; :) That didn't work either, it would not even make any connections then. With '--proxy-server=proxy:3128' though, it works correctly! It would still be nice to be able to set these options in the right place in the gui, and have them work :) Try: --proxy-pac-url=http://proxy-server:port; Work for me. -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
0n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote: I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). patches apply cleanly but buildkernel fails: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /usr/src/sys/kern/kern_et.c: No such file or directory cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/MARGS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. On stable 7.2 the same hardware works as expected: # ping -s 1500 192.168.64.99 PING 192.168.64.99 (192.168.64.99): 1500 data bytes 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms Here is the dump on em interface 15:06:31.452043 IP 192.168.66.65 *: ICMP echo request, id 28729, seq 5, length 1480 15:06:31.452047 IP 192.168.66.65 : icmp 15:06:31.452069 IP 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 15:06:31.452071 IP *** 192.168.66.65: icmp Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable #pciconf -lv e...@pci0:3:4:0: class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet # ping -s 1472 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1472 data bytes 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ^C # ping -s 1473 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1473 data bytes ^C --- 192.168.64.200 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Gigabit network connection (82567LM-3 )' class = network subclass = ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]
0n Mon, Oct 18, 2010 at 04:33:34AM -0700, Jeremy Chadwick wrote: On Sun, Oct 17, 2010 at 03:10:06PM -0700, Sean Bruno wrote: We've successfully installed RHEL 5u4 on it, I'll fire that up and post the boot output shortly. Sean Perhaps this is something as simple as a hardware failure? HP DL980 looks sick, but I'm not sure. Here's the hardware logs, from the iLO on the box as screen scraping on the console is pointless as it's garbled too badly. Bad CPU, Bad Ram or other? http://people.freebsd.org/~sbruno/dl980_Machcheck_exceptions.png Hard to say -- the MCE will need to be decoded. I'm working on a program which can do this, though I know John Baldwin already has one which should work. Will it work something like http://freshmeat.net/projects/mcelog/ ? -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Fri, Oct 15, 2010 at 04:27:51PM +0200, Ivan Voras wrote: On 10/15/10 03:43, Wilkinson, Alex wrote: 0n Thu, Oct 14, 2010 at 04:51:10PM +0800, Wilkinson, Alex wrote: 0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: On 14.10.2010 09:26, Wilkinson, Alex wrote: I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: #sshfs usern...@hostname:/home/username local_mountpoint/ This mounts the remote filesystem fine. However, when i edit and save a file in say vi on the remote sshfs i get the following panic everytime: Try this out http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? Committed! How stable is fuse sshfs lately? It looks like every time in the past I tried it I soon ended up panicking the system. since this patch it has been very stable so far! -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: On 14.10.2010 09:26, Wilkinson, Alex wrote: I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: #sshfs usern...@hostname:/home/username local_mountpoint/ This mounts the remote filesystem fine. However, when i edit and save a file in say vi on the remote sshfs i get the following panic everytime: Try this out http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Thu, Oct 14, 2010 at 04:51:10PM +0800, Wilkinson, Alex wrote: 0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: On 14.10.2010 09:26, Wilkinson, Alex wrote: I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: #sshfs usern...@hostname:/home/username local_mountpoint/ This mounts the remote filesystem fine. However, when i edit and save a file in say vi on the remote sshfs i get the following panic everytime: Try this out http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? Committed! |--+--+--| | [ 12:44 beat ] Original commit message # | | | | | | | | ports/sysutils/fusefs-kmod/Makefile 1.31 diff | | | | ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_main.c 1.1 | | | | | | | | - Fix panic on FreeBSD 8.x and newer | | | | - Bump PORTREVISION | | | | | | | | PR: ports/149674 | | | | Submitted by: Dmitrij Tejblum dt AT yandex.ru | | | | Approved by:Anish Mistry amistry AT am-productions.biz (maintainer) | | | |--+--+--| -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
Hi all, I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: #sshfs usern...@hostname:/home/username local_mountpoint/ This mounts the remote filesystem fine. However, when i edit and save a file in say vi on the remote sshfs i get the following panic everytime: FreeBSD/amd64 (hostname.com) (ttyu0) login: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff80e9d1d9d0 frame pointer = 0x28:0xff80e9d1db50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1749 (vim) trap number = 12 panic: page fault cpuid = 2 Uptime: 17m11s Physical memory: 8096 MB Dumping 1591 MB: It then seems to hang and not actually do a dump and i need to physically reset the box. If there is anything i can do to further assist in debugging please let me know. -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
PANIC: upon disconnecting UMASS device ...
Hi all,
Without a doubt I can reproduce this panic every single time.
1. Insert UMASS USB Stick
2. mount as msdos
3. umount USB stick
4. remove USB stick
4. some time laster [hours/days] *panic*: panic: vinvalbuf: dirty bufs
OS-Version: FreeBSD 5.4-STABLE #0: Thu Jul 14 12:32:30 CST 2005
[/var/log/messages before panic'd. Interestingly it takes
a few hours or days before the panic actually occurs].
Sep 9 17:03:11 hostname kernel: umass0: at uhub1 port 1 (addr 2)
disconnected
Sep 9 17:03:11 hostname kernel: (da0:umass-sim0:0:0:0): lost device
Sep 9 17:03:11 hostname kernel: (da0:umass-sim0:0:0:0): removing device
entry
Sep 9 17:03:11 hostname kernel: umass0: detached
Sep 12 08:15:21 hostname kernel: panic: vinvalbuf: dirty bufs
Sep 12 08:15:21 hostname kernel: KDB: enter: panic
Sep 12 08:15:21 hostname kernel: Dumping 767 MB
backrace:
(kgdb) bt
#0 doadump () at pcpu.h:160
#1 0xc0469db5 in db_fncall (dummy1=0, dummy2=0, dummy3=7919,
dummy4=0xde1619f4 \200\237\226À)
at /usr/src/sys/ddb/db_command.c:531
#2 0xc0469b64 in db_command (last_cmdp=0xc0969684, cmd_table=0x0,
aux_cmd_tablep=0xc08ea080, aux_cmd_tablep_end=0xc08ea09c)
at /usr/src/sys/ddb/db_command.c:349
#3 0xc0469c55 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#4 0xc046bb0d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#5 0xc0686dd3 in kdb_trap (type=0, code=0, tf=0xde161b40) at
/usr/src/sys/kern/subr_kdb.c:470
#6 0xc0860273 in trap (frame=
{tf_fs = -1064566760, tf_es = 16, tf_ds = -568983536, tf_edi = 1,
tf_esi = -1064505670, tf_ebp = -568976504, tf_isp = -568976532, tf_ebx =
-568976448, tf_edx = 0, tf_ecx = -1056878592, tf_eax = 18, tf_trapno = 3,
tf_err = 0, tf_eip = -1066898615, tf_cs = 8, tf_eflags = 646, tf_esp =
-1064519392, tf_ss = -1064525103}) at /usr/src/sys/i386/i386/trap.c:584
#7 0xc084dfaa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#8 0xc08c0018 in ?? ()
#9 0x0010 in ?? ()
#10 0xde160010 in ?? ()
#11 0x0001 in ?? ()
#12 0xc08ceeba in ?? ()
#13 0xde161b88 in ?? ()
#14 0xde161b6c in ?? ()
#15 0xde161bc0 in ?? ()
#16 0x in ?? ()
#17 0xc1015000 in ?? ()
#18 0x0012 in ?? ()
#19 0x0003 in ?? ()
#20 0x in ?? ()
#21 0xc0686b49 in kdb_enter (msg=0x0) at cpufunc.h:56
#22 0xc066c309 in panic (fmt=0xc08ceeba vinvalbuf: dirty bufs) at
/usr/src/sys/kern/kern_shutdown.c:550
#23 0xc06cbbfe in vinvalbuf (vp=0xc4a2d318, flags=1, cred=0x0, td=0x0,
slpflag=0, slptimeo=0)
at /usr/src/sys/kern/vfs_subr.c:972
#24 0xc06cf4b1 in vclean (vp=0xc4a2d318, flags=8, td=0xc1f0f480) at
/usr/src/sys/kern/vfs_subr.c:2478
#25 0xc06cfcb6 in vgonel (vp=0xc4a2d318, td=0x0) at
/usr/src/sys/kern/vfs_subr.c:2697
#26 0xc06ca94f in vlrureclaim (mp=0xc2107000) at pcpu.h:157
#27 0xc06cac7b in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:598
#28 0xc065325e in fork_exit (callout=0xc06caa29 vnlru_proc, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:791
#29 0xc084e00c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:209
(kgdb)
USB Code in kernel:
# USB support
device uhci# UHCI PCI-USB interface
device ohci# OHCI PCI-USB interface
device usb # USB Bus (required)
USB Controllers:
uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xa400-0xa41f
irq 19 at device 31.2 on pci0
usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xa000-0xa01f
irq 23 at device 31.4 on pci0
usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1
usb1: USB revision 1.0
Offending USB UMASS Stick:
Sep 9 15:46:46 hostname kernel: umass0: USB Flash Disk, rev 2.00/2.00,
addr 2
Sep 9 15:46:47 hostname kernel: da0 at umass-sim0 bus 0 target 0 lun 0
Sep 9 15:46:47 hostname kernel: da0: JetFlash TS1GJF2B 2.00 Removable
Direct Access SCSI-2 device
Sep 9 15:46:47 hostname kernel: da0: 1.000MB/s transfers
Sep 9 15:46:47 hostname kernel: da0: 1000MB (2048000 512 byte sectors: 64H
32S/T 1000C)
- aW
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Solved] Re: sshd stops accepting connections
0n Wed, Jan 12, 2005 at 06:59:10AM +1030, Simon L. Nielsen wrote:
On 2004.11.12 21:12:12 +0100, Simon L. Nielsen wrote:
Today I suddenly couldn't log in via ssh to a server I upgraded to
FreeBSD 5.3-RELEASE 4 days ago. When I tried connect to port 22 using
telnet(1) the following just happend:
[EMAIL PROTECTED]:~] telnet 192.168.3.2 22
Trying 192.168.3.2...
Connected to jet.nitro.dk.
Escape character is '^]'.
Connection closed by foreign host.
[...]
For the archives and anybody who may be interested...
There is some kind of bug in OpenSSH 3.8.1p1's sshd (the one shipped
with 5.3), possibly related to PAM and Privilege Separation. The fix
for me was simply to install OpenSSH 3.9 from ports, and I haven't had
the problem since.
3.9 ?
I have an updated ports collection and
# grep -i portv /usr/ports/security/openssh/Makefile
PORTVERSION=3.6.1
DISTNAME= openssh-${PORTVERSION}
PATCHFILES= openbsd28_${PORTVERSION}.patch
- aW
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ patch for if_vlan.c
0n Wed, Jan 05, 2005 at 12:51:56PM -0800, Brooks Davis wrote: FYI, spl*() funtions are all no-ops now. We just have them around to remind us that we need to lock certain functions and to document what was protected before. What is meant by no-ops ? - aW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck: broken file system with background check remains broken after bootup
0n Tue, Jan 04, 2005 at 02:01:22PM +0100, Oliver Fromme wrote: By the way, you can map a key combination (Ctrl-Alt-Del or something else) to the »halt« or »power-down« functions, using kbdcontrol, so it's very easy and intuitive to shut down the machine properly. See the kbdmap(5) manpage for details. This inspires me to ask this question: Is it possible to set up FreeBSD to do a clean shutdown upon a pressing the power button ? i.e. in the same fashion as Solaris does out of the box. Is this an ATX feature or a kernel feature in the PC world ? - aW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck: broken file system with background check remains broken after bootup
0n Tue, Jan 04, 2005 at 09:50:10PM -0600, Craig Boston wrote: Yes, in FreeBSD 5.3 if ACPI is enabled and working properly, pressing the power button will initiate a graceful shutdown (similar to shutdown -p). This feature is enabled by default if it is available, so you don't have to do anything special to get it. How can I confirm that ACPI has been setup to do this ? # acpidump -d | grep ??? - aW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck: broken file system with background check remains broken after bootup
0n Tue, Jan 04, 2005 at 10:17:47PM -0600, Craig Boston wrote: On Tuesday 04 January 2005 9:57 pm, Wilkinson, Alex wrote: How can I confirm that ACPI has been setup to do this ? Hmm, well, the easiest thing to check is to run sysctl hw.acpi.power_button_state and see if that sysctl exists and if so, what it's set to (mine is S5, which IIRC is complete power-off). Also, check dmesg and see if you see a line similar to acpi_button0: Power Button on acpi0 If both of those show up, chances are that your ASL has a power button entry and it should do the right thing. Other than that, you could always wait until the system is idle and just try hitting the button to see what happens ;) Cool, thanks: #sysctl hw.acpi.power_button_state hw.acpi.power_button_state: S5 #grep acpi_button /var/run/dmesg.boot acpi_button0: Power Button on acpi0 - aW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to remote update 4.10 - 5.3?
0n Thu, Dec 30, 2004 at 08:36:56PM +0300, Igor Pokrovsky wrote: On Wed, Dec 29, 2004 at 04:38:23PM -0500, Paul Mather wrote: Palle Girgensohn wrote: I've tried the UPDATING instructions, both locally and remotely (the latter failed ;-). But really, everything has to be reinstalled, ports and the lot, so a new install is probably the best way... That's not so bad. A reinstall means you can newfs your partitions as UFS2 filesystems, which wouldn't be the case if you upgraded 4.10 in-place. Are there any other advantages of UFS2 over UFS except maximum disk size? http://lists.freebsd.org/pipermail/freebsd-current/2003-April/001444.html - aW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need source to TCP/IP 'connect()'
0n Mon, Nov 29, 2004 at 09:35:42PM -0500, Ken Smith wrote: When 'fishing' for stuff in the kernel source code I find the tags files kind of useful. In a kernel build directory (e.g. I usually use src/sys/i386/compile/GENERIC on a 5.X machine, after config-ing GENERIC) after doing a 'make depend' you can do 'make tags'. It will usually fail once it starts to process the modules because it can't find 'gtags' but by then it's already built what is most useful. Once the tags file is built in the kernel build directory you can do something like: vi -t connect and it will start up vi with the cursor at the beginning of that function. It's not perfect (sometimes it can't find a function) but for the most part it works OK. In this case it found connect() in /usr/src/sys/kern/uipc_syscalls.c (I was using a RELENG_5 source tree). Ken, This looks useful, however, even after a buildkernel all I have is a CVS dir in /usr/src/sys/i386/compile/. Did u mean /usr/obj/usr/src/sys/GENERIC ? When u say config-ing, do u mean running config(8) manually ? -aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious networking (em) performance (ggate and NFS) problem
ping only tests latency *not* throughput. So it is not really a good test. - aW 0n Wed, Nov 17, 2004 at 07:01:24PM -0500, Chuck Swiger wrote: Emanuel Strobl wrote: [ ... ] Tests were done with two Intel GigaBit Ethernet cards (82547EI, 32bit PCI Desktop adapter MT) connected directly without a switch/hub what kind of bandwidth you max out using that. Or use ping with -i -s set to reasonable values depending on whether you're using jumbo frames or not. If the problem is your connection is dropping a few packets, this will show up better here. Using ping -f is also a pretty good troubleshooter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA driver crashing the system
From: /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113/doc/README __ (sec-05) CHOOSING THE AGP GART DRIVER __ Similar to the NVIDIA Linux Driver Set, the user can decide if the NVIDIA driver should use its internal AGP GART driver or if it should rely on an OS provided AGP GART driver with the NvAGP XFree86 config file option: - Option NvAGP 0 Disable AGP - Option NvAGP 1 Use NVIDIA's AGP GART Driver - Option NvAGP 2 Use the OS AGP GART driver (agp.ko) - Option NvAGP 3 Attempt 2, fall back to 1 Unlike Linux, however, this option is not the only controlling factor at this point; for architectural reasons, the nvidia.ko kernel module must be built with exclusive support for NVIDIA's AGP GART driver or with support for FreeBSD's driver and NVIDIA's driver. By default, nvidia.ko is built with support for NVIDIA's internal driver, only; this can be changed (see nv-freebsd.h for details). Please note that if you built nvidia.ko with support for FreeBSD's driver it will not load unless agp.ko is loaded. agp.ko is special in that you can not load it after the system boot is complete, you need to append the following line to /boot/loader.conf to make sure it is pre-loaded: # -- load FreeBSD AGP GART driver -- # agp_load=YES Also note that if agp.ko is loaded, it could conflict with NVIDIA's AGP GART driver (NvAGP), resulting in stability problems; for this reason, the NVIDIA driver will abort NvAGP initialization when it detects agp.ko. Note that current FreeBSD releases are shipped with agp.ko built into the kernel, which will need to be rebuilt without 'device agp'. Very recent -CURRENT kernels allow disabling agp.ko via device hints; if you're using such a kernel, adding the following to /boot/device.hints is sufficient: hint.agp.0.disabled=1 0n Tue, Nov 09, 2004 at 01:08:14AM -0600, Nicolás de Bari Embriz García Rojas wrote: I am trying to use the nvidia driver from the ports on FreeBSD 5.3-STABLE but every time i startup X the system crash My system: Laptop: Dell latitud D800 video card: GeForce FX Go5200 I attached a console to the laptop and i got this: --- NVRM: detected agp.ko, aborting NVIDIA AGP setup! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA driver crashing the system
0n Tue, Nov 09, 2004 at 09:37:37PM -0600, Nicolás de Bari Embriz García Rojas wrote: Doing all this described on (sec-05) dont work I have allready compile the kernel with out the device agp, tried Option NvAGP 0,1,2,3 and still having the same results, kernel still crashing. any more ideas? Not from me. However, try posting to nvidia forums: http://www.nvnews.net/vbulletin/forumdisplay.php?s=forumid=14 - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: preemption stable under 5.3?
For the benefit of those that are not aware. Can someone please explain what is meant by 'kernel preemption' and the benefits of it. Thanks - aW 0n Mon, Nov 08, 2004 at 06:29:23PM +, Robert Watson wrote: On Mon, 8 Nov 2004, Mipam wrote: Thanks for your reply, okay, then i'd like to enable preemption. I noticed it's not in the GENERIC kernel config file. So: options PREEMPTION would suffice to enable it i guess? Any experience with preemption. noticable changes? So the problem: PREEMPTION triggers frequent hangs is resolved? Btw, is RELENG_5 also stable or only for early adopters? I really would like to see ule working stable in combination with preemption, but in 5.3 it won't happen. Maybe ule will be enabled later in the 5 series? There was a series of bugs in the scheduler which got tickled by preemption; I'm unclear as to whether they were all resolved before 5.3 or whether they require fixes in HEAD that haven't yet been merged. It may well be safe, but I make no promises. Hopefully we can trick Julian or John into responding to this thread. :-) Having it off by default on 5.3 is certainly the more conservative (and reasonable) position, but if it helps your environment and appears stable, there should be no reason not to turn it on. It should substantially improve latency in interrupt processing as well as packet processing. Is Fine-grained network stack locking without Giant imported in 5.3 or is a giant lock networking stack still in 5.3? Bye, Giant-free networking is enabled by default in most configurations; there are some chunks of the network stack that aren't fully MPSAFE, and typically the kernel will automatically re-cover the network stack with Giant if one of these is compiled in. Examples are KAME IPSEC (not FAST_IPSEC) and NETIPX. We hope that locking for these subsystems will come in the near future. The upshot is that you should see nicely improved scalability in socket I/O on multiple processors at a time -- threads or processes can now receive input from socket buffers without touching the Giant lock, and can often send under similar circumstances, so if you're running large applications with lots of socket I/O, there should be much less contention. You can increase parallelism in the network stack, especially for interrupt-driven input from multiple interfaces, by setting net.isr.enable=1. However, there is at least one known bug that has been corrected in HEAD but not yet RELENG_5, wherein recv() on UDP sockets can return the incorrect address when UDP input is ocurring from more than one thread (without net.isr.enable, UDP input occurs only from the netisr, so it doesn't occur -- the default). I will be merging the fix to that to 5-STABLE after it's had another couple of weeks to settle in HEAD. In the next couple of weeks I'll also be merging a number of performance improvements for the network stack that settled into the tree after 5.x went to the RC series. So you (and others, ideally) should see network stack performance improve quite a bit over the next month or two if tracking 5-STABLE. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
