[BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

Hello,

On kernel 2.6.20-rc1, ftp (get or put) stops
during file-transfer.

Client: ftp-0.17-33.fc6  (192.168.1.1)
Server: vsftpd-2.0.5-8   (192.168.1.3)

This problem does _not_ happen on kernel-2.6.19.
is it caused by network-subsystem change on 2.6.20-rc1??


Best Regards
Komuro

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Al Viro]

On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> 
> Hello,
> 
> On kernel 2.6.20-rc1, ftp (get or put) stops
> during file-transfer.
> 
> Client: ftp-0.17-33.fc6  (192.168.1.1)
> Server: vsftpd-2.0.5-8   (192.168.1.3)
> 
> This problem does _not_ happen on kernel-2.6.19.
> is it caused by network-subsystem change on 2.6.20-rc1??

Do you have NAT between you and server?

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

On Sun, 17 Dec 2006 04:02:22 +0000
Al Viro <viro@ftp.linux.org.uk> wrote:

> On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> > 
> > Hello,
> > 
> > On kernel 2.6.20-rc1, ftp (get or put) stops
> > during file-transfer.
> > 
> > Client: ftp-0.17-33.fc6  (192.168.1.1)
> > Server: vsftpd-2.0.5-8   (192.168.1.3)
> > 
> > This problem does _not_ happen on kernel-2.6.19.
> > is it caused by network-subsystem change on 2.6.20-rc1??
> 
> Do you have NAT between you and server?

No. I don't have NAT between the client and the server.
Actually, the client and the sever is located in same room.


client -- 100MbpsHub -- server.

Thanks!

Best Regards
Komuro

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Adrian Bunk]

On Sun, Dec 17, 2006 at 11:23:11PM +0900, Komuro wrote:
> On Sun, 17 Dec 2006 04:02:22 +0000
> Al Viro <viro@ftp.linux.org.uk> wrote:
> 
> > On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> > > 
> > > Hello,
> > > 
> > > On kernel 2.6.20-rc1, ftp (get or put) stops
> > > during file-transfer.
> > > 
> > > Client: ftp-0.17-33.fc6  (192.168.1.1)
> > > Server: vsftpd-2.0.5-8   (192.168.1.3)
> > > 
> > > This problem does _not_ happen on kernel-2.6.19.
> > > is it caused by network-subsystem change on 2.6.20-rc1??
> > 
> > Do you have NAT between you and server?
> 
> No. I don't have NAT between the client and the server.
> Actually, the client and the sever is located in same room.
> 
> client -- 100MbpsHub -- server.

What network cards are in the client and the server?

Are there any error messages your client gives or in the log files?

> Thanks!
> 
> Best Regards
> Komuro

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

> 
> What network cards are in the client and the server?

DL10022-based pcmcia network card(both client and server)
The driver name is pcnet_cs.
 
> Are there any error messages your client gives or in the log files?

no error messages.

I capture the packet of ftp transfer by ethereal.
I found the malformed packet when it stops.

I will investigate it further.

Thanks!

Best Regards
Komuro

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

> > On kernel 2.6.20-rc1, ftp (get or put) stops
> > during file-transfer.
> > 
> > Client: ftp-0.17-33.fc6  (192.168.1.1)
> > Server: vsftpd-2.0.5-8   (192.168.1.3)
> > 

This problem happens on kernel-2.6.19-git4 or later.
but does _not_ happen on kernel-2.6.19-git3.

So this problem is introduced to kernel-2.6.19-git4.


I tried the Marvell 88E8001(skge) and Realtek 8139(8139too),
the same problem happens.

I think this is not a network-card-driver problem.

Thanks!
 
Best Regards
Komuro
 

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

Hi,

I investigated the ftp-file-transfer-stop problem by git-bisect method,
and found this problem was introduced by
"[TCP]: MD5 Signature Option (RFC2385) support" patch.

Mr.YOSHIFUJI san, please fix this problem.

>commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
>Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>Date:   Tue Nov 14 19:07:45 2006 -0800
>
>    [TCP]: MD5 Signature Option (RFC2385) support.
>    
>    Based on implementation by Rick Payne.
>    
>    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>

Best Regards
Komuro


> On Sun, Dec 17, 2006 at 11:23:11PM +0900, Komuro wrote:
> > On Sun, 17 Dec 2006 04:02:22 +0000
> > Al Viro <viro@ftp.linux.org.uk> wrote:
> > 
> > > On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > On kernel 2.6.20-rc1, ftp (get or put) stops
> > > > during file-transfer.
> > > > 
> > > > Client: ftp-0.17-33.fc6  (192.168.1.1)
> > > > Server: vsftpd-2.0.5-8   (192.168.1.3)
> > > > 
> > > > This problem does _not_ happen on kernel-2.6.19.
> > > > is it caused by network-subsystem change on 2.6.20-rc1??
> > > 
> > > Do you have NAT between you and server?
> > 
> > No. I don't have NAT between the client and the server.
> > Actually, the client and the sever is located in same room.
> > 
> > client -- 100MbpsHub -- server.

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20061230185043.d31d2104.komurojun-mbn@nifty.com> (at Sat, 30 Dec 2006 18:50:43 +0900), Komuro <komurojun-mbn@nifty.com> says:

