login
Search
You know the drill, so all together now: "Another week, another -rc
kernel".
Most of the changes are small one-liners, but the dirstat shows the areas
that got a bit more tender loving care:
17.4% arch/arm/mach-omap2/
2.2% arch/arm/mm/
3.8% arch/arm/plat-omap/
24.3% arch/arm/
2.5% arch/microblaze/
29.2% arch/
9.6% drivers/gpu/drm/radeon/
13.2% drivers/gpu/drm/
3.2% drivers/i2c/busses/
2.8% drivers/media/dvb/frontends/
4.7% drivers/media/dvb/siano/
7.6% drivers/media/dvb/
2.6% drivers/media/video/em28xx/
8.2% drivers/media/video/
16.2% drivers/media/
3.0% drivers/net/e1000e/
3.4% drivers/net/ixgbe/
2.6% drivers/net/netxen/
16.6% drivers/net/
50.2% drivers/
2.9% fs/xfs/
5.7% fs/
2.5% include/linux/
3.1% include/
3.1% mm/
2.0% net/
2.5% security/
290 files changed, 3366 insertions(+), 1777 deletions(-)
ie we have some arm and microblaze updates, radeon/drm and media updates,
and network drivers. The rest tends to be a random smattering all over.
But apart from a couple of bigger ones (OMAP GPIO/UART fixes and the
radeom/kms changes), it's really pretty small. The bulk of those 290 files
changed are basically few-liners in 213 commits (shortlog below), and in
general we should have cut down the regression list another tiny bit.
Worth testing: if you've seen NULL pointer oopses with reiserfs under
load, I committed something I hope fixes it. I'd have wished to get
a firm confirmation before doing that, but I wanted to get the fix in
before -rc7, so now I'll just have to wait for results after.
And if you had odd lock-ups with older dual-CPU machines (PPro, P2, P3,
Athlon XP), that should be fixed too.
There's some inotify fixes here too, but I don't think we've confirmed
whether they help the (apparently very hard to trigger) oopses some
people have seen. So please test and report.
Thanks,
Linus
---
Alex Deucher (1):
drm/radeon: add GET_PARAM/INFO ...Another rebuild didn't help: Thinking it didn't load it87, I tried again: [root@coyote 3.002005]# modprobe it87 FATAL: Error inserting it87 (/lib/modules/2.6.31-rc7/kernel/drivers/hwmon/it87.ko): Device or resource busy [root@coyote 3.002005]# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. Been there, done that, no joy. From messages when I attempt to access the it87: Aug 21 22:59:37 coyote kernel: [ 572.507928] it87: Found IT8716F chip at 0x290, revision 1 Aug 21 22:59:37 coyote kernel: [ 572.507937] it87: in3 is VCC (+5V) Aug 21 22:59:37 coyote kernel: [ 572.507939] it87: in7 is VCCH (+5V Stand-By) Aug 21 22:59:37 coyote kernel: [ 572.508232] ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region IP__ [0x295-0x296] Aug 21 22:59:37 coyote kernel: [ 572.508234] ACPI: Device needs an ACPI driver From uname -a Linux coyote.coyote.den 2.6.31-rc7 #2 SMP PREEMPT Fri Aug 21 22:37:38 EDT 2009 i686 athlon i386 GNU/Linux .config is attached, in case I've screwed the moose. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> Server depressed, needs Prozak
There haven't been any changes to the it87 driver since 2.6.30, nor do I see any ACPI changes that would be relevant. Of course, if you used to build without any ACPI support at all, that region conflict wouldn't have shown up, so it _could_ be config-dependent, but that sounds unliklely too. Linus --
I rebooted a few times this morning, and the loss actually takes place between -rc5 and -rc6. At rc6 and rc7, any attempt to load the it87 module gets a message advising the resources are busy and it refuses to load. I'd get a sample of the error but I'm booted to -rc5 atm and its working. I also noted that the output of sensors, when it works, contains more temps than gkrellm displays, except for THRM, the rest are all displayed as 32F in gkrellm. Attached is a log of sorts, consisting of the output of uname -a, followed by the output of sensors during that boot, and the sensors modules loaded and linked during that boot. Thank you. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> Anyone can make an omelet with eggs. The trick is to make one with none.
The ACPI AML on your machine indicates that the BIOS may attempt to access the it87 hardware, and the kernel now by default blocks it87 from requesting those ports as it may conflict with what the BIOS is trying to do. On some machines, the ACPI BIOS accesses hardware monitoring chips itself to manage ACPI thermal zones, etc. and the conflicting access can cause incorrect temperature readings and other bad behavior. You can try acpi_enforce_resources=lax on the kernel command line to restore the previous behavior. Or for some Asus boards, you can try the asus_atk0110 ACPI driver instead of it87. --
PS: There have been previous reports, e.g. those logged as http://bugzilla.kernel.org/show_bug.cgi?id=13967 -- Stefan Richter -=====-==--= =--- =-==- http://arcgraph.de/sr/ --
I have applied that fix from the bz entry to my grub.conf but have not
rebooted as yet. However if this asus_atk0110.ko module is supposed to do
the same job, then obviously I do not have some other, required option set in
my .config's for rc6 and rc7. Directly choosing it doesn't seem to be
available in a make xconfig. What am I missing?
Thanks, Stefan.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>
It's the Magic that counts.
-- Larry Wall on Perl's apparent ugliness
--
The entry is in 'Device Drivers'/ 'Hardware Monitoring support'/ 'ASUS ATK0110 ACPI hwmon (SENSORS_ATK0110)' and depends on: HWMON (Hardware Monitoring support), X86, ACPI, EXPERIMENTAL. ACPI in turn depends on PM (Power Management support). -- Stefan Richter -=====-==--= =--- =-==- http://arcgraph.de/sr/ --
I have the EXPERIMENTAL flag set on the first page of the xconfig. root@coyote linux-2.6.31-rc7]# grep EXPERIMENTAL .config CONFIG_EXPERIMENTAL=y # CONFIG_CIFS_EXPERIMENTAL is not set Hardware Monitoring support does not grep, but a grep for HWMON shows this. CONFIG_HWMON=m CONFIG_HWMON_VID=m CONFIG_ACPI_ASUS=y is now, was not set or available to be set in xconfig that I could find. I set it with vim instead. And finally CONFIG_SENSORS_ATK0110=m I'll rebuild it now for test, and advise of the results. Thanks, Stefan. Results are that without that command line argument, I'm still dead. With it, it worked. I even changed the line in my rc.local that was loading it87, to loading asus_atk0110 but that is way too late I believe. .config & dmesg attached. Thanks everybody! -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> Aleph-null bottles of beer on the wall, Aleph-null bottles of beer, You take one down, and pass it around, Aleph-null bottles of beer on the wall.
That module is loaded right now while I'm on rc5, [root@coyote]# lsmod|grep asus asus_atk0110 8124 0 hwmon 2552 2 it87,asus_atk0110 [root@coyote hwmon]# lsmod|grep it87 it87 20908 0 hwmon_vid 2780 1 it87 hwmon 2552 2 it87,asus_atk0110 and all seems well. I just went through a make xconfig for about 30 minutes, looking to see if there was someplace to select that and actually make it work in place of the it87 module. I was not able to locate such an option. Now what? Thanks, Robert. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> Having a wonderful wine, wish you were beer. --
On Sat, Aug 22, 2009 at 03:26, Linus
drivers/staging/android/lowmemorykiller.c: In function 'lowmem_shrink':
drivers/staging/android/lowmemorykiller.c:108: error: 'struct
mm_struct' has no member named 'oom_adj'
I guess this one must be reverted as well?
commit a6a9f81ccc9f5c86ccc22bbed1960a57d0316e8b
Author: David Rientjes <rientjes@google.com>
Date: Tue Jun 16 16:42:53 2009 -0700
Staging: android: lowmemorykiller.c: fix it for "oom: move oom_adj value fro
I'm about to merge "oom: move oom_adj value from task_struct to
mm_struct", and this fixup is needed to repair linux-next's
drivers/staging/android/lowmemorykiller.c.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Thank you for very kindly bug report.
Unfortunatelly I didn't notice this ugly crap driver.
Yes, you are right. it should be reverted too.
Linus, can you please consider to apply following revert patch?
============================================
Subject: [PATCH] Revert android: lowmemorykiller.c: fix it for "oom: move oom_adj value from task_struct to mm_struct"
commit 0753ba01 (mm: revert "oom: move oom_adj value") reverted some
regression patch. but it didn't revert one strange oom retrieved driver patch.
Then, it made build error on this android driver.
This reverts commit a6a9f81ccc9f5c86ccc22bbed1960a57d0316e8b too and
fixes the build error.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
drivers/staging/android/lowmemorykiller.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index f934393..fe72240 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -96,21 +96,19 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
read_lock(&tasklist_lock);
for_each_process(p) {
- struct mm_struct *mm;
int oom_adj;
task_lock(p);
- mm = p->mm;
- if (!mm) {
+ if (!p->mm) {
task_unlock(p);
continue;
}
- oom_adj = mm->oom_adj;
+ oom_adj = p->oomkilladj;
if (oom_adj < min_adj) {
task_unlock(p);
continue;
}
- tasksize = get_mm_rss(mm);
+ tasksize = get_mm_rss(p->mm);
task_unlock(p);
if (tasksize <= 0)
continue;
--
1.6.2.5
--
Hi, I am far away from being a coder or a kernel geek, so bear with me if I can not provide all information on first try. Unlike rc6, this rc (rc7) does not boot correctly on my Macbook 2.1. I am using amd64 kernel-debs provided by Ubuntu on http://kernel.ubuntu.com/~kernel-ppa/mainline/. During boot with rc7, I can unlock my encrypted volumes just fine. After that, boot continues till suddenly screen goes black. I can not tell if the whole thing hangs or just the screen dies, but I can tell that the only way to get out of that limbo seems to be the power button. Again, everything seems to work flawless with rc6 Ubuntu deb. Assuming that dmesg output of rc6 and rc7 should look kinda similar, I tried to narrow the problem down to the following part in the output of rc6: [ 21.193733] cfg80211: Regulatory domain changed to country: AT [ 21.193737] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 21.193740] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 21.193742] (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 21.193745] (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 21.193747] (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm) [ 21.707177] lp: driver loaded but no devices found [ 21.913101] Adding 2097144k swap on /dev/mapper/vgencrypted-swap. Priority:-1 extents:1 across:2097144k [ 22.485747] EXT3 FS on dm-1, internal journal [ 23.482830] kjournald starting. Commit interval 5 seconds [ 23.483105] EXT3 FS on sda4, internal journal [ 23.483109] EXT3-fs: mounted filesystem with writeback data mode. [ 23.628917] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled [ 23.630731] SGI XFS Quota Management subsystem [ 23.688751] XFS mounting filesystem dm-3 [ 24.004942] Ending clean XFS mount for filesystem: dm-3 [ 24.844066] HDA Intel 0000:00:1b.0: PCI INT A disabled [ 24.853007] HDA Intel 0000:00:1b.0: ...
Are you using the same config? It sounds very much like your -rc7 problems are due to the Intel KMS (kernel mode setting) driver, which I know has had problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used different config options and didn't enable KMS, for example. Because I don't think anything actually changed in the KMS code itself between rc6 and rc7. That said, there were some generic EDID changes that could possibly affect KMS, but looking at the dmesg, I don't think you had KMS enabled in -rc6, and maybe you do in -rc7. I have no idea what configs those debian builds use. Linus --
Not sure what settings to look for, but this looks like you are completely correct: tobias@tbox:~$ cat /boot/config-2.6.31-020631rc6-generic | grep KMS # CONFIG_DRM_I915_KMS is not set # CONFIG_DRM_RADEON_KMS is not set tobias@tbox:~$ cat /boot/config-2.6.31-020631rc7-generic | grep KMS CONFIG_DRM_I915_KMS=y CONFIG_DRM_RADEON_KMS=y I thought that they would not change the configs where not necessary and was obviously wrong. Attaching both configs for completeness. Sorry for the false alarm and thanks for taking the time to look at this.
Yeah, so it's i915 kms. You can disable it dynamically at boot time with the i915.modeset=0 kernel command line (or I guess with "nomodeset" too, for that matter, which should disable both i915 and radeom kms). However, the problem remains that KMS gets the output wrong, in ways that clearly X does not. Eric - it's clearly not just Mac Mini and my experimental machine that have problems, but also a Macbook 2.1. I wonder why the Intel KMS logic doesn't look at which output was driven before it got invoked. Instead, it seems to want to try to detect everything from scratch, even though we should be able to assume that if you boot from BIOS (or EFI, for that matter), the current state of the graphics pipeline is likely meaningful. And clearly distros are trying to enable this. Which means that this is getting way more important to solve. Linus --
yeah, normally VBIOS startup just needs or only can driver one pipe, so we already have some mac relate bugs open, but please report on it so we do have people with hardware to try and response. We have recently got a We should also have floating patch on that, hope we'll prepare and cleanup the patches for mac soon. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
Umm. What's your guys point, exactly? The fact is, as-is, YOU DETECT THE WRONG OUTPUTS! If you actually detected things _right_, none of this would be an issue. But you don't. And you seem to have a really hard time even admitting Quite frankly, I've reported these things several times. I've been open to try patches. Nothing has ever come out of it. I have a Mac Mini that I reported as broken over a month ago. I have a Westemere I've reported as not doing any DDC probing - and that I have to disable the LVDS probing on entirely in order to not make KMS set up the display to go to a non-existent LVDS port. You claim that you "detect everything", but quite frankly, you don't. The KMS code seems to assume that if it's a mobile chipset, it should have an LVDS output - and whether anything is connected to that or not is totally immaterial. There's clearly _zero_ "detection" going on. And the thing is, X seems to get it right, at least more often than KMS does. Linus --
On Wed, Aug 26, 2009 at 1:33 PM, Linus This isn't anything to do with redetection, and in the Mac case there isn't even a BIOS table that you can really rely on since Apple hard coded all this stuff into their EFI and Mac OSX drivers. Now you probably get a video bios using Apples bios layer, but it also is most likely not telling anything close to the truth about the hw layout. Just because the BIOS manages to light up an output in now way effects I'm not sure why the mac-mini hack hasn't been merged I asked for it a few times, I'd rather the proper solution was merged but that seems to not have happened either. You have two special cases here, a) mac mini - apple hw, needs hacks to workaround the fact that they do something nobody else does with the hw and then don't tell you about it in the hw. the hack from userspace should have been ported to the kernel but I keep not seeing it. b) pre-production SDV hardware for a mobile chipset without LVDS, here's both pieces you get to keep them. LVDS isn't detectable on any hw, the sanity assumption so far are you have a mobile chipset you must have LVDS, you have an ACPI lid button you might have LVDS. You cannot reliably detect LVDS since DDC on LVDS panels isn't mandatory. most BIOSes have an LVDS table, guess what I'd bet your BIOS claims you have LVDS. So yes it nice you get free shiny hw but if it doesn't work, its not nice to give out about it. Dave. --
That's really my point. There _is_ one sort of detection you could do: look at the actual state of the graphics chip. In other words, exactly the case you mention: don't trust any BIOS tables (they may not exist, and they _are_ broken in many cases) or silly EFI information (I guarantee that any firmware info will eventually be buggy: EFI is in no way going to be magically less buggy than BIOS tables have been). So what's left? You can still look at how the chip was programmed. If it's driving the VGA port, you can be pretty sure that there's a monitor attached. Sure, there might be something _else_ attached too, and I'm not saying that you cannot try to probe other things, but right now it seems that KMS totally throws away a free - and fairly reliable - piece of information. And replaces it with very unreliable information that definitely doesn't work. I'm all for looking at many different places to find 'the truth', but I'm very unhappy with KMS looks into BIOS tables, decides that there's a LVDS panel attached (there isn't), and then disables the VGA port that drives the monitor. That doesn't help _anybody_. It just results in a black screen. And I guarantee that this happens on several pieces of hardware, and no, it's not all just "crap Apple and EFI". One of the pieces of hardware it happens on is an Intel-only machine. Intel hardware, Intel firmware, Intel motherboard, Intel _everything_. And yes, KMS decides to drive a nonexistent LVDS display, rather than the one that the BIOS correctly .. but if the BIOS drives one output, that should be a damn big hint that you shouldn't then just randomly pick another one! It sure as hell is a bigger hint than the ones you're using right now. The thing is, the BIOS _does_ report it to the hardware: you could just read the hardware registers. But no. Instead the Intel KMS code discards the hardware registers, and reads the BIOS tables instead, finds a LVDS entry there, and uses that - ...
On Wed, Aug 26, 2009 at 2:13 PM, Linus So most of your arguments are valid and someone at Intel should probably investigate it. Some points though: 1. I know what hw you have, you reported bugs against only Apple and SDVs, via Fedora we track a lot more hw, and we haven't seen this issue reported on any production PC hardware. 2. LVDS is enabled by the BIOS so we read back the hw, its turned on even on your SDV. So yes we shouldn't shut off VGA, but reading back the hw isn't reliable either. 3. Here's the thing, we do detect something has changed, we detect we no longer have a monitor connected on the mac mini because the routing for the DDC pins is insane and need special treatment in the driver. So maybe we get kms started and we fail when X tries to start or the first time the user sets a mode or probes the hw. We also would really like to know some information about the monitor you plugged in so we don't do anything stupid to it. so yes I think do better at failing is what is needed, its still failing but its more user friendly fail. Dave. --
That's the second thing - DDC in general seems to be _very_ flaky on intel chips. And I don't mean that in a "Mac Mini" kind of sense. I'm seeing in on other machines. Here's my old EeePC 701: [drm] Initialized drm 1.1.0 20060810 i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 i915 0000:00:02.0: setting latency timer to 64 i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data [drm] DAC-6: set mode 640x480 0 i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data [drm] TV-11: set mode NTSC 480i 0 allocated 800x480 fb: 0x007df000, bo f735b540 [drm] LVDS-8: set mode 800x480 15 Console: switching to colour frame buffer device 100x30 and quite frankly, I suspect you've never ever actually googled for "no EDID data", because if you had, you'd have seen that this is quite common. And yes, the response of KMS seems to be "ok, I failed at EDID, so I'll just assume something isn't there". And then usually it picks LVDS instead, if it finds a VBT table for it. Which happens to work fine on most laptops, but it's still just a random heuristic. And yes, for all I know it's because the display really doesn't do any EDID. And that really kind of is the point - it doesn't even matter whether the problem is the Intel driver doing something wrong on the EDID front (which it has done quite often - ranging from just looking at the wrong port, to not setting the right bits to make bit-banging i2c work AT ALL), or whether the problem is that the hardware is wired up oddly (Mac Mini) or whether it's the hardware simply not doign EDID at all (maybe my EeePC? Or a really old VGA monitor, or whatever). In all three cases the end result is "no EDID", but regardless of that, the correct action is basically _never_ to say "ok, I'll just assume that the display is on connector XYZ regardless of what the state of the Yes. If something fails ("oops, I can't seem EDID for any ...
On Wed, 26 Aug 2009 10:12:14 -0700 (PDT) Yeah, that's normal. Most builtin panels don't have EDIDs. Failures Right, we need to improve our detection heuristics. We've recently added some to catch non-existent LVDS displays, but currently don't have any for VGA. Using the current configuration as a guide is a reasonable addition... -- Jesse Barnes, Intel Open Source Technology Center --
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqU1bIACgkQHUdvYGzw6vdQcwCePOOpZRFU+hiv6EBCFB/kjqO/ noEAn0H0CkTKu9r5WUjsDihaI+q+vbLR =l06e -----END PGP SIGNATURE-----
I later told Keith to go ahead and send it onwards with the proviso someone would look at doing it properly. Granted with Linus suggestions maybe someone needs to look at it sooner. Dave. --
We can't depend on any BIOS display config as you noted before our driver. We know we have problem on Mac mini, this issue has been known for a while. And Keith also posted patch at http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html We've tried many ways to detect LVDS, but none is stable or actually work for every chip. But now we have DMI quirks for some known no LVDS machine (including Mac mini), and we detect through ACPI LID object for LVDS exist. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
But you do. You depend on the even _less_ reliable existence of a VBT If by "flexible" you mean "doesn't work in many more ways", then yes. I have never EVER found a BIOS that didn't output to at least _some_ screen that is connected. That's fairly damn fundamental. Yet that is exactly what KMS screws up on some hardware right now. And how about MacBook 2.1, which apparently also goes black? And dammit, if you cannot detect it, then don't try. You'd actually be better off not trying your random crud, and instead - leave whatever connection the BIOS set up - let the user _tell_ you about other ones. If you cannot reliably detect something, don't go off and use some random number generator. And quite frankly, depending on BIOS tables _is_ a random number generator. It may be that you just haven't learnt that yet, but maybe you could work on ACPI for a while to see what I mean. Right now, there's not even any way to _override_ your incorrect guesses. So I can say "don't do mode-setting at all", but I can't say "use SVDO at 1680x1050". So my screen goes black. And I happen to be in the enviable position of having known about the Mac Mini issues and the KMS thing - think about what happens to people that just try a new distro kernel, and suddenly there's nothing on the screen. Linus --
Linus, sorry for reply this old thread.
I just handed on one MacBook with 945GM, and tried to find out
the reason of black screen. It is TV detection that caused it.
MacBook routes integrated TV DAC to mini-DVI port too, like for VGA.
Our TV detect does load detect, which trys to set a mode onto TV port
and checked back its status. This TV load-detect makes the LVDS black
on MacBook.
It looks our load detect function has problem that when we pick
up one crtc, we don't check if its has a fb. During first TV detect,
choosed crtc obviously has no fb, it would fail in modesetting when
setting plane surface. This might have effect on the purpose of load-
detect process. I'll see how it should be fixed. But even if I hacked
plane setting with all zeros, screen still goes black on my MacBook,
although TV detect return is right that there's none found.
So this blank issue is within detect process, if you try to load fbcon
or X later, setting mode is fine on LVDS. That's why build fbcon in
kernel might workaround this issue.
I don't know much about our TV detect method details, but looks like
here we should check current TV status when system start. Otherwise
it seems we can't stopping blank the screen...So I did a temp hacking
like,
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 5b1c9e9..f3ecbaa 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1451,8 +1451,18 @@ intel_tv_detect(struct drm_connector *connector)
struct intel_output *intel_output = to_intel_output(connector);
struct intel_tv_priv *tv_priv = intel_output->dev_priv;
struct drm_encoder *encoder = &intel_output->enc;
+ struct drm_i915_private *dev_priv = connector->dev->dev_private;
int dpms_mode;
int type = tv_priv->type;
+ static int first_detect = 1;
+
+ if (first_detect) {
+ first_detect = 0;
+ if (!(I915_READ(TV_CTL) & TV_ENC_ENABLE))
+ return connector_status_disconnected;
+ else
+ return ...On Wed, 2009-08-26 at 11:58 +0800, Zhenyu Wang wrote:
Hi
From the config file it seems that the CONFIG_FRAMEBUFFER_CONSOLE is
set as m.
Will you please set it to y and see whether the black screen
happens?
Thanks.
--
On Tue, Aug 25, 2009 at 15:07:55 -0700, Linus Torvalds wrote: Hi Linus, for the Mac mini case, I need at least this patch to get the DVI output working: http://bugs.freedesktop.org/show_bug.cgi?id=23350 Without the patch, the KMS code won't detect any modes because it gets no EDID via DDC. Regards, Tino --
