gmane.os.netbsd.ports.amiga

Re: amiga kernel missing

Radoslaw Kujawa — 2013-05-17T22:26:17

Hi.

On 16 May, 2013, at 21:58 , Al Zick <al< at >familysafeinternet.com> wrote:


You've mentioned having working floppy drive in your Amiga. Do you have any other machine with floppy drive?

If yes, then you can use floppy disks formatted as 720kB FAT12 to transfer stuff to AmigaOS. Google for "CrossDOS".

Re: amiga kernel missing

Al Zick — 2013-05-16T19:58:40

Hi,


On May 16, 2013, at 1:43 PM, Radoslaw Kujawa wrote:


That is the trick getting the network card to work under Amiga OS.

Thanks,
Al

Re: amiga kernel missing

Radoslaw Kujawa — 2013-05-16T17:43:06

On 16 May, 2013, at 5:43 , Al <al< at >familysafeinternet.com> wrote:

Try loadbsd maybe? Although, I doubt that gobsd is at fault here.



I'm not sure if I understand your problem then. Why don't you copy the kernel over ethernet from some other machine? Assuming that you have some network stack installed on AmigaOS, that would be the easiest way.

Re: amiga kernel missing

Al — 2013-05-16T03:46:52

Hi John,


If it is SCSI I could. I don't have a CompactFlash reader. NetBSD 6 is 
fine.

Thanks,
Al

Re: amiga kernel missing

Al — 2013-05-16T03:43:31

Hi,

On Thu, 16 May 2013, Radoslaw Kujawa wrote:
I normally don't transfer the kernel to the amiga partition. I usually use 
gobsd, but it stopped booting for some reason. It does not have a cdrom, 
but it does have ethernet cards.

Thanks,
Al

amiga kernel missing

Al — 2013-05-15T22:50:55

Hi,

I am really sorry to bother everyone with this, but I may have really 
messed things up. Anyway, I need a kernel on my amiga partition to make it 
boot now. I am not sure what is the best way to get it there. I would be 
willing to pay someone to put a NetBSD 5.2 or newer kernel on an amiga 
formated floppy and send it to me.

Thanks,
Al

(unknown)

Robert — 2013-05-02T02:13:17

From Robert Walter (For Trustees)
Managing Partner (Stevens & Walter)
London - United Kingdom.

Notification of Bequest

On behalf of Stevens and Walter Chambers, Trustees and Executors of the
estate of Late Kaiser Hartmann, I once again try to notify you as my
earlier letter was returned undelivered. I hereby attempt to reach you
again by this same email address.

Please if I reach you, as I am hopeful, endeavor to get back to me as soon
as possible for further details.

I look forward to your prompt response.

Yours sincerely,
Robert Walter





The content of this email and any attachment(s) are for the sole use of the intended recipient(s). Any unauthorised review, retention, duplication, disclosure or distribution is prohibited. If you are not an intended recipient, please notify the sender by reply email, do not use or share it. Subject to applicable law, we may monitor, review, retain and archive copies of electronic communications travelling through our networks/systems, without further notice or co

(unknown)

Regina Clay — 2013-04-30T11:34:22

Are you interested in any kind of financial help?.
If yes email us via: kimholdings44< at >sbcglobal.net

build of NetBSD 5.2 failed

Al — 2013-04-02T01:33:26

Hi,

I am trying to compile NetBSD 5.2 on a 5.1.2 system. The build ended with:
/src/../obj/destdir.amiga/usr/include             -c 
/usr/src/dist/atf/tests/atf/atf-c++/t_fs.cpp
virtual memory exhausted: Cannot allocate memory

*** Failed target:  t_fs.o
*** Failed command: /usr/src/../tools/bin/m68k--netbsdelf-c++ 
-frandom-seed=NetBSD-5/\^destdir/usr/include/atf-c++/exceptions.hpp\ 
\^destdir/usr/include/atf-c++/fs.hpp
\ \^destdir/usr/include/atf-c++/macros.hpp\ 
\^destdir/usr/include/atf-c++/tests.hpp\ 
\^destdir/usr/include/atf-c++/utils.hpp\ 
\^destdir/usr/include/atf-c/defs.h\ \^des
tdir/usr/include/atf-c/dynstr.h\ \^destdir/usr/include/atf-c/error.h\ 
\^destdir/usr/include/atf-c/fs.h\ \^destdir/usr/include/atf-c/list.h\ 
\^destdir/usr/include/atf-c

The system has 128 Mb of ram and a 516 MB swap partition. Could it really 
need more swap?

Also, is there a way that I can make the build pick up where it left off?

Best Regards,
Al

Off-by-one CD-ROM bug (was Re: Possible problem with accessing DVDs larger than 4GB)

