From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 15073 invoked from network); 1 Oct 2022 10:36:00 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2022 10:36:00 -0000 Received: from cc-smtpout3.netcologne.de ([89.1.8.213]) by 9front; Sat Oct 1 06:34:29 -0400 2022 Received: from cc-app1.netcologne.de (cc-app1.netcologne.de [89.1.9.190]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 2187B1240B for <9front@9front.org>; Sat, 1 Oct 2022 12:34:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1664620466; bh=mYPR9k0O9+5Kh4UCQivKXpWcA3QB5cJbV0UqwfVYFpM=; h=Date:From:To:Message-ID:Subject:From; b=AWpIv6l6zKQfSg5QzFoa9jagW72Fntaj6uDO/I/yATRVaD0P3wWzQLn22m2DLi1II cPUalNhFm7sAQYF+TXIpKEyBKLI5cf/RTjK5WVL7ps0LcxjhhuSCA3r7ppU1GvsTMQ lew7FF+PeY7XScVWTHCPZj0hy8aY2DMasvqNRUCI/1XD/BDl5Els9qVVHzqTJodUKp boq8xHGmBq33/Dqsr+m8kAQRI3bgEZGprkOtCetkCGBGgTFJF546iZMoVy4AyhOUIx lZ1a5l8AKz0Si04hCi/wFS/1SNBXC4V659fXpTY5y5/i1vBrANUV38aqgUK1KCFKl9 EWObjXPz2CN4Q== Received: from cc-app1.netcologne.de (localhost [127.0.0.1]) by cc-app1.netcologne.de (Postfix) with ESMTPA id EF3E811EB2 for <9front@9front.org>; Sat, 1 Oct 2022 12:34:25 +0200 (CEST) Date: Sat, 1 Oct 2022 12:34:25 +0200 (CEST) From: Arne Meyer To: "9front@9front.org" <9front@9front.org> Message-ID: <827131327.3389568.1664620465910@comcenter.netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev16 X-Originating-IP: 2001:4dd1:4eee:0:3850:e1a8:5783:1b7e X-Originating-Client: open-xchange-appsuite X-NetCologne-Spam: L X-Rspamd-Queue-Id: EF3E811EB2 X-Spamd-Bar: - List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: storage content-driven ORM CSS API Subject: [9front] [patch] cdfs handle block sizes correctly Reply-To: 9front@9front.org Precedence: bulk The Readblock enum does not work when you try to read audio cds. 4 cdda blocks are lager than 8192 and the command fails (at least when using an usb cd drive). This sets the block count according to the track block size. With this and the fix for libdisk I can rip audio cds on my el cheapo usb dvd drive. Tested with "Midnight Oil - Blue Sky Mining" Greetings, Arne diff e938acc8ff64a3cbbd6ef7ba88f83e3f03ede681 uncommitted --- a/sys/src/cmd/cdfs/dat.h +++ b/sys/src/cmd/cdfs/dat.h @@ -133,10 +133,11 @@ DVDNblock = 16, /* DVD ECC block is 16 sectors */ BDNblock = 32, /* BD ECC block (`cluster') is 32 sectors */ /* - * make a single transfer fit in a 9P rpc. if we don't do this, - * remote access (e.g., via /mnt/term/dev/sd*) fails mysteriously. + * number of blocks read/written must fit in this. if we don't do this, + * remote access (e.g., via /mnt/term/dev/sd* or nusb/disk) fails mysteriously. + * see /sys/src/9/port/devmnt.c MAXRPC. */ - Readblock = 8192/BScdrom, + Maxrpc = 8192, }; typedef struct Buf Buf; --- a/sys/src/cmd/cdfs/mmc.c +++ b/sys/src/cmd/cdfs/mmc.c @@ -1171,7 +1171,7 @@ o->track = &drive->track[trackno]; o->nchange = drive->nchange; o->omode = OREAD; - o->buf = bopen(mmcread, OREAD, o->track->bs, Readblock); + o->buf = bopen(mmcread, OREAD, o->track->bs, Maxrpc/o->track->bs); o->buf->otrack = o; aux->nropen++; @@ -1395,7 +1395,7 @@ o->nchange = drive->nchange; o->omode = OWRITE; o->track = t; - o->buf = bopen(mmcwrite, OWRITE, bs, Readblock); + o->buf = bopen(mmcwrite, OWRITE, bs, Maxrpc/bs); o->buf->otrack = o; aux->nwopen++;