Re: Big ATA problems

[Nick Hibma]

Maybe this is a silly suggestion, but could someone with a card like
that boot it in a Windows environment and tell us what that hardware
manager tells us about hardware requirements the card would have if it
is configured for the '0x160' address (whatever that configuration is
on the card I don't know)?

Nick

> > > A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
> > > chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
> > > the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.
> > 
> > But in the case of the teles16.3, it does _not_ use offsets 0x00-0x3b in
> > the HSCX or ISAC: the ASIC on the card has 'folded' the address space so
> > that the fifo appears at an address 3 bytes after the last register (0x3e
> > with the current scheme - see tels0163_read_fifo()).
> 
> Oh yes, you are right! I was (and am still a bit) confused.
> 
> So it uses 0x20-0x3e for the ISAC and 0x20-0x3e and 0x60-0x7e for the HSCX
> and at least three bytes at its base address, right ?
> 
> This makes sense. Now the real question left is are this the only locations
> where the card is driving the bus ?
> 
> hellmuth
> -- 
> Hellmuth Michaelis[EMAIL PROTECTED]   Hamburg, Europe
>  We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Hellmuth Michaelis]

Andrew Gordon wrote:

> On Sun, 20 Feb 2000, Hellmuth Michaelis wrote:
> > 
> > A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
> > chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
> > the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.
> 
> But in the case of the teles16.3, it does _not_ use offsets 0x00-0x3b in
> the HSCX or ISAC: the ASIC on the card has 'folded' the address space so
> that the fifo appears at an address 3 bytes after the last register (0x3e
> with the current scheme - see tels0163_read_fifo()).

Oh yes, you are right! I was (and am still a bit) confused.

So it uses 0x20-0x3e for the ISAC and 0x20-0x3e and 0x60-0x7e for the HSCX
and at least three bytes at its base address, right ?

This makes sense. Now the real question left is are this the only locations
where the card is driving the bus ?

hellmuth
-- 
Hellmuth Michaelis[EMAIL PROTECTED]   Hamburg, Europe
 We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Martin Husemann]

> But in the case of the teles16.3, it does _not_ use offsets 0x00-0x3b in
> the HSCX or ISAC: the ASIC on the card has 'folded' the address space so
> that the fifo appears at an address 3 bytes after the last register (0x3e
> with the current scheme - see tels0163_read_fifo()).

Ah, then the driver should map the region the correct way and access it 
without offsets.

This kind of stuff is why the NetBSD port uses an extra "offset" field in its
private map/region array, so it can map something offset from the expected 
range and map the generic register offsets to the mapped-region-offsets 
efficiently.


Martin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Andrew Gordon]

On Sun, 20 Feb 2000, Hellmuth Michaelis wrote:
> 
> A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
> chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
> the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.

But in the case of the teles16.3, it does _not_ use offsets 0x00-0x3b in
the HSCX or ISAC: the ASIC on the card has 'folded' the address space so
that the fifo appears at an address 3 bytes after the last register (0x3e
with the current scheme - see tels0163_read_fifo()).

The existing driver only uses offsets 0x20-0x3e relative to its assumed
base address (and offsets 0x40 upwards are mapped separately).

Note that the base address of 0x160 is a figment of the driver's
imagination: the card is labelled as occupying 0xd80, and hence occupies
0x180/0x580/0x980 due to ISA address decoding rules.  The 0x160 is only a
convenience to make the driver's address calculations the same as the
other cards - which is no longer necessary now that the driver has been
restructured to have sc->readreg/writereg and can do things differently
for each type of card.

> The card in question allocates 3 portranges for this uses with each 0x40
> bytes in length. 
> 
> In case there is is already an IDE controller allocated at 0x170 and a
> Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.
> 
> So where is the bug ?

There is definitely a bug that it doesn't seem to allocate a (larger)
portrange at 0xd80 - the output shown in an earlier message in this thread
suggested that only a single byte at 0xd80 was allocated.  The probe code
accesses 0xd80, 0xd81, 0xd82, and testing indicates that it goes up to at
least 0xd87, probably in fact all the way to 0xd1f.

I am 99% certain that it is also incorrect to protect 0x160-0x17f (etc.).
The driver certainly doesn't access registers in these ranges, and simple
testing suggests that the card doesn't drive the bus for these
regions.  Unfortunately, my only 16.3 card is in a machine that is in use,
so I can only do non-destructive testing on it.  I will be able to test it
properly in a couple of weeks when this machine has been retired. 

