Re: RELENG_7 problem with playing DVDs
Olivier Brisson wrote: >> Using mplayer to try play a DVD my errorconsole is spammed with: >> >> ata1: FAILURE - non aligned DMA transfer attempted >> acd0: setting up DMA failed >> >> The mplayer just hangs around in physrd status and cannot be killed >> (even by >> kill -9). The error message gets posted until the system is shutdown. >> The >> mplayer process also stays alive for the whole time. The only way to >> open the >> DVD-drive after attempting to play the DVD is to reboot the system. > > It seems that you have a hardware problem. Could you please try with an other > drive? I now find your suggestion more likely. I think it might be a cable problem (both are on the same ata channel and thus use the same cable), fortunately I have some spares, so I'll exchange the cable tonight and report weather that was of any use. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 1.3G of my /var missing
Jeremy Chadwick wrote: > On Wed, Oct 24, 2007 at 08:27:10AM +0200, [LoN]Kamikaze wrote: >> df -h reports that on /var 1.5G of 1.9G are used and only 237M of free space >> remain. >> >> However doing a >> du -hd 1 /var >> >> and summing up the results I only get to less than 200M of used space, so >> there are 1.3G unaccounted for. fsck in single user mode does not recognize a >> problem. > > Try looking at tunefs(8), particularly the -m flag. That amount of > space is kept for root (the user). > As in most cases the problem was sitting between the chair and the keyboard. I simply overlooked the G when I read that /var/log contained 1.3G of data. I'm sorry for wasting the precious time of those who read or even replied with my stupidity. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 1.3G of my /var missing
Jeremy Chadwick wrote: On Wed, Oct 24, 2007 at 08:27:10AM +0200, [LoN]Kamikaze wrote: df -h reports that on /var 1.5G of 1.9G are used and only 237M of free space remain. However doing a du -hd 1 /var and summing up the results I only get to less than 200M of used space, so there are 1.3G unaccounted for. fsck in single user mode does not recognize a problem. Try looking at tunefs(8), particularly the -m flag. That amount of space is kept for root (the user). As in most cases the problem was sitting between the chair and the keyboard. I simply overlooked the G when I read that /var/log contained 1.3G of data. I'm sorry for wasting the precious time of those who read or even replied with my stupidity. Sounds like you need to make a few entries in /etc/newsyslog First thing I do when I add any new apps is give their logs a life cycle. All too quickly logs become bulky and you find /var holding it's breath. -Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
any hope for nfe/msk?
Hi, these drivers don't work under 7.0 As soon as some mild preasure is applied, they start loosing interrupts, and in my case the hosts come to a total stand-still, since they are diskless and rely on the network. This happens at 1gb and at 100mg. Maybe the problem is with the shared interrups? irq16: mskc0 uhci0 3308351 13 or irq21: nfe0 ohci01584415 24 but I have no idea how to uncouple this danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA1
On Tue, Oct 23, 2007 at 11:08:27PM +0200, Per olof Ljungmark wrote: > rihad wrote: > >How risky is it to start using 7.0-BETA1 in production, with the > >intention of upgrading to release as soon as possible? Thanks. > We've used 7-CURRENT since January on a couple of production boxes and > had very few disasters, well, none, but a couple of issues. > "Risky" is a relative term really, but if you ask me I'd say the "risk" > is rather low. > But: TEST FIRST! I concur with Per. I've been running 7-CURRENT on a couple of "production" machines for some months, without any serious problems -- but these are not mission-critical machines. Risk is a relative thing, and it is relative to both the risk of failure and the cost of that failure should it occur. I have 7- running on one fileserver that is used only by our IT group (for online copies of distfiles and other installable software), meaning that if something should go horribly wrong, it would be an annoyance, but not a disaster. The same could _not_ be said about our central user fileservers, and so they do not run 7-. I could also note that I've been running 7-CURRENT on my own workstation (including X, but only fvwm2 and nothing too fancy) for about 6 months, and have experienced no serious problems (though I have swapped out SCHED_4BSD for SCHED_ULE due to poor interactivity with 4BSD). And I also emphasise: TEST FIRST! My situation is not the same as yours, and something that works fine in my environment may break horribly in yours. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
On Wed, Oct 24, 2007 at 09:33:48AM +0200, Danny Braniss wrote: > Hi, > these drivers don't work under 7.0 > As soon as some mild preasure is applied, they start loosing interrupts, and > in my case the hosts come to a total stand-still, since they are diskless > and rely on the network. > This happens at 1gb and at 100mg. > > Maybe the problem is with the shared interrups? > > irq16: mskc0 uhci0 3308351 13 > or > irq21: nfe0 ohci01584415 24 > > but I have no idea how to uncouple this > If you see watchdog timeout errors on your console, shared interrupt would be culprit. For msk(4) set hw.msk.legacy_intr="1" in loader.conf or use kenv(1) to set it before loading msk(4) kernel module. For nfe(4) you can switch to polling(4). -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA1
Greg Byshenk wrote: On Tue, Oct 23, 2007 at 11:08:27PM +0200, Per olof Ljungmark wrote: rihad wrote: How risky is it to start using 7.0-BETA1 in production, with the intention of upgrading to release as soon as possible? Thanks. We've used 7-CURRENT since January on a couple of production boxes and had very few disasters, well, none, but a couple of issues. "Risky" is a relative term really, but if you ask me I'd say the "risk" is rather low. My question was more a theoretical one: it's called BETA for some reason, otherwise it'd still be in HEAD. To me BETA means that no major architectural changes are expected in it any more, no? But: TEST FIRST! I concur with Per. I've been running 7-CURRENT on a couple of "production" machines for some months, without any serious problems -- but these are not mission-critical machines. Our machine-to-be is quite mission-critical... But if I start with the latest 6.x release, it would be more difficult to migrate to 7.0 when it comes out than if I start with 7.0-BETA?. I've known people running 4-STABLE or 5-STABLE branches on mission-critical machines, without even bothering to upgrade, but I think they're stress-testing their luck ;-) So I don't want to join their camp, that's why I asked for advice ;-) Again it's named BETA for a reason, so it could be less intrusive than STABLE?.. I will definitely start with beta if it reaches BETA2 in a week or two - the time I got ;-) Thanks for advice. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA1
On Wed, Oct 24, 2007 at 02:00:42PM +0500, rihad wrote: > >>rihad wrote: > >>>How risky is it to start using 7.0-BETA1 in production, with the > >>>intention of upgrading to release as soon as possible? Thanks. > My question was more a theoretical one: it's called BETA for some > reason, otherwise it'd still be in HEAD. To me BETA means that no major > architectural changes are expected in it any more, no? Yes, but it doesn't mean that there can't be undiscovered bugs that could cause problems. > Our machine-to-be is quite mission-critical... But if I start with the > latest 6.x release, it would be more difficult to migrate to 7.0 when it > comes out than if I start with 7.0-BETA?. I've known people running > 4-STABLE or 5-STABLE branches on mission-critical machines, without even > bothering to upgrade, but I think they're stress-testing their luck ;-) > So I don't want to join their camp, that's why I asked for advice ;-) > Again it's named BETA for a reason, so it could be less intrusive than > STABLE?.. > I will definitely start with beta if it reaches BETA2 in a week or two - > the time I got ;-) Thanks for advice. Well, if it is a "machine-to-be", then I suspect that you should be safe in starting with 7.0-BETA. First, there don't appear to be any serious problems with it, and second, if it is a new build "machine-to-be", then you will have the opportunity to do the testing required to ensure that there are no problems (in your situation) prior to rollout. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] 8-CURRENT, RELENG_7 and RELENG_6 have gotten latest ?unionfs improvements
[Note: stripped excessive Cc.] Dmitry Marakasov <[EMAIL PROTECTED]> wrote: > Btw, I was wondering: is unionfs related in any way with -ounion > option of mount_*? No. The union mount option (-o union) is completely separate from UNIONFS, although it can be used to achieve a somewhat similar effect. It depends on your requirements whether it is sufficient or not. > I was told long time ago that -ounion is even > more broken than unionfs. That's wrong. The union mount option was _never_ really broken. I'm using it for almost as long as FreeBSD exists. However UNIONFS was broken for a long time (along with NULLFS and UMAPFS). NULLFS has been fixed some time ago, UMAPFS was abandoned apparently, i.e. nobody showed up to fix it, and UNIONFS was pretty much completely overhauled by Daichi GOTO and his team. I would now regard it as stable. > Though, those two features seem to do very > similar thing and I think that -ounion option is pretty useful. Yes, it is useful. The biggest differences are: - The union mount option newly mounts a filesystem on top of an arbitrary existing directory tree, while UNIONFS mounts another representation of one existing directory tree on top of another one. That means UNIONFS does the same as NULLFS, but unlike NULLFS it does not hide the underlying directory tree. - When using the union mount option, only the entries in the root directory show through from the "lower" file system. When using UIONFS, _all_ entries in _all_ directories are visible (unless masked by an identical entry in the upper file system, of course). - The implementation of the union mount option is rather simple has rather low overhead. UNIONFS is much more complex and has some overhead for certain operations, especially when files and directories have to be created automatically in the upper layer. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 1.3G of my /var missing
Clayton Milos wrote: >> Jeremy Chadwick wrote: >>> On Wed, Oct 24, 2007 at 08:27:10AM +0200, [LoN]Kamikaze wrote: ... and summing up the results I only get to less than 200M of used space, so there are 1.3G unaccounted for. fsck in single user mode does not recognize a problem. >>> >>> Try looking at tunefs(8), particularly the -m flag. That amount of >>> space is kept for root (the user). >>> >> >> As in most cases the problem was sitting between the chair and the >> keyboard. I >> simply overlooked the G when I read that /var/log contained 1.3G of data. >> >> I'm sorry for wasting the precious time of those who read or even >> replied with >> my stupidity. > > Sounds like you need to make a few entries in /etc/newsyslog > First thing I do when I add any new apps is give their logs a life cycle. > All too quickly logs become bulky and you find /var holding it's breath. > > -Clay The problem was messages, and it's related with my DVD troubles which spammed the log with DMA errors. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA1
rihad <[EMAIL PROTECTED]> wrote: > My question was more a theoretical one: it's called BETA for some > reason, otherwise it'd still be in HEAD. To me BETA means that no major > architectural changes are expected in it any more, no? That's correct. In theory, if BETA had no bugs (and no new ones are discovered during the beta/rc phase), the exact same code would probably become the RELEASE. Of course, in practice there are always bugs. > > > But: TEST FIRST! > > > > I concur with Per. Me too. > > I've been running 7-CURRENT on a couple of "production" > > machines for some months, without any serious problems -- but these are not > > mission-critical machines. I've updated a production machine from 6-stable to 7-stable last week, without any issues. It was even a remote update without console access, which presented a certain risk. But all went well (and I had backups, of course). > Our machine-to-be is quite mission-critical... But if I start with the > latest 6.x release, it would be more difficult to migrate to 7.0 when it > comes out than if I start with 7.0-BETA?. Not necessarily. The update from 6-stable to 7-stable was just as easy as an update within the 6-stable branch. It was just the usual buildworld, kernel, mergemaster dance. Nothing special at all, except that mergemaster took a little longer because there were more differences, and I had to do a few edits to the kernel config (enable the new scheduler). But you have to do that anyway, whether you go for 7.x now or later. > Again it's named BETA for a reason, so it could be less intrusive than > STABLE?.. BETA means it is on its way to the RELEASE (with some RCs in between, i.e. release candidates). It means that no architectural changes are made (those usually only happen in -current anyway), and no major new features, only fixes. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 1.3G of my /var missing
> Clayton Milos wrote: > >> Jeremy Chadwick wrote: > >>> On Wed, Oct 24, 2007 at 08:27:10AM +0200, [LoN]Kamikaze wrote: > ... > > and summing up the results I only get to less than 200M of used > space, so > there are 1.3G unaccounted for. fsck in single user mode does not > recognize a > problem. > >>> > >>> Try looking at tunefs(8), particularly the -m flag. That amount of > >>> space is kept for root (the user). > >>> > >> > >> As in most cases the problem was sitting between the chair and the > >> keyboard. I > >> simply overlooked the G when I read that /var/log contained 1.3G of data. > >> > >> I'm sorry for wasting the precious time of those who read or even > >> replied with > >> my stupidity. > > > > Sounds like you need to make a few entries in /etc/newsyslog > > First thing I do when I add any new apps is give their logs a life cycle. > > All too quickly logs become bulky and you find /var holding it's breath. > > > > -Clay > > The problem was messages, and it's related with my DVD troubles which spammed > the log with DMA errors. If you let the tools do their jobs you won't get silly errors like that. Both du and df default to returning 1k blocks. You will note that the usage figure is identical by both methods. Mark drugs# du -s /var 404806 /var drugs# df /var Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s4d 2004526 404806 143935822%/var drugs# -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [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: [EMAIL PROTECTED]: cvs commit: src/crypto/openssl/ssl ?d1_both.c ?dtls1.h ssl.h ssl_err.c]
Ken Smith wrote: > Oliver Fromme wrote: > > Uhm, are you sure? In the past, whenever a new RELENG > > branch was created, it was implicitly the next -stable > > branch, because -current moved on to the next version > > number. Did that policy change? > > It is implicitly the *next* -stable but it's not there yet. That's > what Simon was saying. > > FreeBSD's development (specifically the CVS repository) is public. > But the bottom line is that the RELENG_X branches are *development* > branches. I'm well aware of that. My question was only about naming conventions. People often talk about either "-current" and "-stable", so was curious what RELENG_7 would be called right now. Obviously it's not called "-current", but (according to you and Simon) it's not called "-stable" either. Actually the often used terms "-current" and "-stable" are ambiguous and not really accurate. E.g. someone talks about "the -stable branch" and you have no idea which one of the several RELENG_* ones he means. It's probably better to always use the CVS names or the branch name (from sys/conf/newvers.sh). > No change in any policies or anything like that. What I'm describing > has been the status quo for a long time but people tend to forget or > never quite "get it" or ... so I'm sure you're not the only one thinking > this way. I'm not thinking that way. :-) I do know very well that the -stable branches are development branches. Although in pre-4.0 days (when release branches didn't exist) -stable had a slightly different meaning, but it has really been a long time since then. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA1 Available, 6.3-BETA1 coming soon...
On Mon, 2007-10-22 at 22:21 -0400, Ken Smith wrote: > We have entered the final phases of the FreeBSD-7.0 Release cycle which > also means the beginning of the FreeBSD-6.3 Release cycle. Because the > people who support the ports for FreeBSD also need to go through a > freeze cycle as part of releases we had decided to combine the two > releases to try and minimize the impact on the ports maintainers. [...snip...] I upgraded with CVSup. It works fine. I'll wait for -RELEASE. [EMAIL PROTECTED]:~> uname -v FreeBSD 7.0-BETA1 #3: Wed Oct 24 00:58:37 KST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC [EMAIL PROTECTED]:~> Thanks! -- Byung-Hee HWANG * InZealBomb "You know who I am?" -- Vito Corleone, "Chapter 1", page 52 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supermicro X7DBR-8+ hang at boot
John Baldwin wrote: On Tuesday 23 January 2007 01:17:57 pm Guy Helmer wrote: Jack Vogel wrote: On 1/23/07, Guy Helmer <[EMAIL PROTECTED]> wrote: Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ motherboard (dual Xeon 5130 CPUs on the Blackford chipset - http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) hanging after printing the "Waiting 5 seconds for SCSI devices to settle" message. The hang doesn't always happen - sometimes we have to go through several reboot cycles for it to happen - but sometimes it happens with every reboot. For those who would suggest that this happens because I'm using Seagate drives, it happens even if we totally remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit ethernet NICs aren't found but the hang doesn't occur. ... If that isnt it, I would suggest installing using ACPI disabled or SAFE if needed, and then tweak the kernel after. hint.apic.0.disabled=1 helped - it hasn't hung yet in several boot cycles. New dmesg is attached below in case it helps anyone see a better fix than disabling the APICs. So you got an interrupt storm on IRQ 18 when ahd0 tried to probe and ahd0 got interrupt timeouts. This indicates that ahd0 really lives on IRQ 18, not IRQ 30. Your BIOS is likely busted since ACPI hardcodes these sort of IRQs. You can override the BIOS by doing: set hw.pci5.2.INTA.irq=18 in the loader (or adding a line to loader.conf) and seeing if that fixes the boot with APIC enabled. I'm trying to resolve what looks like a similar problem with an IBM Blade Server unit. I'm reviewing my previous emails on this subject with the verbose boot messages to try to learn what lead you to determine the correct interrupt would be 18, but I can't seem to figure out what data leads to this conclusion. Any hints? Thanks, Guy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 1.3G of my /var missing
NCDU.. http://www.freshports.org/sysutils/ncdu/ is your friend ;-)) > >> > >> As in most cases the problem was sitting between the chair and the > >> keyboard. I > >> simply overlooked the G when I read that /var/log contained 1.3G of > data. > >> > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can I do 6.1-RELEASE to 6.2 via cvsup
> > > Also, the list of things to do is a bit mis-ordered and truncated. The > > > official list is in /usr/src/UPDATING and reads: > > > > > > > > > make buildworld > > > make kernel KERNCONF=YOUR_KERNEL_HERE > > > [1] > > > [3] > > > mergemaster -p [5] > > > make installworld > > > make delete-old > > > > > ^ Where in /usr/src/UPDATING is that command. I > > can't see it. > > > > > > mergemaster [4] > > > > > > > > > Thanks, Tuc > > > > Sorry. It is there on my 6-Stable system, but it looks like it is not in > 6.2-Release.It's been in HEAD for over 2 years. > > I am a bit confused,though. I see my 6.2-Stable has src/UPDATING,v > 1.416.2.35, but I can't find that version in CVS. I see only one commit, > 1.416, in RELENG_6 and I know that it has had more commits since then. > Um, I went to go check the file on a 7.0-BETA1 I just installed and and doing the ground up on.. And I just realized something... WHERE is the step to install the kernel?? I always thought it was : make buildworld make kernel KERNCONF=YOUR_KERNEL_HERE make installkernel KERNCONF=YOUR_KERNEL_HERE [1] [3] Tuc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can I do 6.1-RELEASE to 6.2 via cvsup
On Wed, Oct 24, 2007 at 11:18:30AM -0400, Tuc at T-B-O-H.NET wrote: > > > > Also, the list of things to do is a bit mis-ordered and truncated. The > > > > official list is in /usr/src/UPDATING and reads: > > > > > > > > > > > > make buildworld > > > > make kernel KERNCONF=YOUR_KERNEL_HERE > > > > [1] > > > > [3] > > > > mergemaster -p [5] > > > > make installworld > > > > make delete-old > Um, I went to go check the file on a 7.0-BETA1 I just installed and and > doing the ground > up on.. And I just realized something... > > WHERE is the step to install the kernel?? I always thought it was : > > make buildworld > make kernel KERNCONF=YOUR_KERNEL_HERE > make installkernel KERNCONF=YOUR_KERNEL_HERE > [1] > [3] Pay attention to the make options (you can find them in /usr/src/Makefile). 'make kernel' is equivalent to 'make buildkernel + installkernel', just like 'make world' is equivalent to 'make buildworld + installworld'. The latter can be dangerous, but the former usually isn't. One process is: [csup, etc.] make buildworld make buildkernel make installkernel [reboot single user] [mergemaster -p if necessary] make installworld mergemaster [reboot] [ports or other stuff] If you wish, the 'make buildkernel' + 'make installkernel' can be replaced with 'make kernel', which does them both in sequence with one command. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can I do 6.1-RELEASE to 6.2 via cvsup
> From: "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> > Date: Wed, 24 Oct 2007 11:18:30 -0400 (EDT) > > > > > Also, the list of things to do is a bit mis-ordered and truncated. The > > > > official list is in /usr/src/UPDATING and reads: > > > > > > > > > > > > make buildworld > > > > make kernel KERNCONF=YOUR_KERNEL_HERE > > > > [1] > > > > [3] > > > > mergemaster -p [5] > > > > make installworld > > > > make delete-old > > > > > > > ^ Where in /usr/src/UPDATING is that command. I > > > can't see it. > > > > > > > > mergemaster [4] > > > > > > > > > > > > > Thanks, Tuc > > > > > > > Sorry. It is there on my 6-Stable system, but it looks like it is not in > > 6.2-Release.It's been in HEAD for over 2 years. > > > > I am a bit confused,though. I see my 6.2-Stable has src/UPDATING,v > > 1.416.2.35, but I can't find that version in CVS. I see only one commit, > > 1.416, in RELENG_6 and I know that it has had more commits since then. > > > Um, I went to go check the file on a 7.0-BETA1 I just installed and and > doing the ground > up on.. And I just realized something... > > WHERE is the step to install the kernel?? I always thought it was : > > > make buildworld > make kernel KERNCONF=YOUR_KERNEL_HERE > make installkernel KERNCONF=YOUR_KERNEL_HERE > [1] > [3] > 'make kernel' makes buildworld and then makes installkernel. So 'make kernel' both builds and installs the kernel. 'make kernel' is not new (goes back to at least V4), but was not placed in the UPDATING file until V7. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgphNTwWm2Skv.pgp Description: PGP signature
Re: any hope for nfe/msk?
Pyun YongHyeon wrote: On Wed, Oct 24, 2007 at 09:33:48AM +0200, Danny Braniss wrote: > Hi, > these drivers don't work under 7.0 > As soon as some mild preasure is applied, they start loosing interrupts, and > in my case the hosts come to a total stand-still, since they are diskless > and rely on the network. > This happens at 1gb and at 100mg. > > Maybe the problem is with the shared interrups? > > irq16: mskc0 uhci0 3308351 13 > or > irq21: nfe0 ohci01584415 24 > > but I have no idea how to uncouple this > If you see watchdog timeout errors on your console, shared interrupt would be culprit. For msk(4) set hw.msk.legacy_intr="1" in loader.conf or use kenv(1) to set it before loading msk(4) kernel module. For nfe(4) you can switch to polling(4). I have some msk troubles too. On my laptop (acer travelmate 2483wxmi) under heavy cpu & network load msk periodically stops working for few minutes. sysctl -a|grep msk <118>msk0: no link ... <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67 <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67 <118>DHCPDISCOVER on msk0 to 255.255.255.255 port 67 interval 3 <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67 <118>msk0: flags=8843 metric 0 mtu 1500 msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: Rx FIFO overrun! msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering dev.mskc.0.%desc: Marvell Yukon 88E8038 Gigabit Ethernet dev.mskc.0.%driver: mskc dev.mskc.0.%location: slot=0 function=0 dev.mskc.0.%pnpinfo: vendor=0x11ab device=0x4352 subvendor=0x1025 subdevice=0x0110 class=0x02 dev.mskc.0.%parent: pci2 dev.mskc.0.process_limit: 128 dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01 dev.msk.0.%driver: msk dev.msk.0.%parent: mskc0 dev.miibus.0.%parent: msk0 Not sure if it is connected to previous issue. uname -a FreeBSD tdevil.lomaka.org.ua 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Mon Oct 22 18:32:01 EEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TDEVIL-7.kernconf i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can I do 6.1-RELEASE to 6.2 via cvsup
> > WHERE is the step to install the kernel?? I always thought it was : > > > > > > make buildworld > > make kernel KERNCONF=YOUR_KERNEL_HERE > > make installkernel KERNCONF=YOUR_KERNEL_HERE > > [1] > > [3] > > > > 'make kernel' makes buildworld and then makes installkernel. So 'make > kernel' both builds and installs the kernel. > > 'make kernel' is not new (goes back to at least V4), but was not placed > in the UPDATING file until V7. > SORRY My bad. I was reading too fast.. I normally do "buildkernel" then "installkernel", and was too use to doing it via 2 lines. Tuc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
Robert Watson wrote: > On Sat, 20 Oct 2007, Alfred Perlstein wrote: > > >>This is my feeling also -- I would consider ABI breakage a show stopper > >>for 6.x, but feel otherwise that the new code is much more mature and > >>capable and would be quite beneficial to people building appliances and > >>related products on 6.x. You might check with Attilio about whether there > >>are any remaining outstanding issues that need to be resolved first, and > >>make sure to send a heads up out on stable@ and put a note in UPDATING > >>that the option and details have changed. > > > >I still get confused as to the meaning of this... > > > >It only breaks ABI when it's enabled. > > > >I think that is OK, right? > > As we're eliminating MUTEX_PROFILING and replacing it with LOCK_PROFILING, > I think it is OK that the ABI for one differs from the other as long as the > base kernel ABI remains static. I.e., this seems OK to me also. If -stable will have LOCK_PROFILING, it'd be really nice to have it compatible with a standard world in some way, even if just with a makefile hack that builds netstat_lp(1) in addition to netstat(1) (and other utilities.) One can easily boot a diskless email, web, or name server into kernels with other debug-type options without maintaining multiple worlds. One might want to run a LOCK_PROFILING stable kernel on a diskless email server for a period of time, but that will require either a matching world, or putting up with breakage for that period of time, neither of which is a fair expectation in a stable environment, IMO. I can maintain local makefile hacks for production if somebody with some makefile foo gets me started. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
On Sunday 21 October 2007 04:56:30 am Kris Kennaway wrote: > Alfred Perlstein wrote: > > * Robert Watson <[EMAIL PROTECTED]> [071020 10:21] wrote: > >> On Sat, 20 Oct 2007, Kris Kennaway wrote: > >> > >>> Alfred Perlstein wrote: > Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, > this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 > to FreeBSD-6. > > Do we want this? > > I'd like to do it if people want it. > >>> I think it should be done, performance is a lot better than the old 6.x > >>> version and it also adds another very useful performance metric (time > >>> spent waiting for the lock). The only concern is that it doesn't break > >>> ABI support when not compiled in, but I'm pretty sure you've already told > >>> me this is OK. Thanks for looking at this. > >> This is my feeling also -- I would consider ABI breakage a show stopper for > >> 6.x, but feel otherwise that the new code is much more mature and capable > >> and would be quite beneficial to people building appliances and related > >> products on 6.x. You might check with Attilio about whether there are any > >> remaining outstanding issues that need to be resolved first, and make sure > >> to send a heads up out on stable@ and put a note in UPDATING that the > >> option and details have changed. > > > > I still get confused as to the meaning of this... > > > > It only breaks ABI when it's enabled. > > > > I think that is OK, right? > > > > Yes, that is fine. Other existing debugging options also break ABI when > enabled, so it's OK. Well, MUTEX_PROFILING does and LOCK_PROFILING is the same thing. This option is a known "special case" that breaks the ABI and people using it should already be aware of that. Other debugging options (INVARIANTS, WITNESS, etc.) do not affect the ABI. -- 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: Supermicro X7DBR-8+ hang at boot
On Wednesday 24 October 2007 09:49:06 am Guy Helmer wrote: > John Baldwin wrote: > > On Tuesday 23 January 2007 01:17:57 pm Guy Helmer wrote: > > > >> Jack Vogel wrote: > >> > >>> On 1/23/07, Guy Helmer <[EMAIL PROTECTED]> wrote: > >>> > Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ > motherboard (dual Xeon 5130 CPUs on the Blackford chipset - > http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) > > hanging after printing the "Waiting 5 seconds for SCSI devices to > settle" message. The hang doesn't always happen - sometimes we have to > go through several reboot cycles for it to happen - but sometimes it > happens with every reboot. For those who would suggest that this > happens because I'm using Seagate drives, it happens even if we totally > remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) > and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit > ethernet NICs aren't found but the hang doesn't occur. > > >>> ... > >>> If that isnt it, I would suggest installing using ACPI disabled or > >>> SAFE if > >>> needed, and then tweak the kernel after. > >>> > >> hint.apic.0.disabled=1 helped - it hasn't hung yet in several boot > >> cycles. New dmesg is attached below in case it helps anyone see a > >> better fix than disabling the APICs. > >> > > > > So you got an interrupt storm on IRQ 18 when ahd0 tried to probe and ahd0 got > > interrupt timeouts. This indicates that ahd0 really lives on IRQ 18, not IRQ > > 30. Your BIOS is likely busted since ACPI hardcodes these sort of IRQs. > > > > You can override the BIOS by doing: > > > > set hw.pci5.2.INTA.irq=18 > > > > in the loader (or adding a line to loader.conf) and seeing if that fixes the > > boot with APIC enabled. > > > > > I'm trying to resolve what looks like a similar problem with an IBM > Blade Server unit. I'm reviewing my previous emails on this subject > with the verbose boot messages to try to learn what lead you to > determine the correct interrupt would be 18, but I can't seem to figure > out what data leads to this conclusion. Any hints? He got an interrupt storm on IRQ 18 while the ahd0 device on IRQ 30 was timing out. -- 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: LOCK_PROFILING in -stable
John Baldwin wrote: On Sunday 21 October 2007 04:56:30 am Kris Kennaway wrote: Alfred Perlstein wrote: * Robert Watson <[EMAIL PROTECTED]> [071020 10:21] wrote: On Sat, 20 Oct 2007, Kris Kennaway wrote: Alfred Perlstein wrote: Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 to FreeBSD-6. Do we want this? I'd like to do it if people want it. I think it should be done, performance is a lot better than the old 6.x version and it also adds another very useful performance metric (time spent waiting for the lock). The only concern is that it doesn't break ABI support when not compiled in, but I'm pretty sure you've already told me this is OK. Thanks for looking at this. This is my feeling also -- I would consider ABI breakage a show stopper for 6.x, but feel otherwise that the new code is much more mature and capable and would be quite beneficial to people building appliances and related products on 6.x. You might check with Attilio about whether there are any remaining outstanding issues that need to be resolved first, and make sure to send a heads up out on stable@ and put a note in UPDATING that the option and details have changed. I still get confused as to the meaning of this... It only breaks ABI when it's enabled. I think that is OK, right? Yes, that is fine. Other existing debugging options also break ABI when enabled, so it's OK. Well, MUTEX_PROFILING does and LOCK_PROFILING is the same thing. This option is a known "special case" that breaks the ABI and people using it should already be aware of that. Other debugging options (INVARIANTS, WITNESS, etc.) do not affect the ABI. DEBUG_VFS_LOCKS and/or DEBUG_LOCKS also break the ABI. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
* Skip Ford <[EMAIL PROTECTED]> [071024 10:47] wrote:
> Robert Watson wrote:
> > On Sat, 20 Oct 2007, Alfred Perlstein wrote:
> >
> > >>This is my feeling also -- I would consider ABI breakage a show stopper
> > >>for 6.x, but feel otherwise that the new code is much more mature and
> > >>capable and would be quite beneficial to people building appliances and
> > >>related products on 6.x. You might check with Attilio about whether there
> > >>are any remaining outstanding issues that need to be resolved first, and
> > >>make sure to send a heads up out on stable@ and put a note in UPDATING
> > >>that the option and details have changed.
> > >
> > >I still get confused as to the meaning of this...
> > >
> > >It only breaks ABI when it's enabled.
> > >
> > >I think that is OK, right?
> >
> > As we're eliminating MUTEX_PROFILING and replacing it with LOCK_PROFILING,
> > I think it is OK that the ABI for one differs from the other as long as the
> > base kernel ABI remains static. I.e., this seems OK to me also.
>
> If -stable will have LOCK_PROFILING, it'd be really nice to have
> it compatible with a standard world in some way, even if just with
> a makefile hack that builds netstat_lp(1) in addition to
> netstat(1) (and other utilities.)
>
> One can easily boot a diskless email, web, or name server into
> kernels with other debug-type options without maintaining
> multiple worlds. One might want to run a LOCK_PROFILING stable
> kernel on a diskless email server for a period of time, but
> that will require either a matching world, or putting up with
> breakage for that period of time, neither of which is a fair
> expectation in a stable environment, IMO.
>
> I can maintain local makefile hacks for production if somebody
> with some makefile foo gets me started.
This is really beyond the scope of what I have time for however
I can say that probably all that is needed is a Makefile that
uses something like a makefile in a directory next to netstat
called netstat_lp and either duplicate the makefile and add:
SRCDIR= ${.CURDIR}/netstat
CFLAGS+=-DLOCKPROFILING
or like make the netstat directory have a "Makefile.netstat.inc" in it
with the common parts and have both Makefiles for netstat and netstat_lp
include it. in fact you could hack netstat to exec netstat_lp if the
sysctls indicating lockprofiling is enabled... e. :)
good luck!
--
- Alfred Perlstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: cvs commit: src/crypto/openssl/ssl ?d1_both.c ?dtls1.h ssl.h ssl_err.c]
On Wed, 24 Oct 2007, Oliver Fromme wrote: People often talk about either "-current" and "-stable", so was curious what RELENG_7 would be called right now. Obviously it's not called "-current", but (according to you and Simon) it's not called "-stable" either. I have been making an effort in the recent past to refer to the branches by their branch names (RELENG_*) to avoid confusion. I am also of the mind that we should have mailing lists named after the branches as well, rather than going through the awkward transitions that you describe in this post. (Which is a long-winded way to say that I think your confusion is justified and understandable.) I think this is going to be more prevalent in the time-based release world since we will soon have 3 different RELENG branches that could reasonably be called "-stable". Actually the often used terms "-current" and "-stable" are ambiguous and not really accurate. E.g. someone talks about "the -stable branch" and you have no idea which one of the several RELENG_* ones he means. It's probably better to always use the CVS names or the branch name (from sys/conf/newvers.sh). Voila! GMTA :) Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
On Wednesday 24 October 2007 03:44:52 pm Kris Kennaway wrote: > John Baldwin wrote: > > On Sunday 21 October 2007 04:56:30 am Kris Kennaway wrote: > >> Alfred Perlstein wrote: > >>> * Robert Watson <[EMAIL PROTECTED]> [071020 10:21] wrote: > On Sat, 20 Oct 2007, Kris Kennaway wrote: > > > Alfred Perlstein wrote: > >> Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, > >> this means I can relatively easily backport LOCK_PROFILING from > > FreeBSD-7 > >> to FreeBSD-6. > >> > >> Do we want this? > >> > >> I'd like to do it if people want it. > > I think it should be done, performance is a lot better than the old 6.x > > version and it also adds another very useful performance metric (time > > spent waiting for the lock). The only concern is that it doesn't break > > ABI support when not compiled in, but I'm pretty sure you've already > > told > > me this is OK. Thanks for looking at this. > This is my feeling also -- I would consider ABI breakage a show stopper > > for > 6.x, but feel otherwise that the new code is much more mature and capable > and would be quite beneficial to people building appliances and related > products on 6.x. You might check with Attilio about whether there are any > remaining outstanding issues that need to be resolved first, and make > > sure > to send a heads up out on stable@ and put a note in UPDATING that the > option and details have changed. > >>> I still get confused as to the meaning of this... > >>> > >>> It only breaks ABI when it's enabled. > >>> > >>> I think that is OK, right? > >>> > >> Yes, that is fine. Other existing debugging options also break ABI when > >> enabled, so it's OK. > > > > Well, MUTEX_PROFILING does and LOCK_PROFILING is the same thing. This option > > is a known "special case" that breaks the ABI and people using it should > > already be aware of that. Other debugging options (INVARIANTS, WITNESS, > > etc.) do not affect the ABI. > > > > DEBUG_VFS_LOCKS and/or DEBUG_LOCKS also break the ABI. True, but those are the exception rather than the rule. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12 on 7.0-BETA1 i386
Hello,
I just had a kernel panic using BETA1. According to the Developer
Handbook Kernel Debugging, I'm supplying the following information in
hopes that it is useful. Please note: I'm not familiar with this
process so you need more data, just ask:
kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x9006004
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc079c961
stack pointer = 0x28:0xe74a7bcc
frame pointer = 0x28:0xe74a7be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 46 (ath0 taskq)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 4h9m30s
Physical memory: 3435 MB
Dumping 214 MB: ...
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc079c961
0xc079c961 is in mb_free_ext (/usr/src/sys/kern/uipc_mbuf.c:226).
221 * check if the header is embedded in the cluster
222 */
223 skipmbuf = (m->m_flags & M_NOFREE);
224
225 /* Free attached storage if this mbuf is the only
reference to it. */
226 if (*(m->m_ext.ref_cnt) == 1 ||
227 atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 1) {
228 switch (m->m_ext.ext_type) {
229 case EXT_PACKET:/* The packet zone is
special. */
230 if (*(m->m_ext.ref_cnt) == 0)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12 on 7.0-BETA1 i386
Doug Poland wrote:
Hello,
I just had a kernel panic using BETA1. According to the Developer
Handbook Kernel Debugging, I'm supplying the following information in
hopes that it is useful. Please note: I'm not familiar with this
process so you need more data, just ask:
kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x9006004
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc079c961
stack pointer = 0x28:0xe74a7bcc
frame pointer = 0x28:0xe74a7be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 46 (ath0 taskq)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 4h9m30s
Physical memory: 3435 MB
Dumping 214 MB: ...
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc079c961
0xc079c961 is in mb_free_ext (/usr/src/sys/kern/uipc_mbuf.c:226).
221 * check if the header is embedded in the cluster
222 */
223 skipmbuf = (m->m_flags & M_NOFREE);
224
225 /* Free attached storage if this mbuf is the only
reference to it. */
226 if (*(m->m_ext.ref_cnt) == 1 ||
227 atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 1) {
228 switch (m->m_ext.ext_type) {
229 case EXT_PACKET:/* The packet zone is
special. */
230 if (*(m->m_ext.ref_cnt) == 0)
Almost :)
What does 'bt' show in kgdb?
Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Installworld broken on RELENG_6 by libc commit?
Hello, My installworld of RELENG_6 from a few hours ago failed with this error (from memory): /lib/libncurses.so.6: undefined symbol: __mb_sb_limit This broke everything that depended on libncurses, plus PAM. I had to force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to /lib using binaries from /rescue to fix it so I could run make installworld again. I upgraded from RELENG_6 of October, 22. I believe I followed the procedure from /usr/src/UPDATING fairly closely, except for the reboot to single user part after installing the kernel: mergemaster -p && make buildworld && make kernel && make installworld && mergemaster && make delete-old I would expect libc to be installed before other libs. The securelevel was -1, so it should be no problem to overwrite libc. Did I do something wrong or is this a bug/missing entry in UPDATING? regards, Alson The csup output since my last make world: -- >>> Running /usr/bin/csup -- Parsing supfile "/usr/share/examples/cvsup/stable-supfile" Connecting to cvsup3.nl.freebsd.org Connected to 62.250.3.15 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Edit src/include/_ctype.h Add delta 1.30.2.1 2007.10.24.14.32.32 rafan Edit src/include/ctype.h Add delta 1.28.8.1 2007.10.24.14.32.32 rafan Edit src/lib/libc/locale/big5.c Add delta 1.17.2.1 2007.10.24.14.32.32 rafan Edit src/lib/libc/locale/euc.c Add delta 1.21.2.1 2007.10.24.14.32.32 rafan Edit src/lib/libc/locale/gb18030.c Add delta 1.7.2.1 2007.10.24.14.32.32 rafan Edit src/lib/libc/locale/gb2312.c Add delta 1.9.2.1 2007.10.24.14.32.33 rafan Edit src/lib/libc/locale/gbk.c Add delta 1.12.2.1 2007.10.24.14.32.33 rafan Edit src/lib/libc/locale/isctype.c Add delta 1.9.14.1 2007.10.24.14.32.33 rafan Edit src/lib/libc/locale/mskanji.c Add delta 1.17.2.1 2007.10.24.14.32.33 rafan Edit src/lib/libc/locale/none.c Add delta 1.13.2.1 2007.10.24.14.32.33 rafan Edit src/lib/libc/locale/setrunelocale.c Add delta 1.45.2.1 2007.10.24.14.32.33 rafan Edit src/lib/libc/locale/utf8.c Add delta 1.13.2.2 2007.10.24.14.32.33 rafan Edit src/lib/libstand/Makefile Add delta 1.54.2.1 2007.10.24.11.50.06 nyan Edit src/release/Makefile Add delta 1.887.2.21 2007.10.23.23.45.14 kensmith Edit src/sbin/mount_unionfs/mount_unionfs.8 Add delta 1.20.2.2 2007.10.23.03.37.09 daichi Edit src/share/mklocale/UTF-8.src Add delta 1.1.8.2 2007.10.24.14.32.33 rafan Edit src/sys/alpha/pci/pcibus.c Add delta 1.36.2.2 2007.10.24.12.36.25 jhb Edit src/sys/boot/ficl/Makefile Add delta 1.41.2.2 2007.10.24.11.50.07 nyan Edit src/sys/boot/pc98/Makefile.inc Add delta 1.5.8.2 2007.10.24.11.50.07 nyan Edit src/sys/conf/newvers.sh Add delta 1.69.2.15 2007.10.23.23.41.24 kensmith Edit src/sys/ddb/db_command.c Add delta 1.60.2.4 2007.10.23.16.07.30 obrien Edit src/sys/fs/nullfs/null_subr.c Add delta 1.48.2.2 2007.10.23.03.38.31 daichi Edit src/sys/fs/nullfs/null_vnops.c Add delta 1.87.2.4 2007.10.23.03.38.32 daichi Edit src/sys/fs/unionfs/union.h Add delta 1.31.2.2 2007.10.23.03.28.22 daichi Add delta 1.31.2.3 2007.10.23.03.37.09 daichi Edit src/sys/fs/unionfs/union_subr.c Add delta 1.86.2.2 2007.10.23.03.22.48 daichi Add delta 1.86.2.3 2007.10.23.03.28.22 daichi Edit src/sys/fs/unionfs/union_vfsops.c Add delta 1.76.2.3 2007.10.23.03.32.17 daichi Add delta 1.76.2.4 2007.10.23.03.34.58 daichi Add delta 1.76.2.5 2007.10.23.03.37.09 daichi Edit src/sys/fs/unionfs/union_vnops.c Add delta 1.132.2.2 2007.10.23.03.24.37 daichi Add delta 1.132.2.3 2007.10.23.03.26.37 daichi Add delta 1.132.2.4 2007.10.23.03.28.22 daichi Add delta 1.132.2.5 2007.10.23.03.30.13 daichi Add delta 1.132.2.6 2007.10.23.03.32.17 daichi Add delta 1.132.2.7 2007.10.23.03.33.43 daichi Add delta 1.132.2.8 2007.10.23.03.37.10 daichi Shutting down connection to server Finished successfully ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Realtek Gigabit Network Card 0xd6088086
Hi, FreeBSD 6.2-STABLE can support this network card? [EMAIL PROTECTED]:0:0: class=0x02 card=0xd6088086 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' class= network subclass = ethernet []s -- Daniel Dias Gonçalves DGNET Network Solutions [EMAIL PROTECTED] http://www.dgnetwork.com.br/ +55 37-88263752 +55 37-32421109 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Realtek Gigabit Network Card 0xd6088086
On Wed, 24 Oct 2007 22:28 -0200, daniel wrote: Hi, FreeBSD 6.2-STABLE can support this network card? [EMAIL PROTECTED]:0:0: class=0x02 card=0xd6088086 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' class= network subclass = ethernet []s Should considering everything from RELENG_4 does with the rl or re driver. Are you having some sort of trouble with this driver ? -- Sincerely,-- CmdLnKid The Command Line Kid. mailto:gmail.com!cmdlnkid - (2^(N-1)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADSUP: don't upgrade to RELENG_[67] now (Re: Installworld broken on RELENG_6 by libc commit?)
On 10/25/07, Alson van der Meulen <[EMAIL PROTECTED]> wrote: > Hello, > > My installworld of RELENG_6 from a few hours ago failed with this error > (from memory): > /lib/libncurses.so.6: undefined symbol: __mb_sb_limit > > This broke everything that depended on libncurses, plus PAM. I had to > force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to /lib > using binaries from /rescue to fix it so I could run make installworld > again. I will take a look. before that do not upgrade your system. Regards, Rong-En Fan > > I upgraded from RELENG_6 of October, 22. I believe I followed the > procedure from /usr/src/UPDATING fairly closely, except for the reboot > to single user part after installing the kernel: > mergemaster -p && make buildworld && make kernel && make installworld && > mergemaster && make delete-old > > I would expect libc to be installed before other libs. The securelevel > was -1, so it should be no problem to overwrite libc. > > Did I do something wrong or is this a bug/missing entry in UPDATING? > > regards, > Alson > > The csup output since my last make world: > -- > >>> Running /usr/bin/csup > -- > Parsing supfile "/usr/share/examples/cvsup/stable-supfile" > Connecting to cvsup3.nl.freebsd.org > Connected to 62.250.3.15 > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing multiplexed-mode data connection > Running > Updating collection src-all/cvs > Edit src/include/_ctype.h > Add delta 1.30.2.1 2007.10.24.14.32.32 rafan > Edit src/include/ctype.h > Add delta 1.28.8.1 2007.10.24.14.32.32 rafan > Edit src/lib/libc/locale/big5.c > Add delta 1.17.2.1 2007.10.24.14.32.32 rafan > Edit src/lib/libc/locale/euc.c > Add delta 1.21.2.1 2007.10.24.14.32.32 rafan > Edit src/lib/libc/locale/gb18030.c > Add delta 1.7.2.1 2007.10.24.14.32.32 rafan > Edit src/lib/libc/locale/gb2312.c > Add delta 1.9.2.1 2007.10.24.14.32.33 rafan > Edit src/lib/libc/locale/gbk.c > Add delta 1.12.2.1 2007.10.24.14.32.33 rafan > Edit src/lib/libc/locale/isctype.c > Add delta 1.9.14.1 2007.10.24.14.32.33 rafan > Edit src/lib/libc/locale/mskanji.c > Add delta 1.17.2.1 2007.10.24.14.32.33 rafan > Edit src/lib/libc/locale/none.c > Add delta 1.13.2.1 2007.10.24.14.32.33 rafan > Edit src/lib/libc/locale/setrunelocale.c > Add delta 1.45.2.1 2007.10.24.14.32.33 rafan > Edit src/lib/libc/locale/utf8.c > Add delta 1.13.2.2 2007.10.24.14.32.33 rafan > Edit src/lib/libstand/Makefile > Add delta 1.54.2.1 2007.10.24.11.50.06 nyan > Edit src/release/Makefile > Add delta 1.887.2.21 2007.10.23.23.45.14 kensmith > Edit src/sbin/mount_unionfs/mount_unionfs.8 > Add delta 1.20.2.2 2007.10.23.03.37.09 daichi > Edit src/share/mklocale/UTF-8.src > Add delta 1.1.8.2 2007.10.24.14.32.33 rafan > Edit src/sys/alpha/pci/pcibus.c > Add delta 1.36.2.2 2007.10.24.12.36.25 jhb > Edit src/sys/boot/ficl/Makefile > Add delta 1.41.2.2 2007.10.24.11.50.07 nyan > Edit src/sys/boot/pc98/Makefile.inc > Add delta 1.5.8.2 2007.10.24.11.50.07 nyan > Edit src/sys/conf/newvers.sh > Add delta 1.69.2.15 2007.10.23.23.41.24 kensmith > Edit src/sys/ddb/db_command.c > Add delta 1.60.2.4 2007.10.23.16.07.30 obrien > Edit src/sys/fs/nullfs/null_subr.c > Add delta 1.48.2.2 2007.10.23.03.38.31 daichi > Edit src/sys/fs/nullfs/null_vnops.c > Add delta 1.87.2.4 2007.10.23.03.38.32 daichi > Edit src/sys/fs/unionfs/union.h > Add delta 1.31.2.2 2007.10.23.03.28.22 daichi > Add delta 1.31.2.3 2007.10.23.03.37.09 daichi > Edit src/sys/fs/unionfs/union_subr.c > Add delta 1.86.2.2 2007.10.23.03.22.48 daichi > Add delta 1.86.2.3 2007.10.23.03.28.22 daichi > Edit src/sys/fs/unionfs/union_vfsops.c > Add delta 1.76.2.3 2007.10.23.03.32.17 daichi > Add delta 1.76.2.4 2007.10.23.03.34.58 daichi > Add delta 1.76.2.5 2007.10.23.03.37.09 daichi > Edit src/sys/fs/unionfs/union_vnops.c > Add delta 1.132.2.2 2007.10.23.03.24.37 daichi > Add delta 1.132.2.3 2007.10.23.03.26.37 daichi > Add delta 1.132.2.4 2007.10.23.03.28.22 daichi > Add delta 1.132.2.5 2007.10.23.03.30.13 daichi > Add delta 1.132.2.6 2007.10.23.03.32.17 daichi > Add delta 1.132.2.7 2007.10.23.03.33.43 daichi > Add delta 1.132.2.8 2007.10.23.03.37.10 daichi > Shutting down connection to server > Finished successfully > ___ > 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: any hope for nfe/msk?
On Wed, Oct 24, 2007 at 05:12:44PM +0300, Oleg Lomaka wrote: > Pyun YongHyeon wrote: > >On Wed, Oct 24, 2007 at 09:33:48AM +0200, Danny Braniss wrote: > > > Hi, > > > these drivers don't work under 7.0 > > > As soon as some mild preasure is applied, they start loosing > > interrupts, and > > > in my case the hosts come to a total stand-still, since they are > > diskless > > > and rely on the network. > > > This happens at 1gb and at 100mg. > > > > > > Maybe the problem is with the shared interrups? > > > > > > irq16: mskc0 uhci0 3308351 13 > > > or > > > irq21: nfe0 ohci01584415 24 > > > > > > but I have no idea how to uncouple this > > > > > > >If you see watchdog timeout errors on your console, shared interrupt > >would be culprit. > >For msk(4) set hw.msk.legacy_intr="1" in loader.conf or use kenv(1) > >to set it before loading msk(4) kernel module. > >For nfe(4) you can switch to polling(4). > > > > > I have some msk troubles too. On my laptop (acer travelmate 2483wxmi) > under heavy cpu & network load msk periodically stops working for few > minutes. If that happens msk(4) recover from the non-working state? > sysctl -a|grep msk > <118>msk0: no link ... > <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67 > <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67 > <118>DHCPDISCOVER on msk0 to 255.255.255.255 port 67 interval 3 > <118>DHCPREQUEST on msk0 to 255.255.255.255 port 67 > <118>msk0: flags=8843 metric 0 > mtu 1500 > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: Rx FIFO overrun! This looks bad. Would you show me verbosed boot messages related with msk(4) and PHY driver as well as "vmstat -i" output. > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > dev.mskc.0.%desc: Marvell Yukon 88E8038 Gigabit Ethernet > dev.mskc.0.%driver: mskc > dev.mskc.0.%location: slot=0 function=0 > dev.mskc.0.%pnpinfo: vendor=0x11ab device=0x4352 subvendor=0x1025 > subdevice=0x0110 class=0x02 > dev.mskc.0.%parent: pci2 > dev.mskc.0.process_limit: 128 > dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01 > dev.msk.0.%driver: msk > dev.msk.0.%parent: mskc0 > dev.miibus.0.%parent: msk0 > > Not sure if it is connected to previous issue. > > uname -a > FreeBSD tdevil.lomaka.org.ua 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Mon Oct 22 > 18:32:01 EEST 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TDEVIL-7.kernconf i386 > -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12 on 7.0-BETA1 i386
On Thu, Oct 25, 2007 at 01:17:38AM +0200, Kris Kennaway wrote:
> Doug Poland wrote:
> >Hello,
> >
> >I just had a kernel panic using BETA1. According to the Developer
> >Handbook Kernel Debugging, I'm supplying the following information in
> >hopes that it is useful. Please note: I'm not familiar with this
> >process so you need more data, just ask:
> >
> >
> > snip
> >
>
> Almost :)
>
> What does 'bt' show in kgdb?
>
kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x9006004
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc079c961
stack pointer = 0x28:0xe74a7bcc
frame pointer = 0x28:0xe74a7be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 46 (ath0 taskq)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 4h9m30s
Physical memory: 3435 MB
Dumping 214 MB: 199 183 167 151 135 119 103 87 71 55 39 23 7
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc079c961
0xc079c961 is in mb_free_ext (/usr/src/sys/kern/uipc_mbuf.c:226).
221 * check if the header is embedded in the cluster
222 */
223 skipmbuf = (m->m_flags & M_NOFREE);
224
225 /* Free attached storage if this mbuf is the only reference to
it. */
226 if (*(m->m_ext.ref_cnt) == 1 ||
227 atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 1) {
228 switch (m->m_ext.ext_type) {
229 case EXT_PACKET:/* The packet zone is special.
*/
230 if (*(m->m_ext.ref_cnt) == 0)
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0xc074fed7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0750199 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a1485c in trap_fatal (frame=0xe74a7b8c, eva=151019524) at
/usr/src/sys/i386/i386/trap.c:872
#4 0xc0a14ae0 in trap_pfault (frame=0xe74a7b8c, usermode=0, eva=151019524) at
/usr/src/sys/i386/i386/trap.c:785
#5 0xc0a15455 in trap (frame=0xe74a7b8c) at /usr/src/sys/i386/i386/trap.c:463
#6 0xc09fb46b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc079c961 in mb_free_ext (m=0xc7151e00) at
/usr/src/sys/kern/uipc_mbuf.c:226
#8 0xc079cfc1 in m_freem (mb=0x0) at mbuf.h:510
#9 0xc051e39e in ath_rxbuf_init (sc=0xc6e95000, bf=0xc6e9cc94) at
/usr/src/sys/dev/ath/if_ath.c:3257
#10 0xc052595d in ath_rx_proc (arg=0xc6e95000, npending=1) at
/usr/src/sys/dev/ath/if_ath.c:3711
#11 0xc07809c5 in taskqueue_run (queue=0xc6dd8300) at
/usr/src/sys/kern/subr_taskqueue.c:255
#12 0xc0780bcb in taskqueue_thread_loop (arg=0xc6e96664) at
/usr/src/sys/kern/subr_taskqueue.c:374
#13 0xc07304b9 in fork_exit (callout=0xc0780b10 ,
arg=0xc6e96664, frame=0xe74a7d38) at /usr/src/sys/kern/kern_fork.c:796
#14 0xc09fb4e0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205
(kgdb)
Here's the whole thing with a backtrace. Thanks for your patience...
--
Regards,
Doug
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Realtek Gigabit Network Card 0xd6088086
On Wed, Oct 24, 2007 at 10:28:46PM -0200, Daniel Dias Gon?alves wrote: > Hi, > > FreeBSD 6.2-STABLE can support this network card? > > [EMAIL PROTECTED]:0:0: class=0x02 card=0xd6088086 chip=0x816810ec > rev=0x01 > hdr=0x00 >vendor = 'Realtek Semiconductor' >class= network >subclass = ethernet > If it's not detected by re(4) your NIC would be newer 8168 series. So try re(4) first and let me know the result.(I have a WIP version for newer 8168 family but need testers.) -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Installworld broken on RELENG_6 by libc commit?
On Wednesday 24 October 2007, Alson van der Meulen wrote: > Hello, > > My installworld of RELENG_6 from a few hours ago failed with this > error (from memory): > /lib/libncurses.so.6: undefined symbol: __mb_sb_limit > > This broke everything that depended on libncurses, plus PAM. I had > to force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to > /lib using binaries from /rescue to fix it so I could run make > installworld again. > > I upgraded from RELENG_6 of October, 22. I believe I followed the > procedure from /usr/src/UPDATING fairly closely, except for the > reboot to single user part after installing the kernel: > mergemaster -p && make buildworld && make kernel && make > installworld && mergemaster && make delete-old > > I would expect libc to be installed before other libs. The > securelevel was -1, so it should be no problem to overwrite libc. > > Did I do something wrong or is this a bug/missing entry in > UPDATING? > > regards, > Alson > It is not something you did. I had the same problem and have just recovered from it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: don't upgrade to RELENG_6 now (7 is fine)
On 10/25/07, Rong-en Fan <[EMAIL PROTECTED]> wrote: > On 10/25/07, Alson van der Meulen <[EMAIL PROTECTED]> wrote: > > Hello, > > > > My installworld of RELENG_6 from a few hours ago failed with this error > > (from memory): > > /lib/libncurses.so.6: undefined symbol: __mb_sb_limit > > > > This broke everything that depended on libncurses, plus PAM. I had to > > force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to /lib > > using binaries from /rescue to fix it so I could run make installworld > > again. > > I will take a look. before that do not upgrade your system. I did some tests, it turns out that only RELENG_6 is affected. To be more specific, as ncurses lib is installed before libc. It gets broken. For 7 and above, it is fine because we install libc right after csu and before everything. One way to solve this is we install libc as early as possible, but I think it may be too risky at release cycle, so I would like to back out this change and add an UPDATING entry. Then check whether we can change the installation order of libc later. If you cvsup after 'Oct 24 14:32:33 2007 UTC', please do not upgrade until I send out all clear message. If you already broken your world, use this way in *single user*, /rescue/chflags noschg /lib/libc.so.6 /rescue/cp /usr/obj/usr/src/lib/libc/libc.so.6 /lib/ then you need reboot, after that continue installworld (this is what I just did). Sorry for all the trouble. Thanks, Rong-En Fan > > Regards, > Rong-En Fan > > > > > I upgraded from RELENG_6 of October, 22. I believe I followed the > > procedure from /usr/src/UPDATING fairly closely, except for the reboot > > to single user part after installing the kernel: > > mergemaster -p && make buildworld && make kernel && make installworld && > > mergemaster && make delete-old > > > > I would expect libc to be installed before other libs. The securelevel > > was -1, so it should be no problem to overwrite libc. > > > > Did I do something wrong or is this a bug/missing entry in UPDATING? > > > > regards, > > Alson > > > > The csup output since my last make world: > > -- > > >>> Running /usr/bin/csup > > -- > > Parsing supfile "/usr/share/examples/cvsup/stable-supfile" > > Connecting to cvsup3.nl.freebsd.org > > Connected to 62.250.3.15 > > Server software version: SNAP_16_1h > > Negotiating file attribute support > > Exchanging collection information > > Establishing multiplexed-mode data connection > > Running > > Updating collection src-all/cvs > > Edit src/include/_ctype.h > > Add delta 1.30.2.1 2007.10.24.14.32.32 rafan > > Edit src/include/ctype.h > > Add delta 1.28.8.1 2007.10.24.14.32.32 rafan > > Edit src/lib/libc/locale/big5.c > > Add delta 1.17.2.1 2007.10.24.14.32.32 rafan > > Edit src/lib/libc/locale/euc.c > > Add delta 1.21.2.1 2007.10.24.14.32.32 rafan > > Edit src/lib/libc/locale/gb18030.c > > Add delta 1.7.2.1 2007.10.24.14.32.32 rafan > > Edit src/lib/libc/locale/gb2312.c > > Add delta 1.9.2.1 2007.10.24.14.32.33 rafan > > Edit src/lib/libc/locale/gbk.c > > Add delta 1.12.2.1 2007.10.24.14.32.33 rafan > > Edit src/lib/libc/locale/isctype.c > > Add delta 1.9.14.1 2007.10.24.14.32.33 rafan > > Edit src/lib/libc/locale/mskanji.c > > Add delta 1.17.2.1 2007.10.24.14.32.33 rafan > > Edit src/lib/libc/locale/none.c > > Add delta 1.13.2.1 2007.10.24.14.32.33 rafan > > Edit src/lib/libc/locale/setrunelocale.c > > Add delta 1.45.2.1 2007.10.24.14.32.33 rafan > > Edit src/lib/libc/locale/utf8.c > > Add delta 1.13.2.2 2007.10.24.14.32.33 rafan > > Edit src/lib/libstand/Makefile > > Add delta 1.54.2.1 2007.10.24.11.50.06 nyan > > Edit src/release/Makefile > > Add delta 1.887.2.21 2007.10.23.23.45.14 kensmith > > Edit src/sbin/mount_unionfs/mount_unionfs.8 > > Add delta 1.20.2.2 2007.10.23.03.37.09 daichi > > Edit src/share/mklocale/UTF-8.src > > Add delta 1.1.8.2 2007.10.24.14.32.33 rafan > > Edit src/sys/alpha/pci/pcibus.c > > Add delta 1.36.2.2 2007.10.24.12.36.25 jhb > > Edit src/sys/boot/ficl/Makefile > > Add delta 1.41.2.2 2007.10.24.11.50.07 nyan > > Edit src/sys/boot/pc98/Makefile.inc > > Add delta 1.5.8.2 2007.10.24.11.50.07 nyan > > Edit src/sys/conf/newvers.sh > > Add delta 1.69.2.15 2007.10.23.23.41.24 kensmith > > Edit src/sys/ddb/db_command.c > > Add delta 1.60.2.4 2007.10.23.16.07.30 obrien > > Edit src/sys/fs/nullfs/null_subr.c > > Add delta 1.48.2.2 2007.10.23.03.38.31 daichi > > Edit src/sys/fs/nullfs/null_vnops.c > > Add delta 1.87.2.4 2007.10.23.03.38.32 daichi > > Edit src/sys/fs/unionfs/union.h > > Add delta 1.31.2.2 2007.10.23.03.28.22 daichi > > Add delta 1.31.2.3 2007.10.23.03.37.09 daichi > > Edit src/sys/fs/unionfs/union_subr.c > > Add delta 1.86.2.2 2007.10.23.03.22.48 daichi > > Add delta 1.86.2.3 2007.10.23.03.28.22 daichi > > Edit src/sys/fs/unionfs/union_vfsops.c > > Add de
Re: Installworld broken on RELENG_6 by libc commit?
On 10/25/07, David Booth <[EMAIL PROTECTED]> wrote: > On Wednesday 24 October 2007, Alson van der Meulen wrote: > > Hello, > > > > My installworld of RELENG_6 from a few hours ago failed with this > > error (from memory): > > /lib/libncurses.so.6: undefined symbol: __mb_sb_limit > > > > This broke everything that depended on libncurses, plus PAM. I had > > to force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to > > /lib using binaries from /rescue to fix it so I could run make > > installworld again. > > > > I upgraded from RELENG_6 of October, 22. I believe I followed the > > procedure from /usr/src/UPDATING fairly closely, except for the > > reboot to single user part after installing the kernel: > > mergemaster -p && make buildworld && make kernel && make > > installworld && mergemaster && make delete-old > > > > I would expect libc to be installed before other libs. The > > securelevel was -1, so it should be no problem to overwrite libc. > > > > Did I do something wrong or is this a bug/missing entry in > > UPDATING? > > > > regards, > > Alson > > > It is not something you did. I had the same problem and have just > recovered from it. Sorry for the trouble, see my HEADSUP message on [EMAIL PROTECTED] Regards, 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: Installworld broken on RELENG_6 by libc commit?
On Wed, 24 Oct 2007 21:39 -0500, davidb wrote: On Wednesday 24 October 2007, Alson van der Meulen wrote: Hello, My installworld of RELENG_6 from a few hours ago failed with this error (from memory): /lib/libncurses.so.6: undefined symbol: __mb_sb_limit This broke everything that depended on libncurses, plus PAM. I had to force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to /lib using binaries from /rescue to fix it so I could run make installworld again. I upgraded from RELENG_6 of October, 22. I believe I followed the procedure from /usr/src/UPDATING fairly closely, except for the reboot to single user part after installing the kernel: mergemaster -p && make buildworld && make kernel && make installworld && mergemaster && make delete-old I would expect libc to be installed before other libs. The securelevel was -1, so it should be no problem to overwrite libc. Did I do something wrong or is this a bug/missing entry in UPDATING? regards, Alson It is not something you did. I had the same problem and have just recovered from it. Same thing here. -- Sincerely,-- CmdLnKid The Command Line Kid. mailto:gmail.com!cmdlnkid - (2^(N-1)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: don't upgrade to RELENG_6 now (7 is fine)
On 10/25/07, Rong-en Fan <[EMAIL PROTECTED]> wrote: > On 10/25/07, Rong-en Fan <[EMAIL PROTECTED]> wrote: > > On 10/25/07, Alson van der Meulen <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > > > My installworld of RELENG_6 from a few hours ago failed with this error > > > (from memory): > > > /lib/libncurses.so.6: undefined symbol: __mb_sb_limit > > > > > > This broke everything that depended on libncurses, plus PAM. I had to > > > force a reboot via DDB and copy /usr/obj/lib/libc/libc.so.6 to /lib > > > using binaries from /rescue to fix it so I could run make installworld > > > again. > > > > I will take a look. before that do not upgrade your system. > > I did some tests, it turns out that only RELENG_6 is affected. To be > more specific, as ncurses lib is installed before libc. It gets broken. > For 7 and above, it is fine because we install libc right after csu and > before everything. > > One way to solve this is we install libc as early as possible, but I > think it may be too risky at release cycle, so I would like to back > out this change and add an UPDATING entry. Then check whether > we can change the installation order of libc later. > > If you cvsup after 'Oct 24 14:32:33 2007 UTC', please do not > upgrade until I send out all clear message. > > If you already broken your world, use this way in *single user*, > > /rescue/chflags noschg /lib/libc.so.6 > /rescue/cp /usr/obj/usr/src/lib/libc/libc.so.6 /lib/ > > then you need reboot, after that continue installworld (this is what I > just did). > > Sorry for all the trouble. An entry in UPDATING is added and I'm working on a proper fix. Regards, 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]"
