Bug#735424: nvidia-driver: New vesa test
Am 29.01.2014 12:52, schrieb Diederik de Haas: O.K. - but what is the difference? As user i expect to get the correct headers for the kernel linux-image-3.12-1-amd64 when i install 'linux-headers-3.12-1-amd64' That is correct. But you have the package 'linux-image-amd64' installed (and that's a good thing), so when a new kernel enters testing, it will be installed on your system and then you won't have the corresponding headers package on your system. No - i only installed the package linux-headers-3.12-1-amd64. The package linux-image-amd64 was installed automatically! First i have to install the original nvidia driver now. If you mean the 'nvidia-driver' package from Debian, then yes, do that. And report back with the requested information. Sorry - misstyping - i mean UNinstall the origianl nvidia driver. Do you think it is a good idea to start with a clean new copy of wheezy now and upgrade it to jessie? I think everything is really mixed up now. Not now. Let's try to find (and fix) your issue now, otherwise you may end up in the same situation again. Yes - i assume this will be the same. But there is an system upgrade and the installation of the original nvidia package between? What's about the backup of the system before the installation of the original nvidia driver? But it wouldn't hurt to start *preparing* for a complete new install and migrating your users files/settings/etc. Of course - but for 3 users this is really much trouble. And i must compare to have the same packages installed. I did this one time and it takes some days work. There should be a way to upgrade a system ... Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736145: nvidia-detect gives no senseful output
Am 27.01.2014 20:00, schrieb Andreas Beckmann: On 2014-01-27 17:23, Karsten Malcher wrote: Am 25.01.2014 16:57, schrieb Andreas Beckmann: On 2014-01-20 10:30, Karsten Malcher wrote: When i run nvidia-detect i get this output: Detected NVIDIA GPUs: 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) Your card is supported by the default drivers and version 304. It is recommended to install the nvidia-driver package. That's wrong! Correct should be 319.76 and this is installed: Why do you think this is wrong? What would you expect instead? Andreas Please read exact - current driver is 319.76 or not? The purpose of nvidia-detect is not to tell you something about upstream version numbers, ... O.K. It's not a bug - it's a feature. nvidia-detect cries for 304. So how to install something that does not exist? ;-) ... but about Debian package names. And 'nvidia-driver' does exist. That's what 'default drivers' is about. The description says: The 'nvidia-detect' script in this package checks for an NVIDIA GPU in the system and recommends one of the non-free accelerated driver meta-packages When the main function is only to recommend something, everything is perfect. :-) But you are right, we could mark the '304' more prominently as 'legacy'. Fine. :-) Close the bug. Andreas PS: Note to self: check that nvidia-detect in wheezy-backports outputs something sane Then i should update the wiki that this package exists. It's really not clear how get NVidia running in Debian ... Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: nvidia-driver: New vesa test
O.K. Thank you for the advice. 1. I will deinstall all unneeded header packages 2. I will install the correct one and check it with dbsums 3. I will try to install the original nvidia driver and prove if it will work 4. When there is no hope to find the problem up to this point i will make a new installation of testing on the partition. Am 27.01.2014 20:28, schrieb Andreas Beckmann: Is the linux-headers-3.12-1-common package correctly installed? (check with debsums) Before reinstalling, delete the manually created link. Not used up to now - but i will find out. I tried to correct this by a symbolic link: linux-headers-3.12-1-common - linux-headers-3.12-1-common-rt the NVIDIA driver does not work under RT kernels, so get rid of the linux-headers-3.12-1-rt-amd64 linux-headers-3.12-1-common-rt packages i can't remember to have this packages installed. They are not installed under wheezy! Then i rerun the installer and get make2.log I have no idea what's going wrong this time? Nothings works. :-( you probably don't need the uvm module ... ??? But this is not going to fix your problem. There is something X-related broken as you could see in the failing vesa test. Maybe some outdated library, forgotten file or symlink somewhere or a non-default configuration setting somewhere. Yes - but how to find out? I thought it would be easier to get a running NVida-driver first. Changing the tires does not get your car going if the battery is dead. Correct. I just wanted to see if this works. But i only found much problems with headers ... You should really try to do a clean minimal jessie install on a separate disk, ensure X is working properly, install the same package set as you have on the grown system, ensure X is still working, and compare the two installations. Hmmm - yes - but that will take really much time. I will try to do this, it will take time to find a day with some hours ... Unfortunately I don't see another way to find the tiny difference that breaks your system. You have convinced me. BTW, in your wheezy installation, which driver and kernel version were you using? Did you test with the nvidia driver from wheezy-backports? I posted somewhere at the beginning of the bug. It is 304.88-1+deb7u1 You mean i should install the backport driver on wheezy first? I can try whatever can be done that don't need a half of a day. 319.82 backport was uploaded a few hours ago. See the backports page for instructions how to use backports. This should be rather quick and is just to verify that there isn't something broken w.r.t 319.82 on your card. But then i must reinstall a copy of my running system first. I don't want to break my working system. I think it is more sensefull to try a clean installation of testing? Andreas Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736145: nvidia-detect gives no senseful output
Am 25.01.2014 16:57, schrieb Andreas Beckmann: On 2014-01-20 10:30, Karsten Malcher wrote: When i run nvidia-detect i get this output: Detected NVIDIA GPUs: 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) Your card is supported by the default drivers and version 304. It is recommended to install the nvidia-driver package. That's wrong! Correct should be 319.76 and this is installed: Why do you think this is wrong? What would you expect instead? Andreas Please read exact - current driver is 319.76 or not? nvidia-detect cries for 304. So how to install something that does not exist? ;-) Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: nvidia-driver: New vesa test
Hello, Am 23.01.2014 13:14, schrieb Diederik de Haas: On Thursday 23 January 2014 12:37:29 Karsten Malcher wrote: 2. Boot jessie, deinstall all Debian NVidia packages Instead of just deinstalling, I'd suggest purging the package(s), which also removes configuration files. Optionally you can also do the following to make sure all config files are indeed removed: - check /etc/X11/xorg.conf.d/ to see if there are any config files there (which could interfere) - run 'updatedb.mlocate' (as root) - run 'find -name *nvidia* -type f' (as root) to see whether there are still nvidia files on your system you'd like to get rid of Then reboot and install the nvidia driver HTH, Diederik I have purged all the packages. But installation of the NVidia driver fails, because compilation does not work. I atteched the logs. The directory /usr/src/linux-headers-3.12-1-amd64 exists! But only with 1,9 MB content? I already run an package update. I think there are some things really misconfigured and bad in jessie. Cheers Karsten nvidia-installer log file '/var/log/nvidia-installer.log' creation time: Thu Jan 23 13:50:56 2014 installer version: 331.38 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin nvidia-installer command line: ./nvidia-installer Using: nvidia-installer ncurses user interface - License accepted. - Installing NVIDIA driver version 331.38. - There appears to already be a driver installed on your system (version: 331.38). As part of installing this driver (version: 331.38), the existing driver will be uninstalled. Are you sure you want to continue? ('no' will abort installation) (Answer: Yes) - Would you like to register the kernel module sources with DKMS? This will allow DKMS to automatically build a new module, if you install a different kernel later. (Answer: Yes) - Installing both new and classic TLS OpenGL libraries. - Installing both new and classic TLS 32bit OpenGL libraries. - Install NVIDIA's 32-bit compatibility libraries? (Answer: Yes) - Parsing log file: - done. - Validating previous installation: - done. - Uninstalling NVIDIA Accelerated Graphics Driver for Linux-x86_64 (1.0-33138 (331.38)): - DKMS module detected; removing... - Unable to delete directories created by previous installation. - done. - Uninstallation of existing driver: NVIDIA Accelerated Graphics Driver for Linux-x86_64 (331.38) is complete. - Skipping installation of the libvdpau wrapper library. - Searching for conflicting X files: - done. - Searching for conflicting OpenGL files: - done. - Installing 'NVIDIA Accelerated Graphics Driver for Linux-x86_64' (331.38): executing: '/sbin/ldconfig'... executing: '/sbin/depmod -aq'... - done. - Driver file installation is complete. - Installing DKMS kernel module: ERROR: Failed to run `/usr/sbin/dkms build -m nvidia -v 331.38 -k 3.12-1-amd64`: Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area make KERNELRELEASE=3.12-1-amd64 module KERNEL_UNAME=3.12-1-amd64; make -C uvm module KERNEL_UNAME=3.12-1-amd64 KBUILD_EXTMOD=/var/lib/dkms/nvidia/331.38/build/uvm(bad exit status: 2) Error! Bad return status for module build on kernel: 3.12-1-amd64 (x86_64) Consult /var/lib/dkms/nvidia/331.38/build/make.log for more information. - error. ERROR: Failed to install the kernel module through DKMS. No kernel module was installed; please try installing again without DKMS, or check the DKMS logs for more information. ERROR: Installation has failed. Please see the file '/var/log/nvidia-installer.log' for details. You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com. DKMS make.log for nvidia-331.38 for kernel 3.12-1-amd64 (x86_64) Do 23. Jan 13:51:09 CET 2014 NVIDIA: calling KBUILD... make[1]: Entering directory `/usr/src/linux-headers-3.12-1-amd64' make: Entering an unknown directory make: *** /usr/src/linux-headers-3.12-1-common: Datei oder Verzeichnis nicht gefunden. Schluss. make: Leaving an unknown directory make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/usr/src/linux-headers-3.12-1-amd64' NVIDIA: left KBUILD. nvidia.ko failed to build! make: *** [nvidia.ko] Fehler 1 make: Entering directory `/var/lib/dkms/nvidia/331.38/build/uvm' cd /var/lib/dkms/nvidia/331.38/build; make module SYSSRC=/lib/modules/3.12-1-amd64/build SYSOUT=/lib/modules/3.12-1-amd64/build KBUILD_EXTMOD=/var/lib/dkms/nvidia/331.38/build make[1]: Entering directory `/var/lib/dkms/nvidia/331.38/build' NVIDIA: calling KBUILD... make[2]: Entering directory `/usr/src/linux-headers-3.12-1-amd64' make: Entering an unknown directory make: *** /usr/src/linux-headers-3.12-1-common: Datei oder Verzeichnis nicht gefunden. Schluss. make: Leaving an unknown directory make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/usr/src/linux-headers-3.12-1-amd64' NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [nvidia.ko] Fehler 1 make[1
Bug#735424: nvidia-driver: New vesa test
Hello Andreas, Am 22.01.2014 21:41, schrieb Andreas Beckmann: [Please keep the Bug Cc:ed - therefore fullquote] On 2014-01-22 10:47, Karsten Malcher wrote: Hello Diederik, that's really interesting. So it must be a configuration problem of previous installations? Do you have made a fresh installation or an upgrade? I have made now an additional test: On a third partition i have a copy of my wheezy installation. In this installation i have an self compiled kernel V 3.12.6 for some driver tests with a newer kernel. Up to now i booted there using the neauveau driver with this configuration: Section Device Identifier n Driver nv EndSection shouldn't that be Driver nouveau ? (nv is an even older driver last seen in squeeze) but that wouldn't even need an xorg.conf Yes - this was only a quick and dirty solution to get a running X with a new kernel. Now i deinstalled all Debian NVidia packages in this installation and installed the actual NVIdia driver NVIDIA-Linux-x86_64-331.38.run I did have some problems with compilation of the driver, although i installed the kernel with a debian building script. ii linux-image-3.12.6 3.12.6 amd64 Linux kernel binary image for version 3.12.6 ii linux-image-3.2.0-3-amd64 3.2.23-1 amd64Linux 3.2 for 64-bit PCs But the driver could be installed an is running fine! So something with the configuration or the debian package of 319.82 is not correct. The newer driver 331.38 is running on the same installation as the upgraded one in this bug. This has only proved that 331.38 is running in a wheezy environment. Yes and No - it has also proved that my configuration is able to run X with kernel 3.12.6 Vesa should work there as well. As I understood your problem so far it is all xserver video drivers result in a black screen in jessie. Yes - that's correct. I will made the following test now: 1. Backup the current upgraded jessie partition (with the chance to recover). 2. Boot jessie, deinstall all Debian NVidia packages 3. Install NVidia driver 331.38 Then we will see if this will work. Do you have a spare hard disk to make a minimal fresh jessie installation (installing on a usb stick should work as well) and see if you can get X running with vesa/nouveau (and nvidia afterwards)? Thereafter compare /etc contents, maybe install the exactly same packageset in the new install and look for differences. I have no doubt that this will work. The problem is a failing upgrade from wheezy to jessie. Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: nvidia-driver: New vesa test
Hi Diederik, Am 22.01.2014 11:15, schrieb Diederik de Haas: Hi Karsten, On Wednesday 22 January 2014 10:47:48 Karsten Malcher wrote: Now i deinstalled all Debian NVidia packages in this installation and installed the actual NVIdia driver NVIDIA-Linux-x86_64-331.38.run I understand your eagerness to fix this asap, but I'm not going to interfere with Andreas bug-triage efforts. Of course i understand this. But from my point of view i never could made an upgrade in Debian without problems. I always where using Nvidia cards. Before wheezy i never got an running X without original NVidia drivers. In wheezy the first time the Nvidia Debian package was running for me. It seems it was the last time. :-( Any update of the kernel will cause the loose of X. But I can say this: - When trying to find a problem, only change 1 variable at a time, otherwise you don't know which change caused a change in behaviour. i only made an simple system upgrade from wheezy to jessie. - Don't use NVidia's .run file if you're reporting an issue on a Debian package, since they're not meant to be co-installed (and Debian's package cleans thing up from a possible previous .run installation). That's why i made this test in a different installation. It was a simple test if kernel 3.12.6 and the NVidia driver will work together. - Use the same system/installation on all bug-triage efforts, otherwise you're comparing completely different systems (btw 3.12 kernel on wheezy and not from backports?) Somehow it must be possible to have a working PC. ;-) In this case i hold back the upgraded installation for this bug. There is no additional mix up. I've been running Debian's NVidia packages for years, without any issue, including on my freshly installed system I'm running now. That's the main problem. On a fresh installation you don't have this problems. In most of the cases this will work. But what's about of the hundreds of personal configurations for mail, programming, viewing and working? You will loose them with a new installation and need to much time to get them back. In my case i have a master installation with the individual settings for 3 users! This installation will be cloned to all working PC's. When i want to upgrade to a newer distribution it must be an upgrade or it will kill me. I think this problems are not my personal problems and touch many users. So upgrade problems should also be in a distribution focus. Cheers Karsten HTH, Diederik Original-Nachricht Betreff:Re: Bug#735424: nvidia-driver: New vesa test Datum: Wed, 22 Jan 2014 10:47:48 +0100 Von:Karsten Malcher deb...@dct.mine.nu Antwort an: deb...@dct.mine.nu An: Diederik de Haas didi.deb...@cknow.org Kopie (CC): pkg-nvidia-de...@lists.alioth.debian.org Hello Diederik, that's really interesting. So it must be a configuration problem of previous installations? Do you have made a fresh installation or an upgrade? I have made now an additional test: On a third partition i have a copy of my wheezy installation. In this installation i have an self compiled kernel V 3.12.6 for some driver tests with a newer kernel. Up to now i booted there using the neauveau driver with this configuration: Section Device Identifier n Driver nv EndSection Now i deinstalled all Debian NVidia packages in this installation and installed the actual NVIdia driver NVIDIA-Linux-x86_64-331.38.run I did have some problems with compilation of the driver, although i installed the kernel with a debian building script. ii linux-image-3.12.6 3.12.6 amd64Linux kernel binary image for version 3.12.6 ii linux-image-3.2.0-3-amd64 3.2.23-1 amd64 Linux 3.2 for 64-bit PCs But the driver could be installed an is running fine! So something with the configuration or the debian package of 319.82 is not correct. The newer driver 331.38 is running on the same installation as the upgraded one in this bug. Cheers Karsten Andreas, I have the same graphics card (GT 430), the same driver version and (almost) the same kernel (Linux bagend 3.12-1-amd64 #1 SMP Debian 3.12.8-1 (2014-01-19) x86_64 GNU/Linux) and everything is running fine here. So if you want me to check/test things so 'notes' can be compared, just let me know (I'm subsribed to the pkg-nvidia-devel ML). Cheers, Diederik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: nvidia-driver: New vesa test
Am 22.01.2014 13:16, schrieb Andreas Beckmann: This time the log shows a clean vesa install. And if vesa is not working (even if it would be horribly slow), there seems to be something else going on. It's not the nvidia driver being faulty - the same happens there, but you don't see the flickering because its too fast. I see the same in the Xorg.log from both drivers - X is started successfully. But right now I'm out of clues how to debug this further - the X maintainers might help here to get vesa running. And if that is working, switching back to nvidia should be no problem. Andreas Thank you for analyzing and trying to solve the problem! It seems to be a really sucking problem with the configuration of this installation. Is there a chance for a simply and clean reinstall of all the stuff around X and Nvida? Maybe this could save the personal settings and get the same situation as a new installation? Otherwise i think this will cost to much time for further analyzing of this problem. Then there only two options: 1. Wait and try another upgrade from wheezy to jessie in hope that it will work later. 2. Uninstall the nvidia debian packages and try to use the original NVidia installer. (I have no idea what the NVidia installer is making different that it works?) Best regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736145: nvidia-detect gives no senseful output
Package: nvidia-detect Version: 319.76-1 Severity: important Hello, the upgrade from wheezy to jessie failed. Please refer to bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735424 When i run nvidia-detect i get this output: Detected NVIDIA GPUs: 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) Your card is supported by the default drivers and version 304. It is recommended to install the nvidia-driver package. That's wrong! Correct should be 319.76 and this is installed: ii glx-alternative-nvidia0.4.1 amd64allows the selection of NVIDIA as GLX provider rc libgl1-nvidia-alternatives-ia32 304.88-1+deb7u1amd64simplifies replacing MESA libGL with GPU vendor libraries (32-bit) ii libgl1-nvidia-glx:amd64 319.76-1 amd64 NVIDIA binary OpenGL libraries ii libgl1-nvidia-glx:i386319.76-1 i386 NVIDIA binary OpenGL libraries ii libgl1-nvidia-glx-i386319.76-1 i386 NVIDIA binary OpenGL 32-bit libraries ii libnvidia-compiler:amd64 319.76-1 amd64 NVIDIA runtime compiler library ii libnvidia-ml1:amd64 319.76-1 amd64NVIDIA Management Library (NVML) runtime library rc libxvmcnvidia1:amd64 304.88-1+deb7u1amd64 NVIDIA binary XvMC library ii nvidia-alternative319.76-1 amd64allows the selection of NVIDIA as GLX provider ii nvidia-detect 319.76-1 amd64 NVIDIA GPU detection utility ii nvidia-driver 319.76-1 amd64 NVIDIA metapackage ii nvidia-glx319.76-1 amd64 transition to nvidia-driver ii nvidia-installer-cleanup 20131102+1 amd64cleanup after driver installation with the nvidia-installer ii nvidia-kernel-common 20131102+1 amd64NVIDIA binary kernel module support files ii nvidia-kernel-dkms319.76-1 amd64NVIDIA binary kernel module DKMS source ii nvidia-opencl-common 319.76-1 amd64 NVIDIA OpenCL driver ii nvidia-opencl-icd:amd64 319.76-1 amd64 NVIDIA OpenCL ICD ii nvidia-settings 319.72-1 amd64tool for configuring the NVIDIA graphics driver ii nvidia-support20131102+1 amd64NVIDIA binary graphics driver support files ii nvidia-vdpau-driver:amd64 319.76-1 amd64 NVIDIA vdpau driver ii nvidia-xconfig319.72-1 amd64X configuration tool for non-free NVIDIA drivers ii xserver-xorg-video-nvidia 319.76-1 amd64 NVIDIA binary Xorg driver Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: nvidia-driver: needed option x for additional information
Am 19.01.2014 19:00, schrieb Andreas Beckmann: On 2014-01-15 17:54, Karsten wrote: Here are the automatic collected informations. So far I don't see any errors ... X starts ... and after 30 seconds cleanly shuts down. Please check the logfile of login manager (gdm3, kdm, xdm or whatever) That's what i can't understand too. After boot X does not start and i land on the basic text shell. So i can log in as user and startx. Without xorg.conf i only get the error no screens found. With an xorg.conf i only get an blank black screen. It seems that the graphic card is not initialized correctly or something else. Shutdown is with CTRL-C by the user. Please try the new driver releases 319.82 in unstable and 331.38 in experimental. How can i install this driver in jessie? And try a minimal config file as decribed in /usr/share/doc/nvidia-driver/README.Debian.gz I tried to use nvidia-xconfig with the same result of this black blank screen. The xorg.conf is attached. Karsten # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 319.72 (pbuilder@cake) Sat Nov 9 14:15:48 UTC 2013 Section ServerLayout Identifier Layout0 Screen 0 Screen0 0 0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section Files EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/psaux Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section InputDevice # generated from default Identifier Keyboard0 Driver kbd EndSection Section Monitor Identifier Monitor0 VendorName Unknown ModelName Unknown HorizSync 28.0 - 33.0 VertRefresh 43.0 - 72.0 Option DPMS EndSection Section Device Identifier Device0 Driver nvidia VendorName NVIDIA Corporation EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 SubSection Display Depth 24 EndSubSection EndSection
Bug#735424: nvidia-driver: Test with minimal NVIDIA xorg.conf
Package: nvidia-driver Version: 319.76-1 Followup-For: Bug #735424 Thank you for your help and your suggestions! The first test is to boot with the suggested minimal xorg.conf for NVidia. Result is a text console after boot! I logged in as user and startx - result is the blank screen. I opened a second text console and send this message with reportbug -N, Following up with the next test (vesa). Karsten -- Package-specific info: uname -a: Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux /proc/version: Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 GCC version: gcc version 4.8.2 (Debian 4.8.2-12) lspci 'VGA compatible controller [0300]': 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 18 Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d800 (64-bit, prefetchable) [size=128M] Region 3: Memory at d600 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at c800 [size=128] [virtual] Expansion ROM at fea8 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.382826] vgaarb: device added: PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none [0.382828] vgaarb: loaded [0.382829] vgaarb: bridge control possible :02:00.0 [1.067815] PCI-DMA: Disabling AGP. [1.067899] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture [1.147011] Linux agpgart interface v0.103 [5.275911] hda-intel :02:00.1: Handle VGA-switcheroo audio client [5.516103] nvidia: module license 'NVIDIA' taints kernel. [6.139085] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16 [6.139285] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15 [6.139439] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14 [6.139582] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13 [6.141016] vgaarb: device changed decodes: PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none [6.142218] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 14 11:03 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Jan 14 11:03 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 14 11:03 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf - /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 14 11:03 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Jan 14 11:03 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 Jan 14 11:03 /etc/alternatives/nvidia - /usr/lib/nvidia/current lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu
Bug#735424: nvidia-driver: Test with vesa xorg.conf
Package: nvidia-driver Version: 319.76-1 Followup-For: Bug #735424 This time i booted with the suggested xorg.conf with vesa. Result is the same. I land on the text console After login and startx i got no screens found Trying now to install driver from unstable ... Karsten -- Package-specific info: uname -a: Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux /proc/version: Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 GCC version: gcc version 4.8.2 (Debian 4.8.2-12) lspci 'VGA compatible controller [0300]': 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d800 (64-bit, prefetchable) [size=128M] Region 3: Memory at d600 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at c800 [size=128] Expansion ROM at fea8 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.386397] vgaarb: device added: PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none [0.386399] vgaarb: loaded [0.386400] vgaarb: bridge control possible :02:00.0 [1.070997] PCI-DMA: Disabling AGP. [1.071086] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture [1.150122] Linux agpgart interface v0.103 [7.159490] nvidia: module license 'NVIDIA' taints kernel. [7.175092] vgaarb: device changed decodes: PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none [7.175347] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 [7.267428] hda-intel :02:00.1: Handle VGA-switcheroo audio client [8.074148] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16 [8.074343] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15 [8.074488] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14 [8.074630] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13 OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 14 11:03 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Jan 14 11:03 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 14 11:03 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf - /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 14 11:03 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Jan 14 11:03 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 Jan 14 11:03 /etc/alternatives/nvidia - /usr/lib/nvidia/current lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives
Bug#735424: nvidia-driver: Test of unstable driver
Package: nvidia-driver Version: 319.82-1 Followup-For: Bug #735424 Now i installed the driver of the unstable package. I put the minimum xorg.conf for NVidia into /etc/X11 and tried startx as user. It says no screens found Now i rerun the xorg configuration tool and try to reboot ... Karsten -- Package-specific info: uname -a: Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux /proc/version: Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 GCC version: gcc version 4.8.2 (Debian 4.8.2-12) lspci 'VGA compatible controller [0300]': 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d800 (64-bit, prefetchable) [size=128M] Region 3: Memory at d600 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at c800 [size=128] Expansion ROM at fea8 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.386397] vgaarb: device added: PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none [0.386399] vgaarb: loaded [0.386400] vgaarb: bridge control possible :02:00.0 [1.070997] PCI-DMA: Disabling AGP. [1.071086] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture [1.150122] Linux agpgart interface v0.103 [7.159490] nvidia: module license 'NVIDIA' taints kernel. [7.175092] vgaarb: device changed decodes: PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none [7.175347] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 [7.267428] hda-intel :02:00.1: Handle VGA-switcheroo audio client [8.074148] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16 [8.074343] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15 [8.074488] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14 [8.074630] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13 [ 455.350352] NVRM: API mismatch: the client has the version 319.82, but [ 455.350352] NVRM: this kernel module has the version 319.76. Please [ 455.350352] NVRM: make sure that this kernel module and all NVIDIA driver [ 455.350352] NVRM: components have the same version. OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 20 13:50 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Jan 20 13:50 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Jan 20 13:50 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 20 13:50 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 20 13:50 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 20 13:50 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 51 Jan 20 13:50 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Jan 20 13:50 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 20 13:50 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf - /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 20 13:50 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Jan 20 13:50 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 Jan 20 13:50 /etc/alternatives/nvidia - /usr/lib/nvidia/current lrwxrwxrwx 1 root root 49 Jan 20 13:50 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 20 13:50 /etc/alternatives/nvidia
Bug#735424: nvidia-driver: Test of unstable driver
Hello, i am sorry, at least nothing has worked. With the driver from unstable i get no running X. All the configurations of xorg.conf i testes result in no screens found. I attach the last configuration. The first one was the minimal configuration.file:///sda/etc/X11/xorg.conf What is to do now? Regards Karsten # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 319.72 (pbuilder@cake) Sat Nov 9 14:15:48 UTC 2013 Section ServerLayout Identifier Layout0 Screen 0 Screen0 0 0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section Files EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/psaux Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section InputDevice # generated from default Identifier Keyboard0 Driver kbd EndSection Section Monitor Identifier Monitor0 VendorName Unknown ModelName Unknown HorizSync 28.0 - 33.0 VertRefresh 43.0 - 72.0 Option DPMS EndSection Section Device Identifier Device0 Driver nvidia VendorName NVIDIA Corporation EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 SubSection Display Depth 24 EndSubSection EndSection
Bug#686754: Is there any hope that this bug will be fixed?
Am 14.01.2014 19:00, schrieb Colin Watson: GRUB doesn't generate those kernel parameters itself; it relies on os-prober to fetch them from the boot loader configuration files on those other systems. It's quite possible that the problem is simply that the boot loader configuration inside the filesystem on /dev/sda3 (or its associated /boot filesystem) is wrong. Could you find the relevant configuration file and attach it? Hello Colin, now i understand more. I found this description of os-prober here: http://joeyh.name/code/os-prober/ Calling os-prober only give this information: # os-prober /dev/sda2:Debian GNU/Linux (7.2):Debian:linux /dev/sda3:Debian GNU/Linux (jessie/sid):Debian1:linux It seems not to merge the information with the UUID of the partitions. I found an other interesting effect, which explains that this bug has not been found. Now an grub-update produces the correct grub.cfg. menuentry Debian GNU/Linux, mit Linux 3.12-1-amd64 (on /dev/sda3) --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(/dev/sda,msdos3)' search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5 linux /boot/vmlinuz-3.12-1-amd64 root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro quiet initrd /boot/initrd.img-3.12-1-amd64 } menuentry Debian GNU/Linux, mit Linux 3.12-1-amd64 (Wiederherstellungsmodus) (on /dev/sda3) --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(/dev/sda,msdos3)' search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5 linux /boot/vmlinuz-3.12-1-amd64 root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro single initrd /boot/initrd.img-3.12-1-amd64 } What i did in the history: 1. I unpacked an backup of /dev/sdb1 (Grub partition with Debian wheezy) to /dev/sda3 2. I altered the fstab of the copy and run update-grub (After this i got this wrong grub.cfg) 3. I boot from /dev/sda3 and made an system-upgrade from wheezy to jessie 4. After the upgrade i run update-grub again from /dev/sdb1 to actualize the new kernel on /dev/sda3 (Now grub.cfg is correct) Is it possible that the (wrong) information is extraced from initrd.img ? Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: Different drivers for different graphic cards?
When i search for my graphic card GT 430 at Nvidia, this driver is suggested for download: Version: 331.38 Date:2014.1.13 Again this is a different version! In Debian there is only one driver package. How it is able to suffer all the different graphic cards? This driver is for many different graphic cards, including my card: *GeForce 700 Series:* GeForce GTX TITAN, GeForce GTX 780, GeForce GTX 770, GeForce GTX 760, GeForce GTX 760 Ti (OEM) *GeForce 700M Series (Notebooks):* GeForce GTX 780M, GeForce GTX 770M, GeForce GTX 765M, GeForce GTX 760M, GeForce GT 755M, GeForce GT 750M, GeForce GT 745M, GeForce GT 740M, GeForce GT 735M, GeForce GT 730M, GeForce GT 720M, GeForce 710M *GeForce 600 Series:* GeForce GTX 690, GeForce GTX 680, GeForce GTX 670, GeForce GTX 660 Ti, GeForce GTX 660, GeForce GTX 650 Ti BOOST, GeForce GTX 650 Ti, GeForce GTX 650, GeForce GT 645, GeForce GT 640, GeForce GT 630, GeForce GT 620, GeForce GT 610, GeForce 605 *GeForce 600M Series (Notebooks):* GeForce GTX 680MX, GeForce GTX 680M, GeForce GTX 675MX, GeForce GTX 675M, GeForce GTX 670MX, GeForce GTX 670M, GeForce GTX 660M, GeForce GT 650M, GeForce GT 645M, GeForce GT 640M, GeForce GT 640M LE, GeForce GT 635M, GeForce GT 630M, GeForce GT 625M, GeForce GT 620M, GeForce 610M *GeForce 500 Series:* GeForce GTX 590, GeForce GTX 580, GeForce GTX 570, GeForce GTX 560 Ti, GeForce GTX 560 SE, GeForce GTX 560, GeForce GTX 555, GeForce GTX 550 Ti, GeForce GT 545, GeForce GT 530, GeForce GT 520, GeForce 510 *GeForce 500M Series (Notebooks):* GeForce GTX 580M, GeForce GTX 570M, GeForce GTX 560M, GeForce GT 555M, GeForce GT 550M, GeForce GT 540M, GeForce GT 525M, GeForce GT 520M, GeForce GT 520MX *GeForce 400 Series:* GeForce GTX 480, GeForce GTX 470, GeForce GTX 465, GeForce GTX 460 SE v2, GeForce GTX 460 SE, GeForce GTX 460, GeForce GTS 450, GeForce GT 440, GeForce GT 430, GeForce GT 420 *GeForce 400M Series (Notebooks):* GeForce GTX 485M, GeForce GTX 480M, GeForce GTX 470M, GeForce GTX 460M, GeForce GT 445M *GeForce 300 Series:* GeForce GT 340, GeForce GT 330, GeForce GT 320, GeForce 315, GeForce 310 *GeForce 300M Series (Notebooks):* GeForce GTS 360M, GeForce GTS 350M, GeForce GT 335M, GeForce GT 330M, GeForce GT 325M, GeForce GT 320M, GeForce 320M, GeForce 315M, GeForce 310M, GeForce 305M *GeForce 200 Series:* GeForce GTX 295, GeForce GTX 285, GeForce GTX 280, GeForce GTX 275, GeForce GTX 260, GeForce GTS 250, GeForce GTS 240, GeForce GT 230, GeForce GT 240 *GeForce 200M Series (Notebooks):* GeForce GTX 285M, GeForce GTX 280M, GeForce GTX 260M, GeForce GTS 260M *GeForce 100 Series:* GeForce GT 140, GeForce GT 130, GeForce GT 120, GeForce G100 *GeForce 100M Series (Notebooks):* GeForce GTS 160M, GeForce GT 130M, GeForce GT 120M, GeForce G 110M, GeForce G 105M, GeForce G 103M, GeForce G 102M *GeForce 9 Series:* GeForce 9800 GX2, GeForce 9800 GTX/GTX+, GeForce 9800 GT, GeForce 9600 GT, GeForce 9600 GSO, GeForce 9600 GSO 512, GeForce 9600 GS, GeForce 9500 GT, GeForce 9500 GS, GeForce 9400 GT, GeForce 9400, GeForce 9300 GS, GeForce 9300 GE, GeForce 9300 SE, GeForce 9300, GeForce 9200, GeForce 9100 *GeForce 9M Series (Notebooks):* GeForce 9800M GTX, GeForce 9800M GTS, GeForce 9800M GT, GeForce 9800M GS, GeForce 9700M GTS, GeForce 9700M GT, GeForce 9650M GT, GeForce 9650M GS, GeForce 9600M GT, GeForce 9600M GS, GeForce 9500M GS, GeForce 9500M G, GeForce 9400M G, GeForce 9400M, GeForce 9300M GS, GeForce 9300M G, GeForce 9200M GS, GeForce 9100M G *GeForce 8 Series:* GeForce 8800 Ultra, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 GT, GeForce 8800 GS, GeForce 8600 GTS, GeForce 8600 GT, GeForce 8600 GS, GeForce 8500 GT, GeForce 8400 GS *GeForce 8M Series (Notebooks):* GeForce 8800M GTX, GeForce 8800M GTS, GeForce 8700M GT, GeForce 8600M GT, GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS, GeForce 8400M G, GeForce 8200M G, GeForce 8200M *Quadro Series:* Quadro K6000, Quadro K5000, Quadro K4000, Quadro K2000, Quadro K2000D, Quadro K600, Quadro 6000, Quadro 5000, Quadro 4000, Quadro 2000, Quadro 2000D, Quadro 600, Quadro 410, Quadro 400 *Quadro Series (Notebooks):* Quadro K5000M, Quadro K4000M, Quadro K3000M, Quadro K2000M, Quadro K1000M, Quadro K500M, Quadro 5010M, Quadro 5000M, Quadro 4000M, Quadro 3000M, Quadro 2000M, Quadro 1000M *Quadro FX Series:* Quadro FX 3400/4400, Quadro FX 3500, Quadro FX 3700, Quadro FX 3800, Quadro FX 4000, Quadro FX 4500, Quadro FX 4500 X2, Quadro FX 4600, Quadro FX 4700 X2, Quadro FX 4800, Quadro FX 5500, Quadro FX 5600, Quadro FX 5800 *Quadro FX Series (Notebooks):* Quadro FX 3800M, Quadro FX 3700M, Quadro FX 3600M, Quadro FX 2800M, Quadro FX 2700M, Quadro FX 1800M, Quadro FX 1700M, Quadro FX 1600M, Quadro FX 880M, Quadro FX 770M, Quadro FX 570M, Quadro FX 380M, Quadro FX 370M, Quadro FX 360M *Quadro Blade/Embedded Series :* Quadro FX 560M, Quadro FX 770M, Quadro FX 880M, Quadro FX 1600M, Quadro FX 2800M, Quadro FX 3600M
Bug#686754: Is there any hope that this bug will be fixed?
Am 15.01.2014 11:48, schrieb Lukas Schwaighofer: Hi Karsten, To my knowledge linux-boot-prober does the following: * Mount the given partition read-only to a temporary directory * Read the /etc/fstab of this partition to check if /boot is on a separate partition. If so, it is also mounted. * Read and parse the boot loader configuration from the temporary directory. For grub2 that is boot/grub/grub.cfg. The parameters to the linux kernel (the root=… directive that was wrong in your case) should be directly taken from this file. * Unmount everything again So your report from your message #15 makes sense, if the /boot/grub/grub.cfg file on sda3 (I'm assuming you do not have a separate boot partition) previously contained the wrong parameters for the Linux kernel (root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single). Regards Lukas Hi Lukas, then we have found the explanation for this problem - thank you! The grub.cfg on the copy of the installation will be correct only after boot and update of this installation. And i must run update-grub first on the standard installation to get the partition with the copy booted. It's impossible to avoid this error under this circumstances! So this bug can be closed. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: Only blank screen after system-upgrade from wheezy to jessie
Hello Andreas, Am 15.01.2014 12:27, schrieb Andreas Beckmann: On 2014-01-15 11:01, Karsten Malcher wrote: Package: nvidia-driver Version: 319.76-1 Severity: important Hello, again i tried to upgrade from a perfect running installation of Debian wheezy to jessie. That should be supported :-) That was my hope also - but i was really disappointed to land on the shell. This installation has been upgraded more than one time and in the history there might be the usage of original nvidia packages. I have put a lot of effort into cleaning up the mess created by having used the nvidia *.run installer in the past, but I may have missed some corner cases. I believe that and thank you for your work! There are really to many types of NVidia-cards out there. Is there a way to easy find out which package must be installed for an NVidia card? Here i can't find my card: http://packages.debian.org/jessie/nvidia-legacy-173xx-driver Here i can't find any hint what to do on jessie: https://wiki.debian.org/NvidiaGraphicsDrivers I would update this Wiki-page with the correct informations. Right now I don't see an obvious problem. Please run reportbug -N 735424 I will do this. But after this i would try to install the correct NVida-package for a GT 400 if possible. Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735424: nvidia-driver: needed option x for additional information
Package: nvidia-driver Version: 319.76-1 Followup-For: Bug #735424 Here are the automatic collected informations. -- Package-specific info: uname -a: Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux /proc/version: Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 GCC version: gcc version 4.8.2 (Debian 4.8.2-12) lspci 'VGA compatible controller [0300]': 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d800 (64-bit, prefetchable) [size=128M] Region 3: Memory at d600 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at c800 [size=128] Expansion ROM at fea8 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.382826] vgaarb: device added: PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none [0.382828] vgaarb: loaded [0.382828] vgaarb: bridge control possible :02:00.0 [1.067456] PCI-DMA: Disabling AGP. [1.067547] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture [1.146534] Linux agpgart interface v0.103 [5.848494] hda-intel :02:00.1: Handle VGA-switcheroo audio client [5.899764] nvidia: module license 'NVIDIA' taints kernel. [6.730927] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16 [6.731135] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15 [6.731285] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14 [6.731430] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13 [6.732873] vgaarb: device changed decodes: PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none [6.734026] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.76 Fri Nov 22 13:33:19 PST 2013 OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 14 11:03 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 14 11:03 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Jan 14 11:03 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 14 11:03 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf - /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 14 11:03 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Jan 14 11:03 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 Jan 14 11:03 /etc/alternatives/nvidia - /usr/lib/nvidia/current lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 49 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 51 Jan 14 11:03 /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 33 Jan 14 11:03
Bug#686754: Is there any hope that this bug will be fixed?
Again and again i have to correct the grub.cfg manually. And you can see this bug in all depending distributions of Debian. Example today: # blkid /dev/sda1: LABEL=P1EXT4-8G UUID=c4aa8129-f5a0-4599-b487-3f63ff736c1b TYPE=ext4 /dev/sda2: UUID=5166cbb1-8234-4127-bb0b-bbfda1658b68 TYPE=ext4 LABEL=P2EXT4-30G /dev/sda5: UUID=448a6eb5-2173-43e3-b35a-62e9e81a2316 TYPE=swap /dev/sda6: LABEL=P3EXT20G UUID=d37744be-c228-4add-9cf3-ce42aff94a7f SEC_TYPE=ext2 TYPE=ext3 /dev/sda7: LABEL=P7-EXT4-900G UUID=f4d36b10-bae9-4b22-a19b-0f34916337b3 TYPE=ext4 /dev/sda3: LABEL=P3EXT4-30G UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 TYPE=ext4 /dev/sdb1: LABEL=SSD UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 TYPE=ext4 grub.cfg menuentry Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (on /dev/sda3) --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(/dev/sda,msdos3)' search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5 linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet initrd /boot/initrd.img-3.2.0-3-amd64 } menuentry Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (Wiederherstellungsmodus) (on /dev/sda3) --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(/dev/sda,msdos3)' search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5 linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single initrd /boot/initrd.img-3.2.0-3-amd64 But the first 2 partitions are right now. ;-) It would be fine if i can boot from all partitions ... Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Hello together, i will close this bug at Debian now. After the last update this error seems to disappear in Debian stable. http://ftp.debian.org/debian/dists/wheezy/ChangeLog USB: pl2303: fix device initialisation at open The source for this patch can be found here: http://www.spinics.net/lists/stable/msg30311.html It's possible that this will not fix the bug under all circumstances depending on the application. Summary: == I did need some time to realize that this bug will occur only with PL2303HX chips that are China clones. In fact this type of chips run out of production at Profilic. http://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41showlevel=0017-0037-0041 Only the PL2303HXD can be buyed as original, so any new PL2303HX is a China clone. I have been contacted by Frank Schäfer and so we tested some of his driver improvements in combination with newer kernels. Up to now this could not be backported to kernel 3.2.x, but i could test a kernel 3.12.6 on Debian wheezy and the PL2303HX is running fine. There are really much products with this clone chips out there, so some further improvements of the driver would be really helpful. I will make further tests together with Frank and hope that this improvements will find a place into the next kernel versions starting with Debian jessie and 3.12.6 Best regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735092: flash-kernel: add Raspberry Pi support
Package: flash-kernel Version: 3.11 Severity: wishlist Tags: patch The attached patch adds Raspberry Pi support to flash-kernel. It is based on current flash-kernel git (as of 7f52719ab0a607b89555baffd1cc8c14207c0f8f). It is available for merging in the rpi-support-rebased branch at http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. From ff2103a10fc27f77c2763d9dd4b043254b6e489d Mon Sep 17 00:00:00 2001 From: K. Merker mer...@debian.org Date: Wed, 1 Jan 2014 13:17:13 +0100 Subject: [PATCH] Initial Raspberry Pi support Add a method rpiconfigtxt and a new machine database entry for the Raspberry Pi. The method rpiconfigtxt enables flash-kernel to update the kernel file name to be booted by the Raspberry Pi firmware. As the Raspberry Pi firmware can only boot from a FAT partition, using symlinks to point to the kernel to be booted is not possible. Therefore the kernel filename entry in the firmware config has to be changed after installation of a new kernel package. --- README| 10 +- db/all.db |5 + functions | 19 +++ test_db |2 +- 4 files changed, 34 insertions(+), 2 deletions(-) diff --git a/README b/README index 51aa15f..c7cde61 100644 --- a/README +++ b/README @@ -49,6 +49,7 @@ The following systems are supported: - QNAP TS-409 - QNAP TS-410 and TS-410U Turbo NAS - QNAP TS-419P and TS-419U Turbo NAS + - Raspberry Pi - Seagate FreeAgent DockStar - SheevaPlug - SheevaPlug eSATA @@ -153,12 +154,19 @@ The supported fields are: * Method: (optional) indicates how to support this particular machine; the default is generic; other available methods are: android, multi, - redboot, slug, symlink + redboot, slug, symlink, rpiconfigtxt * Boot-Device: (optional) block device to mount before installing kernel, initrd and U-Boot script; Boot-Kernel-Path, Boot-Initrd-Path and Boot-Script-Path are then taken relative to this boot device +* Rpi-ConfigTxt-Path: (optional) Raspberry Pi firmware configuration pathname. + The Raspberry Pi firmware configuration is stored in a text file on the + first (FAT formatted) partition of the SD card in the system and + contains settings like kernel file name, video mode, memory split + between CPU and GPU, overclocking parameters, etc. Rpi-ConfigTxt-Path + contains the full path to this file (default value: /boot/config.txt). + Configuration - - - - - - - diff --git a/db/all.db b/db/all.db index c28432a..c0fdf27 100644 --- a/db/all.db +++ b/db/all.db @@ -382,3 +382,8 @@ Method: android Android-Boot-Device: /dev/mmcblk0 Required-Packages: abootimg Bootloader-Sets-Root: no + +Machine: BCM2708 +Method: rpiconfigtxt +Rpi-ConfigTxt-Path: /boot/config.txt +Bootloader-Sets-Root: yes diff --git a/functions b/functions index 1233981..26a16ed 100644 --- a/functions +++ b/functions @@ -440,6 +440,7 @@ boot_script_path=$(get_machine_field $machine Boot-Script-Path) || : boot_dtb_path=$(get_machine_field $machine Boot-DTB-Path) || : boot_multi_path=$(get_machine_field $machine Boot-Multi-Path) || : android_boot_device=$(get_machine_field $machine Android-Boot-Device) || : +rpi_configtxt_path=$(get_machine_field $machine Rpi-ConfigTxt-Path) || : if [ -n $dtb_append_from ]; then if dtb_append_required; then @@ -711,6 +712,24 @@ case $method in } $imtd || error failed. echo done. 2 ;; + rpiconfigtxt) + rpi_configtxt_path=${rpi_configtxt_path:-/boot/config.txt} + rpi_configtxt_tempfile=$(tempfile) + + if [ ! -e ${rpi_configtxt_path} ]; then + echo ${rpi_configtxt_path} not found. Creating it. + touch ${rpi_configtxt_path} + fi + + grep -E -v ^#fk-old- ${rpi_configtxt_path} | \ + sed -e 's/^kernel=/#fk-old-kernel=/' \ + -e 's/^initramfs/#fk-old-initramfs/' \ + -e 's/^ramfsfile/#fk-old-ramfsfile/' \ + -e 's/^ramfsaddr/#fk-old-ramfsaddr/' ${rpi_configtxt_tempfile} + + echo -n kernel=$(basename ${kfile})\ninitramfs $(basename ${ifile})\n ${rpi_configtxt_tempfile} + mv ${rpi_configtxt_tempfile} ${rpi_configtxt_path} + ;; esac } diff --git a/test_db b/test_db index aec83f1..217fe64 100755 --- a/test_db +++ b/test_db @@ -22,7 +22,7 @@ MACHINE_DB=$(cat ${FK_CHECKOUT:-$FK_DIR}/db/*.db) test_no_unknown_fields() { -local expected='Android-Boot-Device Boot-Device Boot-DTB-Path Boot-Initrd-Path Boot-Kernel-Path Boot-Multi-Path Boot-Script-Path Bootloader-Sets-Root DTB-Append DTB-Append-From DTB-Id Kernel-Flavors Machine Machine-Id Method Mtd-Initrd Mtd-Kernel Optional-Packages Required-Packages U-Boot-Initrd-Address U-Boot-Kernel-Address U-Boot-Kernel-Entry-Point U-Boot-Multi-Address U-Boot-Script-Address U-Boot-Script-Name' +local expected='Android-Boot-Device Boot-Device Boot-DTB
Bug#735093: flash-kernel: does not correctly handle removal of the highest-versioned installed kernel package
Package: flash-kernel Version: 3.11 Severity: normal Tags: patch Flash-Kernel 3.11 does not properly handle a removal of the highest-versioned kernel package. The same applies to current git as of 2014-01-12 which will probably be released as 3.12. When called from the kernel postinst in this case, it just aborts instead of flashing the remaining then-highest-versioned kernel, which in specific cases could lead to an unbootable system. Attached is a patch against current mainline flash-kernel git (as of 7f52719ab0a607b89555baffd1cc8c14207c0f8f). It is available for merging in the rpi-support-rebased branch at http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. From 989312441af9bdec76ba571eb3c6ae3d65f93d4e Mon Sep 17 00:00:00 2001 From: K. Merker mer...@debian.org Date: Thu, 2 Jan 2014 14:34:32 +0100 Subject: [PATCH] Add extended kernel package removal handling Until now, flash-kernel has not properly handled a removal of the highest-versioned kernel package. When called from the kernel postinst in this case, it just aborted instead of flashing the remaining then-highest-versioned kernel, which could lead to an unbootable system. This patch adds extended removal handling which takes care of the issue. --- debian/copyright|1 + flash-kernel.8 | 18 ++--- functions | 63 +++ kernel-hook/zz-flash-kernel |6 +++-- 4 files changed, 71 insertions(+), 17 deletions(-) diff --git a/debian/copyright b/debian/copyright index af21da0..e9fb23c 100644 --- a/debian/copyright +++ b/debian/copyright @@ -6,6 +6,7 @@ Copyright: Copyright (C) 2006 Joey Hess jo...@debian.org Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Martin Michlmayr t...@cyrius.com Copyright (C) 2011 Loïc Minier l...@dooz.org +Copyright (C) 2014 Karsten Merker mer...@debian.org This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License diff --git a/flash-kernel.8 b/flash-kernel.8 index 7b5bad5..8165372 100644 --- a/flash-kernel.8 +++ b/flash-kernel.8 @@ -3,7 +3,7 @@ .SH NAME flash-kernel \- put kernel and initramfs in boot location .SH SYNOPSIS -.B flash-kernel [--supported] [kvers] +.B flash-kernel [--machine machine-type] [--context calling-context] [--supported] [kvers] .SH DESCRIPTION flash-kernel is a script which will put the kernel and initramfs in the boot location of embedded devices that don't load the kernel and @@ -11,7 +11,7 @@ initramfs directly from /boot. flash-kernel supports devices that boot from flash memory (hence the name) as well as some devices that require a special boot image on the disk. .P -Optionally, it can be passed a version of the kernel to flash; only +Optionally, it can be passed a version of the kernel to process; only the highest version will be flashed and other versions will be ignored. Kernel and initrd are read from /boot. .P @@ -20,7 +20,17 @@ the subarchitectures of the machine and the image to be flashed match. Valid filenames for images to flash are suffixed with the subarchitecture. .P -If the \-\-supported option is used, flash\-kernel will test to see if +If the \-\-supported option is used, flash\-kernel will test whether the hardware is supported, and return a true or false value. +.P +The \-\-machine option allows to manually override the auto-detected +machine type string. +.P +The \-\-context option is used internally by the kernel +postinst/postrm scripts which call flash-kernel upon kernel package +installations and removals. It provides flash-kernel with the +information that it is running in the kernel packages +postinst/postrm context. Valid values are postinst.d* and +postrm.d*. .SH AUTHOR -Martin Michlmayr t...@cyrius.com +Martin Michlmayr t...@cyrius.com, Karsten Merker mer...@debian.org \ No newline at end of file diff --git a/functions b/functions index 26a16ed..4b1745e 100644 --- a/functions +++ b/functions @@ -351,28 +351,69 @@ android_flash() { } main() { -if [ x$1 = x--machine ]; then - machine=$2 - shift 2 -else + +while [ $# -gt 0 ] +do +if [ x$1 = x--machine ]; then +machine=$2 +shift 1 +elif [ x$1 = x--context ]; then +context=$2 +shift 1 +elif [ x$1 = x--supported ]; then +do_check_supported=true +elif [ $# -eq 1 ]; then +kvers=$1 +fi +shift 1 +done + +if [ -z $machine ]; then get_machine fi -if [ x$1 = x--supported ]; then +if [ -n $do_check_supported ]; then if check_supported $machine; then exit 0 + else + exit 1 fi - exit 1 fi -# kernel
Bug#735092: flash-kernel: add Raspberry Pi support
On Sun, Jan 12, 2014 at 07:01:36PM +, Ian Campbell wrote: On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote: On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote: On Sun, 2014-01-12 at 18:34 +0100, Karsten Merker wrote: The attached patch adds Raspberry Pi support to flash-kernel. [SNIP] So the boot partition is mounted at /boot? Doesn't that make it impossible to install packaged kernels (as dpkg needs to create hard links)? Installing a kernel package (locally built using make-kpkg) with a VFAT /boot does not show any problems here: The normal way of dealing with this is to not have the bootloader partition mounted on boot, this is described in flash-kernel via the Boot-Device field. I think this should be honoured for Rpi too. Rpi-ConfigTxt-Path would then be relative to this device. Having the vfat boot partition as /boot is the standard way in Raspbian (Debian/armhf rebuild for the Pi/armv6, official OS distribution for the Pi) and is described this way in all user documentation for the Pi. This is also expected by other software, in particular the firmware update mechanism, which expects the firmware image to be at /boot/bootcode.bin, as well as by the Raspberry Pi foundation's kernel updates (which do not come as a Debian kernel package). Not mounting the vfat boot partition at /boot would of course be technically possible, but nobody actually does that on a Pi and it would pose several problems: - The firmware update mechanism would have to be changed. This is outside the scope of Debian and as installing firmware updates is something that happens rather frequently on the Pi, that must work without problems. - All the Pi user documentation would have to be changed, which is also outside the scope of Debian. - In case the vfat boot partition is not mounted at /boot, the firmware cannot anymore directly boot the /boot/vmlinuz-* and /boot/initrd.img-* files from the kernel package. That would therefore require copying the files from /boot to the actual vfat boot partition. As having the vfat boot partition mounted on /boot is the actual default case, flash-kernel would have to handle this as well. This means either special handling depending on whether the vfat partition is at /boot or not, or generally copying the kernel to the vfat partition under another name. The latter would in the case vfat-at-/boot result in having the kernel and initrd twice on the already quite small system vfat partition, which is a route I would like to avoid. All things taken together I think that we should simply accept that the vfat boot partition gets mounted at /boot on the Pi and use it this way. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735092: flash-kernel: add Raspberry Pi support
On Sun, Jan 12, 2014 at 07:32:56PM +, Ben Hutchings wrote: On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote: On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote: So the boot partition is mounted at /boot? Doesn't that make it impossible to install packaged kernels (as dpkg needs to create hard links)? Installing a kernel package (locally built using make-kpkg) with a VFAT /boot does not show any problems here: [...] Please also test upgrading (or simply reinstalling the same package again). Indeed, reinstalling fails: dpkg: error processing linux-image-3.12.6-rpi+_2014010201_armhf.deb (--install): unable to make backup link of `./boot/vmlinuz-3.12.6-rpi+' before installing new version: Operation not permitted Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732310: xserver-xorg: xserver does not start after dist-upgrade from wheezy
Package: xserver-xorg Version: 1:7.7+4 Severity: important Dear Maintainer, at this time i only have console access and use reportbug. I will see to attach the xsession-errors as soon as possible. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jan 8 2012 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2281744 Nov 25 14:55 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions VGA-compatible devices on PCI bus: -- 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) Xorg X server configuration file status: -rw-r--r-- 1 root root 1319 May 30 2011 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 260.19.21 (buildmeister@builder101) Thu Nov 4 21:47:28 PDT 2010 Section ServerLayout Identifier Layout0 Screen 0 Screen0 0 0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section Files EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/psaux Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section InputDevice # generated from default Identifier Keyboard0 Driver kbd EndSection Section Monitor Identifier Monitor0 VendorName Unknown ModelName Unknown HorizSync 28.0 - 33.0 VertRefresh 43.0 - 72.0 Option DPMS EndSection Section Device Identifier Device0 Driver nvidia VendorName NVIDIA Corporation EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 SubSection Display Depth 24 EndSubSection EndSection /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.11-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) Xorg X server log files on system: -- -rw-r--r-- 1 webuser webuser 42479 Dec 4 2010 /var/log/Xorg.2.log -rw-r--r-- 1 webuser webuser 20923 Feb 11 2013 /var/log/Xorg.1.log -rw-r--r-- 1 rootroot19456 Dec 16 16:28 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [84.752] X.Org X Server 1.14.3 Release Date: 2013-09-12 [84.752] X Protocol Version 11, Revision 0 [84.752] Build Operating System: Linux 3.12.0-rc6-patser+ x86_64 Debian [
Bug#704242: Driver for PL-2303 HX not working
Am 15.12.2013 18:05, schrieb Greg KH: Have you tried a newer kernel in a while? A number of things have been hopefully fixed since June when you last looked. greg k-h no at this time i have not tested it - sorry. Although i am fascinated from your work i personally prefer to use stable releases for my daily work. This bug here shows that several functionalites in detail can be lost with an update. Then it takes much time to find workarounds - specially when hardware is not running any more. When i look in the Debian repositories i only see kernel 3.11.10 for testing and unstable. The latest one is 3.12.3 in experimental. I will see to upgrade one copy of my installation to testing on another partition with 3.11.10. Do you mean that will hopefully show a resolution for this problem? I do not know, 3.11 is pretty old, sorry. My distribution update fails into a system without X. So no new tests with Kernel 3.11 so far. I looked for a CD booting system with a newer kernel, but there seems to be no one? * Knoppix Kernel 3.9.6 * Kubuntu Kernel 3.11 maybe a choice As you can see - you can only dream of a 3.12.5 stable kernel. ;-) But when Debian Testing will run i make a retest of the PL-2303 HX. Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Hello Greg, Am 14.12.2013 18:08, schrieb Greg KH: On Fri, Dec 13, 2013 at 04:06:35PM +0100, Karsten Malcher wrote: Hello together, is there anything new for the PL-2303 HX? It would be fine if it could work like in the past. Have you tried a newer kernel in a while? A number of things have been hopefully fixed since June when you last looked. greg k-h no at this time i have not tested it - sorry. Although i am fascinated from your work i personally prefer to use stable releases for my daily work. This bug here shows that several functionalites in detail can be lost with an update. Then it takes much time to find workarounds - specially when hardware is not running any more. When i look in the Debian repositories i only see kernel 3.11.10 for testing and unstable. The latest one is 3.12.3 in experimental. I will see to upgrade one copy of my installation to testing on another partition with 3.11.10. Do you mean that will hopefully show a resolution for this problem? Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Hello together, is there anything new for the PL-2303 HX? It would be fine if it could work like in the past. Of course for Linux there are good alternatives. Here is a new one with the CP2102 suffering easy supply voltage: http://www.ebay.de/itm/110954294607 Best regards Karsten Am 24.06.2013 21:00, schrieb Greg KH: On Mon, Jun 24, 2013 at 12:38:17PM -0400, Aric Fedida wrote: I will gladly ship you one. Give me address details, and I'll go to the post office to send it. I'll send it off-list, thanks. Personally, I have resolved to abandon the PL2303 chip, and move to FTDI instead. But for the sake of other Linux users who might buy that adapter by mistake, I am willing to donate the hardware to an able kernel hacker :-) Yes, I recommend the ftdi devices as well, the specs are availble, and the driver seems to work better because of it. thanks, greg k-h -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726666: [nepomuk-core-runtime] nepomuk requires virtuoso version 6.1.6
Package: nepomuk-core-runtime Version: 4:4.11.3-1 After upgrading to nepomuk 4.11.3-1, the file indexer did not work anymore. .xsession-errors: nepomukstorage(14192)/nepomuk (storage service): NepomukStorage only works with virtuoso 6.1.6 and beyond kcmshell(14101)/nepomuk (library): Could not find virtuoso to connect to. Aborting Removing the existing configs and database did not help. After installing virtuoso-minimal from unstable (version 6.1.6+dfsg-3) all services work as expected. --- System information. --- Architecture: amd64 Kernel: Linux 3.10-3-amd64 Debian Release: jessie/sid 990 testing security.debian.org 990 testing ftp.de.debian.org 500 unstableftp.de.debian.org 500 testing-updates ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== libavformat54 (= 6:9.1-1) | 6:9.10-1 libavutil52(= 6:9.1-1) | 6:9.10-1 libc6 (= 2.14) | libepub0 (= 0.1.1) | libexiv2-12 | libgcc1(= 1:4.1.1) | libkdecore5 (= 4:4.11) | libkdeui5 (= 4:4.11) | libkidletime4 (= 4:4.11) | libkio5 (= 4:4.11) | libnepomukcore4 (= 4:4.11.3-1) | libpoppler-qt4-3 (= 0.18) | libqt4-dbus(= 4:4.6.1) | libqt4-xml (= 4:4.5.3) | libqtcore4 (= 4:4.8.0) | libqtgui4 (= 4:4.5.3) | libsolid4 (= 4:4.11) | libsoprano4 (= 2.9.3) | libstdc++6 (= 4.6) | libtag1c2a (= 1.5) | Package's Recommends field is empty. Package's Suggests field is empty. smime.p7s Description: S/MIME cryptographic signature
Bug#728014: [PATCH] Fix cross-building armhf kernel packages
Package: kernel-package Version: 12.036+nmu3 Tags: patch I am rather new to the arm architecture and currently trying to get a couple of things working on a Raspberry Pi. Building kernel packages natively on a 700MHz single-core ARMv6 cpu takes ages, so I have been looking into possibilities for cross-building kernel packages from faster architectures. According to the make-kpkg manpage, the following command $ make-kpkg --arch armhf --cross_compile arm-rpi-linux-gnueabi- \ --revision 20131002 --append_to_version -rpi --initrd \ --us --uc --rootcmd fakeroot kernel_image should build an armhf kernel package on an amd64 host with an arm-rpi-linux-gnueabi-crosstoolchain installed. With kernel-package 12.036+nmu3 this fails with debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel image goes to [kimagedest undefined] The usual case for this is that I could not determine which arch or subarch this machine belongs to. Please specify a subarch, and try again.. Stop. It looks like there are just a few definitions for armhf missing, which are only used in the case of cross-building - native builds work fine. With the attached patch, cross-building kernel packages for armhf works for me, i.e. it results in working kernel-image packages for the Raspberry Pi. I had asked on debian-arm whether anybody sees issues with the patch, but have received no reply. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/arches/armhf.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/arches/armhf.mk --- kernel-package-12.036+nmu3/kernel/ruleset/arches/armhf.mk 1970-01-01 01:00:00.0 +0100 +++ kernel-package-12.036+nmu3.patched/kernel/ruleset/arches/armhf.mk 2013-10-02 22:02:47.0 +0200 @@ -0,0 +1,34 @@ +# -*- Mode: Makefile-Gmake -*- +## armhf.mk --- +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## +### + +### ARMHF +ifeq ($(strip $(architecture)),armhf) + kimage := vmlinuz + target = zImage + NEED_DIRECT_GZIP_IMAGE=NO + kimagesrc = arch/$(KERNEL_ARCH)/boot/zImage + kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(KERNELRELEASE) + DEBCONFIG = $(CONFDIR)/config.armhf + kelfimagesrc = vmlinux + kelfimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(KERNELRELEASE) +endif + +#Local variables: +#mode: makefile +#End: diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/architecture.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/architecture.mk --- kernel-package-12.036+nmu3/kernel/ruleset/architecture.mk 2012-03-04 02:22:23.0 +0100 +++ kernel-package-12.036+nmu3.patched/kernel/ruleset/architecture.mk 2013-10-02 22:01:08.0 +0200 @@ -59,6 +59,10 @@ ifeq ($(strip $(architecture)),armeb) include $(DEBDIR)/ruleset/arches/armeb.mk endif +ifeq ($(strip $(architecture)),armhf) +include $(DEBDIR)/ruleset/arches/armhf.mk +endif + # PowerPC and PowerPC architecture ifneq ($(strip $(filter ppc powerpc ppc64 powerpc64,$(architecture))),) diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/misc/kernel_arch.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/misc/kernel_arch.mk --- kernel-package-12.036+nmu3/kernel/ruleset/misc/kernel_arch.mk 2012-03-04 02:39:27.0 +0100 +++ kernel-package-12.036+nmu3.patched/kernel/ruleset/misc/kernel_arch.mk 2013-10-02 21:55:54.0 +0200 @@ -56,6 +56,10 @@ KERNEL_ARCH := arm endif +ifeq ($(strip $(architecture)),armhf) + KERNEL_ARCH := arm +endif + ifeq ($(strip $(architecture)),hppa) KERNEL_ARCH := parisc endif
Bug#727102: wmbattery doesn't report battery status (3.2.0 kernel)
Package: wmbattery Version: 2.41 Severity: important Dear Maintainer, Following a system update and windowmanager (WindowMaker) restart, wmbattery would launch but reports no charge in the bell, '00:00' battery life, and 0% charge status. APM doesn't appear to be supported by my kernel. 'acpi -b' _does_ report battery status, e.g.: $ acpi -b Battery 0: Unknown, 95% Providing the '-b 0' option to wmbattery results in a segfault. '-b 1' reports as indicated above. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (999, 'testing'), (500, 'oldstable-updates'), (500, 'oldstable'), (400, 'experimental'), (400, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wmbattery depends on: ii hal 0.5.14-8 ii libapm1 3.2.2-14 ii libc62.17-93 ii libdbus-1-3 1.6.14-1 ii libhal1 0.5.14-8 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxpm4 1:3.5.10-1 wmbattery recommends no packages. Versions of packages wmbattery suggests: ii wmaker 0.95.4-2 -- no debconf information -- Karsten M. Self kars...@linuxmafia.comhttp://linuxmafia.com/~karsten What part of gestalt don't you understand? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723847: [Pkg-postgresql-public] Bug#723847: Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
On Sat, Oct 19, 2013 at 02:05:34PM +0200, Christoph Berg wrote: What we could do is to add this as an example (comment) to the default version we ship for createcluster.conf. I would say that's better than the current situation. Also, what about a debonf question of medium priority ? Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723847: [Pkg-postgresql-public] Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
On Tue, Oct 15, 2013 at 11:15:07PM -0400, Peter Eisentraut wrote: On Sat, 2013-10-12 at 11:09 +0200, Karsten Hilbert wrote: So, to rephrase the question: I wonder whether --data-checksums can be pre-set in /etc/postgresql-common/createcluster.conf's initdb_options ? It doesn't matter where you attach the option, the answer is the same: Upstream has decided that checksums should not be the default at this time. If you want to override that for the entire world of Debian, you need to come up with a good reason. No problem. Just asking. I do have good reasons but they probably only apply to my universe (p.d.o/gnumed-server). Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723847: [Pkg-postgresql-public] Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
On Fri, Oct 11, 2013 at 04:29:59PM -0400, Peter Eisentraut wrote: On 9/20/13 8:51 AM, Karsten Hilbert wrote: Package: postgresql-9.3 Version: 9.3~rc1-2 Severity: wishlist I wonder whether --data-checksums / -k can be made the default for creating new clusters starting with PG 9.3. It's an upstream decision, and it's not our place to override that. Well, OK, strictly speaking you are right because I misdirected the report -- it should have gone to postgresql-common since pg_upgradecluster belongs to that. Anything in postgresql-common ultimately is a Debian decision (as it is not provided by upstream). I agree those decisions may very well be in the *spirit* of upstream's defaults. So, to rephrase the question: I wonder whether --data-checksums can be pre-set in /etc/postgresql-common/createcluster.conf's initdb_options ? Would you take care of re-attaching the report or should I file a new one ? Thanks for the work on PostgreSQL, Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725691: mc: erratic behaviour of mcedit as subprocess of mc
Package: mc Version: 3:4.8.10-4 Severity: normal Tags: upstream With the latest update mcedit started to behave quite erratically: When mcedit is invoked by typing mcedit SOMEFILE from the mc commandline rather then pressing F4 on the file the editor will behave quite strange: - at first no file content is shown - upon pressing the first key the file content shows up - all keys react very delayed or not at all - the key delay is not predictable it differs from keystroke to keystroke - which keys don't react at all is not predictable either, the affected keys change, even within one and the same mcedit session The following has happened under the same circumstances but already for a longer time (it worked before): - ctrl/shift+INS copy/paste doesn't work - cursor key based text selection doesn't work Now, the answer might be: don't invoke mcedit manually under mc. However, mcedit is configured to be my default editor (say, sensible-editor and such) and thusly is invoked by many tools (like git for editing commit messages). Invoking mcedit from the shell makes it behave just fine. Karsten -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mc depends on: ii e2fslibs 1.42.8-1 ii libc6 2.17-93 ii libglib2.0-0 2.36.4-1 ii libgpm2 1.20.4-6.1 ii libslang2 2.2.4-15 ii libssh2-1 1.4.3-1 ii mc-data 3:4.8.10-4 Versions of packages mc recommends: ii mime-support 3.54 ii perl 5.18.1-4 ii unzip 6.0-9 Versions of packages mc suggests: ii acroread [pdf-viewer] 9.5.5-dmo1 ii arj3.10.22-11 ii bzip2 1.0.6-5 ii catdvi 0.14-12.1 ii dbview 1.0.4-1 ii djvulibre-bin 3.5.25.4-2 ii file 1:5.14-2 ii genisoimage9:1.1.11-2 pn gv none ii imagemagick8:6.7.7.10-6 ii odt2txt0.4+git20100620-1+b1 ii okular [pdf-viewer]4:4.10.5-1 ii poppler-utils 0.18.4-8 ii python 2.7.5-5 pn python-botonone ii python-tz 2012c-1 ii texlive-binaries 2013.20130729.30972-2 ii w3m0.5.3-11 ii xpdf [pdf-viewer] 3.03-11 ii zip3.0-7 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725692: mc: faulty behaviour of ALT-P
Package: mc Version: 3:4.8.10-4 Severity: normal Tags: upstream Regardless of whether mcedit is called from bash or from within an mc session this happens: - ALT-P sometimes does not properly wrap the first line of a paragraph - it ends considerably shorter than what would have fit inside the configured maximum width This has started to occur quite recently, maybe even with 4.8.10. Karsten -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mc depends on: ii e2fslibs 1.42.8-1 ii libc6 2.17-93 ii libglib2.0-0 2.36.4-1 ii libgpm2 1.20.4-6.1 ii libslang2 2.2.4-15 ii libssh2-1 1.4.3-1 ii mc-data 3:4.8.10-4 Versions of packages mc recommends: ii mime-support 3.54 ii perl 5.18.1-4 ii unzip 6.0-9 Versions of packages mc suggests: ii acroread [pdf-viewer] 9.5.5-dmo1 ii arj3.10.22-11 ii bzip2 1.0.6-5 ii catdvi 0.14-12.1 ii dbview 1.0.4-1 ii djvulibre-bin 3.5.25.4-2 ii file 1:5.14-2 ii genisoimage9:1.1.11-2 pn gv none ii imagemagick8:6.7.7.10-6 ii odt2txt0.4+git20100620-1+b1 ii okular [pdf-viewer]4:4.10.5-1 ii poppler-utils 0.18.4-8 ii python 2.7.5-5 pn python-botonone ii python-tz 2012c-1 ii texlive-binaries 2013.20130729.30972-2 ii w3m0.5.3-11 ii xpdf [pdf-viewer] 3.03-11 ii zip3.0-7 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692957: Info received (Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel)
Unforunately I could not follow up on the issue anymore because I had to get my systems back into a running state. If nobody else can reproduce it on Debian, then it is possible that the issue was indeed related to Ubuntu only or the specific kernel version used there. So this bug can probably be closed. BR, Karsten
Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
Package: postgresql-9.3 Version: 9.3~rc1-2 Severity: wishlist I wonder whether --data-checksums / -k can be made the default for creating new clusters starting with PG 9.3. If not it'd still be good to capture the rationale for that decision. I am aware of /etc/postgresql-common/createcluster.conf - initdb_options and that has worked nicely for me. Karsten -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postgresql-9.3 depends on: ii libc6 2.17-92+b1 ii libcomerr2 1.42.8-1 ii libgssapi-krb5-2 1.11.3+dfsg-3 ii libkrb5-3 1.11.3+dfsg-3 ii libldap-2.4-2 2.4.31-1+nmu2+b1 ii libpam0g 1.1.3-9 ii libpq5 9.3~rc1-2 ii libssl1.0.01.0.1e-3 ii libxml22.9.1+dfsg1-3 ii locales2.17-92 ii locales-all [locales] 2.17-92+b1 ii postgresql-client-9.3 9.3~rc1-2 ii postgresql-common 149 ii ssl-cert 1.0.33 ii tzdata 2013d-1 postgresql-9.3 recommends no packages. Versions of packages postgresql-9.3 suggests: ii locales-all 2.17-92+b1 pn oidentd | ident-server none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721595: KDE network manager does not work
Package: plasma-widget-networkmanagement Version: 0.9.0.3-1 Severity: important Hello, i am trying desperated to get WLAN working without problems on wheezy. One time i get a connection, then never again. I installed the network manager to have a comfortable configuration, but it seems not to have the correct rights to work. The scanning for hotspots does not work and when i manually create a WLAN connection and try to save it, it fails with insufficient privileges (see screenshot). As you can see here i have access to WLAN functionality on the shell: root@pc# iwlist wlan2 scan wlan2 Scan completed : Cell 01 - Address: 00:1E:58:BB:80:CD Channel:1 Frequency:2.412 GHz (Channel 1) Quality=68/70 Signal level=-42 dBm Encryption key:on ESSID:dd-wrt Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf= Extra: Last beacon: 32ms ago IE: Unknown: 000664642D777274 IE: Unknown: 010882848B960C121824 IE: Unknown: 030101 IE: Unknown: 05040001 IE: Unknown: 2A0104 IE: Unknown: 32043048606C IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: Unknown: DD0900037F01010020FF7F But automatically it is not configured correct with the WPA key: root@pc# iwconfig wlan2 IEEE 802.11abg ESSID:dd-wrt Mode:Managed Frequency:2.412 GHz Access Point: 00:1E:58:BB:80:CD Tx-Power=200 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off This is my current network configuration file: root@pc:/etc/network# cat interfaces ... allow-hotplug eth6 iface eth6 inet static ... auto wlan2 iface wlan2 inet dhcp wpa-ssid dd-wrt wpa-psk mysecretpassword Why the network manager has not enough privileges? Any other idea to solve the problem? Best regards Karsten -- System Information: Debian Release: 7.1 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages plasma-widget-networkmanagement depends on: ii kde-runtime 4:4.8.4-2 ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libkcmutils44:4.8.4-4 ii libkdecore5 4:4.8.4-4 ii libkdeui5 4:4.8.4-4 ii libkio5 4:4.8.4-4 ii libknotifyconfig4 4:4.8.4-4 ii libplasma3 4:4.8.4-4 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network 4:4.8.2+dfsg-11 ii libqt4-svg 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsolid4 4:4.8.4-4 ii libsolidcontrol4abi24:4.8.4-6 ii libstdc++6 4.7.2-5 ii mobile-broadband-provider-info 20120708-1 ii network-manager 0.9.4.0-10 Versions of packages plasma-widget-networkmanagement recommends: ii kwalletmanager 4:4.8.4-3 ii network-manager-openvpn 0.9.4.0-1 ii network-manager-pptp 0.9.4.0-2 ii network-manager-vpnc 0.9.4.0-1 Versions of packages plasma-widget-networkmanagement suggests: pn kdebase-workspace-bin none -- no debconf information attachment: privileges.png
Bug#721595: package not working
Here is a forum thread with someone where it is not working also. http://debianforum.de/forum/viewtopic.php?f=30t=138291 The solution was to deinstall the kde networkmanager and to install wicd. root@weide:/home/hugo# apt-get purge network-manager root@weide:/home/hugo# rm -r /etc/NetworkManager/ root@weide:/home/hugo# apt-get install wicd wicd-gtk wicd-curses I think i will test it now. Is this really the only solution? Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721595: KDE network manager does not work
Hi Michael, the first thing is that wicd doesn't work also. :-) So i reinstalled the network-manager-kde. Am 02.09.2013 14:10, schrieb Michael Biebl: You've configured your network interface device(s) in /etc/network/interface, that means they are managed by ifupdown. It makes no difference if i have only the lines for iface lo in the interfaces file or if the file doesn't exist. Network is not coming up and the manager is not scanning for WLAN. The same message with insufficient privileges appers by manual entry and save. There must be more wrong. If you want to manage your interface with network-manager/plasma-widget-networkmanagement, you should remove those interfaces from /etc/network/interfaces. See also /usr/share/doc/network-manager/README.Debian Hmm - this dependencies are not not clear for me and for other users. It would be fine if the right dependencies would be checked when the package is installed. It seems to be always a struggle to get WLAN running. I will not think about bluetooth .. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721595: KDE network manager does not work
Hi, Am 02.09.2013 17:10, schrieb Michael Biebl: Do you have a complete, default KDE desktop installation? What's complete? Default is very complicate with an upgraded system. So i would say - No. What's the output of 'ck-list-sessions' and 'pkaction'? karsten@pc:~$ ck-list-sessions Session1: unix-user = '1000' realname = 'Karsten' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2013-09-02T15:54:11.303898Z' login-session-id = '4294967295' karsten@pc:~$ pkaction Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Do you have polkit-kde-1 installed? Yes ii polkit-kde-1 0.99.0-3 amd64KDE dialogs for PolicyKit Thanks for your help so far. Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721243: rsyslog: $PreserveFQDN on was not honored in some modules.
Package: rsyslog Version: 5.8.11-3 Severity: important plaese insert commit from rsysloggit http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=dec9bcfe2a869b0f70b5f2a18e08a0322ebf5517 I dont use the fqdn. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720859: kwalletmanager does not start
Package: kwalletmanager Version: 4:4.8.4-3 Severity: important Hello, today i want to delete two stored passwords from kwallet. But when i try to open the kwalletmanager nothing happens. When i try to open it from the shell i get: karsten@PC:~$ kwalletmanager QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. Any ideas to solve the problem? Best regards Karsten -- System Information: Debian Release: 7.1 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kwalletmanager depends on: ii kde-runtime 4:4.8.4-2 ii libc62.13-38 ii libkdecore5 4:4.8.4-4 ii libkdeui54:4.8.4-4 ii libkio5 4:4.8.4-4 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui44:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 kwalletmanager recommends no packages. kwalletmanager suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: Info received (Bug#705919: icedove does not play sounds (notifications when new messages arrive))
Today after the next reboot it works! My last actions where to install this two packages: pulseaudio-esound-compat alsaplayer-esd I think this seems to fix the problem. This bug can be closed. Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Hi, Am 21.07.2013 14:20, schrieb Carsten Schoenert: Hello Karsten, Where i can see this? There is no line with something like sound. You found the related lines as you wrote in the other mail. No - i opened prefs.js directly with an editor. Found this two lines in prefs.js now: user_pref(mail.biff.play_sound.type, 1); user_pref(mail.biff.play_sound.url, file:///path/mysound.wav); This means the file would be found in '/path/mysound.wav' ? Is that true? And if so what about the access right of that file? Icedove is able access that file (in context of your user permissions)? A file location like this is very unconventional. Better select a file inside your home directory. Of course not - the file name was manually edited for the email from me. If this want work your sound system is configured wrong. My soundsystem is working perfect in all other cases. I have renamed my prefs.js and started Icedove again. Now i simply added the soundfile as shown in the screenshot. This does not work! The only thing i can do now is to try the original Thunderbird. Cheers Karsten attachment: soundconfig.png
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Hello Carsten, i tested now with the original Thunderbird and there is no sound notification also. So this should be a general problem or a sound misconfiguration. I attached a screenshot for the sound configuration of the Thunderbird. But how can i find the problem? All other sound is working! The file is playing perfect with any other soundplayer including aplay siehabenpost.wav. Best regards Karsten attachment: thunderbird.png
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
One new idea basing on this Link: http://forums.bodhilinux.com/index.php?/topic/5060-solved-thunderbird-stopped-playing-sound-when-new-messages-arrive/ The libs libesd0 libcanberra0 libstdc are installed. Esound is installed, but the pulseaudio layer was missed first. # dpkg -l | grep esound ii esound-common 0.2.41-10 all Enlightened Sound Daemon - Common files ii pulseaudio-esound-compat 2.0-6.1amd64PulseAudio ESD compatibility layer Sound is still not playing. I found out that the esound daemon is not runnning. But when i manually start esd this does not matter. # esd -v pulseaudio esd wrapper 2.0 I am not shure if this mus really run, because it is also a wrapper? Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Hello Carsten, thank you for response. Can you supply me with some more details how to proceed your tests? Am 21.07.2013 11:58, schrieb Carsten Schoenert: Check your settings in your prefs.js if you have sound support enabled. Where i can see this? There is no line with something like sound. Also check your setting in General if the selected 'Use the following sound file' is working, if not you have missconfigured soundsystem. There is a wav file selected, but this does not work. Even with the play button nor with incoming mail. This is the reason for this bug report. If yes, please start with disabled plugins and in safe-mode, maybe there is something that block the sound output. I have no idea how to do this? If that doesn't work backup your current profile and start from scratch with a fresh clean profile. Very offen problems comes in context with a old profile.js migrated from the beginning of using Icedove. To be sure the problem is a real software problem please check if your issue is not depending on the old profile. I will try this, but this is really much work, because i have plenty of accounts and settings. When you are waiting for mail response it is very helpful to get an acoustic sign for incoming mails when you are not working on the screen the whole time. For me that isn't importend. I have static times there I check my mails, I made the decision if I look at the mail, not the MTA. My life is easier with that rule. And i want to be notified. And, Icedove will only play a sound if the mail is the really first one new in the queue and you have no others unread new messages. If you have other ones that are unread and a new mail is comming no sound will played. That's fullfilled. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Found this two lines in prefs.js now: user_pref(mail.biff.play_sound.type, 1); user_pref(mail.biff.play_sound.url, file:///path/mysound.wav); Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
Hello Greg, Am 24.06.2013 20:56, schrieb Greg KH: But wiring that up to a real 9pin serial port would be a pain (doable, but a pain). Is there any devices out there with a DB-9 output connector? You mean if you want to test full handshake with all signals - that's true. Which is what the driver needs to test, right? And of course, everone with this problem is properly hooking up these signals, right? I can't speak for all applications but i never use the hardware handshake for data transfer. As i have written i don't know applications that will do it. Like most of the older mobile adapters. That's the reason why this PL-2303 HX adapter has no handshake signals outside. Maybe some people abuse this input and output lines for IO purposes like for programmers. One time is tried such an adapter like this but it does not work. ;-) http://www.lancos.com/siprogsch.html (I tried not to use it with an usb serial interface - i used a good and old PC UART.) Otherwise, there will be problems as the pins could float and cause transmissions / receive data to stop happening. This should not happen if handshake is disabled. In the case of this PL-2303 HX adapter it worked with windows and the older kernel without handshake. But of course it is better when everything is tested. At the least, loop-back testing is important. This test is sufficient to see if the problem occurs. The advantage of the adapter is to get directly 5V and 3,3V. What do you mean by this? Normally you use this adapters to transfer data from a microcontroller. It is very useful when you have direct the necessary power supply for the microcontroller. The PL-2303 can work with 5V and 3.3V logic and this adapter has also a 3.3V output for some mA. I don't know some other adapter with exactly this chip, because i don't need them. Only this Adapter which use the other chip ch341-uart which works without problems http://www.ebay.com/itm/USB-to-RS232-Serial-9-Pin-DB9-Adapter-PC-PDA-RS-232-/180399132966 When i think about it i never seen that someone uses the handshake for this simple serial communication. Not in communication with mobiles, ARM-boards or AVR microcontroller. The built-in UART's in the ARM and AVR don't suffer handshake signals, so that you must do it by software with additional IO ports. What's wrong with software flow control? Nothing is wrong with it! I just want to say that in most applications nobody use it. You communicate from a quick PC to a slower microcontroller with at least slow data rates. The microcontroller has an IRQ on the UART you can use for incoming data. So this works normally without any problems and additional handshake. Why reinvent something that has been successfully used for 30+ years? Before 30 years computers where slow and without a multitasking OS. So you need handshake when you don't want to loose data. i think you misunderstand me. thanks, greg k-h Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Am 24.06.2013 21:00, schrieb Greg KH: Personally, I have resolved to abandon the PL2303 chip, and move to FTDI instead. But for the sake of other Linux users who might buy that adapter by mistake, I am willing to donate the hardware to an able kernel hacker :-) Yes, I recommend the ftdi devices as well, the specs are availble, and the driver seems to work better because of it. Yes - i agree. But you have no influence which chip is used when you buy an adapter or interface cable. There are millions out there for mobiles, GPS, PDA, etc. It's a pity when you can't connect your device because the usb serial chip is not supported in Linux. (When you have a newer device you will find out that bluetooth is not working correct also.) thanks, greg k-h Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
Am 25.06.2013 18:54, schrieb Johan Hovold: On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote: Hello Greg, have you buyed one of this jinxed PL-2303 HX adapters? Yesterday i got this interesting mail from Aric, who has analyzed a similar problem with this chip. Why do you think that this is related to the problems you were experiencing back in April? Maybe Aric can explain it better? I only see several problems to use a PL-2303 HX with newer kernels. Just to be clear, that's your setup. AFAICT Aric never got his setup to work with any kernel (but for a brief period with the same 3.0 kernel). The only solution i see is to give up any PL-2303 HX device like Aric. But the problems for other users will remain ... As we discussed in April, there has been a lot of changes (including performance improvements) made to the pl2303 driver since 2.6.32 which could possibly explain why you did not trigger your (suspected) hw error on really old kernels. I remember a similar discussion on not reliable usb connectors with external hdd's. This connectors are often produced cheap and the connection is not reliable each time after plugin. When you argue that you must forget each device or hardware in case of an error, you can forgot much usb devices using with Linux. (In fact windows just ignores the errors.) My forecast is that the number of sporadic errors will increase, specially with usb 3. Thanks, Johan Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
Am 25.06.2013 19:29, schrieb Johan Hovold: Maybe Aric can explain it better? I only see several problems to use a PL-2303 HX with newer kernels. Just to be clear, that's your setup. AFAICT Aric never got his setup to work with any kernel (but for a brief period with the same 3.0 kernel). The only solution i see is to give up any PL-2303 HX device like Aric. But the problems for other users will remain ... Only if the hardware is actually broken, of course. I'm just saying that it looks like two different (hw related) problems here. Yes - that's correct. I misunderstood. I could not detect wrong bytes when i received some bytes after plugin. In fact we have to different problems here. I remember a similar discussion on not reliable usb connectors with external hdd's. This connectors are often produced cheap and the connection is not reliable each time after plugin. When you argue that you must forget each device or hardware in case of an error, you can forgot much usb devices using with Linux. (In fact windows just ignores the errors.) My forecast is that the number of sporadic errors will increase, specially with usb 3. Sure, if it is something that can be worked around in software without too much overhead for non-broken devices (I have only a working HX here), then we can try it. Perhaps the device you were gonna send to Greg can be used to implement such a work-around (or at least be used to determine the cause of the problem). This error override seems to work for some devices, but i have no knowledge of the general Linux USB architecture. I only want to remark that it could happen sometimes that a device has a bad connection after plugin. Next time it can work without any error. Of course there is many cheap (china) hardware that always produces errors. I have seen many bad usb hubs. Johan Hopefully the problem with the PL-2303 HX could be fixed in the future. As Greg has written the RS-232 is not dead for more than 30 years and it will live for many more years. Only this usb converters make simple and good things problematic ... Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
Hello Greg, Am 24.06.2013 18:17, schrieb Greg KH: On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote: Hello Greg, have you buyed one of this jinxed PL-2303 HX adapters? No, I have not been able to find one. Does anyone know where I can purchase one? Just take this one: http://www.ebay.com/itm/USB-To-RS232-TTL-PL2303HX-Auto-Converter-Module-5V-3-3V-Output-Converter-Adapter-/370812126675 US $1.67 and it is yours. Yesterday i got this interesting mail from Aric, who has analyzed a similar problem with this chip. I think something went wrong in the usb serial handling, but not in the driver itself. But the error is really complicate to figure out in the depth of the software. The really annoying thing is that it worked with kernel 2.6.32. That's a really long time ago, loads of things have changed since then. If someone can run 'git bisect' to track down the problem, that would be wonderful. Yes - that would reduce the problem. But i think it must be debugged with the correspondend hardware too, or not? thanks, greg k-h Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Am 24.06.2013 18:38, schrieb Aric Fedida: I will gladly ship you one. Give me address details, and I'll go to the post office to send it. Personally, I have resolved to abandon the PL2303 chip, and move to FTDI instead. But for the sake of other Linux users who might buy that adapter by mistake, I am willing to donate the hardware to an able kernel hacker :-) Yes - i will also spend $1,67 and buy one to send to the right destination address to help to solve the problem. Just let me know ... The advantage of this universal adapters is that you can simply shorten RXD and TXD for a loop with one of the included cables. Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
Am 24.06.2013 20:18, schrieb Greg KH: On Mon, Jun 24, 2013 at 06:41:38PM +0200, Karsten Malcher wrote: Hello Greg, Am 24.06.2013 18:17, schrieb Greg KH: On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote: Hello Greg, have you buyed one of this jinxed PL-2303 HX adapters? No, I have not been able to find one. Does anyone know where I can purchase one? Just take this one: http://www.ebay.com/itm/USB-To-RS232-TTL-PL2303HX-Auto-Converter-Module-5V-3-3V-Output-Converter-Adapter-/370812126675 US $1.67 and it is yours. But wiring that up to a real 9pin serial port would be a pain (doable, but a pain). Is there any devices out there with a DB-9 output connector? You mean if you want to test full handshake with all signals - that's true. The advantage of the adapter is to get directly 5V and 3,3V. I don't know some other adapter with exactly this chip, because i don't need them. Only this Adapter which use the other chip ch341-uart which works without problems http://www.ebay.com/itm/USB-to-RS232-Serial-9-Pin-DB9-Adapter-PC-PDA-RS-232-/180399132966 When i think about it i never seen that someone uses the handshake for this simple serial communication. Not in communication with mobiles, ARM-boards or AVR microcontroller. The built-in UART's in the ARM and AVR don't suffer handshake signals, so that you must do it by software with additional IO ports. thanks, greg k-h Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: It's a problem of PHP and not MySQL
Hello Bob, Am 10.06.2013 02:30, schrieb Bob Proulx: Thank you for the bug report. However this is very little to go upon. From what you have said so far there isn't enough information to know what might be happening. At this point the problem could be anything. Yes - i have the same problem at this time. But most of the applications are to complex for a simply debug. Because php has been updated to 5.5.0 it is most likely that your wikimedia and phpbb applications are not updated to work with the changes in php 5.5. I think that is the most likely problem. The server installation is complete new (no upgrade) with wheezy from beginning of may. I installed most of the applications new to the latest stable releases. So wikimedia is V 1.20.4. The migration of the previous version seems not make problems. What can i do more than to install the actual version? There is other software that has no newer versions. E.g. http://www.phpmyedit.org/ Here i have the problem that the software is doing nearly nothing. There is no error message in the apache2 logs and links and buttons are not working. But this error is consistent. What i cannot understand is why an update is empty depending of the content (always simple text)? If it didn't work at all then there would be many reports. Yes - i wonder about this also . And i thought that PHP is more downwards compatible. Hopefully someone will answer with the same problem. Therefore this is probably simply an incompatibility with the recent updates and changes in upstream php 5.5. Up to now i can't find similar problem descriptions. Since you have the problem, and no one else is seeing the problem so far, and you have been making progress debugging it then it would be most helpful if you could keep going and get to the bottom of the problem. Thanks, Bob I must find out how to increase the debug information of php5? Here the installed packages: ii libapache2-mod-php5 5.4.4-14 i386 server-side, HTML-embedded scripting language (Apache 2 module) ii php5 5.4.4-14 all server-side, HTML-embedded scripting language (metapackage) ii php5-cli 5.4.4-14 i386 command-line interpreter for the php5 scripting language ii php5-common 5.4.4-14 i386 Common files for packages built from the php5 source ii php5-curl5.4.4-14 i386 CURL module for php5 ii php5-exactimage 0.8.5-5i386 fast image manipulation library (PHP bindings) ii php5-gd 5.4.4-14 i386 GD module for php5 ii php5-geoip 1.0.7-8 i386 GeoIP module for php5 ii php5-imagick 3.1.0~rc1-1+b2 i386 ImageMagick module for php5 ii php5-imap5.4.4-14 i386 IMAP module for php5 ii php5-intl5.4.4-14 i386 internationalisation module for php5 ii php5-mcrypt 5.4.4-14 i386 MCrypt module for php5 ii php5-mysql 5.4.4-14 i386 MySQL module for php5 ii php5-pspell 5.4.4-14 i386 pspell module for php5 ii php5-recode 5.4.4-14 i386 recode module for php5 ii php5-sqlite 5.4.4-14 i386 SQLite module for php5 Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL
Hello, Am 10.06.2013 10:42, schrieb Ondřej Surý: On Mon, Jun 10, 2013 at 9:58 AM, Karsten Malcher deb...@dct.mine.nu mailto:deb...@dct.mine.nu wrote: The server installation is complete new (no upgrade) with wheezy from beginning of may. I installed most of the applications new to the latest stable releases. So wikimedia is V 1.20.4. There was something related to the upgrade of mediawiki in Debian: http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/NEWS?view=markup But I am not sure if this is related to your installation. The user has all rights for the DB. There is a good and comfatable installer for mediawiki. Every checkes and migration works without problem. I have the reported problems with the user. For this i will ask the mediawiki team. Does the affected applications use some common (could be PEAR or PECL or just some PHP files somewhere) library which you have installed by hand? No - i only downloaded the installation file and unpacked it. Thank you for help. Karsten Ondrej -- Ondřej Surý ond...@sury.org mailto:ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: It's a problem of PHP and not MySQL
I activated the general log in MySQL and proofed what SQL is send to the server in the problematic updates. In case of wikimedia no clear update command is send, but in phpbb i could see that the update is blank instead of the content. 1339 Query UPDATE phpbb_topics SET topic_title = '', topic_type = 0 WHERE topic_id = 1066 The topic_title should contain a text. Something goes wrong in PHP5. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: Bug reported to MySQL
Please refer to the bug at mySQL: http://bugs.mysql.com/bug.php?id=69430 I have done an additional test now. Up to now i used phpmyadmin to talk to mysql. Now i tried to use the shell command instead. mysql -u username -ppassword dbname -e UPDATE user SET user_password = CONCAT(':A:', MD5('public')) WHERE user_name = 'public' This seems to work. mysql -u username -ppassword dbname -eselect * from user WHERE user_name = 'public' +-+---++-+--+---+-++--+--+--+--+---++ | user_id | user_name | user_real_name | user_password | user_newpassword | user_newpass_time | user_email | user_touched | user_token | user_email_authenticated | user_email_token | user_email_token_expires | user_registration | user_editcount | +-+---++-+--+---+-++--+--+--+--+---++ | 2 | public| Public | :A:4c9184f37cff01bcdc32dc486ec36961 | :B:b50fb7bb:e5fcb263a54546d423589c83cc5b1263 | 20130605082126| w...@dct.mine.nu | 20130605082131 | 6cddefa506a7c33b9a7372af70c69604 | NULL | NULL | NULL | 20071015111247| 1132 | +-+---++-+--+---+-++--+--+--+--+---++ So maybe the problem is caused by PHP? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711254: mysql-server-5.5: Some inserts and updates with strange effects (missing results)
Package: mysql-server-5.5 Version: 5.5.31+dfsg-0+wheezy1 Severity: important Hello, after my last update i have very strange effects on my webserver regarding mySQL. One example with an installed wikimedia. I can't use or update the user public. The user exists - i can see it with select * from user WHERE user_name = 'public' but when i try to update the users password with UPDATE user SET user_password = CONCAT(':A:', MD5('public')) WHERE user_name = 'public' no rows are affected. The user is not found by the wiki when you try to login. It's the same with the updatescript from wikimedia: # php changePassword.php --user=public --password=public No such user: public There are also strange effects in other software like an phpbb forum. I can add a thread but the title is missing and empty. When i try to edit it sometimes a title is accepted and updated and sometimes it is empty again. Everything else seems to work without problems. I open this bug in hope that someone have the same problems. Is it possible to roll back the last package updates only for mysql? Best regards Karsten -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mysql-server-5.5 depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii initscripts2.88dsf-41 ii libc6 2.13-38 ii libdbi-perl1.622-1 ii libgcc11:4.7.2-5 ii libstdc++6 4.7.2-5 ii lsb-base 4.1+Debian8 ii mysql-client-5.5 5.5.31+dfsg-0+wheezy1 ii mysql-common 5.5.31+dfsg-0+wheezy1 ii mysql-server-core-5.5 5.5.31+dfsg-0+wheezy1 ii passwd 1:4.1.5.1-1 ii perl 5.14.2-21 ii psmisc 22.19-1+deb7u1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages mysql-server-5.5 recommends: ii bsd-mailx [mailx] 8.1.2-0.2006cvs-1 ii libhtml-template-perl 2.91-1 Versions of packages mysql-server-5.5 suggests: pn tinyca none -- debconf information: * mysql-server/root_password_again: (password omitted) * mysql-server/root_password: (password omitted) mysql-server/error_setting_password: mysql-server-5.5/postrm_remove_databases: false mysql-server-5.5/nis_warning: mysql-server-5.5/really_downgrade: false mysql-server-5.5/start_on_boot: true mysql-server/password_mismatch: mysql-server/no_upgrade_when_using_ndb: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706499: Ethernet with Realtek R8169 only working with IPV6
Hello Ben, yesterday i started my tests and the system just wants to blame me. I connected the 1000 MB card with an additional network cable and i setup the /etc/network/interfaces with # The primary network interface 1000 MB allow-hotplug eth0 iface eth0 inet static address 192.168.1.3 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # The secondary network interface 100 MB allow-hotplug eth1 iface eth1 inet static address 192.168.1.4 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.1 and rebootet. Afterwards the R8169 card works without problem. # ip addr 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:e0:52:c8:d4:38 brd ff:ff:ff:ff:ff:ff inet 192.168.1.4/24 brd 192.168.1.255 scope global eth0 inet6 fe80::2e0:52ff:fec8:d438/64 scope link valid_lft forever preferred_lft forever 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:13:d4:d2:84:32 brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth1 inet6 fe80::213:d4ff:fed2:8432/64 scope link valid_lft forever preferred_lft forever # ifconfig eth0 Link encap:Ethernet Hardware Adresse 00:e0:52:c8:d4:38 inet Adresse:192.168.1.4 Bcast:192.168.1.255 Maske:255.255.255.0 inet6-Adresse: fe80::2e0:52ff:fec8:d438/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:194 errors:0 dropped:0 overruns:0 frame:0 TX packets:143 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:21846 (21.3 KiB) TX bytes:22549 (22.0 KiB) Interrupt:20 Basisadresse:0x8c00 eth1 Link encap:Ethernet Hardware Adresse 00:13:d4:d2:84:32 inet Adresse:192.168.1.3 Bcast:192.168.1.255 Maske:255.255.255.0 inet6-Adresse: fe80::213:d4ff:fed2:8432/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:27 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:3052 (2.9 KiB) TX bytes:4382 (4.2 KiB) Interrupt:17 Basisadresse:0xc400 The problem has come like a ghost and gone like a ghost. It's hard to say for me but - the bug can be closed. This problem is really not reproducible. Now i must master my routing problem - maybe the problem will come up again ... Best regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706499: Ethernet with Realtek R8169 only working with IPV6
Hello Ben, Am 04.05.2013 23:19, schrieb Ben Hutchings: No, I want bug reports that have useful information for working towards a solution. Then don't close bugs without trying to solve them please. I am not a maintainer and an expert, but i am learning and do what is possible. [...] So this interface has not been brought up. Neither IPv4 nor IPv6 will work. I have written that the server is in use. Stable ethernet connection only over the built-in 100 network of the mainboard. The 1000 card with R8169 is not in use at this moment. I will connect it with an additional network cable to the switch and make a retest hopefully this evening. As final solution i want to connect the internet router near the server to the internal 100 network and route it through the server to the 1000 card connected to the LAN. So i have a highspeed connection for the fileserver and only one network cable for the server and slower 100 internet router. Just in this second i found an additional hint to solve the problem: http://www.fene-blog.de/linux/kein-netzwerk-bei-debian-6-squeeze-und-realtek-r8168/ http://www.fene-blog.de/linux/debian-eth0-link-down-problem-mit-realtek-r8169-beheben/ http://forums.debian.net/viewtopic.php?f=5t=85431 (english) It's written in german and says the problem is that the driver for 8169 is used instead of 8168. This seems not to make sense but apparently has solved the problem for Debian Squeeze ? (It's not clear if the chip 8168 or 8169 was in use.) I have a network card with the 02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) The driver for the 8168 is not in the testing distribution but seems to be in unstable. http://packages.debian.org/unstable/main/r8168-dkms I will try to compile it and test if it helps. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706499: Ethernet with Realtek R8169 only working with IPV6
Am 02.05.2013 12:20, schrieb Ben Hutchings: If you want us, as maintainers, to investigate a bug, you must let us decide what information we need. Please provide the whole boot log. On one side you want to have only bug reports with a solution and on the other side you want to be the only one who decides what information will be given in the bug report without any help from me. Sorry - that don't fit together. First i could work with eth0 and installed debian without problems. After a reboot the problems come up. Now i use eth1, because eth0 comes not up reliable. I'm still unclear on what you mean by this. Please provide the output of 'ip addr' in the case where you consider that eth0 has not come up. Ben. O.K. The problem is that this is my server running without keyboard and screen standing in the basement. That's the reason why eth must come up reliable to have access. So it is running with the onboard 100 MB now and the 1000 MB R8169 is not connected. For test purposes i can connect an additional network cable to the R8169 and make the tests you need. But it seems to be senseless for a closed bug. ;-) At this time: # ip addr 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:e0:52:c8:d4:38 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:13:d4:d2:84:32 brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth1 inet6 fe80::213:d4ff:fed2:8432/64 scope link valid_lft forever preferred_lft forever Best regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706499: Ethernet with Realtek R8169 only working with IPV6
Hello Ben, Am 02.05.2013 01:41, schrieb Ben Hutchings: Control: tag -1 moreinfo Please provide: - Kernel boot log (/var/log/dmesg) Is provided in the first post. Nothing special can be seen. Maybe it is possible to activate a debug mode? When i have enough information i may ask the kernel team. But my experience is that the first question is It is working with the actual kernel? - Network configuration files (/etc/network/interfaces and any others) First i could work with eth0 and installed debian without problems. After a reboot the problems come up. Now i use eth1, because eth0 comes not up reliable. - If you are using DHCP, the DHCP daemon log messages (grep dhclient /var/log/daemon.log) It's configuration with static IP's. Ben. Karsten # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface 1000 MB allow-hotplug eth0 iface eth0 inet static address 192.168.1.3 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.1.1 # The secondary network interface 100 MB allow-hotplug eth1 iface eth1 inet static address 192.168.1.4 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255
Bug#706499: Ethernet with Realtek R8169 only working with IPV6
Hello Ben, maybe you are right and this is not a bug. But it is caused by an alternating configuration. I think it is not caused by the firmware and the driver. As i have written first the eth0 works without no problem. I have ethernet cards with the same chip on other PC's and the problem does not occur. It must be a special combination so only soome users are affected. When i boot the backup of this first configuration from the second partition eth0 works again. After some time and additional installation of packages there seems to go something wrong. But the error first occured after a reboot. I remember that only IPV6 was active but no IPV4. My question is where IPV4 is activated and configured? Best regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706583: Installation report Wheezy DI rc2 amd64 xfce: installation ok
Package: installation-reports Boot method: isohybrid image booted from USB stick Image version: http://cdimage.debian.org/cdimage/wheezy_di_rc2/amd64/iso-cd/debian-wheezy-DI-rc2-amd64-netinst.iso Date: 2013-05-01 Mainboard: ECS P35T-A Processor: Intel E3300 Memory: 4GB Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1] (rev 02) 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC-2 Gigabit Network Connection [8086:294c] (rev 02) 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 02) 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 02) 00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.3 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IH (ICH9DH) LPC Interface Controller [8086:2912] (rev 02) 00:1f.2 IDE interface [0101]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA Controller [IDE mode] [8086:2920] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2 port SATA Controller [IDE mode] [8086:2926] (rev 02) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV505 [Radeon X1550 Series] [1002:7143] 01:00.1 Display controller [0380]: Advanced Micro Devices [AMD] nee ATI RV505 [Radeon X1550 Series] (Secondary) [1002:7163] 06:00.0 SATA controller [0106]: JMicron Technology Corp. JMB361 AHCI/IDE [197b:2361] (rev 02) 06:00.1 IDE interface [0101]: JMicron Technology Corp. JMB361 AHCI/IDE [197b:2361] (rev 02) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The installation process worked flawlessly. Installation was done using a network mirror; network connectivity was provided via a TP-Link TL-WN727N 802.11n WLAN dongle (USB ID: 148f:5370, Ralink RT5370 chipset). The installer prompted for the WLAN dongle's firmware, which was provided on a USB stick (downloaded from http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/wheezy/current/). Basic X11 functionality worked out of the box, advanced X11 features (in particular XVideo support) required installation of the non-free radeon firmware from the package firmware-linux-nonfree. A sidenote: while the WLAN via the TL-WN727N generally works, interactive use (in particular using logins via ssh) shows that the connection often has short lags or hangs. This happens even when the WLAN dongle is within 2m of the access point with direct line of sight. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706499: Ethernet with Realtek R8169 only working with IPV6
Package: firmware-realtek Version: 0.36+wheezy.1 Severity: normal Hello, please refer to this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611954 and http://serverfault.com/questions/384165/after-installing-debian-squeeze-ethernet-does-not-come-up The card only works when you do a manually ifup eth0 with IPV4. But not every time - sometimes it is simply dead for IPV4. Here what you see when it comes up: [ 12.096480] uli526x :00:0d.0: eth1: NIC Link is Down [ 12.551617] r8169 :02:07.0: eth0: link up [ 12.551821] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.235598] Netfilter messages via NETLINK v0.30. [ 22.568023] eth0: no IPv6 routers present [ 24.229825] device eth0 entered promiscuous mode [ 260.098704] device eth0 left promiscuous mode [ 1222.481295] r8169 :02:07.0: eth0: link down [ 1222.481308] r8169 :02:07.0: eth0: link down [ 1222.481564] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 1225.543046] r8169 :02:07.0: eth0: link up [ 1225.543248] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1235.824012] eth0: no IPv6 routers present lspci shows: 02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 20 I/O ports at e000 [size=256] Memory at fbff9c00 (32-bit, non-prefetchable) [size=256] Expansion ROM at fbfc [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Kernel driver in use: r8169 Regards Karsten -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools0.109.1 ii linux-image-3.2.0-4-486 [linux-image] 3.2.41-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705912: edfbrowser: new upstream (1.50) available
Package: edfbrowser Version: 1.48-1 Severity: wishlist Tags: upstream Upstream has released 1.50: http://www.teuniz.net/edfbrowser/ Please package as time permits. Thanks, Karsten -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages edfbrowser depends on: ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 edfbrowser recommends no packages. edfbrowser suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Package: icedove Version: 10.0.12-1 Severity: normal This bug still exists for 3 years now! Please refer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598379 There are many people affected by this bug mostly with no solution. For instance look here: http://crunchbang.org/forums/viewtopic.php?id=18383 Cheers Karsten -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages icedove depends on: ii debianutils 4.3.2 ii fontconfig2.9.0-7.1 ii libasound21.0.25-4 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100.2-1 ii libevent-2.0-52.0.19-stable-3 ii libffi5 3.0.10-3 ii libfontconfig12.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libhunspell-1.3-0 1.3.2-4 ii libjpeg8 8d-1 ii libnspr4 2:4.9.2-1 ii libnspr4-0d 2:4.9.2-1 ii libnss3 2:3.14.3-1 ii libnss3-1d2:3.14.3-1 ii libpango1.0-0 1.30.0-1 ii libpixman-1-0 0.26.0-4 ii libsqlite3-0 3.7.13-1 ii libstartup-notification0 0.12-1 ii libstdc++64.7.2-5 ii libvpx1 1.1.0-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxrender1 1:0.9.7-1 ii libxt61:1.1.3-1 ii psmisc22.19-1+deb7u1 ii zlib1g1:1.2.7.dfsg-13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Hello Carsten Am 22.04.2013 11:06, schrieb Carsten Schoenert: hmm, there is no need to open a new bug for an already existing issue so I merge this two bugs together. Yes - but my try to update the version fails. ;-) As far as I remember the sound notification work with KDE, but I will check it next time. How can i debug this? The error should be searched where it occurs or not? Maybe I just turn this off, because I don't need this. Regards Carsten That's maybe the problem. In the forum they said it is not compiled correctly with the right suppport of sound and external links. When you are waiting for mail response it is very helpful to get an acoustic sign for incoming mails when you are not working on the screen the whole time. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Am 18.04.2013 11:35, schrieb Johan Hovold: I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. But where the data has gone? With cutecom i can see that some of the first bytes are looped back. It must be possible to read any binary (streamed) data. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Hmmn - i don't know which method is used by programs like cutecom or putty? But i know everything works fine before. In this programs every data is terminated with newline, but it does not work. I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Here you can see what's initialized in Perl: use Device::SerialPort 0.12; $port-baudrate(9600) || die failed setting baudrate; $port-parity(none)|| die failed setting parity; $port-databits(8) || die failed setting databits; $port-handshake(none) || die failed setting handshake; $port-write_settings|| die could not write settings; $port-lookclear || die could not empty buffer; $port-read_char_time(0);# don't wait for each character $port-read_const_time(1000);# 1 second per unfulfilled read call my $STALL_DEFAULT = 1;# how many seconds to wait for new input Cheers Karsten Johan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Am 18.04.2013 12:56, schrieb Johan Hovold: Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. This was a log with lost data. The logs seems to make politics. ;-) How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p/sys/kernel/debug/dynamic_debug/control echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control Johan Sorry - this does not work for me? root@PC# mount -t debugfs none /sys/kernel/debug root@PC# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755) /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) none on /sys/kernel/debug type debugfs (rw,relatime) root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht gefunden root@PC# ls -l /sys/kernel/debug insgesamt 0 drwx-- 14 root root 0 Apr 19 10:27 . drwxr-xr-x 6 root root 0 Apr 19 10:27 .. drwxr-xr-x 2 root root 0 Apr 19 10:27 acpi drwxr-xr-x 17 root root 0 Apr 19 10:27 bdi drwxr-xr-x 2 root root 0 Apr 19 10:27 extfrag -r--r--r-- 1 root root 0 Apr 19 10:27 gpio drwxr-xr-x 4 root root 0 Apr 19 10:27 hid drwxr-xr-x 2 root root 0 Apr 19 10:27 kprobes drwxr-xr-x 2 root root 0 Apr 19 10:27 kvm drwxr-xr-x 2 root root 0 Apr 19 10:27 mce drwxr-xr-x 2 root root 0 Apr 19 10:27 regmap drwxr-xr-x 3 root root 0 Apr 19 10:27 regulator -rw-r--r-- 1 root root 0 Apr 19 10:27 sched_features -r--r--r-- 1 root root 0 Apr 19 10:27 suspend_stats drwxr-xr-x 5 root root 0 Apr 19 10:27 tracing drwxr-xr-x 2 root root 0 Apr 19 10:27 usb -r--r--r-- 1 root root 0 Apr 19 10:27 wakeup_sources drwxr-xr-x 2 root root 0 Apr 19 10:27 x86 Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Hi Johan, Am 19.04.2013 11:04, schrieb Johan Hovold: This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Stop - it's really possible that i send not enough bytes. Sometimes up to 6 Bytes will come back. This time i send this string (3.2.0): 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n I get back the first 3 Bytes of it. Log is attached. Before closing the connection Perl sends a 'stty -aF /dev/ttyUSB0' and prints the result: speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 16; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke canonical-mode is not enabled and I get back 3 bytes - so data is not lost complete. With cutecom it's -icanon also. So everything should be fine. There are 2 beasty questions left: 1. Why it works with PL2303H ? 2. Why i receive sometimes the first bytes? Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I learned much in kernel testing the last time ... :-) Maybe there is a HowTo for the bisect testing? Your kernel is not configured to use dynamic debugging. You need to enable CONFIG_DYNAMIC_DEBUG=y. Oh - then i must compile again. I found # CONFIG_DYNAMIC_DEBUG is not set in .config. Johan Karsten [ 1443.104346] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install [ 1443.104363] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0 [ 1443.104366] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - port 0 [ 1443.104581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0 0 [ 1443.106606] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0 0 [ 1443.106619] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0 [ 1443.108584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1443.108594] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8 [ 1443.108603] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600 [ 1443.108611] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600 [ 1443.108618] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1 [ 1443.108625] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none [ 1443.110595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0 7 [ 1443.112584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1443.114595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0 0 [ 1443.114605] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb [ 1443.114627] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb [ 1443.116581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0 [ 1443.116821] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1443.116832] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 1443.116841] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 1443.116903] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1443.116913] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
Bug#704242: Driver for PL-2303 HX not working
Am 17.04.2013 15:13, schrieb Johan Hovold: Can you try to reproduce this on a later kernel (e.g. 3.8) which uses dynamic debugging? I have compiled a 3.8.5 kernel now on Debian testing (wheezy). The result is the same as in 3.2.0 ! I could receive only some of the first bytes after opening the port afterwards everything is lost without errors. How can i enable the debugging in kernel 3.8.5? root@PC# modprobe usbserial debug=1 ERROR: could not insert 'usbserial': Invalid argument root@PC# modprobe pl2303 debug=1 ERROR: could not insert 'pl2303': Invalid argument Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Am 17.04.2013 15:13, schrieb Johan Hovold: The logs look incomplete. It's probably because they're flooded with serial_write_room and chars_in_buffer messages. Hmmm - i feared that this happens - the logs where to big. Can you try to reproduce this on a later kernel (e.g. 3.8) which uses dynamic debugging? I will try to compile a kernel 3.8.5 like this way: http://verahill.blogspot.de/2013/02/342-compiling-kernel-38-on-debian.html But this will take some time ... Can you minimise your test setup using a custom program which only opens the device, initialises it, writes the four characters (e.g. test) and reads them back (over you hardwired loop) before closing the device again? I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Make sure to verify it using a working device first. I use this script with a ch341 adapter and it works. Thanks, Johan Cheers Karsten [ 1714.545685] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install [ 1714.545704] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0 [ 1714.545708] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - port 0 [ 1714.546283] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0 0 [ 1714.548272] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0 0 [ 1714.548276] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0 [ 1714.550281] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1714.550284] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8 [ 1714.550287] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600 [ 1714.550289] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600 [ 1714.550291] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1 [ 1714.550292] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none [ 1714.552272] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0 7 [ 1714.554290] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1714.556270] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0 0 [ 1714.556283] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb [ 1714.556305] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb [ 1714.557255] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_read_int_callback (0) [ 1714.557261] pl2303 ttyUSB0: pl2303_read_int_callback - length = 10, data = a1 20 00 00 00 00 02 00 8b 00 [ 1714.557271] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_handle_dcd_change - port 0, status 1 [ 1714.558284] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0 [ 1714.558522] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1714.558534] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 1714.558543] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 1714.558604] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1714.558613] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 1714.558622] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 1714.558856] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1714.558866] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 1714.558875] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 1714.558886] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c
Bug#704242: Driver for PL-2303 HX not working
Hi, Hi, Fri, 12 Apr 2013, 9:43 +02:00 from Karsten Malcher deb...@dct.mine.nu: Very strange. As i have written i have an old mobile adapter with PL2303 H that's running without no problem in Linux. I suppose it's a genuine one :) It seems so. There are adapters with HL-340 chip (ID 1a86:7523), that are running without problems in Linux too. It's not a PL-2303 clone, but a different device; ch341 kernel module is used for it. Yes - but here the cheap china devices are working. But often you don't know which chip you get when you buy an adapter. By the way, have you tried to do the simple loopback test? No - but now i tested it with 9600 baud. The result is the same. No input over RXD without any debug message. Just connect Rx Tx pins together, try to send something and check what's received, e. g. with help of some terminal application. Here the debug output opening TTYUSB0: [ 3476.251300] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - port 0 [ 3476.252276] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0 0 [ 3476.254283] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0 0 [ 3476.254295] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0 [ 3476.256271] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 3476.256281] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8 [ 3476.256290] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600 [ 3476.256298] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600 [ 3476.256306] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1 [ 3476.256313] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none [ 3476.258281] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0 7 [ 3476.260269] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 3476.262282] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0 0 [ 3476.262293] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb [ 3476.262315] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb [ 3476.264258] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_read_int_callback (0) [ 3476.264263] pl2303 ttyUSB0: pl2303_read_int_callback - length = 10, data = [ 3476.264272] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0 [ 3476.264284] a1 20 00 00 00 00 02 00 8b 02 [ 3476.264302] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x540b [ 3476.264311] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x540b [ 3476.264327] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 3476.264335] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 3476.264345] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 3476.264353] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 3476.264365] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 3476.264373] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 3476.264381] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5402 [ 3476.264389] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5402 [ 3476.264399] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0 [ 3476.264409] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 3476.264417] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
Bug#704242: Driver for PL-2303 HX not working
: 0x40:0x1:0x404:0x0 0 [ 1863.394045] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 0 [ 1863.394169] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0 1 - 0 [ 1863.394293] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 0 [ 1863.394419] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x404:0x1 0 [ 1863.394544] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 0 [ 1863.394700] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0 1 - 0 [ 1863.394913] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x1 0 [ 1863.395038] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x1:0x0 0 [ 1863.395162] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x2:0x24 0 [ 1863.395269] usb 1-2.3: pl2303 converter now attached to ttyUSB0 I added the output of lsusb -v too. Cheers Karsten Bus 001 Device 018: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice2.02 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice3.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer
Bug#704242: Driver for PL-2303 HX not working
Package: src:linux Version: 3.2.23-1 Severity: important Hello, i have the problem that i have nearly no serial communication with a USB-Serial-Adapter type PL-2303 HX. The interesting point is that i have an older adapter and this is working without problems. When you use the check tool of profilic the running chip is identified as PL-2303 H Chip. The chip not running is a Pl-2303 XA / HXA. Exact type is Pl-2303HX LF12313A or LF13313A Both are identified as ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port When you connect the adapter everything looks fine. It is recognized and attached as ttyUSB0. But the PL-2303HX does not receive data! Sometimes you get only some bytes directly after connection of the serial device and then nothing. I checked the input of the chip, the signal is clear and perfect. It is the same result with 2 different adapter of the same type. The sending of data is no problem, that's working. Maybe you can refer also to this reported problems: http://ubuntuforums.org/showthread.php?t=1580150 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321 Regards Karsten -- Package-specific info: ** Version: Linux version 3.2.0-3-amd64 (Debian 3.2.23-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Mon Jul 23 02:4$ ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [ 3497.136623] usb 1-2.3: new full-speed USB device number 14 using ehci_hcd [ 3497.245697] usb 1-2.3: New USB device found, idVendor=067b, idProduct=2303 [ 3497.245708] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 3497.245716] usb 1-2.3: Product: USB-Serial Controller [ 3497.245721] usb 1-2.3: Manufacturer: Prolific Technology Inc. [ 3497.246184] pl2303 1-2.3:1.0: pl2303 converter detected [ 3497.247748] usb 1-2.3: pl2303 converter now attached to ** Model information sys_vendor: To Be Filled By O.E.M. product_name: To Be Filled By O.E.M. product_version: To Be Filled By O.E.M. chassis_vendor: To Be Filled By O.E.M. chassis_version: To Be Filled By O.E.M. bios_vendor: American Megatrends Inc. bios_version: P1.10 board_vendor: ASRock board_name: M3A770DE board_version: ** Loaded modules: pl2303 pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) ppdev lp vboxdrv(O) snd_hrtimer cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats fuse ext3 jbd w83627ehf hwmon_vid loop snd_hda_codec_hdmi nvidia(P) usb_storage uas ch341 snd_hda_codec_via usbserial snd_hda_intel snd_hda_codec snd_seq_midi snd_hwdep snd_seq_midi_event snd_pcm_oss snd_rawmidi snd_mixer_oss snd_pcm snd_seq snd_page_alloc sp5100_tco k10temp parport_pc i2c_piix4 snd_seq_device psmouse snd_timer parport powernow_k8 snd pcspkr serio_raw evdev mperf soundcore i2c_core edac_mce_amd wmi edac_core processor button thermal_sys ext4 crc16 jbd2 mbcache microcode usbhid hid sg sr_mod sd_mod cdrom crc_t10dif ata_generic ohci_hcd pata_atiixp floppy ahci libahci ehci_hcd r8169 libata mii usbcore scsi_mod usb_common ** PCI devices: 00:12.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI]) Subsystem: ASRock Incorporation Device [1849:4396] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 17 Region 0: Memory at fceff000 (32-bit, non-prefetchable) [size=256] Capabilities: access denied Kernel driver in use: ehci_hcd 00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Device [1849:4397] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at fcefc000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.1 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1 Controller [1002:4398] (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Device [1849:4398] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory
Bug#689025: Most probably a rsyslog configuration problem
Hi, this may be not an openldap, but a rsyslog configuration problem. We experienced this problem as well with other services (mainly mail servers) logging to rsyslog via tcp syslog when the remote loghost was not responding. To the bug reporter: Have you configured a (disk, memory or combined) queue in rsyslog? As described in http://www.rsyslog.com/doc/queues.html, this is the recommended setup to deal with such outages. If no, this bug can probably be closed. Best Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701153: llvm-dev: LLVM/Clang packages in Wheezy Beta4 are missing files
Package: llvm-dev Severity: normal I'm having issues with the LLVM/Clang packages in Debian Wheezy Beta4. It seems these packages are missing files that I can only obtain when building LLVM/Clang myself. I'd rather use Debian's packages, and so I am wondering if these files can be included in either an existing or a new dev package. The files I am referring to are the LLVM cmake modules - applications that build custom LLVM passes require the LLVM cmake modules during the build process. For llvm-3.2, the files I'm referring to exist in: llvm-3.2.src/cmake/modules/*.cmake And after building LLVM/Cmake like this: wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz tar xaf llvm-3.2.src.tar.gz tar xaf clang-3.2.src.tar.gz cp -R clang-3.2.src llvm-3.2.src/tools/clang cd llvm-3.2.src/ mkdir build cd build/ cmake -DCMAKE_INSTALL_PREFIX=/home/karsten/.local ../. make make install the files are then installed to: /home/karsten/.local/share/llvm/cmake/*.cmake Neither the llvm or llvm-dev packages contain these files. Is there an existing package that I am missing that contains these files? Otherwise, does it make sense to include these files in the llvm-dev package? -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686376: ginkgocadx: this is a non-issue
Package: ginkgocadx Followup-For: Bug #686376 This is a non-issue. When Ginkgo-CADx is started it will show a start page in the right hand side (if so configured - and that's the default). On the right hand side, normally images are displayed in tabs. Ginkgo-CADx does not close as long as an image is open on the right hand side. In this case the start page. Yes, this is unfortunate programming (especially since there's no feedback) but, no, it is NOT a bug. Please close this report unless the original poster shows instructions to replicate the reported behaviour independant of the above explanation. Karsten -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ginkgocadx depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-37 ii libcairo2 1.12.2-2 ii libdcmtk2 3.6.0-12 ii libfftw3-33.3.2-3.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdcm2.22.2.0-13 ii libgdk-pixbuf2.0-02.26.1-1 ii libgl1-mesa-glx [libgl1] 8.0.5-3 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libinsighttoolkit3.20 3.20.1+git20120521-3 ii libpango1.0-0 1.30.0-1 ii libpng12-01.2.49-1 ii libsqlite3-0 3.7.13-1 ii libssl1.0.0 1.0.1c-4 ii libstdc++64.7.2-5 ii libtiff5 4.0.2-5 ii libvtk5.8 5.8.0-13+b1 ii libwrap0 7.6.q-24 ii libwxbase2.8-02.8.12.1-12 ii libwxgtk2.8-0 2.8.12.1-12 ii libxml2 2.8.0+dfsg1-7 ii zlib1g1:1.2.7.dfsg-13 ginkgocadx recommends no packages. ginkgocadx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688952: ginkgocadx: seems resolved
Package: ginkgocadx Version: 2.12.0.4889-1 Followup-For: Bug #688952 This problem seems resolved with the upstream release 3.1.0. Citing from their README: Ginkgo CADx Project Changelog www.ginkgo-cadx.com Version 3.1.0 (2012-12-12) --- ... * wrong LGPL3 aditional clause removed Please close this bug if you agree. Thanks, Karsten -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ginkgocadx depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-37 ii libcairo2 1.12.2-2 ii libdcmtk2 3.6.0-12 ii libfftw3-33.3.2-3.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdcm2.22.2.0-13 ii libgdk-pixbuf2.0-02.26.1-1 ii libgl1-mesa-glx [libgl1] 8.0.5-3 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libinsighttoolkit3.20 3.20.1+git20120521-3 ii libpango1.0-0 1.30.0-1 ii libpng12-01.2.49-1 ii libsqlite3-0 3.7.13-1 ii libssl1.0.0 1.0.1c-4 ii libstdc++64.7.2-5 ii libtiff5 4.0.2-5 ii libvtk5.8 5.8.0-13+b1 ii libwrap0 7.6.q-24 ii libwxbase2.8-02.8.12.1-12 ii libwxgtk2.8-0 2.8.12.1-12 ii libxml2 2.8.0+dfsg1-7 ii zlib1g1:1.2.7.dfsg-13 ginkgocadx recommends no packages. ginkgocadx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686376: ginkgocadx: this is a non-issue
Sorry this should have been attached to #684990 Please re-assign. Thanks, Karsten On Sun, Jan 27, 2013 at 01:36:48PM +0100, Karsten Hilbert wrote: Package: ginkgocadx Followup-For: Bug #686376 This is a non-issue. When Ginkgo-CADx is started it will show a start page in the right hand side (if so configured - and that's the default). On the right hand side, normally images are displayed in tabs. Ginkgo-CADx does not close as long as an image is open on the right hand side. In this case the start page. Yes, this is unfortunate programming (especially since there's no feedback) but, no, it is NOT a bug. Please close this report unless the original poster shows instructions to replicate the reported behaviour independant of the above explanation. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686376: ginkgocadx: Upstream 3.1.0 available
Package: ginkgocadx Version: 2.12.0.4889-1 Followup-For: Bug #686376 Upstream has release 3.1.0. This - among fixing bugs - resolves the inaccurate licensing. Uploading to experimental would be beneficial to users as they can use this version even before Testing becomes stable (it runs just fine on Testing AFAICT). Please package as time permits. Thanks, Karsten -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ginkgocadx depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-37 ii libcairo2 1.12.2-2 ii libdcmtk2 3.6.0-12 ii libfftw3-33.3.2-3.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdcm2.22.2.0-13 ii libgdk-pixbuf2.0-02.26.1-1 ii libgl1-mesa-glx [libgl1] 8.0.5-3 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libinsighttoolkit3.20 3.20.1+git20120521-3 ii libpango1.0-0 1.30.0-1 ii libpng12-01.2.49-1 ii libsqlite3-0 3.7.13-1 ii libssl1.0.0 1.0.1c-4 ii libstdc++64.7.2-5 ii libtiff5 4.0.2-5 ii libvtk5.8 5.8.0-13+b1 ii libwrap0 7.6.q-24 ii libwxbase2.8-02.8.12.1-12 ii libwxgtk2.8-0 2.8.12.1-12 ii libxml2 2.8.0+dfsg1-7 ii zlib1g1:1.2.7.dfsg-13 ginkgocadx recommends no packages. ginkgocadx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640851: evolution: local mail files no longer accessible
Because of this bug i updated to 3.6.1-1 from experimental - it didn't help. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691560: IvyBridge: Gnome in fallback mode
On Tue, 2013-01-08 at 18:32 +0100, Julien Cristau wrote: Oh also can you upgrade libdrm-intel1 to 2.4.40, see if that makes any difference. This forced me to update libdrm2 too. Installed the versions form unstable (2.4.40-1~deb7u2 respectively) Now i works great. Thank You! Karsten signature.asc Description: This is a digitally signed message part
Bug#691560: IvyBridge: Gnome in fallback mode
The same problem with kernel 3.7.1-1~experimental.2 and driver 2:2.20.14-1 from experimental. There are less distortions on the screen than before, but changing VT does not work. [12.906] X.Org X Server 1.12.4 Release Date: 2012-08-27 [12.906] X Protocol Version 11, Revision 0 [12.906] Build Operating System: Linux 3.2.0-4.drm-amd64 x86_64 Debian [12.906] Current Operating System: Linux schnattchen 3.7-trunk-amd64 #1 SMP Debian 3.7.1-1~experimental.2 x86_64 [12.906] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7-trunk-amd64 root=UUID=b40b1a73-1fc8-4fde-990a-cf74eed016e3 ro quiet [12.906] Build Date: 29 November 2012 07:18:16PM [12.906] xorg-server 2:1.12.4-4 (Julien Cristau jcris...@debian.org) [12.906] Current version of pixman: 0.26.0 [12.906] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [12.906] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [12.906] (==) Log file: /var/log/Xorg.1.log, Time: Tue Jan 8 17:07:20 2013 [12.906] (==) Using system config directory /usr/share/X11/xorg.conf.d [12.907] (==) No Layout section. Using the first Screen section. [12.907] (==) No screen section available. Using defaults. [12.907] (**) |--Screen Default Screen Section (0) [12.907] (**) | |--Monitor default monitor [12.907] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [12.907] (==) Automatically adding devices [12.907] (==) Automatically enabling devices [12.907] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [12.907] Entry deleted from font path. [12.907] (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist. [12.907] Entry deleted from font path. [12.907] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [12.907] (==) ModulePath set to /usr/lib/xorg/modules [12.907] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [12.907] (II) Loader magic: 0x7f02045c3ae0 [12.907] (II) Module ABI versions: [12.907] X.Org ANSI C Emulation: 0.4 [12.907] X.Org Video Driver: 12.1 [12.907] X.Org XInput driver : 16.0 [12.907] X.Org Server Extension : 6.0 [12.907] (--) PCI:*(0:0:2:0) 8086:016a:8086:201c rev 9, Mem @ 0xfdc0/4194304, 0xe000/268435456, I/O @ 0xf000/64 [12.907] (II) Open ACPI successful (/var/run/acpid.socket) [12.907] (II) LoadModule: extmod [12.908] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [12.908] (II) Module extmod: vendor=X.Org Foundation [12.908] compiled for 1.12.4, module version = 1.0.0 [12.908] Module class: X.Org Server Extension [12.908] ABI class: X.Org Server Extension, version 6.0 [12.908] (II) Loading extension SELinux [12.908] (II) Loading extension MIT-SCREEN-SAVER [12.908] (II) Loading extension XFree86-VidModeExtension [12.908] (II) Loading extension XFree86-DGA [12.908] (II) Loading extension DPMS [12.908] (II) Loading extension XVideo [12.908] (II) Loading extension XVideo-MotionCompensation [12.908] (II) Loading extension X-Resource [12.908] (II) LoadModule: dbe [12.908] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [12.908] (II) Module dbe: vendor=X.Org Foundation [12.908] compiled for 1.12.4, module version = 1.0.0 [12.908] Module class: X.Org Server Extension [12.908] ABI class: X.Org Server Extension, version 6.0 [12.908] (II) Loading extension DOUBLE-BUFFER [12.908] (II) LoadModule: glx [12.908] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [12.908] (II) Module glx: vendor=X.Org Foundation [12.908] compiled for 1.12.4, module version = 1.0.0 [12.908] ABI class: X.Org Server Extension, version 6.0 [12.908] (==) AIGLX enabled [12.908] (II) Loading extension GLX [12.908] (II) LoadModule: record [12.908] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [12.908] (II) Module record: vendor=X.Org Foundation [12.908] compiled for 1.12.4, module version = 1.13.0 [12.908] Module class: X.Org Server Extension [12.908] ABI class: X.Org Server Extension, version 6.0 [12.908] (II) Loading extension RECORD [12.908] (II) LoadModule: dri [12.908] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [12.908] (II) Module dri: vendor=X.Org Foundation [12.908] compiled for 1.12.4, module version = 1.0.0 [12.908] ABI class: X.Org Server Extension, version 6.0 [12.908]
Bug#695762: python-psycopg2: new 2.4.6 bug-fix only upstream release available
Package: python-psycopg2 Version: 2.4.5-1 Severity: wishlist Tags: upstream Upstream has released 2.4.6 which is declared bug-fix only. Here's the release announcement: http://web.archiveorange.com/archive/v/ZbQiGLotb3e3b7Ph1N3i Thanks a lot, Karsten -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-psycopg2 depends on: ii libc6 2.13-37 ii libpq5 9.1.6-1 ii python 2.7.3~rc2-1 ii python2.7 2.7.3~rc2-2.1 Versions of packages python-psycopg2 recommends: ii python-egenix-mxdatetime 3.2.1-1.1 Versions of packages python-psycopg2 suggests: pn python-psycopg2-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693620: [Pkg-opt-media-team] Bug#693620: dvdisaster does not start
Hi Carsten, Am 19.11.2012 20:13, schrieb Carsten Gnörlich: Rogério already summed it up perfectly. Just to add some more technical info: It's not too uncommon to see a drive freeze in midst of fulfilling a SCSI request on faulty media due to bugs in its firmware. While this may freeze the calling application and maybe even the whole system if one was unlucky enough to have the root file system on the same SCSI subsystem, remedy is usually possible by a) pushing eject on the drive, which is totally unspecified and unexpected behaviour, but may actually reset the drive and abort the stuck SCSI command; or by In my case this does not help. b) simply waiting for the SCSI timeout specified by the application. When the timeout is reached, the kernel will abort and unlock the failed command, and the system will come back to life again. I would say i have waited for about 5 minutes. Before i shutdown the system i tested if the processes still exists. None of the processes did disappear. On dvdisaster the timeout is 10min. While this might seem a high value, please resist the temptation to fiddle with it. O.K. In Karstens case, the drive was probably already stuck before calling dvdisaster. Yes - of course - the first thing i tried was just to read the CD. But the CD was so bad that it was not recognized. It was my second idea to use dvdisaster to check the CD. I tested the CD on 3 different drives and i could read it only on the 4th drive. Yesterday it was possible to read the file on the first drive, that's really interesting. Since dvdisaster queries all connected drives for some of their properties while preparing its main window, it hung up right off the box. In command line mode, the failure would probably have been deferred until the first read operation. But anyways, these are really firmware bugs which can only be corrected by the drive manufacturer, and neither the kernel nor dvdisaster can work around them in a meaningful way. It's very simple why i rise this bug. I give up to use CD's and DVD's, because they are more expensive and reliable than hard disks. The other thing is that my DVD-burner GH22NP20 has give up to write after only a few DVD's in 2 years. So the last time i use dvdisaster was on debian squeeze. I assumed that it was not working any more after my upgrade to wheezy. That's all. Greetings, Carsten Thank you all for your advise. Cheers Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693620: Fwd: dvdisaster does not start
Hi Michael, i could not believe it, but today the application is running without problems. Seems not to run on sundays. :-) Yesterday i inserted a CD that is nearly impossible to read. Maybe the device was somehow blocked after this, so that the program did not start. Today i can't reproduce this. So please close the bug. Best regards Karsten Am 18.11.2012 23:33, schrieb Michael Gilbert: Hi, I've just tested this, and it works fine for me. Could you post a debugging backtrace and an strace? $ gdb dvdisaster run backtrace karsten@PC:/tmp$ gdb dvdisaster GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/dvdisaster...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/dvdisaster [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. backtrace[Inferior 1 (process 4945) exited normally] (gdb) (gdb) backtrace No stack. $ strace dvdisaster Thanks, Mike execve(/usr/bin/dvdisaster, [dvdisaster], [/* 39 vars */]) = 0 brk(0) = 0x1b53000 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1a54169000 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory) open(/etc/ld.so.cache, O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=154236, ...}) = 0 mmap(NULL, 154236, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1a54143000 close(3)= 0 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) open(/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0, O_RDONLY) = 3 read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0@\7\0\0\0\0\0\0..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=6120, ...}) = 0 mmap(NULL, 2101288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1a53d4a000 mprotect(0x7f1a53d4b000, 2093056, PROT_NONE) = 0 mmap(0x7f1a53f4a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f1a53f4a000 close(3)= 0 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) open(/lib/x86_64-linux-gnu/librt.so.1, O_RDONLY) = 3 read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\220!\0\0\0\0\0\0..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=31744, ...}) = 0 mmap(NULL, 2128856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1a53b42000 mprotect(0x7f1a53b49000, 2093056, PROT_NONE) = 0 mmap(0x7f1a53d48000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f1a53d48000 close(3)= 0 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) open(/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0, O_RDONLY) = 3 read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200;\7\0\0\0\0\0..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=4442248, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1a54142000 mmap(NULL, 6546664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1a53503000 mprotect(0x7f1a53935000, 2097152, PROT_NONE) = 0 mmap(0x7f1a53b35000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x432000) = 0x7f1a53b35000 mmap(0x7f1a53b4, 5352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1a53b4 close(3)= 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693620: [Pkg-opt-media-team] Bug#693620: dvdisaster does not start
Hi, Am 19.11.2012 01:03, schrieb Rogério Brito: Hi. On Nov 18 2012, Karsten Malcher wrote: i just tried to use dvdisaster - without success. The application just hangs and does not start. Every process i started could not be killed manually with kill -9 ! If a given process doesn't get killed even with signal 9, then it is probably the case that the process is in the D state and the kernel is waiting for some device (or IO) to fulfill a request. In this case this must have happen. Are you trying to create the image of a badly scratched CD/DVD? Yes - but this CD was nearly fresh burned without any visible defects. What if you do the same operations without dvdisaster? Say, what if you create the image with ddrescue? Do you still get uninterruptible processes? For one time i was able to read the CD. There is only one file with 20 MB on it. It seems to be pure accident when this problem happens. Unfortunately, I can't reproduce this myself and I see that Michael has already tagged this as unreproducible and moreinfo, which is certainly appropriate here, as we have too few details to continue debugging. Regards, Yes - this is only one of this crazy one-time-bugs. Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693620: dvdisaster does not start
Package: dvdisaster Version: 0.72.4-1 Justification: renders package unusable Severity: grave Hello, i just tried to use dvdisaster - without success. The application just hangs and does not start. Every process i started could not be killed manually with kill -9 ! Best regards Karsten -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dvdisaster depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgtk2.0-0 2.24.10-2 ii libpango1.0-0 1.30.0-1 ii xdg-utils 1.1.0~rc1+git20111210-6 Versions of packages dvdisaster recommends: ii dvdisaster-doc 0.72.4-1 dvdisaster suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel
Package: src:linux Version: 3.2.32-1 Severity: important I originally niticed the issue on Ubuntu 12.04.1, but could reproduce it on Debian as well. I upgraded a squeeze system to testing and found that NFS access creates a high load on the NFS server. A single client machine with a single write causes 40% system load, where the original load on Squeeze was 7-10% (which still is high, but might be causes by running in a test VM). My Ubuntu production server got completely killed by several clients accessing. Steps to reproduce: Server: - install vanilla Squeeze server system without Graphical UI and standard settings otherwise - install nfs-kernel-server - add to exports: /export client(rw,no_root_squash,async,subtree_check) - exportfs -a Client: - same installation, install nfs-common - mount with mount -t nfs server:/export /mnt - go to /mnt and write a file with dd if=/dev/zero of /mnt/t1 bs=1M count=1 - measure the load on the server while writing - upgrade the server to Wheezy - do the same writing test and see the load go up If I boot Wheezy to the still installed 2.6 kernel, the load goes back to normal. I have played around with different nfs export and mount options. The only change that I found was using -o proto=uds when mounting. This reduces the load to 15% which is still higher than the original load, but still much lower that 40%. Ubuntu Bug #879334 and it's duplicates report the same issues. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-12) ) #1 SMP Debian 3.2.32-1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=0f95e4ef-e796-41b1-9e14-8878428a61a4 ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [1.312867] Switching to clocksource tsc [1.461471] e1000 :00:03.0: eth0: (PCI:33MHz:32-bit) 08:00:27:f2:11:56 [1.461481] e1000 :00:03.0: eth0: Intel(R) PRO/1000 Network Connection [1.461562] ohci_hcd :00:06.0: setting latency timer to 64 [1.461574] ohci_hcd :00:06.0: OHCI Host Controller [1.461590] ohci_hcd :00:06.0: new USB bus registered, assigned bus number 1 [1.461649] ohci_hcd :00:06.0: irq 22, io mem 0xf0804000 [1.517407] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [1.517410] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.517412] usb usb1: Product: OHCI Host Controller [1.517414] usb usb1: Manufacturer: Linux 3.2.0-4-amd64 ohci_hcd [1.517415] usb usb1: SerialNumber: :00:06.0 [1.517499] hub 1-0:1.0: USB hub found [1.517511] hub 1-0:1.0: 8 ports detected [1.517926] ahci :00:0d.0: version 3.0 [1.518083] ahci: SSS flag set, parallel bus scan disabled [1.518247] ahci :00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode [1.518251] ahci :00:0d.0: flags: 64bit ncq stag only ccc [1.518273] ahci :00:0d.0: setting latency timer to 64 [1.519072] scsi0 : ahci [1.519140] ata1: SATA max UDMA/133 abar m8192@0xf0806000 port 0xf0806100 irq 21 [1.519212] ata_piix :00:01.1: version 2.13 [1.519276] ata_piix :00:01.1: setting latency timer to 64 [1.520413] scsi1 : ata_piix [1.520588] scsi2 : ata_piix [1.520627] ata2: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xd000 irq 14 [1.520630] ata3: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xd008 irq 15 [1.676448] ata3.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133 [1.676901] ata3.00: configured for UDMA/33 [1.840110] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [1.840185] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [1.840188] ata1.00: 32118784 sectors, multi 128: LBA48 NCQ (depth 31/32) [1.840284] ata1.00: configured for UDMA/133 [1.840360] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK1.0 PQ: 0 ANSI: 5 [1.840852] scsi 2:0:0:0: CD-ROMVBOX CD-ROM 1.0 PQ: 0 ANSI: 5 [1.846811] sd 0:0:0:0: [sda] 32118784 512-byte logical blocks: (16.4 GB/15.3 GiB) [1.846844] sd 0:0:0:0: [sda] Write Protect is off [1.846846] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.846860] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [1.847914] sda: sda1 sda2 sda5 [1.848330] sd 0:0:0:0: [sda] Attached SCSI disk [1.848710] sr0: scsi3-mmc drive: 32x/32x xa/form2 tray [1.848712] cdrom: Uniform CD-ROM driver Revision: 3.20 [1.848949] sr 2:0:0:0: Attached scsi CD-ROM sr0 [1.853273] sd 0:0:0:0: Attached scsi generic sg0 type 0 [1.853324] sr 2:0:0:0: Attached scsi generic sg1 type 5 [1.924105] usb 1-1: new full-speed USB device number 2 using ohci_hcd [1.961261] PM: Starting manual resume from disk [1.961264] PM: Hibernation image partition 8:5 present [1.961265] PM: Looking for hibernation image. [1.961490] PM: Image not found
Bug#692957: Typo
Sorry, I had a typo. It should have read: The only change that I found was using -o proto=udp when mounting . (instead of tcp which seems to be the default)
Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel
Is that with TCP or UDP? Made a simple mount without specifying any options. So I guess the default would be TCP because specifying UDP made a difference in previous tests, right? --Karsten
Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel
Can you also measure the speed at which the client can write, when the server is running each of the two kernel versions? If the client can write twice as fast (for example) then it should be OK to use twice as high a percentage of CPU time on the server, as the total CPU time needed for a data transfer will be the same. I tested the following combinations with 2 GB writes: Server Client Debian testing kernel 2.6Debian stable ~60 seconds Debian testing kernel 3.2Debian stable ~60 seconds Debian testing kernel 2.6Ubuntu 12.04.1 ~65 seconds Debian testing kernel 3.2Ubuntu 12.04.1 ~67 seconds It seems the speed is comparable in all cases although the load differs. In general my load number looked a bit smaller this time, maybe because the host system was freshly booted. So I guess, I should collect some numbers on an actual machine tomorrow. I also did not have a Debian testing client yet. Do you know if the patch mentioned above also affect the client? --Karsten
Bug#691560: IvyBridge: Gnome in fallback mode
On Sun, 2012-11-04 at 00:59 +0100, Julien Cristau wrote: On Sun, Oct 28, 2012 at 13:52:45 +0100, Karsten Voss wrote: updated xserver-xorg-video-intel to version 2:2.20.5-1 from experimental, and kernel to 3.2.32-1 from unstable, but the same experience. Karsten # dmesg ... [ 346.203441] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! Looks like you need a newer kernel. I have already tested with kernels 3.5 and 3.6 form experimental, but with these kernels X is absolutely unusable. X uses then fbdev driver. Screen does not refresh, up to 3 mouse cursors, switching to a different virtual console does not work... Karsten signature.asc Description: This is a digitally signed message part