Avtar Gill | 3 Feb 09:01 2004
Picon

Two Netwinders 2100 OfficeServers for sale

Hi I have two Netwinders 2100 OfficeServers for sale. They are
both in perfect condition and still in the original box along
with unopened manuals, CDs, etc. I'm asking $188 US for each
if sold separately or $337 US if someone will buy both
together. Pictures of the machines can be provided if required.
Please contact me off the list for more information. Thanks!

Chris Budd | 3 Feb 18:44 2004
Picon

Problems with cmdide on iq80321

I have an Intel iq80321 eval board running a fairly recent NetBSD build
(20040128).  In the dmesg included below, you can see NetBSD recognizes
and configures the PCI card -- a CMD 649 PCI ATA/IDE adapter.  It also
recognizes the hard drive, WDC AC21200H.  I cannot mount this NetBSD
drive nor can I create or view the disklabel.

This same card, cable, and hard drive work fine on a x86 PC running
NetBSD 1.6 from September 2002.  Therefore, I know this equipment works
and works with NetBSD.

I have tried twiddling jumper and switch settings on the iq80321, but it
either did nothing, or made it worse.

Couple of oddities:

1.  NetBSD 1.6.1 on the iq80321 board does not recognize and configure
    this card like NetBSD 1.6 did on the x86 PC; I believe 1.6 on the
    iq80321 does not congfigure the PCI card as well.
2.  NetBSD 1.6ZI (20040128) on the iq80321 uses a cmdide driver for this
    PCI card while 1.6 on the x86 PC uses a more generic pciide driver.

Unless someone has a better idea, my next step is to build my own NetBSD
configuration for the iq80321.  I can at least add some debug or maybe
change the configuration.

Thanks,
Chris.

Here's the dmesg and disklabel output.

(Continue reading)

bumblebee | 4 Feb 14:04 2004
Picon

FW_Employees Revenge

Ha-ha, brilliant! 

Iíve tried this for the last three days, worked perfectly and got my £50 worth every time.

Do you know any overworked, underpaid friends or colleagues? Give them this story to warm their hearts. 

-----Original Message-----
From: Nick Roberts [mailto:nickroberts <at> hotpop.com] 
Sent: 16 January 2004 11:26
To: Belinda [mailto: bumblebee <at> myrealbox.com]
Subject: Employees revenge

Hi,

Once upon a time there was a hard-working software engineer slaving away under cruel masters. The engineer
poured heart and soul into his work till early hours every morning, with the promise of glorious profit
sharing. When the work was finally done, this poor engineer was rewarded by being dismissed and shown the door.

The company I used to work for runs a website:-  www.gamesofskill.co.uk. However after I had left, they went
live with the system, WITH THE TESTING BACKDOOR STILL IN PLACE !!!!! If you call their competition line on
0906 340 1235 and enter "0" instead of a real answer, then the system lets you through to win a prize - Idiots!
They do charge the call at £1.50 per minute but it only lasts one and a half minutes.

Moral of this story? Donít p*ss off employees, especially oneís you fire! 

Viva the workers! Down with the bosses! Share the wealth!

Snorlax | 4 Feb 14:11 2004
Picon

Re: FW_Employees Revenge

Ehm, why the heck do we get such crap on the port-arm?!
Not only is it a fellony, but in addition it's got nothing to do with NetBSD
or ARM...
Sorry for the rant. Just couldn't keep in this time : )

Filip

----- Original Message -----
From: <bumblebee <at> myrealbox.com>
To: <port-arm <at> NetBSD.org>
Sent: Wednesday, February 04, 2004 2:04 PM
Subject: FW_Employees Revenge

> Ha-ha, brilliant!
>
> I've tried this for the last three days, worked perfectly and got my £50
worth every time.
>
> Do you know any overworked, underpaid friends or colleagues? Give them
this story to warm their hearts.
>
>

Hiroyuki Bessho | 9 Feb 10:46 2004
Picon

Re: ARM9 cache routines updated

Richard Earnshaw <rearnsha <at> arm.com> writes:

>
> If anyone has access to the various Samsung ARM920-based boards I'd be 
> interested to hear how this affects performance.
>

 I got an lmbench result on SMDK2410.

                 L M B E N C H  1 . 9   S U M M A R Y
                 ------------------------------------
		 (Alpha software, do not distribute)

Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host                 OS  Mhz null null      open selct sig  sig  fork exec sh  
                             call  I/O stat clos       inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
2410-a     NetBSD 1.6ZI  200  3.1  19.   74  1650 0.51K 10.8   26 7.1K  31K  77K
2410-a     NetBSD 1.6ZI  200  3.1  19.   75  1654 0.52K 10.9   26 7.1K  31K  77K
2410-b     NetBSD 1.6ZI  200  1.8  10.   41  1566 0.29K  6.4   16 6.2K  27K  67K
2410-b     NetBSD 1.6ZI  200  1.8  10.   41  1595 0.29K  6.4   16 6.2K  27K  67K
2410-c     NetBSD 1.6ZI  200  3.1  19.   74  1527 0.51K 10.7   26 7.2K  29K  72K
2410-c     NetBSD 1.6ZI  200  3.1  19.   73  1599 0.50K 10.6   26 7.2K  29K  72K
2410-d     NetBSD 1.6ZI  200  1.5  9.5   36  1431 0.26K  5.3   13 5.8K  24K  59K
2410-d     NetBSD 1.6ZI  200  1.5  9.5   36  1478 0.26K  5.4   13 5.8K  24K  59K

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host                 OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
(Continue reading)

Richard Earnshaw | 9 Feb 11:13 2004

