Re: [2.0-RC1] shutdown is not clean

Michael Gerhards <HM-Gerhards <at> uni.de> wrote:
> 
>> You can also try the attached patch instead of the old one, to see if the
>> ata revision reported by your drive is the problem.
> 
> I am compiling a new kernel with this patch and will test it this
> evening.

Okay, I tried it now. The first thing I noticed was very astonishing to
me - there was no filecheck necessary on startup!

I got these messages on startup:

wd0 at atabus0 drive 0: <SAMSUNG SP0802N>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 76351 MB, 155127 cyl, 16 head, 63 sec, 512 bytes/sect x 156368016
sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(cmdide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
atapibus0 at atabus1: 2 targets
cd0 at atapibus0 drive 0: <HL-DT-ST DVDRAM GSA-4082B, K2743VM1959, A201>
cdrom removable
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
cd0(cmdide0:1:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
wd0: ata_vers 2, trying flushcache anyway
flush cache command completed
root on wd0a dumps on wd0b
wd0: ata_vers 2, trying flushcache anyway
flush cache command completed
wd0: ata_vers 2, trying flushcache anyway

Re: [2.0-RC1] shutdown is not clean

On Mon, Nov 01, 2004 at 01:14:21AM +0100, Michael Gerhards wrote:
> Okay, I tried it now. The first thing I noticed was very astonishing to
> me - there was no filecheck necessary on startup!

Note that of course it's the *next* boot you need to worry about.

--
Dan.

Re: Creator3D support on Ultra10 (was: on Ultra2)

Hi,

sorry for not reporting back.  Testing this was more tricky than I
expected it to be (among others: defective type5 keyboard, defective
13W3->VGA adaptor cable, machine located in a not-always-accessible
colocation, -current being VERY unstable on the replacement U10 I
planned to run the tests on).  Anyway...

On Mon, Oct 11, 2004 at 02:18:35PM +0200, Timo Sch?ler wrote:
> > ... now building X server...
> did it work?

... XFree86 is now working on this U10 here, on the Creator3D.

Here's the recipe what I did to get it working:

 - use a -current kernel.  2.0_RC4 doesn't have all the necessary bits
   (e.g. ioctl WSDISPLAYIO_LINEBYTES).

 - set up the kernel with these options:

# Creator3D
ffb*           at mainbus0
wsdisplay*     at ffb?
# keyboard / mouse
wskbd*          at kbd?                 # console ? 
wsmouse*        at ms?

options         RASTERCONSOLE           # fast rasterop console
options         RASOPS_CLIPPING

Re: [2.0-RC1] shutdown is not clean

Daniel Carosone <dan <at> geek.com.au> wrote:

>> Okay, I tried it now. The first thing I noticed was very astonishing to
>> me - there was no filecheck necessary on startup!
> 
> Note that of course it's the *next* boot you need to worry about.

Sure. I didn't write this clearly, I see. I compiled the new kernel,
booted the system with it once and then I shut down, connected the
serial console and booted again. All messages in my last posting are
from this _second_ booting of the patched kernel.

And I booted the system again five minutes ago - no filechecking either!

Michael

Re: Creator3D support on Ultra10 (was: on Ultra2)

Hi,

following up on my own post - bad style, sorry for that...

On Mon, Nov 01, 2004 at 11:11:23AM +0100, Gert Doering wrote:
>  - X is *slow*.  I'm running x11perf right now, and comparing its output
>    to something I did a while ago on a Pentium-133 with an elderly S3
>    card (anno 1998 or so), and the S3 outperforms the Creator by about
>    factor 3-20.   I assume that, as of today, the Creator X11 isn't
>    accellerated in any way, just having basic "set this pixel"
>    functionality.

This is to be expected, of course.  The XFree86 "wsfb" driver is not
accellerated (as its man page says), so there is no way to make this
fast.

There's a "sunffb" driver in the xsrc-current/xfree source tree that 
claims to be accellerated, and it's has also seen some changes this
year (so it's not a "dead" project).

From what I found in Google, some Linux/Sparc users are using this, and it
seems to work for them.

I don't understand, though, how the "Linux userland / XFree86 -> graphics
hardware" interface works, and neither how "NetBSD userland / XFree 86
-> graphics hardware interface" works either, and what needs to be done
to make this driver work on NetBSD/Sparc64...

If I just set up a device section as this:

Re: [2.0-RC1] shutdown is not clean

On Mon, Nov 01, 2004 at 01:14:21AM +0100, Michael Gerhards wrote:
> [...]
> And when I pressed the power button, I got these messages:
> login: Oct 31 04:57:34 ultra10 shutdown: halt by root: power button
> pressed
> Oct 31 04:57:35 ultra10 shutdown: halt by root: power button pressed
> Oct 31 04:57:43 ultra10 syslogd: Exiting on signal 15
> syncing disks... done
> wd0: ata_vers 2, trying flushcache anyway
> flush cache command completed
> 
> 
> So what does this tell us about the problem?

You drive claims to support only version 2 of ATA protocol, while it supports
some ATA-4 commands (WDC_FLUSHCACHE is part of the ATA command set since
ATA-4).

> At the moment, there is no
> problem, is it?

No, because my patch forces the execution of WDC_FLUSHCACHE regardless of the
revision. But it's not really an acceptable fix.
Could you see if the attached patch fix your problem ? If so I'll commit it.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Re: [2.0-RC1] shutdown is not clean

Manuel Bouyer <bouyer <at> antioche.eu.org> wrote:
> 
> You drive claims to support only version 2 of ATA protocol, while it supports
> some ATA-4 commands (WDC_FLUSHCACHE is part of the ATA command set since
> ATA-4).

Okay, so it is actually a firmware bug of my hard drive, not a bug in
NetBSD. But NetBSD needs a work-around in order to solve this problem...

>> At the moment, there is no
>> problem, is it?
> 
> No, because my patch forces the execution of WDC_FLUSHCACHE regardless of the
> revision. But it's not really an acceptable fix.
> Could you see if the attached patch fix your problem ? If so I'll commit it.

I will try it Friday evening.

Many thanks for your help,

Michael

Re: [2.0-RC1] shutdown is not clean

Manuel Bouyer <bouyer <at> antioche.eu.org> wrote:
> 
> No, because my patch forces the execution of WDC_FLUSHCACHE regardless
> of the revision. But it's not really an acceptable fix.  Could you see
> if the attached patch fix your problem ? If so I'll commit it.

Okay, I patched the kernel with this patch now. I shut down the system
several times by pressing the power button - and every time the system
came up again _without_ doing any filesystem checks! So to me it looks
like this patch fixes the problem! That's great!

Thank you very much for your help!

Michael

Subject: sleep forever bug - not fixed

hi folks.

i have sad sorry news :(  my U5/300 which is running only earlier this
week's -current has just hit the sleep forever bug.  it seemed to take
a good almost two of hitting it with constant 3-11MB/sec read & write
access to a sata disk via NFS for the problem to surface this time
(unlike previous where it would take not long at all.)

the bug fix may have helped - but it hasn't fixed everything 

.mrg.

Subject: re: sleep forever bug - not fixed

   i have sad sorry news :(  my U5/300 which is running only earlier this
   week's -current has just hit the sleep forever bug.  it seemed to take
   a good almost two of hitting it with constant 3-11MB/sec read & write

that's "two days"

   access to a sata disk via NFS for the problem to surface this time
   (unlike previous where it would take not long at all.)

   the bug fix may have helped - but it hasn't fixed everything