Re: Patch for quota deadlock
On Tue, Feb 28, 2006 at 08:40:37AM +0100, Oliver Brandmueller wrote: > Anyway, I'll discuss with my colleagues and we'll see if we want to take > the risk. Thanks, it would be a big help if you're willing to try. Kris pgpBG7ao7EXg0.pgp Description: PGP signature
Re: Patch for quota deadlock
Hi Kris. On Tue, Feb 28, 2006 at 12:23:28AM -0500, Kris Kennaway wrote: > On Tue, Feb 21, 2006 at 02:56:01PM -0500, Kris Kennaway wrote: > > Jeff has been too busy to send this patch himself, but it fixed the > > quota deadlock that I was able to provoke on my machine. Does it also > > solve the issue for others? > > I've seen 0 feedback about this so far. Since a number of people have > reported that the quota deadlock is the only thing keeping them from > upgrading from 5.x to 6.x, I expected a more enthusiastic testing > response than this :-) > > Please, those of you who have reported this problem, test the patch > and see if it works for you. If there are further problems, we can't > fix them in time for 6.1 unless we hear about it in the next week or > so. I'm a little ambivalent about it. The only machine where I could actually observe the behaviour (once a week) is our main prod NFS server. On the backup server there are abviously too few accesses to trigger the hang. So on one hand I se the necessity to test this, because I need quotas again on the server, on the other hand this means a 10 min downtime for installing a new kernel and the risk of 30 min downtime if it did not help. And I can only say this after a week or so. Anyway, I'll discuss with my colleagues and we'll see if we want to take the risk. Anyway, I remember people here, who talked about scenarios where they could trigger the panic with a simple find or something in only two hours. Hello, where are you? :-) - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | pgptFuKbtCuQd.pgp Description: PGP signature
Re: FreeBSD 6.0 on ASUS A8N-SLI motherboard
> Are there any issues running FreeBSD 6.0-STABLE (i386 or amd64 version) > on machine with ASUS A8N-SLI motherboard? It has NVIDIA RAID option in > BIOS and the system has 4x250GB SATA disks. I would like to use its RAID > feature if possible, otherwise I'll try gmirror. > Please let me know if somebody has experience about it. I am running amd64 fbsd-6.0-beta1 on A8N-SLI Deluxe. Nvidia mirroring seems to work well enough but I haven't stressed it much. I am running stock generic kernel with no problems related to the motherboard. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.0 on ASUS A8N-SLI motherboard
Hi, Are there any issues running FreeBSD 6.0-STABLE (i386 or amd64 version) on machine with ASUS A8N-SLI motherboard? It has NVIDIA RAID option in BIOS and the system has 4x250GB SATA disks. I would like to use its RAID feature if possible, otherwise I'll try gmirror. Please let me know if somebody has experience about it. thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (try) core dumps
On Feb 28, 2006, at 12:38 , Tommi Lätti wrote: Kris Kennaway wrote: Probably part of a port build..the configure scripts sometimes deliberately induce core dumps to test various things. i.e. nothing to worry about, if so. Hmm, thanks. There was actually perl getting updated at that point. Heh. Yes, while autoconf uses "conftest" for its test executables, Metaconfig (which I think only perl uses at this point) uses "try". -- brandon s. allbery [linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (try) core dumps
Kris Kennaway wrote: Probably part of a port build..the configure scripts sometimes deliberately induce core dumps to test various things. i.e. nothing to worry about, if so. Hmm, thanks. There was actually perl getting updated at that point. -- br, Tommi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (try) core dumps
On Tue, Feb 28, 2006 at 02:21:37PM +0900, Tommi L?tti wrote: > I just noticed this in my system logs: > > Feb 23 07:14:19 laa kernel: pid 71141 (try), uid 0: exited on signal 10 > (core dumped) > > Now, I have a very busy box here, but I cannot really tell to which > software the 'try' belongs to, and since it's running as uid 0, this > raises some alarms on my end. > > I also cannot find the core file... Probably part of a port build..the configure scripts sometimes deliberately induce core dumps to test various things. i.e. nothing to worry about, if so. Kris pgpT7jBymnRMJ.pgp Description: PGP signature
Re: Patch for quota deadlock
On Tue, Feb 21, 2006 at 02:56:01PM -0500, Kris Kennaway wrote:
> Jeff has been too busy to send this patch himself, but it fixed the
> quota deadlock that I was able to provoke on my machine. Does it also
> solve the issue for others?
I've seen 0 feedback about this so far. Since a number of people have
reported that the quota deadlock is the only thing keeping them from
upgrading from 5.x to 6.x, I expected a more enthusiastic testing
response than this :-)
Please, those of you who have reported this problem, test the patch
and see if it works for you. If there are further problems, we can't
fix them in time for 6.1 unless we hear about it in the next week or
so.
Kris
> - Forwarded message from Jeff Roberson <[EMAIL PROTECTED]> -
>
> X-Original-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> X-Original-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Date: Wed, 15 Feb 2006 17:46:31 -0800 (PST)
> From: Jeff Roberson <[EMAIL PROTECTED]>
> X-X-Sender: [EMAIL PROTECTED]
> To: Kris Kennaway <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Quota deadlock
> In-Reply-To: <[EMAIL PROTECTED]>
> X-Scanned-By: MIMEDefang 2.52 on 216.240.101.25
> X-UIDL: L0D!!!H0!!'W+"!=h9"!
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.0.1
>
> Please try this patch. LK_NOWAIT is causing qsync() to spin forever.
>
> Index: ufs_quota.c
> ===
> RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_quota.c,v
> retrieving revision 1.79
> diff -u -r1.79 ufs_quota.c
> --- ufs_quota.c 12 Feb 2006 13:20:06 - 1.79
> +++ ufs_quota.c 16 Feb 2006 01:45:56 -
> @@ -750,7 +750,7 @@
> MNT_ILOCK(mp);
> continue;
> }
> - error = vget(vp, LK_EXCLUSIVE | LK_NOWAIT | LK_INTERLOCK,
> td);
> + error = vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, td);
> if (error) {
> MNT_ILOCK(mp);
> if (error == ENOENT) {
>
>
> On Wed, 15 Feb 2006, Kris Kennaway wrote:
>
> >Quotas are enabled on this machine:
> >
> >db> show lockedvnods
> >Locked vnodes
> >
> >0xc6be4a80: tag ufs, type VREG
> > usecount 0, writecount 0, refcount 3 mountedhere 0
> > flags ()
> > v_object 0xc6bf4d98 ref 0 pages 2
> >lock type ufs: EXCL (count 1) by thread 0xcb814000 (pid 2031)#0
> >0xc0504d12 at lockmgr+0x55a
> >#1 0xc056f19b at vop_stdlock+0x32
> >#2 0xc06cffde at VOP_LOCK_APV+0xa6
> >#3 0xc063d775 at ffs_lock+0x19
> >#4 0xc06cffde at VOP_LOCK_APV+0xa6
> >#5 0xc0587b58 at vn_lock+0xd3
> >#6 0xc0586d5e at vn_close+0x7c
> >#7 0xc0587cd1 at vn_closefile+0xf0
> >#8 0xc04efc78 at fdrop_locked+0xb9
> >#9 0xc04efbb9 at fdrop+0x3c
> >#10 0xc04ee0ac at closef+0x428
> >#11 0xc04eaf7c at close+0x245
> >#12 0xc06b7359 at syscall+0x2e9
> >#13 0xc06a140f at Xint0x80_syscall+0x1f
> >
> > ino 23557, on dev da0s1a
> >
> >0xc7610540: tag ufs, type VDIR
> > usecount 1, writecount 0, refcount 4 mountedhere 0
> > flags ()
> > v_object 0xc9fb6078 ref 0 pages 1
> >lock type ufs: EXCL (count 1) by thread 0xcb8b2d00 (pid 2001)#0
> >0xc0504d12 at lockmgr+0x55a
> >#1 0xc056f19b at vop_stdlock+0x32
> >#2 0xc06cffde at VOP_LOCK_APV+0xa6
> >#3 0xc063d775 at ffs_lock+0x19
> >#4 0xc06cffde at VOP_LOCK_APV+0xa6
> >#5 0xc0587b58 at vn_lock+0xd3
> >#6 0xc057981f at vget+0xf0
> >#7 0xc056c22f at cache_lookup+0x3d0
> >#8 0xc056c8f6 at vfs_cache_lookup+0xa4
> >#9 0xc06cd997 at VOP_LOOKUP_APV+0xa6
> >#10 0xc057163b at lookup+0x47a
> >#11 0xc0570efa at namei+0x431
> >#12 0xc057cf38 at kern_statfs+0x6d
> >#13 0xc057cea5 at statfs+0x35
> >#14 0xc06b7359 at syscall+0x2e9
> >#15 0xc06a140f at Xint0x80_syscall+0x1f
> >
> > ino 1492256, on dev da0s1e
> >VNASSERT failed
> >0xcac88200: tag (null), type VMARKER
> > usecount 0, writecount 0, refcount 0 mountedhere 0
> > flags ()
> >
> >The only process running is umount:
> >
> >db> wh 2030
> >Tracing pid 2030 tid 100176 td 0xcbaa41a0
> >cpustop_handler(e8ef9a10,c06b648f,e8ef9998,e8ef9998,cbaa41a0) at
> >cpustop_handler+0x2c
> >ipi_nmi_handler(e8ef9998,e8ef9998,cbaa41a0,e8ef99a4,46) at
> >ipi_nmi_handler+0x29
> >trap(e8ef0008,e8ef0028,c06a0028,50,0) at trap+0x3f
> >calltrap() at calltrap+0x5
> >--- trap 0x13, eip = 0xc0504794, esp = 0xe8ef9a58, ebp = 0xe8ef9a78 ---
> >acquire(e8ef9afc,50,105,b2,cbaa41a0) at acquire+0x124
> >lockmgr(cd6bd838,2012,cd6bd8a8,cbaa41a0,e8ef9b28) at lockmgr+0x4df
> >vop_stdlock(e8ef9b7c,c063c186,c057cc44,c0742080,e8ef9b7c) at
> >vop_stdlock+0x32
> >VOP_LOCK_APV(c07425c0,e8ef9b7c,e8ef9b54,c06cffde,e8ef9b7c) at
> >VOP_LOCK_APV+0xa6
> >ffs_lock(e8ef9b7c,ce51a758,87f,2012,cd6bd7e0) at ffs_lock+0x19
> >VOP_LOCK_APV(c0742080,e8ef9b7c,138,ce51a690,ce51a690) at VOP_LOCK_APV+0xa6
> >vn_lock(cd6bd7e0,2012,cbaa41a0,79d,2012) at vn_lock+0xd3
> >vget(cd6bd7e0,2012,cbaa41a0,2ea,c6823488) at vget+0xf0
> >qsync(c6823400,0,c070a
(try) core dumps
I just noticed this in my system logs: Feb 23 07:14:19 laa kernel: pid 71141 (try), uid 0: exited on signal 10 (core dumped) Now, I have a very busy box here, but I cannot really tell to which software the 'try' belongs to, and since it's running as uid 0, this raises some alarms on my end. I also cannot find the core file... -- br, Tommi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.1-prerelease: boot loader pause timer hangs
Hi, I am keeping in sync with 6-Stable every now and then. At present I have a problem with the pause timer of the boot loader. In /boot/loader.conf I have: autoboot_delay="3" and as soon as the pause timer is supposed to count down, it kind of hangs; actually, the cursor seems to jump as if the number "3" is continuously printed instead of a countdown. This 'hang' continues until I hit the return key, after which the boot process continues as usual. When I remove the delay line in loader.conf, then the loader displays a pause timer of "10", but actually *immediately* continues as if the pause timer is zero (so no delay at all). I believe there's something wrong with the boot loader in 6.1-Prerelease. Or has my PC become buggy? Any idea what's the problem? Anybody else sees this? Regards, Rob. - /boot/loader.conf has following lines: autoboot_delay="3" # 3 seconds pause timer if_rl_load="YES" # PCI Ethernet random_load="YES" # Pseudo device for SSH sio_load="YES" # Serial (COM) ports - /boot.config has this: -D kernel config file has following: machine i386 cpu I686_CPU ident MYKERNEL options SCHED_4BSD options INET options INET6 options FFS options SOFTUPDATES options UFS_ACL options UFS_DIRHASH options COMPAT_43 options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV device pci device ata device atadisk options ATA_STATIC_ID device scbus device da device pass device atkbdc device atkbd device psm device vga device splash device sc device pmtimer device loop device ether device pty device md device bpf options SC_DISABLE_REBOOT options TCP_DROP_SYNFIN options DEVICE_POLLING options HZ=1000 --- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1-BETA2/FreeBSD 5.5-BETA2 Available
Disableing ACPI timer solved the problem. My Opteron box does not lock up. Thanks! > In <[EMAIL PROTECTED]> > Vivek Khera <[EMAIL PROTECTED]> wrote: > I'm gonna take a wild guess at ACPI problems. I have one system on > which I have to disable ACPI timer for anything >= 6.0-RELEASE. > To disable it, at the boot menu, select 6 to get a prompt, then type > set debug.acpi.disabled="timer" > boot > and see if it still locks up. -- NAKAJI Hiroyuki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
At 06:56 PM 27/02/2006, Albert Shih wrote: Is there any documentation to explain a newbie like me all (I mean really all of them) sysctl variable ? For example what net.inet.tcp.inflight.enable=0 Some have descriptions, some are talked about in man pages. eg. % sysctl -d net.inet.tcp.inflight net.inet.tcp.inflight: TCP inflight data limiting net.inet.tcp.inflight.enable: Enable automatic TCP inflight data limiting net.inet.tcp.inflight.debug: Debug TCP inflight calculations net.inet.tcp.inflight.min: Lower-bound for TCP inflight window net.inet.tcp.inflight.max: Upper-bound for TCP inflight window net.inet.tcp.inflight.stab: Inflight Algorithm Stabilization 20 = 2 packets and man tcp inflight.enableEnable TCP bandwidth-delay product limiting. An attempt will be made to calculate the bandwidth-delay product for each individual TCP connection, and limit the amount of inflight data being transmitted, to avoid building up unnecessary packets in the network. This option is recommended if you are serving a lot of data over connections with high bandwidth-delay prod- ucts, such as modems, GigE links, and fast long-haul WANs, and/or you have configured your machine to accommodate large TCP windows. In such situations, without this option, you may experience high interac- tive latencies or packet loss due to the overloading of intermediate routers and switches. Note that band- width-delay product limiting only effects the transmit side of a TCP connection. And of course, www.google.com is an excellent start as well. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
Le 27/02/2006 à 10:18:07-0500, Mike Tancsa a écrit > At 09:49 AM 27/02/2006, Danny Butroyd wrote: > >I have tried both tcp and udp mounts and have the same issues, the > >version of nfs is v3 (the default I believe). > > > >Is it possible to implement any of the NFS changes/tweaks on my current > >version? > > Not really as there are many changes behind the scenes that impact > it. Its not just the nfsd binary that has changed. There are a lot > of kernel stuff in support of it that has changed. > > BTW, if you are using tcp mounts, and you have devices not on the > same subnet, setting > net.inet.tcp.inflight.enable=0 > helps with performance. However, this is a separate issue to the > problems you are seeing. Is there any documentation to explain a newbie like me all (I mean really all of them) sysctl variable ? For example what net.inet.tcp.inflight.enable=0 change ? What's purpose of this variable ? Lots of thanks. Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Tue Feb 28 00:55:00 CET 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug(?) in cardbus code MFC'd to RELENG_6 on 30 January
M. Warner Losh wrote: I was unaware of this problem. It may be related to other problems that have surfaced in some code I recently MFC'd. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Perharps, it is the same problem I got with a dc card one week ago, and which seemingly did not interested anyone. Using black magic, I solved it by putting: hw.cbb.start_32_io="0x4000" in my loader.conf... I found it by googling, and trying a trick used for a different card, in a different computer, with a different version of FreeBSD ! I do not know why it works, but it works... Is there somewhere a tool or a set of procedures to diagnostic/solve this kind of port allocation problems, which manifest itself with different kind of messages (as I found when trying the same card on another computer) ?? Claude Buisson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug(?) in cardbus code MFC'd to RELENG_6 on 30 January
I was unaware of this problem. It may be related to other problems that have surfaced in some code I recently MFC'd. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sio12: 178 more interrupt-level buffer overflows" on 6.1-PRERELEASE
On Mon, Feb 27, 2006 at 09:36:25PM +0100, Holger Kipp wrote: > Hello, > > This looks like PR 51982 Yes - I just recompiled my kernel with the suggested change to sio.c, and the problem goes away... hmm. > Feb 27 21:03:17 dialout kernel: sio12: 24 more interrupt-level buffer > overflows (total 433) > Feb 27 21:03:56 dialout kernel: sio12: 178 more interrupt-level buffer > overflows (total 611) > Feb 27 21:04:13 dialout kernel: sio12: 71 more interrupt-level buffer > overflows (total 682) > Feb 27 21:05:56 dialout kernel: sio12: 172 more interrupt-level buffer > overflows (total 854) > Feb 27 21:06:06 dialout kernel: sio12: 79 more interrupt-level buffer > overflows (total 933) > Feb 27 21:06:07 dialout kernel: sio12: 4 more interrupt-level buffer > overflows (total 937) > Feb 27 21:07:56 dialout kernel: sio12: 23 more interrupt-level buffer > overflows (total 960) > Feb 27 21:08:06 dialout kernel: sio12: 26 more interrupt-level buffer > overflows (total 986) > > Interestingly, this only happens with the PCI-800H, > but the system also has an older 8-port ISA-Card that > works without any problems. And yes, the system is > an old and slow PIII with 500 MHz only, but I have > this problem even if only one modem is in use (sio12). > > I also don't know why the card can't use fast mode, > unless this is because it looks like 2 cards with 4 > ports that share an irq. > > All help/ideas really appreciated! > > Regards, > Holger Kipp > > - 8< - > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.1-PRERELEASE #1: Fri Feb 3 13:29:27 CET 2006 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/B-DIALOUT > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > > Features=0x383f9ff > real memory = 134205440 (127 MB) > avail memory = 121810944 (116 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > cpu0 on motherboard > pcib0: pcibus 0 on motherboard > pir0: on motherboard > $PIR: Using invalid BIOS IRQ 15 from 0.10.INTA for link 0x62 > $PIR: Using invalid BIOS IRQ 14 from 0.6.INTA for link 0x63 > pci0: on pcib0 > agp0: mem 0xe400-0xe7ff > at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > isab0: at device 4.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 4.2 (no driver attached) > pci0: at device 4.3 (no driver attached) > ahc0: port 0xb000-0xb0ff mem > 0xe100-0xe1000fff irq 14 at device 6.0 on pci0 > ahc0: [GIANT-LOCKED] > aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs > fxp0: port 0xa800-0xa83f mem > 0xe080-0xe0800fff,0xe000-0xe00f irq 15 at device 10.0 on pci0 > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:d0:b7:16:53:60 > puc0: port 0xa400-0xa41f,0xa000-0xa01f mem > 0xdf80-0xdf800fff,0xdf00-0xdf000fff irq 10 at device 11.0 on pci0 > sio12: on puc0 > sio12: type 16550A > sio12: unable to activate interrupt in fast mode - using normal mode > sio13: on puc0 > sio13: type 16550A > sio13: unable to activate interrupt in fast mode - using normal mode > sio14: on puc0 > sio14: type 16550A > sio14: unable to activate interrupt in fast mode - using normal mode > sio15: on puc0 > sio15: type 16550A > sio15: unable to activate interrupt in fast mode - using normal mode > puc1: port 0x9800-0x981f,0x9400-0x941f mem > 0xde80-0xde800fff,0xde00-0xde000fff irq 10 at device 11.1 on pci0 > sio16: on puc1 > sio16: type 16550A > sio16: unable to activate interrupt in fast mode - using normal mode > sio17: on puc1 > sio17: type 16550A > sio17: unable to activate interrupt in fast mode - using normal mode > sio18: on puc1 > sio18: type 16550A > sio18: unable to activate interrupt in fast mode - using normal mode > sio19: on puc1 > sio19: type 16550A > sio19: unable to activate interrupt in fast mode - using normal mode > pmtimer0 on isa0 > orm0: at iomem > 0xc-0xc7fff,0xc8000-0xcd7ff,0xd-0xd0fff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > isa0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > sc0: at flags 0
Bug(?) in cardbus code MFC'd to RELENG_6 on 30 January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a D-Link AirPlus G+ DWL-G650+ wireless cardbus adapter which I could use with NDISulator until I cvsup'd to 6.1-PRERELEASE yesterday. pciconf info: [EMAIL PROTECTED]:0:0: class=0x028000 card=0x3b051186 chip=0x9066104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapter' class= network dmesg with the "old" cardbus code: cardbus0: Expecting link target, got 0xf7 cardbus0: Resource not specified in CIS: id=10, size=2000 cardbus0: Resource not specified in CIS: id=14, size=2 ndis0: mem 0xd006-0xd0061fff,0xd004-0xd005 irq 18 at device 0.0 on cardbus0 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:11:95:6d:72:5e dmesg with the "new" code: cardbus0: Expecting link target, got 0xf7 ndis0: mem 0xd002-0xd003,0xd0002000-0xd0003fff at device 0.0 on cardbus0 ndis0: NDIS API version: 5.1 ndis0: init handler failed device_attach: ndis0 attach returned 6 Is it a known issue? Or should I cvsup to HEAD for solving this problem? Thanks, Laci - -- László Károly <[EMAIL PROTECTED]> Department of Altaic StudiesEgyetem str. 2. University of Szeged H-6722 Szeged, Hungary PGP/GnuPG key: 1024D/869D81C5 Fingerprint: 1E61 3205 8F5A 87E7 1269 3396 1C63 F9FF 869D 81C5 Encrypted e-mail preferred. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEA26oHGP5/4adgcURArSMAJ9cENeIdEoZCwrYc9klPY+YeOVlOQCfWadO BHDomQEWku3/YBtO4FPi0MY= =gpl1 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.1-PRERELEASE, wi(4), and dhclient
OK; I have been following the -stable list (among others), and realize that there are some "outstanding issues" with respect to wi(4). I'm wondering if premature invocation of dhclient with a reason code of "EXPIRE" is one of those "outstanding issues." Here's some history behind the query; I'll try to be brief: * Until about a week ago, I primarily used FreeBSD 4-STABLE on my succession of laptops (since Dec 2004, a Dell Inspiron 8200). This had nothing to do with the quality of FreeBSD, but was because I didn't want my laptop environment to diverge too much from a couple of "production" machines I have, which have their software built on a separate "build machine." Unfortunately, the build machine stopped working (hardware issues) in Feb 2005, and I have not yet had the resources to fix or replace it. * However, I had been tracking 6-STABLE (on slice 3), as well. * I had seen that dhclient sometimes failed to get a lease using the wi0 NIC under 6-STABLE (possibly 5-STABLE, as well, though I stopped tracking that about a month after 6.0 was released). At the time, I figured it wasn't that big a problem for me, since I was only running 6.x "experimentally" -- and I wasn't really in a position to fix wi(4). Further, I didn't have the problem under 4.x at all. * Last week, the laptop's disk drive reported uncorrectable errors reading from slice 1 (the 4.x slice). Given the available options, I booted from slice 3 (6.x), and then spent the next several days trying to re-assemble a native 6.x working environment. (The process has got to a point where the laptop is generally usable now. Pending some port-building issue resolution, I'm reasonably comfortable with it, save for the issue that catalyzed this note.) * Over the last couple of weeks (tracking 6-STABLE daily), I've not seen a recurrence of the "wi0 fails to get a lease" issue. This seems encouraging. * However, I did see that wi0 would sometimes lose its lease prematurely. * At first, I took the "very large hammer" approach to "resolving" this issue: Once I got a DHCP lease, I'd kill dhclient, thus preventing it from changing anything. I realize that there is no respect in which this might possibly be optimal, but I was short on several resources... and it did have the desired effect of allowing the laptop to maintain connectivity. * More recently, I thought I'd try to track just what is going on, while still trying to maintain connectivity. To that end, I hacked up a dhclient-enter-hooks that would look for a reason of EXPIRE, and then set exit_status to a non-zero value, thus telling dhclient to ignore the invocation. While this has many of the more unfortunate aspects of the earlier approach, it does permit some quantification of what is going on. Thus, yesterday afternoon, I booted up the laptop with the above-cited dhclient-enter-hooks in place at about 16:40 hrs. The laptop got a 7-day (604800-second) lease, and scheduled renewal in 302400 seconds (3.5 days). So far, so good. Here's an excerpt from the message log, showing when dhclient-enter-hooks was invoked. Please note that this was a rather "quiet" network -- there was only one other DHCP client on it: Feb 26 17:41:58 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 18:55:44 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 19:07:34 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 19:30:36 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 19:35:54 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 19:42:07 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 19:45:33 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation Feb 26 20:00:20 localhost dhclient: Ignoring claimed EXPIRE dhclient invocation I'm rather at a loss to make sense of the timing of these invocations. The first is after about an hour; I don't see much of a pattern as far as the intervals for the others are concerned. I'd rather not use this fairly heavy-handed approach to avoiding the symptome of the problem, and actually resolve the problem. If nothing else, I think it would be a lot nicer for other folks who are also trying to use NICs that use the wi(4) driver. So: other than the stock "use a different NIC" (the one I'm using is built into the laptop), would someone please loan me a clue? I do keep a local private mirror of the FreeBSD CVS repository, so it's fairly easy for me to test patches -- it just takes time to rebuild stuff. And I'll see about assigning one of the slices to -CURRENT soon. Here's what I'm running at the moment (recall that I'm tracking RELENG_6 daily): localhost(6.1-P)[11] uname -a FreeBSD localhost 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #5: Mon Feb 27 06:48:11 PST 2006 [EMAIL PROTECTED]:/common/S2/obj/usr/src/sys/LAPTOP_30W i386 localhost(6.1-P)[12] Here's what
Re: SSH login takes very long time...sometimes
Chuck Swiger <[EMAIL PROTECTED]> wrote: > Yar Tikhiy wrote: > [ ... ] > > A similar effect was observed when a `domain' line was specified > > in resolv.conf in place of `search'. > > > > Is there a real reason to retry with a different domain when the > > nameserver doesn't respond at all? > > UDP is lossy, and it may take a nameserver longer to respond that the client > resolver library is willing to wait; the fact that a nameserver didn't answer > once isn't a sure sign that it won't answer other questions, or even that it > won't answer the same question if you just wait a minute. Trying different domains isn't intended for fighting against UDP packets loss. To fight against UDP packets loss you have RES_DFLRETRY or "options attempts:N" retries of the same query. RES_DFLRETRY is defined in resolv.h and "options attempts:N" is optional parameter of /etc/resolv.conf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"sio12: 178 more interrupt-level buffer overflows" on 6.1-PRERELEASE
Hello, I have some problems with a Titan PCI-800H serial card. Due to many interrupt-level buffer overflows I can not use this card to establish TCP-connections via modem (initial telnet handshake did work whilst the card shared its irq with the adaptec- controller - the card should have its own irq now after I put it in a different PCI- slot).. This looks like PR 51982 Feb 27 21:03:17 dialout kernel: sio12: 24 more interrupt-level buffer overflows (total 433) Feb 27 21:03:56 dialout kernel: sio12: 178 more interrupt-level buffer overflows (total 611) Feb 27 21:04:13 dialout kernel: sio12: 71 more interrupt-level buffer overflows (total 682) Feb 27 21:05:56 dialout kernel: sio12: 172 more interrupt-level buffer overflows (total 854) Feb 27 21:06:06 dialout kernel: sio12: 79 more interrupt-level buffer overflows (total 933) Feb 27 21:06:07 dialout kernel: sio12: 4 more interrupt-level buffer overflows (total 937) Feb 27 21:07:56 dialout kernel: sio12: 23 more interrupt-level buffer overflows (total 960) Feb 27 21:08:06 dialout kernel: sio12: 26 more interrupt-level buffer overflows (total 986) Interestingly, this only happens with the PCI-800H, but the system also has an older 8-port ISA-Card that works without any problems. And yes, the system is an old and slow PIII with 500 MHz only, but I have this problem even if only one modem is in use (sio12). I also don't know why the card can't use fast mode, unless this is because it looks like 2 cards with 4 ports that share an irq. All help/ideas really appreciated! Regards, Holger Kipp - 8< - Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-PRERELEASE #1: Fri Feb 3 13:29:27 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/B-DIALOUT Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383f9ff real memory = 134205440 (127 MB) avail memory = 121810944 (116 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Using invalid BIOS IRQ 15 from 0.10.INTA for link 0x62 $PIR: Using invalid BIOS IRQ 14 from 0.6.INTA for link 0x63 pci0: on pcib0 agp0: mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) ahc0: port 0xb000-0xb0ff mem 0xe100-0xe1000fff irq 14 at device 6.0 on pci0 ahc0: [GIANT-LOCKED] aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs fxp0: port 0xa800-0xa83f mem 0xe080-0xe0800fff,0xe000-0xe00f irq 15 at device 10.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:b7:16:53:60 puc0: port 0xa400-0xa41f,0xa000-0xa01f mem 0xdf80-0xdf800fff,0xdf00-0xdf000fff irq 10 at device 11.0 on pci0 sio12: on puc0 sio12: type 16550A sio12: unable to activate interrupt in fast mode - using normal mode sio13: on puc0 sio13: type 16550A sio13: unable to activate interrupt in fast mode - using normal mode sio14: on puc0 sio14: type 16550A sio14: unable to activate interrupt in fast mode - using normal mode sio15: on puc0 sio15: type 16550A sio15: unable to activate interrupt in fast mode - using normal mode puc1: port 0x9800-0x981f,0x9400-0x941f mem 0xde80-0xde800fff,0xde00-0xde000fff irq 10 at device 11.1 on pci0 sio16: on puc1 sio16: type 16550A sio16: unable to activate interrupt in fast mode - using normal mode sio17: on puc1 sio17: type 16550A sio17: unable to activate interrupt in fast mode - using normal mode sio18: on puc1 sio18: type 16550A sio18: unable to activate interrupt in fast mode - using normal mode sio19: on puc1 sio19: type 16550A sio19: unable to activate interrupt in fast mode - using normal mode pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff,0xc8000-0xcd7ff,0xd-0xd0fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <32 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff
Re: sharedmem in jail.
There was some discussion about improving this situation a bit; i.e., by permitting an option wherein sysvipc could be per jail. Did this ever come to fruition? Ivan: you should be aware that Kris's short disclaimer really means that enabling the sysctl exposes sysvipc aware processes on the host to malicious programs in the jails (and between jails...) On Mon, 27 Feb 2006, Ivan Kolosovskiy wrote: > Ivan Kolosovskiy wrote: > > FreeBSD 6.0-p4. Sharedmem in jail doesnot works. I got "Function not > > implemented". > > > Sorry, i found "security.jail.sysvipc_allowed" sysctl flag =) > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Feb 27, 2006, at 1:19 PM, Ed Maste wrote: On Mon, Feb 27, 2006 at 11:07:35AM -0500, Vivek Khera wrote: I get a 9600 baud console with the following after upgrade from 5.4: This is what I'm planning on putting in UPDATING: The i386 loader(8) now defaults to the serial speed set by the previous boot stage, if the comconsole is already in use. If you've changed BOOT_COMCONSOLE_SPEED in make.conf(5) and installed a new loader, but have not rebuilt and reinstalled the boot blocks, then your loader will leave the console at 9600 baud. You may either set comconsole_speed in loader.conf (5), or reinstall new boot blocks as described in boot(8). -ed ... or set -S option in boot.config. From other discussion, the -S option seems to be the most straightforward method. The boot block update is described in boot0cfg(8) not boot(8), and must be done post-installworld, just to be 100% clear. Thanks for adding it to UPDATING. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Mon, Feb 27, 2006 at 11:07:35AM -0500, Vivek Khera wrote: > I get a 9600 baud console with the following after upgrade from 5.4: This is what I'm planning on putting in UPDATING: The i386 loader(8) now defaults to the serial speed set by the previous boot stage, if the comconsole is already in use. If you've changed BOOT_COMCONSOLE_SPEED in make.conf(5) and installed a new loader, but have not rebuilt and reinstalled the boot blocks, then your loader will leave the console at 9600 baud. You may either set comconsole_speed in loader.conf(5), or reinstall new boot blocks as described in boot(8). -ed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Mon, Feb 27, 2006 at 12:01:08PM -0500, Rong-En Fan wrote: > Which way is preferred: setting comconsole_speed, -S in > boot.config, or using harded code BOOT_COMCONSOLE_SPEED in make.conf? > If now the most preferred way is to using -S or > comconsole_speed in loader.conf, please update that in Handbook > 22.6.5.1 Setting a Faster Serial Port Speed. Probably the "best" way is now -S in boot.config, since it means that you don't have to recompile and you only have to change it in one place. Note that the instructions in 22.6.5.1 will still apply -- if you reinstall boot blocks compiled with BOOT_COMCONSOLE_SPEED=115200, the loader will automatically pick that up as well. You're right though that the handbook should document the preferred way of accomplishing this. -ed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Mon, Feb 27, 2006 at 12:01:08PM -0500, Rong-En Fan wrote: > On 2/27/06, Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > > On Sun, Feb 26, 2006 at 08:26:42PM +0100, Dimitry Andric wrote: > > > Ian Dowse wrote: > > > >> Okay, but why did 4.x through 5.x through 6.x (these have all been on > > > >> this particular machine) always boot with 115200 until now? :) > > > > > > > They probably used 9600 for the boot blocks, and then switched to > > > > 115200 when /boot/loader started, so you didn't notice. Now the > > > > settings from the boot blocks get used by /boot/loader. > > > > > > Ah, but this still means that /boot/loader used to use a hardcoded > > > default specified in /etc/make.conf, and now it doesn't honor that > > > anymore. > > > > > Have you checked with documentation? > > > > : comconsole_speed > > : Defines the speed of the serial console (i386 and amd64 only). > > : If the previous boot stage indicated that a serial console is > > : in use then this variable is initialized to the current speed > > : of the console serial port. Otherwise it is set to 9600 unless > > : this was overridden using the BOOT_COMCONSOLE_SPEED variable > > : when loader was compiled. Changes to the comconsole_speed > > : variable take effect immediately. > > Which way is preferred: setting comconsole_speed, -S in > boot.config, or using harded code BOOT_COMCONSOLE_SPEED in make.conf? > -S is the most convenient, as it will cause the serial port's speed to be consistent throughout all stages, boot2, loader, and kernel. > If now the most preferred way is to using -S or > comconsole_speed in loader.conf, please update that in Handbook > 22.6.5.1 Setting a Faster Serial Port Speed. > Someone with doc/-fu should pick it up I think. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpRZMBBYmm8W.pgp Description: PGP signature
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On 2/27/06, Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > On Sun, Feb 26, 2006 at 08:26:42PM +0100, Dimitry Andric wrote: > > Ian Dowse wrote: > > >> Okay, but why did 4.x through 5.x through 6.x (these have all been on > > >> this particular machine) always boot with 115200 until now? :) > > > > > They probably used 9600 for the boot blocks, and then switched to > > > 115200 when /boot/loader started, so you didn't notice. Now the > > > settings from the boot blocks get used by /boot/loader. > > > > Ah, but this still means that /boot/loader used to use a hardcoded > > default specified in /etc/make.conf, and now it doesn't honor that anymore. > > > Have you checked with documentation? > > : comconsole_speed > : Defines the speed of the serial console (i386 and amd64 only). > : If the previous boot stage indicated that a serial console is > : in use then this variable is initialized to the current speed > : of the console serial port. Otherwise it is set to 9600 unless > : this was overridden using the BOOT_COMCONSOLE_SPEED variable > : when loader was compiled. Changes to the comconsole_speed > : variable take effect immediately. Which way is preferred: setting comconsole_speed, -S in boot.config, or using harded code BOOT_COMCONSOLE_SPEED in make.conf? If now the most preferred way is to using -S or comconsole_speed in loader.conf, please update that in Handbook 22.6.5.1 Setting a Faster Serial Port Speed. Thanks, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Feb 25, 2006, at 9:14 PM, Ed Maste wrote: Thus, I'm not surprised that you get a 9600 baud console without an rc.conf setting. The thing that concerns me is your report that the console does not run at 115200 even if /boot/loader.conf contains comconsole_speed="115200". I get a 9600 baud console with the following after upgrade from 5.4: in make.conf: BOOT_COMCONSOLE_SPEED=115200 in kernel config: options CONSPEED=115200 # Speed for serial console /boot.config has just "-Dh" /boot/loader.conf just disables ACPI timer. The BIOS boots to 115200 serial output, too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Feb 25, 2006, at 8:56 PM, Ian Dowse wrote: They probably used 9600 for the boot blocks, and then switched to 115200 when /boot/loader started, so you didn't notice. Now the settings from the boot blocks get used by /boot/loader. Please document this loudly in the UPGRADING file. It caught me totally by surprise that the console speed was now 9600. I thought I lost my serial console since the BIOS was booting up at 115200. If it weren't for the other error (ACPI) keeping the kernel from booting, I would have realized it *before* I drove down to the office late saturday night. See, I needed a serial console to disable part of acpi for debugging :-( Anyhow, please, please document this in UPGRADING so others won't be bitten by it. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH login takes very long time...sometimes
Yar Tikhiy wrote: [ ... ] > A similar effect was observed when a `domain' line was specified > in resolv.conf in place of `search'. > > Is there a real reason to retry with a different domain when the > nameserver doesn't respond at all? UDP is lossy, and it may take a nameserver longer to respond that the client resolver library is willing to wait; the fact that a nameserver didn't answer once isn't a sure sign that it won't answer other questions, or even that it won't answer the same question if you just wait a minute. On the other hand, if you make 100 queries and not hear anything back, perhaps it would be useful to log that information and possibly take action. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
Mike Tancsa wrote: > At 10:26 AM 27/02/2006, Danny Butroyd wrote: > >> OK, do the changes affect both server and client and is there any >> documentation on the changes? > > cvs commits and reading this mailing is the best place to track what has > changed in detail. Unfortunately, there is no middle ground source for > information. I use a procmail script to sort all RELENG_6 commits into > a file that I can then search through after the fact. The descriptions > generally offer an OK description as to what was changed / fixed > improved. If that fails, going back to the original commit message might > offer more detail. e.g. a quick perusal of just the nfs code commits > shows a couple of obvious bug fixes. > > > maxim 2005-12-15 18:10:37 UTC > > FreeBSD src repository > > Modified files:(Branch: RELENG_6) > sys/nfsclientnfs_socket.c > Log: > MFC rev. 1.134: fix for a bug where NFS/TCP would > not reconnect (in the case where the server FIN'ed). > > PR: kern/88833 > Requested by: Roman V. Palagin > Approved by:Mohan Strinivasan > > Revision ChangesPath > 1.125.2.5 +1 -1 src/sys/nfsclient/nfs_socket.c > > > > tegge 2006-01-14 01:05:22 UTC > > FreeBSD src repository > > Modified files:(Branch: RELENG_6) > sys/nfs4client nfs4_vfsops.c > Log: > MFC: Obtain mount point lock before restarting sync loop if vget() > failed. > > Revision ChangesPath > 1.20.2.1 +1 -0 src/sys/nfs4client/nfs4_vfsops.c > > > > rwatson 2006-02-14 00:06:32 UTC > > FreeBSD src repository > > Modified files:(Branch: RELENG_6) > sys/nfsclientnfs_lock.c > Log: > Merge nfs_lock.c:1.43 from HEAD to RELENG_6: > > In nfs_dolock(), GC now under-used ioflg, rendered obsolete when we > moved > from using a fifo to talk to rpc.lockd to using a special device node. > > Approved by:re (scottl) > > > > > rees2006-02-16 02:39:53 UTC > > FreeBSD src repository > > Modified files:(Branch: RELENG_6) > sys/nfsclientnfs_socket.c > Log: > MFC rev 1.135: > Don't log an error on tcp connection reset, even if we don't get > ECONNRESET. > > Submitted by: [EMAIL PROTECTED] > Approved by:re (scottl) > > Revision ChangesPath > 1.125.2.6 +2 -2 src/sys/nfsclient/nfs_socket.c Thanks for the info Mike, I will upgrade my client machine to 6.1 (as the changes appear to be for the client source code) and do some testing. Cheers Danny > > > > > >> > >> > BTW, if you are using tcp mounts, and you have devices not on the same >> > subnet, setting >> > net.inet.tcp.inflight.enable=0 >> > helps with performance. However, this is a separate issue to the >> > problems you are seeing. >> > >> Yeah, I saw this in the list archives :) >> >> Danny >> > ---Mike >> > >> > >> >> Danny >> > >> > ___ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" >> > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1-BETA2/FreeBSD 5.5-BETA2 Available
I'm gonna take a wild guess at ACPI problems. I have one system on which I have to disable ACPI timer for anything >= 6.0-RELEASE. To disable it, at the boot menu, select 6 to get a prompt, then type set debug.acpi.disabled="timer" boot and see if it still locks up. On Feb 25, 2006, at 12:41 AM, NAKAJI Hiroyuki wrote: I tried 6.1-BETA2 on my dual Opteron PC, on which Solaris 10 is working very well. :) M/B RIOWORKS HDAMD (nForce 3 chipset) CPU AMD Opteron(tm) Processor 240 x2 Mem 1GB HDD U320 scsi drive (I forgot and Solaris does not show) SCSIAdaptec 39320A-R (I don't use RAID) I booted with bootonly.iso. But after the message, Waiting 5 seconds for SCSI devices to settle the PC stacks and ScreenLock key is no use. Can I use serial console to record the boot messages? Thanks. -- NAKAJI Hiroyuki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
At 10:26 AM 27/02/2006, Danny Butroyd wrote: OK, do the changes affect both server and client and is there any documentation on the changes? cvs commits and reading this mailing is the best place to track what has changed in detail. Unfortunately, there is no middle ground source for information. I use a procmail script to sort all RELENG_6 commits into a file that I can then search through after the fact. The descriptions generally offer an OK description as to what was changed / fixed improved. If that fails, going back to the original commit message might offer more detail. e.g. a quick perusal of just the nfs code commits shows a couple of obvious bug fixes. maxim 2005-12-15 18:10:37 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/nfsclientnfs_socket.c Log: MFC rev. 1.134: fix for a bug where NFS/TCP would not reconnect (in the case where the server FIN'ed). PR: kern/88833 Requested by: Roman V. Palagin Approved by:Mohan Strinivasan Revision ChangesPath 1.125.2.5 +1 -1 src/sys/nfsclient/nfs_socket.c tegge 2006-01-14 01:05:22 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/nfs4client nfs4_vfsops.c Log: MFC: Obtain mount point lock before restarting sync loop if vget() failed. Revision ChangesPath 1.20.2.1 +1 -0 src/sys/nfs4client/nfs4_vfsops.c rwatson 2006-02-14 00:06:32 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/nfsclientnfs_lock.c Log: Merge nfs_lock.c:1.43 from HEAD to RELENG_6: In nfs_dolock(), GC now under-used ioflg, rendered obsolete when we moved from using a fifo to talk to rpc.lockd to using a special device node. Approved by:re (scottl) rees2006-02-16 02:39:53 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/nfsclientnfs_socket.c Log: MFC rev 1.135: Don't log an error on tcp connection reset, even if we don't get ECONNRESET. Submitted by: [EMAIL PROTECTED] Approved by:re (scottl) Revision ChangesPath 1.125.2.6 +2 -2 src/sys/nfsclient/nfs_socket.c > > BTW, if you are using tcp mounts, and you have devices not on the same > subnet, setting > net.inet.tcp.inflight.enable=0 > helps with performance. However, this is a separate issue to the > problems you are seeing. > Yeah, I saw this in the list archives :) Danny > ---Mike > > >> Danny > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
> >> I have major problems using NFS on FreeBSD. My setup is:- > > I know there have been a number of changes that might help you since > > 6.0. I would try going to 6.1 first to see if your NFS problems go > > away. Also, are you mounting TCP or UDP mounts ? What version of NFS ? > I have tried both tcp and udp mounts and have the same issues, the > version of nfs is v3 (the default I believe). What is your rw-size in /etc/fstab? regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
Mike Tancsa wrote: > At 09:49 AM 27/02/2006, Danny Butroyd wrote: >> I have tried both tcp and udp mounts and have the same issues, the >> version of nfs is v3 (the default I believe). >> >> Is it possible to implement any of the NFS changes/tweaks on my current >> version? > > Not really as there are many changes behind the scenes that impact it. > Its not just the nfsd binary that has changed. There are a lot of > kernel stuff in support of it that has changed. OK, do the changes affect both server and client and is there any documentation on the changes? > > BTW, if you are using tcp mounts, and you have devices not on the same > subnet, setting > net.inet.tcp.inflight.enable=0 > helps with performance. However, this is a separate issue to the > problems you are seeing. > Yeah, I saw this in the list archives :) Danny > ---Mike > > >> Danny > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH login takes very long time...sometimes
On Sat, Feb 25, 2006 at 02:08:21AM +0900, Hajimu UMEMOTO wrote:
> > On Fri, 24 Feb 2006 15:51:53 +0200
> > Rostislav Krasny <[EMAIL PROTECTED]> said:
>
> rosti> Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need
> rosti> more testing or discussion?
>
> It seems reasonable to me, and there are no objection here. So, I've
> just committed both into HEAD.
I finally spared some time to test your recent changes and found
that the resolver still would retry using the first, and only the
first, domain on the `search' list when the nameserver was down,
which effectively led to another kind of request doubling.
A similar effect was observed when a `domain' line was specified
in resolv.conf in place of `search'.
Is there a real reason to retry with a different domain when the
nameserver doesn't respond at all?
--
Yar
P.S. Here's the details of what I'm talking about:
Commands:
vpc7# hostname
vpc7
vpc7# cat /etc/resolv.conf
search aaa.ru bbb.ru
nameserver 195.208.208.25
vpc7# ./gethost foo
foo: Host name lookup failure
vpc7# ./gethost foo.zzz.ru
foo.zzz.ru: Host name lookup failure
tcpdump:
=== for ./gethost foo ===
18:01:51.756764 IP 10.1.1.27.51030 > 195.208.208.25.53: 5443+ A? foo.aaa.ru.
(33)
18:01:56.971187 IP 10.1.1.27.57913 > 195.208.208.25.53: 5443+ A? foo.aaa.ru.
(33)
18:02:07.071088 IP 10.1.1.27.55508 > 195.208.208.25.53: 5444+ A? foo. (21)
18:02:12.210384 IP 10.1.1.27.62824 > 195.208.208.25.53: 5444+ A? foo. (21)
=== for ./gethost foo.zzz.ru ===
18:02:33.509361 IP 10.1.1.27.65031 > 195.208.208.25.53: 19867+ A?
foo.zzz.ru. (32)
18:02:38.567045 IP 10.1.1.27.55358 > 195.208.208.25.53: 19867+ A?
foo.zzz.ru. (32)
18:02:48.824136 IP 10.1.1.27.61855 > 195.208.208.25.53: 19868+ A?
foo.zzz.ru.aaa.ru. (44)
18:02:53.922071 IP 10.1.1.27.49351 > 195.208.208.25.53: 19868+ A?
foo.zzz.ru.aaa.ru. (44)
Here's ./gethost src. It essentially calls a single gethostbyname()
if given a host name or gethostbyaddr() if given an IP address.
=== gethost.c ===
#include
#include
#include
#include
#include
#include
int
main(int argc, char **argv)
{
struct in_addr ia;
struct hostent *hp;
char *name;
char **st;
if (argc < 2)
return (2);
name = argv[1];
if (inet_aton(name, &ia))
hp = gethostbyaddr((char *)&ia, sizeof(ia), AF_INET);
else
hp = gethostbyname(name);
if (hp == NULL) {
herror(name);
return (1);
}
printf("%s\n", hp->h_name);
for (st = hp->h_addr_list; *st; st++)
printf("%s\n", inet_ntoa(*(struct in_addr *)*st));
if (st == hp->h_addr_list)
printf("no address records\n");
return (0);
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
At 09:49 AM 27/02/2006, Danny Butroyd wrote: I have tried both tcp and udp mounts and have the same issues, the version of nfs is v3 (the default I believe). Is it possible to implement any of the NFS changes/tweaks on my current version? Not really as there are many changes behind the scenes that impact it. Its not just the nfsd binary that has changed. There are a lot of kernel stuff in support of it that has changed. BTW, if you are using tcp mounts, and you have devices not on the same subnet, setting net.inet.tcp.inflight.enable=0 helps with performance. However, this is a separate issue to the problems you are seeing. ---Mike Danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
Claus Guttesen wrote: I have major problems using NFS on FreeBSD. My setup is:- >>> I know there have been a number of changes that might help you since >>> 6.0. I would try going to 6.1 first to see if your NFS problems go >>> away. Also, are you mounting TCP or UDP mounts ? What version of NFS ? >> I have tried both tcp and udp mounts and have the same issues, the >> version of nfs is v3 (the default I believe). > > What is your rw-size in /etc/fstab? I have tried it with the defaults (i.e. none set) and also with the following:- r and w set to 32768. Danny > > regards > Claus > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
Mike Tancsa wrote: > At 07:26 AM 27/02/2006, Danny Butroyd wrote: >> Hi List >> >> I have major problems using NFS on FreeBSD. My setup is:- >> >> 1 mail server with 6.0 running NFS to serve mailboxes in standard unix >> format > > I know there have been a number of changes that might help you since > 6.0. I would try going to 6.1 first to see if your NFS problems go > away. Also, are you mounting TCP or UDP mounts ? What version of NFS ? Hi Mike I have tried both tcp and udp mounts and have the same issues, the version of nfs is v3 (the default I believe). Is it possible to implement any of the NFS changes/tweaks on my current version? Danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs woes in FreeBSD 6.0
At 07:26 AM 27/02/2006, Danny Butroyd wrote: Hi List I have major problems using NFS on FreeBSD. My setup is:- 1 mail server with 6.0 running NFS to serve mailboxes in standard unix format I know there have been a number of changes that might help you since 6.0. I would try going to 6.1 first to see if your NFS problems go away. Also, are you mounting TCP or UDP mounts ? What version of NFS ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Matlab
On Monday 27 February 2006 22:45, Albert Shih wrote: > > > /usr/local/matlab/bin/matlab: line 1: /lib/libc.so.6: cannot execute > > > binary file /usr/local/matlab-14/bin/glnx86/MATLAB: error while loading > > > shared libraries: /usr/lib/libtermcap.so: ELF file OS ABI invalid > > > > > > But I've compile the kernel with linux option and maple (other soft > > > using linux too) work fine. > > > > Do you have "linux_enable=YES" in your rc.conf? > > Yes of course... > > If I don't maple can't run... The problem you are having is that the FreeBSD libtermcap.so file is being found by the Linux dynamic linker. Unfortunately it does not just ignore the fact it's a FreeBSD binary - it blows up. You can try adding a manual symlink - I have libreadline.so.4 from linux_base but not libreadline.so, ie I suggest you do this.. cd /compat/linux/usr/lib ln -s libreadline.so.4 libreadline.so -- 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 pgpZTZHRuiygG.pgp Description: PGP signature
nfs woes in FreeBSD 6.0
Hi List I have major problems using NFS on FreeBSD. My setup is:- 1 mail server with 6.0 running NFS to serve mailboxes in standard unix format 2 webmail servers running a customised squirrellmail mounting the mailboxes from the main server (Yes, i know this is a nasty setup). All servers are talking over gigabit ethernet with an MTU set to 9000, they are all running Intel gigabit cards. Basically the mail server was running 5.1 and was working fine. I upgraded to 6.0 and now the NFS screws up all the time. The symtoms are failing NFS connections and corrupted mailboxes. Server errors are:- Feb 27 08:43:11 cwsmail-pri kernel: nfsd send error 32 Feb 27 08:56:47 cwsmail-pri kernel: nfsd send error 32 Feb 27 09:00:33 cwsmail-pri kernel: nfsd send error 32 Feb 27 09:12:21 cwsmail-pri kernel: nfsd send error 32 Feb 27 09:15:48 cwsmail-pri kernel: nfsd send error 32 Feb 27 09:24:11 cwsmail-pri last message repeated 11 times Feb 27 09:28:57 cwsmail-pri last message repeated 9 times Client errors are:- Feb 27 09:29:27 cwswebmail-1 kernel: nfs send error 35 for server 172.31.255.100:/var Feb 27 09:29:33 cwswebmail-1 kernel: nfs send error 35 for server 172.31.255.100:/var Feb 27 09:29:34 cwswebmail-1 kernel: nfs server 172.31.255.100:/var: not responding Feb 27 09:29:37 cwswebmail-1 kernel: nfs server 172.31.255.100:/var: not responding Feb 27 09:29:38 cwswebmail-1 kernel: nfs send error 35 for server 172.31.255.100:/var Feb 27 09:29:40 cwswebmail-1 kernel: nfs server 172.31.255.100:/var: not responding Feb 27 09:29:43 cwswebmail-1 kernel: nfs server 172.31.255.100:/var: not responding Feb 27 09:29:43 cwswebmail-1 kernel: nfs send error 35 for server 172.31.255.100:/var Feb 27 09:29:48 cwswebmail-1 kernel: nfs send error 35 for server 172.31.255.100:/var Feb 27 09:29:51 cwswebmail-1 kernel: nfs server 172.31.255.100:/var: not responding Feb 27 09:29:53 cwswebmail-1 kernel: nfs send error 35 for server 172.31.255.100:/var Feb 27 09:29:53 cwswebmail-1 kernel: nfs server 172.31.255.100:/var: is alive again Any help will be very much appreciated. Thanks Danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Matlab
Le 27/02/2006 à 12:39:13+0100, Dimitry Andric a écrit > Albert Shih wrote: > > /usr/local/matlab/bin/matlab: line 1: /lib/libc.so.6: cannot execute binary > > file > > /usr/local/matlab-14/bin/glnx86/MATLAB: error while loading shared > > libraries: /usr/lib/libtermcap.so: ELF file OS ABI invalid > > > > But I've compile the kernel with linux option and maple (other soft using > > linux too) work fine. > > Do you have "linux_enable=YES" in your rc.conf? > Yes of course... If I don't maple can't run... Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Mon Feb 27 13:14:16 CET 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Matlab
Albert Shih wrote: > /usr/local/matlab/bin/matlab: line 1: /lib/libc.so.6: cannot execute binary > file > /usr/local/matlab-14/bin/glnx86/MATLAB: error while loading shared libraries: > /usr/lib/libtermcap.so: ELF file OS ABI invalid > > But I've compile the kernel with linux option and maple (other soft using > linux too) work fine. Do you have "linux_enable=YES" in your rc.conf? signature.asc Description: OpenPGP digital signature
Matlab
Hi all I've a problem to running matlab (using linux_base-rh9) on my FreeBSD 6-stable (PAE kernel). On my old server (5-stable) everthing work fine but I'v make news fresh install with 6-stable (using PAE need because I have 4 Go). On the new server when I launch matlab I've got this message /usr/local/matlab/bin/matlab: line 1: /lib/libc.so.6: cannot execute binary file /usr/local/matlab-14/bin/glnx86/MATLAB: error while loading shared libraries: /usr/lib/libtermcap.so: ELF file OS ABI invalid But I've compile the kernel with linux option and maple (other soft using linux too) work fine. Anyone have a idea ? Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Mon Feb 27 12:13:24 CET 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Mon, Feb 27, 2006 at 10:38:20AM +0200, Ruslan Ermilov wrote: > > Okay. I still think it would be wiser to just reinstall them during > > installworld, just to be sure there's no incompatibilities... > > > It's not always possible to do: there can be different boot locations, > the root FS can be a remote one, it can be a diskless system, etc. Not to mention that broken boot blocks will destroy the ability of your system to boot, and require major reconstructive surgery. Much safer to only install them on command. Kris pgpLFwYMuOsZO.pgp Description: PGP signature
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
Ruslan Ermilov wrote: >> That's why installing 115200 baud boot blocks is still the better >> solution for me; my BIOS doesn't have any possibility to set the COM >> port speeds... > The best for you would be to add -S115200 in /boot.config, after > reinstalling new boot blocks (bsdlabel -B), and throw everything > else that's related from make.conf and loader.conf. I'll try this out, but I still usually like hardcoded defaults. :) signature.asc Description: OpenPGP digital signature
Re: Freebsd 6.1 and Palm Tungsten C
Hi!
Thanks for Your help!
I tried Your advice, but i'm in stock anyway.
Because all devices are created when i press Palm Sync. Except of course
/dev/ucom0, which now is replaced by /dev/cua0 in 6.+ version fbsd.
But when i press sync and run command which you have mentioned before, nothing
happens...
i see only
Listening to port: /dev/cuaU0
Please press teh HotSync button now
and nothing... after a few minutes palm says: unable to connect with device and
that's all...
i have googled, but didn't find any resolution, except same questions without
any answers...
it's seems - somewhere it's working and somewhere not...
i don't know what else i can do...
Best Regards,
Victoria
Hello Victoria,
>
> I also have a Tungsten C that I am using with FreeBSD 6.1-PRERELEASE
> without any problems.
>
> I *do not* have the entries that you have in my usbd.conf. In fact, I
> have not touched usbd.conf. However, I have the following entries added to
> /etc/devd.conf:
>
> attach 10 {
> device-name "ucom0";
> action "chmod 0666 /dev/cuaU0";
> };
>
>
> To backup my palm, I do the following:
>
> 1. kldload uvisor
>
> 2. Press the sync button on my Tungsten C cradle.
>
> 3. Run the following command:
> pilot-xfer -p /dev/cuaU0 -b /home/someone/palm_bkup
>
> Try commenting out the entries in your usbd.conf file and add the
> entries that I have in my devd.conf file and see if it works for you.
>
> regards,
> joseph
>
>
>
> On Sun, Feb 19, 2006 at 02:56:46AM +, Viktorija wrote:
> > Hi!
> >
> > I have following problem. I have Palm Tungsten C and FreeBSD 6.1 on my
> > laptop. I'm trying to synhronize my palm with freebsd, but without any
> > success. What i did:
> > in kernel added devices:
> > ucom and uvisor.
> > in usbd.conf:
> > device "Palm Handheld"
> > devname "ucom[0-9]+"
> > vendor 0x0830
> > product 0x0060
> > release 0x0100
> > attach "ln -fs /dev/ucom0 /dev/pilot; chmod 666 /dev/ucom0"
> >
> > When i press sync button on palm, i see in messages:
> > Feb 19 02:50:29 blue kernel: ucom0: Palm, Inc. Palm Handheld, rev
> > 1.00/1.00, addr 2
> >
> > And in /dev directory i get cuaU0 and ttyU0, but not ucom0.
> > Ok, i saw in one message, that now ttyU0 should be used instead of ucom0,
> > but when i'm trying:
> > pilot-xfer -p /dev/ttyU0 -i palm/softs/Tube/Tube2.prc
> > nothing happens...
> >
> > What i'm doing wrong?
> > Why ucom0 doesn't exist?
> > Maybe someone got similar problems?
> >
> >
> > Thank You!
> > Victoria
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
On Sun, 19 Feb 2006 18:33:22 -0800
Joseph Olatt <[EMAIL PROTECTED]> wrote:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Sun, Feb 26, 2006 at 09:26:02PM +0100, Dimitry Andric wrote: > Ed Maste wrote: > > So I suspect that the following happens when you boot: > > > > - your BIOS sets the serial port to 9600 > > Yes. > > > - boot0 does nothing with the serial pot > > I'm using 'dangerously dedicated' disks, so it's only boot[12] that is used. > > > - boot1/2 reads the -P in /boot.config and detects no keyboard, and > > then sets the serial port to 9600 and the console to comconsole > > Indeed, I never got the "/boot.config: -P" message on the serial console > before. Now I get it, using updated boot blocks. > > > - the loader detects that the serial port is enabled and is already > > set to 9600 > > > Thus, I'm not surprised that you get a 9600 baud console without > > an rc.conf setting. The thing that concerns me is your report that > > the console does not run at 115200 even if /boot/loader.conf > > contains comconsole_speed="115200". > > This turns out to be an error on my part, sorry to have you worried. :) > I'd accidentally put "console_speed=115200" in loader.conf. With > "comconsole_speed=115200" and 9600 baud boot blocks, it works okay, > although you don't see any of the boot[12] messages, of course. > > That's why installing 115200 baud boot blocks is still the better > solution for me; my BIOS doesn't have any possibility to set the COM > port speeds... > The best for you would be to add -S115200 in /boot.config, after reinstalling new boot blocks (bsdlabel -B), and throw everything else that's related from make.conf and loader.conf. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgprJ5XO3cqOf.pgp Description: PGP signature
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Sun, Feb 26, 2006 at 08:26:42PM +0100, Dimitry Andric wrote:
> Ian Dowse wrote:
> >> Okay, but why did 4.x through 5.x through 6.x (these have all been on
> >> this particular machine) always boot with 115200 until now? :)
>
> > They probably used 9600 for the boot blocks, and then switched to
> > 115200 when /boot/loader started, so you didn't notice. Now the
> > settings from the boot blocks get used by /boot/loader.
>
> Ah, but this still means that /boot/loader used to use a hardcoded
> default specified in /etc/make.conf, and now it doesn't honor that anymore.
>
Have you checked with documentation?
: comconsole_speed
: Defines the speed of the serial console (i386 and amd64 only).
: If the previous boot stage indicated that a serial console is
: in use then this variable is initialized to the current speed
: of the console serial port. Otherwise it is set to 9600 unless
: this was overridden using the BOOT_COMCONSOLE_SPEED variable
: when loader was compiled. Changes to the comconsole_speed
: variable take effect immediately.
> > Boot blocks need to be installed manually - installworld installs
> > the boot blocks as files in /boot/boot{1,2}, but when booting, it
> > is the boot blocks in the first 8k of the slice that are used, not
> > the /boot/boot{1,2} files.
>
> Okay. I still think it would be wiser to just reinstall them during
> installworld, just to be sure there's no incompatibilities...
>
It's not always possible to do: there can be different boot locations,
the root FS can be a remote one, it can be a diskless system, etc.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpVnv0QPXRfw.pgp
Description: PGP signature
Re: sharedmem in jail.
Ivan Kolosovskiy wrote: FreeBSD 6.0-p4. Sharedmem in jail doesnot works. I got "Function not implemented". Sorry, i found "security.jail.sysvipc_allowed" sysctl flag =) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sharedmem in jail.
On Mon, Feb 27, 2006 at 12:32:33PM +0300, Ivan Kolosovskiy wrote: > FreeBSD 6.0-p4. Sharedmem in jail doesnot works. I got "Function not > implemented". It's disabled by default because it's an information disclosure risk. The manpage tells you how to enable it. Kris pgpU97jJ4Tkub.pgp Description: PGP signature
sharedmem in jail.
FreeBSD 6.0-p4. Sharedmem in jail doesnot works. I got "Function not
implemented".
Source code:
#include
#include
#include
#include
int main() {
unsigned int segment = shmget( IPC_PRIVATE, 1 , SHM_R | SHM_W );
perror("");
printf( "Got segment: %d\n", segment );
return 1;
}
in jail:
$ ./a.out
Function not implemented
Got segment: -1
not in jail:
# ./a.out
Unknown error: 0
Got segment: 196609
what's wrong?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rip2 ospf: freebsd 6.0
> >>hi liste > >> > >>I'm looking for a dynamic routing (rip2, ospf) solution under freebsd > >>6.0. currently, I've always known zebra which exists in freebsd ports > >>collection. do have a better idea? > >> > >Though I haven't used it myself, I've talked to people who've done > >well with quagga for BGP. > >> > nice, i've had fun with one hour of gmake. It seems being supported by > $M... let's see... thanks a lot for informations Quagga is a port and there is a package for it available, so you don't need to fight with gmake. I haven't used it with ospf yet, but have used it on IPv4 and IPv6 with rip1, rip2, ripng and bgp. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rip2 ospf: freebsd 6.0
Aaron Seelye wrote: Though I haven't used it myself, I've talked to people who've done well with quagga for BGP. -Aaron - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Friday, February 24, 2006 1:47 AM Subject: rip2 ospf: freebsd 6.0 hi liste I'm looking for a dynamic routing (rip2, ospf) solution under freebsd 6.0. currently, I've always known zebra which exists in freebsd ports collection. do have a better idea? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.0.0/267 - Release Date: 2/22/2006 nice, i've had fun with one hour of gmake. It seems being supported by $M... let's see... thanks a lot for informations -- Richard VENNE www.dental-on-line.com Phone: 01 43 27 94 24 fax: 01 43 27 66 85 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
