RE: ICH7 SATA RAID Broken, Was (Re: Timescale for 6.1-RELEASE...)
-Original Message- From: Nikolas Britton [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 5:47 PM To: Ted Mittelstaedt Cc: freebsd-stable@freebsd.org; [EMAIL PROTECTED] Subject: ICH7 SATA RAID Broken, Was (Re: Timescale for 6.1-RELEASE...) On 4/12/06, Ted Mittelstaedt [EMAIL PROTECTED] wrote: -Original Message- From: Ted Mittelstaedt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 11, 2006 6:04 PM To: Nikolas Britton Cc: Harrison Peter CSA BIRKENHEAD; freebsd-questions@freebsd.org Subject: RE: Timescale for 6.1-RELEASE... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nikolas Britton Sent: Tuesday, April 11, 2006 1:25 PM To: Ted Mittelstaedt Cc: Harrison Peter CSA BIRKENHEAD; freebsd-questions@freebsd.org Subject: Re: Timescale for 6.1-RELEASE... I think the ICH7 sata problem has already been fixed, check the logs here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ if not jump onto the stable mailing list and start waving your hands. I'm doing a make release on today's cvs as we speak, I'll see tomorrow if it recognizes the disks. Nikolas, Just an update, no the ICH7R problem has not been fixed. OpenSUSE recognizes the array, though. Send email to Søren Schmidt [EMAIL PROTECTED] I have been already. Soren is very responsive to PR's if the people filing them meet him halfway and he responded as soon as the PR was filed. and/or post this on the stable mailing list, their is nothing I can do personally that will fix it for you. I know that. What I was pointing out is that while your enthusiasm is commendable, FreeBSD 6.1 really isn't totally ready for prime time. The HP DL320 G4 is a pretty cheap server - it's positioned squarely to compete agressively with the black box intel motherboard servers out there. It's also got an embedded remote control package that is fantastic - you can do a nuke and repave of the server remotely if you want. We are going to see a lot of these out there pretty soon. And if HP could fuck up the SATA controller to make it not work, then other server vendors can do it also. I suspect this is the tip of the iceberg with the ICH7R controllers. Damn Intel for designing a controller that apparently lets designers improve it. You could start hacking away at the problem if you know some C, digging around in /usr/src/sys/dev/ata/ Soren sent a patch this morning which I think gave him some more data to work with. We will see. Unfortunately, though, getting the SATA controller working on this beast is just the first problem - there's also (I suspect) something not kosher about the ethernet ports either. But until I get a system on it, I can't dig into that. Ted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Portupgrade in Xfree86 pkg failed
Warren, Why are you building xfree86? FreeBSD 5.4 uses Xorg. It's just about the same code just different licensing. I don't think the FreeBSD core is bothering to keep the xfree86 port working on FreeBSD 5.X just FreeBSD 4.11 Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Warren Sent: Friday, June 24, 2005 4:17 AM To: Daniel O'Connor Cc: freebsd-stable@freebsd.org; freebsd-questions@freebsd.org Subject: Re: Portupgrade in Xfree86 pkg failed On Fri, 24 Jun 2005 9:11 pm, Daniel O'Connor wrote: On Fri, 24 Jun 2005 20:35, Warren wrote: ln -s /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfre e86/os-su pp ort/linux/drm/xf86drmRandom.c xf86drmRandom.c rm -f xf86drmSL.c ln -s /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfre e86/os-su pp ort/linux/drm/xf86drmSL.c xf86drmSL.c make: don't know how to make /drm.h. Stop *** Error code 2 Stop in /usr/ports/graphics/xfree86-dri/work/xc/lib/GL. *** Error code 1 Stop in /usr/ports/graphics/xfree86-dri. What commanad did you run? portupgrade -aDk -m BATCH=yes What version of FreeBSD are you running? 5.4-STABLE When did you last cvsup your ports tree? Just before doing PortUpgrade before sending the 1st email Did you read /usr/ports/UPDATING? cant say as i did. -- Yours Sincerely Shinjii http://www.shinji.nq.nu ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions 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: Portupgrade in Xfree86 pkg failed
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Linimon Sent: Saturday, June 25, 2005 11:25 AM To: Ted Mittelstaedt Cc: Daniel O'Connor; freebsd-stable@freebsd.org; Warren; freebsd-questions@freebsd.org Subject: Re: Portupgrade in Xfree86 pkg failed On Sat, Jun 25, 2005 at 09:14:26AM -0700, Ted Mittelstaedt wrote: Why are you building xfree86? FreeBSD 5.4 uses Xorg. It's just about the same code just different licensing. I don't think the FreeBSD core is bothering to keep the xfree86 port working on FreeBSD 5.X just FreeBSD 4.11 I'm sorry, but this is wrong on almost all counts. The default X server that is installed by the base for 5.4 is indeed xorg, but both XFree and xorg are being actively maintained. I'm sorry to step on the toes of the port maintainer but instead of complaining about it you need to respond to the realitites. And the reality is this: ln -s /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-su pport/linux/drm/xf86drmRandom.c xf86drmRandom.c rm -f xf86drmSL.c ln -s /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-su pport/linux/drm/xf86drmSL.c xf86drmSL.c make: don't know how to make /drm.h. Stop *** Error code 2 Stop in /usr/ports/graphics/xfree86-dri/work/xc/lib/GL. *** Error code 1 Stop in /usr/ports/graphics/xfree86-dri. If you really believe that XFree86 is being actively maintained, then answer the original poster, quit bitching about what I'm saying. What do you think maintainence is? A great deal of work goes into keeping both X servers working on the active source branches. The 4.X source branch isn't really active anymore. As for the licensing meta-fiasco, see the FAQ or use Google to find out more; this has been hashed and re-hashed and re-re-hashed here, and in other venues, many times. If the licensng was a non-issue then xorg wouldn't exist. Personally I deplore the move to xorg based on the simple requirement of xfree86 for recognition in their new license - this was the same bunch of bullcrap that the GPL bigots were using to throw rocks at the BSD license years ago. But the plain fact of the matter is that the Open Source community isn't going to tolerate what xfree86 tried doing, and the users of open source, which is you and I, are not served by splitting development between 2 forks of X Windows. The amount of new video hardware that is coming out and needs drivers is increasing, drivers are getting more and more complex to write, and manufacturers are just as bad as they always have been about assisting in video driver development. The sooner that xfree86 goes away and dies the better for the community in the long run. We just had a big thread on making FreeBSD easier to use for the average person - and now your claiming that it's a -good- thing to have two completely different X Windows distributions?!?! How exactly does this HELP with the complexity issue - unless the goal is to make FreeBSD even more complicated? Ted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Portupgrade in Xfree86 pkg failed
-Original Message- From: Mark Linimon [mailto:[EMAIL PROTECTED] Sent: Saturday, June 25, 2005 3:51 PM To: Ted Mittelstaedt Cc: Mark Linimon; Daniel O'Connor; freebsd-stable@freebsd.org; Warren; freebsd-questions@freebsd.org Subject: Re: Portupgrade in Xfree86 pkg failed On Sat, Jun 25, 2005 at 02:45:45PM -0700, Ted Mittelstaedt wrote: I'm sorry to step on the toes of the port maintainer but instead of complaining about it you need to respond to the realitites. In general I would rather do that than argue, yes. make: don't know how to make /drm.h. Stop *** Error code 2 If you really believe that XFree86 is being actively maintained, then answer the original poster, quit bitching about what I'm saying. Actively maintained means having updates tested on the build cluster and committed when the majority of ports upgrade successfully. It does not mean every port necessarily is going to work in every single configuration, since there are a large number of interdependent parts. Have you filed a PR about this? query-pr shows no match for 'drm'. It's not a problem I have since I use xorg on 5.X As a matter of fact I just installed xfree86 a week ago, from scratch, on a new 4.11 system, from a ports tree that I cvsupped, with no problems. So I don't have an answer for the OP as to why his xfree86 setup doesen't build. But I have no problems in building xorg on FreeBSD 5, the OP indicated he was using FreeBSD 5, and FreeBSD 5 comes with a prebuilt binary of xorg. So a very logical question is to ask the OP why he is going at cross-currents and using xfree86 on 5. If his answer had been something that indicated that xfree86 was not a dependency for what he was doing, then once again, the quickest fix would be to simply tell him to stop using xfree86 and build xorg. I don't have any particular bias against xfree86. I do not agree with fracturing the X development effort between 2 virtually identical projects - but as I didn't have any vote in that happening, I am forced to deal with the aftermath. And so I'm going to do that from a self-interest point of view. And the best solution for me and for just about everyone in Open Source is to choose between xfree86 or xorg, and for just about everyone to choose the same choice, and let the other project die off from neglect. The FreeBSD Project chose xorg, so I will chose xorg. Maybe they chose wrong and xorg will die and xfree86 will continue - if that happens I'll deal with it then. If there was significant product differentiation between xfree86 and xorg, then there would be a reason to keep both. Right now there is not and with the difficulty in X development, there won't soon be. fwiw, the most recent update to x11/XFree86-4/Makefile was on 2005/06/15 02:39:58 to update to 4.5.0 and shows that 8 different PRs were closed by the commit. The 4.X source branch isn't really active anymore. This is news to me. AFAIK we are still requesting all our port maintainers to keep things working on 4.X whenever possible. OK, then schedule another RELEASE. If you knew anything about the history of FreeBSD you would know that 4.X should have ended years ago. I know Rod Grimes personally and he was one of the founders, and he said that what happened with 4 was never the way it was intended. Here's the litmus test - would you pull a popular port if it breaks on 4 but not on 5? 'nuff said. the users of open source, which is you and I, are not served by splitting development between 2 forks of X Windows. You are entitled to your opinion. Others disagree, and quite strongly so. The FreeBSD project agrees with me, if they did not then they would have rewritten the installer to make it optional which one to pick. Finally, the initial question would have probably gotten a better answer if posted to the freebsd-x11 mailing list, where the maintainers of the X servers tend to hang out, and any further discussion of these issues ought to migrate there as well. I agree with that. Ted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: applying the vesa patch to stable for high console resolution
Hi, Has this patch beeen applied to CURRENT? So it will be in the next release of FreeBSD? Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Didier Wiroth Sent: Monday, June 13, 2005 1:46 PM To: freebsd-stable@freebsd.org Cc: freebsd-questions@freebsd.org Subject: applying the vesa patch to stable for high console resolution Hi, USE AT YOUR OWN RISK! this for the freebsd5 branch only Here is how to apply the patch to get the long awaited high console text modes under freebsd! I actually use it on my nc6000 hp laptop with the following mode: 1400x1050x16 damm .. really nice ;-)) This patch is actually for freebsd current but it works (for me) with 5-stable and may be release or earlier versions (5.X) too. ONCE AGAIN BE WARNED!! USE AT YOUR OWN RISK!!! Let's go: 1) Get the patch here: http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 2) Remove the lines which are not required for us and rename the patch we will use to syscons.patch: split -p Index: usr.sbin patchset-highres.20050522 mv xaa syscons.patch 3) backup and patch your local (stable) sources: (/usr/src/sys/dev/syscons - will be patched) cp -Rp /usr/src/sys/dev/syscons /usr/src/sys/dev/BAK.syscons cd /usr/src patch path_to_patch/syscons.patch 4) recompile and install your kernel with sc_pixel_mode and vesa support see handbook for details! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernel config.html 5) backup your vidcontrol sources cp -Rp /usr/src/usr.sbin/vidcontrol /usr/src/usr.sbin/BAK.vidcontrol 6) update your vidcontrol sources with the current/HEAD vidcontrol sources cd /usr/src cvs [EMAIL PROTECTED]:/home/ncvs co -rHEAD usr.sbin/vidcontrol 7) recompile vidcontrol and install cd /usr/src/usr.sbin/vidcontrol make clean make all make install 8) reboot 9) after having rebooted with your new kernel (with sc_pixel_mode and vesa) issue a vidcontrol -i mode You will get lots of ouput like this: 322 (0x142) 0x000f G 1400x1050x16 1 8x16 0xa 64k 64k 0x9800 65472k Test the mode in a shell by issuying: vidcontrol MODE_322 If it works (I hope for you ;-)) but your corresponding mode in rc.conf like this: allscreens_flags=MODE_322 Voilà :-)) Long live freebsd ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions 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: 5.4 install disc1 will not find hard drive
PR i386/81082 Once again, I don't think the problem is in the build process they used for making the ISO. As a matter of fact I just yesterday did a 5.4 install on a system, booting from CD, which I burned from disc1.iso that I downloaded from one of the FTP mirrors, on the one machine I mentioned in the PR that didn't have a problem. I think the problem is in the driver. If you go to the CVS tree it is obvious that they have been dealing with these issues. For example, check out comments like Fix more ATAPI breakage. Apparently some devices are very picky on details :) made just 2 days ago, see here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ You also might consider that according to the device driver output your running a 40pin non-UDMA cable on what looks like a UDMA drive, which is a no-no, it might simply be a cabling issue with bad cables in your system. If you really do have an 80 pin cable then try exchanging it with another one, and remember, the blue connector goes to the adapter card, the black connector to the drive, and the grey to the secondary drive, if there is one. I don't have any more pull getting PR's worked on, but I have found that if they are properly filed then they get worked on faster. For example, the PR system isn't an appropriate place for complaining that a mirror site is missing miniinst.iso file - you should contact the mirror administrator of the mirror in question, directly. And you might also consider that there is a 20MB file named 5.4-RELEASE-i386-bootonly.iso in the release directory - see for example: ftp://ftp13.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/5.4/ and that there IS NOT a miniinst.iso file in the master FTP location, see: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/5.4/ I would guess maybe they renamed it? Also, you cannot assume a mirror site is going to have a good copy of stable anyway. You can only assume mirrors are going to be accurate for RELEASES, as there's always propagation time from when changes are made. If your traking snapshots you should be using ftp://current.freebsd.org/pub/FreeBSD/snapshots/ Ted Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of fbsd_user Sent: Sunday, May 15, 2005 4:41 AM To: Ted Mittelstaedt; [EMAIL PROTECTED] ORG Cc: [EMAIL PROTECTED] Subject: RE: 5.4 install disc1 will not find hard drive -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of fbsd_user Sent: Saturday, May 14, 2005 12:54 PM To: [EMAIL PROTECTED] ORG Cc: [EMAIL PROTECTED] Subject: 5.4 install disc1 will not find hard drive Power management and APIC have been bios disabled since version FreeBSD 3.4 version so that is not the problem. I tried selecting safe option to boot and still get same error 'no hard disk found. My hard drive is an western digital 310100 on ata0 as master. When using this 5.4 install cd on other pc/ motherboard/ hard drive combos I get same error. I think there is something wrong with the build process of the disc1.iso file. I don't think there is anything wrong with the build process of disc1.iso. I think instead that someone made a change in the atapi driver that broke this. I have a Intel Desktop Motherboard VC820 that this exact thing happened to. In my case, I fortunately was running a Hipoint RAID card in it so the only thing that got wacked was the system now does not recognize that there is a CDROM on the secondary onboard IDE controller. Last week I had it running FreeBSD 4.11 just fine. (not on the RAID controller) I had assumed that using the RAID controller made it so that the onboard ATAPI controller had some problem, but after seeing this post it is clear that they broke the driver. DO you want to file a PR or should I? Ted -Original Message- From: Ted Mittelstaedt [mailto:[EMAIL PROTECTED] Sent: Sunday, May 15, 2005 12:38 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] ORG Cc: [EMAIL PROTECTED] Subject: RE: 5.4 install disc1 will not find hard drive Ted. I filed a PR on the missing miniinst.iso file. http://www.freebsd.org/cgi/query-pr.cgi?pr=80861 And it's not been addressed yet. So if you have some pull in getting PR's worked on then you should file the PR on this problem. As I see this, it's a show stopper in distributing 5.4 stable and needs to be addressed immediately because all the mirror FTP sites are populated with non-functional disc1 iso files. Here are some more details from the boot of disc1. The btx loader issues this messages bios drive C: is disk1 and near the end of the boot messages I get ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata1-master; setting pio4 on VIA 82C596B chip Please send me the PR number after you report this so I can track it. Thanks ___ freebsd-questions
RE: 5.4 install disc1 will not find hard drive
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of fbsd_user Sent: Saturday, May 14, 2005 12:54 PM To: [EMAIL PROTECTED] ORG Cc: [EMAIL PROTECTED] Subject: 5.4 install disc1 will not find hard drive Power management and APIC have been bios disabled since version FreeBSD 3.4 version so that is not the problem. I tried selecting safe option to boot and still get same error 'no hard disk found. My hard drive is an western digital 310100 on ata0 as master. When using this 5.4 install cd on other pc/ motherboard/ hard drive combos I get same error. I think there is something wrong with the build process of the disc1.iso file. I don't think there is anything wrong with the build process of disc1.iso. I think instead that someone made a change in the atapi driver that broke this. I have a Intel Desktop Motherboard VC820 that this exact thing happened to. In my case, I fortunately was running a Hipoint RAID card in it so the only thing that got wacked was the system now does not recognize that there is a CDROM on the secondary onboard IDE controller. Last week I had it running FreeBSD 4.11 just fine. (not on the RAID controller) I had assumed that using the RAID controller made it so that the onboard ATAPI controller had some problem, but after seeing this post it is clear that they broke the driver. DO you want to file a PR or should I? Ted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
