Bug#752881:

2014-07-02 Thread Andrew Worsley 
Hi I've done some git bisection on this problem and cut it down to a 1000 revs:

git bisect log
git bisect start
# good: [4c37b233616542536c75d20355d38d1065842103] fixes so can build
under wheezy
git bisect good 4c37b233616542536c75d20355d38d1065842103
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect bad 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [8c4877a4128e7931077b024a891a4b284d8756a3] ehea: Use the
standard logging functions
git bisect good 8c4877a4128e7931077b024a891a4b284d8756a3
# good: [1d0738ea48829cb234fcaba830eef3461985ff44] ARM: mach-shmobile:
Use SCIFA and SCIFB port types on sh7377
git bisect good 1d0738ea48829cb234fcaba830eef3461985ff44
# good: [03b7898d300de62078cc130fbc83b84b1d1e0f8d] ARM: perf: move
active_events into struct arm_pmu
git bisect good 03b7898d300de62078cc130fbc83b84b1d1e0f8d
# good: [0e59e7e7feb5a12938fbf9135147eeda3238c6c4] Merge branch
'next-rebase' of
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci
git bisect good 0e59e7e7feb5a12938fbf9135147eeda3238c6c4
# good: [1046a2c428bedd64c960dcfd0c57cc69a82fea2f] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good 1046a2c428bedd64c960dcfd0c57cc69a82fea2f
# bad: [5b34b08996decc53a993287282e2cd42b90e02f7] Merge branch 'fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 5b34b08996decc53a993287282e2cd42b90e02f7


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+Y=x3n=zjqf6ycvas_vjo1tr8_dx+wwjrwf3c9ykkcxs8p...@mail.gmail.com

Bug#752881: Shorter gitsect list

2014-07-04 Thread Andrew Worsley 
It appears some where between linux 3.1.0-rc4 and 3.1.0


More detailed git log  below:


git bisect view --pretty=oneline --abbrev-commit --graph
* 00411ee watchdog: Convert wm831x driver to watchdog core
* 25dc46e watchdog: s3c2410: convert to use the watchdog framework
* 74cd4c6 Documentation: watchdog: add guide how to convert drivers to
new framework
* deb9197 watchdog: iTCO_wdt.c - problems with newer hardware due to
SMI clearing
* c63b6d0 watchdog: Add WDIOC_GETTIMELEFT ioctl support to w83627
watchdog driver
* 86b5912 watchdog: irq: Remove IRQF_DISABLED
* 47bfd05 watchdog: Octeon: Mark octeon_wdt interrupt as IRQF_NO_THREAD
* cef153a watchdog: sc520_wdt: Remove unnecessary cast.
* dc822e5 ARM: EXYNOS4: Fix the merge conflict
* 5c8a0fb VFS: fix statfs() automounter semantics regression
*   fba9569 Merge branch 'next' of git://git.infradead.org/users/vkoul/slave-dma
|\
| * 4598fc2 dmaengine: mid_dma: mask_peripheral_interrupt only when dmac is idle
| * 2389d67 dmaengine/ep93xx_dma: add module.h include
| * 01631243d pch_dma: Reduce wasting memory
| * c43f150 pch_dma: Fix suspend issue
| * f80befe dma/timberdale: free_irq() on an error path
| * 7a1cd9a dma: shdma: transfer based runtime PM
| * b4dae6e dmaengine: shdma: protect against the IRQ handler
| * 0745c9a Merge branch 'samsung_dma' into next
| * f8de8f4 dmaengine i.MX DMA/SDMA: add missing include of linux/module.h
| * 46389470 dmaengine: delete redundant chan_id and chancnt
initialization in dma drivers
| * c120564 dmaengine/amba-pl08x: Check txd-llis_va before freeing dma_pool
| * b7f69d9 dmaengine/amba-pl08x: Add support for sg len greater than
one for slave transfers
| * 937bb6e serial: sh-sci: don't filter on DMA device, use only channel ID
* 3d0a8d1 Merge branch 'for-3.2/drivers' of git://git.kernel.dk/linux-block
* a0eda62 virtio-blk: use ida to allocate disk index
* c4853ef hpsa: add small delay when using PCI Power Management to
reset for kump
* ab5dbeb cciss: add small delay when using PCI Power Management to
reset for kump
*   b8d8bdf Merge branch 'stable/for-jens-3.2' of
git://oss.oracle.com/git/kwilk/xen into for-3.2/drivers
|\
| * 6927d92 xen/blkback: Fix two races in the handling of barrier requests.
| * dda1852 xen/blkback: Check for proper operation.
| * 64391b2 xen/blkback: Fix the inhibition to map pages when
discarding sector ranges.
| * 5c62cb4 xen/blkback: Report VBD_WSECT (wr_sect) properly.
| * 29bde09 xen/blkback: Support 'feature-barrier' aka old-style
BARRIER requests.
| * 469738e xen-blkfront: plug device number leak in xlblk_init() error path
| * d11e615 xen-blkfront: If no barrier or flush is supported, use
invalid operation.
| * 8e6dc6f xen-blkback: use kzalloc() in favor of kmalloc()+memset()
| * c555aab xen-blkback: fixed indentation and comments
| * 69ef68c xen-blkfront: fix a deadlock while handling discard response
| * ed30bf3 xen-blkfront: Handle discard requests.
| * b3cb0d6 xen-blkback: Implement discard requests ('feature-discard')
| * 32a8d26 xen-blkfront: add BLKIF_OP_DISCARD and discard request struct
* 4c823cc drivers/block/loop.c: remove unnecessary bdev argument from
loop_clr_fd()
* 8a9c594 drivers/block/loop.c: emit uevent on auto release
* 5a3a76e drivers/block/cpqarray.c: use pci_dev-revision
* e03c8dd loop: always allow userspace partitions and optionally
support automatic scanning
*   e8b177c Merge branch 'for-3.2/core' into for-3.2/drivers
|\
| * d27769e block: add GENHD_FL_NO_PART_SCAN
* dfaa2ef loop: add discard support for loop devices
* 548ef6c nbd-replace-some-printk-with-dev_warn-and-dev_info-checkpatch-fixes
* 5eedf54 nbd: replace some printk with dev_warn() and dev_info()
* 7742ce4 nbd: lower the loglevel of an error message
* 7f1b90f nbd: replace printk KERN_ERR with dev_err()
* 1695b87 nbd: replace sysfs_create_file() with device_create_file()
* 25ac0c2 nbd: use task_pid_nr() to get current pid
* f963d27 cciss: add transport mode attribute to sys
* 1304953 cciss: Adds simple mode functionality


git bisect start
# good: [4c37b233616542536c75d20355d38d1065842103] fixes so can build
under wheezy
git bisect good 4c37b233616542536c75d20355d38d1065842103
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect bad 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [8c4877a4128e7931077b024a891a4b284d8756a3] ehea: Use the
standard logging functions
git bisect good 8c4877a4128e7931077b024a891a4b284d8756a3
# good: [1d0738ea48829cb234fcaba830eef3461985ff44] ARM: mach-shmobile:
Use SCIFA and SCIFB port types on sh7377
git bisect good 1d0738ea48829cb234fcaba830eef3461985ff44
# good: [03b7898d300de62078cc130fbc83b84b1d1e0f8d] ARM: perf: move
active_events into struct arm_pmu
git bisect good 03b7898d300de62078cc130fbc83b84b1d1e0f8d
# good: [0e59e7e7feb5a12938fbf9135147eeda3238c6c4] Merge branch
'next-rebase' of

Bug#752881: Another git bisection