> This all looks perfectly reasonable to me with the exception that we
> could start argueing about whether it would be reasonable to split the
> allocation ranges for the ISAC and to save (if at all possible, there
> are some more registers at the end of the HSCX on the card) some bytes
> in the HSCX case.

This would be wrong - the driver needs to protect all the address space
occupied by the card, since it will be driving the bus for all these
addresses and so another (PnP) device must not be assigned addresses in
the "hole".



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Nikolai Saoukh]

> Depends. If the drivers allocation is coherent with the vendors description
> in the PnP configuration data, it's a newbus error (it shouldn't try to 
> allocate the card there in the first place). If the PnP info differs from
> the drivers view of the card, it's either the vendors fault for providing wrong
> infos (this wouldn't be the only card suffering) [fix: provide a quirk entry],
> or the drivers fault: it should obey what the vendor tells PnP about the
> card. Which case applies? Simple: if it's possible to change the driver to
> obey the cards infos, that should be done. If the driver couldn't be made
> to work support for that card should be removed :-)

Well,
current PnP code has own problems with parsing card data:

 * wrong calculation of memory range size (PR: kern/16712 with path).
   This bug will hit any card with io memory (ed driver for example).

 * inability to parse a little bit complicated config like in
   'IBM Auto 16/4 Token-Ring ISA Adapter' -- I am still fighting
   with this bug.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Hellmuth Michaelis]

>From the keyboard of Martin Husemann:

> > In case there is is already an IDE controller allocated at 0x170 and a
> > Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.
> 
> This is a PnP card, right?

No.

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Martin Husemann]

> In case there is is already an IDE controller allocated at 0x170 and a
> Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.

This is a PnP card, right? So what does the PnP info say about needed
memory ranges?

> So where is the bug ?

Depends. If the drivers allocation is coherent with the vendors description
in the PnP configuration data, it's a newbus error (it shouldn't try to 
allocate the card there in the first place). If the PnP info differs from
the drivers view of the card, it's either the vendors fault for providing wrong
infos (this wouldn't be the only card suffering) [fix: provide a quirk entry],
or the drivers fault: it should obey what the vendor tells PnP about the
card. Which case applies? Simple: if it's possible to change the driver to
obey the cards infos, that should be done. If the driver couldn't be made
to work support for that card should be removed :-)

If I'm wrong and this isn't a PnP card: it's pilot error. The card can't
work at the specified address, so everything works as expected. Paraphrased 
in a sentence often heard as a reply from technical support persons for a
big commercial OS vendor: "Status: This behaviour is by design."


Martin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Hellmuth Michaelis]

Brian Somers wrote:

> > So you are saying that what we really have here is a simple i/o conflict
> > and possibly the ISDN card can be reconfigured to use a non-conflicting
> > address? If so, then everything is working correctly and the resource
> > manager has pointed a possible hardware problem :-).
> 
> So it would seem, *but*, before moving from wd to ata I had both 
> working 100% reliably.  I had to move the Teles card to get it to 
> work (allocate resources successfully) once I changed to ata.
> 
> I would be pretty sure that the Teles S0/16.3 doesn't actually go 
> near the I/O range @ 0x170.

It depends. Assuming that the 16.3 allocates 0x40 bytes from 0x160 on,
it has 32 bytes r/w fifo from 0x160. This fifo may be accessed directly
at each location or indirectly in autoincrement mode. The isic driver
(IIRC) accesses it in autoincrement mode, this results in using only
the first byte for read/write of the fifo. This may be the reason why
it succeeds until now.

Anyhow - the fifo in non-autoincrement mode is _still_ there (it might
also be, that Teles does not decode the last 30 bytes of this range,
but i have no idea since the chance to get docs is nearly equal to zero)
how this behaves cannot be predicted for shure, so IMHO there is a
resource clash and the isic driver behaves correctly unless i overlooked
something.

hellmuth
-- 
Hellmuth Michaelis[EMAIL PROTECTED]   Hamburg, Europe
 We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Hellmuth Michaelis]

