Bug#437009: No window borders in latest Compiz
I figure that's the issue for me - though I don't have access to a Lenny/Sid machine to test it at the moment. You can go ahead and close this if you wish... On 8/24/07, Sven Arvidsson [EMAIL PROTECTED] wrote: On Fri, 2007-08-24 at 22:14 +0200, Brice Goglin wrote: So the actual original bug would just be that the decoration plugin isn't loaded by default? If so, great, it's easy to fix. As I said in http://bgoglin.livejournal.com/11253.html, _lots_ of plugins have to be enabled manually to get something interesting in Compiz. I did read that post, but I guess I expected at least some basic plugins by default (functionality similar to metacity, only with compositing). If that's not possible, at the very least should README.Debian be updated, as it now reads; $ compiz --replace Which will start compiz, make it replace the current window manager and background the process so you can safely close the terminal again. If all went well, compiz should start up and enable a whole bunch of desktop effects. -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22
Bug#437018: closed by Joey Hess [EMAIL PROTECTED] (Re: Bug#437018: Network shouldn't be used/enforced on non-network installs)
-- Forwarded message -- From: Joey Hess [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 15 Aug 2007 16:13:23 -0400 Subject: Re: Bug#437018: Network shouldn't be used/enforced on non-network installs Wouter Verhelst wrote: (there's no working connection to the Internet, but what the heck, we'll try anyway, and if it doesn't work, the admin will have to wait for the connection to time out an insane number of times) If there's no network connection *at all*, there is no timeout to wait for. Try it yourself: [EMAIL PROTECTED]:/home/joeyifdown wlan0 ... [EMAIL PROTECTED]:/home/joeytime apt-get update ... 0.06user 0.04system 0:00.21elapsed 48%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+3403minor)pagefaults 0swaps zsh: exit 100 command time apt-get update In the edge case where there is a network connection with a default route that doesn't work, you get to wait for a timeout. We have discussed this before, and this is a sufficiently uncommon enough case that it's not worth asking in every install whether d-i should hit the network[1]. If you're in such a situation, unplug your network cable, or fix your network before trying to install Debian, or run the install in expert mode and tell it not to set up a network connection. I see what you're saying. However, one must still navigate the d-i steps related to networking in any case, and in my experience I've had to wait for a DHCP timeout on a disconnected network card. IMHO, it seems logical to add a Don't use a network for this install option as a choice on the screen which lists the available network cards. If that is selected, the updates step and all network-related steps would be skipped entirely. I think that would be the ideal solution - it would make the install much more friendly to users who don't have networking during the install. This situation is probably more common than you think, since it includes every wi-fi-only user as well as anyone who uses authentication methods like 802.11x. Could this be considered? Tim Tim
Bug#437705: Gksu causes large amount of wakeups from idle w/tickless kernel
Package: gksu Version: 2.0.0-1 On my Debian Etch install with backported 2.6.22 kernel, running any application that uses gksu (such as the Root Terminal) causes an extraordinarily high amount of wakeups (and thus, a large amount of power to be consumed) as measured with the PowerTOP 1.7 tool. In the case of applications which use gksu for authentication, this continues as long as the application is open, and does NOT stop after the user has successfully authenticated. For comparison: System with gnome-terminal open, doing nothing: Wakeups-from-idle per second : 422.0 System with gnome-terminal open, doing nothing (invoked with gksu): Wakeups-from-idle per second : 1550.6 This needs to be fixed...
Bug#437009: No window borders in latest Compiz
Any warning? Is gtk-window-decorator running after starting compiz? if so, kill it and compiz --replace again and again? Brice The warnings I got were: GLX_EXT_texture_from_pixmap is not available with direct rendering. GLX_EXT_texture_from_pixmap is available with indirect rendering. gtk-window-decorator IS running after I do compiz --replace, and if I kill it and run compiz --replace again, I initially lose the borders. However, if I do compiz --replace a third time, I get the borders to appear. However, only some applications - and not all - get borders. In particular, newly-launched applications (after Compiz is run) never acquire borders, and tend to start in the top left-most corner of the screen rather than the middle of the screen.
Bug#437019: Don't lock display on suspend-to-RAM
This is intentional, because it is a very bad idea, security speaking, not to lock the screen when you are not using the system. If you really want to do that, you can change the /apps/gnome-power-manager/lock_on_suspend GConf key. OK - I guess I don't like it because Mac OS X and Windows do nothing of the sort and it takes long enough to resume from suspend in Debian as-is. I understand the security risk - it definitely seems worthwhile to do this if your system is being left in a public place - though it becomes less of a concern if this isn't the case. In any case, it would be nice to have this as a GUI-configurable option in g-p-m - the gconf key will do for now, though... Thanks for responding, though... Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. (Your sig is funny - I like it :))
Bug#434833: Issue with X rebooting system/new intel driver
Hi, Is there any progress on this issue (spontaneous rebooting in X with the intel driver)? I'm experiencing this on both Debian and Ubuntu with said driver, so it definitely is an upstream issue. Has an upstream bug been filed? I'm not acquainted with X.org's bug reporting system myself... In the meantime, is there a place I can get the latest version of the old i810 driver? xserver-xorg-video-i810 in both testing and unstable is simply a transitional package. In my case, if I use i810+915resolution, I have no issues whatsoever with X and spontaneous rebooting. Tim
Bug#437018: Network shouldn't be used/enforced on non-network installs
I guess having it look for a network in the background and silently fail would be preferable, in any case. Is this doable? On 8/10/07, Christian Perrier [EMAIL PROTECTED] wrote: Quoting Tim Hull ([EMAIL PROTECTED]): It would be GREAT if the network-related steps would be skipped/bypassed on a default install from non-netinstall media. Users then could configure the network at their leisure after the install using the tools they prefer (NetworkManager etc). Could this be considered? Probably not. Having a system with immediate support for security updates is one of the key features of Debian. Doing this would defeat that design choice. I'm letting other D-I team members give their advice and decide whether this bug report should be kept or marked wontfix. -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGu/1r1OXtrMAUPS0RAvwAAJoCbz6zN8M4ZXBWVjIAix7ekHr1gwCgoWOg dUzSO/6xCpIaWOHTn6NOsxs= =eJ8o -END PGP SIGNATURE-
Bug#437018: Network shouldn't be used/enforced on non-network installs
Of course security updates should be enabled by default, and I do agree that it's sensible for the system to _ask_ to try to install security updates even if there's no network. But there are cases where security updates don't make much sense, and I do think that the current behaviour (there's no working connection to the Internet, but what the heck, we'll try anyway, and if it doesn't work, the admin will have to wait for the connection to time out an insane number of times) is a bug. In my circumstance, I've been installing on a system with both an Ethernet card (supported during the install) and a wi-fi card (supported with non-free madwifi driver). I currently don't use the ethernet - wi-fi is all I use. When I go back to school (in about 2 weeks or so), I'll have Ethernet, but it uses 802.1x authentication so it still will be worthless for the install. Furthermore, even if I had networking durring the install, I do NOT like the idea of downloading updates during the install without prompting - sometimes I'm using a satellite internet connection with some pretty hefty bandwidth quotas and would MUCH rather grab these updates during off-peak hours. I had this cause bandwidth throttling in the past when I was installing Debian in a VM with network connectivity during the install. Anyway, it seems like there should be a would you like to use the network question or option in the installation boot menu. As it stands, the current behavior is quite bad for those who either have no usable network during an install (which I would have to guess is sizable) and even worse for those who *do* have networking but which have limited bandwidth that they don't want sucked up at will. Tim
Bug#437182: CD Burner should be default program associated with ISO mimetype
Package: nautilus-cd-burner Version: 2.18.2-1 In a Debian sid install with the desktop task installed, nautilus-cd-burner isn't the default handler associated with the mimetype for .ISO files - file-roller is. This should be changed, such that opening a .iso file burns its contents to a CD.
Bug#437013: d-i doesn't properly understand LVM groups with active snapshot volumes
The message states: Unable to determine geometry of file/device. You should not use Parted unless you REALLY know what you're doing! The log is attached... On 8/10/07, Otavio Salvador [EMAIL PROTECTED] wrote: Tim Hull [EMAIL PROTECTED] writes: Package: debian-installer Version: 20070308 I recently used d-i to install Debian Etch to a volume that was part of an LVM volume group that contained an active snapshot volume. While the installation proceeded fine, it issued an error message to the effect that something was wrong with the partition table (can't recall the exact message). This should be fixed for future d-i releases... Can you check your installed system on /var/log/installer/ and see if the error message is avaiable there? In case you find it, you can send the logfile, bziped, to the bug report. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. partman.bz2 Description: BZip2 compressed data
Bug#434833: Spontaneous reboots on suspend-to-RAM with new Xorg intel driver
I must note that I do have the composite extension enabled. If I disable composite, I see these issues occur much less frequetly. On 7/27/07, Julien Cristau [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2007 at 23:27:51 -0400, Tim Hull wrote: When using the new intel video driver that replaced the former i810 driver in Debian, I am experiencing spontaneous reboots randomly on suspend-to-RAM. What are you using for suspend/resume? Right before the system spontaneously reboots, I see a checkered pattern on a black-and-white console display. At times, though rare, I have also seen similar crashes when stopping and restarting the X server manually - which leads me to believe that starting/stopping the X server is what is causing the issue. I have no such problem when using 915resolution and the old i810 driver in Etch and on Ubuntu Feisty (their stable), but do see the same problem on Ubuntu Gutsy (their unstable) which uses the intel driver. While it doesn't occur every time I suspend, it occurs often enough that this is a MAJOR annoyance for me. I'm marking this as RC, as such crashes DO cause data loss in open files - you're free to disagree with me, though... That's not what data loss means. System configuration is a MacBook Core Duo (first generation) with 2GB RAM and Debian Sid. I've attached my xorg.conf and appropriate logs... Thanks, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqclAmEvTgKxfcAwRAkL/AKCKOW6jyvcqKMCG0kOCqORzevVkRQCfYZdK vj3gLM/cmygo5gkhzurvph8= =6eET -END PGP SIGNATURE-
Bug#434833: Spontaneous reboots on suspend-to-RAM with new Xorg intel driver
Actually, I don't think it happens at all - at least I can't reproduce it as of now without composite. So this seems to be an issue between composite (and/or additional settings needed to get it working) and the new mode-setting driver (it didn't happen w/i810+915resolution). On 8/9/07, Brice Goglin [EMAIL PROTECTED] wrote: Tim Hull wrote: I must note that I do have the composite extension enabled. If I disable composite, I see these issues occur much less frequetly. Less frequency or not at all? Brice
Bug#434833: Spontaneous reboots on suspend-to-RAM with new Xorg intel driver
I guess I was wrong - it just happened without composite. So I guess it's completely random, other than the fact that it freezes/reboots at random times when: * I switch from X to console * I suspend/resume the machine * I kill the X server (Ctrl-Alt-Backspace) with the new modesetting intel driver. This did not happen with i810+915resolution. Before freezing/rebooting, the console always displays a checkerboard pattern. On 8/9/07, Tim Hull [EMAIL PROTECTED] wrote: Actually, I don't think it happens at all - at least I can't reproduce it as of now without composite. So this seems to be an issue between composite (and/or additional settings needed to get it working) and the new mode-setting driver (it didn't happen w/i810+915resolution). On 8/9/07, Brice Goglin [EMAIL PROTECTED] wrote: Tim Hull wrote: I must note that I do have the composite extension enabled. If I disable composite, I see these issues occur much less frequetly. Less frequency or not at all? Brice
Bug#437007: Arial and other Core Fonts should be remapped to Bitstream Vera/DejaVu by default
Package: fontconfig-config Version: 2.4.2-1.2 With the default font configuration, Arial and the other fonts that make up the MS Core Fonts aren't remapped/aliased to any sane alternative. Thus, if Arial is used by a website in a browser that uses the system default font configuration, it will fall back on a font that is less-than-sane (in the case of debian.org, you can see it fall back to *bitmap Helvetica*). It would be nice to use a font like DejaVu Sans if Arial is requested by the system (this is what is done on Ubuntu). I tried to find where Debian and Ubuntu's font configuration diverges (to figure out how to make this fix) but was unsuccessful in doing so. Hopefully the fontconfig maintainer(s) may be able to locate this in order to fix the issue.
Bug#437009: No window borders in latest Compiz
Package: compiz Version: 0.5.0.dfsg-2 Priority: important On Debian sid with the latest Compiz and X installed, running compiz --replace with an active Gnome/Metacity session results in there being no window borders. Compiz effects (cube, window effects, alt+tab, etc) all work, but none of my windows have window borders. I even tried unregistering the /apps/compiz settings in gconf, but it still doesn't work - hence Compiz is basically unusable. I'm using a MacBook with Intel GMA 950 graphics and the X.org intel driver. No such problems were experienced with Compiz with the same system in Etch.
Bug#437018: Network shouldn't be used/enforced on non-network installs
Package: debian-installer Version: 20070308 Priority: wishlist During installs from CD-ROM and DVD media, users are still currently prompted to set up the network and download security fixes from the network. However, many (quite possibly most) users who use the full-blown install media (as opposed to the netinstall CD) do not have access to a network connection which is functional during the install and as such have to navigate through these steps and the inevitable errors they produce for no reason at all. It would be GREAT if the network-related steps would be skipped/bypassed on a default install from non-netinstall media. Users then could configure the network at their leisure after the install using the tools they prefer (NetworkManager etc). Could this be considered?
Bug#437016: d-i inconsistent in definition of GB used
Package: debian-installer Version: 20070308 During an Etch install, the partitioning step is inconsistent about the definition of a gigabyte. For example, when LVM volumes are created, the definition of GB used for specifying their size is (1024*1024*1024) bytes. However, the definition of GB used on the main partitioning screen is a billion (1000*1000*1000) bytes. Thus, a 10.0GB LVM volume will appear confusingly as 10.6 GB on the main partitioning screen. This should be fixed in a future d-i build.
Bug#437012: Gdebi should be default handler for application/x-deb when installed
Package: gdebi Version: 0.2.4debian1 Currently, I have gdebi installed on my Debian Sid system. While it is registered as a handler for the MIME type application/x-deb in the system, it is NOT the default application for GNOME/Iceweasel/etc to handle .deb files (File Roller is). It seems like if gdebi is installed on a system, it should make itself the default handler for .debs (in GNOME/Iceweasel/etc) on the system which it is installed.
Bug#437013: d-i doesn't properly understand LVM groups with active snapshot volumes
Package: debian-installer Version: 20070308 I recently used d-i to install Debian Etch to a volume that was part of an LVM volume group that contained an active snapshot volume. While the installation proceeded fine, it issued an error message to the effect that something was wrong with the partition table (can't recall the exact message). This should be fixed for future d-i releases...
Bug#437019: Don't lock display on suspend-to-RAM
Package: gnome-power-manager Version: 2.18.3-1 Priority: wishlist Currently, when one suspends-to-RAM using the Suspend option in gnome-power-manager, the display is locked upon resume from suspend. This is somewhat annoying, as I did not set my system to lock on suspend-to-RAM in the suspend scripts. Could gnome-power-manager not do this by default? It is quite annoying for a user who suspends their system for short periods of time often and has no way of disabling this besides calling suspend-to-RAM scripts manually from the command line.
Bug#434833: Spontaneous reboots on suspend-to-RAM with new Xorg intel driver
Just default acpi-support + gnome-power-manager (I set my system to suspend on lid close). On 7/27/07, Julien Cristau [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2007 at 23:27:51 -0400, Tim Hull wrote: When using the new intel video driver that replaced the former i810 driver in Debian, I am experiencing spontaneous reboots randomly on suspend-to-RAM. What are you using for suspend/resume? Right before the system spontaneously reboots, I see a checkered pattern on a black-and-white console display. At times, though rare, I have also seen similar crashes when stopping and restarting the X server manually - which leads me to believe that starting/stopping the X server is what is causing the issue. I have no such problem when using 915resolution and the old i810 driver in Etch and on Ubuntu Feisty (their stable), but do see the same problem on Ubuntu Gutsy (their unstable) which uses the intel driver. While it doesn't occur every time I suspend, it occurs often enough that this is a MAJOR annoyance for me. I'm marking this as RC, as such crashes DO cause data loss in open files - you're free to disagree with me, though... That's not what data loss means. System configuration is a MacBook Core Duo (first generation) with 2GB RAM and Debian Sid. I've attached my xorg.conf and appropriate logs... Thanks, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqclAmEvTgKxfcAwRAkL/AKCKOW6jyvcqKMCG0kOCqORzevVkRQCfYZdK vj3gLM/cmygo5gkhzurvph8= =6eET -END PGP SIGNATURE-
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
I think this just simply a dupe of 399039, and I figure Ubuntu is building
HAL with MacBook support. From the looks of that kernel driver, it appears
us MacBook users are stuck with pommed until somebody writes a kernel driver
to interface with HAL..
On 7/26/07, Tim Hull [EMAIL PROTECTED] wrote:
I'm actually on a MacBook (non-Pro) but I figure HAL works the same in
both cases...
On 7/26/07, Sven Arvidsson [EMAIL PROTECTED] wrote:
On Thu, 2007-07-26 at 18:14 +0200, Julien BLACHE wrote:
HAL/g-p-m should support the MacBook {,Pro} out of the box, and
without pommed as far as the LCD backlight and sound support goes,
though AFAIK it doesn't use ACPI.
It looks like HAL in Debian is built without support for the macbook
pro, see http://bugs.debian.org/399039
--
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
I'm actually on a MacBook (non-Pro) but I figure HAL works the same in both
cases...
On 7/26/07, Sven Arvidsson [EMAIL PROTECTED] wrote:
On Thu, 2007-07-26 at 18:14 +0200, Julien BLACHE wrote:
HAL/g-p-m should support the MacBook {,Pro} out of the box, and
without pommed as far as the LCD backlight and sound support goes,
though AFAIK it doesn't use ACPI.
It looks like HAL in Debian is built without support for the macbook
pro, see http://bugs.debian.org/399039
--
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
I have acpi-support, and I have the other significant power-management stuff installed here. In fact, I can suspend-to-RAM with no problem using g-p-m and stock configuration, and I can change the brightness using pommed (I'm on a MacBook). Does anyone have a clue as to WHY I'm not seeing brightness control support as I do on Ubuntu with the same version of g-p-m? I am running Debian unstable currently, so I do have the latest versions of everything... On 7/26/07, Loïc Minier [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2007, Tim Hull wrote: In Ubuntu Feisty, gnome-power-manager includes support for controlling LCD brightness. In Debian, the shipped version of gnome-power-manager does NOT have this feature. Could Debian please sync with the Ubuntu patchset for this package - brightness control is a useful feature... I'm running Debian's gnome-power-manager and I have support for brightness-control. Perhaps you're missing packages to support your hardware? Do you have acpi-support for example? -- Loïc Minier
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
They don't use pommed at all - they use just gnome-power-manager. I'm just saying pommed will change the brightness on Debian, so it is obvious brightness CAN be changed on Debian. Regarding the changes, Ubuntu posts its changes to Debian sources at patches.ubuntu.com. Gnome-power-manager's patchfile is located at: http://patches.ubuntu.com/g/gnome-power-manager/ Be forewarned that these are patches against the latest development version (2.19.5) as that's what they have in their unstable repositories. Is there a filesystem directory where I can find system-specific brightness configurations? I figure Ubuntu includes the patches necessary to adjust MacBook brightness, and Debian does not. On 7/26/07, Loïc Minier [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2007, Tim Hull wrote: I have acpi-support, and I have the other significant power-management stuff installed here. In fact, I can suspend-to-RAM with no problem using g-p-m and stock configuration, and I can change the brightness using pommed (I'm on a MacBook). Does anyone have a clue as to WHY I'm not seeing brightness control support as I do on Ubuntu with the same version of g-p-m? I am running Debian unstable currently, so I do have the latest versions of everything... AFAIK, the pommed author knowingly skipped HAL integration as it was considered too painful. Perhaps Ubuntu doesn't use pommed or adds another package providing more information or patches pommed to provide the information? Anyway, it would be nice if you could extract the differences and attach them here, but I'm convinced this is machine specific. -- Loïc Minier
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
OK - It appears the underlying issue is that HAL is built without MacBook support for the reason that it uses hackish solutions (writing directly to /dev/mem in particular). Ubuntu builds HAL with MacBook support, and hence g-p-m functions fine on that distribution. I merged this with the bug report against HAL for this (which was closed as wontfix). I figure we're stuck with th status quo without a kernel module to control MacBook brightness using HAL... It would be nice, though, if we could come up with a temporary workaround - as of now you are basically restricted to running without full g-p-m support on a MacBook, patching HAL manually for each update, or running Ubuntu :) On 7/26/07, Loïc Minier [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2007, Julien BLACHE wrote: And for the record, the GNOME people did not want to integrate with pommed other than by having me code up the whole thing into HAL, which is NOT what I wanted to do. I'm still open to integration with the GNOME things, and the DBus notifications interface are there for a reason. The GNOME people are free to pick up the DBus notifications on the system bus; don't ask me why they didn't do it. It sounds reasonable to integrate such a support into HAL, but I can also understand you can't be bothered to implement it if you don't like it. Was this discussed in a gnome.org bug? It would be nice to link this bug to the upstream issue where the HAL changes are proposed. -- Loïc Minier
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
Then I figure that this is NOT, in fact, an issue of merging Ubuntu patches
OR an issue related to pommed but a bug with g-p-m recognizing MacBooks in
Debian. I've retitled the bug appropriately. Does anyone have a clue as to
where I would look? I'm thinking Ubuntu configures something to make this
work that Debian does not for some weird reason...
On 7/26/07, Julien BLACHE [EMAIL PROTECTED] wrote:
Loïc Minier [EMAIL PROTECTED] wrote:
AFAIK, the pommed author knowingly skipped HAL integration as it was
considered too painful. Perhaps Ubuntu doesn't use pommed or adds
another package providing more information or patches pommed to provide
the information?
HAL/g-p-m should support the MacBook {,Pro} out of the box, and
without pommed as far as the LCD backlight and sound support goes,
though AFAIK it doesn't use ACPI.
And for the record, the GNOME people did not want to integrate with
pommed other than by having me code up the whole thing into HAL, which
is NOT what I wanted to do. I'm still open to integration with the
GNOME things, and the DBus notifications interface are there for a
reason. The GNOME people are free to pick up the DBus notifications on
the system bus; don't ask me why they didn't do it.
JB.
--
Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED]
Public key available on http://www.jblache.org - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Bug#434527: Madwifi problems associating using wext/NetworkManager
I have spent a significant amount of time dealing with issues between MadWifi and wext/wpasupplicant/NetworkManager on Debian (etch, lenny, AND sid). As it stands, there are still significant issues - in factI cannot associate *at all* to my stock, unencrypted WRT54G using NetworkManager+madwifi on my Atheros 5424 card (bundled with MacBook Core Duo). This is about as standard of a configuration as you can get, so it's obviously a widespread bug. I have managed to isolate the issue to a degree. Though I'm somewhat C-impaired, the issue does seem to stem from issues w/wext compliance - and in particular AP scanning and the preempt_scan function. This seems to be a long-standing issue, and has existed in every build of madwifi I've tried. The upstream bug mentioned earlier in this thread is still open, and there appears to be no progress whatsoever on that front. Anyway, there is currently two workarounds that I've tested and know to work. The first, and the one used by Ubuntu, is to change NetworkManager's source such that the wpasupplicant's madwifi driver is used for cards using madwifi instead of the generic wext driver. This seems to work well, though the Debian maintainer for NetworkManager didn't like the idea of special behavior for madwifi. Secondly, there is the option of totally removing the preempt_scan() function and all calls to it from ieee80211_wireless.c. This seems to work perfectly to me, but may come at the loss of some functionality (namely, wireless scan timeout). This function was only added in the last 6-9 months, though, so the driver is known to work without it. I've attached my patch to remove the function in question (preempt_scan) from ieee80211.c. I've attached patches to both the release used in unstable and the trunk from madwifi.org (which, in my experience, blows away the release in wireless performance - in addition to adding support for the Atheros 802.11n chipsets). I hope a workaround such as the one(s) I've suggested can be uploaded to the archive - this can be quite a nasty bug for some Atheros users... patch-release Description: Binary data patch-trunk Description: Binary data
Bug#434702: Please sync with trunk snapshot - new chipset support/better signal strength
Package: madwifi-source Version: 0.9.3-3 Severity: wishlist Currently, the release version of madwifi is missing a significant amount of functionality when compared to the trunk builds at madwifi.org. For one thing, the trunk builds add support for 802.11n Atheros chipsets, which are found in many new systems containing Atheros chipsets including the MacBook Core 2 Duos. Furthermore, I have consistently noticed a 20% gain in signal strength using the trunk as compared to the release - certainly a significant increase. Finally, I'm seeing an increase in association speed when using NetworkManager on the trunk builds as compared to the release Is it possible to sync this package to a trunk build, add a new madwifi-source-trunk package, or put a trunk madwifi-source in experimental? It seems like it would be beneficial to many users...
Bug#434711: Sync with Ubuntu changes - adds brightness control, etc...
Package: gnome-power-manager Version: 2.18.3-1 Severity: wishlist In Ubuntu Feisty, gnome-power-manager includes support for controlling LCD brightness. In Debian, the shipped version of gnome-power-manager does NOT have this feature. Could Debian please sync with the Ubuntu patchset for this package - brightness control is a useful feature...
Bug#434557: Acknowledgement (Random kernel panic on boot with MacBook)
I applied the attached patch (from Ubuntu) to the latest 2.6.22 kernel from
Sid and it resolved the problem. Could this be looked into?
On 7/24/07, Debian Bug Tracking System [EMAIL PROTECTED] wrote:
Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received. It is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
Debian Kernel Team [EMAIL PROTECTED]
If you wish to submit further information on your problem, please send
it to [EMAIL PROTECTED] (and *not* to
[EMAIL PROTECTED]).
If you have filed this report in error and wish to close it, please
send mail to [EMAIL PROTECTED] with an explanation
why the bug report should be closed.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
diff -urp a/init/calibrate.c b/init/calibrate.c
--- a/init/calibrate.c 2006-10-02 11:39:32.0 -0400
+++ b/init/calibrate.c 2007-01-27 16:39:35.0 -0500
@@ -1,5 +1,7 @@
/* calibrate.c: default delay calibration
*
+ * vim:sw=8 noet
+ *
* Excised from init/main.c
* Copyright (C) 1991, 1992 Linus Torvalds
*/
@@ -7,9 +9,36 @@
#include linux/sched.h
#include linux/delay.h
#include linux/init.h
+#include linux/dmi.h
+#include asm/io.h
#include asm/timex.h
+/* On Macbook we have trouble calibrating the delay loop due to excessive
+ * latency in the system management interrupt. We fix this problem by
+ * disabling the legacy USB function of the SMC during delay loop
+ * calibration. From Intel ICH7 manual, this is bit 3 of SMI_EN register
+ * located at 0x430.
+ */
+static int __initdata macbook_calibrate_quirk;
+
+static int __init init_macbook_calibrate_quirk (struct dmi_system_id *d)
+{
+ printk(KERN_WARNING %s detected (calibration quirk enabled)\n,
+ d-ident);
+ macbook_calibrate_quirk = 1;
+ return 0;
+}
+
+static struct dmi_system_id __initdata calibrate_quirks[] = {
+ {
+ .callback = init_macbook_calibrate_quirk,
+ .ident = Apple MacBook,
+ .matches = {DMI_MATCH(DMI_PRODUCT_NAME, MacBook1,1),},
+ },
+ {},
+};
+
static unsigned long preset_lpj;
static int __init lpj_setup(char *str)
{
@@ -37,8 +66,16 @@ static unsigned long __devinit calibrate
unsigned long tsc_rate_min, tsc_rate_max;
unsigned long good_tsc_sum = 0;
unsigned long good_tsc_count = 0;
+ unsigned long saved_smi_en = 0;
int i;
+ if (macbook_calibrate_quirk)
+ {
+ saved_smi_en = inl(0x430);
+ /* mask out bit 3 */
+ outl(saved_smi_en ~8, 0x430);
+ }
+
if (read_current_timer(pre_start) 0 )
return 0;
@@ -94,6 +131,9 @@ static unsigned long __devinit calibrate
}
}
+ if (macbook_calibrate_quirk)
+ outl(saved_smi_en, 0x430);
+
if (good_tsc_count)
return (good_tsc_sum/good_tsc_count);
@@ -117,6 +157,8 @@ void __devinit calibrate_delay(void)
unsigned long ticks, loopbit;
int lps_precision = LPS_PREC;
+ dmi_check_system(calibrate_quirks);
+
if (preset_lpj) {
loops_per_jiffy = preset_lpj;
printk(Calibrating delay loop (skipped)...
Bug#434527: NetworkManager won't associate when using madwifi
Package: network-manager Version: 0.6.4-8 When using a madwifi-based wireless card (with driver built from madwifi-source 0.9.3-3 in sid), it is currently impossible to associate to any access point using NetworkManager. NetworkManager will see the access points, but upon attempting to associate, the lights in nm-applet never turn green and it eventually gives up. The card works fine when configured manually (without using NetworkManager). My system is an up-to-date Debian sid/i386 installation using kernel 2.6.22-1 (from sid) and libc6 2.6-3. This seems somewhat related to the wpa_supplicant settings used by network-manager, as Ubuntu's network-manager has patches which specifically use wpa_supplicant's madwifi driver as opposed to its wext driver. In Ubuntu's case, NetworkManager works flawlessly on the same machine, and installing the Ubuntu network-manager package makes it work on Debian (though that setup has other difficulties due to the problems mixing Debian/Ubuntu packages). Could a fix such as the one used in Ubuntu's case be investigated? The patch is part of the (big) network-manager patch on patches.ubuntu.com. This issue is somewhat of a show-stopper in my case...
Bug#434540: MacBook makes subtle whining noise when idle since 2.6.21
Package: linux-image-2.6-686 Version: 2.6.22-1 Since kernel 2.6.21, my MacBook has made a subtle whining noise when idle. This happens when using the Debian stock kernels from testing and unstable, but also when using other kernels. I believe it has something to do with certain ACPI power-saving modes and/or the switch from 250hz kernel timing to a tickless kernel. 2.6.18 as shipped in Etch does NOT exhibit this problem, and disabling C3/C4 ACPI C-states is a functional workaround for 2.6.21+ (though doing so results in the loss of some battery life). However, C3/C4 ACPI C-states work fine in the aforementioned 2.6.18 kernel, so the HZ timing seems like a more likely root cause.
Bug#434541: Appletouch module not loaded at boot time on supported hardware
Package: udev Version: 0.105-4 On my hardware (MacBook Core Duo), the appletouch module is used for maximum functionality of the touchpad. However, this module is not loaded at boot by default - instead, the usbhid module is used, which works but doesn't support advanced features of the touchpad (scrolling, multi-button taps, etc). The appletouch module CAN be used in Debian, though creating a file in /etc/modprobe.d is necessary to make it work. On Ubuntu, appletouch is loaded by default. Could this be done in Debian as well
Bug#434541: Appletouch module not loaded at boot time on supported hardware
I don't know exactly what needs to be fixed to resolve the issue in Debian, but I will try to give a little more background information: What I basically want is for the udev rules to be changed such that the appletouch module is used for the touchpad (though usbhid is still needed for the keyboard). Sorry if I can't give more technical specifics - though I do know for a fact this was fixed in Ubuntu before. I'll take a look at their udev rules and send more info if possible... I added the following to /etc/modprobe.d/appletouch as a workaround: install usbhid /sbin/modprobe appletouch; /sbin/modprobe --ignore-install usbhid $CMDLINE_OPTS * extra system info - to help with fixing this * Related dmesg output: input: appletouch as /class/input/input23 input: Apple Computer Apple Internal Keyboard / Trackpad as /class/input/input24 input: USB HID v1.11 Device [Apple Computer Apple Internal Keyboard / Trackpad] on usb-:00:1d.0-2 My lsusb output: Bus 005 Device 003: ID 05ac:8300 Apple Computer, Inc. Bus 005 Device 001: ID : Bus 002 Device 001: ID : Bus 004 Device 008: ID 05ac:1000 Apple Computer, Inc. Bus 004 Device 001: ID : Bus 003 Device 006: ID 05ac:8240 Apple Computer, Inc. Bus 003 Device 001: ID : Bus 001 Device 008: ID 05ac:0217 Apple Computer, Inc. Bus 001 Device 001: ID : On 7/24/07, Marco d'Itri [EMAIL PROTECTED] wrote: On Jul 24, Tim Hull [EMAIL PROTECTED] wrote: On my hardware (MacBook Core Duo), the appletouch module is used for maximum functionality of the touchpad. However, this module is not loaded at boot by default - instead, the usbhid module is used, which works but doesn't support advanced features of the touchpad (scrolling, multi-button taps, etc). The appletouch module CAN be used in Debian, though creating a file in /etc/modprobe.d is necessary to make it work. On Ubuntu, appletouch is loaded by default. Could this be done in Debian as well I am sorry, but I am currently having troubles reading your mind and/or your file system. Do you mind explaining me what am I supposed to do? -- ciao, Marco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpk40FGfw2OHuP7ERArxFAJ93ZShBulYiKBn3aBwV+A1NjIzAVgCffk8B Bt4ZCbXDd84V2aVHGna0IZE= =9P+O -END PGP SIGNATURE-
Bug#434557: Random kernel panic on boot with MacBook
Package: kernel-image-2.6-686 Version: 2.6.22-1 On my MacBook Core Duo, I am experiencing random kernel panics on boot. The message I am getting is as follows: Kernel panic - not syncing: IO-APIC + timer doesn't work! This appears about 50% of the time on boot, and happens on every version of the Debian kernel including that shipped with Etch and the latest version. This can be worked around by using the lpj= kernel parameter on boot (lpj=733 for a 1.83GHz MacBook). Ubuntu has the same issue (Bug 54621 on Launchpad - https://bugs.launchpad.net/bugs/54621) and a fix mentioned in that thread has apparently been committed. Could this be fixed in the Debian kernel?
Bug#408207: Issue still present/possible fix from upstream
Hi, I am thinking 408207 and 385599 are dupes - they sould like pretty much the same bug to me. Anyway, this still exists in the latest package - I can use my Wifi by configuring it manually through GNOME's Network control panel, but not through network manager. What I have found is that the issue seems to be specifically confined to madwifi, NetworkManager, and unprotected access points. If you change any of these, it works fine. I did find an upstream bug about this, and reverting the guilty revision mentioned in that bug fixed the problem for me. http://madwifi.org/ticket/1030 is the upstream bug in question...Fixing that seems to cure the problem. Tim