2014-07-04 Thread Andrew Worsley 
Identified Fault within 7 changes
commit b8d8bdfe31a67981bbc398a4886ccc67aff521d5
Merge: 4c823cc 6927d92
Author: Jens Axboe ax...@kernel.dk
Date:   Thu Oct 20 15:10:59 2011 +0200

Merge branch 'stable/for-jens-3.2' of git://oss.oracle.com/git/kwilk/xen 
into for-3.2/drivers

commit 6927d92091df2848fc0e6a693a017d4b2df549c2
Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date:   Mon Oct 17 14:27:48 2011 -0400

xen/blkback: Fix two races in the handling of barrier requests.

There are two windows of opportunity to cause a race when
processing a barrier request. This patch fixes this.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit dda1852802a6cc6fdecb9021e491b2de680c76b9
Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date:   Fri Oct 14 12:13:05 2011 -0400

xen/blkback: Check for proper operation.

The patch titled: xen/blkback: Fix the inhibition to map pages
when discarding sector ranges. had the right idea except that
it used the wrong comparison operator. It had == instead of !=.

This fixes the bug where all (except discard) operations would
have been ignored.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 64391b2536ca92f9c589b2bfeaca3954896fe057
Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date:   Mon Oct 10 00:47:49 2011 -0400

xen/blkback: Fix the inhibition to map pages when discarding sector ranges.

The 'operation' parameters are the ones provided to the bio layer while
the req-operation are the ones passed in between the backend and
frontend. We used the wrong 'operation' value to squash the
call to map pages when processing the discard operation resulting
in an hypercall that did nothing. Lets guard against going in the
mapping function by checking for the proper operation type.

CC: Li Dongyang lidongy...@novell.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 5c62cb48602dba95159c81ffeca179d3852e25be
Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date:   Mon Oct 10 12:33:21 2011 -0400

xen/blkback: Report VBD_WSECT (wr_sect) properly.

We did not increment the amount of sectors written to disk
b/c we tested for the == WRITE which is incorrect - as the
operations are more of WRITE_FLUSH, WRITE_ODIRECT. This patch
fixes it by doing a  WRITE check.

CC: sta...@kernel.org
Reported-by: Andy Burns xen.li...@burns.me.uk
Suggested-by: Ian Campbell ian.campb...@citrix.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 29bde093787f3bdf7b9b4270ada6be7c8076e36b
Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date:   Mon Oct 10 00:42:22 2011 -0400

xen/blkback: Support 'feature-barrier' aka old-style BARRIER requests.

We emulate the barrier requests by draining the outstanding bio's
and then sending the WRITE_FLUSH command. To drain the I/Os
we use the refcnt that is used during disconnect to wait for all
the I/Os before disconnecting from the frontend. We latch on its
value and if it reaches either the threshold for disconnect or when
there are no more outstanding I/Os, then we have drained all I/Os.

Suggested-by: Christopher Hellwig h...@infradead.org
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 469738e675524b6aa029ecd46bdda3f878b12eff
Author: Laszlo Ersek ler...@redhat.com
Date:   Fri Oct 7 21:34:38 2011 +0200

xen-blkfront: plug device number leak in xlblk_init() error path

... though after a failed xenbus_register_frontend() all may be lost.

Acked-by: Ian Campbell ian.campb...@citrix.com
Signed-off-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit d11e6158307bed3f178399a4e6216eec67d16200
Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date:   Fri Sep 16 15:15:14 2011 -0400

xen-blkfront: If no barrier or flush is supported, use invalid operation.

Guard against issuing BLKIF_OP_WRITE_BARRIER or BLKIF_OP_FLUSH_CACHE
by checking whether we successfully negotiated with the backend.
The negotiation with the backend also sets the q-flush_flags which
fortunately for us is also used when submitting an bio to us. If
we don't support barriers or flushes it would be set to zero so
we should never end up having to deal with REQ_FLUSH | REQ_FUA.

However, other third party implementations of __make_request that
might be stacked on top of us might not be so smart, so lets fix this up.

Acked-by: Jan Beulich jbeul...@suse.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 8e6dc6fe51957116d363204a725c1262b4b78e19
Author: Jan Beulich jbeul...@suse.com
Date:   Fri Sep 16 08:38:09 2011 +0100

xen-blkback: use kzalloc() in favor of kmalloc()+memset()

This fixes the problem of three of those four memset()-s

Bug#752881: Found exact revision that causes problem

2014-07-18 Thread Andrew Worsley 
It looks innocent enough - but I have bisected it down to with (bad)
and just before (good)...

4c823cc3d568277aa6340d8df6981e34f4c4dee5 is the first bad commit

* commit 4c823cc
| Author: Ayan George a...@ayan.net
| Date:   Wed Sep 21 10:02:13 2011 +0200
|
| drivers/block/loop.c: remove unnecessary bdev argument from loop_clr_fd()
|
| If the loop device is associated (lo-lo_state == Lo_bound), it will have
| a valid bdev pointed to by lo-lo_device.  There is no reason to ever pass
| an additional block_device pointer.
|
| Signed-off-by: Ayan George ayan.geo...@canonical.com
| Cc: Phillip Susi ps...@cfl.rr.com
| Cc: Jens Axboe ax...@kernel.dk
| Signed-off-by: Andrew Morton a...@google.com
| Signed-off-by: Jens Axboe ax...@kernel.dk
|
| M drivers/block/loop.c

% git diff 4c823cc3d568277aa6340d8df6981e34f4c4dee5~
4c823cc3d568277aa6340d8df6981e34f4c4dee5
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c2ce03c..9b2f5d3 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1051,10 +1051,11 @@ loop_init_xfer(struct loop_device *lo, struct
loop_func_table *xfer,
return err;
 }