> > > > atapci0:  port 0xe000-0xe00f at device 7.1 on
> > > > pci0
> > > > ata0: at 0x1f0 irq 14 on atapci0
> > > > ata1: at 0x170 irq 15 on atapci0
> > > > ...
> > > > isic0: Error allocating io at 0x160 for Teles S0/16.3!
> > > > 
> > > > While I was able to use the Teles again by changing it's default IO port I
> > > > think there will be some people who will find it cumbersome to have to
> > > > change the IO on a card that was working fine before.
> > > > 
> > > > I feel this is a newbus issue with the ATA driver and/or maybe the i4b
> > > > driver doesn't really need that many IO ports so I'm sending this email to
> > > > both parties.
> > > 
> > > This is a bug in the isic driver. I'm sure it doesn't use every port in
> > > that range so it needs to split the range in to two or more pieces and
> > > only allocate ports which it actually needs.
> > 
> > How do you come to that conclusion ?
> > 
> > A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
> > chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
> > the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.
> > 
> > The card in question allocates 3 portranges for this uses with each 0x40
> > bytes in length. 
> > 
> > In case there is is already an IDE controller allocated at 0x170 and a
> > Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.
> > 
> > So where is the bug ?
> > 
> > This all looks perfectly reasonable to me with the exception that we could
> > start argueing about whether it would be reasonable to split the allocation
> > ranges for the ISAC and to save (if at all possible, there are some more
> > registers at the end of the HSCX on the card) some bytes in the HSCX case.
> 
> So you are saying that what we really have here is a simple i/o conflict
> and possibly the ISDN card can be reconfigured to use a non-conflicting
> address? 

Yes.

> If so, then everything is working correctly and the resource
> manager has pointed a possible hardware problem :-).

Exactly! :-)

hellmuth
-- 
Hellmuth Michaelis[EMAIL PROTECTED]   Hamburg, Europe
 We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Greedy Teles card was Re: Big ATA problems

[Jose Gabriel Marcelino]

> > So you are saying that what we really have here is a simple i/o conflict
> > and possibly the ISDN card can be reconfigured to use a non-conflicting
> > address? If so, then everything is working correctly and the resource
> > manager has pointed a possible hardware problem :-).
> 
> So it would seem, *but*, before moving from wd to ata I had both 
> working 100% reliably.  I had to move the Teles card to get it to 
> work (allocate resources successfully) once I changed to ata.
> 
> I would be pretty sure that the Teles S0/16.3 doesn't actually go 
> near the I/O range @ 0x170.

Yes, it also worked like that for quite some time in my FreeBSD box for
more than 2 years on the my company's old Linux internet gateway/small
server, with IDE disks and a network mounted CDrom running on the
secondary channel.. No problems whatsoever..

I understand this resource allocation assures perfect compliance with the
hardware specs and if so it should really be done this way, however I
think this will brake many Teles cards out there once people start
changing to FreeBSD 4.x so it should be at least documented, preferably
with the switch settings since the card is old and people tend to lose
the docs (I didn't have mine's so it took some trial and error to match
IO and switches.. some people will surely have problem with that)

Regards

Gabriel







To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Brian Somers]

> On Sun, 20 Feb 2000, Hellmuth Michaelis wrote:
> 
> > Doug Rabson wrote:
> > 
> > > > atapci0:  port 0xe000-0xe00f at device 7.1 on
> > > > pci0
> > > > ata0: at 0x1f0 irq 14 on atapci0
> > > > ata1: at 0x170 irq 15 on atapci0
> > > > ...
> > > > isic0: Error allocating io at 0x160 for Teles S0/16.3!
> > > > 
> > > > While I was able to use the Teles again by changing it's default IO port I
> > > > think there will be some people who will find it cumbersome to have to
> > > > change the IO on a card that was working fine before.
> > > > 
> > > > I feel this is a newbus issue with the ATA driver and/or maybe the i4b
> > > > driver doesn't really need that many IO ports so I'm sending this email to
> > > > both parties.
> > > 
> > > This is a bug in the isic driver. I'm sure it doesn't use every port in
> > > that range so it needs to split the range in to two or more pieces and
> > > only allocate ports which it actually needs.
> > 
> > How do you come to that conclusion ?
> > 
> > A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
> > chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
> > the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.
> > 
> > The card in question allocates 3 portranges for this uses with each 0x40
> > bytes in length. 
> > 
> > In case there is is already an IDE controller allocated at 0x170 and a
> > Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.
> > 
> > So where is the bug ?
> > 
> > This all looks perfectly reasonable to me with the exception that we could
> > start argueing about whether it would be reasonable to split the allocation
> > ranges for the ISAC and to save (if at all possible, there are some more
> > registers at the end of the HSCX on the card) some bytes in the HSCX case.
> 
> So you are saying that what we really have here is a simple i/o conflict
> and possibly the ISDN card can be reconfigured to use a non-conflicting
> address? If so, then everything is working correctly and the resource
> manager has pointed a possible hardware problem :-).