Mark — 2013-03-21T11:14:06

Hi,

Following up on my previous message...

On Sun, March 3, 2013 21:16, Mark wrote:

This is actually a bug in NetBSD; I'm surprised no-one else noticed it
before. I have filed a report at the netbsd.org bug tracker, but if anyone
is interested...

The bug is in src/sys/dev/scsipi.cd.c, in the read_cd_capacity() function.
The bug was first introduced in version 1.227:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/scsipi/cd.c?annotate=1.227
Compare with 1.226:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/scsipi/cd.c?annotate=1.227

The line
*size = _4btol(data.addr);
should be changed to read
*size = _4btol(data.addr) + 1;

Re: Possible problem with accessing DVDs larger than 4GB

Michael L. Hitch — 2013-03-09T05:12:51


   That would be because you are using the block device, /dev/cd0c.  That 
will read the device data into a kernel buffer, using BLKDEV_IOSIZE sized 
reads, which is 2048 bytes.  It also means that the data has to be copied 
to the user buffer after it has been read, slowing things down even more.

   If you use the character (raw) device, /dev/rcd0c, then the transfer 
will use up to 64K byte I/O, and the data is read directly into the user 
buffer.

Mike

---
Michael L. Hitch                        mhitch< at >montana.edu
Operations Consulting,  Information Technology Center
Montana State University, Bozeman, MT     USA

Re: Possible problem with accessing DVDs larger than 4GB

Mark — 2013-03-03T21:16:53

Hi,

On Thu, February 28, 2013 21:31, Mark wrote:

After some more testing, it seems NetBSD 3.1 doesn't have the off-by-one
problem, but both NetBSD 4.0.1 and 5.2 do. So if this *is* actually a
NetBSD bug, the regression appeared somewhere between 3.1 and 4.0.1.

It would be great if someone could test using dd on their real Amiga and
recent NetBSD. The problem only seems to occur with CD-ROMs, not when
using dd to read the last sectors of the hard disk.

Re: Possible problem with accessing DVDs larger than 4GB

Frank Wille — 2013-02-28T21:53:54

booting NetBSD 6.0.1 and doing

Just in this minute I finished my test too. I used an A3000/060 with SCSI
CDR, running on NetBSD 6.0.

How did you determine the correct number of blocks on the CD?
I ask because NetBSD's disklabel showed me 85427 for my test CD, while
MorphOS (info blocks) displayed 85396. ;)

I tried the dd(1) command, as you wrote above, into a file, but the system
crashed (hard reboot) after a few minutes.

Then I tried it again with of=/dev/null. Now I got the expected result of
85427 blocks. No problem with 6.0 on a real A3000/060.



I should do a test with another 6.x system to verify that.

A second test with NetBSD/macppc 5.2 and an ATAPI drive was interesting:
disklabel(8) showed 85428 - 1 block more! And dd(1) also transfered this
additional block.

So there is either a problem with the SCSI CDRom driver, or with the Amiga
port, or a general problem since NetBSD 6.

Re: Possible problem with accessing DVDs larger than 4GB

Mark — 2013-02-28T21:31:14

Hi,

On Mon, February 25, 2013 18:14, Mark wrote:
booting NetBSD 6.0.1 and doing
dd, to skip most of the disc.)

I did some more testing. At least in WinUAE (A3000, SCSI CD drive), NetBSD
2.1 doesn't have that problem. It reads all 19057 sectors from the disc.
And the same with NetBSD 1.6.2 with emulated A4000 and ATAPI CD drive.

So this issue could possibly be a regression in later NetBSD versions. Or
it could be an emulation bug if earlier versions somehow accessed CDs
differently.

Re: Possible problem with accessing DVDs larger than 4GB

Mark — 2013-02-25T18:14:21

his Amiga first. :)
try
range is truncated modulo 2^32.
hours the 4GB barrier definitely had been crossed:

Thanks very much for taking the time to do that!

I figured out the cause of the problem, which was in WinUAE after all. In
the WinUAE source, blkdev_cdimage.cpp, there was this line:
        cdu->cdsize = cdu->toc[cdu->tracks].address * cdu->blocksize;

The type of cdu->cdsize is uae_u64, but cdu->toc[cdu->tracks].address and
cdu->blocksize are both int. That statement casts the result to uae_u64
after working it out as a (32-bit) int, hence the truncation modulo 2^32.

Quite a hard bug to figure out, not only because I'm no C expert. Running
the Debian 3.1r8 installer, that works fine with the DVD connected via
ATAPI, but has the same truncation bug connecting over SCSI. I assume the
Debian ATAPI driver doesn't prevent out-of-bounds accesses, but the SCSI
driver does. So actually attempting to read the ATAPI DVD past the bogus
READ CAPACITY value did work there.