-static int loop_clr_fd(struct loop_device *lo, struct block_device *bdev)
+static int loop_clr_fd(struct loop_device *lo)
 {
struct file *filp = lo-lo_backing_file;
gfp_t gfp = lo-old_gfp_mask;
+   struct block_device *bdev = lo-lo_device;

if (lo-lo_state != Lo_bound)
return -ENXIO;
@@ -1372,7 +1373,7 @@ static int lo_ioctl(struct block_device *bdev,
fmode_t mode,
break;
case LOOP_CLR_FD:
/* loop_clr_fd would have unlocked lo_ctl_mutex on success */
-   err = loop_clr_fd(lo, bdev);
+   err = loop_clr_fd(lo);
if (!err)
goto out_unlocked;
break;
@@ -1583,7 +1584,7 @@ static int lo_release(struct gendisk *disk, fmode_t mode)
 * In autoclear mode, stop the loop thread
 * and remove configuration after last close.
 */
-   err = loop_clr_fd(lo, lo-lo_device);
+   err = loop_clr_fd(lo);
if (!err)
goto out_unlocked;
} else {


--
   Full git bisection history:
git bisect start
# good: [4c37b233616542536c75d20355d38d1065842103] fixes so can build
under wheezy
git bisect good 4c37b233616542536c75d20355d38d1065842103
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect bad 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [8c4877a4128e7931077b024a891a4b284d8756a3] ehea: Use the
standard logging functions
git bisect good 8c4877a4128e7931077b024a891a4b284d8756a3
# good: [1d0738ea48829cb234fcaba830eef3461985ff44] ARM: mach-shmobile:
Use SCIFA and SCIFB port types on sh7377
git bisect good 1d0738ea48829cb234fcaba830eef3461985ff44
# good: [03b7898d300de62078cc130fbc83b84b1d1e0f8d] ARM: perf: move
active_events into struct arm_pmu
git bisect good 03b7898d300de62078cc130fbc83b84b1d1e0f8d
# good: [0e59e7e7feb5a12938fbf9135147eeda3238c6c4] Merge branch
'next-rebase' of
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci
git bisect good 0e59e7e7feb5a12938fbf9135147eeda3238c6c4
# good: [1046a2c428bedd64c960dcfd0c57cc69a82fea2f] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good 1046a2c428bedd64c960dcfd0c57cc69a82fea2f
# bad: [5b34b08996decc53a993287282e2cd42b90e02f7] Merge branch 'fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 5b34b08996decc53a993287282e2cd42b90e02f7
# bad: [32aaeffbd4a7457bf2f7448b33b5946ff2a960eb] Merge branch
'modsplit-Oct31_2011' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
git bisect bad 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb
# bad: [ec773e99ab4abce07b1ae23117179c2861831964] Merge branch 'fixes'
of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm
git bisect bad ec773e99ab4abce07b1ae23117179c2861831964
# bad: [00411ee9308e4b5f4b04caaa01685f955e259373] watchdog: Convert
wm831x driver to watchdog core
git bisect bad 00411ee9308e4b5f4b04caaa01685f955e259373
# good: [b4fdcb02f1e39c27058a885905bd0277370ba441] Merge branch
'for-3.2/core' of git://git.kernel.dk/linux-block
git bisect good b4fdcb02f1e39c27058a885905bd0277370ba441
# good: [51ddf31da16b1ab9da861eafedad6d263faf4388] ARM: SAMSUNG:
Remove Samsung specific enum type for dma direction
git bisect good 51ddf31da16b1ab9da861eafedad6d263faf4388
# bad: [b8d8bdfe31a67981bbc398a4886ccc67aff521d5] Merge branch
'stable/for-jens-3.2' of git://oss.oracle.com/git/kwilk/xen into
for-3.2/drivers
git bisect bad b8d8bdfe31a67981bbc398a4886ccc67aff521d5
# good: [8a9c594422ecad912d6470888acdee9a1236ad68]
drivers/block/loop.c: emit uevent on auto release
git bisect good

Bug#752881: Fwd: Bug#752881: Found exact revision that causes problem

2014-07-21 Thread Andrew Worsley 
For got to cc this to the bug...-(

On 21 July 2014 09:29, Ben Hutchings b...@decadent.org.uk wrote:
...

 Assuming that this regression only happened once, we can be fairly
 confident that it happened before
 4c823cc3d568277aa6340d8df6981e34f4c4dee5, but as that is around v3.2-rc1
 it doesn't reduce the range very much. :-(


Thank for looking at this issue. I don't get what is going on here
either but it seemed to reliably cause the problem BUT when I reverted
this change in the v3.2 kernel it still had the fault! (Broke my
heart!).

Then I built the version 8a9c59 (just prior to the bad version) from
scratch and this time it had the fault where as before worked!
 So I think I have to build completely cleanly each time...

So I am doing a git bisect again using  a cleaner way of rebuilding the kernels.

I did compile one on either side of it and it seemed solid. i.e.
rebooting the same kernel reliably results in a failure. I didn't
reboot every kernel but certainly the squeeze one is always good and
the wheezy is almost always bad (sometimes you can partially write a
BluRay before it completely bombs but it always gives these errors on
kernel booting).

One idea was that it might be a kernel configuration dependant because
I had to do make oldconfig and as I switched back and forth between
revisions it might have different configurations. But I just diff'ed
the config file from the last 4 builds and there was *NO* difference
so that should cover good and bad builds.

As I didn't rebuild the last set of kernels from scratch I suspect
this is the  cause of the inconstancies.

I am now trying the bisection again but now doing this each time.
  1. Rebuilding from scratch (make-kpkg clean)
  2. Copying the same config file and doing make oldconfig and always
accepting the default.

So far I have:

git bisect start
# bad: [8a9c594422ecad912d6470888acdee9a1236ad68]
drivers/block/loop.c: emit uevent on auto release
git bisect bad 8a9c594422ecad912d6470888acdee9a1236ad68
# good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
# good: [0003230e8200699860f0b10af524dc47bf8aecad] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
git bisect good 0003230e8200699860f0b10af524dc47bf8aecad
# good: [206d440f64030b6425841bf7cb38e26a5ea0c382] xfs: Fix build
breakage in xfs_iops.c when CONFIG_FS_POSIX_ACL is not set
git bisect good 206d440f64030b6425841bf7cb38e26a5ea0c382
# skip: [c11abbbaa3252875c5740a6880b9a1a6f1e2a870] Merge branch
'slub/lockless' of
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
git bisect skip c11abbbaa3252875c5740a6880b9a1a6f1e2a870

The last skip because I got compile errors.
...
arch/x86/built-in.o: In function `atomic_read':
/movies3/work/linux/arch/x86/include/asm/atomic.h:25: undefined
reference to `__tracepoint_xen_cpu_write_gdt_entry'
...
Actually I couldn't build the squeeze kernel under wheezy (lots of
problems) so I was building that under the squeeze in a virtual
machine.

This is a real annoying bug because I have to build so many kernels
and hit compile problems but I will crush it.
Suggestions on improving this debug plan would be much welcomed.

Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+Y=x3nb3qzsjykqnai0jwyo4f+__z1jab5e8ut+cxwnh0g...@mail.gmail.com

Bug#752881: update on re-bisect - with clean builds.

2014-07-23 Thread Andrew Worsley 
Rebuilding the kernels completely cleanly each time has narrowed it
down to a list of changes that sound more plausible.

Still working on building and testing...

Andrew

commit e8b177cedc39b092e423b8cbc687dbf096a1de47
Merge: dfaa2ef d27769e
Author: Jens Axboe jax...@fusionio.com
Date:   Tue Aug 23 20:01:11 2011 +0200

Merge branch 'for-3.2/core' into for-3.2/drivers

commit d27769ec3df1a8de9ca450d2dcd72d1ab259ba32
Author: Tejun Heo t...@kernel.org
Date:   Tue Aug 23 20:01:04 2011 +0200

block: add GENHD_FL_NO_PART_SCAN

There are cases where suppressing partition scan is useful - e.g. for
lo devices and pseudo SATA devices which advertise to be a disk but
get upset on partition scan (some port multiplier control devices show
such behavior).

This patch adds GENHD_FL_NO_PART_SCAN which suppresses partition scan
regardless of the number of possible partitions.  disk_partitionable()
is renamed to disk_part_scan_enabled() as suppressing partition scan
doesn't imply the device can't be partitioned using
BLKPG_ADD/DEL_PARTITION calls from userland.  show_partition() now
directly tests disk_max_parts() to maintain backward-compatibility.

-v2: Updated to make it clear that only partition scan is suppressed
 not partitioning itself as suggested by Kay Sievers.

Signed-off-by: Tejun Heo t...@kernel.org
Cc: Kay Sievers kay.siev...@vrfy.org
Signed-off-by: Jens Axboe jax...@fusionio.com

commit dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef
Author: Lukas Czerner lczer...@redhat.com
Date:   Fri Aug 19 14:50:46 2011 +0200

loop: add discard support for loop devices

This commit adds discard support for loop devices. Discard is usually
supported by SSD and thinly provisioned devices as a method for
reclaiming unused space. This is no different than trying to reclaim
back space which is not used by the file system on the image, but it
still occupies space on the host file system.

We can do the reclamation on file system which does support hole
punching. So when discard request gets to the loop driver we can
translate that to punch a hole to the underlying file, hence reclaim
the free space.

This is very useful for trimming down the size of the image to only what
is really used by the file system on that image. Fstrim may be used for
that purpose.

It has been tested on ext4, xfs and btrfs with the image file systems
ext4, ext3, xfs and btrfs. ext4, or ext6 image on ext4 file system has
some problems but it seems that ext4 punch hole implementation is
somewhat flawed and it is unrelated to this commit.

Also this is a very good method of validating file systems punch hole
implementation.

Note that when encryption is used, discard support is disabled, because
using it might leak some information useful for possible attacker.

Signed-off-by: Lukas Czerner lczer...@redhat.com
Reviewed-by: Jeff Moyer jmo...@redhat.com
Signed-off-by: Jens Axboe jax...@fusionio.com

commit 548ef6cc26ca1c81f19855d57d3fb0f9a7ce3385
Author: Andrew Morton a...@linux-foundation.org
Date:   Fri Aug 19 14:48:28 2011 +0200

nbd-replace-some-printk-with-dev_warn-and-dev_info-checkpatch-fixes

ERROR: code indent should use tabs where possible
#30: FILE: drivers/block/nbd.c:578:
+^Idev_info(disk_to_dev(lo-disk), NBD_DISCONNECT\n);$

total: 1 errors, 0 warnings, 35 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
  scripts/cleanfile

./patches/nbd-replace-some-printk-with-dev_warn-and-dev_info.patch
has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Paul Clements paul.cleme...@steeleye.com
Cc: WANG Cong amw...@redhat.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Jens Axboe jax...@fusionio.com


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+Y=x3mqmpomz44w4sb3wpd7pvtxw8omh03rhvl1okv4fjg...@mail.gmail.com

Bug#752881: Verified bugfix against kernel v3.2

2014-07-26 Thread Andrew Worsley 
-bd_contains)
+   if (!disk_part_scan_enabled(disk) || bdev != bdev-bd_contains)
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
diff --git a/fs/block_dev.c b/fs/block_dev.c
index ff77262..0bed0d4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -971,7 +971,7 @@ static void flush_disk(struct block_device *bdev,
bool kill_dirty)

if (!bdev-bd_disk)
return;
-   if (disk_partitionable(bdev-bd_disk))
+   if (disk_part_scan_enabled(bdev-bd_disk))
bdev-bd_invalidated = 1;
 }

diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 02fa469..6d18f35 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -128,6 +128,7 @@ struct hd_struct {
 #define GENHD_FL_EXT_DEVT  64 /* allow extended devt */
 #define GENHD_FL_NATIVE_CAPACITY   128
 #define GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE256
+#define GENHD_FL_NO_PART_SCAN  512

 enum {
DISK_EVENT_MEDIA_CHANGE = 1  0, /* media changed */
@@ -234,9 +235,10 @@ static inline int disk_max_parts(struct gendisk *disk)
return disk-minors;
 }

-static inline bool disk_partitionable(struct gendisk *disk)
+static inline bool disk_part_scan_enabled(struct gendisk *disk)
 {
-   return disk_max_parts(disk)  1;
+   return disk_max_parts(disk)  1 
+   !(disk-flags  GENHD_FL_NO_PART_SCAN);
 }

 static inline dev_t disk_devt(struct gendisk *disk)
From d307a67863bf14f1785f0faa39ef2ad496758e4a Mon Sep 17 00:00:00 2001
From: Andrew Worsley amwors...@gmail.com
Date: Sat, 26 Jul 2014 06:46:53 +1000
Subject: [PATCH] Revert block: add GENHD_FL_NO_PART_SCAN

This reverts commit d27769ec3df1a8de9ca450d2dcd72d1ab259ba32 but keeps the
definition of GENHD_FL_NO_PART_SCAN used by drivers/block/loop.c

 Fix debian bug report #752881 which results in errors like then when access a PCI bus based bluRay drive
...
Jun  7 14:08:36 azza kernel: [569395.478041] end_request: I/O error, dev sr1, sector 0
Jun  7 14:08:36 azza kernel: [569395.481744] sr 6:0:0:0: [sr1] Unhandled sense code
Jun  7 14:08:36 azza kernel: [569395.481746] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun  7 14:08:36 azza kernel: [569395.481748] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current]
Jun  7 14:08:36 azza kernel: [569395.481751] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
Jun  7 14:08:36 azza kernel: [569395.481754] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
...
---
 block/genhd.c |4 ++--
 block/ioctl.c |2 +-
 fs/block_dev.c|2 +-
 include/linux/genhd.h |7 +++
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 02e9fca..d261b73 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -536,7 +536,7 @@ void register_disk(struct gendisk *disk)
 	disk-slave_dir = kobject_create_and_add(slaves, ddev-kobj);
 
 	/* No minors to use for partitions */
-	if (!disk_part_scan_enabled(disk))
+	if (!disk_partitionable(disk))
 		goto exit;
 
 	/* No such device (e.g., media were just removed) */
@@ -847,7 +847,7 @@ static int show_partition(struct seq_file *seqf, void *v)
 	char buf[BDEVNAME_SIZE];
 
 	/* Don't show non-partitionable removeable devices or empty devices */