So it would seem, *but*, before moving from wd to ata I had both 
working 100% reliably.  I had to move the Teles card to get it to 
work (allocate resources successfully) once I changed to ata.

I would be pretty sure that the Teles S0/16.3 doesn't actually go 
near the I/O range @ 0x170.

> --
> Doug Rabson   Mail:  [EMAIL PROTECTED]
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Doug Rabson]

On Sun, 20 Feb 2000, Hellmuth Michaelis wrote:

> Doug Rabson wrote:
> 
> > > atapci0:  port 0xe000-0xe00f at device 7.1 on
> > > pci0
> > > ata0: at 0x1f0 irq 14 on atapci0
> > > ata1: at 0x170 irq 15 on atapci0
> > > ...
> > > isic0: Error allocating io at 0x160 for Teles S0/16.3!
> > > 
> > > While I was able to use the Teles again by changing it's default IO port I
> > > think there will be some people who will find it cumbersome to have to
> > > change the IO on a card that was working fine before.
> > > 
> > > I feel this is a newbus issue with the ATA driver and/or maybe the i4b
> > > driver doesn't really need that many IO ports so I'm sending this email to
> > > both parties.
> > 
> > This is a bug in the isic driver. I'm sure it doesn't use every port in
> > that range so it needs to split the range in to two or more pieces and
> > only allocate ports which it actually needs.
> 
> How do you come to that conclusion ?
> 
> A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
> chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
> the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.
> 
> The card in question allocates 3 portranges for this uses with each 0x40
> bytes in length. 
> 
> In case there is is already an IDE controller allocated at 0x170 and a
> Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.
> 
> So where is the bug ?
> 
> This all looks perfectly reasonable to me with the exception that we could
> start argueing about whether it would be reasonable to split the allocation
> ranges for the ISAC and to save (if at all possible, there are some more
> registers at the end of the HSCX on the card) some bytes in the HSCX case.

So you are saying that what we really have here is a simple i/o conflict
and possibly the ISDN card can be reconfigured to use a non-conflicting
address? If so, then everything is working correctly and the resource
manager has pointed a possible hardware problem :-).

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Hellmuth Michaelis]

Doug Rabson wrote:

> > atapci0:  port 0xe000-0xe00f at device 7.1 on
> > pci0
> > ata0: at 0x1f0 irq 14 on atapci0
> > ata1: at 0x170 irq 15 on atapci0
> > ...
> > isic0: Error allocating io at 0x160 for Teles S0/16.3!
> > 
> > While I was able to use the Teles again by changing it's default IO port I
> > think there will be some people who will find it cumbersome to have to
> > change the IO on a card that was working fine before.
> > 
> > I feel this is a newbus issue with the ATA driver and/or maybe the i4b
> > driver doesn't really need that many IO ports so I'm sending this email to
> > both parties.
> 
> This is a bug in the isic driver. I'm sure it doesn't use every port in
> that range so it needs to split the range in to two or more pieces and
> only allocate ports which it actually needs.

How do you come to that conclusion ?

A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC
chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b,
the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73.

The card in question allocates 3 portranges for this uses with each 0x40
bytes in length. 

In case there is is already an IDE controller allocated at 0x170 and a
Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so.

So where is the bug ?

This all looks perfectly reasonable to me with the exception that we could
start argueing about whether it would be reasonable to split the allocation
ranges for the ISAC and to save (if at all possible, there are some more
registers at the end of the HSCX on the card) some bytes in the HSCX case.

hellmuth
-- 
Hellmuth Michaelis[EMAIL PROTECTED]   Hamburg, Europe
 We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Hellmuth Michaelis]

Jose Gabriel Marcelino wrote:

> This obviously conflicts with the secondary IDE controller which lies at
> 0x170, however this has not been a problem till this day and no driver
> complained about this. Now, with the newer kernel I get this:
> 
> atapci0:  port 0xe000-0xe00f at device 7.1 on
> pci0
> ata0: at 0x1f0 irq 14 on atapci0
> ata1: at 0x170 irq 15 on atapci0
> ...
> isic0: Error allocating io at 0x160 for Teles S0/16.3!
> 
> While I was able to use the Teles again by changing it's default IO port I
> think there will be some people who will find it cumbersome to have to
> change the IO on a card that was working fine before.
> 
> I feel this is a newbus issue with the ATA driver and/or maybe the i4b
> driver doesn't really need that many IO ports so I'm sending this email to
> both parties.

