robust mutexes
I'm not sure that this problem is debian specific, but glibc developers recommend to ask questions about the library at distro-specific place first... Since version 2.4 glibc supports robust mutexes. They work fine for me in x64 linux (and both x64/sparc solaris). But an attempt to use them on sparc with debian linux (Linux x1 2.6.26-2-sparc64 #1 Sat Mar 28 08:25:47 UTC 2009 sparc64 GNU/Linux) causes segfault. Removing robust attribute makes it work fine. Before providing other details I want to know - is it correct place to discuss such problems? Alex. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
On Thu, May 07, 2009 at 02:00:35AM +0100, Martin wrote: [...] My question is - when I find things that worked in Ubuntu sparc but not on Debian, what is the proper procedure for resolving the issue? Is there a checklist or flowchart anywhere public that should be followed when issues are found? I'm guessing the first step is probably to determine whether it's a kernel issue or an issue external to the kernel so that a bug report can be filed with the correct team (while also checking to see if the issue has already been reported), but again that's just a guess. A general procedure might be: 1. Identify which package(s) are causing the problem. 2. Attempt to identify what conditions / factors / circumstances trigger the issue. All the normal rules about writing bug reports apply. 3. File a bug report against the relevant Debian package. 4. Assist the package maintainer with any follow up queries. Sounds about right. If it's a generic kernel problem, it can be reported directly to sparcli...@vger.kernel.org, which is upstream list dedicated to the discussion of sparc kernel issues. Reporting it in Debian (against linux-2.6 package) is fine too, it just may take longer to propagate to upstream. In either case, if you feel like you are stuck and the bug is not getting enough attention, dropping a message to this list is fine. It is also very useful if you can do occasional tests of kernels in unstable or the daily builds of Debian installer, available from http://www.debian.org/devel/debian-installer If you have time and access to a version of the package that does work, it might be helpful to track down which differences are causing the problem, and if possible, submit a patch. Certainly, including a reference / pointer to the nearest version of Ubuntu package that works would be helpful. If the bug turns out to be something that is not specific to Debian and is a more general problem then the packages maintainer may forward it (upstream) to the main developers for that package. Any guidance would be greatly appreciated. Does the above help? I'm far from an expert on this; I'm just an end-user, but the above procedure has worked for me. HTH Cheers, - Martin -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: robust mutexes
On Thu, May 07, 2009 at 03:54:35PM +0400, Alexander peshkoff wrote: I'm not sure that this problem is debian specific, but glibc developers recommend to ask questions about the library at distro-specific place first... Since version 2.4 glibc supports robust mutexes. They work fine for me in x64 linux (and both x64/sparc solaris). But an attempt to use them on sparc with debian linux (Linux x1 2.6.26-2-sparc64 #1 Sat Mar 28 08:25:47 UTC 2009 sparc64 GNU/Linux) causes segfault. Removing robust attribute makes it work fine. Before providing other details I want to know - is it correct place to discuss such problems? I would suggest to contact debian-gl...@lists.debian.org first, keep in mind that Debian is currently transitioning to eglibc, so they are in better position to comment. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
Jurij Smakov wrote: On Thu, May 07, 2009 at 02:00:35AM +0100, Martin wrote: [...] My question is - when I find things that worked in Ubuntu sparc but not on Debian, what is the proper procedure for resolving the issue? Is there a checklist or flowchart anywhere public that should be followed when issues are found? I'm guessing the first step is probably to determine whether it's a kernel issue or an issue external to the kernel so that a bug report can be filed with the correct team (while also checking to see if the issue has already been reported), but again that's just a guess. A general procedure might be: 1. Identify which package(s) are causing the problem. 2. Attempt to identify what conditions / factors / circumstances trigger the issue. All the normal rules about writing bug reports apply. 3. File a bug report against the relevant Debian package. 4. Assist the package maintainer with any follow up queries. Sounds about right. If it's a generic kernel problem, it can be reported directly to sparcli...@vger.kernel.org, which is upstream list dedicated to the discussion of sparc kernel issues. Reporting it in Debian (against linux-2.6 package) is fine too, it just may take longer to propagate to upstream. In either case, if you feel like you are stuck and the bug is not getting enough attention, dropping a message to this list is fine. It is also very useful if you can do occasional tests of kernels in unstable or the daily builds of Debian installer, available from http://www.debian.org/devel/debian-installer If you have time and access to a version of the package that does work, it might be helpful to track down which differences are causing the problem, and if possible, submit a patch. Certainly, including a reference / pointer to the nearest version of Ubuntu package that works would be helpful. If the bug turns out to be something that is not specific to Debian and is a more general problem then the packages maintainer may forward it (upstream) to the main developers for that package. Martin/Jurij, Thanks for the guidelines, I really appreciate it. One current concern (which I've brought up in the past but probably didn't follow proper procedure) is still the conflict between the tulip and dmfe ethernet kernel modules on both the Sun Netra X1 and Sunfire V100 platforms, as well as their eth0/eth1 numbering being swapped - which neither issue exists with Ubuntu. I haven't tested the latest unstable or daily builds of Debian though nor have I looked into detail how Ubuntu went about resolving the issue. I'll follow the guidelines above and see what can be done. Thanks again, Brian -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
- Original Message - From: Brian Thompson br...@eng.wayne.edu To: Jurij Smakov ju...@wooyd.org; Martin inku...@interalpha.co.uk Cc: debian-sparc@lists.debian.org Sent: Thursday, May 07, 2009 3:01 PM Subject: Re: sparc/debian/linux procedures One current concern (which I've brought up in the past but probably didn't follow proper procedure) is still the conflict between the tulip and dmfe ethernet kernel modules on both the Sun Netra X1 and Sunfire V100 platforms, as well as their eth0/eth1 numbering being swapped - which neither issue exists with Ubuntu. The ethx numbering can be cured through the use of udev config files. You can force the system to give a static ethx mapping to an Ethernet card via its MAC address. Jim -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
On Thu, 07 May 2009 15:15:55 CST, Jim MacKenzie writes: The ethx numbering can be cured through the use of udev config files. You can force the system to give a static ethx mapping to an Ethernet card via its MAC address. or, if you dislike udev (like me), then nameif does that job very well, too. nameif belongs to the net-tools package, it'll certainly be installed. regards az -- + Alexander Zangerl + DSA 42BD645D + (RSA 5B586291) Fachbegriffe der Informatik, Strong international Encryption: Triple-ROT13 -- Carsten Lechte signature.asc Description: Digital Signature
