Bug#499833: chccwdev cannot set device offline in Lenny
On 2010-01-25 at 05:58:04 +0100, Franz Pop wrote: If there still is an issue affecting current kernels, you will probably get much more response reporting it to the upstream kernel developers than with a Debian bug report. I'm just trying to follow the rules. From http://www.debian.org/Bugs/Reporting Don't file bugs upstream If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream. Given that, what are the guidelines for when to file the initial bug report directly with upstream vs. when to file a bug report with Debian? -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499833: chccwdev cannot set device offline in Lenny
Given that, what are the guidelines for when to file the initial bug report directly with upstream vs. when to file a bug report with Debian? It's mostly a question of what's most effective. The kernel team is already drowned in bug reports and has very little manpower to deal with relatively minor or very specific issue, especially not for the less popular arches. There are very few Debian-specific patches in the kernel, especially not for s390. So any s390 kernel issue is almost certain to be an upstream issue. Besides that I'm *not* saying your original report was wrong. But based on the information in it (and its lack of progress) I'm now suggesting that contacting upstream directly is probably most efficient. In this case my (not so) humble opinion as a Debian Developer is that there is zero benefit from having a DD acting as a middleman for this issue. I've done quite a lot of work with kernel upstream myself, so I think I'm a fair judge of that. So the general rule is to report bugs in Debian, but there is no rule that says a Debian Developer cannot refer you to upstream developers. Also: rules are nice, but one should always use ones own judgement. The rule is there to avoid having upstreams swamped with distro-specific issues. As we've determined that's unlikely, there's no reason not to contact them directly. The same is true if a user is himself certain an issue is upstream, especially if there's no progress on a Debian BR. The main thing is to get things done. Whatever works without annoying people (volunteers) is good in free software. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499833: chccwdev cannot set device offline in Lenny
On Mon, Sep 22, 2008 at 04:10:01PM -0400, [EMAIL PROTECTED] wrote: This works just fine in Etch, but fails in Lenny. A device cannot be taken offline dynamically. I fail to see what s390-tools or the chccwdev tools have to do with this problem. The device normally uses the dasd_diag_mod driver, but in order to get zipl to work, I have to switch to the dasd_eckd_mod driver. Just to be curious, why do operate it in diag mode then? /boot is not used in normal operation. Kernel is stock Lenny kernel linux-image-2.6.24-1-s390, Version 2.6.24-7. Lenny have 2.6.26-5. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499833: chccwdev cannot set device offline in Lenny
Package: s390-tools Version: 1.6.2-1 This works just fine in Etch, but fails in Lenny. A device cannot be taken offline dynamically. In my case, I have a separate dasd device for use as a boot partition. The device number is 0201, which Linux references as 0.0.0201. The device node name for this device is /dev/dasdb. The device has a single partition, /dev/dasdb1, is formatted using the ext3 file system, and is mounted as /boot in /etc/fstab. The device normally uses the dasd_diag_mod driver, but in order to get zipl to work, I have to switch to the dasd_eckd_mod driver. The following sequence of commands (logged in as root) is what I normally use in Etch with my custom kernel: umount /boot echo 0 /sys/bus/ccw/devices/0.0.0201/online echo 0 /sys/bus/ccw/devices/0.0.0201/use_diag echo 1 /sys/bus/ccw/devices/0.0.0201/online mount -t ext3 /dev/dasdb1 /boot . . invoke zipl (or update-initramfs, or aptitude dist-upgrade, or whatever) . umount /boot echo 0 /sys/bus/ccw/devices/0.0.0201/online echo 1 /sys/bus/ccw/devices/0.0.0201/use_diag echo 1 /sys/bus/ccw/devices/0.0.0201/online mount -t ext3 /dev/dasdb1 /boot When I do this under recent versions of Lenny, though, the device never goes offline, as verified by cat /sys/bus/ccw/devices/0.0.0201/online which still shows 1 after supposedly setting the device offline. Another way of telling is to issue cat /proc/dasd/devices which still shows the device online using the original DIAG driver. I tried using chccwdev -d 0.0.0201 also, and it says that it did it, but in reality nothing has changed. The device is still online. Just for grins, I tried setting a device offline dynamically which was using the ECKD driver, but that doesn't work either. Kernel is stock Lenny kernel linux-image-2.6.24-1-s390, Version 2.6.24-7. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