This type of error with the 2nd IDE controller was reported also by other
people, mostly the reports were "working sometimes".

First of all, Teles refuses to give out any docs about their hardware, so
it might be that not all addresses are used but this is 100% speculation.

What you are recognizing is the real nice thing about newbus: you can't
allocate a resource twice. I admit, this might be a bit cumbersome in the
single case but it saves us from the "working sometimes" and "working
sometimes not" and "sometimes, very seldom and unreproducible" error
reports in the general case.

hellmuth
-- 
Hellmuth Michaelis[EMAIL PROTECTED]   Hamburg, Europe
 We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Doug Rabson]

On Sat, 19 Feb 2000, Jose Gabriel Marcelino wrote:

> atapci0:  port 0xe000-0xe00f at device 7.1 on
> pci0
> ata0: at 0x1f0 irq 14 on atapci0
> ata1: at 0x170 irq 15 on atapci0
> ...
> isic0: Error allocating io at 0x160 for Teles S0/16.3!
> 
> While I was able to use the Teles again by changing it's default IO port I
> think there will be some people who will find it cumbersome to have to
> change the IO on a card that was working fine before.
> 
> I feel this is a newbus issue with the ATA driver and/or maybe the i4b
> driver doesn't really need that many IO ports so I'm sending this email to
> both parties.

This is a bug in the isic driver. I'm sure it doesn't use every port in
that range so it needs to split the range in to two or more pieces and
only allocate ports which it actually needs.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Jose Gabriel Marcelino]

Hi again,

After remaking the loader (unnecessary since it's still broken), I've
removed my KLDs from loader.conf (I was loading a splash screen) and it
now boots as Bryan noticed.

However it seems another problem showed up, and I'm not sure where the
problem is.

I have a Teles ISDN card on this machine which was working very well
before this change using it's factory default IO configuration which
places it at 0xd80. It's driver however due to some hardware "features"
unknown to me says the following:

ata-pci0:  port 0xe000-0xe00f at device 7.1
on pci0
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
...
isic0 at port 0xd80,0x960-0x99f,0x160-0x19f,0x560-0x59f irq 10 flags 0x3
on isa0
isic0: Teles S0/16.3

This obviously conflicts with the secondary IDE controller which lies at
0x170, however this has not been a problem till this day and no driver
complained about this. Now, with the newer kernel I get this:

atapci0:  port 0xe000-0xe00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
...
isic0: Error allocating io at 0x160 for Teles S0/16.3!

While I was able to use the Teles again by changing it's default IO port I
think there will be some people who will find it cumbersome to have to
change the IO on a card that was working fine before.

I feel this is a newbus issue with the ATA driver and/or maybe the i4b
driver doesn't really need that many IO ports so I'm sending this email to
both parties.

Thanks again.

Regards,

Gabriel




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Soren Schmidt]

It seems Bryan Liesner wrote:
> On Sat, 19 Feb 2000, Soren Schmidt wrote:
> 
> >Have you rebuild your modules lately ??
> >
> >-Søren
> >
> Yes.  My world is current as of a few hours ago.  I did a make world 
> right after finding out about the loader problem to rule that
> possibility out.  The disk probes still fail when loading today's 
> modules with the loader.

Wierd, I'll try to investigate that here...

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Bryan Liesner]

On Sat, 19 Feb 2000, Soren Schmidt wrote:

>Have you rebuild your modules lately ??
>
>-Søren
>

Yes.  My world is current as of a few hours ago.  I did a make world 
right after finding out about the loader problem to rule that
possibility out.  The disk probes still fail when loading today's 
modules with the loader.

-Bryan





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Soren Schmidt]

It seems Bryan Liesner wrote:
> >Do you use KLMs?
> 
> Yes, I do! I was loading a screen saver with the boot loader. And
> now I see I am wrong about rebuilding the loader!  When I had success
> loading the kernel directly, I moved loading the screensaver into
> rc.conf instead.  Then I thought that something may be wrong with the
> loader, rebuilt it, and booted successfully.
> 
> I broke the rule - never change more than one thing at a time :)
> 
> I put the screen saver back in loader.conf and the boot failed again,
> so it is a loader/kernel issue, but I didn't have to rebuild loader.

