From: Derek Johansen <djohanse678@gmail.com>
To: Jody Bruchon <jody@jodybruchon.com>
Cc: ELKS <linux-8086@vger.kernel.org>
Subject: Re: Cannot boot the real thing from HDD
Date: Sat, 22 Feb 2020 10:19:11 -0700 [thread overview]
Message-ID: <CAOv0vdnTnsJoOJXdUCrgLJNsxasVfRfTQ5VVm9POKgwFUNRYCQ@mail.gmail.com> (raw)
In-Reply-To: <A5612F29-0CC2-4902-8E35-F14DD5D4334A@jodybruchon.com>
Same result. still get the errors with sudo ./build.sh clean
On Sat, Feb 22, 2020 at 9:38 AM Jody Bruchon <jody@jodybruchon.com> wrote:
>
> Have you run './build.sh clean' yet? That should reset any stale files. If something changed in the code, you may have some object files that are incompatible.
>
> On February 22, 2020 11:24:02 AM EST, Derek Johansen <djohanse678@gmail.com> wrote:
> >i did a git pull last night and then sudp ./build.sh and got these
> >errors. This is the same process i have been using to build forever.
> >Did not modify any settings in menuconfig. How do i get back to a
> >working build?
> >
> >On Mon, Feb 17, 2020 at 2:38 PM Paul Osmialowski <pawelo@king.net.pl>
> >wrote:
> >>
> >>
> >>
> >> On Mon, 17 Feb 2020, Paul Osmialowski wrote:
> >>
> >> > Yes, I failed to express how worried I am by (ab)using ageing DD
> >floppy
> >> > drive (the only thing on-board floppy disk controller is able to
> >> > recognize) when doing my tests. I'm mounting the on-card rootfs in
> >/mnt to
> >> > start as many of the commands as possible (chroot would help).
> >> >
> >> > Setting "Extra external buffer cache" would probably help, but it
> >fails to
> >> > compile...
> >>
> >> Turning this option on causes ELKS building proces to fail at linking
> >like
> >> this:
> >>
> >> arch/i86/boot/crt0.o arch/i86/boot/crt1.o \
> >> init/main.o '-(' fs/fs.a kernel/kernel.a lib/lib.a net/net.a
> >> fs/minix/minixfs.a fs/msdos/msdos.a arch/i86/kernel/akernel.a
> >> arch/i86/lib/lib86.a arch/i86/mm/mm.a
> >arch/i86/drivers/char/chr_drv.a
> >> arch/i86/drivers/block/blk_drv.a arch/i86/drivers/net/net_drv.a '-)'
> >\
> >> -o arch/i86/boot/system > arch/i86/boot/system.map)
> >> kernel/kernel.a(sleepwake.o): in function `_wake_up':
> >> (.text+0xf4): relocation truncated to fit: R_386_16 against
> >`select_queue'
> >> net/net.a(af_inet.o): in function `inet_create':
> >> (.text+0xb): relocation truncated to fit: R_386_16 against
> >`tcpdev_inuse'
> >> arch/i86/drivers/char/chr_drv.a(tcpdev.o): in function `tcpdev_open':
> >> (.text+0xc): relocation truncated to fit: R_386_16 against
> >`tcpdev_inuse'
> >> (.text+0x19): relocation truncated to fit: R_386_16 against
> >`tcpdev_inuse'
> >> arch/i86/drivers/char/chr_drv.a(tcpdev.o): in function
> >`tcpdev_release':
> >> (.text+0x2b): relocation truncated to fit: R_386_16 against
> >`tcpdev_inuse'
> >> arch/i86/drivers/char/chr_drv.a(tcpdev.o): in function `tcpdev_init':
> >> (.text+0x174): relocation truncated to fit: R_386_16 against
> >> `tcpdev_inuse'
> >> arch/i86/drivers/block/blk_drv.a(ll_rw_blk.o): in function
> >`make_request':
> >> (.text+0x179): relocation truncated to fit: R_386_16 against
> >`blk_dev'
> >> arch/i86/drivers/block/blk_drv.a(ll_rw_blk.o): in function
> >`ll_rw_blk':
> >> (.text+0x1ba): relocation truncated to fit: R_386_16 against
> >`blk_dev'
> >> arch/i86/drivers/block/blk_drv.a(ll_rw_blk.o): in function
> >`blk_dev_init':
> >> (.text+0x1ef): relocation truncated to fit: R_386_16 against
> >`blk_dev'
> >> (.text+0x1ff): relocation truncated to fit: R_386_16 against
> >`blk_dev'
> >> arch/i86/drivers/block/blk_drv.a(doshd.o): in function `end_request':
> >> (.text+0xa0): additional relocation overflows omitted from the output
> >>
> >>
> >> >
> >> > Cheers,
> >> > Paul
> >> >
> >> > On Mon, 17 Feb 2020, Marc-F. Lucca-Daniau wrote:
> >> >
> >> > > Got the same problem as you while trying to use the HD image,
> >with wrong
> >> > > partition detection when no MBR. Working on it...
> >> > >
> >> > > I am just wondering why you try to mount the rootfs partition as
> >you booted on
> >> > > it and it should be mounted. Did I miss something in your
> >statement ?
> >> > >
> >> > > MFLD
> >> > >
> >> > >
> >> > > Le 12/02/2020 ? 23:31, Paul Osmialowski a écrit :
> >> > > > Yeah, it is described there indeed.
> >> > > >
> >> > > > I tried todays master. It does boot from CF card (MINIX HD
> >image), so the
> >> > > > original issue is now fixed. Yet still problem with lack of
> >ability to
> >> > > > mount rootfs from the same CF card and wrong listing of
> >partitions on a
> >> > > > card that contains no partitions (just a boot sector and a
> >MINIX rootfs
> >> > > > filesystem) remains and I guess deserved new (critical?) ticket
> >as it
> >> > > > limits usability of ELKS severely.
> >> > > >
> >> > > > Thanks,
> >> > > > Paul
> >> > > >
> >> > > > On Wed, 12 Feb 2020, Marc-François Lucca-Daniau wrote:
> >> > > >
> >> > > > > Please read the updated 'README.md' :-)
> >> > > > > MFLD
> >> > > > >
> >> > > > > Le mer. 12 févr. 2020 22:10, Paul Osmialowski
> ><pawelo@king.net.pl> a
> >> > > > > écrit :
> >> > > > > Just a quick question. If there's no tools/env.sh, how
> >one does
> >> > > > > 'make
> >> > > > > clean' now?
> >> > > > >
> >> > > > > On Wed, 12 Feb 2020, Marc-F. Lucca-Daniau wrote:
> >> > > > >
> >> > > > > > Hello Paul,
> >> > > > > >
> >> > > > > > Regression should be fixed now by latest commits.
> >> > > > > >
> >> > > > > > I selected CONFIG_IMG_HD, set CHS to 80/2/18 and
> >size to 1440
> >> > > > > blocks (to mimic
> >> > > > > > a floppy).
> >> > > > > >
> >> > > > > > After modifying 'qemu.sh' to boot on 'image/hd.bin',
> >got the ELKS
> >> > > > > login
> >> > > > > > prompt.
> >> > > > > >
> >> > > > > > So closing the issue, unless you still have the
> >problem.
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > >
> >> > > > > > MFLD
> >> > > > > >
> >> > > > > >
> >> > > > > > Le 11/02/2020 ? 21:38, Marc-F. Lucca-Daniau a écrit
> >:
> >> > > > > > > Hello Paul,
> >> > > > > > >
> >> > > > > > > Yes, confirmed, a recent commit on the boot sector
> >missed the
> >> > > > > CONFIG_IMG_HD
> >> > > > > > > case.
> >> > > > > > >
> >> > > > > > > Tracked by :
> >https://github.com/elks-org/elks/issues/323
> >> > > > > > >
> >> > > > > > > It again shows that we REALLY need more automatic
> >testing in
> >> > > > > the CI !
> >> > > > > > >
> >> > > > > > > MFLD
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Le 11/02/2020 ? 00:38, Paul Osmialowski a écrit :
> >> > > > > > > > Hi Marc,
> >> > > > > > > >
> >> > > > > > > > I'm observing some regression with today's
> >changes on git
> >> > > > > master. Despite
> >> > > > > > > > selecting MINIX boot image, -DBOOT_FAT is still
> >present in
> >> > > > > build log
> >> > > > > > > > (seems -UBOOT_FAT is not propagated properly):
> >> > > > > > > >
> >> > > > > > > > make[2]: Entering directory
> >> > > > > '/home/pawelo/elks.git/elkscmd/bootblocks'
> >> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
> >-o
> >> > > > > boot_sect.tmp
> >> > > > > > > > boot_sect.S
> >> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
> >-UBOOT_FAT
> >> > > > > -o
> >> > > > > > > > boot_sect.tmp boot_sect.S
> >> > > > > > > > ia16-elf-as -o boot_sect.o boot_sect.tmp
> >> > > > > > > > rm -f boot_sect.tmp
> >> > > > > > > > ia16-elf-gcc -Wall -Os -mregparmcall
> >-fno-toplevel-reorder
> >> > > > > -fno-inline
> >> > > > > > > > -mcmodel=tiny -mno-segment-relocation-stuff
> >-ffreestanding
> >> > > > > -mtune=i8086 -I
> >> > > > > > > > /home/pawelo/elks.git/include -c -o
> >boot_minix.o
> >> > > > > boot_minix.c
> >> > > > > > > > ia16-elf-ld -T
> >/home/pawelo/elks.git/elks/elks-raw.ld -M -o
> >> > > > > minix.bin
> >> > > > > > > > boot_sect.o boot_minix.o > minix.map
> >> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
> >-o
> >> > > > > boot_probe.tmp
> >> > > > > > > > boot_probe.S
> >> > > > > > > > ia16-elf-as -oboot_probe.o boot_probe.tmp
> >> > > > > > > > rm -f boot_probe.tmp
> >> > > > > > > > ia16-elf-ld -T
> >/home/pawelo/elks.git/elks/elks-raw.ld -M -o
> >> > > > > probe.bin
> >> > > > > > > > boot_sect.o boot_probe.o > probe.map
> >> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
> >-DBOOT_FAT
> >> > > > > -o
> >> > > > > > > > boot_sect_fat.tmp boot_sect.S
> >> > > > > > > > ia16-elf-as -o boot_sect_fat.o
> >boot_sect_fat.tmp
> >> > > > > > > > boot_sect.S: Assembler messages:
> >> > > > > > > > boot_sect.S:41: Error: Unknown disk medium!
> >> > > > > > > > make[2]: *** [Makefile:42: boot_sect_fat.o]
> >Error 1
> >> > > > > > > > make[2]: Leaving directory
> >> > > > > '/home/pawelo/elks.git/elkscmd/bootblocks'
> >> > > > > > > > make[1]: *** [Makefile:126: all] Error 1
> >> > > > > > > > make[1]: Leaving directory
> >'/home/pawelo/elks.git/elkscmd'
> >> > > > > > > > make: *** [Makefile:37: all] Error 2
> >> > > > > > > > Build script has terminated with error 5
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Sat, 8 Feb 2020, Paul Osmialowski wrote:
> >> > > > > > > >
> >> > > > > > > > > Things changed overnight on the ELKS repo and
> >now my
> >> > > > > Amstrad PC 2086
> >> > > > > > > > > boots
> >> > > > > > > > > ELKS from 32MB CF card!
> >> > > > > > > > >
> >> > > > > > > > > There are some shortcomings though:
> >> > > > > > > > >
> >> > > > > > > > > 1. Bootable MINIX image does not contain
> >partition table.
> >> > > > > There's
> >> > > > > > > > > nothing
> >> > > > > > > > > wrong about that, yet it makes ELKS's
> >Partition Check
> >> > > > > routine lost a
> >> > > > > > > > > bit.
> >> > > > > > > > > Contrary to this, the Desktop tools for
> >managing external
> >> > > > > storage in my
> >> > > > > > > > > Desktop Linux environment somehow are able to
> >spot that and
> >> > > > > do mount
> >> > > > > > > > > MINIX
> >> > > > > > > > > fs on /dev/sdc when asked, not on /dev/sdc1 or
> >anything
> >> > > > > else (note that
> >> > > > > > > > > fdisk /dev/sdc shows rubbish like non-existing
> >/dev/sdc4
> >> > > > > partition of
> >> > > > > > > > > exotic type and size). ELKS's Partition Check
> >also shows
> >> > > > > rubbush bda4
> >> > > > > > > > > partition of a very wrong size.
> >> > > > > > > > >
> >> > > > > > > > > 2. Root fs mount fails asking me to insert
> >rootfs floppy:
> >> > > > > > > > >
> >> > > > > > > > > FAT: can't read super
> >> > > > > > > > > VFS: Insert root floppy and press ENTER
> >> > > > > > > > >
> >> > > > > > > > > Fortunately, I still have one. Yet during
> >that, good old
> >> > > > > problem with
> >> > > > > > > > > mounting on-card fs appeared again:
> >> > > > > > > > >
> >> > > > > > > > > minix: unable to read sb
> >> > > > > > > > > mount failed: Invalid argument
> >> > > > > > > > >
> >> > > > > > > > > I suspect it tried to mount non-existing
> >/dev/bda1 or wrong
> >> > > > > /dev/bda4
> >> > > > > > > > > partition as suggested by misleading Partition
> >Check
> >> > > > > > > > >
> >> > > > > > > > > When I finally reached the shell, I managed to
> >mount MINIX
> >> > > > > fs anyway,
> >> > > > > > > > > just
> >> > > > > > > > > by doing:
> >> > > > > > > > >
> >> > > > > > > > > mount /dev/bda /mnt
> >> > > > > > > > >
> >> > > > > > > > > and it just worked, all the files and
> >directories were
> >> > > > > there!
> >> > > > > > > > >
> >> > > > > > > > > Cheers,
> >> > > > > > > > > Paul
> >> > > > > > > > >
> >> > > > > > > > > On Thu, 6 Feb 2020, Paul Osmialowski wrote:
> >> > > > > > > > >
> >> > > > > > > > > > Some more update:
> >> > > > > > > > > >
> >> > > > > > > > > > I've compiled FAT support into kernel. Then
> >I've also
> >> > > > > built HD image
> >> > > > > > > > > > with
> >> > > > > > > > > > FAT filesystem (non-bootable), in facts,
> >what have been
> >> > > > > built was not
> >> > > > > > > > > > binary image, it was rather rootfs in the
> >'target'
> >> > > > > directory. I've
> >> > > > > > > > > > created
> >> > > > > > > > > > partition table on the 32MB CF card with DOS
> >partition
> >> > > > > and formated
> >> > > > > > > > > > the
> >> > > > > > > > > > partition with FAT16 filesystem (all using
> >FreeDOS booted
> >> > > > > from
> >> > > > > > > > > > floppy).
> >> > > > > > > > > > Then I've rebooted the machine with ELKS
> >bootable floppy
> >> > > > > and this
> >> > > > > > > > > > time...
> >> > > > > > > > > > the rootfs was mounted by init into '/mnt'
> >mountpoint. So
> >> > > > > the HDD
> >> > > > > > > > > > support
> >> > > > > > > > > > isn't that entirely bad in ELKS and we're
> >nearly there!
> >> > > > > What I also
> >> > > > > > > > > > immediately noticed is that this system
> >lacks 'chroot'
> >> > > > > command...
> >> > > > > > > > > >
> >> > > > > > > > > > Cheers,
> >> > > > > > > > > > Paul
> >> > > > > > > > > >
> >> > > > > > > > > > On Thu, 6 Feb 2020, Paul Osmialowski wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > Hi Marc,
> >> > > > > > > > > > >
> >> > > > > > > > > > > Now it prints:
> >> > > > > > > > > > >
> >> > > > > > > > > > > C=0x3C H=0x10 S=0x3F
> >> > > > > > > > > > >
> >> > > > > > > > > > > Following this, I've tried to build HD
> >boot image with
> >> > > > > 63 sectors,
> >> > > > > > > > > > > 16
> >> > > > > > > > > > > heads and 60 tracks (cylinders), but it
> >still dies at
> >> > > > > '....4!'.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Also, when I booted ELKS from floppy
> >again, I noticed
> >> > > > > it tried to
> >> > > > > > > > > > > mount
> >> > > > > > > > > > > filesystem on the card with the image
> >mentioned above
> >> > > > > that I left in
> >> > > > > > > > > > > the
> >> > > > > > > > > > > CF adapter. It failed eventually as such:
> >> > > > > > > > > > >
> >> > > > > > > > > > > Mounting FAT filesystem: hd: error:
> >AX=0x04
> >> > > > > > > > > > > BIOSHD: I/O error
> >> > > > > > > > > > > dev 301, sector 2
> >> > > > > > > > > > > minix: unable to read sb
> >> > > > > > > > > > > mount failed: Invalid argument
> >> > > > > > > > > > >
> >> > > > > > > > > > > This 'Mounting FAT filesystem' message is
> >kinda
> >> > > > > misleading: I didn't
> >> > > > > > > > > > > compile FAT support into the system, and
> >the image on
> >> > > > > CF card has
> >> > > > > > > > > > > MINIX
> >> > > > > > > > > > > filesystem installed.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Cheers,
> >> > > > > > > > > > > Paul
> >> > > > > > > > > > >
> >> > > > > > > > > > > On Wed, 5 Feb 2020, Marc-F. Lucca-Daniau
> >wrote:
> >> > > > > > > > > > >
> >> > > > > > > > > > > > Yep, hex error fixed in latest commit:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > >
> >https://github.com/elks-org/elks/commit/6332929104591ecbd62f18757a76506938cf96ce
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > MFLD
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Le 03/02/2020 ? 23:05, Paul Osmialowski
> >a écrit :
> >> > > > > > > > > > > > > probe.bin prints:
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Boot sector
> >> > > > > > > > > > > > > C=0x3D H=0x10 S=0x3G
> >> > > > > > > > > > > > > Press key
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > 0x3G is a rather strange hex value...
> >I assume
> >> > > > > off-by-one error
> >> > > > > > > > > > > > > while
> >> > > > > > > > > > > > > doing 'A' + h.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > I looked at what fdisk on different
> >systems prints
> >> > > > > about this
> >> > > > > > > > > > > > > 32MB CF
> >> > > > > > > > > > > > > card.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > On Linux (fdisk -c=dos /dev/sdX):
> >cyls: 1024,
> >> > > > > heads: 1, sects:
> >> > > > > > > > > > > > > 61
> >> > > > > > > > > > > > > On Linux (fdisk -c=dos on FreeDOS
> >image): cyls: 3,
> >> > > > > heads: 16,
> >> > > > > > > > > > > > > sects: 63
> >> > > > > > > > > > > > > On FreeDOS (fdisk /info /tech): TC: 61
> > TH: 15 TS:
> >> > > > > 63
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > I've tried all of those values, with
> >the same
> >> > > > > effect (....4!).
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Also I think the name of config option
> >in kernel
> >> > > > > configuration
> >> > > > > > > > > > > > > is
> >> > > > > > > > > > > > > misleading. Tracks refers to number of
> >tracks per
> >> > > > > cylinder which
> >> > > > > > >
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2020-02-22 17:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LNX.2.21.1904141943280.11933@localhost.localdomain>
[not found] ` <alpine.LNX.2.21.1904151809190.25824@localhost.localdomain>
[not found] ` <e10535c1-4751-7e9a-5f76-9cc631e4eb3c@gmail.com>
[not found] ` <alpine.LNX.2.21.1904162210400.4944@localhost.localdomain>
[not found] ` <6e26eeeb-c80a-c42b-f2af-91b8df146a5e@gmail.com>
[not found] ` <alpine.LNX.2.21.1904172300570.28634@localhost.localdomain>
[not found] ` <cf48f070-f306-4afa-8afa-3e5b338114e7@gmail.com>
[not found] ` <alpine.LNX.2.21.1904181343510.11093@localhost.localdomain>
[not found] ` <1c3b5526-66ae-5ed3-ecc2-b6e7f14b53ca@gmail.com>
[not found] ` <alpine.LNX.2.21.1.1912161352140.19666@localhost.localdomain>
[not found] ` <alpine.LNX.2.21.1.1912171117001.25658@localhost.localdomain>
[not found] ` <f62d11b1-8e42-cbd9-d466-b4b60c5c18ea@gmail.com>
[not found] ` <alpine.LNX.2.21.1.1912172310001.28757@localhost.localdomain>
[not found] ` <CACpuWUnxxZr=8i0srFGkSPPLzrhMxMVBF1xXbh6ZXaG2ORS8Tw@mail.gmail.com>
[not found] ` <alpine.LNX.2.21.1.1912182337240.24813@localhost.localdomain>
[not found] ` <alpine.LNX.2.21.1.1912182347540.24813@localhost.localdomain>
[not found] ` <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com>
2020-01-24 21:05 ` Cannot boot the real thing from HDD Marc-F. Lucca-Daniau
2020-01-30 19:51 ` Paul Osmialowski
2020-01-30 21:43 ` Marc-F. Lucca-Daniau
2020-02-01 10:28 ` Marc-F. Lucca-Daniau
2020-02-03 16:59 ` Paul Osmialowski
2020-02-03 18:52 ` Marc-F. Lucca-Daniau
2020-02-03 22:05 ` Paul Osmialowski
2020-02-03 22:09 ` Paul Osmialowski
2020-02-05 15:37 ` Paul Osmialowski
2020-02-08 9:35 ` Marc-F. Lucca-Daniau
2020-02-08 12:58 ` Paul Osmialowski
2020-02-05 19:26 ` Marc-F. Lucca-Daniau
2020-02-05 23:45 ` Paul Osmialowski
2020-02-06 10:07 ` Paul Osmialowski
2020-02-08 13:08 ` Paul Osmialowski
2020-02-10 23:38 ` Paul Osmialowski
2020-02-11 20:38 ` Marc-F. Lucca-Daniau
2020-02-12 19:39 ` Marc-F. Lucca-Daniau
[not found] ` <alpine.LNX.2.21.1.2002122207100.31423@localhost.localdomain>
[not found] ` <CACpuWU=DhqB93KxhmD2jpueOUrAkSPVeMPmLnRq4_j=zLjfm5g@mail.gmail.com>
[not found] ` <alpine.LNX.2.21.1.2002122326370.561@localhost.localdomain>
2020-02-17 21:24 ` Marc-F. Lucca-Daniau
2020-02-17 21:27 ` Paul Osmialowski
2020-02-17 21:34 ` Paul Osmialowski
2020-02-20 23:21 ` Paul Osmialowski
2020-02-22 16:24 ` Derek Johansen
2020-02-22 16:38 ` Jody Bruchon
2020-02-22 17:19 ` Derek Johansen [this message]
2020-02-22 21:27 ` Paul Osmialowski
2020-02-21 9:11 ` Marc-F. Lucca-Daniau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOv0vdnTnsJoOJXdUCrgLJNsxasVfRfTQ5VVm9POKgwFUNRYCQ@mail.gmail.com \
--to=djohanse678@gmail.com \
--cc=jody@jodybruchon.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).