DragonFlyBSD

:Hi,
:
:I've download:
:http://chlamydia.fs.ei.tum.de/pub/DragonFly/snapshots/i386/LATEST-Release-1.6.iso.bz2
:
:and I tried it on a old PC with AMD Athlon 700MHz. and Asus A7V mobo.
:That mainboard has 2 controllers (one Ultra66 and other Ultra100) and 4 ata channels; I've only one hd ata100 master on ata2 channel.

Hmm.  It is panicing on a wild pointer on line 739 of
    sys/dev/disk/ata/ata-disk.c:

request->bio->bio_buf->b_resid = request->bytecount;

Either 'request', 'bio', or 'bio_buf' is a wild pointer.

Could you do a 'trace' from the DDB prompt ?

:kernel type 12 trap, code=2
:stopped at ad_interrupt+0x38a: movl %eax,0x148(%edx)
:db>
:
:Bye, \fer

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Hi Matt,

nice to meet you again (since Amiga DICE time). I appreciate your DFBSD project.

Matthew Dillon wrote:

:Hi,
:
:I've download:
:http://chlamydia.fs.ei.tum.de/pub/DragonFly/snapshots/i386/LATEST-Release-1.6.iso.bz2
:
:and I tried it on a old PC with AMD Athlon 700MHz. and Asus A7V mobo.
:That mainboard has 2 controllers (one Ultra66 and other Ultra100) and 4 ata channels; I've only one hd ata100 master on ata2 channel.

Hmm. It is panicing on a wild pointer on line 739 of
sys/dev/disk/ata/ata-disk.c:

request->bio->bio_buf->b_resid = request->bytecount;

Either 'request', 'bio', or 'bio_buf' is a wild pointer.

Could you do a 'trace' from the DDB prompt ?

ok

:kernel type 12 trap, code=2
:stopped at ad_interrupt+0x38a: movl %eax,0x148(%edx)
:db>

ad_interrupt(c8cd0bc8,c0c91540,c8d25d84,c029d8e9,c0de4450) at ad_interrupt+0x38a

ata_intr(c0de4450,0,0,0,11) at ata_intr+0x10a
ithread_handler(a,0,0,0,0) at ithread_handler+0x9d
lwkt_exit() at lwkt_exit

I fear that such problem was generated by SATA and parallel ATA cables in the same box, then I've disconnected any SATA cable but this error appears in same way.

DragonFlyBSD doesn't detect yet the Promise SATA 300 TX2plus (PDC20775) pci board and devices connected to it.
Can I do something to have support for that controller?

Thank you in advance, \fer
--
NonSoLoSoft (Italy) - http://www.nonsolosoft.com/

:Hi Matt,
:
:nice to meet you again (since Amiga DICE time). I appreciate your DFBSD project.
:
:...
:> :kernel type 12 trap, code=2
:> :stopped at ad_interrupt+0x38a: movl %eax,0x148(%edx)
:> :db>
:
:ad_interrupt(c8cd0bc8,c0c91540,c8d25d84,c029d8e9,c0de4450) at ad_interrupt+0x38a
:
:ata_intr(c0de4450,0,0,0,11) at ata_intr+0x10a
:ithread_handler(a,0,0,0,0) at ithread_handler+0x9d
:lwkt_exit() at lwkt_exit
:
:
:I fear that such problem was generated by SATA and parallel ATA cables in the same box, then I've disconnected any SATA cable but this error appears in same way.

Hmm.  It's clearly a software bug, but finding it is going to be
    difficult.

:DragonFlyBSD doesn't detect yet the Promise SATA 300 TX2plus (PDC20775) pci board and devices connected to it.
:Can I do something to have support for that controller?
:

I did a quick google search and it looks like it ought to be fairly easy
    to support the controller.  A couple of PCI ID entries might do it.

What we really need to do is port the current FreeBSD ATA driver to
    DragonFly.  Our current code is ancient.  I will spend a day to see
    if I can do that.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Matthew Dillon wrote:

Hmm. It's clearly a software bug, but finding it is going to be
difficult.

I've seen that both FreeSBIE 1.0 (FreeBSD 5.3) and FreeBSD 7.0-CURRENT do not report any connection problem to fallback to PIO as DragonFlyBSD 1.4.4 does on this PC and this HD.

ad4: READ command timeout tag=0 serv=0 - resetting
ata2: resetting devices .. done
ad4: 152627MB <WDC WD1600JB-00REA0> [310101/16/63] at ata2-master UDMA100
ad4: READ command timeout tag=0 serv=0 - resetting
ata2: resetting devices .. done
ad4: READ command timeout tag=0 serv=0 - resetting
ata2: resetting devices .. done
ad4: READ command timeout tag=0 serv=0 - resetting
ad4: trying fallback to PIO mode

:DragonFlyBSD doesn't detect yet the Promise SATA 300 TX2plus (PDC20775) pci board and devices connected to it.
:Can I do something to have support for that controller?
:

I did a quick google search and it looks like it ought to be fairly easy
to support the controller. A couple of PCI ID entries might do it.

I've just tested with FreeBSD 7.0-CURRENT and this is output, I don't know if it could be useful for you:

atapci1: <Promise PDC40775 SATA 300 Controller> port 0x947f, 0x9000-0x90ff mem 0xde800000-0xde800fff, 0xde000000-0xde01ffff irq 12 at device 10.0 on pci0

What we really need to do is port the current FreeBSD ATA driver to
DragonFly. Our current code is ancient. I will spend a day to see
if I can do that.

Thank you Matt for your passion on DFBSD. \fer

Matthew Dillon wrote:

What we really need to do is port the current FreeBSD ATA driver to
DragonFly. Our current code is ancient. I will spend a day to see
if I can do that.

thomas spanjaard is working on a patch. maybe he can publish some diffs to make the progress quicker?

cheers
simon

:thomas spanjaard is working on a patch. maybe he can publish some diffs =
:to make the progress quicker?
:
:cheers
: simon

I took a long look at the FreeBSD code today.   It is not going to be an
    easy port, mainly due to a ton of API changes from FreeBSD<->DragonFly
    code divergence.  It isn't hard necessarily, but there will be a lot of
    grunt work.

I am going to continue to work on the userland VFS API, but I'll get
    some of the device API changes done first so the device API stops
    being a moving target.  The device work has to run along the same
    lines as the VFS work.  Moving arguments into argument structures
    and providing an abstraction layer (which are those SYSLINK commits I
    made a few days ago) that will allow them to operate in userland over
    a communications link.

I'll revisit the ATA code and see how Thomas is doing after I get
    the device work done (which should be by the weekend).

-Matt

Matthew Dillon wrote:

I'll revisit the ATA code and see how Thomas is doing after I get
the device work done (which should be by the weekend).

-Matt

Hi Matt,

have you rescheduled ATA revisit?
When do you plan to renew ATA support?

Thank you in advance, \fer

:Hi Matt,
:
:have you rescheduled ATA revisit?
:When do you plan to renew ATA support?
:
:Thank you in advance, \fer

Well, Thomas and Simon set up a mercurial repository, but I really
    don't want to try to use yet another repository to work on the driver.
    I would much prefer that it simply be brought into CVS and worked on
    in CVS.  It would simply remain disconnected from the build until 
    it can be made to work.

There are only two header files outside of the nata driver code that
    conflict.  The nata driver versions of those header files can simply
    be renamed so as not to conflict.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Matthew Dillon wrote:

:have you rescheduled ATA revisit?
:When do you plan to renew ATA support?
:Thank you in advance, \fer
Well, Thomas and Simon set up a mercurial repository, but I really
don't want to try to use yet another repository to work on the driver.
I would much prefer that it simply be brought into CVS and worked on
in CVS. It would simply remain disconnected from the build until
it can be made to work.

You don't have to, it can be imported into CVS and have the existing
patches applied there, and then the remaining work.

There are only two header files outside of the nata driver code that
conflict. The nata driver versions of those header files can simply
be renamed so as not to conflict.

ata.h has already been renamed nata.h, and I guess you're talking about
opt_ata.h for the other one, which can be renamed to opt_nata.h without
too much of a problem. Then the only 'conflict' keeping both drivers
from being in the same system is that the new ATA driver supports the
same hardware as the old one besides new hardware it also supports,
meaning it depends on who attaches first; we could just let config(8)
bail out as soon as it finds both ata and nata devices in the kernel
config. Also, it's possible to have both drivers attach only a set of
devices which don't overlap with eachother. I'm not sure if that's
something worth having?

Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net

:ata.h has already been renamed nata.h, and I guess you're talking about
:opt_ata.h for the other one, which can be renamed to opt_nata.h without
:too much of a problem. Then the only 'conflict' keeping both drivers
:from being in the same system is that the new ATA driver supports the
:same hardware as the old one besides new hardware it also supports,
:meaning it depends on who attaches first; we could just let config(8)
:bail out as soon as it finds both ata and nata devices in the kernel
:config. Also, it's possible to have both drivers attach only a set of
:devices which don't overlap with eachother. I'm not sure if that's
:something worth having?
:
:Cheers,
:--
: Thomas E. Spanjaard
: tgen@netphreax.net

Generally speaking it should be one or the other, but it might actually
    be a good idea to add an exception variable in the kernel environment
    that can be specified in /boot/loader.conf to allow both drivers to 
    attach to different ATA controllers for testing purposes.  Lost of
    machines have normal devices and SATA devices (with different PCI IDs).

This way we could boot a test machine with the old driver talking to 
    the boot disk and the new driver talking to a disk on the other 
    controller.  Again, just for testing.

-Matt

Does this still happen?

I've not worked on this since last report.
I can retry next future as soon as I get that hardware again.

Bye, \fer

No it doesn't happen anymore.

But lastest HEAD that I've got last saturday doesn't detect Promise SATAII 300 TX2.

Here the pciconf -l -v

none0@pci0:10:0: class=0x018000 card=0x3d73105a chip=0x3d73105a rev=0x02 hdr=0x00
vendor = 'Promise Technology Inc'
device = 'PDC20775 SATAII 300 TX2plus IDE Controller'
class = mass storage

Is new ATA ready?

Bye, \fer