Have you rebuild your modules lately ??

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Bryan Liesner]

On Sat, 19 Feb 2000, Philipp Mergenthaler wrote:

>On Sat, Feb 19, 2000 at 10:39:42AM -0500, Bryan Liesner wrote:
>> Jose, the problem seems to be resolved by rebuilding the boot
>> loader.  Or bypass the loader altogether. 
>> 
>> cd /usr/src/sys/boot
>> make obj
>> make all install
>> 
>> and you'll be able to boot the kernel with the latest ata stuff. 
>
>Do you use KLMs?

Yes, I do! I was loading a screen saver with the boot loader. And
now I see I am wrong about rebuilding the loader!  When I had success
loading the kernel directly, I moved loading the screensaver into
rc.conf instead.  Then I thought that something may be wrong with the
loader, rebuilt it, and booted successfully.

I broke the rule - never change more than one thing at a time :)

I put the screen saver back in loader.conf and the boot failed again,
so it is a loader/kernel issue, but I didn't have to rebuild loader.


-Bryan




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Philipp Mergenthaler]

On Sat, Feb 19, 2000 at 10:39:42AM -0500, Bryan Liesner wrote:
> Jose, the problem seems to be resolved by rebuilding the boot
> loader.  Or bypass the loader altogether. 
> 
> cd /usr/src/sys/boot
> make obj
> make all install
> 
> and you'll be able to boot the kernel with the latest ata stuff. 

Do you use KLMs?

When I load the kernel alone, it detects the ATA devices normally.
When I let the loader load a module in addition to the kernel
(I tried it with each of vinum, netgraph, linux, splash_bmp and joy),
it fails with these messages:
ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY
ata0-slave: ata_command: timeout waiting for intr
ata0-slave: identify failed

(The primary slave is a CDROM.)

This was with linux.ko; with joy.ko, the line "WARNING:..." wasn't
printed. (BTW, with kernel+umap.ko, the ATA detection succeeded.)

Every access to an ATA device then fails like this:
# fdisk ad0
fdisk: cannot open disk /dev/rad0: Device not configured
# ls -l *ad0
crw-r-  1 root  operator  116, 0x00010002 Feb 19 17:03 ad0
crw-r-  1 root  operator  116, 0x00010002 Feb 19 17:03 rad0

This is with an updated /boot/loader and the "lun=2" patch applied.

Bye, Philipp

P.S.: Here's a diff between a successful and an unsuccessful verbose boot:

~%diff -1000 -u /var/tmp/dmesgv_ok /var/tmp/dmesgv_fail
--- /var/tmp/dmesgv_ok  Sat Feb 19 18:55:55 2000
+++ /var/tmp/dmesgv_failSat Feb 19 19:51:41 2000
@@ -1,247 +1,205 @@
 Copyright (c) 1992-2000 The FreeBSD Project.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
 FreeBSD 4.0-CURRENT #145: Sat Feb 19 18:13:37 CET 2000
 [EMAIL PROTECTED]:/usr/src/sys/compile/I609
-Calibrating clock(s) ... TSC clock: 233862696 Hz, i8254 clock: 1193178 Hz
+Calibrating clock(s) ... TSC clock: 233862171 Hz, i8254 clock: 1193176 Hz
 CLK_USE_I8254_CALIBRATION not specified - using default frequency
 Timecounter "i8254"  frequency 1193182 Hz
 CLK_USE_TSC_CALIBRATION not specified - using old calibration method
-Timecounter "TSC"  frequency 233864747 Hz
-CPU: AMD-K6tm w/ multimedia extensions (233.86-MHz 586-class CPU)
+Timecounter "TSC"  frequency 233865033 Hz
+CPU: AMD-K6tm w/ multimedia extensions (233.87-MHz 586-class CPU)
   Origin = "AuthenticAMD"  Id = 0x562  Stepping = 2
   Features=0x8001bf
   AMD Features=0x400<>
 Data TLB: 128 entries, 2-way associative
 Instruction TLB: 64 entries, 1-way associative
 L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative
 L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative
 Write Allocate Enable Limit: 96M bytes
 Write Allocate 15-16M bytes: Enable
 Hardware Write Allocate Control: Disable
 real memory  = 100663296 (98304K bytes)
 Physical memory chunk(s):
 0x1000 - 0x0009efff, 647168 bytes (158 pages)
