On 2010-01-25 at 07:32:30 -0500, Frans Pop wrote:
> ...
> 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.
> ...
OK, I will continue to report bugs in Debian. But if you (or some other package
maintainer
> 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 relativel
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/B
I have some new information. I happened to be logged on to the virtual Linux
server's virtual console in VM while attempting to vary the device offline in
a separate remote ssh session. When I did so, I saw messages on the virtual
console like I see during boot-up when the device first comes onli
Hey, I just thought of something. The same day I installed
linux-source-2.6.26, etc., I also changed the device numbers of
the minidisks. The old device number range was 200-203, and the new device
number range is 210-213. And I didn't re-test the offline / online procedure
until AFTER I changed
> You always showed direct usage of /sys.
Yes. But since "echo" with redirection was no longer working, I thought maybe
the procedure had changed. To make sure, I invoked
chccwdev -d 0.0.0201
I figured that if the procedure had changed, chccwdev would know the new
way to get the device offline
On Tue, Sep 23, 2008 at 01:34:53PM -0400, [EMAIL PROTECTED] wrote:
> It's possible that I may have reported this bug against the wrong
> package. chccwdev is part of the s390-tools package. And chccwdev fails.
> But the actual cause of the problem may be elsewhere.
You always showed direct usage
Hi, Bastien.
> I fail to see what s390-tools or the chccwdev tools have to do with this
> problem.
It's possible that I may have reported this bug against the wrong
package. chccwdev is part of the s390-tools package. And chccwdev fails.
But the actual cause of the problem may be elsewhere.
As
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.
>
Well now, here's something strange. I just installed packages
linux-source-2.6.26, kernel-package, and libncurses5-dev, along with all
the packages that aptitude brings in with them as prerequisites and
corequisites, and now I can get the device offline dynamically! I haven't
installed a custom
I just upgraded to Debian stock kernel linux-image-2.6.26-1-s390, version
2.6.26-5, but the problem remains.
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 th
12 matches
Mail list logo
