RE: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> > > One last point, either remove me from the reply to list or place the > > > maillist > > > back on it, thank you. > > > > I think you owe me an apology - but I doubt I will get it. > > Your correct, you won't. I think you mean "you are" ? It is a writer's credibility that is at stake if they choose to argue ad personam, or make patently incorrect and illogical statements and then do not apologize afterwards. Your loss - not mine Take care david ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Freebsd Stable documentation
Thiis was originally Upgrading 5.3 > 6.0 buildworld failure now in libmagic And on Mike Shultz recommendation I have relabeled the topic > On Thursday 08 December 2005 08:57, [EMAIL PROTECTED] wrote: > > > From: Peter Jeremy <[EMAIL PROTECTED]> > > > Date: 2005/12/08 Thu AM 01:34:42 PST > > > To: Vizion <[EMAIL PROTECTED]> > > > CC: Doug Barton <[EMAIL PROTECTED]>, freebsd-stable@freebsd.org > > > Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic > > > > > > On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: > > > >Well having run many very large scale projects myself I find it > > > > difficult to accept either implication of this perspective. > > > > > > There's a massive difference between running a large commercial > project > > > and running a large open source project using volunteers. > > > > Not really I have done both and found that shared values and community > > collaboration work the same. > > > > >On a commercial > > > project, you can direct someone to do something and they have a choice > of > > > either doing it or finding another job. > > > > Well that kind of development environment (rule by dictat) does not work > > very well. Developers are people who are engaged in a collaborative > > process. If you encourage them to think like prima donas then they will > > behave like prima donas rather than as part of an integrated team. > > > > >On a volunteer project, there's > > > a limit to how far you can push someone to do something they don't > enjoy > > > before they just leave. > > > > Push has it limitations everywhere.. goals and communal rewards are > better > > in both volunteer and commercial projects. > > > > > > The first implication is that > > > >we should be complacent about it and not seek to find a method to > > > > improve the process. > > > > > > I don't think anyone is suggesting this. In my experience, the > FreeBSD > > > project is always open to process improvements - this is especially > > > obvious in the documentation and release engineering areas. > > > > The question is about the degree of committment to process change not > > whwther it is absent or present. The critique is there is tooo little > > comitment to process change and too much resistance to greater > > concentration on the quality of user docuimentation and the significance > of > > that work in the developmenmt cycle. > > > > > >>Most of our really top > > > >>notch developers are actually very bad at documenting their work (I > > > >> don't mean bad at being timely with it, I mean that they are bad at > > > >> DOING it), and frankly their time is better spent elsewhere. > > > > > > > >That is a judgment call - franky my experience has been that > developers > > > > who are bad at ensuring their work is well documentated are second > rate > > > > rather than top rate developers. > > > > > > Software developers are notoriously poor at writing documentation for > > > non-technical people. There are probably very few developers who > > > enjoy writing end-user documentation (and can write). In my > > > experience, especially on large projects, it's rare for developers to > > > write the end-user documentation. > > > > NOTE I said" > > F:ranky my experience has been that developers who are bad at > > ENSURING > > their work is well documentated are second rate rather than top rate > > developers. The work of the technical writer needs to influence > development > > at the design stage! It does not matter whether the developer does or > does > > not write the the documentation but it does matter whether the developer > is > > COMIITED to both ensuring that there is proper documentation AND that > the > > documentation process is an integral part of the development process > that > > influences its outcome. > > > > >They may write a rough outline but > > > it's the technical writers who actually do the documentation. > > > > The outline for user documentation needs to be structured BEFORE > > development begins NOT as an afterthought. In a well structured > > development environment documentation is part of DESIGN not post design > > implementation . That is because thinking about end user at the design > > stage is necessary i
RE: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> -Original Message- > From: Michael C. Shultz [mailto:[EMAIL PROTECTED] > Sent: Friday, December 09, 2005 10:32 AM > To: vizion > Cc: 'Peter Jeremy'; 'Doug Barton' > Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic > > On Friday 09 December 2005 09:39, vizion wrote: > > > Vison, you are much better at writting florid prose on how and why > > > FreeBSD is > > > such an awful OS run by a team of Techies who care nothing about end > > > users needs than you are at reading and comprehending simple > > > instructions. > > > > > > What you write is almost believable, your writing skill is very good > and > > > convincing, only in this particualr case I know you are completely > wrong > > > and > > > your failure to follow the simplest advice is why your machine is now > non > > > operational. Quit crying about non relevent issues and concentrate on > > > solving your real problem - getting that darn machine to boot up. > > > > > > One last thought, name one OS that has better documentation than > FreeBSD > > > please, comercial or otherwise. Maybe there is such a beast, if so I > am > > > very > > > curious to know what it is called. > > > > Mike > > > > Rather than replying to the list I am emailing you direct and cc onl;y > the > > individuals to whom you cc'd your original. > > > > Frankly I never ceased to be amazed at diversionary personalized attacks > > that seem to be a regular occurrence on freebsd lists whenever someone > > makes friendly but critical observations about freebsd. There is a > > touchyness there which is a big deterrent to the engagement of others > and a > > tendency to paternalize which, on rare occasions, is an unspeakably ugly > > aspect of some freebsd interactions. > > > > I do not know the root cause of such over-defensiveness I am constantly > > amazed when old timers do not recognize it. It is time to grow up and I > > hope something will happen to discourage people from arguing ad > personam. > > > > Your remarks seem to have been written with the deliberate intention of > > attacking the messenger rather than discussing the message. You did not > > even aspire to achieving accuracy. > > > > The fact the my system did upgrade successfully from 5.3 to 5.4 by > > following your advice does not give you the right to make false > assumptions > > about a failed upgrade from 5.4 to 6.0 that is due to a combination of > > events that have nothing whatsoever to do with the topic under > discussion, > > advice that has been given or even freebsd or its documentation. It > turns > > out that a motherboard hardware failure was the casue of the upgrade > > failure.. hence I have to do a total rebuild because the motherboard is > no > > longer available. > > > And this is your excuse for attacking the FreeBSD organization? No and I have nott attacked "the organization". The c ritic of the way in which documentation is not integrated ionto the freebsd development cycle was made long before there was any motherboard failure. I do wish you would stick to the facts. I'm sure > everyone feels bad for you that you have to get a new motherboard. I am > confused as to how better coordination between developers and technical > writers could have prevented it from failing though. I have not made that suggestion - only you have put forward that notion -- come on laugh a bit - you are really being a bit wild and cranky over this . The motherboard failure occurred after the discussion on documentation not before you really are missing the point here. > > > > As for the use of perjorative terminology (florid prose) and false > > accusations - I am really personally very disappointed in your > reactions. > > > > What you seemed to be saying was that you were unable to counter my > > suggestions which were so unwelcome to you that you chose to attack me > > personally. > > Your suggestions were irrelevent to the problem at hand. My suggestions are very relevant to the documentary errors, omissions and lack of documentary integration that waste much of the time of many end users. My suggestions were, it is true, were off the original topic and came about as a response to someone else who complained about freebsd documentation and I responded to him. He was strongly critical because the documentation stated that direct upgrade from 5.3 to 6.00 was possible when, as you pointed out, it was not. I suggest you reread the whole thread with care and look at
Re: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> > From: "Matthew D. Fuller" <[EMAIL PROTECTED]> > Date: 2005/12/08 Thu AM 08:01:47 PST > To: Peter Jeremy <[EMAIL PROTECTED]> > CC: Doug Barton <[EMAIL PROTECTED]>, freebsd-stable@freebsd.org, > Vizion <[EMAIL PROTECTED]> > Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic > > On Thu, Dec 08, 2005 at 08:34:42PM +1100 I heard the voice of > Peter Jeremy, and lo! it spake thus: > > On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: > > >development is so good. It deserves better and more professional > > >attention to the role of end user documentation. > > > > Are you volunteering? > > It should be noted that this sort of response often comes across > rather sneering and snarky, but (most of the time, anyway) it's really > not meant to. It often DOES translate pretty directly to "Yes, that > would be nice, and it would be really great if somebody who was > interested and capable were to grab the reins and do it." > > Do you mean the response sounds like freebsd documentation See my last email for a response to that one ! ATM I am struggling on a win machine because my local server once more refused to upgrade to 6.0 and this time has bombed outcompletely - looks nlike a complete rebuild david > -- > Matthew Fuller (MF4839) | [EMAIL PROTECTED] > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ >On the Internet, nobody can hear you scream. > ___ > 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: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> > From: Peter Jeremy <[EMAIL PROTECTED]> > Date: 2005/12/08 Thu AM 01:34:42 PST > To: Vizion <[EMAIL PROTECTED]> > CC: Doug Barton <[EMAIL PROTECTED]>, freebsd-stable@freebsd.org > Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic > > On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: > >Well having run many very large scale projects myself I find it difficult > >to > >accept either implication of this perspective. > > There's a massive difference between running a large commercial project > and running a large open source project using volunteers. Not really I have done both and found that shared values and community collaboration work the same. >On a commercial > project, you can direct someone to do something and they have a choice of > either doing it or finding another job. Well that kind of development environment (rule by dictat) does not work very well. Developers are people who are engaged in a collaborative process. If you encourage them to think like prima donas then they will behave like prima donas rather than as part of an integrated team. >On a volunteer project, there's > a limit to how far you can push someone to do something they don't enjoy > before they just leave. Push has it limitations everywhere.. goals and communal rewards are better in both volunteer and commercial projects. > > > The first implication is that > >we should be complacent about it and not seek to find a method to improve > >the > >process. > > I don't think anyone is suggesting this. In my experience, the FreeBSD > project is always open to process improvements - this is especially > obvious in the documentation and release engineering areas. > The question is about the degree of committment to process change not whwther it is absent or present. The critique is there is tooo little comitment to process change and too much resistance to greater concentration on the quality of user docuimentation and the significance of that work in the developmenmt cycle. > >>Most of our really top > >>notch developers are actually very bad at documenting their work (I don't > >>mean bad at being timely with it, I mean that they are bad at DOING it), and > >>frankly their time is better spent elsewhere. > > > >That is a judgment call - franky my experience has been that developers who > >are bad at ensuring their work is well documentated are second rate rather > >than top rate developers. > > Software developers are notoriously poor at writing documentation for > non-technical people. There are probably very few developers who > enjoy writing end-user documentation (and can write). In my > experience, especially on large projects, it's rare for developers to > write the end-user documentation. NOTE I said" F:ranky my experience has been that developers who are bad at ENSURING their work is well documentated are second rate rather than top rate developers. The work of the technical writer needs to influence development at the design stage! It does not matter whether the developer does or does not write the the documentation but it does matter whether the developer is COMIITED to both ensuring that there is proper documentation AND that the documentation process is an integral part of the development process that influences its outcome. >They may write a rough outline but > it's the technical writers who actually do the documentation. The outline for user documentation needs to be structured BEFORE development begins NOT as an afterthought. In a well structured development environment documentation is part of DESIGN not post design implementation . That is because thinking about end user at the design stage is necessary if the outcome of the process is going to be user centric. >The > problem is finding people with technical writing skills who are > interested in helping with FreeBSD. > Freebsd needs to reorganize the way it develops if it is going to interest techn ical writers. No technical writer wants to be associated with writing documnets for developments that have been poorly designed for the end user. Clearing up someone else's mess is no fun. If you treat technical writers as people who come along afterwards and pick up yopur trash OF COURSE you will not get them involved. You need to ask WHY it is difficult to get them. It is because freebsd does not produce software with a focus on end user satisfaction. This is a chicken and egg problem that can only be solved by a fu8ndamental shift both the focus of development objectives and the development process. > > It's also worth noting that a number of FreeBSD developers are not native > English spe
Stable Doc issues- thread branched from [Upgrading 5.3 > 6.0 buildworld failure]
On Wednesday 07 December 2005 13:34, the author Vizion contributed to the dialogue on- Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic now Stable Doc issues- thread branched from [Upgrading 5.3 > 6.0 buildworld failure] >On Wednesday 07 December 2005 13:01, the author Doug Barton contributed to >the dialogue on- > > Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >>Vizion wrote: >>> Well I do not want to not thank those who have made the upgrades viable. >>> The value of their work should not be underrated. >> >>That's a step in the right direction, thanks. :) >> >>> There is however a perennial problem that freebsd documentation has >>> always been seen as behind and seperate from the development process >>> rather than an integral part of that process. >> >>You're right, however that is just "the way it is." > >Well having run many very large scale projects myself I find it difficult > to accept either implication of this perspective. The first implication is > that we should be complacent about it and not seek to find a method to > improve the process. The second implication is that top notch developers do > not care about end user comfort. My experience is that most do care but > they needa helpful environment to achieve food documentation. > >>Most of our really top >>notch developers are actually very bad at documenting their work (I don't >>mean bad at being timely with it, I mean that they are bad at DOING it), >> and frankly their time is better spent elsewhere. > >That is a judgment call - franky my experience has been that developers who >are bad at ensuring their work is well documentated are second rate rather >than top rate developers. > >What I have found works in development is to create team relationships that >cover design, development and documentation. Unfortunately this does go >against the somewhat individualistic elitist relationship that is >unnecessarily sustained by the implications I referred to earlier (neither > of which I buy and both of which seem to me to be condescending nonsense). > >My view would be that the freebsd project might do well to consider >implementing a "no release without quality documentation assurance" policy. >Such a policy forces design and development to integrate their work with >whoever has been identified as responsible for user documentation (whether >that is the designer, developer or a seprate documentation person or team. >This encourage the preparation of user documentation as part of the project >rather then an afterthought (that depends upon members of the "hoi poloi". > >>The documentation is light >>years ahead of where it was 11 years ago when I started using FreeBSD for >>one simple reason. Interested users stepped up and helped make it better. >>That's the only way that things improve in an open source project. > >OK so some of that talent needs to be harnessed and integrated into the >development process. In this day and age we need to believe that user >documentation provides a paradigm for design and development not design and >development a paradigm for documentation. The latter view characterized >development in the early 70,s and 80's. I thought we had moved beyond that. > >>FWIW, I added a paragraph to the UPDATING file in both HEAD and RELENG_6 >>that describes why updating to the latest code in the installed branch is a >>good idea before trying a major version upgrade. Hopefully that will help >>the next person who stumbles over this same issue. > >Thank you so much for what you do. I trust that you will understand that >recomendations for improvement are made BECAUSE the quality of design and >development is so good. It deserves better and more professional attention > to the role of end user documentation. > >my two pennorth > Just another thought - it seems that the current philosophy is We know generally what you the users want and you will know exactly what you have got when we have done it!! When we have done we will give it to you for you to sort out how you can use it! Ps. If you fo not like what we have done or the way we have done it you need to be reminded you are lucky we have done it for you!! Come on - it just cannot be like this for ever. Open source projects start like this but as they mature does not the concentatration need to shift towards user satisfaction rather than just a constant gallop towards greater technical functionality. david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help - vr0: rx packet loss on new 6.0 kernel
Hi I have two questions: 1. Why on booting up from a new freebsd 6.0 generic kernel I should get repeated messages at high frequency on the consol related to vr0: rx packet loss 2. How can I stop the messages to investigate? I have gone back to 5.4 to lick my wounds until I know how to deal with this one david ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Wednesday 07 December 2005 13:01, the author Doug Barton contributed to the dialogue on- Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >Vizion wrote: >> Well I do not want to not thank those who have made the upgrades viable. >> The value of their work should not be underrated. > >That's a step in the right direction, thanks. :) > >> There is however a perennial problem that freebsd documentation has always >> been seen as behind and seperate from the development process rather than >> an integral part of that process. > >You're right, however that is just "the way it is." Well having run many very large scale projects myself I find it difficult to accept either implication of this perspective. The first implication is that we should be complacent about it and not seek to find a method to improve the process. The second implication is that top notch developers do not care about end user comfort. My experience is that most do care but they needa helpful environment to achieve food documentation. >Most of our really top >notch developers are actually very bad at documenting their work (I don't >mean bad at being timely with it, I mean that they are bad at DOING it), and >frankly their time is better spent elsewhere. That is a judgment call - franky my experience has been that developers who are bad at ensuring their work is well documentated are second rate rather than top rate developers. What I have found works in development is to create team relationships that cover design, development and documentation. Unfortunately this does go against the somewhat individualistic elitist relationship that is unnecessarily sustained by the implications I referred to earlier (neither of which I buy and both of which seem to me to be condescending nonsense). My view would be that the freebsd project might do well to consider implementing a "no release without quality documentation assurance" policy. Such a policy forces design and development to integrate their work with whoever has been identified as responsible for user documentation (whether that is the designer, developer or a seprate documentation person or team. This encourage the preparation of user documentation as part of the project rather then an afterthought (that depends upon members of the "hoi poloi". >The documentation is light >years ahead of where it was 11 years ago when I started using FreeBSD for >one simple reason. Interested users stepped up and helped make it better. >That's the only way that things improve in an open source project. OK so some of that talent needs to be harnessed and integrated into the development process. In this day and age we need to believe that user documentation provides a paradigm for design and development not design and development a paradigm for documentation. The latter view characterized development in the early 70,s and 80's. I thought we had moved beyond that. > >FWIW, I added a paragraph to the UPDATING file in both HEAD and RELENG_6 >that describes why updating to the latest code in the installed branch is a >good idea before trying a major version upgrade. Hopefully that will help >the next person who stumbles over this same issue. Thank you so much for what you do. I trust that you will understand that recomendations for improvement are made BECAUSE the quality of design and development is so good. It deserves better and more professional attention to the role of end user documentation. my two pennorth > >Doug -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help - vr0: rx packet loss on new 6.0 kernel
On Tuesday 06 December 2005 22:57, the author [EMAIL PROTECTED] contributed to the dialogue on- Help - vr0: rx packet loss on new 6.0 kernel: >vr0: rx packet loss even on single user mode > On Wednesday 07 December 2005 04:36, the author Randy Rowe contributed to the dialogue on- Re: Help - vr0: rx packet loss on new 6.0 kernel: >[EMAIL PROTECTED] wrote: >>>From: <[EMAIL PROTECTED]> >>>Date: 2005/12/06 Tue PM 11:23:18 PST >>>To: <[EMAIL PROTECTED]>, >>>Subject: Re: Re: Help - vr0: rx packet loss on new 6.0 kernel >> >>OK booted on the old kernel back to 5.4 >>Does anyone have any idea what may have caused the problem? >>Thanks >> From: <[EMAIL PROTECTED]> Date: 2005/12/06 Tue PM 11:13:31 PST To: <[EMAIL PROTECTED]>, Subject: Re: Help - vr0: rx packet loss on new 6.0 kernel >From: <[EMAIL PROTECTED]> >Date: 2005/12/06 Tue PM 10:57:44 PST >To: >Subject: Help - vr0: rx packet loss on new 6.0 kernel > >Just upgraded from 5.4 >6.0 and am getting >vr0: rx packet loss even on single user mode > >I'm no expert but it sounds to me like your world and your kernel are >not in sync. >I'm not sure if a 5.4 kernel can run properly with a 6.0 world and so it >could be that you still have a 5.4 world. > >Just my first guess. You might want to follow up with the steps that you >used to move from 5.4 to 6.0. > Thanks You may be right -- Well I booted up from kernel.old -- moved the new kernel to kernel.faulty and kernel.old to kernel, rebooted and came right up on 5.4. Here are the entries re vro in dmesg.boot on the 5.4 kernel: vr0: port 0xc400-0xc4ff mem 0xde016000-0xde0160ff irq 23 at device 18.0 on pci0 miibus0: on vr0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:50:8d:6e:9d:31 The repeated messages vr0: packet loss just took over the system. Here are the boot sequences Dec 6 22:38:24 dns1 kernel: FreeBSD 6.0-STABLE #0: Tue Dec 6 22:00:00 PST 2005 Dec 6 22:38:24 dns1 kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Dec 6 22:38:24 dns1 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Dec 6 22:38:24 dns1 kernel: CPU: AMD Athlon(tm) XP (1593.54-MHz 686-class CPU) Dec 6 22:38:24 dns1 kernel: Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Dec 6 22:38:24 dns1 kernel: Features=0x383fbff Dec 6 22:38:24 dns1 kernel: AMD Features=0xc0480800 Dec 6 22:38:24 dns1 kernel: real memory = 2080309248 (1983 MB) Dec 6 22:38:24 dns1 kernel: avail memory = 2030624768 (1936 MB) Dec 6 22:38:24 dns1 kernel: ACPI APIC Table: Dec 6 22:38:24 dns1 kernel: ioapic0 irqs 0-23 on motherboard Dec 6 22:38:24 dns1 kernel: npx0: [FAST] Dec 6 22:38:24 dns1 kernel: npx0: on motherboard Dec 6 22:38:24 dns1 kernel: npx0: INT 16 interface Dec 6 22:38:24 dns1 kernel: acpi0: on motherboard Dec 6 22:38:24 dns1 kernel: acpi0: Power Button (fixed) Dec 6 22:38:24 dns1 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Dec 6 22:38:24 dns1 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Dec 6 22:38:24 dns1 kernel: cpu0: on acpi0 Dec 6 22:38:24 dns1 kernel: acpi_button0: on acpi0 Dec 6 22:38:24 dns1 kernel: pcib0: port 0xcf8-0xcff on acpi0 Dec 6 22:38:24 dns1 kernel: pci0: on pcib0 Dec 6 22:38:24 dns1 kernel: agp0: mem 0xd000-0xd7ff at device 0.0 on pci0 Dec 6 22:38:24 dns1 kernel: pcib1: at device 1.0 on pci0 Dec 6 22:38:24 dns1 kernel: pci1: on pcib1 Dec 6 22:38:24 dns1 kernel: pci1: at device 0.0 (no driver attached) Dec 6 22:38:24 dns1 kernel: pci0: at device 9.0 (no driver attached) Dec 6 22:38:24 dns1 kernel: fwohci0: mem 0xde014000-0xde0147ff,0xde01-0xde013fff irq 18 at device 10.0 on pci0 Dec 6 22:38:24 dns1 kernel: fwohci0: OHCI version 1.10 (ROM=1) Dec 6 22:38:24 dns1 kernel: fwohci0: No. of Isochronous channels is 4. Dec 6 22:38:24 dns1 kernel: fwohci0: EUI64 00:d0:03:56:00:b2:b7:e6 Dec 6 22:38:24 dns1 kernel: fwohci0: Phy 1394a available S400, 3 ports. Dec 6 22:38:24 dns1 kernel: fwohci0: Link S400, max_rec 2048 bytes. Dec 6 22:38:24 dns1 kernel: firewire0: on fwohci0 Dec 6 22:38:24 dns1 kernel: fwe0: on firewire0 Dec 6 22:38:24 dns1 kernel: if_fwe0: Fake Ethernet address: 02:d0:03:b2:b7:e6 Dec 6 22:38:24 dns1 kernel: fwe0: Ethernet address: 02:d0:03:b2:b7:e6 Dec 6 22:38:24 dns1 kernel: fwe0: if_start running deferred for Giant Dec 6 22:38:24 dns1 kernel: sbp0: on firewire0 Dec 6 22:38:24 dns1 kernel: fwohci0: Initiate bus reset Dec 6 22:38:24 dns1 kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Dec 6 22:38:24 dns1 kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Dec 6 22:38:24 dns1 kernel: firewire0: bus manager 0 (me) Dec 6 22:38:24 dns1 kernel: atapci0: port 0x9000-0x9007,0x9400-0x9403,0x9800-0x9807,0x9c00-0x9c03,0xa000-0xa00f,0xa400-0xa4ff irq 20 at device 15.0 on pci0 Dec 6 22:38:24 dns1 kernel: ata2: on atapci0 Dec 6 22:38:24 dns1 ke
Re: Re: Help - vr0: rx packet loss on new 6.0 kernel
> > From: <[EMAIL PROTECTED]> > Date: 2005/12/06 Tue PM 11:23:18 PST > To: <[EMAIL PROTECTED]>, > Subject: Re: Re: Help - vr0: rx packet loss on new 6.0 kernel > OK booted on the old kernel back to 5.4 Does anyone have any idea what may have caused the problem? Thanks > > > > > From: <[EMAIL PROTECTED]> > > Date: 2005/12/06 Tue PM 11:13:31 PST > > To: <[EMAIL PROTECTED]>, > > Subject: Re: Help - vr0: rx packet loss on new 6.0 kernel > > > > > > > > > > From: <[EMAIL PROTECTED]> > > > Date: 2005/12/06 Tue PM 10:57:44 PST > > > To: > > > Subject: Help - vr0: rx packet loss on new 6.0 kernel > > > > > > Just upgraded from 5.4 >6.0 and am getting > > > vr0: rx packet loss even on single user mode > > > > > > can anyone please help me to fix the problem > > > > > > Thanks > > cANNOT GET CONTROL OF SYSTEM EVEN VIA ALTERNATIVE TTY > Just managed to get a ps -aux - does anyone know what process I need to kill? > > Thanks > > > > > > > > > ___ > > > 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: Re: Help - vr0: rx packet loss on new 6.0 kernel
> > From: <[EMAIL PROTECTED]> > Date: 2005/12/06 Tue PM 11:13:31 PST > To: <[EMAIL PROTECTED]>, > Subject: Re: Help - vr0: rx packet loss on new 6.0 kernel > > > > > > From: <[EMAIL PROTECTED]> > > Date: 2005/12/06 Tue PM 10:57:44 PST > > To: > > Subject: Help - vr0: rx packet loss on new 6.0 kernel > > > > Just upgraded from 5.4 >6.0 and am getting > > vr0: rx packet loss even on single user mode > > > > can anyone please help me to fix the problem > > > > Thanks > cANNOT GET CONTROL OF SYSTEM EVEN VIA ALTERNATIVE TTY Just managed to get a ps -aux - does anyone know what process I need to kill? Thanks > > > > > ___ > > 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: Help - vr0: rx packet loss on new 6.0 kernel
> > From: <[EMAIL PROTECTED]> > Date: 2005/12/06 Tue PM 10:57:44 PST > To: > Subject: Help - vr0: rx packet loss on new 6.0 kernel > > Just upgraded from 5.4 >6.0 and am getting > vr0: rx packet loss even on single user mode > > can anyone please help me to fix the problem > > Thanks cANNOT GET CONTROL OF SYSTEM EVEN VIA ALTERNATIVE TTY > > ___ > 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]"
Help - vr0: rx packet loss on new 6.0 kernel
Just upgraded from 5.4 >6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help - vr0: rx packet loss on new 6.0 kernel
Just upgraded from 5.4 >6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 16:50, the author Allen contributed to the dialogue on- Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >On Tue, December 6, 2005 19:44, Doug Barton wrote: >> On Tue, 6 Dec 2005, secmgr wrote: >>> Not to belabour this, but the 6.0 release notes do specificly say 5.3 >>> RELEASE >>> and newer. >> >> 5.4-STABLE is newer. :) >> >>> "Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD >>> 5.3-RELEASE or later. Users of older systems wanting to upgrade >>> 6.0-RELEASE >>> will need to update to FreeBSD 5.3 or newer first, then to FreeBSD >>> 6.0-RELEASE." >> >> How does this change to UPDATING in RELENG_6 look to you: >> >> Index: UPDATING >> === >> RCS file: /home/ncvs/src/UPDATING,v >> retrieving revision 1.416.2.7 >> diff -u -r1.416.2.7 UPDATING >> --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 >> +++ UPDATING7 Dec 2005 00:42:04 - >> @@ -229,7 +229,13 @@ >> page for more details. >> >> Due to several updates to the build infrastructure, source >> - upgrades from versions prior to 5.3 no longer supported. >> + upgrades from versions prior to 5.4-STABLE are not likely >> + to succeed. > >Sorry to butt in but.. > >Doesn't the definition of -STABLE change, for all intents and purposes, by >the minute? > >What next, "versions prior to 5.4-STABLE as of MMDD "? > >> + >> + When upgrading from one major version to another, it is >> + generally best to upgrade to the latest code in the branch >> + currently installed first, then do another upgrade to the >> + new branch. > >This is getting closer to the truth. > >Why don't you just say "update to the most recent RELENG_5 before >attempting." Future proof, no room for confusion. Well I do not want to not thank those who have made the upgrades viable. The value of their work should not be underrated. There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an integral part of that process. I do not know whether that historical habit is changeable. I suspect it is the only major disadvantage from what I would personally describe as a somewhat "technologically centred meritocratic school of governance" for the freebsd project. Some improved cohesion between the desire to meet the developmental needs and a desirable objective to provide an end user-centric operation is, to my mind desirable. On the other hand freebsd has prospered in the past by devotion to reliance upon idiosyncratic individual initiatives and that does not blend well with co-operatively integrated plans to similtaneously meet the twin goals I identify. On the whole the result is a A for freebsd when we all want an A++ Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s Thank you top everyone who helped. I have now successfully upgarded to 5.4 and am about to begin the last leg of this journey towards 6.0. my two pennorth david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 14:36, the author Doug Barton contributed to the dialogue on- Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >On Tue, 6 Dec 2005, Vizion wrote: >> Just an additional question if some one has time to answer. >> >> Should I upgrade my ports from 5.4 as well prior to moving to 6? > >No, that's not needed. > Thanks again david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 14:15, the author Vizion contributed to the dialogue on- Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >On Tuesday 06 December 2005 13:28, the author Kris Kennaway contributed to >the dialogue on- > > Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >>On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: >>> On Tuesday 06 December 2005 11:47, the author Vizion contributed to the >>> dialogue which was on- >>> Re: Upgrading 5.3 > 6.0 buildworld failure in libkrb5 but is currently: >>> Upgrading 5.3 > 6.0 buildworld failure now in libmagic >>> >>> >On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov >>> > contributed to the dialogue on- >>> >>> >>> >>> >>The example of setting up ccache in /etc/make.conf is just plain >>> >>wrong. It shouldn't be hardcoding CC to "/usr/bin/cc", similarly >>> >>for CXX. Comment out the ccache stuff completely in /etc/make.conf >>> >>(or at least the last "else" part), make sure your PATH doesn't >>> >>include the ccache path, and try again with an empty /usr/obj. >>> >>Please report back if it succeeded (it should). Please send your >>> >>complaints to the ccache port MAINTAINER as he did not respond to >>> >>my email explaining the problem, and I'm getting really tired of >>> >>explaining this for the Nth time. >>> > >>> >Thanks very much - I am building right now --after deinstalling ccache, >>> > make cleandir x3 and an empty /usr/obj. I will post the results here >>> >>> Well certainly made a difference but now it fails in magic >> >>Update to 5.4 before trying to update to 6.0. > >Thank you Kris > >You are a mine of information as always. > >I do wish there was some consistency in updating about this.. I asked on > this list whether I needed to upgrade to 5.4 before mocing to 6 and the > advice suggested that I could go straight from 5.3 to 6 but there we are -- > guess that's life > >Presumably it would be safest to delete /usr/src/* and cvsup with > tag=RELENG_5 > >Thanks again > >david Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? I have a large ports installation on the system I am upgrading. david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 13:28, the author Kris Kennaway contributed to the dialogue on- Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic: >On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: >> On Tuesday 06 December 2005 11:47, the author Vizion contributed to the >> dialogue which was on- >> Re: Upgrading 5.3 > 6.0 buildworld failure in libkrb5 but is currently: >> Upgrading 5.3 > 6.0 buildworld failure now in libmagic >> >> >On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed >> > to the dialogue on- >> >> >> >> >>The example of setting up ccache in /etc/make.conf is just plain >> >>wrong. It shouldn't be hardcoding CC to "/usr/bin/cc", similarly >> >>for CXX. Comment out the ccache stuff completely in /etc/make.conf >> >>(or at least the last "else" part), make sure your PATH doesn't >> >>include the ccache path, and try again with an empty /usr/obj. >> >>Please report back if it succeeded (it should). Please send your >> >>complaints to the ccache port MAINTAINER as he did not respond to >> >>my email explaining the problem, and I'm getting really tired of >> >>explaining this for the Nth time. >> > >> >Thanks very much - I am building right now --after deinstalling ccache, >> > make cleandir x3 and an empty /usr/obj. I will post the results here >> >> Well certainly made a difference but now it fails in magic > >Update to 5.4 before trying to update to 6.0. > Thank you Kris You are a mine of information as always. I do wish there was some consistency in updating about this.. I asked on this list whether I needed to upgrade to 5.4 before mocing to 6 and the advice suggested that I could go straight from 5.3 to 6 but there we are -- guess that's life Presumably it would be safest to delete /usr/src/* and cvsup with tag=RELENG_5 Thanks again david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 > 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 > 6.0 buildworld failure now in libmagic >On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to >the dialogue on- >>The example of setting up ccache in /etc/make.conf is just plain >>wrong. It shouldn't be hardcoding CC to "/usr/bin/cc", similarly >>for CXX. Comment out the ccache stuff completely in /etc/make.conf >>(or at least the last "else" part), make sure your PATH doesn't >>include the ccache path, and try again with an empty /usr/obj. >>Please report back if it succeeded (it should). Please send your >>complaints to the ccache port MAINTAINER as he did not respond to >>my email explaining the problem, and I'm getting really tired of >>explaining this for the Nth time. > >Thanks very much - I am building right now --after deinstalling ccache, make >cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic building static magic library ranlib libmagic.a cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/apprentice.c -o apprentice.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/apptype.c -o apptype.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/ascmagic.c -o ascmagic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/compress.c -o compress.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/fsmagic.c -o fsmagic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/funcs.c -o funcs.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/is_tar.c -o is_tar.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/magic.c -o magic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/print.c -o print.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/readelf.c -o readelf.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/softmagic.c -o softmagic.So building shared library libmagic.so.2 cat /usr/src/lib/libmagic/../../contrib/file/Header /usr/src/lib/libmagic/../../contrib/file/Localstuff /usr/src/lib/libmagic/../../contrib/file/Magdir/xo65,v /usr/src/lib/libmagic/../../contrib/file/Magdir/virtutech,v /usr/src/lib/libmagic/../../contrib/file/Magdir/uuencode,v /usr/src/lib/libmagic/../../contrib/file/Magdir/netbsd,v /usr/src/lib/libmagic/../../contrib/file/Magdir/allegro /usr/src/lib/libmagic/../../contrib/file/Magdir/sccs /usr/src/lib/libmagic/../../contrib/file/Magdir/sysex /usr/src/lib/libmagic/../../contrib/file/Magdir/xdelta /usr/src/lib/libmagic/../../contrib/file/Magdir/zyxe
Re: Upgrading 5.3 > 6.0 buildworld failure in libkrb5
On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to
the dialogue on-
Re: Upgrading 5.3 > 6.0 buildworld failure in libkrb5:
>On Mon, Dec 05, 2005 at 03:18:43PM -0800, Vizion wrote:
>> Hi
>>
>> I have tried repeatedly to get make buildworld for upgrading from freebsd
>> 5.3 to 6.0 but get repeated failure in libkrb5.
>>
>> FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004
>> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> CPU: AMD Athlon(tm) (1593.54-MHz 686-class CPU)
>> Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0
>>
>> Features=0x383fbff>A,CMOV,PAT,PSE36,MMX,FXSR,SSE> AMD Features=0xc048
>> real memory = 2080309248 (1983 MB)
>> avail memory = 2030002176 (1935 MB)
>> ACPI APIC Table:
>>
>> I have tried with very helpful advice from freebsd-questions contributors:
>>
>> with and without ccache
>>
>> 3x make cleandir prior to build
>> additional cvsup of source tree
>>
>> but the problem still remains .
>> Hopefully someone on stable may have the answer.
>>
>> Here is my make.conf
>>
>> SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
>> # added by use.perl 2005-11-18 10:51:36
>> PERL_VER=5.8.7
>> PERL_VERSION=5.8.7
>> .if !defined(NOCCACHE)
>> .if ${.CURDIR:M/usr/src*}
>> CC=/usr/local/libexec/ccache/cc
>> CXX=/usr/local/libexec/ccache/c++
>> .else
>> CC=cc
>> CXX=c++
>> .endif
>> .else
>> CC=/usr/bin/cc
>> CXX=/usr/bin/c++
>> .endif
>
>The example of setting up ccache in /etc/make.conf is just plain
>wrong. It shouldn't be hardcoding CC to "/usr/bin/cc", similarly
>for CXX. Comment out the ccache stuff completely in /etc/make.conf
>(or at least the last "else" part), make sure your PATH doesn't
>include the ccache path, and try again with an empty /usr/obj.
>Please report back if it succeeded (it should). Please send your
>complaints to the ccache port MAINTAINER as he did not respond to
>my email explaining the problem, and I'm getting really tired of
>explaining this for the Nth time.
>
Thanks very much - I am building right now --after deinstalling ccache, make
cleandir x3 and an empty /usr/obj. I will post the results here
Thanks again for taking the time to reply
david
--
40 yrs navigating and computing in blue waters.
English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus.
Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after
completing engineroom refit.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Upgrading 5.3 > 6.0 buildworld failure in libkrb5
Hi
I have tried repeatedly to get make buildworld for upgrading from freebsd 5.3
to 6.0 but get repeated failure in libkrb5.
FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) (1593.54-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0
Features=0x383fbff
AMD Features=0xc048
real memory = 2080309248 (1983 MB)
avail memory = 2030002176 (1935 MB)
ACPI APIC Table:
I have tried with very helpful advice from freebsd-questions contributors:
with and without ccache
3x make cleandir prior to build
additional cvsup of source tree
but the problem still remains .
Hopefully someone on stable may have the answer.
Here is my make.conf
SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
# added by use.perl 2005-11-18 10:51:36
PERL_VER=5.8.7
PERL_VERSION=5.8.7
.if !defined(NOCCACHE)
.if ${.CURDIR:M/usr/src*}
CC=/usr/local/libexec/ccache/cc
CXX=/usr/local/libexec/ccache/c++
.else
CC=cc
CXX=c++
.endif
.else
CC=/usr/bin/cc
CXX=/usr/bin/c++
.endif
I show the output from pkg_info below the build result
# cd /usr/src && make NOCCACHE=1 buildworld && make NOCCACHE=1 buildkernel
/* NOTE: I get the same failure for the same function in linkrb5 no matter
what I try: */
/libkrb5/../../../crypto/heimdal/lib/krb5/net_write.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/padata.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/principal.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/prog_setup.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/prompter_posix.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_cred.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_error.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_priv.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_rep.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_req.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_safe.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/read_message.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/recvauth.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/replay.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/send_to_kdc.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/sendauth.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/set_default_realm.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/sock_principal.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store_emem.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store_fd.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store_mem.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/ticket.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/time.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/transited.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/verify_init.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/verify_user.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/version.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/warn.c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/write_message.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I.
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -DINET6
-c /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/acl.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I.
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -DINET6
-c /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/add_et_list.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I.
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -DINET6
-c
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/addr_families.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn
recomendations please for new freebsd development system
Hi Like the title.. I need to build a new systemsupporting a substantial mysql database application for a development team and also able to provide: 1. fast as possible compile times 2. raid 6 support with 6-10 terabytes of data storage 3. 1 terabyte fast data storage 4. 8G or more of ram 5. excellent graphics performance and capabilities with high quality sound/video supporting dual high resolution monitors and surround sound. 6. Back up facilities for 6-10 terabytes. Would anyone be so bold as to make some recommendations for a reliable motherboard/processor combination on the assumption that this is to be a dual processor system running freebsd 6.0 Thanks in advance david ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Configuring SMP on Proliant 5500 Quad Xeon 500Mhz
Hi Here is the system: Compaq Proliant 5500 Quad Xeon 500Mhz Booting from Compaq Smart Raid configured to give 3 virtual drives JBOD on seperate adaptec SCSI 2 PCI card Fibre Channel Array 1.2T Adaptec AHA 6944A/TX 4 port PCI 10/100 NVidia PCI TNT2 M64 32M Video card - working fine after a struggle - configured as vesa vesa! Built in ATI Rage IIc (DISABLED) on standard peripheral interface FreeBSD 4.7 My first attempt at configuring this system for SMP was a total failure!! and I also lost the original configuration as I was unable to re-start successfully with kernel.old. I havesuccessfully rebuilt the configuration as single processor and am ready to have another go to build as SMP. Before doing so some handholding advice would be very welcome. Is there anyone out there with a similar system who could advise. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
V5 with Proliant 5500 SMP Quad
Hi I had just finished an install of FreeBSD 4.7 onto a Proliant 5500 Quad system, reconfigured the kernel to (as I thought) support SMP when my new CD set from FreeBSD Mall arrived with V5.00. I put the CDset to one side as I did make installkernel. Well the SMP kernel failed and as I seemed to be unable to recover from boot.old I decided to do another install and go for V5. Here is my report on on my experience so far with V5: 1. The boot sequence from V5 gave me an error Checksum RSDP - does anyone know what that is? 2. The graphics card is nvidia TNT2 M64 PCI in the primary PCI bus (has to be here because this card does not work in the secondary PCI bus for some reason). I struggled to get X windows working with this card on 4.7and eventualy succeeded by selecting vesa vesa as the card. While working on this I had no problems during the install process under 4.7. However installing from the V5 CD produced scattered artifacts on the screen during the file loading sequences. At the time of this email I have not even been able to attempt configuring X under V5 because of the mouse problems. 3. The next thing is there are some problems with configuring the mouse. I tried a PS/2 three button mouse KEIO with a wheel by KYE systems group and an alps glidepoint device. The latter device was recognised by the system psm0: irq 12 on atkbdc psm0: model Glidepoint, Device ID 0 There were no apparent irq clashes. No matter what choices are made the system crashes when "Trying to start the mouse daemon" . The only choice is to reboot. Disabling the mouse daemon got nowhere - X windows config program crashed! Any way I am back configuring 4.7 and am slowly overcoming the problems. I am asking for guidance on configuring SMP for this system in a separate email! David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Plain text posting
Hi I have noticed an increased tendency of a few people to post to plain text lists using attachments. Quite apart from minor irritations such as increased bandwidth and the necessity to open attachments some people seem to have the mistaken impression that the practise of sending messages via a PGP signed attachments somehow adds to general recipient security rather than diminish it by encouraging careless attachment usage. It may be important to remember the general principle that the customary opening of attachments is inherently more risky than a plain text message for the recipent even when PGP signed. The less secure the operating system of the immediate recipent the more risky the practice. Viruses, which may not be able to infect a primary recipient often reach their targets by being forwared from a primary to a secondary recipent on a more vulnerable platform. PGP only tells us that the message has not changed in transit. A malformed/abusive/virus laden attachment is still malformed/abusive/virus laden even if PGP signed. Can we please stick to plain text UNLESS the material cannot reasonably be transmitted without being in attachment form. There is no benefit to be gained from attachments otherwise. Thanks David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ASUS A7M266-D: enabling 'on board sound'
- Original Message - From: "Randall Hopper" <[EMAIL PROTECTED]> To: "Marc G. Fournier" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, April 28, 2002 9:17 AM Subject: Re: ASUS A7M266-D: enabling 'on board sound' > Marc G. Fournier: > | Just recently picked up an ASUS A7M266-D Motherboard with Dual: > |"(AMD Athlon(TM) MP Processor (1200.05-MHz 686-class CPU)" ... the system > |purrs like the proverbial kitten ... but the one thing that is eluding me > |so far is getting the onboard sound to work ... > ... > |pcm0: at device 4.0 on pci2 > |pcm0: cmi_attach: Cannot allocate bus resource > |device_probe_and_attach: pcm0 attach returned 6 > ... > |___device pcm0 at isa? irq 5 drq 1 flags 0x0 > > I have the original non-dual version (ASUS A7M266) with the same sound > chip: > >> dmesg | grep pcm0 >pcm0: port 0xa400-0xa4ff irq 10 at device 5.0 on pci0 > > Here's what I have on my 4.3-STABLE (circa 06/01) config: > >device pcm0 >device sbc0at isa? port 0x220 irq 5 drq 1 flags 0x15 > > The flags may be the kicker for you. That sets the 2nd (16-bit) DMA > channel IIRC. > If you have the time I would be very interested in having more information about your configuration as I am contemplating building a similar SMP system. How much memory do you have installed and what use do you have for the system? Any information much appreciated. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Test - Please ignore - Original Message - From: "David Schultz" <[EMAIL PROTECTED]> To: "Terry Lambert" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, April 22, 2002 6:09 AM Subject: Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ? > Thus spake Terry Lambert <[EMAIL PROTECTED]>: > > If you want more, then you need to use a 64 bit processor (or use a > > processor that supports bank selection, and hack up FreeBSD to do > > bank swapping on 2G at a time, just like Linux has been hacked up, > > and expect that it won't be very useful). > > I'm guessing that this just means looking at more than 4 GB of memory > by working with 2 GB frames at a time. As I recall, David Greenman > said that this hack would essentially require a rewrite of the VM > system. Does this just boil down to using 36 bit physical addresses? > Are there plans for FreeBSD to support it, or is everyone just waiting > until 64 bit processors become more common? > > > You can't > > really avoid that, for the most part, since there's a shared TLB > > cache that you really don't have opportunity to manage, other than > > by seperating 4M vs. 4K pages (and 2M, etc., for the Pentium Pro, > > though variable page granularity is not supported in FreeBSD, since > > it's not common to most hardware people actually have). > > Does FreeBSD use 4M pages exclusively for kernel memory, as in > Solaris, or is there a more complicated scheme? > > > If you increase the KVA, then you will decrease the UVA available to > > user processes. The total of the two can not exceed 4G. > > In Linux, all of physical memory is mapped into the kernel's virtual > address space, and hence, until recently Linux was limited to ~3 GB of > physical memory. FreeBSD, as I understand, doesn't do that. So is > the cause of this limitation that the top half of the kernel has to > share a virtual address space with user processes? > > I'll have to read those books one of these days when I have time(6). > Thanks for the info. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