-0x0033f000 - 0x05ff5fff, 97218560 bytes (23735 pages)
-avail memory = 94158848 (91952K bytes)
+0x00353000 - 0x05ff5fff, 97136640 bytes (23715 pages)
+avail memory = 94076928 (91872K bytes)
 bios32: Found BIOS32 Service Directory header at 0xc00f9a20
 bios32: Entry = 0xf04e0 (c00f04e0)  Rev = 0  Len = 1
 pcibios: PCI BIOS entry at 0x510
 pnpbios: Found PnP BIOS data at 0xc00fcf10
 pnpbios: Entry = f:cf40  Rev = 1.0
 pnpbios: OEM ID cd041
 Other BIOS signatures found:
 ACPI: 
-Preloaded elf kernel "kernel" at 0xc0326000.
+Preloaded elf kernel "kernel" at 0xc033a000.
+Preloaded elf module "linux.ko" at 0xc033a09c.
 module_register_init: MOD_LOAD (vesa, c0240a78, 0) error 6
 md0: Malloc disk
 Creating DISK md0
 pci_open(1):   mode 1 addr port (0x0cf8) is 0x805c
 pci_open(1a):  mode1res=0x8000 (0x8000)
 pci_cfgcheck:  device 0 [class=06] [hdr=00] is there (id=71008086)
 npx0:  on motherboard
 npx0: INT 16 interface
-i586_bzero() bandwidth = 43677658 bytes/sec
-bzero() bandwidth = 46259888 bytes/sec
+i586_bzero() bandwidth = 43664308 bytes/sec
+bzero() bandwidth = 46249190 bytes/sec
 pci_open(1):   mode 1 addr port (0x0cf8) is 0x
 pci_open(1a):  mode1res=0x8000 (0x8000)
 pci_cfgcheck:  device 0 [class=06] [hdr=00] is there (id=71008086)
 pcib0:  on motherboard
 found->vendor=0x8086, dev=0x7100, revid=0x01
class=06-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
 found->vendor=0x8086, dev=0x7110, revid=0x01
class=06-01-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
 found->vendor=0x8086, dev=0x7111, revid=0x01
class=01-01-80, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[20]: type 1, range 32, base e000, size  4
 found->vendor=0x8086, dev=0x7112, revid=0x01
class=0c-03-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=d, irq=255
map[20]: type 1, range 32, base d800, size  5
 found->vendor=0x8086, dev=0x7113, revid=0x01
class=06-80-00, hdrtype=0x00, mfdev

Re: Big ATA problems

[Bryan Liesner]

On Sat, 19 Feb 2000, Jose Gabriel Marcelino wrote:

>
>hi Soren,
>
>The latest ata commits left me unbootable too, the patch you provided
>below didn't help this too. I have a very different configuration from
>Bryan's (much simpler too):
>

Jose, the problem seems to be resolved by rebuilding the boot
loader.  Or bypass the loader altogether. 

cd /usr/src/sys/boot
make obj
make all install

and you'll be able to boot the kernel with the latest ata stuff. 


Bryan





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Soren Schmidt]

It seems Jose Gabriel Marcelino wrote:

Well, rebuild the loader, that helped Bryan, apparently it has 
nothing to do with the ata driver

> The latest ata commits left me unbootable too, the patch you provided
> below didn't help this too. I have a very different configuration from
> Bryan's (much simpler too):
> 
> - DFI K6XV3+ mb with VIA MVP3 chipset 
> ata-pci0:  port 0xe000-0xe00f at device 7.1
> on pci0
> ata0 at 0x01f0 irq 14 on ata-pci0
> ata1 at 0x0170 irq 15 on ata-pci0
> ...
> ad0: 14664MB  [31781/15/63] at ata0-master using UDMA33
> ad1: 4103MB  [8894/15/63] at ata0-slave using UDMA33
> acd0: DVD-ROM  at ata1-master using UDMA33
> afd0: 96MB  [96/64/32] at ata1-slave using PIO0
 

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Jose Gabriel Marcelino]

hi Soren,

The latest ata commits left me unbootable too, the patch you provided
below didn't help this too. I have a very different configuration from
Bryan's (much simpler too):

- DFI K6XV3+ mb with VIA MVP3 chipset 
ata-pci0:  port 0xe000-0xe00f at device 7.1
on pci0
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
...
ad0: 14664MB  [31781/15/63] at ata0-master using UDMA33
ad1: 4103MB  [8894/15/63] at ata0-slave using UDMA33
acd0: DVD-ROM  at ata1-master using UDMA33
afd0: 96MB  [96/64/32] at ata1-slave using PIO0