> I investigated the ftp-file-transfer-stop problem by git-bisect method,
> and found this problem was introduced by
> "[TCP]: MD5 Signature Option (RFC2385) support" patch.
> 
> Mr.YOSHIFUJI san, please fix this problem.

Hmm, have you try disabling CONFIG_TCP_MD5SIG?
(Is it already disabled?)

Are there any specific size of transfer to reproduce this?
Do you see similar issue with other simple application?

--yoshfuji

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

> 
> > I investigated the ftp-file-transfer-stop problem by git-bisect method,
> > and found this problem was introduced by
> > "[TCP]: MD5 Signature Option (RFC2385) support" patch.
> > 
> > Mr.YOSHIFUJI san, please fix this problem.
> 
> Hmm, have you try disabling CONFIG_TCP_MD5SIG?
> (Is it already disabled?)

This problem happens both CONFIG_TCP_MD5SIG is disabled and enabled.

> Are there any specific size of transfer to reproduce this?

When I do ftp 40Mbytes file for 5-times or more,
 this problem happens.


> Do you see similar issue with other simple application?

sorry, I don't reproduce this problem on other application.

Thanks,

Best Regards
Komuro.

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20061230205931.9e430173.komurojun-mbn@nifty.com> (at Sat, 30 Dec 2006 20:59:31 +0900), Komuro <komurojun-mbn@nifty.com> says:

> > Do you see similar issue with other simple application?
> 
> sorry, I don't reproduce this problem on other application.

Can you reproduce it with other ftp client and/or server?


Anyway...

Please provide the output of "netstat -na" command during the
transfer, and the output of "lsmod | grep conntrack" (just for
sure).


More questions:

What kind of mode do you use? e.g. PORT/EPRT/LPRT/PASV/EPSV/LPSV

When the transfer get stuck, are other communication still working?

Are there any workaround?
e.g. stop-start vsftpd cycle, ifdown-ifup cycle, rmmod/insmod cycle etc.


Regards,

--yoshfuji

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

> Can you reproduce it with other ftp client and/or server?
 
O.K. I wiil try to test other ftp client and server.
 

> Please provide the output of "netstat -na" command during the
> transfer, and the output of "lsmod | grep conntrack" (just for
> sure).

Please see the output of "netstat -na" when stuck. (below)

CONFIG_NETFILER is diabled in my test configuration
,conntrack modules is not loaded.
(CONFIG_IP_DCCP, CONFIG_IP_SCTP, CONFIG_TIPC, CONFIG_IPV6 is
also disabled) 

 
> What kind of mode do you use? e.g. PORT/EPRT/LPRT/PASV/EPSV/LPSV

PASV mode.
 
> When the transfer get stuck, are other communication still working?

Other communication works properly.
Actually, I can start other ftp session on other console of the same PC.

> Are there any workaround?
> e.g. stop-start vsftpd cycle, ifdown-ifup cycle, rmmod/insmod cycle etc.

I only need to do the killall command.


>> output of netstat -na

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
tcp        0      0 0.0.0.0:873                 0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      
tcp        0      0 192.168.0.6:35737           192.168.0.2:26827           TIME_WAIT   
tcp        0      0 192.168.0.6:51036           192.168.0.2:21              ESTABLISHED 
udp        0      0 0.0.0.0:68                  0.0.0.0:*                               
udp        0      0 0.0.0.0:867                 0.0.0.0:*                               
udp        0      0 0.0.0.0:870                 0.0.0.0:*                               
udp        0      0 0.0.0.0:111                 0.0.0.0:*                               
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     STREAM     LISTENING     5056   /tmp/.font-unix/fs7100
unix  2      [ ]         DGRAM                    1234   @/org/kernel/udev/udevd
unix  5      [ ]         DGRAM                    4748   /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     4917   /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     4989   /var/run/acpid.socket
unix  2      [ ]         DGRAM                    5390   
unix  3      [ ]         STREAM     CONNECTED     4920   
unix  3      [ ]         STREAM     CONNECTED     4919   
unix  2      [ ]         DGRAM                    4866   
unix  2      [ ]         DGRAM                    4756   



Thanks,

Best Regards
Komuro

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

> 
> Can you reproduce it with other ftp client and/or server?

I tried the proftpd-1.3.0a-1.fc6(kernel version is 2.6.19).
The ftp stop problem does not happen.

Therefore, this problem is reproduced when
client's kernel-version is 2.6.20-rc1 or later
and server is vsftpd.
Server's kernel-version is not related with this problem.

The ftp-stop-problem happens on client's PC.

Please advise.

Best Regards
Komuro



 

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

Hi,

I made a patch below.
With this patch, the ftp-transfer-stop problem does not happen.
Therefore, I think this is not a problem of vsftpd.

Mr.YOSHIFUJI san, why did you set TCPOLEN_TSTAMP_ALIGNED
to iov_len?



--- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig	2007-01-03 11:50:04.000000000 +0900
+++ linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c	2007-01-03 15:30:44.000000000 +0900
@@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_t
 				   TCPOLEN_TIMESTAMP);
 		rep.opt[1] = htonl(tcp_time_stamp);
 		rep.opt[2] = htonl(ts);
-		arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED;
+		arg.iov[0].iov_len = sizeof(rep);
 	}
 
 	/* Swap the send and the receive. */


