Ingo,
any further news on this one?
Well, not really, I think... but this might be good news. ;)
Indeed - at the very least it shows it is a rare error.
Yesterday there were two media sense errors on /dev/sda on Spice
(A3000/040 with Warpengine, so no ESP), but I guess that's a real
m
Ingo J�rgensmann dixit:
>Yesterday there were two media sense errors on /dev/sda on Spice
>(A3000/040 with Warpengine, so no ESP), but I guess that's a real
Try writing (512 bytes of zero) to those sectors, that often
triggers bad block reallocation. (It can’t do that on uncorrectable
read errors
Am 03.11.2013 um 07:55 schrieb Michael Schmitz
:
> any further news on this one?
Well, not really, I think... but this might be good news. ;)
Yesterday there were two media sense errors on /dev/sda on Spice (A3000/040
with Warpengine, so no ESP), but I guess that's a real media error, especial
Hello Ingo,
any further news on this one?
Cheers,
Michael
On 2013-10-22 22:38, Michael Schmitz wrote:
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,
On Tue, Oct 22, 2013 at 10:38 PM, Michael Schmitz
wrote:
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->devic
Hi Ingo,
Nah, executables are padded and aligned.
Small deltas like this do not normally show up.
My feelings exactly.
Now I hope the new kernel does print something enlightening ...
Well, we'll see... I have booted Akire now with that kernel. Runs fine the last
hour so far... ;-
Am 24.10.2013 um 09:18 schrieb Michael Schmitz
:
>> Nah, executables are padded and aligned.
>> Small deltas like this do not normally show up.
> My feelings exactly.
> Now I hope the new kernel does print something enlightening ...
Well, we'll see... I have booted Akire now with that kernel. R
Ingo,
Ingo Jürgensmann dixit:
does show up that string, so it should be fine. But I'd have expected
a different kernel size because there's some extra code and some
additional text.
Nah, executables are padded and aligned.
Small deltas like this do not normally show up.
My feelings exactly
Ingo Jürgensmann dixit:
> does show up that string, so it should be fine. But I'd have expected
> a different kernel size because there's some extra code and some
> additional text.
Nah, executables are padded and aligned.
Small deltas like this do not normally show up.
bye,
//mirabilos
--
Bew
On 2013-10-24 06:56, Michael Schmitz wrote:
... will rebuilt and install it then...
Precisely what I meant, thanks.
Only problem is: the kernel is exactly that large as the old kernel
before, although I did a "make clean" inbetween. But a "strings vmlinux
| grep -i whoa" does show up that st
Hi Ingo,
On 2013-10-22 22:38, Michael Schmitz wrote:
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?
Ok, so, drivers/scsi/sd.c looks
On 2013-10-22 22:38, Michael Schmitz wrote:
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?
Ok, so, drivers/scsi/sd.c looks now as this
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);
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);
On Mon, Oct 21, 2013 at 9:34 AM, Michael Schmitz
wrote:
> this looks like it might be related to the ESP driver - scsi_finish_command
> called from the swapper process during apt-get dist-upgrade does seem
> plausible.
>
> Some of the Amiga SCSI drivers did fiddle with the chip interrupt enable on
Ingo,
this looks like it might be related to the ESP driver -
scsi_finish_command called from the swapper process during apt-get
dist-upgrade does seem plausible.
Some of the Amiga SCSI drivers did fiddle with the chip interrupt
enable on SCSI interrupt entry, but I'd have thought the ESP co
Geert Uytterhoeven dixit:
>BIG FAT WARNING for Thorsten: 3.10.7 does _not_ have this fix!
Debian 3.10.7-1 does have it (as Debian-specific patch).
Otherwise my buildd couldn’t run that kernel as it uses btrfs.
bye,
//mirabilos
--
Beware of ritual lest you forget the meaning behind it.
yeah bu
On Sun, Oct 20, 2013 at 12:25 PM, Ingo Jürgensmann
wrote:
>> However, the addresses and the code above don't match the kernel image in
>> linux-3.12.0-rc4-amiga-m68k.tar.gz?
>> Can we get the image somewhere?
>
> I can give you access to the VM with the (patched) kernel source where I
> crosscomp
Am 20.10.2013 um 12:10 schrieb Geert Uytterhoeven :
> However, the addresses and the code above don't match the kernel image in
> linux-3.12.0-rc4-amiga-m68k.tar.gz?
> Can we get the image somewhere?
I can give you access to the VM with the (patched) kernel source where I
crosscompiled the image
On Sun, Oct 20, 2013 at 11:37 AM, Ingo Jürgensmann
wrote:
> I'm testing the ESP SCSI driver port by Tuomas and Michael to 3.12-rc4 and
> got now this kernel panic during heavy disk activity (apt-get dist-upgrade
> and parallel a rsync backup by BackupPC):
>
> Debian GNU/Linux jessie/sid spice ttyS
Hi!
I'm testing the ESP SCSI driver port by Tuomas and Michael to 3.12-rc4
and got now this kernel panic during heavy disk activity (apt-get
dist-upgrade and parallel a rsync backup by BackupPC):
Debian GNU/Linux jessie/sid spice ttyS0
spice login: [77568.07] *** ZERO DIVIDE *** FORMAT
21 matches
Mail list logo
