Bug#321902: tikugoku
Make your tiny lace a true symbol of your power Reesa luciuk http://fewdiscuss.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268609: lanicidi
Encourage your partner to improve your joint life Lassi ferican http://continueear.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268184: lastighe
You cant find a looser among mens with a long PE.Here is how you can be among one of those Muhammad Nudge http://www.continueear.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451859: linux-image-2.6.22-2-amd64: snd_hda_intel gives poor sound quality for Intel g33/ich9 chipset
On 2007-11-19 13:50-0700 dann frazier wrote: On Sun, Nov 18, 2007 at 02:31:01PM -0800, Alan W. Irwin wrote: Package: linux-image-2.6.22-2-amd64 Version: 2.6.22-4 Severity: normal For the Debian testing version of the snd_hda_intel kernel module, there was nothing but a hum from the speakers for the g33/ich9 Intel chipset for my ASUS P5K-V MB. After updating to the current debian unstable form of this module, I do get intelligible sound from the speakers for the first time, but there is still an audible hum which detracts from the quality of the sound. hey Alan, If you can help narrow it down a change that broke/fixed it, that would help us a great deal. See this page for suggested ways of doing this: http://wiki.debian.org/DebianKernelReportingBugs Hi Dann: The kernel version which has mostly working sound (intelligible with some hum) for the ASUS P5K-V g33/ich9 chipset is linux-image-2.6.22-2-amd64_2.6.22-4_amd64.deb. Alsa has a long track record of giving good support for Intel chipsets so I suspect it is only a matter of waiting until their support for ich9 has matured. For example, there may be some improvement in sound quality for this chipset between 2.6.22 and 2.6.23 so I do have plans to check out the sound quality from Debian experimental kernel-2.6.23 packages as suggested by Maks Attems once another major Debian distraction is out of the way. Meanwhile, however, I think this bug report is a useful status report of the current Debian support for sound for those with g33/ich9 chipsets. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451367: installation-reports: Does not allow ethernet over firewire
On Thu, 15 Nov 2007, Frans Pop wrote: On Thursday 15 November 2007, you wrote: the new stack is very promising, we will reconsider later if no eth1394 shows up, for now that's just a minor regression. No, that is not a minor regression. Half the functionality of the old drivers is missing! eth1394 is missing that is by far the less used firewire driver. the switch to the juju stack allowed to close a huge nr. of bugs. the old stack is just not supportable and never was, plus is a security nightmare. ieee1394 in fact deserves the Kbuild variable BROKEN. the new stack is aiming for feature parity, but with interface incompatibility, so the various firewire userland needs to pick up the switch. the new stack although more compact is already more stable. What discussion? I googled for it and after skimming through about 20 pages I still have not found it. What I _did_ find is several other reports of problems with the new stack, two of which complain about missing Ethernet support: - http://lists.debian.org/debian-kernel/2007/10/msg00414.html - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441206 - http://www.debianhelp.org/node/9328 i consider that smallish to the *huge* usability improvement on not having a strange firewire ethernet device to choose for your network connectivity in d-i. so no tears for it. So Google does not help. Let's check the changelog: linux-2.6 (2.6.22~rc5-1~experimental.1) experimental; urgency=low * Enable the new firewire stack labeled to be more simple and robust. -- Bastian Blank [EMAIL PROTECTED] Tue, 19 Jun 2007 17:49:52 +0200 Strange. No mention of the fact that the new stack is [1]: - experimental - not recommended for distributions by its upstream developers - has a _major_ regression in it's lack of Ethernet support - lacks userspace integration - has had only limited testing if i'm wrong, we can still enable both and start blacklisting the bad oldie one in m-i-t early enough. RH did rewrite the stack and it's main upstream developer ships it already enabled in 2 major releases fedora 7 and 8. juju has already nicely improved since the 2.6.22 inclusion, so still looks for the most promising option for the lenny release. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451367: installation-reports: Does not allow ethernet over firewire
Hello, On Tue, Nov 20, 2007 at 08:01:40PM +0100, maximilian attems wrote: eth1394 is missing that is by far the less used firewire driver. But for some people the driver used early in the installation (where a kernel rebuild is not very convenient). the switch to the juju stack allowed to close a huge nr. of bugs. the old stack is just not supportable and never was, plus is a security nightmare. ieee1394 in fact deserves the Kbuild variable BROKEN. Well, it worked fine for me, except that the version from 2.4 could not interoperate with the version from 2.6. The only minor oddity was that sometimes the logs were flooded with certain warnings (I can dig them out if necessary). i consider that smallish to the *huge* usability improvement on not having a strange firewire ethernet device to choose for your network connectivity in d-i. so no tears for it. Well, I cannot really argue with you on technical merits, but then it was one of the (long) supported options for d-i, so please *document* it properly. I would've started out with an Etch image, if I had known this regression. RH did rewrite the stack and it's main upstream developer ships it already enabled in 2 major releases fedora 7 and 8. juju has already nicely improved since the 2.6.22 inclusion, so still looks for the most promising option for the lenny release. It would be great if also eth1394 would reappear in the new stack, especially since the original developer is an @debian.org person. Greetings Helge -- Dr. Helge Kreutzmann [EMAIL PROTECTED] Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#451367: installation-reports: Does not allow ethernet over firewire
On Tue, Nov 20, 2007 at 08:01:40PM +0100, maximilian attems wrote: What discussion? I googled for it and after skimming through about 20 pages I still have not found it. What I _did_ find is several other reports of problems with the new stack, two of which complain about missing Ethernet support: - http://lists.debian.org/debian-kernel/2007/10/msg00414.html - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441206 - http://www.debianhelp.org/node/9328 i consider that smallish to the *huge* usability improvement on not having a strange firewire ethernet device to choose for your network connectivity in d-i. so no tears for it. The device was listed in d-i because people were using it. This thread is here because they can no longer do so. It's rather rude of you to declare that it's ok for the kernel team to fix usability issues in the installer by removing functionality from the kernel. I understand the technical arguments regarding the replacement of the stack, and have no informed position on this bigger issue (though it seems that plenty of people have been using the previous stack without complaint?), but that doesn't make it ok that functionality has been dropped, whether or not you happen to like that functionality. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451367: installation-reports: Does not allow ethernet over firewire
On Tue, Nov 20, 2007 at 08:32:44PM +0100, Helge Kreutzmann wrote: It would be great if also eth1394 would reappear in the new stack, especially since the original developer is an @debian.org person. you seem to have a strange confidence in someone, whose stack went so badly down the road, but yeah an upstream push for firewire juju eth1394 is best for all. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451025: marked as done (ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen, when smartd starts)
Your message dated Tue, 20 Nov 2007 21:12:46 +0100 with message-id [EMAIL PROTECTED] and subject line [solved] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: linux-image-2.6.22-2-amd64 Version: 2.6.22-4 Severity: normal When smartd starts up the kernel logs a lot of exceptions. Smartd can only collect information from /dev/sda, not from /dev/sdb. HDD information for /dev/sda and /dev/sdb: ATA device, with non-removable media Model Number: WDC WD5000ABYS-01TNA0 Serial Number: WD-WCAPW[snipped] Firmware Revision: 12.01C01 Storage Controller: IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE [8086:27c0] (rev 01) (prog-if 8f [Master SecP SecO PriP PriO]) on a Supermicro PDSMU board. -- Package-specific info: ** Version: Linux version 2.6.22-2-amd64 (Debian 2.6.22-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)) #1 SMP Fri Aug 31 02:15:40 UTC 2007 ** Not tainted ** Kernel log: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 123392 in res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 123392 in res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 123392 in res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 123392 in res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 123392 in res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 123392 in res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 126976 in res 50/00:f8:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 126976 in res 50/00:f8:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 126976 in res 50/00:f8:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 126976 in res 50/00:f8:00:4f:c2/00:00:00:00:00/00 Emask 0x202 (HSM violation) ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00
Bug#451367: installation-reports: Does not allow ethernet over firewire
On Tue, Nov 20, 2007 at 11:50:58AM -0800, Steve Langasek wrote: The device was listed in d-i because people were using it. This thread is here because they can no longer do so. It's rather rude of you to declare that it's ok for the kernel team to fix usability issues in the installer by removing functionality from the kernel. as i mentioned on the mail announcing the switch eth1394 might go missing for a while, if it doesn't reappear soon enough for lenny, the m-i-t blacklisting of the old stack seems an easy way to get it back. and yes i have seen quite a lot of people stumble on that dialogue. I understand the technical arguments regarding the replacement of the stack, and have no informed position on this bigger issue (though it seems that plenty of people have been using the previous stack without complaint?), but that doesn't make it ok that functionality has been dropped, whether or not you happen to like that functionality. plenty of people have left *lots* of bug reports on ieee1394. it is trivialy easy to crash any box as user with it. it's buggyness was the reason for rh to sponsor the rewrite. also it's sysfs device name support is quite lacking afair. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