Best Regards
Komuro

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Craig Schlenter]

On Fri, Jan 05, 2007 at 05:45:46AM +0900, Komuro wrote:
> Hi,
> 
> I made a patch below.
> With this patch, the ftp-transfer-stop problem does not happen.
> Therefore, I think this is not a problem of vsftpd.
> 
> Mr.YOSHIFUJI san, why did you set TCPOLEN_TSTAMP_ALIGNED
> to iov_len?
> 
> 
> 
> --- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig	2007-01-03 11:50:04.000000000 +0900
> +++ linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c	2007-01-03 15:30:44.000000000 +0900
> @@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_t
>  				   TCPOLEN_TIMESTAMP);
>  		rep.opt[1] = htonl(tcp_time_stamp);
>  		rep.opt[2] = htonl(ts);
> -		arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED;
> +		arg.iov[0].iov_len = sizeof(rep);

Perhaps this was supposed to be
                arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED;

That's what the ipv6 stuff does in places.

bye,

--Craig

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20070104122330.GA2233@craigdell.detnet.com> (at Thu, 4 Jan 2007 14:23:30 +0200), Craig Schlenter <craig@codefountain.com> says:

> On Fri, Jan 05, 2007 at 05:45:46AM +0900, Komuro wrote:
> > Hi,
> > 
> > I made a patch below.
> > With this patch, the ftp-transfer-stop problem does not happen.
> > Therefore, I think this is not a problem of vsftpd.
> > 
> > Mr.YOSHIFUJI san, why did you set TCPOLEN_TSTAMP_ALIGNED
> > to iov_len?
> > 
> > 
> > 
> > --- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig	2007-01-03 11:50:04.000000000 +0900
> > +++ linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c	2007-01-03 15:30:44.000000000 +0900
> > @@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_t
> >  				   TCPOLEN_TIMESTAMP);
> >  		rep.opt[1] = htonl(tcp_time_stamp);
> >  		rep.opt[2] = htonl(ts);
> > -		arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED;
> > +		arg.iov[0].iov_len = sizeof(rep);
> 
> Perhaps this was supposed to be
>                 arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED;
> 
> That's what the ipv6 stuff does in places.

Good catch! I agree.
Craig, please provide a patch for us, please.

Thank you again.

--yoshfuji

[PATCH] Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Craig Schlenter]

Hi Dave

YOSHIFUJI Hideaki / 吉藤英明 has suggested that I send the patch
below to fix the ftp stalls present in the current kernels.

All credit goes to Komuro <komurojun-mbn@nifty.com> for tracking
this down. The patch is untested but it looks *cough* obviously
correct.

Signed-off-by: Craig Schlenter <craig@codefountain.com>

Thank you!

--Craig

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index bf7a224..12de90a 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_timewait_sock *twsk,
 				   TCPOLEN_TIMESTAMP);
 		rep.opt[1] = htonl(tcp_time_stamp);
 		rep.opt[2] = htonl(ts);
-		arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED;
+		arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED;
 	}
 
 	/* Swap the send and the receive. */

Re: [PATCH] Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[YOSHIFUJI Hideaki / 吉藤英明]

[-- Attachment #1: Type: Text/Plain, Size: 438 bytes --]

Dave, please apply.  Thank you.

In article <20070109051139.GA2229@craigdell.detnet.com> (at Tue, 9 Jan 2007 07:11:39 +0200), Craig Schlenter <craig@codefountain.com> says:

> All credit goes to Komuro <komurojun-mbn@nifty.com> for tracking
> this down. The patch is untested but it looks *cough* obviously
> correct.
> 
> Signed-off-by: Craig Schlenter <craig@codefountain.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

[-- Attachment #2: Type: Message/Rfc822, Size: 3419 bytes --]

From: Craig Schlenter <craig@codefountain.com>
To: "YOSHIFUJI Hideaki / 吉藤英明" <yoshfuji@linux-ipv6.org>, davem@davemloft.net
Cc: komurojun-mbn@nifty.com, bunk@stusta.de, jgarzik@pobox.com, viro@ftp.linux.org.uk, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCH] Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
Date: Tue, 9 Jan 2007 07:11:39 +0200
Message-ID: <20070109051139.GA2229@craigdell.detnet.com>

Hi Dave

YOSHIFUJI Hideaki / 吉藤英明 has suggested that I send the patch
below to fix the ftp stalls present in the current kernels.

All credit goes to Komuro <komurojun-mbn@nifty.com> for tracking
this down. The patch is untested but it looks *cough* obviously
correct.

Signed-off-by: Craig Schlenter <craig@codefountain.com>

Thank you!

--Craig

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index bf7a224..12de90a 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_timewait_sock *twsk,
 				   TCPOLEN_TIMESTAMP);
 		rep.opt[1] = htonl(tcp_time_stamp);
 		rep.opt[2] = htonl(ts);
-		arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED;
+		arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED;
 	}
 
 	/* Swap the send and the receive. */

Re: [PATCH] Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[David Miller]

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 09 Jan 2007 14:22:44 +0900 (JST)