-	if (!get_capacity(sgp) || (!disk_max_parts(sgp) 
+	if (!get_capacity(sgp) || (!disk_partitionable(sgp) 
    (sgp-flags  GENHD_FL_REMOVABLE)))
 		return 0;
 	if (sgp-flags  GENHD_FL_SUPPRESS_PARTITION_INFO)
diff --git a/block/ioctl.c b/block/ioctl.c
index ca939fc..5554403 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -102,7 +102,7 @@ static int blkdev_reread_part(struct block_device *bdev)
 	struct gendisk *disk = bdev-bd_disk;
 	int res;
 
-	if (!disk_part_scan_enabled(disk) || bdev != bdev-bd_contains)
+	if (!disk_partitionable(disk) || bdev != bdev-bd_contains)
 		return -EINVAL;
 	if (!capable(CAP_SYS_ADMIN))
 		return -EACCES;
diff --git a/fs/block_dev.c b/fs/block_dev.c
index b07f1da..1c44b8d 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -971,7 +971,7 @@ static void flush_disk(struct block_device *bdev, bool kill_dirty)
 
 	if (!bdev-bd_disk)
 		return;
-	if (disk_part_scan_enabled(bdev-bd_disk))
+	if (disk_partitionable(bdev-bd_disk))
 		bdev-bd_invalidated = 1;
 }
 
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 6d18f35..886f8ea 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -128,7 +128,7 @@ struct hd_struct {
 #define GENHD_FL_EXT_DEVT			64 /* allow extended devt */
 #define GENHD_FL_NATIVE_CAPACITY		128
 #define GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE	256
-#define GENHD_FL_NO_PART_SCAN			512
+#define GENHD_FL_NO_PART_SCAN   512
 
 enum {
 	DISK_EVENT_MEDIA_CHANGE			= 1  0, /* media changed */
@@ -235,10 +235,9 @@ static inline int disk_max_parts(struct gendisk *disk)
 	return disk-minors;
 }
 
-static inline bool disk_part_scan_enabled(struct

Bug#752881: Stack Trace

2014-08-03 Thread Andrew Worsley 
After much stuffing around I managed to get a stack trace related to
the change near the problem:


Aug  4 06:20:13 azza kernel: [   12.680555] end_request: I/O error,
dev sr1, sector 0
Aug  4 06:20:13 azza kernel: [   12.685541] sr 6:0:0:0: [sr1]
Unhandled sense code
Aug  4 06:20:13 azza kernel: [   12.686984] sr 6:0:0:0: [sr1]  Result:
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug  4 06:20:13 azza kernel: [   12.688417] sr 6:0:0:0: [sr1]  Sense
Key : Blank Check [current]
Aug  4 06:20:13 azza kernel: [   12.689842] sr 6:0:0:0: [sr1]  Add.
Sense: No additional sense information
Aug  4 06:20:13 azza kernel: [   12.691269] sr 6:0:0:0: [sr1] CDB:
Read(10): 28 00 00 00 00 00 00 00 01 00
Aug  4 06:20:13 azza kernel: [   12.692729] end_request: I/O error,
dev sr1, sector 0
Aug  4 06:20:13 azza kernel: [   13.014699] EXT3-fs (md10): using
internal journal
Aug  4 06:20:13 azza kernel: [   13.140807] dump_bug_752881() -
disk_max_parts(disk)=256, (disk-flags  GENHD_FL_NO_PART_SCAN)=0x200
Aug  4 06:20:13 azza kernel: [   13.142307] Pid: 1123, comm: modprobe
Not tainted 3.2.0-amw-fix3+ #1
Aug  4 06:20:13 azza kernel: [   13.143797] Call Trace:
Aug  4 06:20:13 azza kernel: [   13.145303]  [8119abce] ?
dump_bug_752881+0x4e/0x6a
Aug  4 06:20:13 azza kernel: [   13.146771]  [8119ac85] ?
register_disk+0x9b/0x133
Aug  4 06:20:13 azza kernel: [   13.148239]  [8119995b] ?
blk_register_region+0x22/0x27
Aug  4 06:20:13 azza kernel: [   13.149700]  [8119add2] ?
add_disk+0xb5/0x27f
Aug  4 06:20:13 azza kernel: [   13.151148]  [a03af843] ?
loop_add+0x1c9/0x1f5 [loop]
Aug  4 06:20:13 azza kernel: [   13.152593]  [81039613] ?
should_resched+0x5/0x23
Aug  4 06:20:13 azza kernel: [   13.154028]  [a03b6101] ?
loop_init+0x101/0x1000 [loop]
Aug  4 06:20:13 azza kernel: [   13.155472]  [a03b6000] ?
0xa03b5fff
Aug  4 06:20:13 azza kernel: [   13.156907]  [81002085] ?
do_one_initcall+0x75/0x12c
Aug  4 06:20:13 azza kernel: [   13.158350]  [a03b6000] ?
0xa03b5fff
Aug  4 06:20:13 azza kernel: [   13.159769]  [81073b04] ?
sys_init_module+0x109/0x25b
Aug  4 06:20:13 azza kernel: [   13.161185]  [813464d2] ?
system_call_fastpath+0x16/0x1b
Aug  4 06:20:13 azza kernel: [   13.162810] dump_bug_752881() -
disk_max_parts(disk)=256, (disk-flags  GENHD_FL_NO_PART_SCAN)=0x200
Aug  4 06:20:13 azza kernel: [   13.164301] Pid: 1123, comm: modprobe
Not tainted 3.2.0-amw-fix3+ #1
Aug

This is the patch and it was run with the fix disabled and stack
tracing enabled (
diff --git a/block/genhd.c b/block/genhd.c
index 02e9fca..43d783a 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1798,3 +1798,29 @@ static void disk_release_events(struct gendisk *disk)
WARN_ON_ONCE(disk-ev  disk-ev-block != 1);
kfree(disk-ev);
 }
+
+
+int bug_752881_dbg;
+static int __init set_bug_752881_dbg(char *s)
+{
+   set_bug_752881_dbg = simple_strtoul(s, NULL, 0);
+
+   return 1;
+}
+__setup(bug_752881_dbg=, set_bug_752881_dbg);
+
+#define BUG_DUMP_STK 1
+#define BUG_GOOD_CODE 2
+
+int dump_bug_752881(struct gendisk *disk)
+{
+if (disk_max_parts(disk) = 1)
+return 0;
+if (bug_752881_dbg  BUG_DUMP_STK) {
+printk(%s() - disk_max_parts(disk)=%d, (disk-flags 
GENHD_FL_NO_PART_SCAN)=%#x\n,
+__func__, disk_max_parts(disk), (disk-flags 
GENHD_FL_NO_PART_SCAN));
+}
+if (bug_752881_dbg  BUG_GOOD_CODE)
+return 1;
+return !(disk-flags  GENHD_FL_NO_PART_SCAN);
+}
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 6d18f35..be3ad96 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -237,8 +237,13 @@ static inline int disk_max_parts(struct gendisk *disk)

 static inline bool disk_part_scan_enabled(struct gendisk *disk)
 {
+#if 0
return disk_max_parts(disk)  1 
!(disk-flags  GENHD_FL_NO_PART_SCAN);
+#else
+extern int dump_bug_752881(struct gendisk *disk);
+return dump_bug_752881(disk);
+#endif
 }

 static inline dev_t disk_devt(struct gendisk *disk)


I also suspect that having a blank bluRay in the tray which gives
media errors is important?

Aug  4 06:15:51 azza kernel: [3.793076] generic-usb
0003:1267:0201.0001: input,hidraw0: USB HID v1.00 Mouse [USB Mouse] on
usb-:00:1a.1-1/input0
Aug  4 06:15:51 azza kernel: [3.795362]  sdb: sdb1 sdb2 sdb3 sdb4
Aug  4 06:15:51 azza kernel: [3.795721] sd 4:0:0:0: [sdb] Attached SCSI disk
Aug  4 06:15:51 azza kernel: [3.797081] input: Dell Dell Smart
Card Reader Keyboard as
/devices/pci:00/:00:1a.2/usb8/8-1/8-1:1.0/input/input1
Aug  4 06:15:51 azza kernel: [3.797196] generic-usb
0003:413C:2101.0002: input,hidraw1: USB HID v1.11 Keyboard [Dell Dell
Smart Card Reader Keyboard] on usb-:00:1a.2-1/input0
Aug  4 06:15:51 azza kernel: [3.797286] usbcore: registered new
interface driver usbhid
Aug  4 06:15:51 azza kernel: [3.797331] usbhid: USB HID core driver

Bug#822671: initramfs-tools: preserves unmodified /etc/initramfs-tools/initramfs.conf on upgrades from jessie

2016-10-08 Thread Andrew Worsley 
On 2 October 2016 at 07:15, Ben Hutchings <b...@decadent.org.uk> wrote:
> On Fri, 2016-09-30 at 09:57 +1000, Andrew Worsley wrote:
>> Hi, I am a newbie (have a mentor account and looking to help)
>> I just looked into this bug and tried to apply the patch - but it
>> appears the files are missing - perhaps way out of date?
> [...]
>
> The patch applies for me with 'patch -p1'.  But I haven't yet taken the
> time to try it out.
>
> Ben.

  Sorry I got confused and was apply to an older (0.120 version) it applies
 perfectly for me against 0.125 the latest version. I believe version
looks ok to
a basic piuparts but I am having troubles testing a distribution
upgrade with piuparts
but that might be a  limitation of piuparts or my knowledge on how to run it.

Help on how to proceed would be appreciated.

It may well be that the unpatched version is fine now - I did most of
my testing with the patched
package.

* I checked it with a basic piuparts :
  piuparts initramfs-tools_0.125_all.deb

  * and got a complaint:

4m20.9s ERROR: FAIL: Package purging left files on system:
  /var/log/apt/eipp.log.xz   not owned


  I got this on the unpatched *and* the patched version of the package.
It turns out this is a piupart bug - fixed in version 0.72
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830527

I upgraded to backports version of piuparts:
  apt-get install piuparts/jessie-backports

vagrant(0)% piuparts --version
piuparts 0.72~bpo8+1

and it is much happier:
  * piuparts -s piuparts-base.tgz initramfs-tools-core_0.125+nmu1_all.deb

4m55.5s DEBUG: Removed directory tree at /tmp/tmpJyGQJ8
4m55.5s INFO: PASS: All tests.
4m55.5s INFO: piuparts run ends.

  * Running the .changes file into a log and grep-ing the info entries
all looks good.
   piuparts -b piuparts-base.tgz -l piuparts-log.txt
initramfs-tools_0.125+nmu1_amd64.changes

0m24.5s INFO: Installation of
['tmp/initramfs-tools-core_0.125+nmu1_all.deb',
'tmp/initramfs-tools_0.125+nmu1_all.deb'] ok
0m25.8s INFO: Running adequate version 0.12.1 now.
0m27.7s INFO: PASS: Installation, upgrade and purging tests.
0m28.0s INFO: PASS: All tests.
0m28.0s INFO: piuparts run ends.

  * Trying to run an upgrade test fails:
piuparts -b piuparts-base.tgz -l piuparts-log2.txt -d jessie -d
stretch initramfs-tools_0.125+nmu1_amd64.changes

1m12.5s DEBUG: Starting command: ['chroot', '/tmp/tmpcZJKsf',
'eatmydata', 'apt-get', '-y', 'install', 'initramfs-tools']
1m12.8s DUMP:
  Reading package lists...
  Building dependency tree...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   initramfs-tools : Depends: udev but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.
1m12.8s ERROR: Command failed (status=100): ['chroot',
'/tmp/tmpcZJKsf', 'eatmydata', 'apt-get', '-y', 'install',
'initramfs-tools']
  Reading package lists...
  Building dependency tree...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   initramfs-tools : Depends: udev but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.



Is there a way to do this with piuparts or  do I have to figure out
some way to testing this by actually physically upgrading my vagrant
box to stretch and checking if there are files left behind?

Finally if the patched version is worth applying what other functional
tests should be considered to validate the patched version?

Thanks

Andrew

Bug#822671: initramfs-tools: preserves unmodified /etc/initramfs-tools/initramfs.conf on upgrades from jessie

2016-09-29 Thread Andrew Worsley 
Hi, I am a newbie (have a mentor account and looking to help)
I just looked into this bug and tried to apply the patch - but it
appears the files are missing - perhaps way out of date?

Perhaps still has errors as piuparts that I ran reported a problem
with the latest package I built.

If it is welcome I am willing to investigate and try to fix this.

If I am way off track let me know so I don't waste people's time
(including mine :-)

I also just tried to run piuparts in a (vagrant box in case it messed
up my own initramfs ?) and still getting an error:

...
6m17.1s DEBUG: No broken symlinks as far as we can find.
6m17.1s DEBUG: Starting command: ['chroot', '/tmp/tmpJWYJRD',
'eatmydata', 'dpkg-divert', '--list']
6m17.1s DUMP:
  diversion of /usr/share/man/man1/sh.1.gz to
/usr/share/man/man1/sh.distrib.1.gz by dash
  diversion of /bin/sh to /bin/sh.distrib by dash
6m17.1s DEBUG: Command ok: ['chroot', '/tmp/tmpJWYJRD', 'eatmydata',
'dpkg-divert', '--list']
6m17.1s DEBUG: Starting command: ['chroot', '/tmp/tmpJWYJRD',
'eatmydata', 'apt-get', 'clean']
6m17.1s DEBUG: Command ok: ['chroot', '/tmp/tmpJWYJRD', 'eatmydata',
'apt-get', 'clean']
6m17.4s ERROR: FAIL: Package purging left files on system:
  /etc/bash_completion.d/not owned
  /etc/bash_completion.d/initramfs-tools.dpkg-newnot owned
  /var/log/apt/eipp.log.xz   not owned

6m17.4s ERROR: FAIL: Installation and purging test.
...

Andrew Worsley

make -f debian/rules build - does not correctly rebuild files- why?

2016-11-25 Thread Andrew Worsley 
I found that rebuilding the kernel package does NOT rebuild  the .o
files which I found very surprising.
In fact after much painful experimenting I was forced do a clean to
get my modified .c files to be compiled!

Basically I was trying to build a new kernel in order to debug
   bug844788 "hibernate: suspends ok but hangs on restore after
decompressing with stretch kernel on macbook pro"

when I found the kernel was *unchanged* from the original version no
matter how I rebuilt the kernel. My confusion wasn't helped by the
fact the the timestamp in the kernel is based on the debian/changelog
:-(

After much painful building packages/installing and getting *NO*
change just got more desperate and in the end I just removed a .o

  rm linux-4.8.5/debian/build/build_amd64_none_amd64/kernel/power/swap.o

Then I found nothing would rebuild that .o - even though it spend much
time generating packages and so forth!
I was using dpkg-buildpackage with -nc (no clean)

Then tried plain make more and more make targets to see if any of them
would regenerate the file:

fakeroot make -n -f debian/rules.gen binary-arch_amd64_none_amd64
make  -f debian/rules.gen build-arch_amd64_none_amd64
make  -f debian/rules.gen build-arch_amd64
make  -f debian/rules build-arch
make  -f debian/rules build

Then finally I did this and then it was rebuilt - correctly with my
changes (which I verified with strings command on the binary):
 make  -f debian/rules clean

Now this works
 make  -f debian/rules.gen build-arch_amd64_none_amd64

Surely no one can work under these painful conditions - being forced
to rebuild all the code from scratch for the kernel to test a change?

Could some one point me to a way or documentation to easily - rebuild
(rather the clean and rebuild) the kernel for another test?

It takes a long time to build the kernel packages from scratch...

Thanks in advance

Andrew

Re: cross building linux-image packages

2016-11-23 Thread Andrew Worsley 
> From: Ben Hutchings 
> >
> > In particular trying to do
> >
> >   fakeroot make -f debian/rules.gen binary-arch_armel_none
> >
> > but that doesn't seem work  (gcc-5 command not found?) under jessie -
> > now looking at under stretch...
> >
> > But I think I am straying too far from the beaten track and hitting
> > lots of problems - hence the question about where information on what
> > people are normally doing to cross build the kernel using debian
> > packages.
>
> Using the stretch branch you should use something like:
>
> dpkg-buildpackage -Pcross,nopython -aarmel -B -uc -us
>
> I got that working (except with armhf as the target) a few months back.
>
> You can also add 'notools' to the -P option if you don't need the
> userland packages; this will reduce the build-dependencies.
>
> Ben.

  Thank-you very much Ben - got that approach to work (eventually :-)

  I tried:
  dpkg-buildpackage  -Pcross,nopython -aarmel -B -uc -us

  First I got several dependancy complaints that were not valid. The
components that
  dpkg-buildpackage complained about were apparently already installed
according to

apt-get install libssl-dev libglib2.0-dev libudev-dev libwrap0-dev
libpci-dev gcc-5-arm-linux-gnueabi:native

  So I tried it with -d  and got *lot* of compiling ending with the failures and
  requiring some missing parts to be installed...

  * missing arm-linux-gnueabi-gcc - installed the package gcc-arm-linux-gnueabi
  * missing openssl/opensslconf.h: - installed libssl-dev:armel
  * missing libpci - installed libpci-dev:armel
  * missing libwrap - installed libwrap0-dev:armel

Glad I found out about the -nc option to avoid the lengthy
rebuilding from scratch...

  * Hmm apparently the complaints were valid - but for the armel packages!

Thanks again.

Andrew

cross building linux-image packages

2016-10-31 Thread Andrew Worsley 
Can some one direct me to information on how to cross build debian
kernel packages?

I tried using pbuilder (based off
https://jodal.no/2015/03/08/building-arm-debs-with-pbuilder/) but ->
qemu-arm-static has bugs (segmentation faults - possibly
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087

which blocks that path.

But I see that buildd (
https://buildd.debian.org/status/logs.php?pkg=linux=armel )
apparently works some how.

I am looking at
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

In particular trying to do

  fakeroot make -f debian/rules.gen binary-arch_armel_none

but that doesn't seem work  (gcc-5 command not found?) under jessie -
now looking at under stretch...

But I think I am straying too far from the beaten track and hitting
lots of problems - hence the question about where information on what
people are normally doing to cross build the kernel using debian
packages.

Andrew

Re: cross building linux-image packages

2016-10-31 Thread Andrew Worsley 
On 1 November 2016 at 10:58, Christian Seiler <christ...@iwakd.de> wrote:
> On 11/01/2016 12:22 AM, Andrew Worsley wrote:
>> I tried using pbuilder (based off
>> https://jodal.no/2015/03/08/building-arm-debs-with-pbuilder/) but ->
>> qemu-arm-static has bugs (segmentation faults - possibly
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087
>
> You can use (in your pbuilderrc)
> PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic"
> to make pbuilder use a different (much slower, and in edge cases
> possibly problematic) dependency-resolution algorithm. In that
> case aptitude will never be invoked and builds in qemu-user
> chroots will mostly work - with possibly some exceptions. I've
> never tried a kernel build in such a setup though.

Thank-you very much Christian, that variable does indeed avoid the qemu crash.

I'm hitting other errors now
OS=debian DIST=stretch ARCH=armel pbuilder --build linux_4.7.8-1.dsc

 -> Considering build-dep gcc-5 [alpha amd64 arm64 armel armhf hppa
i386 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sh4 sparc64]
   -> Trying gcc-5
 -> Considering build-dep gcc-5-alpha-linux-gnu:native [alpha]
   -> This package is not for this architecture
 -> Considering build-dep gcc-5-x86-64-linux-gnu:native [amd64]
   -> This package is not for this architecture
 -> Considering build-dep gcc-5-aarch64-linux-gnu:native [arm64]
   -> This package is not for this architecture
 -> Considering build-dep gcc-5-arm-linux-gnueabi:native [armel]
   -> Trying gcc-5-arm-linux-gnueabi:native
   -> Cannot install gcc-5-arm-linux-gnueabi:native; apt errors follow:
...

But stretch has gcc-6 ? - anyway much more managable problem than
qemu-arm-static seg fault!

But using a different .dsc file:
OS=debian DIST=stretch ARCH=armel pbuilder --build linux-latest_75.dsc

With this .dsc file It can find gcc-5 ?

Get:35 ftp://218.100.43.30/debian stretch/main armel gcc-5 armel
5.4.1-3 [5297 kB]

I am guessing there is a ton of extra detail to these .dsc files and
kernel building - long learning curve ahead of me but it is actually
BUILDING now!

> Note that qemu-user chroots are _really_, _really_ slow. Builds
> can take anywhere from 3 to 20 times as long as on native
> hardware. (For other packages, in my experience building armhf
> in qemu-user chroots on amd64 is ~12 times slower. YMMV.)
.

I'll see how far it goes and if my patience will make it.
But as a practical scheme it sounds like I will likely need to go another way.

> Alternatively, you can actually cross-compile stuff by
> employing a real cross compiler that runs natively on your
> hardware (hence faster) but generates code for the target
> hardware you're looking at. The build system of a package must
> support cross compiling explicitly for this to work and be
> useful, I've never tried the kernel packages, so I don't know
> if that will work. You can get a pointer on how to actually
> cross-compile Debian packages under:
> https://wiki.debian.org/CrossCompiling

..
Thanks for this link - it points to schroot - so perhaps that is the
way forward as you suggest it will be *extremely* slow (although for
the small random package appears to be quite practical).


>> But I see that buildd (
>> https://buildd.debian.org/status/logs.php?pkg=linux=armel )
>> apparently works some how.
>
> Well, the official Debian buildds for armhf/armel actually run on
> ARM hardware, so that's why the "work". ;-)
>
> Regards,
> Christian

Ok that explains the current best practices that Debian uses now. I
guess in the past they used schroot.

Thanks again I am so much happier that I have some options to move forwards.

Andrew

Trying to build both linux kernel + kernel/debian from .git

2016-12-21 Thread Andrew Worsley 
Help appreciated on how these two .git repositories are expected to
work together. Or just if they are not meant to.

I am trying to do a git bisect to see when the hibernation bug#844788 (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844788 )

I have checked out the mainline kernel into linux and then checked out
https://anonscm.debian.org/git/kernel/linux.git  into
   /build/linux/debian-linux

- which apprently gives a debian directory for the kernel .

I then do a symbolic link from with the mainline linux checkout to the
debian directory check out:

debian -> /build/linux/debian-linux/debian

Using git tag -l to find a suitable tag and then select the kernel a
similar tag and build the release and install it and see if it works.

But this doesn't seem to work at all  so I guess is completely wrong

I get errors like:

fakeroot make -f debian/rules -n binarymacbook: 2:51PM
dh_testdir
make -f debian/rules.gen binary-indep
make[1]: Entering directory '/build/deb-linux'
make[1]: debian/rules.gen: No such file or directory
make[1]: *** No rule to make target 'debian/rules.gen'.  Stop.
make[1]: Leaving directory '/build/deb-linux'
debian/rules:46: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2

I was trying to just compile mainline kernels (no debian patches) via

make deb-pkg


Kinda of getting stuck -Hitting problems where ever I turn to. Recent
4.9 kernels compile and run - but hibernate doesn't restore

My mainline 3.18 kernel + initrd just crash without any output after
booting from grub when building with a stretch based system (needs a
few patches to compile them).

I am suspecting the stretch based system might be causing the older
kernels problems. Perhaps using containers to build them under older
releases might fix things?

I am thinking I need a working serial port (not a laptop) to debug the
restore crashes or perhaps try and reproduce things via kvm?

No easy paths...

Andrew

Missing firmware files

2019-03-09 Thread Andrew Worsley 
After the latest upgrade of buster I get this list of missing files
when it rebuilt my initramfs. The files are not in my current
firmware-misc-nonfree 20190114-1

I don't know where they might be found - or how important they are.

My suspend to ram is no longer working - I wondering if this is
related but this is a troublesome MacBookPro10,1 with regard to
hibernating so it my be unrelated.

Thanks for any suggestions

Andrew


Processing triggers for initramfs-tools (0.133) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-2-amd64
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/sig.bin
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/image.bin
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/desc.bin
for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/nvdec/scrubber.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/sw_method_init.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/sw_bundle_init.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/sw_nonctx.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_ctx.bin
for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_sig.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_data.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_inst.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_bl.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/fecs_sig.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/fecs_data.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/fecs_inst.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_bl.bin
for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/acr/ucode_load.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/bl.bin for
module nouveau

Re: Asahi Linux Support - any plans?

2022-08-05 Thread Andrew Worsley 
I believe the Asahi team has them all submitted via the various relevant
maintainers
and they are working their way through the groups. Some patches make
significant
changes and there is obviously discussion about whether they need to be
reworked
before being passed up.

That said there was this recently on the 5.19 kernel release from Linus
Torvalds...

https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rcz7w28fj_o02s0xi0oeq3h1uqgodfvhg...@mail.gmail.com/T/#u

"...

On a personal note, the most interesting part here is that I did the
release (and am writing this) on an arm64 laptop. It's something I've
been waiting for for a _loong_ time, and it's finally reality, thanks
to the Asahi team. We've had arm64 hardware around running Linux for a
long time, but none of it has really been usable as a development
platform until now.
..."


On Fri, 5 Aug 2022 at 16:06, Marc Haber 
wrote:

> On Fri, Aug 05, 2022 at 11:36:40AM +1000, Andrew Worsley wrote:
> > Thanks Diederik, so I'm guessing 173 is way too much but a lot of it
> might
> > not
> > be critical to something running on the M1 (versus M2).
> >
> > If I was to find a smaller set of say 10 patches to 5.19 that booted a
> > usable
> > system would I be able to submit those patches some where for building
> > (arm64 of course)?
>
> Is there any reason why you don't take those patches upstream where they
> belong?
>
> Greetings
> Marc
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>

Re: Asahi Linux Support - any plans?

2022-08-04 Thread Andrew Worsley 
On Fri, 5 Aug 2022 at 02:00, Diederik de Haas  wrote:

> On donderdag 4 augustus 2022 14:40:14 CEST Andrew Worsley wrote:
> > I am wondering if there are any plans for supporting Asahi/M1 linux in
> > the debian kernels?
> > At the moment there are about 173 patches from the v5.19 kernel - see
> > https://paste.debian.net/1249157/
>
> The normal course of action is to get it included in the upstream linux
> kernel
> first and then Debian will pick it up 'automatically' at some point.
> If there are kernel modules that need to be enabled, then that is
> something
> that needs to be done on the Debian kernel side, but it would still need
> to be
> available in the upstream kernel (first).
>
> HTH


Thanks Diederik, so I'm guessing 173 is way too much but a lot of it might
not
be critical to something running on the M1 (versus M2).

If I was to find a smaller set of say 10 patches to 5.19 that booted a
usable
system would I be able to submit those patches some where for building
(arm64 of course)?

Andrew

Re: Asahi Linux Support - any plans?

2022-08-06 Thread Andrew Worsley 
The patches are being put upstream by developers far better than me -
but it will take time.
I just had a painful time trying to trim down the patchset but it's
not likely to be below 100 for a while yet.
The Asahi team are doing a good job of keeping them rebased onto the
latest kernel and I'm using
debian bookworm + Asahi kernel on an M1 MacBook Air very nicely as my
work and general machine.

I was thinking if it is fairly easy to build a "feature-set" for M1/M2
that is pretty functional - it would allow the
work to progress on getting the debian installer working for it for
bookworm. The initial installing part is quite complex
as there is no way around booting into apple's recovery mode to set up
the boot stub.
Once that is done then you can build and install Asahi kernels
packages as normal:

make -j 8 bindeb-pkgdpkg -i
../linux-image-5.19.0-asahi-1-gddbaa60fc907_5.19.0-asahi-1-gddbaa60fc907-9_arm64.deb

No need to touch the installer again

If the bookworm debian installer supports apple M1 it will be really
useful to many people.

Andrew

On Fri, 5 Aug 2022 at 16:06, Marc Haber  wrote:
>
> On Fri, Aug 05, 2022 at 11:36:40AM +1000, Andrew Worsley wrote:
> > Thanks Diederik, so I'm guessing 173 is way too much but a lot of it might
> > not
> > be critical to something running on the M1 (versus M2).
> >
> > If I was to find a smaller set of say 10 patches to 5.19 that booted a
> > usable
> > system would I be able to submit those patches some where for building
> > (arm64 of course)?
>
> Is there any reason why you don't take those patches upstream where they
> belong?
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Asahi Linux Support - any plans?

2022-08-04 Thread Andrew Worsley 
I am wondering if there are any plans for supporting Asahi/M1 linux in
the debian kernels?
At the moment there are about 173 patches from the v5.19 kernel - see
https://paste.debian.net/1249157/

Is that too many to be practical for debian arm64 building?

What about an experimental kernel?

Is a separate package more suitable?

Who would I talk to about debian installer support.

I tried asking on debian-kernel IRC but it seems to be mostly
automated postings.

Thanks

Andrew

Bug#752881: linux-image-3.2.0-4-amd64: bluRay writer can't write under wheezy kernel (I/O error: Unhandled sense code) but ok under squeeze

2014-06-27 Thread Andrew Worsley andrew.worsley 
Package: src:linux
Version: 3.2.57-3+deb7u2
Severity: normal

Dear Maintainer,

   Under this linux-image-3.2.0-4-amd64 kernel my blu Ray writer [sr1] has 
severe problems so that I can not writer a Blu Ray with it.
But it writes perfectly under the older squeeze linux-image-2.6.32-5-amd64 
kernel. This is how I presently work around the problem (boot the
older kernel). It produces endless errors of the form:

Jun  7 14:08:36 azza kernel: [569395.478041] end_request: I/O error, dev sr1, 
sector 0
Jun  7 14:08:36 azza kernel: [569395.481744] sr 6:0:0:0: [sr1] Unhandled sense 
code
Jun  7 14:08:36 azza kernel: [569395.481746] sr 6:0:0:0: [sr1]  Result: 
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun  7 14:08:36 azza kernel: [569395.481748] sr 6:0:0:0: [sr1]  Sense Key : 
Blank Check [current] 
Jun  7 14:08:36 azza kernel: [569395.481751] sr 6:0:0:0: [sr1]  Add. Sense: No 
additional sense information
Jun  7 14:08:36 azza kernel: [569395.481754] sr 6:0:0:0: [sr1] CDB: Read(10): 
28 00 00 00 00 00 00 00 01 00
...

   Googling around I hit upon this 
http://forums.debian.net/viewtopic.php?f=7t=111795start=30 which references 
https://lkml.org/lkml/2014/5/9/363
   and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701201
   which suggested : libata.atapi_passthru16=0 is needed by some hardware

   I tried this which allowed me to write about half a bluRay and then it 
failed - leaving a half written unusable disc !

   Would love a fix to avoid having to flick back to the older kernel which is 
really inconvient to others.


   Thinking about trying to build kernels back to 2.6.32 and seeing where the 
break is - but 2.6.32 appears to have *LOTS* of problems compiling with the 
wheezy
   set up (gcc 4.7.2)...

   Perhaps Jessie might be a better direction - but really want to run a stable 
kernel on this machine as it is used by other people.

   Andrew


-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.57-3+deb7u2

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=c5c1b15a-a6fc-11e0-a2f4-001e8c7db70d ro nmi_watchdog=1 
libata.atapi_passthru16=0

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   30.012531] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.014528] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.016534] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.018571] end_request: I/O error, dev sr1, sector 0
[   30.029441] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.031425] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.033432] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.035432] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.037440] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.039476] end_request: I/O error, dev sr1, sector 0
[   30.050342] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.052329] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.054327] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.056332] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.058334] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.060376] end_request: I/O error, dev sr1, sector 0
[   30.071236] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.073223] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.075221] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.077225] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.079223] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.081266] end_request: I/O error, dev sr1, sector 0
[   30.092129] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.094107] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.096117] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.098117] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.100123] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.102159] end_request: I/O error, dev sr1, sector 0
[   30.113029] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.115015] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.117024] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.119024] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.121029] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.123067] end_request: I/O error, dev sr1, sector 0
[   30.133933] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.135916] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.137924] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.139921] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.141927] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00