Anyway. Continuing with the testing

Re: Possible problem with accessing DVDs larger than 4GB

Frank Wille — 2013-02-25T08:47:42

Hi Mark,

sorry for the late reply. But I had to find somebody with a DVD drive on
his Amiga first. :)


On Wed, 13 Feb 2013 17:54:13 -0000
"Mark" <markk< at >clara.co.uk> wrote:


We did the test with A4000 IDE, and after running for more than three
hours the 4GB barrier definitely had been crossed:

2173887+0 records in
2173887+0 records out
4452120576 bytes transferred in 7266.108 secs (612724 bytes/sec)

Re: -m68060 breaks stuff in NetBSD-6

Al Zick — 2013-02-15T22:17:24

Hello,


On Jan 28, 2013, at 5:12 AM, Ignatios Souvatzis wrote:

Could this explain some of the compiling problems that I have in  
NetBSD 6?

Best Regards,
Al

Re: unable to allocate space in parent map

Radoslaw Kujawa — 2013-02-14T19:39:16

Hi.

On 14 Feb, 2013, at 20:04 , Leonard Schmidt <Leonard24< at >gmx.net> wrote:


I saw your previous mail but had no time to take to do any further analysis yet. The problem is quite mysterious for me.


You probably have ddb.onpanic=0 set in sysctl? Change it to 1, then it should drop to DDB instead of dump and reboot. 

Nevertheless, I think all needed information so far is contained on the photos you've taken.

Re: unable to allocate space in parent map

Leonard Schmidt — 2013-02-14T19:04:50


Got HEAD 201302040040Z compiled and installed. Typing "iteconfig" directly after the login does nothing. Typing "iteconfig -w 100 -h 75" panics with cannot allocate memory message. Changing console resolution to 800x600x8 with "grfconfig /dev/grf7 /etc/grfmodes" works, but typing "iteconfig" afterwards will panic with a different message. I took some photos, maybe it helps to identify the bug: https://plus.google.com/u/0/116765303897805064610/posts

When and how do I invoke DDB? During core dump no interaction is possible and directly after the dump the amiga resets?

-Leo24

Possible problem with accessing DVDs larger than 4GB

Mark — 2013-02-13T17:54:13

Hi,

I have been testing the latest beta versions of the WinUAE Amiga emulator
with several versions of NetBSD. That's shown up a few bugs in WinUAE's
SCSI and MMU emulation which have been fixed. Hopefully the next release
should be useful for testing NetBSD/amiga with emulated 68030/040/060.
(WinUAE works mostly fine under Wine.)

I came across one issue which might actually indicate a problem with
NetBSD though. I'm hoping someone has access to a real Amiga with DVD-ROM
drive in order to check whether it happens on a real machine.

Testing NetBSD 6.0.1 with emulated SCSI or ATAPI DVD drive, when you try
to access a DVD which is larger than 4GB (2^32 bytes), the accessible
range is truncated modulo 2^32.

For example, one ISO image I used is 4933021696 bytes long.
4933021696 - 2^32 = 638054400 = 311550 * 2048.

Using dd, it stops the 311550-sector point:
# dd if=/dev/cd0c of=/dev/null bs=2048 iseek=311540
9+0 records in
9+0 records out
18432 bytes transferred in 0.089 secs (207101 bytes/sec)

That issue af

Re: unable to allocate space in parent map

Leonard Schmidt — 2013-02-11T13:37:04

I will do that.
Currently I´m stuck in compiling the kernel (tarballs from http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201302101340Z/source/sets/).I used the default compiler options for a test run but it stops. Any idea?

==> MAKECONF file:       /etc/mk.conf (File not found)
#    objdir  /usr/obj/
===> TOOLDIR path:        /usr/src/obj/tooldir.Darwin-12.2.0-x86_64
===> DESTDIR path:        /usr/src/obj/destdir.amiga
===> RELEASEDIR path:     /usr/src/obj/releasedir
===> Created /usr/src/obj/tooldir.Darwin-12.2.0-x86_64/bin/nbmake
===> Updated makewrapper: /usr/src/obj/tooldir.Darwin-12.2.0-x86_64/bin/nbmake-amiga
===> Building kernel without building new tools
===> Building kernel:     GENERIC
===> Build directory:     /usr/src/sys/arch/amiga/compile/obj/GENERIC
Build directory is /usr/src/sys/arch/amiga/compile/obj/GENERIC
Don't forget to run "make depend"
depending the kern library objects
depending the compat library objects
making sure the compat library is up to date...
`libcompat.a' is up to date.