From rolf.offermanns at gmx.net Wed Sep 2 15:45:50 2009 From: rolf.offermanns at gmx.net (Rolf Offermanns) Date: Wed, 02 Sep 2009 17:45:50 +0200 Subject: F11 - vmlinuz-2.6.29.6-217.2.16.fc11.i586 does not boot In-Reply-To: <4A97D0A3.40302@gmail.com> References: <4A97CEE9.5090908@gmx.net> <4A97D0A3.40302@gmail.com> Message-ID: <4A9E932E.90508@gmx.net> Aioanei Rares wrote: > On 08/28/2009 03:34 PM, Rolf Offermanns wrote: >> Hi All, >> >> I recently updatet my kernel first to vmlinuz-2.6.29.6-217.2.8.fc11.i586 >> and then to vmlinuz-2.6.29.6-217.2.16.fc11.i586 and neither of them >> bootet on my system. >> >> Currently I am back to vmlinuz-2.6.29.6-217.2.3.fc11.i586 which runs >> fine. >> >> My kernel commandline looks like this: "rhgb quiet nomodeset" (mode >> setting never worked right for me). >> >> The only thing I get to see when booting one of the not working kernels >> is the output of the usb probing with my mouse being the last device >> found. After this the system just does nothing. It does not hang >> completely though since I am able to reboot with ctrl-alt-delete. If I >> press those keys, the kernel prints "md: stopping all devices" (or >> something very similar) and reboots. [...] > Try removing your USB mouse and see if it boots. Nope, that didn't change anything. Any other ideas. What can I do to track this down? -Rolf From remotestar at live.com Wed Sep 2 21:22:21 2009 From: remotestar at live.com (Markus Kesaromous) Date: Wed, 2 Sep 2009 14:22:21 -0700 Subject: F11 - vmlinuz-2.6.29.6-217.2.16.fc11.i586 does not boot In-Reply-To: <4A9E932E.90508@gmx.net> References: <4A97CEE9.5090908@gmx.net> <4A97D0A3.40302@gmail.com> <4A9E932E.90508@gmx.net> Message-ID: > Date: Wed, 2 Sep 2009 17:45:50 +0200 > From: rolf.offermanns at gmx.net > To: fedora-kernel-list at redhat.com > CC: schaiba at gmail.com > Subject: Re: F11 - vmlinuz-2.6.29.6-217.2.16.fc11.i586 does not boot > > Aioanei Rares wrote: >> On 08/28/2009 03:34 PM, Rolf Offermanns wrote: >>> Hi All, >>> >>> I recently updatet my kernel first to vmlinuz-2.6.29.6-217.2.8.fc11.i586 >>> and then to vmlinuz-2.6.29.6-217.2.16.fc11.i586 and neither of them >>> bootet on my system. >>> >>> Currently I am back to vmlinuz-2.6.29.6-217.2.3.fc11.i586 which runs >>> fine. >>> >>> My kernel commandline looks like this: "rhgb quiet nomodeset" (mode >>> setting never worked right for me). >>> >>> The only thing I get to see when booting one of the not working kernels >>> is the output of the usb probing with my mouse being the last device >>> found. After this the system just does nothing. It does not hang >>> completely though since I am able to reboot with ctrl-alt-delete. If I >>> press those keys, the kernel prints "md: stopping all devices" (or >>> something very similar) and reboots. > [...] >> Try removing your USB mouse and see if it boots. > > Nope, that didn't change anything. Any other ideas. What can I do to > track this down? > > -Rolf You are having exactly the same problem I had with 2.6.3x kernels which obtained from the development tree, and compiled on F11. I never was able to get to the bottom of it. _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009 From aris at redhat.com Thu Sep 3 15:48:42 2009 From: aris at redhat.com (Aristeu Rozanski) Date: Thu, 3 Sep 2009 11:48:42 -0400 Subject: CONFIG_CC_OPTIMIZE_FOR_SIZE? Message-ID: <20090903154841.GC24318@redhat.com> Hi, does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I thought that option was useful for embedded systems only. Thanks -- Aristeu From acme at redhat.com Thu Sep 3 16:01:55 2009 From: acme at redhat.com (Arnaldo Carvalho de Melo) Date: Thu, 3 Sep 2009 13:01:55 -0300 Subject: CONFIG_CC_OPTIMIZE_FOR_SIZE? In-Reply-To: <20090903154841.GC24318@redhat.com> References: <20090903154841.GC24318@redhat.com> Message-ID: <20090903160155.GA3262@ghostprotocols.net> Em Thu, Sep 03, 2009 at 11:48:42AM -0400, Aristeu Rozanski escreveu: > Hi, > does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I > thought that option was useful for embedded systems only. IIRC because it makes the kernel faster :-) - Arnaldo From davej at redhat.com Thu Sep 3 16:14:45 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 3 Sep 2009 12:14:45 -0400 Subject: CONFIG_CC_OPTIMIZE_FOR_SIZE? In-Reply-To: <20090903160155.GA3262@ghostprotocols.net> References: <20090903154841.GC24318@redhat.com> <20090903160155.GA3262@ghostprotocols.net> Message-ID: <20090903161445.GB1270@redhat.com> On Thu, Sep 03, 2009 at 01:01:55PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Sep 03, 2009 at 11:48:42AM -0400, Aristeu Rozanski escreveu: > > Hi, > > does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I > > thought that option was useful for embedded systems only. > > IIRC because it makes the kernel faster :-) The reduced icache pressure makes it a win. As a bonus some non-performance-sensitive code (like the acpi interpretor) gets a _lot_ smaller on-disk. Dave From remotestar at live.com Fri Sep 4 05:08:13 2009 From: remotestar at live.com (Markus Kesaromous) Date: Thu, 3 Sep 2009 22:08:13 -0700 Subject: Building kernel-2.6.31-0.190 rawhide in F11 Message-ID: Build, instal and boot went fine, except radeon driver does not work. Radeon works just fine in 2.6.29.6-217.2.16.fc11.i586, but not in 2.6.31-0.190... Here's /var/log/Xorg.0.log: X.Org X Server 1.6.1.901 (1.6.2 RC 1) Release Date: 2009-5-8 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-128.1.6.el5 i686 Current Operating System: Linux localhost.localdomain 2.6.31-rc8.fc11.i586 #1 SMP PREEMPT Wed Sep 2 20:59:16 PDT 2009 i686 Kernel command line: ro root=UUID=7cf783f9-8bbb-421c-a919-fd7f6d9ab463 rhgb quiet Build Date: 18 May 2009 02:47:59PM Build ID: xorg-x11-server 1.6.1.901-1.fc11 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 3 18:00:01 2009 (II) Loader magic: 0x640 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (--) using VT number 7 (--) PCI:*(0 at 1:0:0) ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] rev 0, Mem @ 0xf0000000/134217728, 0xfeaf0000/65536, I/O @ 0x0000c800/256, BIOS @ 0x????????/131072 (==) Using default built-in configuration (30 lines) (==) --- Start of built-in configuration --- Section "Device" Identifier "Builtin Default ati Device 0" Driver "ati" EndSection Section "Screen" Identifier "Builtin Default ati Screen 0" Device "Builtin Default ati Device 0" EndSection Section "Device" Identifier "Builtin Default vesa Device 0" Driver "vesa" EndSection Section "Screen" Identifier "Builtin Default vesa Screen 0" Device "Builtin Default vesa Device 0" EndSection Section "Device" Identifier "Builtin Default fbdev Device 0" Driver "fbdev" EndSection Section "Screen" Identifier "Builtin Default fbdev Screen 0" Device "Builtin Default fbdev Device 0" EndSection Section "ServerLayout" Identifier "Builtin Default Layout" Screen "Builtin Default ati Screen 0" Screen "Builtin Default vesa Screen 0" Screen "Builtin Default fbdev Screen 0" EndSection (==) --- End of built-in configuration --- (==) ServerLayout "Builtin Default Layout" (**) |-->Screen "Builtin Default ati Screen 0" (0) (**) | |-->Monitor "" (**) | |-->Device "Builtin Default ati Device 0" (==) No monitor specified for screen "Builtin Default ati Screen 0". Using a default monitor configuration. (**) |-->Screen "Builtin Default vesa Screen 0" (1) (**) | |-->Monitor "" (**) | |-->Device "Builtin Default vesa Device 0" (==) No monitor specified for screen "Builtin Default vesa Screen 0". Using a default monitor configuration. (**) |-->Screen "Builtin Default fbdev Screen 0" (2) (**) | |-->Monitor "" (**) | |-->Device "Builtin Default fbdev Device 0" (==) No monitor specified for screen "Builtin Default fbdev Screen 0". Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) No APM support in BIOS or kernel (II) System resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [22] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [23] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "ati" (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.6.1, module version = 6.12.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "radeon" (II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.1, module version = 6.12.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "vesa" (II) Loading /usr/lib/xorg/modules/drivers//vesa_drv.so (II) Module vesa: vendor="X.Org Foundation" compiled for 1.6.0, module version = 2.2.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "fbdev" (II) Loading /usr/lib/xorg/modules/drivers//fbdev_drv.so (II) Module fbdev: vendor="X.Org Foundation" compiled for 1.6.0, module version = 0.4.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Radeon RV730 (AGP), ATI FirePro M5750, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon RV710, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, ATI Radeon HD Graphics, ATI Radeon Graphics, ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics, ATI Radeon Graphics (II) VESA: driver for VESA chipsets: vesa (II) FBDEV: driver for framebuffer: fbdev (II) Primary Device is: PCI 01 at 00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [22] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [23] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (WW) Falling back to old probe method for vesa (WW) Falling back to old probe method for fbdev (II) Loading sub module "fbdevhw" (II) LoadModule: "fbdevhw" (II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so (II) Module fbdevhw: vendor="X.Org Foundation" compiled for 1.6.1.901, module version = 0.0.2 ABI class: X.Org Video Driver, version 5.0 (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [21] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [22] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [23] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [24] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [25] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [26] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [27] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [28] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [29] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [30] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [31] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [32] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [33] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [34] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): Creating default Display subsection in Screen section "Builtin Default ati Screen 0" for depth/fbbpp 24/32 (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: "ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)" (ChipID = 0x4e50) (II) RADEON(0): AGP card detected drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEON(0): Output VGA-0 has no monitor section (II) RADEON(0): Output LVDS has no monitor section (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): EDID for output LVDS (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1280x800"x60.0 68.90 1280 1288 1328 1408 800 800 803 816 (48.9 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output VGA-0 disconnected (II) RADEON(0): Output LVDS connected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output LVDS using initial mode 1280x800 initing gart:8000000 vram: s:8000000 v:7c00000 (II) UnloadModule: "radeon" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. _________________________________________________________________ Get back to school stuff for them and cashback for you. http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1 From pebolle at tiscali.nl Fri Sep 4 08:38:44 2009 From: pebolle at tiscali.nl (Paul Bolle) Date: Fri, 04 Sep 2009 10:38:44 +0200 Subject: Building kernel-2.6.31-0.190 rawhide in F11 In-Reply-To: References: Message-ID: <1252053524.1597.15.camel@localhost.localdomain> On Thu, 2009-09-03 at 22:08 -0700, Markus Kesaromous wrote: > Build, instal and boot went fine, except radeon driver does not work. > Radeon works just fine in 2.6.29.6-217.2.16.fc11.i586, but not > in 2.6.31-0.190... That could be some sort of mismatch between that Rawhide kernel and the F11 X Server you seem to use (Rawhide currently uses X.Org X Server 1.6.99.1). I'd try one of the following kernel command line options: nomodeset radeon.modeset=0 Those could be used to work around some issues with Rawhide's Radeon kernel driver (or Rawhide's Radeon X module, or whatever) a few weeks back. (It' s just a guess though. I hardly know anything about the way the kernel and the X Server interact.) Paul Bolle From remotestar at live.com Sat Sep 5 03:04:35 2009 From: remotestar at live.com (Markus Kesaromous) Date: Fri, 4 Sep 2009 20:04:35 -0700 Subject: Building kernel-2.6.31-0.190 rawhide in F11 In-Reply-To: <1252053524.1597.15.camel@localhost.localdomain> References: <1252053524.1597.15.camel@localhost.localdomain> Message-ID: ---------------------------------------- > From: pebolle at tiscali.nl > To: remotestar at live.com > Date: Fri, 4 Sep 2009 10:38:44 +0200 > CC: fedora-kernel-list at redhat.com > Subject: Re: Building kernel-2.6.31-0.190 rawhide in F11 > > On Thu, 2009-09-03 at 22:08 -0700, Markus Kesaromous wrote: >> Build, instal and boot went fine, except radeon driver does not work. >> Radeon works just fine in 2.6.29.6-217.2.16.fc11.i586, but not >> in 2.6.31-0.190... > > That could be some sort of mismatch between that Rawhide kernel and the > F11 X Server you seem to use (Rawhide currently uses X.Org X Server > 1.6.99.1). I'd try one of the following kernel command line options: > > nomodeset > radeon.modeset=0 > > Those could be used to work around some issues with Rawhide's Radeon > kernel driver (or Rawhide's Radeon X module, or whatever) a few weeks > back. (It' s just a guess though. I hardly know anything about the way > the kernel and the X Server interact.) > > > Paul Bolle > Thank you Paul. nomodeset was accepted as a boot arg. radeon.modeset=0 was not recognized as a valid boot arg. However, nomodeset did the trick. I now have X up under the auspices of kernel-2.6.31-rc8.fc11.i586 Other observations: after I edited the boot args and added the nomodeset radeo.moseset=0 and pressed b to boot, it took almost 3 minutes to get the login prompt. Even after logging in, it took more than 1 minute to populate the screen with all my icons: about 55 of them. Also, starting up Firefox and thunderbird also took considerably longer. Sorry for not providing an objective time value in terms of how much slower they started - should have timed them ! To provide some comparison with other kernels: 2.6.29.6-217.2.16.fc11.i586 boots to the login prompt in 1.5 minutes. 2.6.29.5.191.fc11.586 booted to login prompt in 38 seconds. On same dual boot machine, Windows XP boots to login prompt in 30 seconds. Cheers, MK _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009 From remotestar at live.com Sat Sep 5 14:55:02 2009 From: remotestar at live.com (Markus Kesaromous) Date: Sat, 5 Sep 2009 07:55:02 -0700 Subject: Building kernel-2.6.31-0.190 rawhide in F11 In-Reply-To: <1252053524.1597.15.camel@localhost.localdomain> References: <1252053524.1597.15.camel@localhost.localdomain> Message-ID: ---------------------------------------- > From: remotestar at live.com > CC: fedora-kernel-list at redhat.com > Subject: RE: Building kernel-2.6.31-0.190 rawhide in F11 > Date: Fri, 4 Sep 2009 20:04:35 -0700 > > > > > ---------------------------------------- >> From: pebolle at tiscali.nl >> To: remotestar at live.com >> Date: Fri, 4 Sep 2009 10:38:44 +0200 >> CC: fedora-kernel-list at redhat.com >> Subject: Re: Building kernel-2.6.31-0.190 rawhide in F11 >> >> On Thu, 2009-09-03 at 22:08 -0700, Markus Kesaromous wrote: >>> Build, instal and boot went fine, except radeon driver does not work. >>> Radeon works just fine in 2.6.29.6-217.2.16.fc11.i586, but not >>> in 2.6.31-0.190... >> >> That could be some sort of mismatch between that Rawhide kernel and the >> F11 X Server you seem to use (Rawhide currently uses X.Org X Server >> 1.6.99.1). I'd try one of the following kernel command line options: >> >> nomodeset >> radeon.modeset=0 >> >> Those could be used to work around some issues with Rawhide's Radeon >> kernel driver (or Rawhide's Radeon X module, or whatever) a few weeks >> back. (It' s just a guess though. I hardly know anything about the way >> the kernel and the X Server interact.) >> >> >> Paul Bolle >> > > Thank you Paul. > > nomodeset was accepted as a boot arg. radeon.modeset=0 was not recognized as a valid boot arg. > > However, nomodeset did the trick. I now have X up under the auspices > of kernel-2.6.31-rc8.fc11.i586 > > Other observations: > after I edited the boot args and added the nomodeset radeo.moseset=0 > and pressed b to boot, it took almost 3 minutes to get the login prompt. > Even after logging in, it took more than 1 minute to populate the screen with all my icons: about 55 of them. > > Also, starting up Firefox and thunderbird also took considerably longer. > Sorry for not providing an objective time value in terms of how much > slower they started - should have timed them ! > > To provide some comparison with other kernels: > 2.6.29.6-217.2.16.fc11.i586 boots to the login prompt in 1.5 minutes. > 2.6.29.5.191.fc11.586 booted to login prompt in 38 seconds. > On same dual boot machine, Windows XP boots to login prompt in > 30 seconds. > > Cheers, > > MK I timed the boot to login prompt duration again for kernel-2.6.31-0.190 and this time it took only 84 seconds. First timing may have been affected by other factors - fsck??? MK _________________________________________________________________ Get back to school stuff for them and cashback for you. http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1 From remotestar at live.com Mon Sep 7 21:27:24 2009 From: remotestar at live.com (Markus Kesaromous) Date: Mon, 7 Sep 2009 14:27:24 -0700 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm Message-ID: Still not fixed: arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined _________________________________________________________________ Get back to school stuff for them and cashback for you. http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1 From snecklifter at gmail.com Mon Sep 7 21:41:24 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 7 Sep 2009 22:41:24 +0100 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: References: Message-ID: <364d303b0909071441j514d7fa5j1a8ee0c13a2ffa53@mail.gmail.com> 2009/9/7 Markus Kesaromous : > > Still not fixed: > > arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined Correct. You will see this in 2.6.31. http://lkml.org/lkml/2009/7/14/164 Regards -- Christopher Brown From jwboyer at gmail.com Mon Sep 7 22:17:38 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 7 Sep 2009 18:17:38 -0400 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: References: Message-ID: <20090907221738.GB10173@hansolo.jdub.homelinux.org> On Mon, Sep 07, 2009 at 02:27:24PM -0700, Markus Kesaromous wrote: > >Still not fixed: > >arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined Please stop posting such messages here. josh From remotestar at live.com Tue Sep 8 00:16:27 2009 From: remotestar at live.com (Markus Kesaromous) Date: Mon, 7 Sep 2009 17:16:27 -0700 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: <20090907221738.GB10173@hansolo.jdub.homelinux.org> References: <20090907221738.GB10173@hansolo.jdub.homelinux.org> Message-ID: ---------------------------------------- > Date: Mon, 7 Sep 2009 18:17:38 -0400 > From: jwboyer at gmail.com > To: remotestar at live.com > CC: fedora-kernel-list at redhat.com > Subject: Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm > > On Mon, Sep 07, 2009 at 02:27:24PM -0700, Markus Kesaromous wrote: >> >>Still not fixed: >> >>arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined > > Please stop posting such messages here. > > josh Why? What gives you the right to say what gets posted or does not get posted here ? This is the fedora kernel list. I posted an issue with the latest fedora kernel source. If you have a problem with that, I strongly encourage you to unsubscribe from this list. MK _________________________________________________________________ Hotmail? is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009 From jwboyer at gmail.com Tue Sep 8 02:16:22 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 7 Sep 2009 22:16:22 -0400 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: References: <20090907221738.GB10173@hansolo.jdub.homelinux.org> Message-ID: <20090908021622.GC10173@hansolo.jdub.homelinux.org> >>>Still not fixed: >>> >>>arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined >> >> Please stop posting such messages here. >> >> josh > >Why? Because this is not bugzilla. Posting emails here on issues you've already reported and are applicable to upstream isn't really going to do anything. Bugs (like your radeon issue) should be reported in bugzilla. josh From pebolle at tiscali.nl Tue Sep 8 08:24:09 2009 From: pebolle at tiscali.nl (Paul Bolle) Date: Tue, 08 Sep 2009 10:24:09 +0200 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: <20090908021622.GC10173@hansolo.jdub.homelinux.org> References: <20090907221738.GB10173@hansolo.jdub.homelinux.org> <20090908021622.GC10173@hansolo.jdub.homelinux.org> Message-ID: <1252398249.6265.7.camel@x61.thuisdomein> On Mon, 2009-09-07 at 22:16 -0400, Josh Boyer wrote: > Bugs (like your radeon issue) should be reported in bugzilla. The radeon issue I'm familiar with was related to running a (locally rebuild) Rawhide kernel rpm on a Fedora 11 installation. That caused some problems with the Fedora 11 X Server radeon stuff. I don't think bugzilla will be of much use for an issue like that. Paul Bolle From snecklifter at gmail.com Tue Sep 8 12:25:56 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 8 Sep 2009 13:25:56 +0100 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: References: <20090907221738.GB10173@hansolo.jdub.homelinux.org> Message-ID: <364d303b0909080525p126a5b0ds857d31a83d3a4ad0@mail.gmail.com> 2009/9/8 Markus Kesaromous : > > > > ---------------------------------------- >> Date: Mon, 7 Sep 2009 18:17:38 -0400 >> From: jwboyer at gmail.com >> To: remotestar at live.com >> CC: fedora-kernel-list at redhat.com >> Subject: Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm >> >> On Mon, Sep 07, 2009 at 02:27:24PM -0700, Markus Kesaromous wrote: >>> >>>Still not fixed: >>> >>>arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined >> >> Please stop posting such messages here. >> >> josh > > Why? > What gives you the right to say what gets posted or does not get posted ?here ? > > This is the fedora kernel list. I posted an issue with the latest fedora kernel source. No, you didn't. The latest fedora kernel source is found in rawhide. > If you have a problem with that, I strongly encourage you to unsubscribe from this list. The problem Markus is that you have already had your query responded to and it took me a very small amount of time to discover the problem was fixed in 2.6.31. Messages like the ones above detract from people's time spent developing the kernel and as such you were asked to not post messages of this nature. Please respect that - contributions such as patches to enable the kernel to build are most welcome however. Regards -- Christopher Brown From cebbert at redhat.com Wed Sep 9 20:29:26 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 9 Sep 2009 16:29:26 -0400 Subject: snd-vxpocket in kernel not enabled in fedora ? In-Reply-To: <4A986DB0.5010301@tom-ipp.info> References: <4A986DB0.5010301@tom-ipp.info> Message-ID: <20090909162926.51f3c87e@dhcp-100-2-144.bos.redhat.com> On Sat, 29 Aug 2009 01:52:16 +0200 tom-ipp wrote: > Hello, > I assume it's the place to ask my question : > is there some known reason to not enable the module alsa snd-vxpocket, > for the digigram soundcard? > Otherwise, due to its audio quality, and despite of its long life, it > should be included in the fedora kernel... > Compilation of the module from alsa 1.0.20 lib is ok. Wow, $618 from B&H. We can enable it in rawhide/F-12 I guess. From cebbert at redhat.com Wed Sep 9 20:40:39 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 9 Sep 2009 16:40:39 -0400 Subject: Compiling kernel-2.6.30.5-43.fc11.src.rpm In-Reply-To: References: Message-ID: <20090909164039.4e3f1a70@dhcp-100-2-144.bos.redhat.com> On Mon, 7 Sep 2009 14:27:24 -0700 Markus Kesaromous wrote: > > Still not fixed: > > arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined > > It really is just a warning, arising because the kernel gets built with -Wundef. From caedmon.maillist at gmail.com Thu Sep 10 01:13:15 2009 From: caedmon.maillist at gmail.com (chen caedmon) Date: Thu, 10 Sep 2009 09:13:15 +0800 Subject: Fedora 11 EFI installation issue. Message-ID: hi, I saw http://fedoraproject.org/wiki/Features/EFI, it said it support EFI installation , so i download a iso from http://fedoraproject.org/en/get-fedora , then i burn a DVD with the iso. i try to install it in EFI way : 1. in EFI front page choose "Boot manger" 2. then in "boot option menu " choose "EFI DVD/CDROM" then i will return the step 2("boot option menu " page ), i failed to detect it in EFI way . is there any other ISO special for EFI installation ?or another method to install FC11 in EFI way? From cebbert at redhat.com Fri Sep 11 22:04:20 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 11 Sep 2009 18:04:20 -0400 Subject: Fedora kernel has branched for F-12 Message-ID: <20090911180420.11498465@dhcp-100-2-144.bos.redhat.com> The F-12 branch is now for Fedora 12, and devel is now targeted for Fedora 13. If you have updates that you don't expect to be upstream soon, please update both branches. From xose.vazquez at gmail.com Sun Sep 13 13:28:48 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Sun, 13 Sep 2009 15:28:48 +0200 Subject: update kernel in liveusb Message-ID: <4AACF390.6000506@gmail.com> hi, is there a _easy and fast_ way to update the kernel in the liveusb distribution ? -thanks- -- ?All? muevan feroz guerra, ciegos reyes por un palmo m?s de tierra; que yo aqu? tengo por m?o cuanto abarca el mar brav?o, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y d? pecho a mi valor.? From xose.vazquez at gmail.com Sun Sep 13 13:47:09 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Sun, 13 Sep 2009 15:47:09 +0200 Subject: [RFE] x86_64 kernel running in i386 distribution Message-ID: <4AACF7DD.1020809@gmail.com> hi, would it be possible to adapt the i386 distribucion to run also the x86_64 kernel ? -thanks- -- ?All? muevan feroz guerra, ciegos reyes por un palmo m?s de tierra; que yo aqu? tengo por m?o cuanto abarca el mar brav?o, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y d? pecho a mi valor.? From amit.shah at redhat.com Sun Sep 13 13:58:45 2009 From: amit.shah at redhat.com (Amit Shah) Date: Sun, 13 Sep 2009 19:28:45 +0530 Subject: [RFE] x86_64 kernel running in i386 distribution In-Reply-To: <4AACF7DD.1020809@gmail.com> References: <4AACF7DD.1020809@gmail.com> Message-ID: <20090913135845.GA5607@amit-x200.redhat.com> On (Sun) Sep 13 2009 [15:47:09], Xose Vazquez Perez wrote: > hi, > > would it be possible to adapt the i386 distribucion > to run also the x86_64 kernel ? You can just 'yum install kernel.x86_64' and that'll work. Amit From mchristi at redhat.com Tue Sep 15 18:05:53 2009 From: mchristi at redhat.com (Mike Christie) Date: Tue, 15 Sep 2009 13:05:53 -0500 Subject: [PATCH] update f12 fcoe related kernel code Message-ID: <4AAFD781.3080802@redhat.com> Hi, Sorry for the large patch. I was not sure how I should do this. I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic and dcb) kernel code that is going into fedora 12. The attached patch updates the fedora 12 kernel to what is in the SCSI maintainer and network maintainer's trees for 2.6.32-rc1. For scsi this is the scsi-misc tree http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary and for networking this is the net-next tree http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. The net and SCSI maintainer's have asked Linus to pull their trees for 2.6.32 and so the patches are in there or on there way. I think there is close to 100 patches, so I did not want to flood the list sending them individually. I could break this down into sub systems if it helps to make it reviewable. Thanks Mike From davej at redhat.com Tue Sep 15 18:22:50 2009 From: davej at redhat.com (Dave Jones) Date: Tue, 15 Sep 2009 14:22:50 -0400 Subject: [PATCH] update f12 fcoe related kernel code In-Reply-To: <4AAFD781.3080802@redhat.com> References: <4AAFD781.3080802@redhat.com> Message-ID: <20090915182250.GA20946@redhat.com> On Tue, Sep 15, 2009 at 01:05:53PM -0500, Mike Christie wrote: > Hi, > > Sorry for the large patch. I was not sure how I should do this. > > I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic and > dcb) kernel code that is going into fedora 12. The attached patch > updates the fedora 12 kernel to what is in the SCSI maintainer and > network maintainer's trees for 2.6.32-rc1. For scsi this is the > scsi-misc tree > http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary > and for networking this is the net-next tree > http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. This scares me. We're shipping 2.6.31 because we can't justify the risk of shipping rc code in a final release. With huge amounts of change like this, we're essentially doing the same thing. What justification is there for this ? (If the answer involves the acronym 'RHEL' there are better ways than shoving it into Fedora at the last minute) Dave From mchristi at redhat.com Tue Sep 15 18:45:36 2009 From: mchristi at redhat.com (Mike Christie) Date: Tue, 15 Sep 2009 13:45:36 -0500 Subject: [PATCH] update f12 fcoe related kernel code In-Reply-To: <20090915182250.GA20946@redhat.com> References: <4AAFD781.3080802@redhat.com> <20090915182250.GA20946@redhat.com> Message-ID: <4AAFE0D0.5030403@redhat.com> Dave Jones wrote: > On Tue, Sep 15, 2009 at 01:05:53PM -0500, Mike Christie wrote: > > Hi, > > > > Sorry for the large patch. I was not sure how I should do this. > > > > I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic and > > dcb) kernel code that is going into fedora 12. The attached patch > > updates the fedora 12 kernel to what is in the SCSI maintainer and > > network maintainer's trees for 2.6.32-rc1. For scsi this is the > > scsi-misc tree > > http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary > > and for networking this is the net-next tree > > http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. > > This scares me. We're shipping 2.6.31 because we can't justify the risk > of shipping rc code in a final release. With huge amounts of change > like this, we're essentially doing the same thing. There is actually going to be more patches :( There are maybe 50+ other patches floating around the linux scsi and fcoe lists that are not yet in the scsi maintainer's tree. I was going to send those patches once the review for those other patches was done upstream and the scsi maintainer had taken them. > > What justification is there for this ? > (If the answer involves the acronym 'RHEL' there are better ways > than shoving it into Fedora at the last minute) > It might be both RHEL and fedora. Hans de Goede is working on adding fcoe boot to F12, so I wanted to make sure that he and our users/testers had the most up to date fcoe kernel code. I think fcoe boot is probably getting added to F12 for RHEL though. I also need to update the fcoe code for RHEL too. From jwboyer at gmail.com Tue Sep 15 19:09:35 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 15 Sep 2009 15:09:35 -0400 Subject: [PATCH] update f12 fcoe related kernel code In-Reply-To: <4AAFE0D0.5030403@redhat.com> References: <4AAFD781.3080802@redhat.com> <20090915182250.GA20946@redhat.com> <4AAFE0D0.5030403@redhat.com> Message-ID: <20090915190935.GE3302@hansolo.jdub.homelinux.org> On Tue, Sep 15, 2009 at 01:45:36PM -0500, Mike Christie wrote: > Dave Jones wrote: >> On Tue, Sep 15, 2009 at 01:05:53PM -0500, Mike Christie wrote: >> > Hi, >> > > Sorry for the large patch. I was not sure how I should do this. >> > > I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic >> and > dcb) kernel code that is going into fedora 12. The attached >> patch > updates the fedora 12 kernel to what is in the SCSI maintainer >> and > network maintainer's trees for 2.6.32-rc1. For scsi this is the >> > scsi-misc tree > >> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary >> > and for networking this is the net-next tree > >> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. >> This scares me. We're shipping 2.6.31 because we can't justify the >> risk >> of shipping rc code in a final release. With huge amounts of change >> like this, we're essentially doing the same thing. > > There is actually going to be more patches :( There are maybe 50+ other > patches floating around the linux scsi and fcoe lists that are not yet > in the scsi maintainer's tree. I was going to send those patches once > the review for those other patches was done upstream and the scsi > maintainer had taken them. The kernel has already branched for F-12. From a rel-eng standpoint, this looks like a poor idea. Particularly, as Dave points out, there are lots of changes all over the place and you said there are even more not merged yet. I'm pretty sure rel-eng is not going to be happy with this at all, and I suggest punting it to F-13. RHEL is outside of the scope of the Fedora kernel. josh From amitshah at gmx.net Wed Sep 16 07:10:25 2009 From: amitshah at gmx.net (Amit Shah) Date: Wed, 16 Sep 2009 12:40:25 +0530 Subject: Backport virtio patches for optimised virtio-net Message-ID: <20090916071025.GC18015@amit-x200.redhat.com> Hello, Please consider pulling in http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=1cf32ed6ba54693f51f81c29b7d5f9625ec36c78 virtio:add_buf-return-capacity Rusty Russell [Wed, 2 Sep 2009 00:29:09 +0000 (10:29 +1000)] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=422c63d9e6e896b0709610b0b792b3b3541a7182 virtio:net-stop_queue-before-full Rusty Russell [Wed, 2 Sep 2009 00:29:09 +0000 (10:29 +1000)] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=1bd0e3809cd71567bb19059bb4818a9324771a40 virtio_net: Check for room in the vq before adding buffer Amit Shah [Wed, 26 Aug 2009 09:28:28 +0000 (14:28 +0530)] (in that order) for virtio-net optimisations to the F12 kernel. These patches are in Rusty's queue and should make .32. Thanks, Amit -- http://log.amitshah.net/ From kmcmartin at redhat.com Thu Sep 17 17:44:42 2009 From: kmcmartin at redhat.com (Kyle McMartin) Date: Thu, 17 Sep 2009 13:44:42 -0400 Subject: [ppc64] newer gcc breaks kernel build? Message-ID: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> - fix ppc/ppc64 -mmultiple and out of line gpr/fpr saving bugs (#519409, PR target/40677, PR target/41175) My guess is this has broken the kernel build on powerpc64: init/built-in.o: In function `arch_disable_smp_support': /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._savegpr0_31' /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._restgpr0_31' by generating calls to out of line handlers, which are only supplied for PPC32 in arch/powerpc/lib/. Any thoughts? If it's not this, it must have been something hitting rawhide between: 2009-09-16 22:06:38 and 2009-09-17 15:25:47 cheers, Kyle From kmcmartin at redhat.com Thu Sep 17 19:25:51 2009 From: kmcmartin at redhat.com (Kyle McMartin) Date: Thu, 17 Sep 2009 15:25:51 -0400 Subject: [ppc64] newer gcc breaks kernel build? In-Reply-To: <20090917190433.GP14664@tyan-ft48-01.lab.bos.redhat.com> References: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> <20090917190433.GP14664@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090917192551.GK11469@kibblesnbits.boston.devel.redhat.com> On Thu, Sep 17, 2009 at 09:04:33PM +0200, Jakub Jelinek wrote: > On Thu, Sep 17, 2009 at 01:44:42PM -0400, Kyle McMartin wrote: > > - fix ppc/ppc64 -mmultiple and out of line gpr/fpr saving bugs > > (#519409, PR target/40677, PR target/41175) > > > > My guess is this has broken the kernel build on powerpc64: > > init/built-in.o: In function `arch_disable_smp_support': > > /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._savegpr0_31' > > /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._restgpr0_31' > > > > by generating calls to out of line handlers, which are only supplied for > > PPC32 in arch/powerpc/lib/. > > > > Any thoughts? If it's not this, it must have been something hitting rawhide > > between: > > 2009-09-16 22:06:38 and > > 2009-09-17 15:25:47 > > For 64-bit code it is ld that is supposed to synthetize those symbols on the > fly. gcc uses them (newly, starting with gcc 4.5 as of a few days ago > upstream and gcc-4.4.1-14 in rawhide) even for 64-bit code when -Os, as the > out of line savers/restorers are smaller than inline register > saving/restoring. > Ah, so it's a binutils bug? (Sorry, the only reason I fingered gcc was because binutils hadn't been updated recently.) Would a workaround be to switch ppc64 back to -O2 until ld is fixed? regards, Kyle From jakub at redhat.com Thu Sep 17 19:04:33 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 17 Sep 2009 21:04:33 +0200 Subject: [ppc64] newer gcc breaks kernel build? In-Reply-To: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> References: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> Message-ID: <20090917190433.GP14664@tyan-ft48-01.lab.bos.redhat.com> On Thu, Sep 17, 2009 at 01:44:42PM -0400, Kyle McMartin wrote: > - fix ppc/ppc64 -mmultiple and out of line gpr/fpr saving bugs > (#519409, PR target/40677, PR target/41175) > > My guess is this has broken the kernel build on powerpc64: > init/built-in.o: In function `arch_disable_smp_support': > /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._savegpr0_31' > /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._restgpr0_31' > > by generating calls to out of line handlers, which are only supplied for > PPC32 in arch/powerpc/lib/. > > Any thoughts? If it's not this, it must have been something hitting rawhide > between: > 2009-09-16 22:06:38 and > 2009-09-17 15:25:47 For 64-bit code it is ld that is supposed to synthetize those symbols on the fly. gcc uses them (newly, starting with gcc 4.5 as of a few days ago upstream and gcc-4.4.1-14 in rawhide) even for 64-bit code when -Os, as the out of line savers/restorers are smaller than inline register saving/restoring. Jakub From jakub at redhat.com Thu Sep 17 19:31:52 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 17 Sep 2009 21:31:52 +0200 Subject: [ppc64] newer gcc breaks kernel build? In-Reply-To: <20090917192551.GK11469@kibblesnbits.boston.devel.redhat.com> References: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> <20090917190433.GP14664@tyan-ft48-01.lab.bos.redhat.com> <20090917192551.GK11469@kibblesnbits.boston.devel.redhat.com> Message-ID: <20090917193152.GQ14664@tyan-ft48-01.lab.bos.redhat.com> On Thu, Sep 17, 2009 at 03:25:51PM -0400, Kyle McMartin wrote: > On Thu, Sep 17, 2009 at 09:04:33PM +0200, Jakub Jelinek wrote: > > On Thu, Sep 17, 2009 at 01:44:42PM -0400, Kyle McMartin wrote: > > > - fix ppc/ppc64 -mmultiple and out of line gpr/fpr saving bugs > > > (#519409, PR target/40677, PR target/41175) > > > > > > My guess is this has broken the kernel build on powerpc64: > > > init/built-in.o: In function `arch_disable_smp_support': > > > /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._savegpr0_31' > > > /builddir/build/BUILD/kernel-2.6.31/linux-2.6.31.ppc64/init/main.c:139: undefined reference to `._restgpr0_31' > > > > > > by generating calls to out of line handlers, which are only supplied for > > > PPC32 in arch/powerpc/lib/. > > > > > > Any thoughts? If it's not this, it must have been something hitting rawhide > > > between: > > > 2009-09-16 22:06:38 and > > > 2009-09-17 15:25:47 > > > > For 64-bit code it is ld that is supposed to synthetize those symbols on the > > fly. gcc uses them (newly, starting with gcc 4.5 as of a few days ago > > upstream and gcc-4.4.1-14 in rawhide) even for 64-bit code when -Os, as the > > out of line savers/restorers are smaller than inline register > > saving/restoring. > > > > Ah, so it's a binutils bug? (Sorry, the only reason I fingered gcc was because > binutils hadn't been updated recently.) I've noticed the dot in front of the symbol, is kernel using still the for years deprecated oldish ppc64 ABI instead of the new one (i.e. uses -mcall-aixdesc instead of not using this option at all)? Maybe it is broken only in that case. > Would a workaround be to switch ppc64 back to -O2 until ld is fixed? Sure, at -O2 those aren't emitted. Jakub From kyle at mcmartin.ca Thu Sep 17 19:41:47 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 17 Sep 2009 15:41:47 -0400 Subject: [ppc64] newer gcc breaks kernel build? In-Reply-To: <20090917193152.GQ14664@tyan-ft48-01.lab.bos.redhat.com> References: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> <20090917190433.GP14664@tyan-ft48-01.lab.bos.redhat.com> <20090917192551.GK11469@kibblesnbits.boston.devel.redhat.com> <20090917193152.GQ14664@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090917194147.GC11961@bombadil.infradead.org> On Thu, Sep 17, 2009 at 09:31:52PM +0200, Jakub Jelinek wrote: > I've noticed the dot in front of the symbol, is kernel using still the for > years deprecated oldish ppc64 ABI instead of the new one (i.e. uses > -mcall-aixdesc instead of not using this option at all)? Maybe it is broken > only in that case. > arch/powerpc/Makefile: CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc Seems to... :/ > > Would a workaround be to switch ppc64 back to -O2 until ld is fixed? > > Sure, at -O2 those aren't emitted. > Groovy, I just kicked off a build with CC_OPTIMIZE_FOR_SIZE unset on ppc64, and it seems to have made it farther. Thanks! Kyle > Jakub > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > From roland at redhat.com Thu Sep 17 19:54:17 2009 From: roland at redhat.com (Roland McGrath) Date: Thu, 17 Sep 2009 12:54:17 -0700 (PDT) Subject: [ppc64] newer gcc breaks kernel build? In-Reply-To: Kyle McMartin's message of Thursday, 17 September 2009 15:41:47 -0400 <20090917194147.GC11961@bombadil.infradead.org> References: <20090917174442.GJ11469@kibblesnbits.boston.devel.redhat.com> <20090917190433.GP14664@tyan-ft48-01.lab.bos.redhat.com> <20090917192551.GK11469@kibblesnbits.boston.devel.redhat.com> <20090917193152.GQ14664@tyan-ft48-01.lab.bos.redhat.com> <20090917194147.GC11961@bombadil.infradead.org> Message-ID: <20090917195417.93EDB2721@magilla.sf.frob.com> > On Thu, Sep 17, 2009 at 09:31:52PM +0200, Jakub Jelinek wrote: > > I've noticed the dot in front of the symbol, is kernel using still the for > > years deprecated oldish ppc64 ABI instead of the new one (i.e. uses > > -mcall-aixdesc instead of not using this option at all)? Maybe it is broken > > only in that case. It would be nice if -mcall-aixdesc were even in the GCC manual. From aris at redhat.com Fri Sep 18 13:14:50 2009 From: aris at redhat.com (Aristeu Rozanski) Date: Fri, 18 Sep 2009 09:14:50 -0400 Subject: [RHEL6 PATCH] internal: properly define %{dist} and compute correct pkg_release from Makefile In-Reply-To: <1253269164-18825-1-git-send-email-pbonzini@redhat.com> References: <1253259873-15118-2-git-send-email-pbonzini@redhat.com> <1253269164-18825-1-git-send-email-pbonzini@redhat.com> Message-ID: <20090918131450.GT8246@redhat.com> > --- a/redhat/Makefile.common > +++ b/redhat/Makefile.common > @@ -1,14 +1,15 @@ > RPMBUILD := $(shell if [ -x "/usr/bin/rpmbuild" ]; then echo rpmbuild; \ > else echo rpm; fi) > MACH := $(shell uname -m) > -KVERSION:=2.6.30 > +KVERSION:=2.6.31 > # marker is git tag > -MARKER:=v2.6.31-rc5-git2 > +MARKER:=v2.6.31 are you sure? alpha2 branch is based on 2.6.31-rc5-git2 and has patches applied over. you'll create a 2.6.31 tarball and patches over it and will be without modsign patches and fedora patches at least. -- Aristeu From pbonzini at redhat.com Fri Sep 18 07:44:32 2009 From: pbonzini at redhat.com (Paolo Bonzini) Date: Fri, 18 Sep 2009 09:44:32 +0200 Subject: [RHEL6 PATCH 1/2] internal: add redhat makefile magic from RHEL 5 Message-ID: <1253259873-15118-1-git-send-email-pbonzini@redhat.com> RHEL-5 patches: cf868ddc, a294b89 Bugzilla, upstream status, Brew build: N/A The current RHEL6 tree lacks makefile magic to automatically do brew/koji builds. Also rh-* targets are not automatically forwarded to the Makefile in the redhat directories. This patch fixes this two nits. Please review and ack! --- makefile | 6 ++++++ redhat/Makefile | 5 +++++ 2 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 makefile diff --git a/makefile b/makefile new file mode 100644 index 0000000..d4f4474 --- /dev/null +++ b/makefile @@ -0,0 +1,6 @@ +ifeq ($(filter rh-%,$(MAKECMDGOALS)),) + include Makefile +else +%:: + $(MAKE) -C redhat $(@) +endif diff --git a/redhat/Makefile b/redhat/Makefile index 9bfa3c3..91d838f 100644 --- a/redhat/Makefile +++ b/redhat/Makefile @@ -104,3 +104,8 @@ rh-rpms: rh-sources rh-prep: rh-sources $(RPMBUILD) --define "_sourcedir $(SOURCES)" --define "_builddir $(RPM)/BUILD" --define "_srcrpmdir $(RPM)/SRPMS" --define "_rpmdir $(RPM)/RPMS" --define "_specdir $(RPM)/SPECS" --nodeps --target noarch -bp $(RPM)/SOURCES/kernel.spec +.PHONY: rh-brew rh-koji +rh-brew : BUILD_FLAGS ?= $(BREW_FLAGS) +rh-koji : BUILD_FLAGS ?= $(KOJI_FLAGS) +rh-brew rh-koji: rh-%: rh-srpm + $* build $(BUILD_FLAGS) $(BUILD_TARGET) $(SRPMS)/kernel-$(KVERSION)-$(RELEASE)$(DIST)$(BUILDID).src.rpm -- 1.6.2.5 From pbonzini at redhat.com Fri Sep 18 07:44:33 2009 From: pbonzini at redhat.com (Paolo Bonzini) Date: Fri, 18 Sep 2009 09:44:33 +0200 Subject: [RHEL6 PATCH 2/2] internal: fix redhat/create-patches.sh logic errors In-Reply-To: <1253259873-15118-1-git-send-email-pbonzini@redhat.com> References: <1253259873-15118-1-git-send-email-pbonzini@redhat.com> Message-ID: <1253259873-15118-2-git-send-email-pbonzini@redhat.com> This patch fixes problems I had when attempting rh-srpm with KVERSION:=2.6.31 MARKER:=v2.6.31 The problem is that "cut -f2 -d-" in this case returns the whole string, not the empty string. Fixed by switching to sed. There were also a couple of missing question marks in the spec. --- redhat/Makefile.common | 5 +++-- redhat/create-patches.sh | 9 +++++++-- redhat/kernel.spec.template | 4 ++-- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/redhat/Makefile.common b/redhat/Makefile.common index b91748a..b926bf5 100644 --- a/redhat/Makefile.common +++ b/redhat/Makefile.common @@ -16,8 +16,9 @@ TARBALL:=$(REDHAT)/$(TARFILE) TESTPATCH:=$(REDHAT)/linux-kernel-test.patch SUBLEVEL := $(shell echo $(MARKER) | cut -f 3 -d '.' | cut -f 1 -d '-') -RCREV := $(shell echo $(MARKER) | cut -f 2 -d '-' | sed -e "s/rc//") -GITREV := $(shell echo $(MARKER) | cut -f 3 -d '-' | sed -e "s/git//") +RCREV := $(shell echo $(MARKER) | sed -ne "s/^[^-]*-rc//p") +GITREV := $(shell echo $(MARKER) | sed -ne "s/^[^-]*-[^-]*-git//p") + ifneq ($(RCREV),) RELEASED_KERNEL := 0 else diff --git a/redhat/create-patches.sh b/redhat/create-patches.sh index d6835ba..2c9cf62 100755 --- a/redhat/create-patches.sh +++ b/redhat/create-patches.sh @@ -10,13 +10,18 @@ SERIESF="$SOURCES/series" clogf="$SOURCES/changelog" SUBLEVEL="$(echo $MARKER | cut -f 3 -d '.' | cut -f 1 -d '-')"; #SUBLEVEL="$(echo $MARKER | cut -f 3 -d '.')"; -RCREV=$(echo $MARKER | cut -f 2 -d '-' | sed -e "s/rc//") -GITREV=$(echo $MARKER | cut -f 3 -d '-' | sed -e "s/git//") +RCREV=$(echo $MARKER | sed -ne "s/^[^-]*-rc//p") +GITREV=$(echo $MARKER | sed -ne "s/^[^-]*-[^-]*-git//p") + if [ -n "$RCREV" ]; then RELEASED_KERNEL="0"; SUBLEVEL=$(($SUBLEVEL - 1)); else RELEASED_KERNEL="1"; + RCREV="0"; +fi +if [ -z "$GITREV" ]; then + GITREV="0"; fi touch $PATCHF $patchf diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template index d7f1666..cbe88e4 100644 --- a/redhat/kernel.spec.template +++ b/redhat/kernel.spec.template @@ -518,9 +518,9 @@ Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-%{kversion}.tar.bz2 Source1: Makefile.common -%if 0%{rcrev} +%if 0%{?rcrev} Source2: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/incr/patch-2.6.%{upstream_sublevel}-rc%{rcrev}.bz2 -%if 0%{gitrev} +%if 0%{?gitrev} Source3: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/incr/patch-2.6.%{upstream_sublevel}-rc%{rcrev}-git%{gitrev}.bz2 %endif %endif -- 1.6.2.5 From pbonzini at redhat.com Fri Sep 18 10:19:24 2009 From: pbonzini at redhat.com (Paolo Bonzini) Date: Fri, 18 Sep 2009 12:19:24 +0200 Subject: [RHEL6 PATCH] internal: properly define %{dist} and compute correct pkg_release from Makefile In-Reply-To: <1253259873-15118-2-git-send-email-pbonzini@redhat.com> References: <1253259873-15118-2-git-send-email-pbonzini@redhat.com> Message-ID: <1253269164-18825-1-git-send-email-pbonzini@redhat.com> This third patch, on top of the two I sent earlier, completes the changes to the Makefile so that they support brew. The reason is that while the previous patch added the targets, there are still differences between the RHEL5 and RHEL6 spec templates so that the RHEL6 Makefile did not behave properly. The changes here are threefold, but difficult to separate further: - compute the correct value of %{pkg_release} (and hence the name of the build srpm) from the Makefile. - I also made the buildid come at the end, after the %{dist}, for consistency with RHEL5 - finally, I allowed the RHEL build to define its %{dist} instead of always taking it from the environment. With this patch in place, I finally was able to start a brew build with "make rh-brew". --- redhat/Makefile | 21 +++++++++++---------- redhat/Makefile.common | 5 +++-- redhat/create-patches.sh | 2 ++ redhat/kernel.spec.template | 7 ++++--- 4 files changed, 20 insertions(+), 15 deletions(-) diff --git a/redhat/Makefile b/redhat/Makefile index 91d838f..71770fa 100644 --- a/redhat/Makefile +++ b/redhat/Makefile @@ -11,21 +11,22 @@ BUILD_TARGET ?= --scratch $(BUILD_SCRATCH_TARGET) #BUILD_TARGET ?= $(BUILD_DEFAULT_TARGET) #endif -BUILDID:=$(shell sed -ne 's/^[^\#]*define buildid \(.*\)/\1/p' $(REDHAT)/$(SPECFILE).template) -RELEASE:=$(shell sed -ne 's/^[^\#]*define release \(.*\)%.*%.*/\1/p' $(REDHAT)/$(SPECFILE).template) -DIST:=$(shell sed -ne 's/^[^\#]*define dist \(.*\)/\1/p' $(REDHAT)/$(SPECFILE).template) +RELEASE:=$(BUILD)$(if $(RCREV),.rc$(RCREV),) -ifeq ($(BUILDID),) +ifeq ($(origin BUILDID),undefined) ifneq ($(wildcard $(LOCVERFILE)),) BUILDID:=$(shell cat $(LOCVERFILE)) $(info Using LOCALVERSION buildid "$(BUILDID)") -else +else # no localversion +BUILDID:=$(shell sed -ne 's/^[^\#]*define buildid \(.*\)/\1/p' $(REDHAT)/$(SPECFILE).template) +ifneq ($(BUILDID),) +$(info Using SPECFILE buildid "$(BUILDID)") +else # not in spec BUILDID:=.test $(info Using default buildid "$(BUILDID)". Specify one in "localversion" file if you want.) -endif -else -$(info Using SPECFILE buildid "$(BUILDID)") -endif +endif # not in spec +endif # no localversion +endif # not on commandline rh-configs: cd $(REDHAT)/configs; $(MAKE) VERSION=$(KVERSION) configs @@ -81,7 +82,7 @@ sources-rh: $(TARBALL) $(RC_PATCH) $(GIT_PATCH) @diff $(TESTPATCH).tmp $(TESTPATCH) > /dev/null || \ echo "WARNING: There are uncommitted changes in your tree or the changes are not in sync with the kernel-test.patch. Either commit the changes or run 'make rh-test-patch'" @rm $(TESTPATCH).tmp - @$(REDHAT)/create-patches.sh $(MARKER) $(SOURCES) $(SOURCES)/$(SPECFILE) $(BUILD) + @$(REDHAT)/create-patches.sh $(MARKER) $(SOURCES) $(SOURCES)/$(SPECFILE) $(BUILD) $(DIST) @cp $(SOURCES)/$(SPECFILE) $(SOURCES)/../SPECS @cp $(TESTPATCH) $(SOURCES)/linux-kernel-test.patch @cp configs/Makefile $(SOURCES)/Makefile.config diff --git a/redhat/Makefile.common b/redhat/Makefile.common index b926bf5..e5ec9c1 100644 --- a/redhat/Makefile.common +++ b/redhat/Makefile.common @@ -1,14 +1,15 @@ RPMBUILD := $(shell if [ -x "/usr/bin/rpmbuild" ]; then echo rpmbuild; \ else echo rpm; fi) MACH := $(shell uname -m) -KVERSION:=2.6.30 +KVERSION:=2.6.31 # marker is git tag -MARKER:=v2.6.31-rc5-git2 +MARKER:=v2.6.31 SPECFILE:=kernel.spec REDHAT:=$(CURDIR) RPM:=$(REDHAT)/rpm SRPMS:=$(RPM)/SRPMS SOURCES:=$(RPM)/SOURCES +DIST:=.el6 BUILD:=1 #TARFILE:=$(subst _,.,$(MARKER)).tar.bz2 TARFILE:=linux-$(KVERSION).tar.bz2 diff --git a/redhat/create-patches.sh b/redhat/create-patches.sh index 2c9cf62..8bef8ad 100755 --- a/redhat/create-patches.sh +++ b/redhat/create-patches.sh @@ -4,6 +4,7 @@ MARKER=$1 SOURCES=$2 SPECFILE=$3 BUILD=$4 +DIST=$5 PATCHF="$SOURCES/Patch.include" patchf="$SOURCES/patch.include" SERIESF="$SOURCES/series" @@ -195,6 +196,7 @@ test -n "$SPECFILE" && /%%CHANGELOG%%/r $clogf.rev /%%CHANGELOG%%/d s/%%BUILD%%/$BUILD/ + s/%%DIST%%/$DIST/ s/%%SUBLEVEL%%/$SUBLEVEL/ s/%%RCREV%%/$RCREV/ s/%%GITREV%%/$GITREV/ diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template index cbe88e4..bbe1369 100644 --- a/redhat/kernel.spec.template +++ b/redhat/kernel.spec.template @@ -15,10 +15,11 @@ Summary: The Linux kernel # that the kernel isn't the stock distribution kernel, for example, # by setting the define to ".local" or ".bz123456" # -# % define buildid .local +#% define buildid .local %define rhel 1 %if %{rhel} +%define dist %%DIST%% %define distro_build %%BUILD%% %define signmodules 1 %else @@ -154,7 +155,7 @@ Summary: The Linux kernel %if 0%{?stable_rc} %define stable_rctag .rc%{stable_rc} %endif -%define pkg_release %{distro_build}%{?stable_rctag}%{?buildid}%{?dist} +%define pkg_release %{distro_build}%{?stable_rctag}%{?dist}%{?buildid} %else @@ -168,7 +169,7 @@ Summary: The Linux kernel %define rctag .rc0 %endif %endif -%define pkg_release 0.%{distro_build}%{?rctag}%{?gittag}%{?buildid}%{?dist} +%define pkg_release 0.%{distro_build}%{?rctag}%{?gittag}%{?dist}%{?buildid} %endif -- 1.6.2.5 From snecklifter at gmail.com Sat Sep 19 19:35:30 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 19 Sep 2009 20:35:30 +0100 Subject: [RHEL6 PATCH] internal: properly define %{dist} and compute correct pkg_release from Makefile In-Reply-To: <1253269164-18825-1-git-send-email-pbonzini@redhat.com> References: <1253259873-15118-2-git-send-email-pbonzini@redhat.com> <1253269164-18825-1-git-send-email-pbonzini@redhat.com> Message-ID: <364d303b0909191235v7d30d927w5a219c165df16698@mail.gmail.com> Hi Paolo, 2009/9/18 Paolo Bonzini : > This third patch, on top of the two I sent earlier, completes the > changes to the Makefile so that they support brew. ?The reason is > that while the previous patch added the targets, there are still > differences between the RHEL5 and RHEL6 spec templates so that the > RHEL6 Makefile did not behave properly. > > The changes here are threefold, but difficult to separate further: > > - compute the correct value of %{pkg_release} (and hence the name of > the build srpm) from the Makefile. > > - I also made the buildid come at the end, after the %{dist}, for > consistency with RHEL5 > > - finally, I allowed the RHEL build to define its %{dist} instead > of always taking it from the environment. > > With this patch in place, I finally was able to start a brew build > with "make rh-brew". > --- > ?redhat/Makefile ? ? ? ? ? ? | ? 21 +++++++++++---------- > ?redhat/Makefile.common ? ? ?| ? ?5 +++-- > ?redhat/create-patches.sh ? ?| ? ?2 ++ > ?redhat/kernel.spec.template | ? ?7 ++++--- > ?4 files changed, 20 insertions(+), 15 deletions(-) > > diff --git a/redhat/Makefile b/redhat/Makefile > index 91d838f..71770fa 100644 > --- a/redhat/Makefile > +++ b/redhat/Makefile > @@ -11,21 +11,22 @@ BUILD_TARGET ?= --scratch $(BUILD_SCRATCH_TARGET) > ?#BUILD_TARGET ?= $(BUILD_DEFAULT_TARGET) > ?#endif > > -BUILDID:=$(shell sed -ne 's/^[^\#]*define buildid \(.*\)/\1/p' $(REDHAT)/$(SPECFILE).template) > -RELEASE:=$(shell sed -ne 's/^[^\#]*define release \(.*\)%.*%.*/\1/p' $(REDHAT)/$(SPECFILE).template) > -DIST:=$(shell sed -ne 's/^[^\#]*define dist \(.*\)/\1/p' $(REDHAT)/$(SPECFILE).template) > +RELEASE:=$(BUILD)$(if $(RCREV),.rc$(RCREV),) > > -ifeq ($(BUILDID),) > +ifeq ($(origin BUILDID),undefined) > ?ifneq ($(wildcard $(LOCVERFILE)),) > ?BUILDID:=$(shell cat $(LOCVERFILE)) > ?$(info Using LOCALVERSION buildid "$(BUILDID)") > -else > +else # no localversion > +BUILDID:=$(shell sed -ne 's/^[^\#]*define buildid \(.*\)/\1/p' $(REDHAT)/$(SPECFILE).template) > +ifneq ($(BUILDID),) > +$(info Using SPECFILE buildid "$(BUILDID)") > +else # not in spec > ?BUILDID:=.test > ?$(info Using default buildid "$(BUILDID)". Specify one in "localversion" file if you want.) > -endif > -else > -$(info Using SPECFILE buildid "$(BUILDID)") > -endif > +endif # not in spec > +endif # no localversion > +endif # not on commandline > > ?rh-configs: > ? ? ? ?cd $(REDHAT)/configs; $(MAKE) VERSION=$(KVERSION) configs > @@ -81,7 +82,7 @@ sources-rh: $(TARBALL) $(RC_PATCH) $(GIT_PATCH) > ? ? ? ?@diff $(TESTPATCH).tmp $(TESTPATCH) > /dev/null || \ > ? ? ? ? ? ? ? ?echo "WARNING: There are uncommitted changes in your tree or the changes are not in sync with the kernel-test.patch. ?Either commit the changes or run 'make rh-test-patch'" > ? ? ? ?@rm $(TESTPATCH).tmp > - ? ? ? @$(REDHAT)/create-patches.sh $(MARKER) $(SOURCES) $(SOURCES)/$(SPECFILE) $(BUILD) > + ? ? ? @$(REDHAT)/create-patches.sh $(MARKER) $(SOURCES) $(SOURCES)/$(SPECFILE) $(BUILD) $(DIST) > ? ? ? ?@cp $(SOURCES)/$(SPECFILE) $(SOURCES)/../SPECS > ? ? ? ?@cp $(TESTPATCH) $(SOURCES)/linux-kernel-test.patch > ? ? ? ?@cp configs/Makefile $(SOURCES)/Makefile.config > diff --git a/redhat/Makefile.common b/redhat/Makefile.common > index b926bf5..e5ec9c1 100644 > --- a/redhat/Makefile.common > +++ b/redhat/Makefile.common > @@ -1,14 +1,15 @@ > ?RPMBUILD := $(shell if [ -x "/usr/bin/rpmbuild" ]; then echo rpmbuild; \ > ? ? ? ? ? ? ? ? ? ?else echo rpm; fi) > ?MACH := ?$(shell uname -m) > -KVERSION:=2.6.30 > +KVERSION:=2.6.31 > ?# marker is git tag > -MARKER:=v2.6.31-rc5-git2 > +MARKER:=v2.6.31 > ?SPECFILE:=kernel.spec > ?REDHAT:=$(CURDIR) > ?RPM:=$(REDHAT)/rpm > ?SRPMS:=$(RPM)/SRPMS > ?SOURCES:=$(RPM)/SOURCES > +DIST:=.el6 > ?BUILD:=1 > ?#TARFILE:=$(subst _,.,$(MARKER)).tar.bz2 > ?TARFILE:=linux-$(KVERSION).tar.bz2 > diff --git a/redhat/create-patches.sh b/redhat/create-patches.sh > index 2c9cf62..8bef8ad 100755 > --- a/redhat/create-patches.sh > +++ b/redhat/create-patches.sh > @@ -4,6 +4,7 @@ MARKER=$1 > ?SOURCES=$2 > ?SPECFILE=$3 > ?BUILD=$4 > +DIST=$5 > ?PATCHF="$SOURCES/Patch.include" > ?patchf="$SOURCES/patch.include" > ?SERIESF="$SOURCES/series" > @@ -195,6 +196,7 @@ test -n "$SPECFILE" && > ? ? ? ?/%%CHANGELOG%%/r $clogf.rev > ? ? ? ?/%%CHANGELOG%%/d > ? ? ? ?s/%%BUILD%%/$BUILD/ > + ? ? ? s/%%DIST%%/$DIST/ > ? ? ? ?s/%%SUBLEVEL%%/$SUBLEVEL/ > ? ? ? ?s/%%RCREV%%/$RCREV/ > ? ? ? ?s/%%GITREV%%/$GITREV/ > diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template > index cbe88e4..bbe1369 100644 > --- a/redhat/kernel.spec.template > +++ b/redhat/kernel.spec.template > @@ -15,10 +15,11 @@ Summary: The Linux kernel > ?# that the kernel isn't the stock distribution kernel, for example, > ?# by setting the define to ".local" or ".bz123456" > ?# > -# % define buildid .local > +#% define buildid .local > > ?%define rhel 1 > ?%if %{rhel} > +%define dist %%DIST%% > ?%define distro_build %%BUILD%% > ?%define signmodules 1 > ?%else > @@ -154,7 +155,7 @@ Summary: The Linux kernel > ?%if 0%{?stable_rc} > ?%define stable_rctag .rc%{stable_rc} > ?%endif > -%define pkg_release %{distro_build}%{?stable_rctag}%{?buildid}%{?dist} > +%define pkg_release %{distro_build}%{?stable_rctag}%{?dist}%{?buildid} > > ?%else > > @@ -168,7 +169,7 @@ Summary: The Linux kernel > ?%define rctag .rc0 > ?%endif > ?%endif > -%define pkg_release 0.%{distro_build}%{?rctag}%{?gittag}%{?buildid}%{?dist} > +%define pkg_release 0.%{distro_build}%{?rctag}%{?gittag}%{?dist}%{?buildid} > > ?%endif > > -- > 1.6.2.5 Could you indicate how emails regarding RHEL5 & RHEL6 kernel Makefile and spec files (and starting with "internal:") are appropriate for fedora-kernel development lists please. I believe patches aimed at supporting internal build systems are not appropriate for Fedora. I thought you guys were moving to Koji for RHEL6 anyway? Thanks -- Christopher Brown From pbonzini at redhat.com Mon Sep 21 07:32:12 2009 From: pbonzini at redhat.com (Paolo Bonzini) Date: Mon, 21 Sep 2009 09:32:12 +0200 Subject: [RHEL6 PATCH] internal: properly define %{dist} and compute correct pkg_release from Makefile In-Reply-To: <364d303b0909191235v7d30d927w5a219c165df16698@mail.gmail.com> References: <1253259873-15118-2-git-send-email-pbonzini@redhat.com> <1253269164-18825-1-git-send-email-pbonzini@redhat.com> <364d303b0909191235v7d30d927w5a219c165df16698@mail.gmail.com> Message-ID: <4AB72BFC.80103@redhat.com> [removing RHKL] > Could you indicate how emails regarding RHEL5& RHEL6 kernel Makefile > and spec files (and starting with "internal:") are appropriate for > fedora-kernel development lists please. "Internal" meant that it is not related to upstream, it is just for the RPM build machinery. I don't like calling it "internal:" because it can give exactly this situation, but traditionally this was used for RHEL5. There are plenty of references to Fedora in the spec files I changed, so I thought I would CC the message to the fedora list FYI. Nevertheless, my apologies for the crossposting. I should have sent two separate messages. > I believe patches aimed at supporting internal build systems are not > appropriate for Fedora. I thought you guys were moving to Koji for > RHEL6 anyway? The patches work equivalently for koji. Paolo From xose.vazquez at gmail.com Fri Sep 25 15:52:14 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Fri, 25 Sep 2009 17:52:14 +0200 Subject: linux-2.6-firewire-git-update.patch useless Message-ID: <4ABCE72E.2080601@gmail.com> hi, Please delete linux-2.6-firewire-git-update.patch. There is no code to patch. -thanks- -- ?All? muevan feroz guerra, ciegos reyes por un palmo m?s de tierra; que yo aqu? tengo por m?o cuanto abarca el mar brav?o, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y d? pecho a mi valor.?