Re: [RFC] Re: nozomi version 2.1d for review
Hi Frank I was wondering if you had a git tree somewhere I could pull. Thanks Mike On 11/11/2007, Frank Seidel <[EMAIL PROTECTED]> wrote: > Hello, > > this one also holds the - little reworked and optimized - > cleanup of the read/write_mem32 functions. > > Comments and any feedback is more than welcome. > > Thanks a lot - especially to Jiri, Alan and Greg, > Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibility of adding -march=native to x86
> > Half the time it's easier doing a lsmod when booted on a livecd and > > trying to figure out what options are required from the module names > > which sometime can be just as tricky. > > Sure, distributions already have solved this and you can use their > work. I like compiling my own kernel it's just a pain doing it the first time on a new motherboard or when adding a new piece of hardware > > Maybe even having a make addnewhardware option to quickly add extra > > devices to your config file. > > Knowing your CPU is much easier to figure out than to figure out the > BIOS settings of your SATA controller that determine how to access it. So how do distro's figure out which driver to use? Isn't it a matter of taking the pci-ids and selecting the correct driver? > If you do not even know what CPU you have you should really not compile > your own kernel. It about ease of use, look at the new core2 architecture, if your gcc is new enough there is a march=core2 else you use an older flag Same with the new cell architecture you use cell if your using gcc 4.3 alpha or 930 if it's not that new. What I'm saying is sometimes GCC or the Kernel is better at making these decisions or at least make it easier Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibility of adding -march=native to x86
> What exactly is irritating? > Please name the problems so that they can be fixed. > > > Detecting the cpu and using march=native could be all part of that > > You don't need march=native for this. > > You have to set the right config option for your CPU and you > automatically get the right compiler options. Well when doing a lspci here are some specific examples: 03:02.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) What modules would you think you'd need to compile to get this to work? No it's not budget card os buget card ci even though the card its self has no cam interface 00:14.2 Audio device: ATI Technologies Inc SB600 Azalia Is there any indication from this piece of info that the intel hda driver is required? 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA This uses AHCI As for the i2c and the hardware monitoring support well that's mostly guess work Half the time it's easier doing a lsmod when booted on a livecd and trying to figure out what options are required from the module names which sometime can be just as tricky. Why not auto detect the CPU the same way GCC does and automatically set the correct CPU and then go the whole hog and let GCC use the correct flags if it's new enough using native I can't understand why you wouldn't find this useful when setting up a customised kernel. Maybe even having a make addnewhardware option to quickly add extra devices to your config file. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibility of adding -march=native to x86
On 25/10/2007, Gabriel C <[EMAIL PROTECTED]> wrote: > Michael Lothian wrote: > >> The MPENTIUM4 option does not only set -march=pentium4, it also enables > >> several other options in arch/i386/Kconfig.cpu resulting in better > >> performance. > > > > How about an autodetect to set the right options here too using cpuid? > > > > With a warning of course that the code produced will be specifically > > for the native cpu that it's compiled on. > > And kill off all Distro kernels right ? IMO to set that auto magically is bad. > > Regards, > > Gabriel > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Yes for something like a distro kernel it is bad but as I said before this isn't what this is for. Eventually it would be nice to to a make localkernel and for a customised kernel to be build compiling in all pci / pci express drivers into the kernel and all usb devices as modules. Auto magically detecting the cpu would be part of that I hate getting a new piece of kit and then have to figure out from lspci which options need to be turned on and the the really iritation part of finding the option in make menuconfig Detecting the cpu and using march=native could be all part of that Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibility of adding -march=native to x86
> The MPENTIUM4 option does not only set -march=pentium4, it also enables > several other options in arch/i386/Kconfig.cpu resulting in better > performance. How about an autodetect to set the right options here too using cpuid? With a warning of course that the code produced will be specifically for the native cpu that it's compiled on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibility of adding -march=native to x86
On 25/10/2007, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Thu, Oct 25, 2007 at 08:09:56PM +0100, Michael Lothian wrote: > > Actually I changed the Makefile.cpu and changed the -march to native > > which did slightly change the size of the kernel (slightly larger I > > think) > > > > So what else does that option change? > > Look at arch/i386/Kconfig.cpu > Can you be a bit more specific? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibility of adding -march=native to x86
Actually I changed the Makefile.cpu and changed the -march to native which did slightly change the size of the kernel (slightly larger I think) So what else does that option change? Mike On 25/10/2007, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Thu, Oct 25, 2007 at 07:33:35PM +0100, Michael Lothian wrote: > > Hi > > > > I was wondering if it was possible to add -march=native support to the > > processor options of the new x86 architecture if gcc 4.2 or greater is being > > used. > > > > I'm not suggesting this should be a default at all, merely an extra option > > similar to selecting P4, Athlon or even -Os. > > > > I've manually tried this flag at home with no ill effects. > > Selecting your CPU in the kernel configuration has more effects than > just setting the gcc flag, so it wouldn't gain you anything since you > anyway have to choose the correct CPU. > > > Mike > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Possibility of adding -march=native to x86
Hi I was wondering if it was possible to add -march=native support to the processor options of the new x86 architecture if gcc 4.2 or greater is being used. I'm not suggesting this should be a default at all, merely an extra option similar to selecting P4, Athlon or even -Os. I've manually tried this flag at home with no ill effects. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Merging Nozomi Driver
Hi I was wondering if there are any plans to merge the Nozomi driver which has been living in mm for quite a while now into the main line kernel. I spoke about this a wee bitafter rc1 of 2.6.22 but I´m not sure if the discussed clean up was ever implemented I´d be greatful for any info Thanks Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
I would probably have recommended an Intel chipset they have truly open drivers which are coming along an absolute treat. Hopefully the Neuveau drivers will get to a usable stage soon and the r300 (for radeon cards) will start to support r400 and r500 cards, Mike On 27/06/07, Marc Perkel <[EMAIL PROTECTED]> wrote: If I were to try a different brand of video card to get 1680x1050 where the main criteria was "just works", what brand should I get? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
OK where to start? Firstly this is really the wrong list your writing to. Chances are you'll be wanting to ask your question at http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14 if your using the Nvidia Blob otherwise if your using the 2D only NV driver then you should really aim your question at the Xorg guys and gals Secondly how exactly did you tell it differently? Chances are your /etc/conf.d/xorg.conf is wrong if you were using the latest X server with the latest binary blob (nvidia driver) chances are it would detect the highest resolution and set it for you. The program nvidia-xconfig should fix the file for you. Oh and thirdly do you really think it just works on windows is a good incentive to get people to help you? Yes it should work out the box but unfortunately the world of Linux 3D drivers is mostly dominated with company's that prefers keeping their drivers in a black box and hopefully in the not too distant future the neuveau project might remedy this. Any way I hope this e-mail both helps with your problems and adds to your understanding of how things work. The kernel mailing list is for kernel issues (which include rivafb and nvidiafb but not nv and nvidia 3d issues) so if you ever plug in a hard drive and it's not working at full speed or something along those lines that's when you should call. Cheers Mike On 27/06/07, Marc Perkel <[EMAIL PROTECTED]> wrote: Trying to get my Asus M2NPV-VM motherboard and my Samsung SyncMaster 215tw Digital to work in 1680x1050 mode but 1280x1024 is the most I can get. Chip Set is GeForce 6150. Looking in Xorg.0.log it ssems to think that the panel size is 1280x1024 in spite of my setting telling it differently. Sorry if this is off topic but I thought that the smart people would be here. In Windows I just plug it in and it works. So I figure Linux should work too. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v13
Just thought I'd let you know that CFS is working on the PS3 neutrino boot # dmesg Using PS3 machine description Page orders: linear mapping = 24, virtual = 12, io = 12 Starting Linux PPC64 #1 SMP Fri May 18 09:26:38 UTC 2007 - ppc64_pft_size= 0x14 physicalMemorySize= 0x800 ppc64_caches.dcache_line_size = 0x80 ppc64_caches.icache_line_size = 0x80 htab_address = 0x htab_hash_mask= 0x1fff - Linux version 2.6.22-rc1-cfs-v13 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #1 SMP Fri May 18 09:26:38 UTC 2007 It feels more responsive but I shall do more testing and see if there are any real benefits On 17/05/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: i'm pleased to announce release -v13 of the CFS scheduler patchset. The CFS patch against v2.6.22-rc1, v2.6.21.1 or v2.6.20.10 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ -v13 is a fixes-only release. It fixes a smaller accounting bug, so if you saw small lags during desktop use under certain workloads then please re-check that workload under -v13 too. It also tweaks SMP load-balancing a bit. (Note: the load-balancing artifact reported by Peter Williams is not a CFS-specific problem and he reproduced it in v2.6.21 too. Nevertheless -v13 should be less prone to such artifacts.) I know about no open CFS regression at the moment, so please re-test -v13 and if you still see any problem please re-report it. Thanks! Changes since -v12: - small tweak: made the "fork flow" of reniced tasks zero-sum - debugging update: /proc//sched is now seqfile based and echoing 0 to it clears the maximum-tracking counters. - more debugging counters - small rounding fix to make the statistical average of rounding errors zero - scale both the runtime limit and the granularity on SMP too, and make it dependent on HZ - misc cleanups As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome, Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
