Bug 58151
| Summary: | kernel 3.2.45 regression in i915 driver for 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Nix\ (nix.sasl) |
| Component: | Video(DRI - Intel) | Assignee: | intel-gfx-bugs (intel-gfx-bugs) |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | high | CC: | daniel, intel-gfx-bugs, nix.sasl |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.2.45 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | .config file used for compile 3.2.45 vanilla kernel | ||
|
Description
Nix\
2013-05-14 22:22:30 UTC
Created attachment 101581 [details]
.config file used for compile 3.2.45 vanilla kernel
Resuming: Using i915.modeset=1 on cmdline of grub, no video, no backlight and boot normally (i can log and reboot without video, i remember the steps and times of my machine). Using i915.modeset=0 on cmdline of grub, yes video, yes backlight, but no framebuffer on VT2 or other VT, resolution is normal, no backlight control, backlight is setted to max without posibility of change. Module i915 is loaded. Output of lsmod: Module Size Used by coretemp 4896 0 8021q 12400 0 garp 4001 1 8021q stp 1033 1 garp llc 2439 2 garp,stp ipv6 216682 10 dm_mod 49181 0 uinput 5124 0 arc4 986 2 thinkpad_acpi 47870 0 wmi 6402 0 sg 20258 0 uvcvideo 47603 0 videodev 56377 1 uvcvideo microcode 6556 0 iwlwifi 148685 0 mac80211 142089 1 iwlwifi cfg80211 113908 2 iwlwifi,mac80211 i915 327268 0 drm_kms_helper 19012 1 i915 cfbcopyarea 2580 1 i915 cfbimgblt 1751 1 i915 cfbfillrect 2474 1 i915 snd_hda_codec_conexant 35252 1 snd_hda_intel 17587 4 snd_hda_codec 60131 2 snd_hda_codec_conexant,snd_hda_intel snd_hwdep 4142 1 snd_hda_codec snd_seq 34643 0 snd_seq_device 3617 1 snd_seq snd_pcm 47691 3 snd_hda_intel,snd_hda_codec snd_timer 12527 2 snd_seq,snd_pcm snd 35479 16 thinkpad_acpi,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer snd_page_alloc 4841 2 snd_hda_intel,snd_pcm iTCO_wdt 10370 0 iTCO_vendor_support 1261 1 iTCO_wdt intel_agp 8120 1 i915 intel_gtt 10506 3 i915,intel_agp e1000e 135093 0 pcmcia 34457 0 yenta_socket 17617 0 pcmcia_rsrc 6990 1 yenta_socket pcmcia_core 9937 3 pcmcia,yenta_socket,pcmcia_rsrc uhci_hcd 17949 0 Output of dmesg: sr 1:0:0:0: Attached scsi generic sg1 type 5 wmi: Mapper loaded iwlwifi 0000:03:00.0: loaded firmware version 8.83.5.1 build 33692 Registered led device: phy0-led thinkpad_acpi: ThinkPad ACPI Extras v0.24 thinkpad_acpi: http://ibm-acpi.sf.net/ thinkpad_acpi: ThinkPad BIOS 7UET92WW (3.22 ), EC 7VHT16WW-1.06 thinkpad_acpi: Lenovo ThinkPad T400, model 6474ES3 thinkpad_acpi: detected a 8-level brightness capable ThinkPad thinkpad_acpi: radio switch found; radios are enabled thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked Registered led device: tpacpi::thinklight Registered led device: tpacpi::power Registered led device: tpacpi::standby Registered led device: tpacpi::thinkvantage thinkpad_acpi: Standard ACPI backlight interface available, not loading native one thinkpad_acpi: Console audio control enabled, mode: monitor (read only) input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input9 ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcffff 0xdc000-0xfffff pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: Calling CRDA for country: AR cfg80211: Regulatory domain changed to country: AR cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EXT4-fs (sda3): re-mounted. Opts: (null) EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) Adding 2047996k swap on /dev/sda6. Priority:-1 extents:1 across:2047996k type=1127 audit(1368570497.528:2): user pid=942 uid=0 auid=4294967295 ses=4294967295 msg='init exe="/sbin/telinit" hostname=? addr=? terminal=console res=success' type=1129 audit(1368570497.529:3): user pid=942 uid=0 auid=4294967295 ses=4294967295 msg='old-level=N new-level=5 exe="/sbin/telinit" hostname=? addr=? terminal=console res=success' NET: Registered protocol family 10 type=1305 audit(1368570498.527:4): audit_pid=1072 old=0 auid=4294967295 ses=4294967295 res=1 8021q: 802.1Q VLAN Support v1.8 e1000e 0000:00:19.0: irq 47 for MSI/MSI-X e1000e 0000:00:19.0: irq 47 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 ADDRCONF(NETDEV_UP): wlan0: link is not ready hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. wlan0: authenticate with e0:69:95:97:52:02 (try 1) wlan0: authenticated wlan0: waiting for beacon from e0:69:95:97:52:02 wlan0: beacon received wlan0: associate with e0:69:95:97:52:02 (try 1) wlan0: RX AssocResp from e0:69:95:97:52:02 (capab=0x411 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready (In reply to comment #0) > Using the same .config file on the same machine (Lenovo Thinkpad t400), > compiling 3.2.44 kernel no problem, compiling 3.2.45 no backlight and no > video. > Disabling the modeseting by default on the .config and setting i915.modeset=0 > the backlight works, but, no framebuffer, and no control of backlight using > Fn > + Bright up/down. This should be easy to bisect. See [1] for instructions. Just use the stable tree [2] if you aren't already using that. [1] http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ [2] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git (In reply to comment #3) > (In reply to comment #0) > > Using the same .config file on the same machine (Lenovo Thinkpad t400), > > compiling 3.2.44 kernel no problem, compiling 3.2.45 no backlight and no > video. > > Disabling the modeseting by default on the .config and setting > i915.modeset=0 > > the backlight works, but, no framebuffer, and no control of backlight using > Fn > > + Bright up/down. > > This should be easy to bisect. See [1] for instructions. Just use the stable > tree [2] if you aren't already using that. > > [1] > > http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ > [2] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git @Jani Nikula: Can you fix it upstream please?. I already "fixed" it for myself (workaround i915.modeset=0 but no framebuffer and backlight control), but I'm asking you to fix it upstream please. (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #0) > > > Using the same .config file on the same machine (Lenovo Thinkpad t400), > > > compiling 3.2.44 kernel no problem, compiling 3.2.45 no backlight and no > video. > > > Disabling the modeseting by default on the .config and setting > i915.modeset=0 > > > the backlight works, but, no framebuffer, and no control of backlight > using Fn > > > + Bright up/down. > > > > This should be easy to bisect. See [1] for instructions. Just use the > stable > > tree [2] if you aren't already using that. > > > > [1] > > > http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ > > [2] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > > @Jani Nikula: > > Can you fix it upstream please?. I already "fixed" it for myself (workaround > i915.modeset=0 but no framebuffer and backlight control), but I'm asking you > to > fix it upstream please. I don't know the root cause here. Fixing it would be easier if you did the bisect, please. It means pinpointing the error introduced between v3.2.44 and v3.2.45 to a single commit in the source. You could also try reverting commit 19c42ce9869ff30f43a08fb774d08f35b92b5ff6 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Apr 12 15:18:38 2013 +0300 drm/i915: ensure single initialization and cleanup of backlight device which touches backlight code and see if that helps, but if it doesn't, it's just useless back and forth when one should've just done the bisect. (Note that I don't find anything obviously wrong with the commit.) Is there anything in the logfiles like? [ 33.852048] [drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind an object larger than the aperture [ 33.968581] [drm:intel_pipe_set_base] *ERROR* pin & fence failed [ 34.040527] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3] Bug #58511 sounds a bit relevant here ... Also are more recent kernel releases (like 3.9) also affected? Ok, bug #58511 bisected to commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 15 11:32:18 2012 +0000 drm/i915: Fix detection of base of stolen memory Which was added in 3.2.45. Symptoms seem to match way to well, so marking as duplicate. Thanks for reporting this bug and please reopen if reverting that patch on 3.2.45 doesn't fix your issue. *** This bug has been marked as a duplicate of bug 58511 *** (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #0) > > > > Using the same .config file on the same machine (Lenovo Thinkpad t400), > > > > compiling 3.2.44 kernel no problem, compiling 3.2.45 no backlight and > no video. > > > > Disabling the modeseting by default on the .config and setting > i915.modeset=0 > > > > the backlight works, but, no framebuffer, and no control of backlight > using Fn > > > > + Bright up/down. > > > > > > This should be easy to bisect. See [1] for instructions. Just use the > stable > > > tree [2] if you aren't already using that. > > > > > > [1] > > > > http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ > > > [2] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > > > > @Jani Nikula: > > > > Can you fix it upstream please?. I already "fixed" it for myself > (workaround > > i915.modeset=0 but no framebuffer and backlight control), but I'm asking > you to > > fix it upstream please. > > I don't know the root cause here. Fixing it would be easier if you did the > bisect, please. It means pinpointing the error introduced between v3.2.44 and > v3.2.45 to a single commit in the source. > > You could also try reverting > commit 19c42ce9869ff30f43a08fb774d08f35b92b5ff6 > Author: Jani Nikula <jani.nikula@intel.com> > Date: Fri Apr 12 15:18:38 2013 +0300 > > drm/i915: ensure single initialization and cleanup of backlight device > > which touches backlight code and see if that helps, but if it doesn't, it's > just useless back and forth when one should've just done the bisect. (Note > that > I don't find anything obviously wrong with the commit.) The steps in your blog no work, git say error, please give me a good guide for bisect. Thank you. (In reply to comment #6) > Is there anything in the logfiles like? > > [ 33.852048] [drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind > an > object larger than the aperture > [ 33.968581] [drm:intel_pipe_set_base] *ERROR* pin & fence failed > [ 34.040527] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on > [CRTC:3] > > Bug #58511 sounds a bit relevant here ... > > Also are more recent kernel releases (like 3.9) also affected? No, 3.9.3 tested from the rpm of elrepo (a vanilla kernel compiled in rpm package), works fine. (In reply to comment #7) > Ok, bug #58511 bisected to > > commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Nov 15 11:32:18 2012 +0000 > > drm/i915: Fix detection of base of stolen memory > > Which was added in 3.2.45. Symptoms seem to match way to well, so marking as > duplicate. Thanks for reporting this bug and please reopen if reverting that > patch on 3.2.45 doesn't fix your issue. > > *** This bug has been marked as a duplicate of bug 58511 *** @ Daniel Vetter Give me the patch for apply to 3.2.44 and test. For the moment i can see the same problem after slackware update using 3.2.45 kernel: http://www.linuxquestions.org/questions/slackware-14/upgrading-slackware-14-to-kernel-3-2-45-resulted-in-black-screen-on-boot-4175462795/ (In reply to comment #10) > (In reply to comment #7) > > Ok, bug #58511 bisected to > > > > commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Thu Nov 15 11:32:18 2012 +0000 > > > > drm/i915: Fix detection of base of stolen memory > > > > Which was added in 3.2.45. Symptoms seem to match way to well, so marking > as > > duplicate. Thanks for reporting this bug and please reopen if reverting > that > > patch on 3.2.45 doesn't fix your issue. > > > > *** This bug has been marked as a duplicate of bug 58511 *** > @ Daniel Vetter > > Give me the patch for apply to 3.2.44 and test. > For the moment i can see the same problem after slackware update using 3.2.45 > kernel: > > http://www.linuxquestions.org/questions/slackware-14/upgrading-slackware-14-to-kernel-3-2-45-resulted-in-black-screen-on-boot-4175462795/ Sorry, or apply to 3.2.45 and test it (In reply to comment #7) > Ok, bug #58511 bisected to > > commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Nov 15 11:32:18 2012 +0000 > > drm/i915: Fix detection of base of stolen memory > > Which was added in 3.2.45. Symptoms seem to match way to well, so marking as > duplicate. Thanks for reporting this bug and please reopen if reverting that > patch on 3.2.45 doesn't fix your issue. > > *** This bug has been marked as a duplicate of bug 58511 *** @Daniel Vetter I can confirm. Using the commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 as .patch file, the bug is solved: [root@nix linux-3.2.45]# patch -R -p1 < patch-revert-i915.patch patching file drivers/gpu/drm/i915/i915_dma.c patching file drivers/gpu/drm/i915/i915_drv.h patch unexpectedly ends in middle of line Hunk #1 succeeded at 581 with fuzz 1. Boot with screen, fb, backlight control and resolution ok. @Daniel Vetter I found the patch into source of Slackware kernel: http://pastebin.com/Pp4QWxPE (In reply to comment #7) > Ok, bug #58511 bisected to > > commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Nov 15 11:32:18 2012 +0000 > > drm/i915: Fix detection of base of stolen memory > > Which was added in 3.2.45. Symptoms seem to match way to well, so marking as > duplicate. Thanks for reporting this bug and please reopen if reverting that > patch on 3.2.45 doesn't fix your issue. > > *** This bug has been marked as a duplicate of bug 58511 *** @Daniel Vetter A question of noob. How the same commit have 2 number of commit: 53e587aa5ca81497d0ea6e340320ec5778d1f311 and e12a2d53ae45a69aea499b64f75e7222cca0f12f And i want see the change for the fix, for see that was the bug. Thanks a lot. (In reply to comment #14) > @Daniel Vetter > > A question of noob. > How the same commit have 2 number of commit: > > 53e587aa5ca81497d0ea6e340320ec5778d1f311 > and > e12a2d53ae45a69aea499b64f75e7222cca0f12f It's not the same commit. One is the commit in the master branch, the other is the backport to the 3.2.x stable series. Ok, i understand about master and backport, but, I no understand it: The original commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 "drm/i915: Fix detection of base of stolen memory", in 3.2.45 was the bug reported. The new code for commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 ( http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=53e587aa5ca81497d0ea6e340320ec5778d1f311&context=3 ) was changed all the .c files from the original 3.2.45 downloaded from kernel.org. So is the SAME commit modified for the regression in 3.2.45?. The commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 is identic to the slackware patch that solve the regression. But, the commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 is mentioned in the changelog of kernel.org in 3.2.45, but, the .c files are no modified (looking the actual patch/commit), so, the patch never was applied or the commit or was modified for the bug report?. Thank you for answer, if you answer me Daniel Vetter, sorry for the flood of messages, the most important is this message, for understand the original commit and the new commit, same number but different code. Resuming, https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.45 commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 15 11:32:18 2012 +0000 drm/i915: Fix detection of base of stolen memory commit e12a2d53ae45a69aea499b64f75e7222cca0f12f upstream. But is a regression, and the actual commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 using patch -R solve the problem, so, is commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 the patch or other patch is?. And if other is, what is?. Regards Ok, I'm a idiot, 1.- The .diff file from slackware was used in -R mode 2.- The commit is the bug But, i915_dma.c file in 3.2.45 final release, look was the commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 was never applied if I compare the - and + in the patch ( http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=53e587aa5ca81497d0ea6e340320ec5778d1f311&context=4 ) with /drivers/gpu/drm/i915/i915_dma.c. So the patches are partially applied?. Example, the line -static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset) is removed by the patch, but, in .c file is present and the +static unsigned long i915_stolen_to_physical(struct drm_device *dev) not, so, the patch are partially applied or the commit was modified by the bug report Daniel?. Sorry for being annoying, but I need to understand for future reports, I see that things are solved in upstream more faster than in the distributions like Fedora, Ubuntu, openSUSE, etc. Commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 is a modified version of the commit in upstream master, as Ben's comment in the commit message indicates. Master has been changed considerably since then, and the upstream commit no longer applies as-is to stable v3.2. The stable v3.2 is *only* changed by backports of important fixes from master. Unfortunately, this "fix" added in 3.2.45 breaks things for you. patch -R option *reverses* the patch, removing the code that was added by that commit, fixing things for you. On a git tree, this is similar to git revert 53e587aa5ca81497d0ea6e340320ec5778d1f311. I presume the commit will be reverted in stable v3.2.46, which will be eventually picked up by distros, and get updated to users. HTH. (In reply to comment #19) > Commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 is a modified version of the > commit in upstream master, as Ben's comment in the commit message indicates. > Master has been changed considerably since then, and the upstream commit no > longer applies as-is to stable v3.2. The stable v3.2 is *only* changed by > backports of important fixes from master. Unfortunately, this "fix" added in > 3.2.45 breaks things for you. > > patch -R option *reverses* the patch, removing the code that was added by > that > commit, fixing things for you. On a git tree, this is similar to git revert > 53e587aa5ca81497d0ea6e340320ec5778d1f311. > > I presume the commit will be reverted in stable v3.2.46, which will be > eventually picked up by distros, and get updated to users. > > HTH. @Jani Nikula Ok, I understand much better now, and thanks a lot for the explanation about it. The commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 that breaks things for me, if I compare it the +/- with i915_dma.c file in 3.2.45 kernel looks that is not applied totally. The last modification of the commit was 5-13-2013, the same day that 3.2.45 was released. Search 'static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset)' line in i915_dma.c of 3.2.45, the line are present (I assume that "-" in patch remove things and "+" add things), so the commit never modified *all* code?. If you download 3.2.45 kernel, and execute # cat ./drivers/gpu/drm/i915/i915_dma.c |grep -i static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset) is present, but, the commit remove the line (using "-" symbol), so, was really applied the commit. http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=53e587aa5ca81497d0ea6e340320ec5778d1f311 -static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset) +static unsigned long i915_stolen_to_physical(struct drm_device *dev) In the 3.2.45 downloaded from http://kernel.org, the line 'static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset) exist, and the line 'static unsigned long i915_stolen_to_physical(struct drm_device *dev)' not, is a example of a lot of lines not changed by the buggy commit. So, the commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 modify the source totally?. If was modified in master branch 5-13-2013, the same day that 3.2.45 was released, and applied, why the changes are no totally applied? in .c files?. Sorry, my bad. I got confused between so many patches and kernels that was testing. 48 hours without sleep does not help. Looking a paste using fpaste from centos, with .c file, right, the patch was applied 2013-5-13. A last question, the patches and more are no well tested before the final release in a long term kernel?. In 5 years using kernel from kernel.org, never had a regression. Regards, thank you very much for your time, I hope you excuse my failure to understanding / knowledge. |