Re: Big problems with 7.1 locking up :-(
> I noticed a similar problem testing 7.1-RC1, It seemed to be a deep > deadlock, as it was triggered by lighttpd doing kern_sendfile, and > never returning. The side effects (being unable to create processes, > etc) is similar. Interesting - did you get any responses from anyone else regarding this ? My last box which locked up was essentialy idle, so I am very surprised by all of this - also none of the heavilt loaded machines (i.e. the actual webservers) have locked up. I am also surprised that this isn't more widely reported, as the hardware is very common. The only oddity with ym compile is that I set the CPUTYPE to 'core2' - that shouldnt have an effect, but I will remove it anyway, just so I am actually building a completely vanilla amd64. That way I should have what everyone else has, and since I don't see anyone else saying they have isues then maybe mine will go away too (fingers crossed) > My kernconf is below, try building the kernel, and send an email > containing the backtrace from any process that has blocked (in my OK, will do. I can try this on the one non-essential box which locked up yesterday. I don't know how long it will before it locks up again, but will see if I can do some things to provoke it. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Medical database Vidal
On Fri, Jan 09, 2009 at 07:10:07PM +, Ben Morrow wrote: > I would guess that your CD has both Rock Ridge and Joliet extensions, > and that the creator has hidden the Win32-specific files from the Unix > directory tree because they thought they wouldn't be useful. If for some > reason you need to see the CD as a Win32 machine would, you can use the > -r option to mount_cd9660. Thank you very much indeed for your detailed explanation. Before searching for help I have tried out all options of mount_cd9660, one after the other and all together or so without understanding their meaning. Therefore I obviously missed the working one. `mount_cd9660 -r /dev/acd0 /cdrom' works like a charm. `wine /cdrom/setup.exe' does the job as well, unfortunately with a certain number of `err:' and `fixme:' lines. `cd path/to/VidalCD ; wine VidalCD.exe' starts the application with the same or similar error lines (which is not surprising). The programme does run, but is not really operational: It is too slow, and exiting without problems requires to type `Ctrl+Alt+Backspace' ! No time yet to see whether I am capable to fix something without further help. Harald -- FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFSv13 in RELENG7
Is any plans to backport ZFSv13 from CURRENT to RELENG7 branxh or not? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> My kernconf is below, try building the kernel, and send an email > containing the backtrace from any process that has blocked (in my Well, I havent managed to get a backtrace, but immediately upon booting the system halts with the following: http://www.twisted.org.uk/~pete/71_lor1.jpg Interestingly, if I try and boot into safe mode then it will not even get that far: http://www.twisted.org.uk/~pete/71_safe1.jpg Am going to try and backtrace that now to see what I can get. Unfortunately I can only provide screen captures rather than actual text output from this due to having to go via a Mac running RDP thought an ssh tunnel to a Windows box and then using IE to go to the iLO :-) Convoluted, but it works... -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
Walter, Thursday, January 8, 2009, 2:50:40 AM, you wrote: WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all WV> problems. I believe this roundly confirms that this is a bug in the WV> 7.1-RELEASE re kernel drivers. Does kern/130011 look similar? http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 The re driver was really broken in 7.1-RC2 and the fix didn't get to 7.1-RELEASE. -- Eugene Gladchenko EVG15-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Lock order reversals using bce in 7.1
Here is a better set of images. This machine was compiled with the following config file: include GENERIC ident DEBUG options KDB options DDB options SW_WATCHDOG options DEBUG_VFS_LOCKS options MUTEX_DEBUG options WITNESS options WITNESS_KDB options LOCK_PROFILING options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC On booting it almost immediately does this: http://www.twisted.org.uk/~pete/71_lor.png The output of trace, show pcpu, show locks, show allpcpu and show alllocks are shown in the following images: http://www.twisted.org.uk/~pete/71_locks_trace.png http://www.twisted.org.uk/~pete/71_pcpu_alllocks.png http://www.twisted.org.uk/~pete/71_allpcpu1.png http://www.twisted.org.uk/~pete/71_allpcpu2.png I am going to revent the machine back to a normal kernel now - is there anything I might be able to do to stop this, or do I need to roll everything back to 7.0 ? cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Sun, Jan 11, 2009 at 11:27 AM, Pete French wrote: >> My kernconf is below, try building the kernel, and send an email >> containing the backtrace from any process that has blocked (in my > > Well, I havent managed to get a backtrace, but immediately upon > booting the system halts with the following: > >http://www.twisted.org.uk/~pete/71_lor1.jpg Not Found ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> Not Found sorry, see the subsequent email, there are more links there to working PNG's -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
IPv6 routing on 7.1R
Hi, I noticed an odd behavior regarding IPv6 after upgrading my 7.0R box to 7.1R. The situation and symptom are the following: 1. The box has two NICs. One has an address 2001:0db8:1::1/64 (NIC A), and another has 2001:0db8:2::1/64 (NIC B). These addresses are assigned manually ($ipv6_ifconfig in rc.conf). 2. RA is periodically sent to the network 2001:0db8:1::1/64 (NIC A) by a router on the subnet. The RA includes a source link-layer address option only. When setting net.inet6.ip6.accept_rtadv=1 in this configuration, I expected the box assigns an autoconf IPv6 address (prefix 2001:0db8:1::/64 + EUI64) to NIC A and an default route based on source link-layer address in the RA packet. Actually, these two were done as expected. However, after addresses are assigned, routes for NIC B disappeared from the routing table. More specifically, a cloning route "2001:0db8:2::1/64 -> link#2" was removed for some reason. Is this an expected behavior? IIRC, 7.0R does not remove the route and I think it is strange. It works fine if a box has a single NIC, though. -- | Hiroki SATO pgpedyyIb66a2.pgp Description: PGP signature
Re: Big problems with 7.1 locking up :-(
On Sun, Jan 11, 2009 at 4:45 AM, Pete French wrote: >> I noticed a similar problem testing 7.1-RC1, It seemed to be a deep >> deadlock, as it was triggered by lighttpd doing kern_sendfile, and >> never returning. The side effects (being unable to create processes, >> etc) is similar. > > Interesting - did you get any responses from anyone else regarding > this ? My last box which locked up was essentialy idle, so I am very > surprised by all of this - also none of the heavilt loaded machines > (i.e. the actual webservers) have locked up. > > I am also surprised that this isn't more widely reported, as > the hardware is very common. The only oddity with ym compile > is that I set the CPUTYPE to 'core2' - that shouldnt have an effect, but > I will remove it anyway, just so I am actually building a completely > vanilla amd64. That way I should have what everyone else has, and since > I don't see anyone else saying they have isues then maybe mine will > go away too (fingers crossed) > >> My kernconf is below, try building the kernel, and send an email >> containing the backtrace from any process that has blocked (in my > > OK, will do. I can try this on the one non-essential box which > locked up yesterday. I don't know how long it will before it > locks up again, but will see if I can do some things to provoke it. > > -pete. Intel suggests nocona for x86_64 platforms and prescott for x86 (i386) based platforms on the 4.2 line, because they best matched the cache size and featureset of the Core2 processors. I don't think that core2 support was fully completed in 4.2 (in fact I believe it was just started), and I don't think that our binutils supports it properly. Some thoughts, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote: > Walter, > > Thursday, January 8, 2009, 2:50:40 AM, you wrote: > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all > WV> problems. I believe this roundly confirms that this is a bug in the > WV> 7.1-RELEASE re kernel drivers. > > Does kern/130011 look similar? > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 Do you have RTL8168C controller? If not, it's not related with Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > The re driver was really broken in 7.1-RC2 and the fix didn't get to > 7.1-RELEASE. If you have re(4) issues, please provide more details such as dmesg output, way to reproduce the issue etc. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [HEADS UP] drm merged to -STABLE
On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: > > If you are experiencing a "garbled" screen with certain pci/pci-e based > > radeons, I have another patch in HEAD that isn't included yet. > > I decided to go ahead and fully sync to HEAD, so this should be resolved > as well. This added: Thank you! :) bye, Uwe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mergemaster broken -- take 2
Mike Lempriere wrote: Thanks everyone for the advice -- I got it working this time just fine. Works much better when one follows the directions accurately instead of by memory -- the bottom line is that this time I remembered to jot down the commands before heading downtown to the machine rack room where there's no browser access... I started over and followed UPDATING: cd /usr/obj rm -R * cd /usr/src rm -R * cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out make buildworld |& tee /root/make-buildworld-090108.out make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out users ps ax | more shutdown -r now You can go into single user without rebooting just by issuing command: # shutdown now NOTE: Network access will be shut down also, so you should be on your console then. 4 (single user) fsck -p mount -u / mount -a cd /usr/src mergemaster -p make installworld |& tee /root/make-installworld-090108.out make delete-old (forgot to do tee redirect) mergemaster -i (did not do tee redirect) shutdown -r now Oliver Fromme wrote: Greg Byshenk wrote: > Andrei Kolu wrote: > > Mike Lempriere wrote: > > > Hi folks -- sorry to be a nag, but my main production system is barely > > > limping along on an old kernel with mismatched libraries. I have no > > > idea what else to do -- please help! > > > --- > > > I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for > > > 6-stable to 7-stable. > > > No problems with cvsup, make buildworld, make installworld, make > > > buildkernel, mergemaster -p. > > > make installkernel, boot to single user. Then mergemaster -- blammo: As others have pointed out, the order is wrong, which caused the problem Mike is seeing. The correct order is listed in /usr/src/UPDATING. > The reasons for the other methods being wrong are (as I understand them): > > - You should build your new world before building your new kernel, as > it may be the case that some aspects of the new kernel build are > dependent upon aspects of the new world build. If you build your > new kernel before building your new world, you will be building > your new kernel against the old world. In particular, building the kernel uses the new toolchain (i.e. compiler, linker, make(1) binary and so on) that was built in /usr/obj during buildworld. That's why you have to do buildworld first, then "make kernel". > - You should install your new kernel before installing your new world, > as it can be the case that some aspects of the new world will not be > understood by your old kernel. A new kernel should always be > compatible with an old userland/world, but an old kernel may not > always be compatible with a new userland/world. That's correct. Note that your kernel config should include the appropriate "options COMPAT_*" lines if you update across a major version boundary, e.g. "options_COMPAT_FREEBSD6" when you update from 6.x to 7.x. The GENERIC kernel already has those. > > NOTE: I do not reboot my system until everything is updated. Why it is > > necessary to boot new kernel and then upgrade world is beyound me..YMMW > > - I suppose that it is not strictly necessary to reboot between > installing kernel and world, but I always do so. It _is_ necessary. If you don't reboot, you're still running the old kernel which might not be able to support new binaries and libraries that installworld will install on your system. For example, there may be new syscalls that the new binaries will try to use, but the old kernel doesn't know about them. It doesn't happen often, so you can get away without rebooting most of the time. But it's risky, especially when updating across major versions. So the recommendation is to always reboot after installing the new kernel and before performing the "installworld". It's also important that "installworld" is the last step (except for mergemaster), because this is the point of no return. As long as you still have the old userland (world), you can still boot the old kernel and everything is fine. You can start all over froms cratch, if necessary. But as soon as you have started "installworld", your system will not be able to work with the old kernel anymore. And remember: Always make a backup before you start to update. And verify that the backup works. Better safe than sorry. Best regards Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Mon, Jan 12, 2009 at 09:32:20AM +0300, eug...@donpac.ru wrote: > EG>> Does kern/130011 look similar? > EG>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 > > > Do you have RTL8168C controller? If not, it's not related with > > Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > Look into kern/130011. As far as I can see I do have RTL8168C. > > EG>> The re driver was really broken in 7.1-RC2 and the fix didn't get > EG>> to 7.1-RELEASE. > > > If you have re(4) issues, please provide more details such as > > dmesg output, way to reproduce the issue etc. > > The issue is now gone but I am sorry 7.1 didn't get the fix in time. > I see, Unfortunately the issue was fixed in the end of 7.1-R release process so I wanted to get more exposure before MFC. I'll make sure to MFC to stable/7 after more testing. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mergemaster broken -- take 2
> Date: Mon, 12 Jan 2009 08:22:40 +0200 > From: Andrei Kolu > Sender: owner-freebsd-sta...@freebsd.org > > Mike Lempriere wrote: > > Thanks everyone for the advice -- I got it working this time just > > fine. Works much better when one follows the directions accurately > > instead of by memory -- the bottom line is that this time I remembered > > to jot down the commands before heading downtown to the machine rack > > room where there's no browser access... I started over and followed > > UPDATING: > > cd /usr/obj > > rm -R * > > cd /usr/src > > rm -R * > > cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out > > make buildworld |& tee /root/make-buildworld-090108.out > > make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out > > users > > ps ax | more > > shutdown -r now > You can go into single user without rebooting just by issuing command: > > # shutdown now > > NOTE: Network access will be shut down also, so you should be on your > console then. Did you even bother reading Oliver's explanation as to why it's a very bad idea. The official upgrade procedure can be modified if you know EXACTLY what you are doing, but it is unwise to suggest that you can go ahead without adequate knowledge of the risks. Please don't suggest skipping the reboot. Feel free to do so yourself, but don't expect much sympathy when an upgrade blows up and a system is down for several hours while you clean up the mess. > >> It _is_ necessary. If you don't reboot, you're still running > >> the old kernel which might not be able to support new binaries > >> and libraries that installworld will install on your system. > >> > >> For example, there may be new syscalls that the new binaries > >> will try to use, but the old kernel doesn't know about them. > >> It doesn't happen often, so you can get away without rebooting > >> most of the time. But it's risky, especially when updating > >> across major versions. So the recommendation is to always > >> reboot after installing the new kernel and before performing > >> the "installworld". > >> > >> It's also important that "installworld" is the last step > >> (except for mergemaster), because this is the point of no > >> return. As long as you still have the old userland (world), > >> you can still boot the old kernel and everything is fine. > >> You can start all over froms cratch, if necessary. > >> But as soon as you have started "installworld", your system > >> will not be able to work with the old kernel anymore. > >> > >> And remember: Always make a backup before you start to > >> update. And verify that the backup works. Better safe > >> than sorry. > >> > >> Best regards > >>Oliver > >> > >> > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > pgpsl4fTYWEIZ.pgp Description: PGP signature
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
EG>> Does kern/130011 look similar? EG>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 > Do you have RTL8168C controller? If not, it's not related with > Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. Look into kern/130011. As far as I can see I do have RTL8168C. EG>> The re driver was really broken in 7.1-RC2 and the fix didn't get EG>> to 7.1-RELEASE. > If you have re(4) issues, please provide more details such as > dmesg output, way to reproduce the issue etc. The issue is now gone but I am sorry 7.1 didn't get the fix in time. -- Eugene Gladchenko EVG15-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
