Re: Zero Divide in Kernel 3.12-rc4
Geert, To pinpoint where in sd_completed_bytes this happens, I'd need the sd_mod module and the module symbol map. /* be careful ... don't want any overflows */ u64 factor = scmd->device->sector_size / 512; do_div(start_lba, factor); do_div(end_lba, factor); scmd->device->sector_size should be 512, so factor should be 1. Let's try a bit harder with a fresher mind and a cup of coffee and a mini-twix: [77568.32] PC: [<0484c33a>] sd_completed_bytes+0x90/0xe8 [sd_mod] [77568.33] SR: 2000 SP: 00277e58 a2: 0027e2e4 [77568.34] d0: d1: 007735a0d2: d3: 0001 [77568.35] d4: d5: 007735a8a0: 024dd000a1: 024a0ea0 [77569.19] Code: 4a80 6704 4c42 0001 2c01 2207 4c42 1406 <2c00> 2e01 2004 2204 6704 4c42 0001 2801 2205 4c42 1404 2800 2a01 202e fff8 222e "4c42" is a division. It's the second one of the four divisions: 0: 4a80 tstl %d0 d0 is zero, so the first division is skipped. 2: 6704 beqs 0x8 4: 4c42 0001 divull %d2,%d1,%d0 8: 2c01 movel %d1,%d6 a: 2207 movel %d7,%d1 c: 4c42 1406 divul %d2,%d6,%d1 It's dividing by d2, which is zero. So scmd->device->sector_size must be smaller than 512 (probably zero). Thanks for parsing the dump - now I'll have to find out how on earth sector_size got overwritten in the first place ... and whether anyrhing in scmd-> device still makes any sense at all. Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/335d2ba0b0b19e56b2880882a1c4c...@biophys.uni-duesseldorf.de
Re: Bits from the Release Team (Jessie freeze info)
Hi Niels, This was quite interesting as it seems to tie in with some other projects that are already being pursued... On 21/10/13 16:42, Niels Thykier wrote: > I would love for us to have an automated system to give us a > "weather-report" on the toolchain for each architecture. It would be > nice both for us to see how ports are doing and for porters to spot and > fix problems early. That sounds a lot like the purpose of Jenkins[0], but I'm not sure if it's exactly suitable. It seems a little heavy, that someone could more easily be able to script some cron jobs for a task than learn how to use it. And Jenkins isn't available yet on all arches; some ports may not have hardware powerful enough to run it. Maybe that doesn't matter - a single Jenkins instance might be able to launch jobs via remote shells to other boxes, running the actual test suite there, or maybe just to fetch, analyse and report on the resulting log files. Ideally I'd like to see a set of command-line scripts runnable either from cron, or maybe someday by Jenkins jobs if someone wants to set that up. And packaged up for people to use at home! [0]: http://jenkins.debian.net/ > Which implies "a set of packages" being "the current version of the > overwhelming part of the archive" plus all of d-i. However, that is not > something you "just build", so having a smaller set as a basic test > would probably be way more useful. I am not aware of such a "basic test > set", so feel free to propose one. Some people have been trying to identify small sets of essential packages already, in the context of bootstrapping an architecture[1]. I wonder if that's likely to overlap with this? It encompasses toolchain and essential arch-specific packages. I imagine a healthy port should be able to bootstrap itself with only current package versions. If this was being tested regularly it could let porters know if circular dependencies are introduced, for example. [1]: https://wiki.debian.org/DebianBootstrap#Toolchain I would maybe take that a little further and say that a system is only stable if it can bootstrap itself, install and boot into the resulting system, and repeat the whole process again... > I like the "toolchain nightly" thing as well. I don't think it is > "required", but it sounds like the kind of thing that would help people > spot issues sooner rather than later! And this also ties in with the reproducible-builds project[2] (not sure if you were hinting at that before). The 'toolchain' is of particular concern because the security of the whole system depends on it. Differences in the output of builds needs to be avoided, or otherwise explained. It would help greatly if there were frequent builds happening so we could see unexpected changes occurring. [2]: https://wiki.debian.org/ReproducibleBuilds So if something can make something that fulfills all the above goals it would certainly be beneficial :) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5266df9d.9040...@pyro.eu.org
Re: Zero Divide in Kernel 3.12-rc4
Hi Geert, To pinpoint where in sd_completed_bytes this happens, I'd need the sd_mod module and the module symbol map. /* be careful ... don't want any overflows */ u64 factor = scmd->device->sector_size / 512; do_div(start_lba, factor); do_div(end_lba, factor); scmd->device->sector_size should be 512, so factor should be 1. Looking at a bit of context right above what you quote here, we can be reasonably certain that scmd->device->sector_size is greater or equal 512. Ingo - could you add if (scmd->device->sector_size > 2048) sdev_printk(KERN_ERR, scmd->device, "Whoa - large secor size %d\n", scmd->device->sector_size); before the do_div calls, and see what that reports? Cheers, Michael Let's try a bit harder with a fresher mind and a cup of coffee and a mini-twix: [77568.32] PC: [<0484c33a>] sd_completed_bytes+0x90/0xe8 [sd_mod] [77568.33] SR: 2000 SP: 00277e58 a2: 0027e2e4 [77568.34] d0: d1: 007735a0d2: d3: 0001 [77568.35] d4: d5: 007735a8a0: 024dd000a1: 024a0ea0 [77569.19] Code: 4a80 6704 4c42 0001 2c01 2207 4c42 1406 <2c00> 2e01 2004 2204 6704 4c42 0001 2801 2205 4c42 1404 2800 2a01 202e fff8 222e "4c42" is a division. It's the second one of the four divisions: 0: 4a80 tstl %d0 d0 is zero, so the first division is skipped. 2: 6704 beqs 0x8 4: 4c42 0001 divull %d2,%d1,%d0 8: 2c01 movel %d1,%d6 a: 2207 movel %d7,%d1 c: 4c42 1406 divul %d2,%d6,%d1 It's dividing by d2, which is zero. So scmd->device->sector_size must be smaller than 512 (probably zero). Thanks for parsing the dump - now I'll have to find out how on earth sector_size got overwritten in the first place ... and whether anyrhing in scmd-> device still makes any sense at all. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9f57bf0fdf7329055ee5f7d2b2fe9...@biophys.uni-duesseldorf.de
Re: Bits from the Release Team (Jessie freeze info)
Steven Chamberlain writes: > On 21/10/13 16:42, Niels Thykier wrote: >> I would love for us to have an automated system to give us a >> "weather-report" on the toolchain for each architecture. It would be >> nice both for us to see how ports are doing and for porters to spot and >> fix problems early. > > That sounds a lot like the purpose of Jenkins[0], but I'm not sure if > it's exactly suitable. It seems a little heavy, that someone could more > easily be able to script some cron jobs for a task than learn how to > use it. It's actually a pretty low barrier to entry, if you know what commands you need to run, it's pretty easy to get started with jenkins (create job, have it execute shell commands, write shell in box, hit build). I'd say that it's about 10 times more likely you'll get it right in Jenkins before you get it right in cron. > And Jenkins isn't available yet on all arches; some ports may not have > hardware powerful enough to run it. Maybe that doesn't matter - a > single Jenkins instance might be able to launch jobs via remote shells > to other boxes, running the actual test suite there, or maybe just to > fetch, analyse and report on the resulting log files. Jenkins can have slaves on remote hosts, via SSH. It runs a small java app there, so as long as the arch has a JVM then you're pretty right. -- Stewart Smith pgpbBHKODKgwm.pgp Description: PGP signature
Re: Bits from the Release Team (Jessie freeze info)
On Wed, Oct 23, 2013 at 12:36 AM, Stewart Smith
wrote:
> Jenkins can have slaves on remote hosts, via SSH. It runs a small java
> app there, so as long as the arch has a JVM then you're pretty right.
For whatever definition of small. I've seen it consuming 1 GiB of memory...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/camuhmdvz3jwmdujds762z-cnhv4z5c9wuuf5rkanarqbsdx...@mail.gmail.com