With the latest kernel I get this relevant messages:

atapci0:  port 0xe000-0xe00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
...
ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY
ata0-slave: ata_command: timeout waiting for intr
ata0-slave: identify failed
nodevsw (majdev=0 bootdev=0xa020)
Mouting root from ufs:/dev/wd0s1a
no such device 'wd'


Thinking that the wd device was gone I tried using /dev/ad0s1a, but it was
the same: no such device 'ad'

Thanks,

Gabriel

> > >> The latest ata commits left my system completely unbootable.  No disks
> > >> were probed.
> > >

> Index: ata-all.c
> ===
> RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
> retrieving revision 1.48
> diff -u -r1.48 ata-all.c
> --- ata-all.c   2000/02/18 20:57:27 1.48
> +++ ata-all.c   2000/02/19 13:58:58
> @@ -336,7 +336,7 @@
>  if (pci_get_progif(dev) & PCIP_STORAGE_IDE_MASTERDEV)
> lun = unit;
>  else
> -   lun = -1;
> +   lun = 2;
>  
>  if (!(child = device_add_child(dev, "ata", lun)))
> return ENOMEM;
> 
> -Søren
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Soren Schmidt]

It seems Bryan Liesner wrote:
> On Sat, 19 Feb 2000, Soren Schmidt wrote:
> 
> >It seems Bryan Liesner wrote:
> >> 
> >> The latest ata commits left my system completely unbootable.  No disks
> >> were probed.
> >
> >He, you always seem to be lucky when I change something :)
> 
> I always hold my breath when I cvsup and see changes to ata*:)
> 
> 
> >Hmm, yes you have one of those motherboards that screw the order 
> >of the controllers, it is an ASUS aliddin right ??

For those that has this problem, this patch should do the trick:

Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.48
diff -u -r1.48 ata-all.c
--- ata-all.c   2000/02/18 20:57:27 1.48
+++ ata-all.c   2000/02/19 13:58:58
@@ -336,7 +336,7 @@
 if (pci_get_progif(dev) & PCIP_STORAGE_IDE_MASTERDEV)
lun = unit;
 else
-   lun = -1;
+   lun = 2;
 
 if (!(child = device_add_child(dev, "ata", lun)))
return ENOMEM;

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Bryan Liesner]

On Sat, 19 Feb 2000, Soren Schmidt wrote:

>It seems Bryan Liesner wrote:
>> 
>> The latest ata commits left my system completely unbootable.  No disks
>> were probed.
>
>He, you always seem to be lucky when I change something :)

I always hold my breath when I cvsup and see changes to ata*:)


>Hmm, yes you have one of those motherboards that screw the order 
>of the controllers, it is an ASUS aliddin right ??

It's a PCChips motherboard...

>
>You could try to not use the ATA_STATIC_ID option, that way your
>disks should be numbered 0 and 1 and at least make it boot...

Never used that option before.

-Bryan



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Big ATA problems

[Soren Schmidt]

It seems Bryan Liesner wrote:
> 
> The latest ata commits left my system completely unbootable.  No disks
> were probed.

He, you always seem to be lucky when I change something :)

> I have on the motherboard's Alladin controller:
> HP 4x4x24 CD burner as master primary channel
> 40x CD as slave primary channel
> HP Colorado 8 Gig ATAPI tape as master secondary channel
> 
> On a Promise Ultra66:
> WDC AC29100D 
> WDC AC32500H 
> each on thier own channel. 
>  
> Here are the boot messages (I had to write them down)
> ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY
> ata0-slave: timeout waiting for intr
> ata0-slave: identify failed

That doesnt't make sense from the new stuffs angle...

> these were repeated once
> 
> and when attempting to mount /
> no devsw(msgdev=0 bootdev=0xa20)
> no such device 'ad'
> 
> Prior the the commit, the motherboard ide controllers were numbered
> ata0,1 and the Promise was ata2,3.
> 
> After the commit it is switched around.  Now the controllers probe as
> Promise ata0,1 and the motherboard as ata2,3.

Hmm, yes you have one of those motherboards that screw the order 
of the controllers, it is an ASUS aliddin right ??

You could try to not use the ATA_STATIC_ID option, that way your
disks should be numbered 0 and 1 and at least make it boot...

I'll try to get this resolved in the meantime, I guess Rabson didn't
think about this one, and neither did I for that matter...

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message