> Dave, please apply.  Thank you.
> 
> In article <20070109051139.GA2229@craigdell.detnet.com> (at Tue, 9 Jan 2007 07:11:39 +0200), Craig Schlenter <craig@codefountain.com> says:
> 
> > All credit goes to Komuro <komurojun-mbn@nifty.com> for tracking
> > this down. The patch is untested but it looks *cough* obviously
> > correct.
> > 
> > Signed-off-by: Craig Schlenter <craig@codefountain.com>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Applied, thanks everyone.

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

On Thu, 4 Jan 2007 14:23:30 +0200
Craig Schlenter <craig@codefountain.com> wrote:


> > --- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig	2007-01-03 11:50:04.000000000 +0900
> > +++ linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c	2007-01-03 15:30:44.000000000 +0900
> > @@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_t
> >  				   TCPOLEN_TIMESTAMP);
> >  		rep.opt[1] = htonl(tcp_time_stamp);
> >  		rep.opt[2] = htonl(ts);
> > -		arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED;
> > +		arg.iov[0].iov_len = sizeof(rep);
> 
> Perhaps this was supposed to be
>                 arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED;
> 
> That's what the ipv6 stuff does in places.

It works properly.
Thanks!


Best Regards
Komuro

Re: [BUG] PATA_PCMCIA does not work

[Alan]

> The PATA_PCMCIA driver does not work.
> The kernel version is 2.6.20.
> Does anyone test this driver?

Yes it gets regularly tested and works reliably on my test harware. I am
however using standards compliant hardware.

> [pata_pcmcia dmesg]
> ata1.00: CFA, max PIO0, 20480 sectors: LBA 
> ata1.00: ata1: dev 0 multi count 0
> ata1.01: CFA, max PIO0, 20480 sectors: LBA 
> ata1.01: ata1: dev 1 multi count 0

Do you have two cards here ?

> ata1.00: failed to set xfermode (err_mask=0x1)

This looks like you have both a CF adapter which does not properly handle
drive select, and a CFA card which incorrectly only allows a set
features/xfer mode to be done once.

The old IDE layer has a workaround to try and detect the former bug
(which sadly looks like it will be needed in libata), and through sheer
ignorance happens not to break in the second case.

Your card should work with the current -mm driver although not entirely
for the right reasons. Given you have such a marvellously buggy set of
hardware can I send you some test patches to try ?

Alan

Re: [BUG] PATA_PCMCIA does not work

[Haavard Skinnemoen]

On 2/11/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > [pata_pcmcia dmesg]
> > ata1.00: CFA, max PIO0, 20480 sectors: LBA
> > ata1.00: ata1: dev 0 multi count 0
> > ata1.01: CFA, max PIO0, 20480 sectors: LBA
> > ata1.01: ata1: dev 1 multi count 0
>
> Do you have two cards here ?

I've seen this as well, on an ancient 4MB card. I'm pretty sure the
-CSEL signal on my test board is incorrectly routed, so I thought it
was because of that. I'll try to strap it tomorrow and see if it
really is the cause of the problem.

> Your card should work with the current -mm driver although not entirely
> for the right reasons. Given you have such a marvellously buggy set of
> hardware can I send you some test patches to try ?

In my current pile of four CF cards, it looks like three of them are
buggy, although in slightly different ways. I'd be happy to test a few
patches.

Haavard

Re: [BUG] PATA_PCMCIA does not work

[Komuro]

>> [pata_pcmcia dmesg]
>> ata1.00: CFA, max PIO0, 20480 sectors: LBA 
>> ata1.00: ata1: dev 0 multi count 0
>> ata1.01: CFA, max PIO0, 20480 sectors: LBA 
>> ata1.01: ata1: dev 1 multi count 0

>Do you have two cards here ?

No. one card.
I am not sure why two devices are detected.


Actually, this card works properly with ide-cs driver.
but it displays some warning message.


hde: SunDisk SDP5-10, CFA DISK drive
hdf: SunDisk SDP5-10, CFA DISK drive
ide-probe: ignoring undecoded slave
ide2 at 0xd100-0xd107,0xd10e on irq 3
hde: max request size: 128KiB
hde: 20480 sectors (10 MB) w/1KiB Cache, CHS=320/2/32
 hde:hde: set_geometry_intr: status=0x51 { DriveReady SeekComplete Error }
hde: set_geometry_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
 hde1
ide-cs: hde: Vpp = 0.0


Best Regards
Komuro

Re: [BUG] PATA_PCMCIA does not work

[Komuro]

Hi,

I tried the kernel 2.6.20-git14,
the pata_pcmcia drive works properly.Thanks!

But I do the "pccardctl eject"
NULL-pointer-dereference error happens.