Re: ARM9 cache routines updated


bsh <at> grotto.jp said:
>   The kernels were built from -current source as of 2004-Feb-04, with
> following changes:

>   2410-a: backed out both write-back dcache change and clocking-mode
>           bits fix in arm9_setup().
>           (using sys/arm/include/cpufunc.h:1.29, sys/arm/arm/
> cpufunc.c:1.65, 
>           sys/arm/arm/cpufunc_asm_arm9.S:1.2)

>   2410-b: with clocking-mode bits fix in arm9_setup(), and without
>           write-back d-cache.

>   2410-c: with write-back d-cache chages, and without clocking-mode
>           bits fix.

>   2410-d: both write-back d-cache changes and clocking-mode bits fix.

>   It showed that clocking-mode bits fix made better results for all
> tests, while write-back d-cache changes gave lower performance on some
> tests. 

Thanks for doing this.  Yes, I think these results are what one would 
expect empirically.

The clock speed improvements are universally good.  Why would running on a 
slower clock ever be better?

The dcache changes are good when you don't need cache flushes (the tests 
(Continue reading)

jbi130 | 9 Feb 18:32 2004
Picon

Netbsd on IXP1200 'howto'

I have an Intel IXP1200 evaluation board running cygmon/linux.  I was
wondering if there are any docs on how to get NetBSD loaded on such a
board.  I've checked the archives and haven't found much to help me
out.

Thanks.

Hiroyuki Bessho | 15 Feb 23:25 2004
Picon

Re: ARM9 cache routines updated

Richard Earnshaw <rearnsha <at> arm.com> writes:

>
> Another useful test that I sometimes run is to time how long it takes to 
> run the configure script for the 'GNU make' source package.
>

  I did it. Kernels are same ones I used in the last report.

  2410-a: backed out both write-back dcache change and clocking-mode
          bits fix in arm9_setup().
          (using sys/arm/include/cpufunc.h:1.29, sys/arm/arm/cpufunc.c:1.65, 
          sys/arm/arm/cpufunc_asm_arm9.S:1.2)

  2410-b: with clocking-mode bits fix in arm9_setup(), and without
          write-back d-cache.

  2410-c: with write-back d-cache chages, and without clocking-mode
          bits fix.

  2410-d: both write-back d-cache changes and clocking-mode bits fix.

smdk2410-a:
      246.77 real       129.77 user        96.28 sys
      234.45 real       127.70 user        93.97 sys
      234.01 real       126.54 user        93.70 sys

smdk2410-b:
      199.95 real        92.56 user        86.82 sys
      188.92 real        91.76 user        84.83 sys
(Continue reading)

McGranaghan, Sean | 16 Feb 00:15 2004

Evbarm questions

Hello all,
 
I have recently started working with the evbarm port of NetBSD. Please feel free to re-direct me to an appropriate list for followup if needed.
 
I have two questions:
 
1.) I have configured a kernel to boot from a ramdisk. The default size is 8192 blocks (4M). If I try and increase the size of the ramdisk my new kernel panics with the following error:
 
"panic: pmap_map_chunk: no L2 table for VA 0xc0800000
 Undefined instruction exception!!!"
 
I have set MEMORY_DISK_ROOT_SIZE=16384 in my config file and set the image size to 8192k for the makefs command. Am I missing something else?
 
2.) I have been trying to build a simple LKM under evbarm. When I use modload to load a skeleton driver ld segfaults:
 
"ld -R /dev/ksyms -e fibo_lkmentry -o /tmp/fibo -Ttext 0x0 /tmp/fibo.o
 [1] Segmentation fault (core dumped) ld -R /dev/ksyms...
 modload: can't prelink 'fibo.o' creating 'fibo'
 
After searching the archives I found several emails and a bug report that mention issues with LKM's for evbarm. Issue # port-arm:22015 specifically. What is the current status of LKM's and evbarm? Is this a bug in ld?
 
 
Any help is appreciated,
Sean
 
 
Richard Earnshaw | 16 Feb 16:11 2004

Re: Evbarm questions

> Hello all,
>  
> I have recently started working with the evbarm port of NetBSD. Please feel
> free to re-direct me to an appropriate list for followup if needed.
>  

Port-arm is normally the correct place for evbarm questions.

> I have two questions:
>  
> 1.) I have configured a kernel to boot from a ramdisk. The default size is
> 8192 blocks (4M). If I try and increase the size of the ramdisk my new
> kernel panics with the following error:
>  
> "panic: pmap_map_chunk: no L2 table for VA 0xc0800000
>  Undefined instruction exception!!!"
>  
> I have set MEMORY_DISK_ROOT_SIZE=16384 in my config file and set the image
> size to 8192k for the makefs command. Am I missing something else?
>  

This has come up before, I can't remember the precise details, but it's 
something to do with the number of static L2 page tables that are loaded 
into the kernel pmap when the system starts.  You might be able to find an 
answer by searching back through the port-arm archives.

> 2.) I have been trying to build a simple LKM under evbarm. When I use
> modload to load a skeleton driver ld segfaults: 
>  
> "ld -R /dev/ksyms -e fibo_lkmentry -o /tmp/fibo -Ttext 0x0 /tmp/fibo.o
>  [1] Segmentation fault (core dumped) ld -R /dev/ksyms...
>  modload: can't prelink 'fibo.o' creating 'fibo'
>  
> After searching the archives I found several emails and a bug report that
> mention issues with LKM's for evbarm. Issue # port-arm:22015 specifically.
> What is the current status of LKM's and evbarm? Is this a bug in ld?
>  

I don't think these are working yet.

R.


Gmane