Re: Disappearing IPv6 default route
John Hay wrote:
-} else if (req == RTM_ADD SDL(gate)-sdl_alen == 0) {
+} else if (req == RTM_ADD SDL(gate)-sdl_alen == 0
+(rt-rt_flags RTF_HOST) != 0) {
ln-ln_state = ND6_LLINFO_INCOMPLETE;
Please do MFC. This patch seems to have solved all the problems I was
experiencing, and I can see the dancing Kame again now.
Cheers,
Matthew
Can you please try this patch too? The previous one I gave you, still
have some unwanted side effect. This one is by JINMEI, Tatuya and
seems to be without any... As far as I could test.
That one seems to work fine as well. I can't say I have seen any side effects
with either the previous patch or this one, but then my IPv6 setup is pretty
minimal and it's all static routing.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: ipfilter nat w/IPFILTER_DEFAULT_BLOCK kernel
On Sat, 30 Sep 2006 20:30:28 -0400
Matt Herzog [EMAIL PROTECTED] wrote:
As the Subject states, I'm trying to get a FreeBSD 6.1 on sparc64 to be a
firewall/gateway/nat machine using a IPFILTER_DEFAULT_BLOCK kernel.
(hme0 is the external NIC. hme1 is the internal NIC.)
If I remove the line:
pass in quick on hme0 all
none of the machines inside the NAT can reach the Internet although I can
still ssh into the firewall/gateway machine from inside the NAT.
i.e. NAT breaks without pass in quick on hme0 all
I haven't read all your config...but i think the problem you are having is that
you are either blocking ALL traffic to hme0 (by removing the 'allow all'), or
allowing all (including external traffic! ) with 'pass in quick on hme0 all'.
You need to be more specific about what you allow in and out. Read the
following and you'll get a better understanding of how it works.
Howto : http://www.obfuscation.org/ipf/ipf-howto.pdf :
http://www.nwo.net/ipf/ipf-howto.html (html format of the pdf)
pass in quick on hme0 all pretty obviously defeats the purpose of the
IPFILTER_DEFAULT_BLOCK kernel so I'm trying to figure out a rule set that
will work with NAT.
well, yes, you are not supposed to open your firewall completely - just enough
to allow you to do whatever you want :)
Good luck,
B
_
{Beto|Norberto|Numard} Meijome
Sysadmins can't be sued for malpractice, but surgeons don't have to
deal with patients who install new versions of their own innards.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS: freeze during copy [ ALMOST RESOLVED]
Christopher Sean Hilton wrote: On Wed, 2006-09-27 at 16:37 -0400, Kris Kennaway wrote: and my luck has it such that i've not had a lockup since i added that extra debugging code into the kernel :-) or :-( depending on your view... Heisenbugs are great! :) Before I classified this as a Heisenbug I'd switch from NFS over UDP to NFS over TCP. The original poster also hasn't mentioned if he's using soft, or hard mounts or if he has the intr option on. Depending on how these options are tuned NFS lockups are normal. I used keep /usr/src mounted via NFS and do make buildworld/installworld on my laptop. The network was a switched lan and there were no firewalls. Very occasionally the build process would lockup. When I went to debug this a sage wizard suggested that the first step was to switch from UDP to TCP. As it turns out the problem was that the ne2000 driver on my laptop was loosing packets. With udp the means to detect this was weak to non-existant. Changing to TCP meant that not only could the kernel detect that a packet had gotten lost but it only had to resend that one packet, not the entire buffer. From that point on the build process worked flawlessly in fact I was able to extend the process to work between a local NFS server and a remote NFS client located 25 miles away at the other end of an IPsec tunnel. Bottom line: change to TCP and retest. NFS over UDP is very sensitive to packet loss. -- Chris yeah, your'ar right, NFS tcp would be propably better. My setup was using UDP with changing port, that's the reason why, as for me, the copy was freezed after somes bytes. But I still supprised by kernel freezing after a night, so that I've had to reboot the server. As 5.x's support will be stopped, I'd better to upgrade all to 6.1 ( NFS problems, openssl secure issues...) thanks a lot for all. -- 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]
Re: GIANT in arcmsr(4)
Dear Nikolas Britton, Sorry, I was busy on some raid bug fix and cause this driver released delay. It had been test this driver on my Lab. for a long time. Hope it can release on FreeBSD new kernel in the near future. Best Regards Erich Chen - Original Message - From: Nikolas Britton [EMAIL PROTECTED] To: erich [EMAIL PROTECTED] Cc: (廣安科技)安可O [EMAIL PROTECTED]; [EMAIL PROTECTED]; FreeBSD Stable List freebsd-stable@freebsd.org Sent: Tuesday, August 01, 2006 10:47 AM Subject: Re: GIANT in arcmsr(4) On 7/31/06, erich [EMAIL PROTECTED] wrote: Dear Nikolas Britton, Sorry I had new arcmsr driver version 1.20.00.13 for FreeBSD i386/amd64/ppc plateform. This version add ARECA new generation RAID adapters ( SATA / SAS ) into arcmsr. Its xfer rate more than 800MB/sec. I need more time to test arcmsr on PowerMac G5 even SPARC machine in my Lab. Any comments and opinion with this driver will win acceptance. Best Regards Erich Chen Do you have a link to download v1.20.00.13? and have you MFC'd the changes we made back into your new code?: Here are the changes we made to 1.20.00.02: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/arcmsr/arcmsr.c Could I also suggest sed 's/.$//' to convert those pesky CR+LF Windows files to UNIX format. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ffs snapshot lockup
On Mon, Oct 02, 2006 at 03:23:49PM -0400, Vivek Khera wrote:
On Sep 22, 2006, at 4:36 PM, Kris Kennaway wrote:
Start by enabling INVARIANTS, INVARIANT_SUPPORT, DEBUG_LOCKS and
DEBUG_VFS_LOCKS, then run 'show lockedvnods' and 'alltrace' in DDB
(spammy, need that serial console), or at least trace the running
processes (show allpcpu) and those listed in lockedvnods. Then call
doadump and save the core+kernel.debug when you reboot.
Well, what an exciting weekend we had! Three lockups/panics: two
during running a dump (mksnap_ffs seems to be the culprit) and one
running background fsck after rebooting from the prior crash.
Details are posted at http://vivek.khera.org/scratch/crashlogs/
I have the crashdumps available to a kernel hacker upon request (i'd
rather not make them generally available to the public...)
It seems that you have snapshotted fs exported by nfsd ? At least, 18a is
definitely the case. I have the patch (for current) that shall fix the issue.
In fact, you need two patches:
1. buffer ownership patch by Tor Egge (already in current, I think it shall
be MFCed before 6.2)
tegge 2006-10-02 02:06:27 UTC
FreeBSD src repository
Modified files:
sys/kern kern_lock.c vfs_bio.c
sys/sys buf.h lockmgr.h
Log:
If the buffer lock has waiters after the buffer has changed identity then
getnewbuf() needs to drop the buffer in order to wake waiters that might
sleep on the buffer in the context of the old identity.
Revision ChangesPath
1.100 +15 -0 src/sys/kern/kern_lock.c
1.510 +11 -0 src/sys/kern/vfs_bio.c
1.194 +11 -0 src/sys/sys/buf.h
1.51 +1 -0 src/sys/sys/lockmgr.h
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to [EMAIL PROTECTED]
Index: src/sys/kern/kern_lock.c
diff -u src/sys/kern/kern_lock.c:1.99 src/sys/kern/kern_lock.c:1.100
--- src/sys/kern/kern_lock.c:1.99 Tue Aug 15 18:29:01 2006
+++ src/sys/kern/kern_lock.cMon Oct 2 02:06:26 2006
@@ -566,6 +566,21 @@
}
/*
+ * Determine the number of waiters on a lock.
+ */
+int
+lockwaiters(lkp)
+ struct lock *lkp;
+{
+ int count;
+
+ mtx_lock(lkp-lk_interlock);
+ count = lkp-lk_waitcount;
+ mtx_unlock(lkp-lk_interlock);
+ return (count);
+}
+
+/*
* Print out information about state of a lock. Used by VOP_PRINT
* routines to display status about contained locks.
*/
Index: src/sys/kern/vfs_bio.c
diff -u src/sys/kern/vfs_bio.c:1.509 src/sys/kern/vfs_bio.c:1.510
--- src/sys/kern/vfs_bio.c:1.509Wed Aug 9 17:43:26 2006
+++ src/sys/kern/vfs_bio.c Mon Oct 2 02:06:26 2006
@@ -1890,6 +1890,17 @@
}
/*
+* Notify any waiters for the buffer lock about
+* identity change by freeing the buffer.
+*/
+ if (qindex == QUEUE_CLEAN BUF_LOCKWAITERS(bp) 0) {
+ bp-b_flags |= B_INVAL;
+ bfreekva(bp);
+ brelse(bp);
+ goto restart;
+ }
+
+ /*
* If we are overcomitted then recover the buffer and its
* KVM space. This occurs in rare situations when multiple
* processes are blocked in getnewbuf() or allocbuf().
Index: src/sys/sys/buf.h
diff -u src/sys/sys/buf.h:1.193 src/sys/sys/buf.h:1.194
--- src/sys/sys/buf.h:1.193 Fri Mar 31 02:56:30 2006
+++ src/sys/sys/buf.h Mon Oct 2 02:06:27 2006
@@ -371,6 +371,17 @@
return ret;
}
+
+/*
+ * Find out the number of waiters on a lock.
+ */
+static __inline int BUF_LOCKWAITERS(struct buf *);
+static __inline int
+BUF_LOCKWAITERS(struct buf *bp)
+{
+ return (lockwaiters(bp-b_lock));
+}
+
#endif /* _KERNEL */
struct buf_queue_head {
Index: src/sys/sys/lockmgr.h
diff -u src/sys/sys/lockmgr.h:1.50 src/sys/sys/lockmgr.h:1.51
--- src/sys/sys/lockmgr.h:1.50 Tue Aug 15 18:29:01 2006
+++ src/sys/sys/lockmgr.h Mon Oct 2 02:06:27 2006
@@ -203,6 +203,7 @@
void lockmgr_printinfo(struct lock *);
intlockstatus(struct lock *, struct thread *);
intlockcount(struct lock *);
+intlockwaiters(struct lock *);
#ifdef DDB
intlockmgr_chain(struct thread *td, struct thread **ownerp);
#endif
2. this one (it shall be applied in the sys/ufs; please, test and report
results)
Index: ffs/ffs_inode.c
===
RCS file: /usr/local/arch/ncvs/src/sys/ufs/ffs/ffs_inode.c,v
retrieving revision 1.106
diff -u -r1.106 ffs_inode.c
--- ffs/ffs_inode.c 5 Apr 2005 08:49:41 - 1.106
+++ ffs/ffs_inode.c 27 Sep 2006 08:29:18 -
@@ -66,9 +66,11 @@
* IN_ACCESS, IN_UPDATE, and IN_CHANGE flags respectively. Write the inode
* to disk if the IN_MODIFIED flag is set (it may be set
Re: EV1 Servers makes me sick
On 10/3/06, Roger 'Rocky' Vetterberg [EMAIL PROTECTED] wrote: Scott I. Remick wrote: Eduardo Meyer wrote: I have been pointed in private mail to http://www.fdcservers.net/ which seems to treat FreeBSD more seriously too, in case anyone else is/get disapointed by EV1's lack of professionalism regarding FreeBSD. FDC seems to have a pretty sweet price for a VPS (starting at $19/mo) but I see no mention of FreeBSD...? I might consider switching to a VPS if I can find a FreeBSD-based one that is priced affordably (I don't make money off my site, so cost matters). If you want a cheap VPS you could look at www.jvds.com, I believe they offer FreeBSD VPS's starting at $15. If you want a true dedicated server I recommend www.layeredtech.com, very cheap, stable and friendly staff. I'm not affiliated in any way with any of the above mentioned companies. In the first case I only know them by reputation, in the second, I'm a satisfied customer. -- R ___ freebsd-advocacy@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy To unsubscribe, send any mail to [EMAIL PROTECTED] I was also told that http://www.serverpronto.com/ is freebsd friendly and extremely cheap. -- Alexandre Vieira - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with old /usr/src/contrib/amd
Hi all, i was wondering if an update of /usr/src/contrib/amd is planned ? I encounter a problem using amd with nolock options, and it seems that this problem was fixed on recent version of am-utils. Many thanks, Nicolas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EV1 Servers makes me sick
Alexandre Vieira wrote: I was also told that http://www.serverpronto.com/ is freebsd friendly and extremely cheap. Since this seems to have become a recommendation thread, I'm a happy customer of http://www.johncompanies.com/. They offer discounts to open source contributor's too. N ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with old /usr/src/contrib/amd
In the last episode (Oct 03), Nicolas Martin said: i was wondering if an update of /usr/src/contrib/amd is planned ? I encounter a problem using amd with nolock options, and it seems that this problem was fixed on recent version of am-utils. If anything, it would be updated in -current, not stable. Until a newer version is imported, you can use the sysutils/am-utils port. -- Dan Nelson [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: 945GM graphics and mplayer
On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
6.2-PRE /boot/loader
Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) regards, -- auge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were RELENG_6: http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch Regards cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. -- Marcus Alves Grando marcus(at)corp.grupos.com.br | Grupos Internet S/A mnag(at)FreeBSD.org | FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EV1 Servers makes me sick
On Monday 02 October 2006 21:16, Roland Smith wrote: Well, these are the same guys that bought a license from SCO for SCO's alleged IP in Linux (and alledgedly in *BSD, before the settlement in USL vs BSDi was made public). Apparently after a large bribe^H^H^H^H^Hdiscount from Microsoft. Definitely not the sharpest knife in the drawer, IMHO. But maybe I'm being too harsh. Someone used them to post a large amount of blog spam to my blog from some of their servers for a period of quite a few weeks. They did nothing, not even reply, despite various abuse reports. They are nothing but pathetic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Crash, pagefault, not sure why/where.
On Mon, 2 Oct 2006, Larry Rosenman wrote: I can also make a shell account available if a dev wants to nose around. LER Should I just send-pr this dump info and hold on to the 4G vmcore for a while? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Various smbus(4) driver fixups and locking
On Mon, 02 Oct 2006 15:53:26 -0400 John Baldwin [EMAIL PROTECTED] wrote: http://www.FreeBSD.org/~jhb/patches/smbus_locking.patch Hmm, I have a Nforce4-based maonboard, and went looking for nfsmb, but I can't find it anywhere on my system. My system is: [EMAIL PROTECTED] uname -a FreeBSD kg-quiet.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #9: Wed Sep 20 22:59:59 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET amd64 Isn't that strange? Or is nfsmb only an i386-thing? -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat -i output after solving snd problems.
On Sunday 01 October 2006 12:08, Marcin Koziej wrote: 2) vmstat -i now shows: interrupt total rate irq0: clk6824889968 irq1: atkbd0 13103 1 irq4: sio0 2 0 irq7: ppc071 0 irq8: rtc 890176126 irq9: nvidia0 cbb*464262 65 irq10: cbb0 uhci1* 3 0 irq11: ndis0 re0+ 130633 18 irq12: psm0 597273 84 irq14: ata0 118892 16 irq15: ata1 74 0 Total9039378 1283 Does it look normal? What do '*' and '+' after device names mean? I couldn't find this information in man vmstat, google or even quich grep through vmstat.c. What am I missing? Is there something to be worried about this? Nothing to worry about. It means that there are more devices that couldn't be fit into the available space for the name. A + means there is one more device on this IRQ and there wasn't enough room for its name. A * means there are 2 or more devices on this IRQ and there wasn't enough room for their names. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE /boot/loader
On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with old /usr/src/contrib/amd
Hi, I'll do an update of /usr/src/contrib/amd soon, after 6.2 is done. Maybe we will see it then in 6.3 RELEASE :-) Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- On Tue, 3 Oct 2006, Nicolas Martin wrote: Hi all, i was wondering if an update of /usr/src/contrib/amd is planned ? I encounter a problem using amd with nolock options, and it seems that this problem was fixed on recent version of am-utils. Many thanks, Nicolas ___ 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[2]: EV1 Servers makes me sick
Hello Nik, Tuesday, October 3, 2006, 4:31:11 PM, you wrote: Alexandre Vieira wrote: I was also told that http://www.serverpronto.com/ is freebsd friendly and extremely cheap. Since this seems to have become a recommendation thread, I'm a happy customer of http://www.johncompanies.com/. They offer discounts to open source contributor's too. also layeredtech.com is pretty good. -- Best regards, Danielmailto:[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: 6.2-PRE /boot/loader
Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpe7t3jjpm9j.pgp Description: PGP signature
Re: 6.2-PRE /boot/loader
On Tue, Oct 03, 2006 at 11:47:35PM +0400, Ruslan Ermilov wrote: Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Hmm, well. I forgot that I've already committed them. But it doesn't use high memory by default, only if bzip2 support is activated. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpH23KlIzVHg.pgp Description: PGP signature
Re: [PATCH] Various smbus(4) driver fixups and locking
On Tuesday 03 October 2006 15:00, Torfinn Ingolfsen wrote: On Mon, 02 Oct 2006 15:53:26 -0400 John Baldwin [EMAIL PROTECTED] wrote: http://www.FreeBSD.org/~jhb/patches/smbus_locking.patch Hmm, I have a Nforce4-based maonboard, and went looking for nfsmb, but I can't find it anywhere on my system. My system is: [EMAIL PROTECTED] uname -a FreeBSD kg-quiet.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #9: Wed Sep 20 22:59:59 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET amd64 Isn't that strange? Or is nfsmb only an i386-thing? That I don't know. It might not be enabled on amd64. Does it work before the patches and not after? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE /boot/loader
On Tuesday 03 October 2006 15:48, Ruslan Ermilov wrote: On Tue, Oct 03, 2006 at 11:47:35PM +0400, Ruslan Ermilov wrote: Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Hmm, well. I forgot that I've already committed them. But it doesn't use high memory by default, only if bzip2 support is activated. I thought you changed that from '#ifdef LOADER_BZIP2_SUPPORT' to '#if 1' in your patches so it now always uses high memory? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE /boot/loader
On Tue, Oct 03, 2006 at 03:58:38PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 15:48, Ruslan Ermilov wrote: On Tue, Oct 03, 2006 at 11:47:35PM +0400, Ruslan Ermilov wrote: Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Hmm, well. I forgot that I've already committed them. But it doesn't use high memory by default, only if bzip2 support is activated. I thought you changed that from '#ifdef LOADER_BZIP2_SUPPORT' to '#if 1' in your patches so it now always uses high memory? In experimental uncommitted patches, yes. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpNiqfK0hS74.pgp Description: PGP signature
Re: [PATCH] Various smbus(4) driver fixups and locking
On Tue, Oct 03, 2006 at 09:00:29PM +0200, Torfinn Ingolfsen wrote: On Mon, 02 Oct 2006 15:53:26 -0400 John Baldwin [EMAIL PROTECTED] wrote: http://www.FreeBSD.org/~jhb/patches/smbus_locking.patch Hmm, I have a Nforce4-based maonboard, and went looking for nfsmb, but I can't find it anywhere on my system. My system is: [EMAIL PROTECTED] uname -a FreeBSD kg-quiet.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #9: Wed Sep 20 22:59:59 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET amd64 Isn't that strange? How did you search for it? Or is nfsmb only an i386-thing? Definitely not. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpJq2xgbTsfQ.pgp Description: PGP signature
Re: 945GM graphics and mplayer
Marcus Alves Grando wrote: Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were RELENG_6: http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch Eric, Marcus, who's patch should I try on RELENG_6? Anyway I'll try both in couple of days and let you know how it goes. thanks a lot, Ganbold Regards cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ffs snapshot lockup
On Oct 3, 2006, at 4:43 AM, Kostik Belousov wrote: Details are posted at http://vivek.khera.org/scratch/crashlogs/ I have the crashdumps available to a kernel hacker upon request (i'd rather not make them generally available to the public...) It seems that you have snapshotted fs exported by nfsd ? At least, 18a is definitely the case. I have the patch (for current) that shall fix the issue. In fact, you need two patches: Yes, it is an NFS exported partition. The patches applied well to my existing 6.2-PRE source tree (I did not cvsup so as to minimize the changes to the system and prove that this fix either does or does not work for my problem.) There was minimal line fuzz, but no failures. If this works out, I'll cvsup and re-patch and test the latest sources. I'm building and installing the kernel now. Tomorrow when I'm at the office I'll try the dump again as that usually causes a lockup. Thanks for helping me solve this.
Xen under -STABLE ... ?
I know there is work being done on this for -HEAD, but does anyone know if it will run under -STABLE? I don't see a port for it, so I'm guessing not, but figured I'd ask ... Thx ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. Oh, ok, I thought so. Some questions: Do I really need acpi_video? Can I use both AGP and acpi_video at the same time? Do I need to load i915 kernel module? So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Yes. Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Ok, I understand, I'll try your patch and let you know whether it solves the problem or not. Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. It is strange though I see mouse pointer in center of the screen, but it doesn't move. As I recall it was working without moused when I first installed FreeBSD-6.1-RELEASE. I'm not quite sure, I did several updates to RELENG_6 and somewhere July it didn't work without moused loaded beforehand. Maybe it is ACPI related problem, but it is only my opinion. thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Watchdog Timeout - bge devices
$ dmesg | grep bge bge0: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 miibus1: MII bus on bge0 bge0: Ethernet address: 00:0b:cd:e7:51:ba bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP I initially pronounced the network cable dead and replaced it. Then I suspected the FastEthernet switch port and relocated to a different port. Watchdog timeouts persisted. I concluded that the bge hardware must be flaky until I read a recent thread on em device watchdog timeouts which led me to wonder about CPU scheduling. The server experiencing the bge timeouts was using SCHED_ULE. I built 6.2-PRERELEASE on a spare disk and booted the problem server from that disk - bge problem persisted. We have a second (identical) problem-free server configured with SCHED_4BSD. I reconfigured both machines so that the first machine (now 6.2-PRERELEASE) used SCHED_4BSD and the second machine (6.1-RELEASE) uses SCHED_ULE. Both machines are configured with PREEMPTION. +---+ | THE PROBLEM FOLLOWS SCHED_ULE ACROSS MACHINES | +---+ The machines are hp ProLiant ML110 servers. There is nothing sharing the interrupt with the bge device. No USB drivers are loaded. $ vmstat -i interrupt total rate irq1: atkbd0 70 0 irq6: fdc0 9 0 irq14: ata0 1234430 6 irq15: ata1 47 0 irq17: bge0 17543591 93 irq26: fxp070832 0 cpu0: timer376381765 1999 Total 395230744 2099 $ sysctl kern.version kern.sched kern.smp hw.machine hw.model dev.bge kern.version: FreeBSD 6.1-RELEASE-p10 #1: Mon Oct 2 08:36:56 AEST 2006 kern.sched.name: ule kern.sched.slice_min: 10 kern.sched.slice_max: 142 kern.sched.preemption: 1 kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 hw.machine: i386 hw.model: Intel(R) Pentium(R) 4 CPU 2.80GHz dev.bge.0.%desc: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 dev.bge.0.%driver: bge dev.bge.0.%location: slot=4 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1654 subvendor=0x103c subdevice=0x1654 class=0x02 dev.bge.0.%parent: pci4 Is there any other information I ought to post to help with diagnosis - or is this a known problem? (I've only subscribed recently) John Marshall. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog Timeout - bge devices
John Marshall wrote: $ dmesg | grep bge bge0: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 miibus1: MII bus on bge0 bge0: Ethernet address: 00:0b:cd:e7:51:ba bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP I initially pronounced the network cable dead and replaced it. Then I suspected the FastEthernet switch port and relocated to a different port. Watchdog timeouts persisted. I concluded that the bge hardware must be flaky until I read a recent thread on em device watchdog timeouts which led me to wonder about CPU scheduling. The server experiencing the bge timeouts was using SCHED_ULE. I built 6.2-PRERELEASE on a spare disk and booted the problem server from that disk - bge problem persisted. We have a second (identical) problem-free server configured with SCHED_4BSD. I reconfigured both machines so that the first machine (now 6.2-PRERELEASE) used SCHED_4BSD and the second machine (6.1-RELEASE) uses SCHED_ULE. Both machines are configured with PREEMPTION. +---+ | THE PROBLEM FOLLOWS SCHED_ULE ACROSS MACHINES | +---+ The machines are hp ProLiant ML110 servers. There is nothing sharing the interrupt with the bge device. No USB drivers are loaded. $ vmstat -i interrupt total rate irq1: atkbd0 70 0 irq6: fdc0 9 0 irq14: ata0 1234430 6 irq15: ata1 47 0 irq17: bge0 17543591 93 irq26: fxp070832 0 cpu0: timer376381765 1999 Total 395230744 2099 $ sysctl kern.version kern.sched kern.smp hw.machine hw.model dev.bge kern.version: FreeBSD 6.1-RELEASE-p10 #1: Mon Oct 2 08:36:56 AEST 2006 kern.sched.name: ule kern.sched.slice_min: 10 kern.sched.slice_max: 142 kern.sched.preemption: 1 kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 hw.machine: i386 hw.model: Intel(R) Pentium(R) 4 CPU 2.80GHz dev.bge.0.%desc: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 dev.bge.0.%driver: bge dev.bge.0.%location: slot=4 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1654 subvendor=0x103c subdevice=0x1654 class=0x02 dev.bge.0.%parent: pci4 Is there any other information I ought to post to help with diagnosis - or is this a known problem? (I've only subscribed recently) John Marshall. Very interesting data point. I wonder if this accounts for some of the inconsistency in the reporting from others. In any case, SCHED_ULE is still considered to be highly experimental. Hopefully it will get some more attention in the near future to bring it closer to production quality. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog Timeout - bge devices
On Wed, Oct 04, 2006 at 02:34:16PM +1000, John Marshall wrote: $ dmesg | grep bge bge0: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 miibus1: MII bus on bge0 bge0: Ethernet address: 00:0b:cd:e7:51:ba bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP As far as SCHED_ULE goes, if you have issues with it, use SCHED_4BSD. 4BSD is still the default, and definitely works. I've run into too many issues (in the past; maybe some have since been dealt with) with ULE, so I stick purely with 4BSD. Now, about watchdog timeouts in general -- there's a pending issue which is still under investigation. Please see this thread: http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028792.html Yes, it's long, but it does pertain to bge (despite the subject stating em). After you read it all, or most of it, you should probably partake in the convo there. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog Timeout - bge devices
Very interesting data point. I wonder if this accounts for some of the inconsistency in the reporting from others. In any case, SCHED_ULE is still considered to be highly experimental. Hopefully it will get some more attention in the near future to bring it closer to production quality. I'm not using SCHED_ULE on any of the machines that I'm seeing the timeout problem with em and fxp devices. I suspect the problem has to do with interrupt thread scheduling; maybe SCHED_ULE just somehow makes the problem worse? -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog Timeout - bge devices
David G Lawrence wrote: Very interesting data point. I wonder if this accounts for some of the inconsistency in the reporting from others. In any case, SCHED_ULE is still considered to be highly experimental. Hopefully it will get some more attention in the near future to bring it closer to production quality. I'm not using SCHED_ULE on any of the machines that I'm seeing the timeout problem with em and fxp devices. I suspect the problem has to do with interrupt thread scheduling; maybe SCHED_ULE just somehow makes the problem worse? -DG Well, the two things that will block the scheduler are critical sections and spinlocks. The system will complain about spinlocks that are held too long, but you might need WITNESS and/or INVARIANTS enabled for it. Critical section debugging is almost non-existant; the only way to do it is to turn on KTR and then feed the output to schedgraph.py. This only works reliably for UP, though. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
