The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
device set up in the old pata_falcon probe code.
Signed-off-by: Michael Schmitz
--
Changes from v1
- drop obsolete ATA_HD_BASE define
- use dev_err() to report
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup code in preparation for this.
Signed-off-by: Michael Schmitz
--
Changes from RFC
- fix region size (spotted by Szymon Bieganski
[Resend because linux-m68k was dropped from the recipient list ...]
As suggested by Geert, at least one of the drivers available for the Falcon
IDE interface should be converted to a platform device driver (to enable
module autoloading by the Debian installer).
Add platform device for Falcon
Hi Geert,
thanks for your feedback!
Am 04.09.2019 um 00:44 schrieb Geert Uytterhoeven:
Hi Michael,
On Tue, Jul 2, 2019 at 12:02 AM Michael Schmitz wrote:
The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
Hi Adrian,
try adding 'initcall_debug' to the kernel command line.
Cheers,
Michael
On 11/09/19 10:39 PM, John Paul Adrian Glaubitz wrote:
On 9/11/19 12:13 PM, John Paul Adrian Glaubitz wrote:
On 9/11/19 12:07 PM, John Paul Adrian Glaubitz wrote:
I just tried booting kernel 5.3.0 (as
;
> Am 07.08.19 um 00:41 schrieb Michael Schmitz:
>> Hi Geert,
>>
>> could be renamed shifter_st, I suppose. Only used in
>> arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c.
> looks like you've come to a solution. Is there any action required from
> my
Hi Geert,
could be renamed shifter_st, I suppose. Only used in
arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c.
Cheers,
Michael
On 6/08/19 7:33 PM, Geert Uytterhoeven wrote:
CC linux-m68k (shifter too generic a name?)
On Tue, Aug 6, 2019 at 5:00 AM kbuild test robot wrote:
Hi Geert,
Am 31.07.19 um 20:20 schrieb Geert Uytterhoeven:
> Hi Finn,
>
> On Wed, Jul 31, 2019 at 9:47 AM Finn Thain wrote:
>> On Wed, 31 Jul 2019, Greg Ungerer wrote:
>>> No, not sufficient. You still get the following warnings after
>>> just moving that include of atarihw.h:
>>>
>>> CC
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup code in preparation for this.
Signed-off-by: Michael Schmitz
--
Changes from RFC
- fix region size (spotted by Szymon Bieganski
The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
device set up in the old pata_falcon probe code.
Signed-off-by: Michael Schmitz
---
drivers/ata/pata_falcon.c | 39 +++
1
As suggested by Geert, at least one of the drivers available for the Falcon
IDE interface should be converted to a platform device driver (to enable
module autoloading by the Debian installer).
Add platform device for Falcon IDE (patch 1), and rewrite the present
libata driver to make use of that
Mike,
Am 29.06.2019 um 23:30 schrieb Mike Rapoport:
Hi Geert,
Sorry for the delay, I've been mostly offline during last weeks.
On Thu, Jun 20, 2019 at 06:46:28PM +0200, Geert Uytterhoeven wrote:
Hi Mike,
On Wed, Jun 19, 2019 at 4:18 PM Mike Rapoport wrote:
On Wed, Jun 19, 2019 at
Hi Geert,
On 25/06/19 7:51 PM, Geert Uytterhoeven wrote:
Hi Michael,
On Thu, Jun 20, 2019 at 10:47 PM Michael Schmitz wrote:
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup
Sergei,
Am 23.06.2019 um 21:06 schrieb Sergei Shtylyov:
Hello!
On 20.06.2019 23:47, Michael Schmitz wrote:
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup code in preparation
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup code in preparation for this.
Add Falcon IDE base address in Atari hardware address header.
Signed-off-by: Michael Schmitz
The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
device set up in the old pata_falcon probe code.
Signed-off-by: Michael Schmitz
---
drivers/ata/pata_falcon.c | 39 +++
1
As suggested by Geert, at least one of the drivers available for the Falcon
IDE interface should be converted to a platform device driver (to enable
module autoloading by the Debian installer).
Add platform device for Falcon IDE (patch 1), and rewrite the present
libata driver to make use of that
Hi Adrian,
On 11/06/19 9:00 AM, John Paul Adrian Glaubitz wrote:
On 6/10/19 10:55 PM, John Paul Adrian Glaubitz wrote:
On 6/10/19 10:49 PM, Michael Schmitz wrote:
Happy to do that, but elgar has a single memory chunk only (on the accelerator
board). Not sure what we hope to learn from
Hi Adrian,
On 11/06/19 8:23 AM, John Paul Adrian Glaubitz wrote:
On 6/10/19 9:59 PM, Geert Uytterhoeven wrote:
Anyone with an Amiga with 2 discontiguous chunks Fast RAM
(e.g. A3000/4000 with motherboard and accelerator RAM) who can give
this a try?
Sure, we can test this on elgar (A4000 with
Hi Geert, Mike,
I hadn't tested that series on actual hardware (just on ARAnyM), but as
it didn't appear to have any substantial changes from the previous one,
no objections from me.
Enabling out-of-order memory still gives me the nonzero mapcount errors,
though the additional memory does
Hi Mike,
sorry, haven't had time to test this one yet.
Thanks for updating the description - note that the case of out-of-order
memory chunks does not only apply to ST-RAM/Fast-RAM on Atari. AFAIK it
can also happen with certain memory expansion boards for Amiga.
What would be required to
Hi Mike,
(recipient list fixed up ...)
Am 12.05.2019 um 19:45 schrieb Michael Schmitz:
I can't say I really understand the reason for inability to use ST-RAM as
normal memory if the kernel was loaded into the FastRAM, maybe with
sprase
it would be easier to fix it.
As far as I remember
in 'normal'memory allocations?
Haven't seen any evidence to the contrary, but I've not put the system
under any kind of memory pressure.
With these caveats:
Tested-By: Michael Schmitz
Cheers,
Michael
The section size of 16M was chosen pretty much arbitrarily as I couldn't
find specs
Eero,
Am 02.05.2019 um 09:34 schrieb Eero Tamminen:
Hi,
Before going for vacation I had changed Hatari call stack handling
to deal with kernel stack manipulations (changing rts to a jump)
by brute force. Call stack output has now also symbol offset info.
I used these to look at the random
Hi Eero,
Am 15.04.2019 um 10:49 schrieb Eero Tamminen:
Hi,
On 4/13/19 2:11 AM, Michael Schmitz wrote:
[...]
Here problem is the second value in stack.
Maybe missing auto-increment when auto-increment instruction page faults
causes later issues, when bus errors with them are ignored.
=> I
Eero
Am 13.04.2019 um 09:43 schrieb Eero Tamminen:
Hi,
On 4/12/19 9:52 AM, Michael Schmitz wrote:
Am 12.04.2019 um 11:03 schrieb Eero Tamminen:
[...]
* Stack is always shown, but call trace following it is always empty.
Is call trace explicitly disabled for m68k task list?
No, must
Hi Eero,
Am 13.04.2019 um 09:43 schrieb Eero Tamminen:
Hi,
On 4/12/19 9:52 AM, Michael Schmitz wrote:
Am 12.04.2019 um 11:03 schrieb Eero Tamminen:
[...]
* Stack is always shown, but call trace following it is always empty.
Is call trace explicitly disabled for m68k task list?
No, must
Hi Eero,
Am 13.04.2019 um 10:53 schrieb Eero Tamminen:
...> You may want to give this a spin, to see whether it fixes your syscall
errors.
I tried the bus_error030() patch.
I still get sometimes:
---
Data read fault at 0x801740c4 in Super Data
Hi Finn,
Am 12.04.2019 um 21:39 schrieb Finn Thain:
On Fri, 12 Apr 2019, Michael Schmitz wrote:
=> I think the problem is that 'I' kthreads have NULL "current_pwq".
Confirmed by the patch you attached so your analysis seems right.
And offset_of(struct poll_workqueue, wq)
Hi Eero,
Am 12.04.2019 um 11:03 schrieb Eero Tamminen:
Hi,
On 4/11/19 5:10 AM, Michael Schmitz wrote:
[...]
OK, I decided to bite the bullet and modify bus_error030() to allow
falling through to do_page_fault if an invalid page read happens while
page faults are disabled.
[...]
Resulting
Hi Finn,
Am 11.04.2019 um 18:54 schrieb Finn Thain:
On Wed, 10 Apr 2019, Michael Schmitz wrote:
What would happen if we just ignore the fault, and let
print_worker_info() carry on?
Unforunately I don't have access to a Motorola '040 or '060 right now, but
if you do, it might provide us
On 10/04/19 10:07 AM, Michael Schmitz wrote:
A potentially good question is why kthread_probe_data() would return
NULL on 030:
/**
* kthread_probe_data - speculative version of kthread_data()
* @task: possible kthread task in question
*
* @task could
Hi Finn,
Am 10.04.2019 um 14:42 schrieb Finn Thain:
On Wed, 10 Apr 2019, Michael Schmitz wrote:
On 10/04/19 12:58 PM, Finn Thain wrote:
On Wed, 10 Apr 2019, Michael Schmitz wrote:
A potentially good question is why kthread_probe_data() would return
NULL on 030
Hi Finn,
On 10/04/19 12:58 PM, Finn Thain wrote:
On Wed, 10 Apr 2019, Michael Schmitz wrote:
A potentially good question is why kthread_probe_data() would return
NULL on 030:
/**
* kthread_probe_data - speculative version of kthread_data()
* @task: possible
Hi Eero,
On 10/04/19 8:07 AM, Eero Tamminen wrote:
Hi,
(I'm not on linux-m68k list, that's why I included everybody in
mail thread to CC.)
On 4/9/19 6:59 AM, Michael Schmitz wrote:
Yep, works for me as well (030 so probably no surprise):
Ok, now that it's been confirmed on real HW, I'll
Hi Andreas,
On 10/04/19 5:05 AM, Andreas Schwab wrote:
On Apr 09 2019, Michael Schmitz wrote:
Now the question I'm asking myself is: why does pagefault_disable() not
suppress the bus error here:
long __probe_kernel_read(void *dst, const void *src, size_t size)
{
long ret
Hi Finn,
Am 09.04.2019 um 17:25 schrieb Finn Thain:
On Tue, 9 Apr 2019, Michael Schmitz wrote:
Seems real enough to me.
I agree. I was wondering if you'd seen anything like it before but I see
that the question is redundant. Had anything like it come up before, I
reckon you would have
Hi Finn,
Yep, works for me as well (030 so probably no surprise):
[1489086.73] sysrq: SysRq : Show State
[1489086.75] taskPC stack pid father
[1489086.76] initS0 1 0 0x
[1489086.77] Stack from 00821fcc:
[1489086.77]
Hard to trigger (nfblock will be compiled in, for the vast majority of
users) but a real bug - LGTM.
Tested-by: Michael Schmitz
Am 01.02.2019 um 16:26 schrieb Chengguang Xu:
When calling register_blkdev() with specified major
device number, the return code is 0 on success.
So it seems
All,
is there anything further I could do to speed up acceptance of these
patches?
Cheers,
Michael
On 15/10/18 3:32 PM, Michael Schmitz wrote:
(hopefully) final version of the Amiga RDB partition table patch follows.
I've split off the part fixing the incorrect use of signed int
Hi Geert,
Am 30.01.2019 um 21:08 schrieb Geert Uytterhoeven:
The remainder is a fix for address wrap around when there is memory located
at the end of the 32-bit address space.
That part looks OK to me, and is still applicable.
I will retest with just the last part of the patch applied.
Kars,
On 28/01/19 9:35 PM, Kars de Jong wrote:
I think this calls for a proper platform device on the m68k side.
Yes. Who could add that?
I can. I would first like to have a more recent kernel that actually
boots though. It looks like the hp300_defconfig (which is what I used)
isn't quite
was added in response to checkpath complaints. So 2.0+ would be correct.
Thomas: does that suit your purpose?
Cheers,
Michael
On 21/01/19 6:43 AM, Andrew Lunn wrote:
On Fri, Jan 18, 2019 at 11:22:39AM +0100, Thomas Gleixner wrote:
Michael,
On Thu, 19 Apr 2018, Michael Schmitz wrote
Hi Dave,
Am 29.12.2018 um 09:43 schrieb David Miller:
From: Michael Schmitz
Date: Sat, 22 Dec 2018 10:30:58 +1300
Am 21.12.2018 um 13:10 schrieb David Miller:
And in particular this huge complicated Kconfig construct is not
maintainable at all.
We can trim this down a bit (for reasons
Christophe,
Am 30.12.2018 um 05:55 schrieb LEROY Christophe:
Michael Schmitz a écrit :
Hi Finn,
Am 29.12.2018 um 14:06 schrieb Finn Thain:
On Fri, 28 Dec 2018, LEROY Christophe wrote:
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 89f5154c40b6..99e5729d910d
in
Tested-by: Christian T. Steigies
Acked-by: Michael Schmitz
---
This patch temporarily disables CONFIG_NVRAM on Atari, to prevent build
failures when bisecting the rest of this patch series. It gets enabled
again with the introduction of CONFIG_HAVE_ARCH_NVRAM_OPS, once the
nvram_* global functions
Hi Finn,
Am 29.12.2018 um 15:34 schrieb Finn Thain:
On Sat, 29 Dec 2018, Michael Schmitz wrote:
IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to suggest.
Or (really going out on a limb here):
IS_BUILTIN(CONFIG_NVRAM) ||
( IS_MODULE(CONFIG_ATARI_SCSI) && IS
Hi Finn,
Am 29.12.2018 um 14:06 schrieb Finn Thain:
On Fri, 28 Dec 2018, LEROY Christophe wrote:
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 89f5154c40b6..99e5729d910d 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -755,9 +755,10 @@
Dave,
Am 21.12.2018 um 13:10 schrieb David Miller:
From: ALeX Kazik
Date: Wed, 19 Dec 2018 23:24:32 +0100
+ bool "PCMCIA NE2000 100MBit support"
+ default n
+ depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n
+ depends on MCF8390=n && NE2000=n && NE2K_PCI=n
Hi Geert,
Am 03.12.2018 um 20:49 schrieb Geert Uytterhoeven:
Hi Michael, Mike,
On Mon, Dec 3, 2018 at 5:53 AM Michael Schmitz wrote:
Am 03.12.2018 um 00:04 schrieb Mike Rapoport:
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated
Hi Mike,
Am 03.12.2018 um 00:04 schrieb Mike Rapoport:
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated differently, so probably the simplest way
would be just inform memblock that the ST-RAM is not available to it:
diff --git
Geert,
On 3/12/18 11:57 AM, Michael Schmitz wrote:
Only a single memory chunk (ST-RAM), and kernel loaded there.
Same here.
The only memory-related option I have in my ARAnyM config is
FastRAM = 256
and that works.
Andreas: can you please share your ARAnyM config, so we can reproduce
On 3/12/18 12:04 AM, Mike Rapoport wrote:
On Sat, Dec 01, 2018 at 11:51:52AM +1300, Michael Schmitz wrote:
Andreas,
Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz wrote:
Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
There's way more
Geert,
On 2/12/18 10:57 PM, Geert Uytterhoeven wrote:
On Fri, Nov 30, 2018 at 10:24 PM Michael Schmitz wrote:
Am 01.12.2018 um 10:12 schrieb Andreas Schwab:
On Nov 30 2018, Andreas Schwab wrote:
[0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
20180712 (GCC)) #3
Andreas,
Am 01.12.2018 um 08:57 schrieb Andreas Schwab:
[0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
[0.00] Saving 190 bytes of bootinfo
[0.00] console [debug0] enabled
[0.00] Atari hardware
Am 01.12.2018 um 12:09 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz wrote:
Doesn't work for me - with or without -s option I get the same
What -s option?
In the LILO section:
Args = -s root=/dev/hda1 debug=par stram_pool=2048k
Cheers,
Michael
Andreas,
Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz wrote:
Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
There's way more than the kernel that must fit in 14 MB.
I realize that. I only said to try and load the kernel to ST-RAM
Andreas,
Am 01.12.2018 um 10:12 schrieb Andreas Schwab:
On Nov 30 2018, Andreas Schwab wrote:
[0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
[0.00] Saving 190 bytes of bootinfo
[0.00] console
Am 01.12.2018 um 09:12 schrieb Jens Axboe:
On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
On Fri, 30 Nov 2018, Kees Cook wrote:
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
In order to comply with the CoC, replace with a hug.
I hope this is some kind of joke. How would
Hi Finn,
Am 25.11.2018 um 14:15 schrieb Finn Thain:
Maybe the timer interrupt has a sufficiently high priority and latency is
low? Maybe cia_set_irq() is really expensive?
I don't know the platform well enough so I'm inclined to revert. We can
benchmark gettimeofday syscalls on elgar but is
Am 20.11.2018 um 23:02 schrieb Andreas Schwab:
On Nov 20 2018, Linus Walleij wrote:
Yes you already see the same as I see: this chip MK68901 has
no less than four timers. I bet the kernel is just using one of them,
out of habit.
Note that not all timers can be used freely. Some of them
uniformly distributed.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
Tested-by: Michael Schmitz
---
TODO: find a spare counter for the clocksource, rather than hanging
it off the HZ timer.
It would be simpler to adopt the 'jiffies' clocksource here
(c.f. patch for the hp300 platform
Hi Finn,
Am 17.11.2018 um 11:49 schrieb Finn Thain:
On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:
The EBSA110 is probably in a similar boat - I don't remember whether it
had 16MB or 32MB as the maximal amount of memory, but memory was getting
tight with some kernels even running a
Hi Finn
Am 15.11.2018 um 12:54 schrieb Michael Schmitz:
That one does appear to work - different versions of ARAnyM, and
different userland versions though. I'll test that again with the setup
that saw c606b5cf902 fail.
Still fails on that emulator / userland.
Must be a quirk of ARAnyM
On 14/11/18 8:58 PM, Russell King - ARM Linux wrote:
Are you saying that's not possible on arm, because the current timer rundown
counter can't be read while the timer is running?
If I were to run a second timer at higher rate for clocksource, but keeping
the 10 ms timer as clock event
Hi Finn,
On 14/11/18 3:58 PM, Michael Schmitz wrote:
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work - different versions of ARAnyM, and
different userland
On 14/11/18 12:43 PM, Russell King - ARM Linux wrote:
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
You could remove the old arch_gettimeoffset API without
Hi Finn,
On 14/11/18 11:11 AM, Finn Thain wrote:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
hardware emulation is a little more complete.
You mean, 40 us resolution, right?
Sorry, typo. Should have been us of course
Hi Finn,
Am 13.11.2018 um 19:15 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
(It appears that a QEMU-emulated Mac does not benefit from having a
clocksource that's more accurate than the 'jiffies' clocksource, in
spite of "clocksource: Switched to clocksource
Hi Finn,
Am 13.11.2018 um 16:14 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain
wrote
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent
Hi Finn,
Am 12.11.18 um 17:34 schrieb Finn Thain:
> On Mon, 12 Nov 2018, Michael Schmitz wrote:
>
>> That's ultimately for Geert to decide - I'll yet have to look at your
>> mac patches to even get a vague idea what this conversion involves, but
>> I can certainly t
Thanks Finn,
Am 09.11.2018 um 12:42 schrieb Finn Thain:
On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
The example I gave was GENERIC_CLOCKEVENTS on m68, which is
supported on most but not all machines there.
That suggests that the removal of just those machines would suffice
(as opposed
Hi Adrian,
my fix is evidently incomplete - I just crashed elgar trying to remove
the pata_buddha module, sorry. Must've done something silly.
So no, can't post a patch to add module_exit just yet.
Cheers,
Michael
Am 31.10.2018 um 23:06 schrieb John Paul Adrian Glaubitz:
Hi!
On
Hi Bartlomiej,
On 19/10/18 01:29, Bartlomiej Zolnierkiewicz wrote:
Add Buddha PATA controller driver. It enables libata support for
the Buddha, Catweasel and X-Surf expansion boards on the Zorro
expansion bus.
Cc: John Paul Adrian Glaubitz
Cc: Michael Schmitz
Cc: Geert Uytterhoeven
Signed
Hi Adrian,
module built and loaded fine (no need to build a new kernel for this).
Can't unload the module however (-EBUSY).
You'll have to reboot elgar to reload the module, I'm afraid.
Cheers,
Michael
On 19/10/18 01:32, John Paul Adrian Glaubitz wrote:
Hi!
On 10/18/18 2:29 PM,
is done
(see patch 2 of this series for that).
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
Tested-by: Martin Steigerwald
Reviewed-by: Geert Uytterhoeven
---
C
(hopefully) final version of the Amiga RDB partition table patch follows.
I've split off the part fixing the incorrect use of signed int
for partition start address and size as separate patch. It does fix the
bug that Martin Steigerwald reported six years ago for a 2 TB disk.
I have tested this
/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
Reviewed-by: Geert Uytterhoeven
---
Changes from RFC:
- use u64 instead of sector_t, since that may be u32 without LBD support
- check multipli
Hi Geert,
thanks for your feedback!
On 14/10/18 23:42, Geert Uytterhoeven wrote:
Hi Michael,
On Sun, Oct 14, 2018 at 6:48 AM Michael Schmitz wrote:
The Amiga partition parser module uses signed int for partition sector
address and count, which will overflow for disks larger than 1 TB.
Use
On 15/10/18 04:47, Christoph Hellwig wrote:
+ *p++ = IDENTIFY(lp && (tp->flags & ESP_TGT_DISCONNECT), lun);
I think lp should always be non-NULL here.
That indeed appears to be the case these days.
So we can't rely on !lp to detect when probing the bus any longer. What
else would be
command and a "DMA length is zero" error.
Fixes: 3109e5ae0311
Signed-off-by: Finn Thain
Cc: Michael Schmitz
Tested-by: Michael Schmitz
Reviewed-by: Michael Schmitz
---
drivers/scsi/zorro_esp.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/scsi/zor
(resend - managed to lose $subject, sorry)
Am 14.10.2018 um 17:48 schrieb Michael Schmitz:
and yet another new version of the Amiga RDB partition table patch.
I've split off the part fixing the incorrect use of signed int
for partition start address and size as separate patch. It does fix
is done
(see patch 2 of this series for that).
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
Tested-by: Martin Steigerwald
Reviewed-by: Geert Uytterhoeven
---
C
and yet another new version of the Amiga RDB partition table patch.
I've split off the part fixing the incorrect use of signed int
for partition start address and size as separate patch. It does fix the
bug that Martin Steigerwald reported six years ago for a 2 TB disk.
I have tested this
/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
---
Changes from RFC:
- use u64 instead of sector_t, since that may be u32 without LBD support
- check multiplication overflows each step - 3 u32 valu
+++
4 files changed, 201 insertions(+), 412 deletions(-)
For Amiga zorro-esp:
Tested-by: Michael Schmitz
Hi Geert,
Am 13.10.2018 um 20:02 schrieb Geert Uytterhoeven:
Hi Michael,
On Sat, Oct 13, 2018 at 4:23 AM Michael Schmitz wrote:
Am 12.10.2018 um 21:54 schrieb Geert Uytterhoeven:
Thanks for being persistent!
BTW, there's another possible overflow in "blk *= blksize", but that o
Hi Finn,
Am 13.10.2018 um 17:09 schrieb Finn Thain:
On Sat, 13 Oct 2018, Michael Schmitz wrote:
Hi Finn,
Am 13.10.2018 um 13:51 schrieb Finn Thain:
Avoid function calls in the inner PIO loops. On a Centris 660av this
improves throughput for sequential read transfers by about 40
Hi Finn,
Am 13.10.2018 um 13:51 schrieb Finn Thain:
Avoid function calls in the inner PIO loops. On a Centris 660av this
improves throughput for sequential read transfers by about 40% and
sequential write by about 10%.
Unfortunately it is not possible to have method calls like esp_write8()
Hi Geert,
Am 12.10.2018 um 21:59 schrieb Geert Uytterhoeven:
Changes from v4:
Andreas Schwab:
- correct cast to sector_t in sector address calculations
Which you only did for the first case...
--- a/block/partitions/amiga.c
+++ b/block/partitions/amiga.c
@@ -100,14 +101,14 @@ int
Hi Geert,
Am 12.10.2018 um 21:54 schrieb Geert Uytterhoeven:
Thanks for being persistent!
BTW, there's another possible overflow in "blk *= blksize", but that one
is very unlikely to happen, as most (all?) partitioners store partition
blocks close to the beginning of the disk.
Thanks - we
yet another new version of the Amiga RDB partition table patch.
I've split off the part fixing the incorrect use of signed int
for partition start address and size as separate patch. This change
should be incontroversial (I hope). It does fix the bug that Martin
Steigerwald reported six
/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
---
Changes from RFC:
- use u64 instead of sector_t, since that may be u32 without LBD support
- check multiplication overflows each step - 3 u32 valu
is done
(see patch 2 of this series for that).
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
Tested-by: Martin Steigerwald
---
Changes from v3:
- split off
Am 05.10.2018 um 15:16 schrieb Leonardo Bras:
Well it's not really that persuasive. Most people simply let the build
run to completion, but if you have a problem with a job control 3h
timelimit, then create a job that kills itself at 2:59 and then
resubmits itself. That will produce a
Thanks Andreas,
it appears I already made the same error in v2 of this series. My bad.
I'll wait for a few more comments before respinning.
Cheers,
Michael
Am 30.09.2018 um 19:16 schrieb Andreas Schwab:
On Sep 30 2018, Michael Schmitz wrote:
@@ -100,17 +101,17 @@ int
/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
---
Changes from RFC:
- use u64 instead of sector_t, since that may be u32 without LBD support
- check multiplication overflows each step - 3 u32 valu
is done
(see patch 2 of this series for that).
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511
Reported-by: Martin Steigerwald
Message-ID: <201206192146.09327.mar...@lichtvoll.de>
Signed-off-by: Michael Schmitz
Tested-by: Martin Steigerwald
---
Changes from v3:
- split off
1 - 100 of 796 matches
Mail list logo
