[PATCH] fix floppy for PAGE_SIZE != 4KB

[PATCH] fix floppy for PAGE_SIZE != 4KB

[Rene Rebe]

For years I wondered why the floppy driver does not just work on
sparc64, e.g:

root@SUNW_375_0066:# disktype /dev/fd0
--- /dev/fd0
disktype: Can't open /dev/fd0: No such device or address

[  525.341906] disktype: attempt to access beyond end of device
               fd0: rw=0, sector=0, nr_sectors = 16 limit=8
[  525.341991] floppy: error 10 while reading block 0

Turns out floppy.c __floppy_read_block_0 tries to read one page for
the first test read to determine the disk size and thus fails if that
is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.

Signed-off-by: René Rebe <rene@exactco.de>

--- linux-6.16/drivers/block/floppy.c.vanilla	2025-09-07 11:16:02.420895667 +0200
+++ linux-6.16/drivers/block/floppy.c	2025-09-07 11:17:17.538595643 +0200
@@ -331,7 +331,7 @@
  * This default is used whenever the current disk size is unknown.
  * [Now it is rather a minimum]
  */
-#define MAX_DISK_SIZE 4		/* 3984 */
+#define MAX_DISK_SIZE (PAGE_SIZE / 1024)
 
 /*
  * globals used by 'result()'

-- 
  René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
  https://exactcode.com | https://t2sde.org | https://rene.rebe.de

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Jens Axboe]

On 11/14/25 6:41 AM, Rene Rebe wrote:
> For years I wondered why the floppy driver does not just work on
> sparc64, e.g:
> 
> root@SUNW_375_0066:# disktype /dev/fd0
> --- /dev/fd0
> disktype: Can't open /dev/fd0: No such device or address
> 
> [  525.341906] disktype: attempt to access beyond end of device
>                fd0: rw=0, sector=0, nr_sectors = 16 limit=8
> [  525.341991] floppy: error 10 while reading block 0
> 
> Turns out floppy.c __floppy_read_block_0 tries to read one page for
> the first test read to determine the disk size and thus fails if that
> is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
> floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.

16k seem like a lot to read from a floppy, no? Why isn't it just
reading a single 512b sector? Or just cap it at 4k rather than do
a full page, at least?

-- 
Jens Axboe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[René Rebe]

From: Jens Axboe <axboe@kernel.dk>

> On 11/14/25 6:41 AM, Rene Rebe wrote:
> > For years I wondered why the floppy driver does not just work on
> > sparc64, e.g:
> > 
> > root@SUNW_375_0066:# disktype /dev/fd0
> > --- /dev/fd0
> > disktype: Can't open /dev/fd0: No such device or address
> > 
> > [  525.341906] disktype: attempt to access beyond end of device
> >                fd0: rw=0, sector=0, nr_sectors = 16 limit=8
> > [  525.341991] floppy: error 10 while reading block 0
> > 
> > Turns out floppy.c __floppy_read_block_0 tries to read one page for
> > the first test read to determine the disk size and thus fails if that
> > is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
> > floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
> 
> 16k seem like a lot to read from a floppy, no? Why isn't it just
> reading a single 512b sector? Or just cap it at 4k rather than do
> a full page, at least?

Well, on my sparc64.config it is just 8k and I did not feel like
changing this vintage code more than was necessiary to write a floppy
for a Firmware update of another systems while my Ultra10 was the only
system with a floppy drive in my office. But even 16k or 64k is not
that much of a 1.44mb disk.

But if someone wants to refactor this code some more, ... I'm happy to
test it, too ;-)

    René

-- 
  René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
  https://exactco.de | https://t2linux.com | https://rene.rebe.de

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Jens Axboe]

On 11/14/25 9:25 AM, Ren? Rebe wrote:
> From: Jens Axboe <axboe@kernel.dk>
> 
>> On 11/14/25 6:41 AM, Rene Rebe wrote:
>>> For years I wondered why the floppy driver does not just work on
>>> sparc64, e.g:
>>>
>>> root@SUNW_375_0066:# disktype /dev/fd0
>>> --- /dev/fd0
>>> disktype: Can't open /dev/fd0: No such device or address
>>>
>>> [  525.341906] disktype: attempt to access beyond end of device
>>>                fd0: rw=0, sector=0, nr_sectors = 16 limit=8
>>> [  525.341991] floppy: error 10 while reading block 0
>>>
>>> Turns out floppy.c __floppy_read_block_0 tries to read one page for
>>> the first test read to determine the disk size and thus fails if that
>>> is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
>>> floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
>>
>> 16k seem like a lot to read from a floppy, no? Why isn't it just
>> reading a single 512b sector? Or just cap it at 4k rather than do
>> a full page, at least?
> 
> Well, on my sparc64.config it is just 8k and I did not feel like
> changing this vintage code more than was necessiary to write a floppy
> for a Firmware update of another systems while my Ultra10 was the only
> system with a floppy drive in my office. But even 16k or 64k is not
> that much of a 1.44mb disk.

64k is 4% of a floppy disk! But I hear you, works for you.

> But if someone wants to refactor this code some more, ... I'm happy to
> test it, too ;-)

I don't think refactoring would be required here, it's probably just
capping that probe read to something constant irrespective of hardware
page sizes.

-- 
Jens Axboe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[René Rebe]

From: Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] fix floppy for PAGE_SIZE != 4KB
Date: Fri, 14 Nov 2025 10:39:21 -0700

> X-Mew-Uidl: 17238 8500
> Return-path: <axboe@kernel.dk>
> Received: from mail-io1-f45.google.com ([209.85.166.45])
> 	by exactco.de with esmtps  (TLS1.3) tls TLS_AES_128_GCM_SHA256
> 	(Exim 4.98.2)
> 	(envelope-from <axboe@kernel.dk>)
> 	id 1vJxmP-000000006fi-12uV
> 	for rene@exactco.de;
> 	Fri, 14 Nov 2025 18:40:13 +0100
> Received: by mail-io1-f45.google.com with SMTP id ca18e2360f4ac-92aee734585so87221739f.3
>         for <rene@exactco.de>; Fri, 14 Nov 2025 09:39:25 -0800 (PST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1763141963; x=1763746763; darn=exactco.de;
>         h=content-transfer-encoding:in-reply-to:content-language:from
>          :references:cc:to:subject:user-agent:mime-version:date:message-id
>          :from:to:cc:subject:date:message-id:reply-to;
>         bh=lZaaDarMi0uZmQYGpNnbLmsBdRPS9KXQOUgY8RY+ykY=;
>         b=h3Wjxcf4oo0j4Shr1vEPf9Udexbr56yRqicutDDnH7Jar8K2VIk803/QoMRDqJKTtT
>          y6G447IzrSYGhBnh5yLyAciijNPInIFdcw/CFhI5VeAVyNC/QVJcBTBZsMSioPxsfVJ0
>          sw/LdOIqSxtwMEzzMM+2yC6LKk9E1A8/hpJElAaBUh7V85/2KsqhTa8Jsvq9TCrKcZdy
>          6ERjqb6roG3W9nB59bkW99uBH0J1NyCKFm99JEo9YtORBh5PchjmBeBtiFpVpDYpZsdP
>          AdDlbuVwJZzVCkkOAh8WtdyALVSNxUogAdafb1W2M0mKzU4FORfhT52j3VOtrIK7i36s
>          386g==
> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20230601; t=1763141963; x=1763746763;        h=content-transfer-encoding:in-reply-to:content-language:from         :references:cc:to:subject:user-agent:mime-version:date:message-id         :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id         :reply-to;        bh=lZaaDarMi0uZmQYGpNnbLmsBdRPS9KXQOUgY8RY+ykY=;        b=wZVg430Cuy+Bm3xCP3xLtJR87QpLmd6CPTy4d2XsNmgORpoou61Ycfr/4PBK/7POa0         T1OR6l1Mdi3J7WBh3SdUkrg0jS0domGuoeqCF2zRMWc0sU0JL8uZnFE4MFot90s8lIyv         RjBavJ/iGoKdojneYS+04VxlCn/CUFhotKjkmaMe+v+p2Gm3lbDWv1rrTOrKwv3osel/         nuqiuVwj4gfVO1HJ+Yb5LS+m/uBd0gEySCc1DRPTgmyWJfuhzTqCycW4qDd+yEJl5GtZ         F7TGR94r+g1H20hhojJjF5lyGtrXes5LGCrFk4sjS6/k+uf1eP8EHLSqiqNl8kGrm+ea         NdWw==
> X-Gm-Message-State: AOJu0YzDbu8SGAL91+VHgvF0LQl/e4dSamw+KEHunptI0Jlg87NBBrxR	DdcJZucxSP/PZElLBiM402EhLFPaX7mSN8IMgAjxDbPgp1Ca5MdopKM2UlkIDagDh4Yi7vfs7B0	Exuok
> X-Gm-Gg: ASbGncuSzfs+0VGvQb7oY2nTlbPuDxAXhz9+Y4sqfdq9cj5rNMa+KDDiYtenirhqsbA	/zigdhq+egQe9+sMwo4zyxSSaXPmEmbx9NXvKJnvLiXupvOumyk6jA+UL1BJJwT0dBZa7XP2kCj	qc3QW0dkRuiqnslz8snnpRg70c4ecQ84XS0ySBgN1p/VR7aEBeubjotUmI8OUqTSMAQUbtaSp3T	PHqm295zazvUtZ/DTq4axMwWRHiXlemkkValmgDHwF0p88P0i4wExBojjONMu9x726mmVerLBy3	XrcdCvtlkE8f32Mz9GudwYkOicCIafV9sAdD7e4+1E/aPnbv26XgIy/Y4GwqFlIkm1GQ8jr/J1v	r7YKKEejl+e9tZkvvJhPfFwwwFLZOxDzbpC/iLLo/Vsh0ssW8NVYnC3YPj9KIl4gUIIZJxsDYrx	aL4QeGQfM=
> X-Google-Smtp-Source: AGHT+IEjcZzHdGktbTOeAvLIuYkdqP8emkJEPDTbPxihjchGZYlR3EBTZoHoVOIlFQFJfLry0Ohr7A==
> X-Received: by 2002:a05:6e02:1a21:b0:433:771e:3dd6 with SMTP id e9e14a558f8ab-4348c87a9f4mr58244765ab.6.1763141963425;        Fri, 14 Nov 2025 09:39:23 -0800 (PST)
> Received: from [192.168.1.116] ([96.43.243.2])
>         by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-434839badb6sm28987385ab.27.2025.11.14.09.39.22
>         (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
>         Fri, 14 Nov 2025 09:39:22 -0800 (PST)
> Message-ID: <fec67c88-53f5-4482-aeef-86e1213d187e@kernel.dk>
> MIME-Version: 1.0
> References: <20251114.144127.170518024415947073.rene@exactco.de>
>  <b1e17016-3d4d-4fac-b5b0-97db357d0749@kernel.dk>
>  <20251114.172543.20704181754788128.rene@exactco.de>
> In-Reply-To: <20251114.172543.20704181754788128.rene@exactco.de>
> X-Spam_score: 0.0
> X-Spam_report: Spam detection software, running on the system "exactco.de", has NOT identified this incoming email as spam.  The original message has been attached to this so you can view it or label similar future email.  If you have any questions, see rene@exactco.de for details.  Content preview:  On 11/14/25 9:25 AM, Ren? Rebe wrote: > From: Jens Axboe <axboe@kernel.dk>    > >> On 11/14/25 6:41 AM, Rene Rebe wrote: >>> For years I wondered why the    floppy driver does not just work on >>> sparc64, [...]   Content analysis details:   (0.0 points, 5.0 required)   pts rule name              description ---- ---------------------- -------------------------------------------------- -0.0 BAYES_20               BODY: Bayes spam probability is 5 to 20%                             [score: 0.1285]  0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)                             [209.85.166.45 listed in wl.mailspike.net]  0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to                              Validity was blocked.  See                             https://knowledge.validity.com/hc/en-us/articles/20961730681243                              for more information.                             [209.85.166.45 listed in bl.score.senderscore.com]  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to DNSWL                             was blocked.  See                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block                              for more information.                             [209.85.166.45 listed in list.dnswl.org]  0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The                             query to Validity was blocked.  See                             https://knowledge.validity.com/hc/en-us/articles/20961730681243                              for more information.                          [209.85.166.45 listed in sa-trusted.bondedsender.org]  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to                             zen.spamhaus.org was blocked due to usage of an                              open resolver. See                             https://www.spamhaus.org/returnc/pub/                             [209.85.166.45 listed in zen.spamhaus.org]  0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to                              Validity was blocked.  See                             https://knowledge.validity.com/hc/en-us/articles/20961730681243                              for more information.                             [209.85.166.45 listed in sa-accredit.habeas.com]
> Content-Language: en-US
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 7bit
> Subject: Re: [PATCH] fix floppy for PAGE_SIZE != 4KB
> From: Jens Axboe <axboe@kernel.dk>
> To: René Rebe <rene@exactco.de>
> Cc: linux-block@vger.kernel.org, efremov@linux.com
> Date: Fri, 14 Nov 2025 10:39:21 -0700
> User-Agent: Mozilla Thunderbird
> Envelope-to: rene@exactco.de
> Delivery-date: Fri, 14 Nov 2025 18:40:14 +0100
> 
> On 11/14/25 9:25 AM, Ren? Rebe wrote:
> > From: Jens Axboe <axboe@kernel.dk>
> > 
> >> On 11/14/25 6:41 AM, Rene Rebe wrote:
> >>> For years I wondered why the floppy driver does not just work on
> >>> sparc64, e.g:
> >>>
> >>> root@SUNW_375_0066:# disktype /dev/fd0
> >>> --- /dev/fd0
> >>> disktype: Can't open /dev/fd0: No such device or address
> >>>
> >>> [  525.341906] disktype: attempt to access beyond end of device
> >>>                fd0: rw=0, sector=0, nr_sectors = 16 limit=8
> >>> [  525.341991] floppy: error 10 while reading block 0
> >>>
> >>> Turns out floppy.c __floppy_read_block_0 tries to read one page for
> >>> the first test read to determine the disk size and thus fails if that
> >>> is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
> >>> floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
> >>
> >> 16k seem like a lot to read from a floppy, no? Why isn't it just
> >> reading a single 512b sector? Or just cap it at 4k rather than do
> >> a full page, at least?
> > 
> > Well, on my sparc64.config it is just 8k and I did not feel like
> > changing this vintage code more than was necessiary to write a floppy
> > for a Firmware update of another systems while my Ultra10 was the only
> > system with a floppy drive in my office. But even 16k or 64k is not
> > that much of a 1.44mb disk.
> 
> 64k is 4% of a floppy disk! But I hear you, works for you.

Again, still only 8k or 16k for most of such remaining workstation
floppy users.

> > But if someone wants to refactor this code some more, ... I'm happy to
> > test it, too ;-)
> 
> I don't think refactoring would be required here, it's probably just
> capping that probe read to something constant irrespective of hardware
> page sizes.

Well, the floppy.c __floppy_read_block_0 does:
        bio_init(&bio, bdev, &bio_vec, 1, REQ_OP_READ);
        __bio_add_page(&bio, page, block_size(bdev), 0);

Is there an easy way to limit that to less than a page without
refactoring it too much? Otherwise we could just apply this hotfix for
now.

	René

-- 
  René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
  https://exactco.de | https://t2linux.com | https://rene.rebe.de

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[René Rebe]

Hi,

>> 64k is 4% of a floppy disk! But I hear you, works for you.
> 
> Again, still only 8k or 16k for most of such remaining workstation
> floppy users.
> 
>>> But if someone wants to refactor this code some more, ... I'm happy to
>>> test it, too ;-)
>> 
>> I don't think refactoring would be required here, it's probably just
>> capping that probe read to something constant irrespective of hardware
>> page sizes.
> 
> Well, the floppy.c __floppy_read_block_0 does:
>        bio_init(&bio, bdev, &bio_vec, 1, REQ_OP_READ);
>        __bio_add_page(&bio, page, block_size(bdev), 0);
> 
> Is there an easy way to limit that to less than a page without
> refactoring it too much? Otherwise we could just apply this hotfix for
> now.


Any chance we can get my initial one liner constant PAGE_SIZE fix
for this over a decade old bug in? I currently don’t have a budget
to refactor the floppy driver probing for efficiency on bigger PAGE_SIZE
configs I’m not even having a floppy controller on.

Thanks!

	René

-- 
 René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
 https://exactco.de | https://t2linux.com | https://rene.rebe.de

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Jens Axboe]

On 11/17/25 2:56 AM, Ren? Rebe wrote:
> Hi,
> 
>>> 64k is 4% of a floppy disk! But I hear you, works for you.
>>
>> Again, still only 8k or 16k for most of such remaining workstation
>> floppy users.
>>
>>>> But if someone wants to refactor this code some more, ... I'm happy to
>>>> test it, too ;-)
>>>
>>> I don't think refactoring would be required here, it's probably just
>>> capping that probe read to something constant irrespective of hardware
>>> page sizes.
>>
>> Well, the floppy.c __floppy_read_block_0 does:
>>        bio_init(&bio, bdev, &bio_vec, 1, REQ_OP_READ);
>>        __bio_add_page(&bio, page, block_size(bdev), 0);
>>
>> Is there an easy way to limit that to less than a page without
>> refactoring it too much? Otherwise we could just apply this hotfix for
>> now.
> 
> 
> Any chance we can get my initial one liner constant PAGE_SIZE fix
> for this over a decade old bug in? I currently don?t have a budget
> to refactor the floppy driver probing for efficiency on bigger PAGE_SIZE
> configs I?m not even having a floppy controller on.

Yep we can do that. It'd be great if we could augment the change with
what commit broke it, so it can get backported to stable kernels as
well. Was it:

commit fe4ec12e1865a2114056b799e4869bf4c30e47df
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jun 26 10:01:52 2020 +0200

    floppy: use block_size

?

-- 
Jens Axboe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[René Rebe]

Hi,

> On 17. Nov 2025, at 14:23, Jens Axboe <axboe@kernel.dk> wrote:
> 
> On 11/17/25 2:56 AM, Ren? Rebe wrote:
...
>> Any chance we can get my initial one liner constant PAGE_SIZE fix
>> for this over a decade old bug in? I currently don?t have a budget
>> to refactor the floppy driver probing for efficiency on bigger PAGE_SIZE
>> configs I?m not even having a floppy controller on.
> 
> Yep we can do that. It'd be great if we could augment the change with
> what commit broke it, so it can get backported to stable kernels as
> well. Was it:
> 
> commit fe4ec12e1865a2114056b799e4869bf4c30e47df
> Author: Christoph Hellwig <hch@lst.de>
> Date:   Fri Jun 26 10:01:52 2020 +0200
> 
>    floppy: use block_size

maybe, but I’m not 100% sure. Probably not the best answer
for kernel driver development. It might have been broken in
other ways for over a decade already. I would need to debug
that to be sure, but then I could also see if I can make it easily
work without changing the max size constant, ...

Thanks!
	René

-- 
https://exactco.de - https://t2linux.com - https://rene.rebe.de

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Jens Axboe]

On Fri, 14 Nov 2025 14:41:27 +0100, Rene Rebe wrote:
> For years I wondered why the floppy driver does not just work on
> sparc64, e.g:
> 
> root@SUNW_375_0066:# disktype /dev/fd0
> --- /dev/fd0
> disktype: Can't open /dev/fd0: No such device or address
> 
> [...]

Applied, thanks!

[1/1] fix floppy for PAGE_SIZE != 4KB
      (no commit info)

Best regards,
-- 
Jens Axboe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Jens Axboe]

On 11/17/25 6:57 AM, René Rebe wrote:
> Hi,
> 
>> On 17. Nov 2025, at 14:23, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 11/17/25 2:56 AM, Ren? Rebe wrote:
> ...
>>> Any chance we can get my initial one liner constant PAGE_SIZE fix
>>> for this over a decade old bug in? I currently don?t have a budget
>>> to refactor the floppy driver probing for efficiency on bigger PAGE_SIZE
>>> configs I?m not even having a floppy controller on.
>>
>> Yep we can do that. It'd be great if we could augment the change with
>> what commit broke it, so it can get backported to stable kernels as
>> well. Was it:
>>
>> commit fe4ec12e1865a2114056b799e4869bf4c30e47df
>> Author: Christoph Hellwig <hch@lst.de>
>> Date:   Fri Jun 26 10:01:52 2020 +0200
>>
>>    floppy: use block_size
> 
> maybe, but I’m not 100% sure. Probably not the best answer
> for kernel driver development. It might have been broken in
> other ways for over a decade already. I would need to debug
> that to be sure, but then I could also see if I can make it easily
> work without changing the max size constant, ...

I'll just mark it for stable, then at least it'll go to most of
the ones we care about.

-- 
Jens Axboe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[John Paul Adrian Glaubitz]

Hi Jens,

On Fri, 2025-11-14 at 09:11 -0700, Jens Axboe wrote:
> On 11/14/25 6:41 AM, Rene Rebe wrote:
> > For years I wondered why the floppy driver does not just work on
> > sparc64, e.g:
> > 
> > root@SUNW_375_0066:# disktype /dev/fd0
> > --- /dev/fd0
> > disktype: Can't open /dev/fd0: No such device or address
> > 
> > [  525.341906] disktype: attempt to access beyond end of device
> >                fd0: rw=0, sector=0, nr_sectors = 16 limit=8
> > [  525.341991] floppy: error 10 while reading block 0
> > 
> > Turns out floppy.c __floppy_read_block_0 tries to read one page for
> > the first test read to determine the disk size and thus fails if that
> > is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
> > floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
> 
> 16k seem like a lot to read from a floppy, no? Why isn't it just
> reading a single 512b sector? Or just cap it at 4k rather than do
> a full page, at least?

My understanding was that the initial read is necessary to determine the
size of the floppy disk. And the easiest approach was to just read as
many sectors that fit into one page which would be 8 512-byte sectors
in a 4k page.

Since back in the days, the standard page size was always 4k, this never
caused any problems.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[John Paul Adrian Glaubitz]

Hi Jens,

On Mon, 2025-11-17 at 06:23 -0700, Jens Axboe wrote:
> On 11/17/25 2:56 AM, Ren? Rebe wrote:
> > Hi,
> > 
> > > > 64k is 4% of a floppy disk! But I hear you, works for you.
> > > 
> > > Again, still only 8k or 16k for most of such remaining workstation
> > > floppy users.
> > > 
> > > > > But if someone wants to refactor this code some more, ... I'm happy to
> > > > > test it, too ;-)
> > > > 
> > > > I don't think refactoring would be required here, it's probably just
> > > > capping that probe read to something constant irrespective of hardware
> > > > page sizes.
> > > 
> > > Well, the floppy.c __floppy_read_block_0 does:
> > >        bio_init(&bio, bdev, &bio_vec, 1, REQ_OP_READ);
> > >        __bio_add_page(&bio, page, block_size(bdev), 0);
> > > 
> > > Is there an easy way to limit that to less than a page without
> > > refactoring it too much? Otherwise we could just apply this hotfix for
> > > now.
> > 
> > 
> > Any chance we can get my initial one liner constant PAGE_SIZE fix
> > for this over a decade old bug in? I currently don?t have a budget
> > to refactor the floppy driver probing for efficiency on bigger PAGE_SIZE
> > configs I?m not even having a floppy controller on.
> 
> Yep we can do that. It'd be great if we could augment the change with
> what commit broke it, so it can get backported to stable kernels as
> well. Was it:
> 
> commit fe4ec12e1865a2114056b799e4869bf4c30e47df
> Author: Christoph Hellwig <hch@lst.de>
> Date:   Fri Jun 26 10:01:52 2020 +0200
> 
>     floppy: use block_size

Yes, Nick Bowler (CC'ed) bisected it to this commit in [1].

So, I suggest to add a proper "Fixes:" tag so the patch is propagated
to all stable kernels.

Adrian

> [1] https://lore.kernel.org/all/u3aaz4bx7xwlboyppeg4y3eixzgxbcodlmw7cwqloskmg6oqw2@j437p47sfww6/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[René Rebe]

Hi,

> On 19. Nov 2025, at 10:00, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> Hi Jens,
> 
> On Mon, 2025-11-17 at 06:23 -0700, Jens Axboe wrote:
>> On 11/17/25 2:56 AM, Ren? Rebe wrote:
>>> Hi,
>>> 
>>>>> 64k is 4% of a floppy disk! But I hear you, works for you.
>>>> 
>>>> Again, still only 8k or 16k for most of such remaining workstation
>>>> floppy users.
>>>> 
>>>>>> But if someone wants to refactor this code some more, ... I'm happy to
>>>>>> test it, too ;-)
>>>>> 
>>>>> I don't think refactoring would be required here, it's probably just
>>>>> capping that probe read to something constant irrespective of hardware
>>>>> page sizes.
>>>> 
>>>> Well, the floppy.c __floppy_read_block_0 does:
>>>>       bio_init(&bio, bdev, &bio_vec, 1, REQ_OP_READ);
>>>>       __bio_add_page(&bio, page, block_size(bdev), 0);
>>>> 
>>>> Is there an easy way to limit that to less than a page without
>>>> refactoring it too much? Otherwise we could just apply this hotfix for
>>>> now.
>>> 
>>> 
>>> Any chance we can get my initial one liner constant PAGE_SIZE fix
>>> for this over a decade old bug in? I currently don?t have a budget
>>> to refactor the floppy driver probing for efficiency on bigger PAGE_SIZE
>>> configs I?m not even having a floppy controller on.
>> 
>> Yep we can do that. It'd be great if we could augment the change with
>> what commit broke it, so it can get backported to stable kernels as
>> well. Was it:
>> 
>> commit fe4ec12e1865a2114056b799e4869bf4c30e47df
>> Author: Christoph Hellwig <hch@lst.de>
>> Date:   Fri Jun 26 10:01:52 2020 +0200
>> 
>>    floppy: use block_size
> 
> Yes, Nick Bowler (CC'ed) bisected it to this commit in [1].

Nice, thanks!

Carefully, it appears to be another commit though:

> I bisected the failure to this old commit:
> 
>   commit 74d46992e0d9dee7f1f376de0d56d31614c8a17a
>   Author: Christoph Hellwig <hch@lst.de>
>   Date:   Wed Aug 23 19:10:32 2017 +0200
>         block: replace bi_bdev with a gendisk pointer and partitions index


René

> So, I suggest to add a proper "Fixes:" tag so the patch is propagated
> to all stable kernels.
> 
> Adrian
> 
>> [1] https://lore.kernel.org/all/u3aaz4bx7xwlboyppeg4y3eixzgxbcodlmw7cwqloskmg6oqw2@j437p47sfww6/

-- 
https://exactco.de - https://t2linux.com - https://rene.rebe.de

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[John Paul Adrian Glaubitz]

On Wed, 2025-11-19 at 10:12 +0100, René Rebe wrote:
> > > Yep we can do that. It'd be great if we could augment the change with
> > > what commit broke it, so it can get backported to stable kernels as
> > > well. Was it:
> > > 
> > > commit fe4ec12e1865a2114056b799e4869bf4c30e47df
> > > Author: Christoph Hellwig <hch@lst.de>
> > > Date:   Fri Jun 26 10:01:52 2020 +0200
> > > 
> > >    floppy: use block_size
> > 
> > Yes, Nick Bowler (CC'ed) bisected it to this commit in [1].
> 
> Nice, thanks!
> 
> Carefully, it appears to be another commit though:
> 
> > I bisected the failure to this old commit:
> > 
> >   commit 74d46992e0d9dee7f1f376de0d56d31614c8a17a
> >   Author: Christoph Hellwig <hch@lst.de>
> >   Date:   Wed Aug 23 19:10:32 2017 +0200
> >         block: replace bi_bdev with a gendisk pointer and partitions index

Yes, you're right. I was briefly distracted when writing this mail.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[René Rebe]

Hi,

> On 19. Nov 2025, at 10:22, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> On Wed, 2025-11-19 at 10:12 +0100, René Rebe wrote:
>>>> Yep we can do that. It'd be great if we could augment the change with
>>>> what commit broke it, so it can get backported to stable kernels as
>>>> well. Was it:
>>>> 
>>>> commit fe4ec12e1865a2114056b799e4869bf4c30e47df
>>>> Author: Christoph Hellwig <hch@lst.de>
>>>> Date:   Fri Jun 26 10:01:52 2020 +0200
>>>> 
>>>>   floppy: use block_size
>>> 
>>> Yes, Nick Bowler (CC'ed) bisected it to this commit in [1].
>> 
>> Nice, thanks!
>> 
>> Carefully, it appears to be another commit though:
>> 
>>> I bisected the failure to this old commit:
>>> 
>>>  commit 74d46992e0d9dee7f1f376de0d56d31614c8a17a
>>>  Author: Christoph Hellwig <hch@lst.de>
>>>  Date:   Wed Aug 23 19:10:32 2017 +0200
>>>        block: replace bi_bdev with a gendisk pointer and partitions index
> 
> Yes, you're right. I was briefly distracted when writing this mail.

No worries, just checking. Should I send a new patch with the Fixes:
or can Jens just add it?

Thanks,
	René

-- 
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[John Paul Adrian Glaubitz]

Hi,

On Wed, 2025-11-19 at 10:24 +0100, René Rebe wrote:
> Hi,
> 
> > On 19. Nov 2025, at 10:22, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> > 
> > On Wed, 2025-11-19 at 10:12 +0100, René Rebe wrote:
> > > > > Yep we can do that. It'd be great if we could augment the change with
> > > > > what commit broke it, so it can get backported to stable kernels as
> > > > > well. Was it:
> > > > > 
> > > > > commit fe4ec12e1865a2114056b799e4869bf4c30e47df
> > > > > Author: Christoph Hellwig <hch@lst.de>
> > > > > Date:   Fri Jun 26 10:01:52 2020 +0200
> > > > > 
> > > > >   floppy: use block_size
> > > > 
> > > > Yes, Nick Bowler (CC'ed) bisected it to this commit in [1].
> > > 
> > > Nice, thanks!
> > > 
> > > Carefully, it appears to be another commit though:
> > > 
> > > > I bisected the failure to this old commit:
> > > > 
> > > >  commit 74d46992e0d9dee7f1f376de0d56d31614c8a17a
> > > >  Author: Christoph Hellwig <hch@lst.de>
> > > >  Date:   Wed Aug 23 19:10:32 2017 +0200
> > > >        block: replace bi_bdev with a gendisk pointer and partitions index
> > 
> > Yes, you're right. I was briefly distracted when writing this mail.
> 
> No worries, just checking. Should I send a new patch with the Fixes:
> or can Jens just add it?

Jens picked the patch up for his block tree already [1], but he could still take
a version 2 from you and force-push the new patch to his tree.

The proper tag would be:

Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index")

It's up to Jens in any case.

Adrian

> [1] https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/commit/?h=for-6.19/block&id=82d20481024cbae2ea87fe8b86d12961bfda7169

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Jens Axboe]

On 11/19/25 2:39 AM, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Wed, 2025-11-19 at 10:24 +0100, Ren? Rebe wrote:
>> Hi,
>>
>>> On 19. Nov 2025, at 10:22, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>>>
>>> On Wed, 2025-11-19 at 10:12 +0100, Ren? Rebe wrote:
>>>>>> Yep we can do that. It'd be great if we could augment the change with
>>>>>> what commit broke it, so it can get backported to stable kernels as
>>>>>> well. Was it:
>>>>>>
>>>>>> commit fe4ec12e1865a2114056b799e4869bf4c30e47df
>>>>>> Author: Christoph Hellwig <hch@lst.de>
>>>>>> Date:   Fri Jun 26 10:01:52 2020 +0200
>>>>>>
>>>>>>   floppy: use block_size
>>>>>
>>>>> Yes, Nick Bowler (CC'ed) bisected it to this commit in [1].
>>>>
>>>> Nice, thanks!
>>>>
>>>> Carefully, it appears to be another commit though:
>>>>
>>>>> I bisected the failure to this old commit:
>>>>>
>>>>>  commit 74d46992e0d9dee7f1f376de0d56d31614c8a17a
>>>>>  Author: Christoph Hellwig <hch@lst.de>
>>>>>  Date:   Wed Aug 23 19:10:32 2017 +0200
>>>>>        block: replace bi_bdev with a gendisk pointer and partitions index
>>>
>>> Yes, you're right. I was briefly distracted when writing this mail.
>>
>> No worries, just checking. Should I send a new patch with the Fixes:
>> or can Jens just add it?
> 
> Jens picked the patch up for his block tree already [1], but he could still take
> a version 2 from you and force-push the new patch to his tree.
> 
> The proper tag would be:
> 
> Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index")
> 
> It's up to Jens in any case.

Yeah not doing that for something that went unfixed for 8 years. It's
clearly not that important. Rene will see stable bot rejects as the
author, so I'd suggest just watching for those in a few weeks and
sending in a modified patch. It should go into 5.4, 5.10, 5.15, 6.1,
6.6, and 6.12. Possibly 6.17 unless that gets deprecated before then.

-- 
Jens Axboe

Re: [PATCH] fix floppy for PAGE_SIZE != 4KB

[Gregor Riepl]

You can add a Tested-by: from me, if you like.
My Ultra 10 can read floppies again!

For the record: I only had a handful of 3.5" 1.44MB PC disks lying around for testing, but I don't think it will make any difference.