Emm Vasilakis | 10 Apr 11:46 2003
Picon

PLIP and X-surf IDE

Hi,

I would like to ask the list, on the progress (or not) on 2 things:

1) PLIP networking. I think someone has started working on it, but I
cant find any clues on whether it is done or not.

2) X-surf IDE controllers. Same story.

I would be interested in trying to get something done here, so if
someone could point me to a starting direction, I would appreciated it.

Thanks,
Emmanuel Vasilakis

John Klos | 18 Apr 01:56 2003

Kernel build failure

Hi,

Has anyone seen this before? I'm trying to use a 1.6_STABLE kernel from
January to build a 1.6.1 kernel from today's sources:

making sure the compat library is up to date...
`libcompat.a' is up to date.
making sure the kern library is up to date...
`libkern.o' is up to date.
ld -n -Ttext 0 -e start -S -o netbsd ${SYSTEM_OBJ} vers.o
siop2.o: In function `siopng_checkintr':
siop2.o(.text+0x22e0): undefined reference to `DCIAS_60'
siop2.o(.text+0x25ae): undefined reference to `DCIAS_60'
siop2.o(.text+0x280a): undefined reference to `DCIAS_60'
pmap.o: In function `pmap_bootstrap':
pmap.o(.text+0x2d0): undefined reference to `DCIS_60'
pmap.o: In function `pmap_init':
pmap.o(.text+0x7e8): undefined reference to `DCIS_60'
pmap.o: In function `pmap_protect':
pmap.o(.text+0x110a): undefined reference to `DCFP_60'
pmap.o(.text+0x1116): undefined reference to `ICPP_60'
pmap.o(.text+0x1152): undefined reference to `TBIS_60'
pmap.o: In function `pmap_enter':
pmap.o(.text+0x1588): undefined reference to `DCFP_60'
pmap.o(.text+0x1594): undefined reference to `ICPP_60'
pmap.o(.text+0x15d2): undefined reference to `TBIS_60'
pmap.o: In function `pmap_kremove':
pmap.o(.text+0x18e2): undefined reference to `TBIS_60'
pmap.o: In function `pmap_zero_page':
pmap.o(.text+0x1d44): undefined reference to `TBIS_60'
(Continue reading)

Picon
Picon

Re: Reading bad floppies.

>>>>> "Ignatios" == Ignatios Souvatzis <is <at> netbsd.org> writes:

Hmmm, I am replying to something that is more than a year old...

I am trying to dd amiga floppies on NetBSD 1.6 and the kernel panics
from time to time.  I believe it is when I encounter a read error.
It also panics when I switch floppy and try another dd.  I have a
vague memory that it used to work ~6 years ago when I had my A3000 up
running NetBSD last time, cannot remember the NetBSD version though..

Message given on console is:
panic: biodone already
Stopped in pid 199 (dd) at     cpu_Debugger+0x6:     unlk    a6

Is there a patch/fix available?

Håkan

Ignatios> On Sat, Mar 02, 2002 at 03:41:27AM +1100, Darren Reed wrote:
>> 
>> I've been dd'ing lots of floppies into ADF files (mmm, winuae) and have
>> found that reading some floppies can cause NetBSD (1.1) to panic.

Ignatios> dd-ing bad floppies can panic NetBSD-1.1? Sounds new to me.

>> Does anyone know if this problem has been fixed since or should I dig
>> in and boot up a kernel, etc and file a decent PR? 

Ignatios> This would be very helpful.

(Continue reading)

Ignatios Souvatzis | 20 Apr 23:59 2003
Picon

Re: Reading bad floppies.

Hi,

On Sun, Apr 20, 2003 at 09:30:17PM +0200, =?ISO-8859-1?Q?H=E5kan Th=F6rngren?= <Håkan Thörngren wrote:

> [...] Is there a patch/fix available?

No. Please use send-pr or the web interface at www.netbsd.org to enter
this report into the NetBSD bug tracking system.

Regards,
	Ignatios
Lars Hecking | 1 May 02:21 2003
Picon

Reading bad disk


 Hi all,

 I'm trying to save data from a broken disk - wondering whether it's possible
 at all.

 Setup: A3000, two internal disks, two external. Ext1 has NetBSD on it,
 ext2 OpenBSD. Both are Sun 1.05GB (Seagate) drives.

 The box was unused for over half a year, on account of the motherboard
 being in a different location :), waiting for the 2nd battery surgery,
 and also a new keyboard. In this period of inactivity, the disk with OBSD
 went bad - no idea how, might just be old age.

 My idea was whether I could salvage anything from that disk via NetBSD,
 but it seems to be next to impossible. Here's the relevant part of dmesg:

NetBSD 1.6.1 (RUSTY) #3: Mon Apr 28 00:59:53 IST 2003
    root <at> localhost:/usr/src/sys/arch/amiga/compile/RUSTY
Amiga 3000 (m68040 CPU/MMU/FPU)
total memory = 22528 KB
avail memory = 19312 KB
using 153 buffers containing 1224 KB of memory
memory segment 0 at 08000000 size 00600000
memory segment 1 at 07000000 size 01000000
memory segment 2 at 00000000 size 00200000
mainbus0 (root)
clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
Calibrating delay loop... 111/1024 us
a34kbbc0 at mainbus0
(Continue reading)

Ignatios Souvatzis | 1 May 10:49 2003
Picon

Re: Reading bad disk

Hi,

On Thu, May 01, 2003 at 01:21:26AM +0100, Lars Hecking wrote:

>  My idea was whether I could salvage anything from that disk via NetBSD,
>  but it seems to be next to impossible. Here's the relevant part of dmesg:

i

> 
> 
> NetBSD 1.6.1 (RUSTY) #3: Mon Apr 28 00:59:53 IST 2003
>     root <at> localhost:/usr/src/sys/arch/amiga/compile/RUSTY
> Amiga 3000 (m68040 CPU/MMU/FPU)
> total memory = 22528 KB
> avail memory = 19312 KB
> using 153 buffers containing 1224 KB of memory
> memory segment 0 at 08000000 size 00600000
> memory segment 1 at 07000000 size 01000000
> memory segment 2 at 00000000 size 00200000
> mainbus0 (root)
> clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
> Calibrating delay loop... 111/1024 us
> a34kbbc0 at mainbus0
> ser0 at mainbus0: input fifo 512 output fifo 256
> par0 at mainbus0
> kbd0 at mainbus0: CIA A type Amiga
> ms0 at mainbus0
> grfcc0 at mainbus0
> grf0 at grfcc0: width 640 height 400 colors 4
(Continue reading)

Lars Hecking | 1 May 13:43 2003
Picon

Re: Reading bad disk


> Only problem is, you'll lose the contents, and it most probably is the
> RDB header block! In case you wrote down the RDB parameters on paper
> somewhere and can repartition the disk to the same values, you'll
> probably lose everything. 

 Yeah, the problem is that I have no saved RDB for these disks - only for
 the internal disks.

> So what you might try, is:
> 
> write a program that reads a block (512 bytes) at offset 0 off the raw disk
> (/dev/rsd3c in this case), and repeats on error, at least a couple of times.
> 
> Once it succeeds, it should:
> 
> a) write that block to a _different_ disk (onto a file!) 
> 
> _Then_ you reassign the block,
> _Then_ you write the saved block back.
> 
> (Hm, a shell loop around dd might work, too).

 Hhm, I've never programmed such low-level stuff before. Will give it a try at
 a moment of leisure :-)

 Thanks!


Gmane