[dmesg]
pcmcia: registering new device pcmcia1.0
SCSI subsystem initialized
libata version 2.10 loaded.
ata1: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x00000000 irq 3
scsi0 : pata_pcmcia
ata1.00: CFA: Hitachi XXM2.3.0, Rev 3.00, max PIO1
ata1.00: 62592 sectors, multi 0: LBA 
ata1.00: configured for PIO0
scsi 0:0:0:0: Direct-Access     ATA      Hitachi XXM2.3.0 Rev  PQ: 0 ANSI: 5
scsi 0:0:0:0: Attached scsi generic sg0 type 0
SCSI device sda: 62592 512-byte hdwr sectors (32 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 62592 512-byte hdwr sectors (32 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
pccard: card ejected from slot 1
ata1.00: disabled
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000020
 printing eip:
d89f7f3e
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: nls_ascii vfat fat sd_mod sg pata_pcmcia libata scsi_mod dm_mirror dm_multipath dm_mod pcmcia yenta_socket rsrc_nonstatic pcmcia_core
CPU:    0
EIP:    0060:[<d89f7f3e>]    Not tainted VLI
EFLAGS: 00010246   (2.6.20-git14 #1)
EIP is at ata_host_release+0x2e/0x48 [libata]
eax: d7981884   ebx: d545b8c0   ecx: d7f6f180   edx: d545b8cc
esi: 00000000   edi: 00000000   ebp: 00000000   esp: d5bfde58
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process pccardctl (pid: 1711, ti=d5bfc000 task=c13d1540 task.ti=d5bfc000)
Stack: d545b8c0 d5ac4700 d7981a24 c0220120 d7981a24 d7981884 00000006 d5ac4720 
       d5ac4660 d7981884 d887c278 d71c8dbc d7c53c48 c02201e9 00000286 d7981884 
       c021d363 d7981884 d7981884 c021d7ae d798192c c021cd84 d7981884 d7981884 
Call Trace:
 [<c0220120>] release_nodes+0x10f/0x12f
 [<c02201e9>] devres_release_all+0x27/0x2a
 [<c021d363>] __device_release_driver+0x78/0x8e
 [<c021d7ae>] device_release_driver+0x31/0x46
 [<c021cd84>] bus_remove_device+0x6d/0x7d
 [<c021b58a>] device_del+0x162/0x1bf
 [<c021b5ef>] device_unregister+0x8/0x10
 [<d88304b9>] pcmcia_card_remove+0x66/0x81 [pcmcia]
 [<d883143d>] ds_event+0x4a/0x6d [pcmcia]
 [<c01b6db5>] kobject_get+0xf/0x13
 [<d88172da>] send_event+0x31/0x49 [pcmcia_core]
 [<d88174b9>] socket_shutdown+0xc/0xb3 [pcmcia_core]
 [<d881757c>] socket_remove+0x1c/0x26 [pcmcia_core]
 [<d88175c5>] pcmcia_eject_card+0x3f/0x4c [pcmcia_core]
 [<d8819e48>] pccard_store_eject+0x1b/0x22 [pcmcia_core]
 [<d8819e2d>] pccard_store_eject+0x0/0x22 [pcmcia_core]
 [<c021af3b>] dev_attr_store+0x27/0x2c
 [<c017d1cb>] sysfs_write_file+0xbc/0xe5
 [<c017d10f>] sysfs_write_file+0x0/0xe5
 [<c014df18>] vfs_write+0x8a/0x10c
 [<c014e3ae>] sys_write+0x41/0x67
 [<c0103c76>] sysenter_past_esp+0x5f/0x85
 [<c02b0000>] wait_for_completion+0x33/0xaf
 =======================
Code: 56 53 8b b0 50 01 00 00 eb 21 8b 5c be 34 85 db 74 18 8b 43 04 8b 90 88 00 00 00 85 d2 74 04 89 d8 ff d2 8b 03 e8 fa 0d e6 ff 47 <3b> 7e 20 72 da 8b 46 28 8b 90 8c 00 00 00 85 d2 74 04 89 f0 ff 
EIP: [<d89f7f3e>] ata_host_release+0x2e/0x48 [libata] SS:ESP 0068:d5bfde58

Best Regards
Komuro

Re: [BUG] PATA_PCMCIA does not work

[Alan]

Does this fix the oops ?

Alan


diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c
--- linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-20 13:37:58.000000000 +0000
+++ linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-21 14:06:58.792707976 +0000
@@ -308,7 +342,6 @@
 		if (info->ndev) {
 			struct ata_host *host = dev_get_drvdata(dev);
 			ata_host_detach(host);
-			dev_set_drvdata(dev, NULL);
 		}
 		info->ndev = 0;
 		pdev->priv = NULL;

Re: [BUG] PATA_PCMCIA does not work

[Manuel Lauss]

On Wed, Feb 21, 2007 at 03:37:29PM +0000, Alan wrote:
> Does this fix the oops ?
> 
> Alan
> 
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c
> --- linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-20 13:37:58.000000000 +0000
> +++ linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-21 14:06:58.792707976 +0000
> @@ -308,7 +342,6 @@
>  		if (info->ndev) {
>  			struct ata_host *host = dev_get_drvdata(dev);
>  			ata_host_detach(host);
> -			dev_set_drvdata(dev, NULL);
>  		}
>  		info->ndev = 0;
>  		pdev->priv = NULL;

This bug is also present in 2.6.21-rc1, and this patch
indeed fixes it.

Thanks,

-- 
 ml.

Re: [BUG] PATA_PCMCIA does not work

[Komuro]

Alan <alan@lxorguk.ukuu.org.uk> wrote:

The oops is fixed. Thanks!

But when I repeat insertion/rejection of the device,
ataX.00 is incremented.
Is this correct?

>pccard: PCMCIA card inserted into slot 1
>pccard: card ejected from slot 1
>ata1.00: disabled
>
>pccard: PCMCIA card inserted into slot 1
>pccard: card ejected from slot 1
>ata2.00: disabled
>
>pccard: PCMCIA card inserted into slot 1
>pccard: card ejected from slot 1
>ata3.00: disabled

Best Regards
Komuro

> Does this fix the oops ?
> 
> Alan
> 
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c
> --- linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-20 13:37:58.000000000 +0000
> +++ linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-21 14:06:58.792707976 +0000
> @@ -308,7 +342,6 @@
>  		if (info->ndev) {
>  			struct ata_host *host = dev_get_drvdata(dev);
>  			ata_host_detach(host);
> -			dev_set_drvdata(dev, NULL);
>  		}
>  		info->ndev = 0;
>  		pdev->priv = NULL;
> 
> 
> 

Re: [BUG] PATA_PCMCIA does not work

[Komuro]

Hi,

The pata_pcmcia problem is fixed. Thanks!
(I tested it on kernel 2.6.20-git14)

But kernel 2.6.20-mm2 introduced new oops
when I insert the pata_pcmcia device.


pcmcia: registering new device pcmcia1.0
SCSI subsystem initialized
libata version 2.10 loaded.
ata1: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x00000000 irq 3
scsi0 : pata_pcmcia
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000004d
 printing eip:
d8a1b10e
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /block/hda/size
Modules linked in: pata_pcmcia libata scsi_mod dm_mirror dm_multipath dm_mod pcmcia yenta_socket rsrc_nonstatic pcmcia_core
CPU:    0
EIP:    0060:[<d8a1b10e>]    Not tainted VLI
EFLAGS: 00010296   (2.6.20-mm2 #1)
EIP is at ata_acpi_exec_tfs+0x157/0x8ad [libata]
eax: 00000001   ebx: 00000000   ecx: d6d43c84   edx: d6d43c84
esi: d51f4514   edi: 00000000   ebp: d51f438c   esp: d6f2bcdc
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process scsi_eh_0 (pid: 1647, ti=d6f2a000 task=c13c9a70 task.ti=d6f2a000)
Stack: d51f6190 00000246 00000246 00000000 d8a130b7 00000000 00000000 00000000 
       00000000 d6f2bd48 d6f2bdf0 d51f4514 ec000000 d51f6190 00000000 00000000 
       00000000 00000246 d6d43c84 00000000 00000000 00000000 00000000 ffffffff 
Call Trace:
 [<d8a130b7>] ata_exec_internal_sg+0x3ae/0x3b8 [libata]
 [<d8a125f8>] ata_dev_configure+0xc1/0x7d2 [libata]
 [<d8a10e87>] ata_dev_select+0xce/0x11a [libata]
 [<d8a1324e>] ata_dev_read_id+0xe0/0x2d1 [libata]
 [<d8a19c7f>] ata_do_eh+0x1235/0x16de [libata]
 [<d8a1234d>] ata_std_softreset+0x0/0xbe [libata]
 [<d8a14270>] ata_std_prereset+0x0/0x127 [libata]
 [<c011ebe9>] cancel_work_sync+0x1c/0x87
 [<d8a17c2a>] ata_bmdma_drive_eh+0xd2/0x167 [libata]
 [<d8a1234d>] ata_std_softreset+0x0/0xbe [libata]
 [<d8a17cf2>] ata_bmdma_error_handler+0x33/0x37 [libata]
 [<d8a1210e>] ata_std_postreset+0x0/0x7e [libata]
 [<d8a1a707>] ata_scsi_error+0x223/0x4b4 [libata]
 [<d885b956>] scsi_error_handler+0x0/0x490 [scsi_mod]
 [<d885ba16>] scsi_error_handler+0xc0/0x490 [scsi_mod]
 [<c02bb445>] _spin_unlock_irq+0x5/0x7
 [<c02b9d9c>] __sched_text_start+0x4e4/0x569
 [<c010eaca>] __wake_up_common+0x32/0x55
 [<d885b956>] scsi_error_handler+0x0/0x490 [scsi_mod]
 [<c0120b4f>] kthread+0xa0/0xc9
 [<c0120aaf>] kthread+0x0/0xc9
 [<c0103f3f>] kernel_thread_helper+0x7/0x10
 =======================
Code: 0f 84 e1 00 00 00 8b 54 24 48 c7 44 24 5c ff ff ff ff 8b 4c 24 48 c7 44 24 60 00 00 00 00 83 ea 48 8b 42 10 8b 5a 20 8b 54 24 48 <8b> 78 4c 8b 92 8c 01 00 00 89 54 24 44 8b 81 a4 00 00 00 8d 54 
EIP: [<d8a1b10e>] ata_acpi_exec_tfs+0x157/0x8ad [libata] SS:ESP 0068:d6f2bcdc

Best Regards
Komuro

Re: [BUG] PATA_PCMCIA does not work

[Jeff Garzik]

Komuro wrote:
> Hi,
> 
> The pata_pcmcia problem is fixed. Thanks!
> (I tested it on kernel 2.6.20-git14)
> 
> But kernel 2.6.20-mm2 introduced new oops
> when I insert the pata_pcmcia device.
> 
> 
> pcmcia: registering new device pcmcia1.0
> SCSI subsystem initialized
> libata version 2.10 loaded.
> ata1: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x00000000 irq 3
> scsi0 : pata_pcmcia
> BUG: unable to handle kernel NULL pointer dereference at virtual address 0000004d
>  printing eip:
> d8a1b10e
> *pde = 00000000
> Oops: 0000 [#1]
> last sysfs file: /block/hda/size
> Modules linked in: pata_pcmcia libata scsi_mod dm_mirror dm_multipath dm_mod pcmcia yenta_socket rsrc_nonstatic pcmcia_core
> CPU:    0
> EIP:    0060:[<d8a1b10e>]    Not tainted VLI
> EFLAGS: 00010296   (2.6.20-mm2 #1)
> EIP is at ata_acpi_exec_tfs+0x157/0x8ad [libata]
> eax: 00000001   ebx: 00000000   ecx: d6d43c84   edx: d6d43c84
> esi: d51f4514   edi: 00000000   ebp: d51f438c   esp: d6f2bcdc
> ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
> Process scsi_eh_0 (pid: 1647, ti=d6f2a000 task=c13c9a70 task.ti=d6f2a000)
> Stack: d51f6190 00000246 00000246 00000000 d8a130b7 00000000 00000000 00000000 
>        00000000 d6f2bd48 d6f2bdf0 d51f4514 ec000000 d51f6190 00000000 00000000 
>        00000000 00000246 d6d43c84 00000000 00000000 00000000 00000000 ffffffff 
> Call Trace:
>  [<d8a130b7>] ata_exec_internal_sg+0x3ae/0x3b8 [libata]
>  [<d8a125f8>] ata_dev_configure+0xc1/0x7d2 [libata]
>  [<d8a10e87>] ata_dev_select+0xce/0x11a [libata]

Any chance you could insert some printk() calls into ata_apci_exec_tfs? 
  ata_exec_internal_sg() never calls that function, so I'm curious if 
something corrupted memory a bit, or what happened.

In any case, I'm surprised that ACPI would be executing taskfiles on 
PCMCIA anyway.

	Jeff

Re: [BUG] PATA_PCMCIA does not work

[Komuro]

On Sat, 24 Feb 2007 20:45:18 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> Any chance you could insert some printk() calls into ata_apci_exec_tfs? 
>   ata_exec_internal_sg() never calls that function, so I'm curious if 
> something corrupted memory a bit, or what happened.

I insert some printk().
I think the problem is happening on do_drive_get_GTF.


>pcmcia: registering new device pcmcia0.0
>SCSI subsystem initialized
>libata version 2.10 loaded.
>ata1: PATA max PIO0 cmd 0x00010100 ctl 0x0001010e bmdma 0x00000000 irq 4
>scsi0 : pata_pcmcia
>ata_acpi_exec_tfs 0  
>ata_acpi_exec_tfs 1  
>BUG: unable to handle kernel NULL pointer dereference at virtual address 0000004d
> printing eip:
>
>
>int ata_acpi_exec_tfs(struct ata_port *ap)
>{
>	int		ix;
>	int		ret =0;
>	unsigned int	gtf_length;
>	unsigned long	gtf_address;
>	unsigned long	obj_loc;
>
>	if (noacpi)
>		return 0;
>
>	for (ix = 0; ix < ATA_MAX_DEVICES; ix++) {
>		printk("ata_acpi_exec_tfs 0  \n");
>		if (!ata_dev_enabled(&ap->device[ix]))
>			continue;
>
>		printk("ata_acpi_exec_tfs 1  \n");
>		ret = do_drive_get_GTF(ap, ix,
>				&gtf_length, &gtf_address, &obj_loc);
>		printk("ata_acpi_exec_tfs 2  \n");
>		if (ret < 0) {

Best Regards
Komuro

Re: [PATCH]: pcmcia - spot slave decode flaws (for testing)

[Komuro]

Hi,

"[PATCH]: pcmcia - spot slave decode flaws (for testing)" works properly.
(kernel 2.6.21-rc4-mm1)

pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
ata3: PATA max PIO0 cmd 0x00010100 ctl 0x0001010e bmdma 0x00000000 irq 3
scsi2 : pata_pcmcia
ata3.00: CFA: SunDisk SDP5-10, Rev 3.70, max PIO0
ata3.00: 20480 sectors, multi 0: LBA 
ata3.01: CFA: SunDisk SDP5-10, Rev 3.70, max PIO0
ata3.01: 20480 sectors, multi 0: LBA 
ata3.01: is a ghost device, ignoring.
ata3.01: disabled
ata3.00: configured for PIO0
scsi 2:0:0:0: Direct-Access     ATA      SunDisk SDP5-10  Rev  PQ: 0 ANSI: 5
sd 2:0:0:0: [sda] 20480 512-byte hardware sectors (10 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: [sda] 20480 512-byte hardware sectors (10 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1
sd 2:0:0:0: [sda] Attached SCSI removable disk
sd 2:0:0:0: Attached scsi generic sg0 type 0

Best Regards
Komuro


>If you've got a CF adapter or PCMCIA disc which shows up twice in libata
>pata_pcmcia can you try this patch on top of the updates posted. It tries
>to spot when the slave is a mirror of the master and to fix up problems
>that causes.
>
>Signed-off-by: Alan Cox <alan@redhat.com>
>
>diff -u --new-file --recursive --exclude-from /usr/src/exclude \
>linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c \
>                linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c
>--- linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-20 13:37:58.000000000 \
>                +0000
>+++ linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c	2007-02-20 14:28:13.000000000 +0000
>@@ -54,6 +54,39 @@
> 	dev_node_t	node;
> };
> 
>+/**
>+ *	pcmcia_set_mode	-	PCMCIA specific mode setup
>+ *	@ap: Port
>+ *	@r_failed_dev: Return pointer for failed device
>+ *
>+ *	Perform the tuning and setup of the devices and timings, which
>+ *	for PCMCIA is the same as any other controller. We wrap it however
>+ *	as we need to spot hardware with incorrect or missing master/slave
>+ *	decode, which alas is embarrassingly common in the PC world
>+ */
>+ 
>+static int pcmcia_set_mode(struct ata_port *ap, struct ata_device **r_failed_dev)
>+{
>+	struct ata_device *master = &ap->device[0];
>+	struct ata_device *slave = &ap->device[1];
>+	
>+	if (!ata_dev_enabled(master) || !ata_dev_enabled(slave))
>+		return ata_do_set_mode(ap, r_failed_dev);
>+		
>+	if (memcmp(master->id + ATA_ID_FW_REV,  slave->id + ATA_ID_FW_REV,
>+			   ATA_ID_FW_REV_LEN + ATA_ID_PROD_LEN) == 0)
>+	{
>+		/* Suspicious match, but could be two cards from
>+		   the same vendor - check serial */
>+		if (memcmp(master->id + ATA_ID_SERNO, slave->id + ATA_ID_SERNO,
>+			   ATA_ID_SERNO_LEN) == 0 && master->id[ATA_ID_SERNO] >> 8) {
>+			ata_dev_printk(slave, KERN_WARNING, "is a ghost device, ignoring.\n");
>+			ata_dev_disable(slave);
>+		}	 
>+	}
>+	return ata_do_set_mode(ap, r_failed_dev);
>+}
>+
> static struct scsi_host_template pcmcia_sht = {
> 	.module			= THIS_MODULE,
> 	.name			= DRV_NAME,
>@@ -73,6 +106,7 @@
> };
> 
> static struct ata_port_operations pcmcia_port_ops = {
>+	.set_mode	= pcmcia_set_mode,
> 	.port_disable	= ata_port_disable,
> 	.tf_load	= ata_tf_load,
> 	.tf_read	= ata_tf_read,

[BUG] PATA_PCMCIA cmd port

[Komuro]

Hi,
 
The pata_pcmcia driver reports the cmd port is 0x00010100,
but actually the cmd port is 0x0100.

Is this corect?

>ata1: PATA max PIO0 cmd 0x00010100 ctl 0x0001010e bmdma 0x00000000 irq 3
                               ^^^^^^^^^^^^^      ^^^^^^^^^^^^^

Best Regards
Komuro

libata reports bogus addresses for everything (was PATA_PCMCIA cmd port)

[Alan Cox]

On Sat, 17 Mar 2007 22:00:50 +0900
Komuro <komurojun-mbn@nifty.com> wrote:

> 
> Hi,
>  
> The pata_pcmcia driver reports the cmd port is 0x00010100,
> but actually the cmd port is 0x0100.
> 
> Is this corect?

When the pci_iomap patches were applied the ports reported for every
device went strange.  It appears to display the wrong information
nowdays. I see the same but I've got many more important things to work
on before I even bother to look at it.

My guess is someone is now printing the iomap virtual addresses not the
bus ones.

Alan

Re: libata reports bogus addresses for everything (was PATA_PCMCIA cmd port)

[Tejun Heo]

Alan Cox wrote:
> On Sat, 17 Mar 2007 22:00:50 +0900
> Komuro <komurojun-mbn@nifty.com> wrote:
> 
>> Hi,
>>  
>> The pata_pcmcia driver reports the cmd port is 0x00010100,
>> but actually the cmd port is 0x0100.
>>
>> Is this corect?
> 
> When the pci_iomap patches were applied the ports reported for every
> device went strange.  It appears to display the wrong information
> nowdays. I see the same but I've got many more important things to work
> on before I even bother to look at it.
> 
> My guess is someone is now printing the iomap virtual addresses not the
> bus ones.

Yes, we're printing the ioaddr.* directly and those are all iomapped
addressed now.  I wonder whether we should fix this or push the port
printing to LLDs (with sff helpers in libata-sff).  ahci and
pata_generic sharing one format doesn't sound like a too good idea.
I'll fix it after new init model.

-- 
tejun

Re: [BUG] PATA_PCMCIA cmd port

[Jeff Garzik]

Komuro wrote:
> The pata_pcmcia driver reports the cmd port is 0x00010100,
> but actually the cmd port is 0x0100.
> 
> Is this corect?
> 
>> ata1: PATA max PIO0 cmd 0x00010100 ctl 0x0001010e bmdma 0x00000000 irq 3
>                                ^^^^^^^^^^^^^      ^^^^^^^^^^^^^

It's printing out the post-iomap numbers.  Just a cosmetic problem. 
Patches welcome though :)

	Jeff