FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 05-21-2010, 03:32 PM
Stephen Powell
 
Default Bug#582281: Promised utility now available

As promised in my original post, I have written a little
utility program to zap the disk labels of minidisks corrupted
by this bug. Running it against all affected disks will allow
existing data to be accessed safely by both types of Linux kernels:
those that have the bug and those that have the fix applied.
The utility can be found here:

http://www.wowway.com/~zlinuxman/kernel/ZAPLABEL.ASM

This is s390 assembler language source code for the utility.
The comments explain how to assemble and use it. It is designed
to be assembled and used under CMS.

Now, how do you want to work this? Do you (the Debian Kernel Team)
want to function as an intermediary between me and upstream?
Or would you prefer that I report the problem to upstream myself?

--
.'`. Stephen Powell
: :' :
`. `'`
`-



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 274713590.319959.1274455956217.JavaMail.root@md01. wow.synacor.com">http://lists.debian.org/274713590.319959.1274455956217.JavaMail.root@md01. wow.synacor.com
 
Old 05-21-2010, 08:48 PM
Jonathan Nieder
 
Default Bug#582281: Promised utility now available

reassign 582281 linux-2.6
tags 582281 + upstream
quit

Stephen Powell wrote:

> Now, how do you want to work this? Do you (the Debian Kernel Team)
> want to function as an intermediary between me and upstream?
> Or would you prefer that I report the problem to upstream myself?

I am not the kernel team, but for issues in upstream code, it is
_always_ a good idea to go to upstream directly[1].

$ grep '^[0-9]*)' Documentation/SubmittingPatches
1) "diff -up"
2) Describe your changes.
3) Separate your changes.
4) Style check your changes.
5) Select e-mail destination.
6) Select your CC (e-mail carbon copy) list.
7) No MIME, no links, no compression, no attachments. Just plain text.
8) E-mail size.
9) Name your kernel version.
10) Don't get discouraged. Re-submit.
11) Include PATCH in the subject
12) Sign your work
13) When to use Acked-by: and Cc:
14) Using Reported-by:, Tested-by: and Reviewed-by:
15) The canonical patch format
16) Sending "git pull" requests (from Linus emails)
1) Read Documentation/CodingStyle
2) #ifdefs are ugly
3) 'static inline' is better than a macro
4) Don't over-design.
$ scripts/get_maintainer.pl -f fs/partitions/ibm.c
"Martin K. Petersen" <martin.petersen@oracle.com>
Jens Axboe <jens.axboe@oracle.com>
linux-kernel@vger.kernel.org

Summary: the best thing is to send your patch as a _unified_ diff
(i.e. generated with diff -u), and include it inline in a message
to the addresses listed above, with the following format:

some timeless words about the patch

Signed-off-by line (see Documentation/SubmittingPatches for what
this means and why)
---
some timely words about the patch

the patch (diff -up output)

It seems I have only been able to make more work for you lately.
Sorry. I would also be willing to pass on the patch myself, but at
minimum this requires your signed-off-by line, and it might be good to
get to know the process anyway.

You can see lots of examples at http://news.gmane.org/gmane.linux.kernel

Hope that helps,
Jonathan

[1] The corresponding Debian bug report is still useful, as a way to
track the status of the bug in Debian (e.g., what versions have the
patch applied).



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100521204838.GA1786@progeny.tock">http://lists.debian.org/20100521204838.GA1786@progeny.tock
 
Old 05-22-2010, 04:38 PM
Stephen Powell
 
Default Bug#582281: Promised utility now available

On Fri, 21 May 2010 16:48:38 -0400 (EDT), Jonathan Nieder wrote:
>
> I am not the kernel team, but for issues in upstream code, it is
> _always_ a good idea to go to upstream directly[1].

To the Debian Kernel Team:

Upon the advice of Jonathan Nieder, I will pursue this directly with
upstream, but I will keep you informed of what's going on by updates
to this bug log. If you have a problem with that, please say so.

On Fri, 21 May 2010 16:48:38 -0400 (EDT), Jonathan Nieder wrote:
>
> $ grep '^[0-9]*)' Documentation/SubmittingPatches
> 1) "diff -up"
> 2) Describe your changes.
> 3) Separate your changes.
> 4) Style check your changes.
> 5) Select e-mail destination.
> 6) Select your CC (e-mail carbon copy) list.
> 7) No MIME, no links, no compression, no attachments. Just plain text.
> 8) E-mail size.
> 9) Name your kernel version.
> 10) Don't get discouraged. Re-submit.
> 11) Include PATCH in the subject
> 12) Sign your work
> 13) When to use Acked-by: and Cc:
> 14) Using Reported-by:, Tested-by: and Reviewed-by:
> 15) The canonical patch format
> 16) Sending "git pull" requests (from Linus emails)
> 1) Read Documentation/CodingStyle
> 2) #ifdefs are ugly
> 3) 'static inline' is better than a macro
> 4) Don't over-design.
> $ scripts/get_maintainer.pl -f fs/partitions/ibm.c
> "Martin K. Petersen" <martin.petersen@oracle.com>
> Jens Axboe <jens.axboe@oracle.com>
> linux-kernel@vger.kernel.org
>
> Summary: the best thing is to send your patch as a _unified_ diff
> (i.e. generated with diff -u), and include it inline in a message
> to the addresses listed above, with the following format:
>
> some timeless words about the patch
>
> Signed-off-by line (see Documentation/SubmittingPatches for what
> this means and why)
> ---
> some timely words about the patch
>
> the patch (diff -up output)
>
> It seems I have only been able to make more work for you lately.
> Sorry. I would also be willing to pass on the patch myself, but at
> minimum this requires your signed-off-by line, and it might be good to
> get to know the process anyway.
>
> You can see lots of examples at http://news.gmane.org/gmane.linux.kernel
>
> Hope that helps,
> Jonathan
>
> [1] The corresponding Debian bug report is still useful, as a way to
> track the status of the bug in Debian (e.g., what versions have the
> patch applied).

To Jonathan:

I'm willing to do this. But there are a couple of
practical considerations why I don't think I'll go that route.

First of all, I have never been able to successfully send or receive
in-line patches using my e-mail client. (You may recall my inability
to successfully receive some patches for parted that you sent me
earlier.) Somehow or other, my e-mail client hoses them up. I don't
know if its the handling of tabs or wrapping long lines, or just what
the problem is.

Second, although my patch works, there is a potential data access
issue involved here. My little stand-alone utility program will fix
that problem, but it relies on knowledgeable human intervention
in advance to prevent data from becoming unreadable. IBM may prefer
a more sophisticated solution. For example, they may prefer a
solution that checks for a valid file system or swap space on the block
that a non-reserved minidisk would use, and, if that is the case, and if
a valid filesystem or swap space is not found on the block that a
reserved minidisk would use, it may automatically set the disk offset
field in the CMS disk label to zero and update the label. That would
involve more work, and is probably beyond my capabilities at this point,
but IBM may choose that as a solution.

>From my research, this bug was probably introduced between kernel
2.6.30.10 and and 2.6.31. That's when they changed the definition
of "blocksize" from dbev_hardsect_size(bdev) to
bdev_logical_block_size(bdev). That apparently fixed one problem
and caused another (this one).

I previously found a bug in the DIAG driver (could not bring read-only
minidisks online) and wrote a zap to fix the problem. But IBM's
solution was more elegant and added several more kernel messages.
Their fix was better than mine. And their fix to this problem may
be better than mine too. So I'm going to send an e-mail to
Linux390@de.ibm.com to report the bug and see what happens.
In the meantime, my patch is available for users who want to build
a custom kernel with my patch applied to fix the problem.
Wish me luck!

--
.'`. Stephen Powell
: :' :
`. `'`
`-



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1734739580.342738.1274546298656.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/1734739580.342738.1274546298656.JavaMail.root@md01 .wow.synacor.com
 
Old 05-22-2010, 08:12 PM
Jonathan Nieder
 
Default Bug#582281: Promised utility now available

Stephen Powell wrote:

> So I'm going to send an e-mail to
> Linux390@de.ibm.com to report the bug and see what happens.

Oh! I should have read the file header:

* Bugreports.to..: <Linux390@de.ibm.com>

Yes, you have the right address. It seems that get_maintainer.pl
expects files to change frequently, and since nothing changed in
that file for the past year, it was confused[1].

> In the meantime, my patch is available for users who want to build
> a custom kernel with my patch applied to fix the problem.

Sounds very good. Thanks for your hard work.

Jonathan

[1] http://marc.info/?l=linux-s390&m=127455832518661&w=2



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100522201252.GB12249@progeny.tock">http://lists.debian.org/20100522201252.GB12249@progeny.tock
 

Thread Tools




All times are GMT. The time now is 01:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org