From bunk at stusta.de  Wed Apr  5 12:37:27 2006
From: bunk at stusta.de (Adrian Bunk)
Date: Wed Apr  5 12:44:43 2006
Subject: [Linux-parport] [2.6 patch] drivers/parport/share.: unexport
	parport_get_port
Message-ID: <20060405163727.GH8673@stusta.de>

This patch removes the unused EXPORT_SYMBOL(parport_get_port).

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-rc1-mm1-full/drivers/parport/share.c.old	2006-04-05 17:12:05.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/parport/share.c	2006-04-05 17:12:42.000000000 +0200
@@ -1003,7 +1003,6 @@
 EXPORT_SYMBOL(parport_unregister_driver);
 EXPORT_SYMBOL(parport_register_device);
 EXPORT_SYMBOL(parport_unregister_device);
-EXPORT_SYMBOL(parport_get_port);
 EXPORT_SYMBOL(parport_put_port);
 EXPORT_SYMBOL(parport_find_number);
 EXPORT_SYMBOL(parport_find_base);


From adobriyan at gmail.com  Thu Apr  6 16:03:29 2006
From: adobriyan at gmail.com (Alexey Dobriyan)
Date: Fri Apr  7 08:10:34 2006
Subject: [Linux-parport] Re: [2.6 patch] drivers/parport/share.: unexport
	parport_get_port
In-Reply-To: <20060405163727.GH8673@stusta.de>
References: <20060405163727.GH8673@stusta.de>
Message-ID: <20060406195005.GA7167@mipter.zuzino.mipt.ru>

On Wed, Apr 05, 2006 at 06:37:27PM +0200, Adrian Bunk wrote:
> This patch removes the unused EXPORT_SYMBOL(parport_get_port).

> --- linux-2.6.17-rc1-mm1-full/drivers/parport/share.c.old
> +++ linux-2.6.17-rc1-mm1-full/drivers/parport/share.c

> -EXPORT_SYMBOL(parport_get_port);
>  EXPORT_SYMBOL(parport_put_port);

This looks wrong even it's unused. Think exporting kfree() and not
exporting kmalloc().


From bunk at stusta.de  Tue Apr 18 18:07:20 2006
From: bunk at stusta.de (Adrian Bunk)
Date: Tue Apr 18 18:36:58 2006
Subject: [Linux-parport] [2.6 patch] drivers/parport/share.: unexport
	parport_get_port
Message-ID: <20060418220720.GQ11582@stusta.de>

This patch removes the unused EXPORT_SYMBOL(parport_get_port).

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 5 Apr 2006

--- linux-2.6.17-rc1-mm1-full/drivers/parport/share.c.old	2006-04-05 17:12:05.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/parport/share.c	2006-04-05 17:12:42.000000000 +0200
@@ -1003,7 +1003,6 @@
 EXPORT_SYMBOL(parport_unregister_driver);
 EXPORT_SYMBOL(parport_register_device);
 EXPORT_SYMBOL(parport_unregister_device);
-EXPORT_SYMBOL(parport_get_port);
 EXPORT_SYMBOL(parport_put_port);
 EXPORT_SYMBOL(parport_find_number);
 EXPORT_SYMBOL(parport_find_base);


From parport at baker-net.org.uk  Wed Apr 19 16:03:17 2006
From: parport at baker-net.org.uk (Adam Baker)
Date: Wed Apr 19 16:04:08 2006
Subject: [Linux-parport] [2.6 patch] drivers/parport/share.: unexport
	parport_get_port
In-Reply-To: <20060418220720.GQ11582@stusta.de>
References: <20060418220720.GQ11582@stusta.de>
Message-ID: <200604192103.17854.parport@baker-net.org.uk>

On Tuesday 18 April 2006 23:07, Adrian Bunk wrote:
> This patch removes the unused EXPORT_SYMBOL(parport_get_port).
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>

It may be unused by any drivers that ship with the kernel but it is used by 
the ppscsi patch to support SCSI over parallel port devices. This export was 
removed in 2.6.10 and put back in in 2.6.16 so someone else obviously thinks 
it should be exported.

> ---
>
> This patch was already sent on:
> - 5 Apr 2006
>
> --- linux-2.6.17-rc1-mm1-full/drivers/parport/share.c.old	2006-04-05
> 17:12:05.000000000 +0200 +++
> linux-2.6.17-rc1-mm1-full/drivers/parport/share.c	2006-04-05
> 17:12:42.000000000 +0200 @@ -1003,7 +1003,6 @@
>  EXPORT_SYMBOL(parport_unregister_driver);
>  EXPORT_SYMBOL(parport_register_device);
>  EXPORT_SYMBOL(parport_unregister_device);
> -EXPORT_SYMBOL(parport_get_port);
>  EXPORT_SYMBOL(parport_put_port);
>  EXPORT_SYMBOL(parport_find_number);
>  EXPORT_SYMBOL(parport_find_base);
>


From bunk at stusta.de  Wed Apr 19 17:02:16 2006
From: bunk at stusta.de (Adrian Bunk)
Date: Wed Apr 19 17:24:54 2006
Subject: [Linux-parport] [2.6 patch] drivers/parport/share.: unexport
	parport_get_port
In-Reply-To: <200604192103.17854.parport@baker-net.org.uk>
References: <20060418220720.GQ11582@stusta.de>
	<200604192103.17854.parport@baker-net.org.uk>
Message-ID: <20060419210216.GF25047@stusta.de>

On Wed, Apr 19, 2006 at 09:03:17PM +0100, Adam Baker wrote:
> On Tuesday 18 April 2006 23:07, Adrian Bunk wrote:
> > This patch removes the unused EXPORT_SYMBOL(parport_get_port).
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> 
> It may be unused by any drivers that ship with the kernel but it is used by 
> the ppscsi patch to support SCSI over parallel port devices. This export was 
> removed in 2.6.10 and put back in in 2.6.16 so someone else obviously thinks 
> it should be exported.
>...

That someone else thinks it should be exported hasn't any value.

If the SCSI over parallel port drivers are considered valuable, someone 
should work on getting them included in the kernel.

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


From myPublicListAddress at bresnan.net  Thu Apr 20 21:54:31 2006
From: myPublicListAddress at bresnan.net (Jason Winzenried)
Date: Fri Apr 21 06:53:21 2006
Subject: [Linux-parport] using backpack with paride and starting k3b causes
	100% CPU until reboot
Message-ID: <200604201954.32055.myPublicListAddress@bresnan.net>

I can load up the backpack drivers for my parallel port cd drive.  Can mount 
and read from a CD just fine.

The problem is when I run k3b.  If there is a disk in the drive, k3b never 
starts (goes into disk sleep), and events/0 chews up 100% CPU until I reboot.  
If no disk is in the drive, k3b starts but as soon as I do 
settings->configure k3b->devices->refresh it goes into disk sleep and 
events/0 does its CPU thing.

Obvious answer is not to do that.  I don't need that drive for burning (would 
rather use the built in DVD/CD burner than the max 2 speed the burnfree-less 
backpack drive offers).  

Nonetheless, it is not ideal to either reboot or watch my CPU burn if I ever 
forget to remove any disk from the backpack before starting k3b.  What could 
be going on?  Is there perhaps a convenient way to have k3b ignore the 
backpack drive?

Not loading pg makes no difference.  Only skipping or unloading pcd can 
prevent it.  Of course then I can't use the drive for reading.

I'm using debian testing.  Same results with Ubuntu Dapper (not entirely 
surprising). 

#uname -a
Linux Otome-Kairo 2.6.15-ck4 #1 PREEMPT Mon Feb 20 00:30:22 MST 2006 i686 
GNU/Linux
(same results with ubuntu, using their kernel 2.6.15-20-386)


(just to show what versions of udev etc. are running)
# apt-get -s remove udev dbus k3b
Remv hal [0.5.7-1]
Remv dbus [0.61-5]
Remv udev [0.089-1]
Remv k3b [0.12.12-1]


#top
PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
3    root      22  -5     0    0    0 R 96.3  0.0   3:17.73 events/0
4254 Winzenri   0   0 40056  22m  17m D  0.0  2.2   0:05.10 k3b 
(k3b is in disk sleep)


#lsmod
Module                  Size  Used by
pcd                    17508  1
pg                     10628  0
bpck6                   6788  2
paride                  8128  3 pcd,pg,bpck6
parport_pc             32644  1
parport                32712  2 paride,parport_pc

#cdrdao scanbus
Cdrdao version 1.2.1 - (C) Andreas Mueller <andreas@daneb.de>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty

Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.

Using libscg version 'schily-0.8'

0,0,0 : TEAC    , CD-W54E         , 1.1B
ATA:1,0,0            PIONEER , DVD-ROM DVD-106 , 1.22
ATA:1,1,0            HL-DT-ST, DVDRRW GCA-4164B, E.D0


#cdrecord -scanbus
Cdrecord-Clone 2.01.01a03 (i686-pc-linux-gnu) Copyright (C) 1995-2005 Joerg 
Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord
      and thus may have bugs that are not present in the original version.
      Please send bug reports and support requests to 
<cdrtools@packages.debian.org>.
      The original author should not be bothered with problems of this 
version.

cdrecord: Warning: Running on Linux-2.6.15-ck4
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
Using libscg version 'debian-0.8debian2'.
cdrecord: Warning: using inofficial version of libscg 
(debian-0.8debian2 '@(#)scsitransp.c      1.91 04/06/17 Copyright 
1988,1995,2000-2004 J. Schilling').
scsibus0:
        0,0,0     0) 'TEAC    ' 'CD-W54E         ' '1.1B' Removable CD-ROM
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *


#ls -l /dev/pcd0
brw-rw---- 1 root cdrom 46, 0 2006-04-20 08:12 ./pcd0

ls -l /dev/pg0
crw-rw---- 1 root cdrom 97, 0 2006-04-20 08:00 ./pg0
pcd0 was in group disk.  pg0 was in group root.  They each revert to that 
after rebooting.  Same results though.


#nano /var/log/syslog
Apr 20 08:01:04 Otome-Kairo kernel: parport_pc: VIA 686A/8231 detected
Apr 20 08:01:04 Otome-Kairo kernel: parport_pc: probing current configuration
Apr 20 08:01:04 Otome-Kairo kernel: parport_pc: Current parallel port base: 
0x378
Apr 20 08:01:04 Otome-Kairo kernel: parport0: PC-style at 0x378 (0x778), irq 
7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]

Apr 20 08:01:04 Otome-Kairo kernel: parport_pc: VIA parallel port: io=0x378, 
irq=7

Apr 20 08:01:04 Otome-Kairo kernel: bpck6: BACKPACK Protocol Driver V2.0.2
Apr 20 08:01:04 Otome-Kairo kernel: bpck6: Copyright 2001 by Micro Solutions, 
Inc., DeKalb IL. USA
Apr 20 08:01:04 Otome-Kairo kernel: paride: bpck6 registered as protocol 0
Apr 20 08:01:04 Otome-Kairo kernel: pcd: pcd version 1.07, major 46, nice 0
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: Sharing parport0 at 0x378
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: BACKPACK Protocol Driver V2.0.2
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: Copyright 2001 by Micro Solutions, 
Inc., DeKalb IL.
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: BACKPACK 2.0.2, Micro Solutions 
BACKPACK Drive at 0x378
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: Unit: 31 Mode:1 (8-bit) Delay 0
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: Master: CD-W54E
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: mode sense capabilities completion: 
alt=0x51 stat=0x51 err=0x64 loop=0 phase=3
Apr 20 08:01:04 Otome-Kairo kernel: pcd0: mode sense capabilities: Sense key: 
6, ASC: 29, ASQ: 0
Apr 20 08:01:04 Otome-Kairo kernel: cdrom: open failed.
Apr 20 08:01:04 Otome-Kairo kernel: pg: pg version 1.02, major 97
Apr 20 08:01:04 Otome-Kairo kernel: pga: Sharing parport0 at 0x378
Apr 20 08:01:04 Otome-Kairo kernel: pga: BACKPACK Protocol Driver V2.0.2
Apr 20 08:01:04 Otome-Kairo kernel: pga: Copyright 2001 by Micro Solutions, 
Inc., DeKalb IL.
Apr 20 08:01:04 Otome-Kairo kernel: pga: BACKPACK 2.0.2, Micro Solutions 
BACKPACK Drive at 0x378
Apr 20 08:01:04 Otome-Kairo kernel: pga: Unit: 31 Mode:1 (8-bit) Delay 0
Apr 20 08:01:04 Otome-Kairo kernel: pga: TEAC CD-W54E, master

Apr 20 08:12:24 Otome-Kairo k3b: resmgr: communication failure: No such file 
or directory

From dsd at gentoo.org  Sun Apr 23 07:06:41 2006
From: dsd at gentoo.org (Daniel Drake)
Date: Mon Apr 24 05:48:06 2006
Subject: [Linux-parport] 2.6.16 doesn't boot with CONFIG_TIPAR=y 
Message-ID: <444B5FC1.9090502@gentoo.org>

Hi Andrew,

Your commit titled "[PATCH] tipar fixes" breaks the boot of 2.6.16 and 
newer when CONFIG_TIPAR=y, and the appropriate parallel port driver is 
compiled-in, and the system has at least one parallel port.

The problem is as follows:

drivers/Makefile loads char/tipar.c early during boot (before any 
parport stuff).

tipar_init_module does some stuff and then reaches:
	if (parport_register_driver(&tipar_driver) || tp_count == 0) {
		destroy sysfs class
		return failure
	}

At this point, parport_register_driver() succeeds, but the tipar_attach 
function is *not* called as the parport system hasn't been initialised 
yet. This means that tp_count == 0, so we clean up a bit and return 
failure. Note that we do not unregister from the parport driver, so as 
far as parport is concerned, all is fine.

Later on, drivers/Makefile loads parport/*. parport then calls the 
tipar_attach function which we registered earlier, which then does some 
sysfs stuff. This is a problem because we destroyed the sysfs class 
earlier on.

This is the end result:

tipar: parallel link cable driver, version 1.19
tipar: unable to register with parport
initcall at 0xc03cf1c6: tipar_init_module+0x0/0xa1(): returned with 
error code -5
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
ppdev: user-space parallel port driver
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.0.1 20051102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
parport0: PC-style at 0x378 [PCSPP,EPP]
BUG: unable to handle kernel paging request at virtual address 00a0008f
  printing eip:
c0167263
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:
CPU:    0
EIP:    0060:[<c0167263>]    Not tainted VLI
EFLAGS: 00000286   (2.6.17-rc2 #3)
EIP is at create_dir+0x15/0x165
eax: c12cedc8   ebx: c12cedcc   ecx: c12cedcc   edx: 00a00087
esi: 00000000   edi: c12cedcc   ebp: c113deac   esp: c113de8c
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=c113c000 task=c1139a10)
Stack: <0>00a00087 c12cedc8 c12cedc8 00000000 c12cedc8 c12768a0 c016740f 
c113deac
        00000000 c12cedc8 c019e611 c12cedc8 c12768b8 c019e7e5 c12cee38 
c12cedc0
        c12cedc8 c021986b ffffffea 00000000 00000000 c12cedc0 fffffff4 
c12768a0
Call Trace:
  <c016740f> sysfs_create_dir+0x4b/0x5d   <c019e611> create_dir+0x10/0x2f
  <c019e7e5> kobject_add+0x90/0xd8   <c021986b> class_device_add+0x9b/0x1dc
  <c0219a32> class_device_create+0x76/0x8c   <c01f562e> 
tipar_register+0x52/0x9e
  <c01f569a> tipar_attach+0x20/0x33   <c02123b5> 
attach_driver_chain+0x21/0x2e
  <c0212751> parport_announce_port+0x72/0x94   <c0216aca> 
parport_pc_probe_port+0x428/0x496
  <c0217475> parport_pc_find_isa_ports+0x3c/0x67   <c03d0004> 
parport_pc_find_ports+0x14/0x37
  <c03d03de> parport_pc_init+0x7f/0x86   <c03be67f> do_initcalls+0x53/0xda
  <c0163422> proc_mkdir_mode+0x37/0x49   <c010027c> init+0x0/0x118
  <c01002ae> init+0x32/0x118   <c0100cbd> kernel_thread_helper+0x5/0xb
Code: 00 00 00 e5 2d c0 31 c0 c3 c7 80 88 00 00 00 40 f7 34 c0 31 c0 c3 
55 57 56 53 53 53 89 cb 8b 6c 24 1c 89 df 89 14 24 89 44 24 04 <8b> 42 
08 83 c0 70 e8 83 16 17 00 31 c0 83 c9 ff f2 ae f7 d1 49
EIP: [<c0167263>] create_dir+0x15/0x165 SS:ESP 0068:c113de8c
  <0>Kernel panic - not syncing: Attempted to kill init!

I've attached a patch to solve this, but I'm not sure if it is correct: 
it reverts part of your patch. From the description it sounds like this 
path may be covered by your changes in tipar_open() so maybe it is OK...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tipar-boot-oops.patch
Type: text/x-patch
Size: 834 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-parport/attachments/20060423/ce1fda93/tipar-boot-oops.bin
From andreas.stricker at fela.ch  Tue Apr 25 07:08:19 2006
From: andreas.stricker at fela.ch (Andreas Stricker)
Date: Tue Apr 25 07:57:17 2006
Subject: [Linux-parport] Problem with ppdev in EPP mode
Message-ID: <444E0323.7020708@fela.ch>

Hi

I've got a problem with ppdev in EPP mode. I need a verification
if I'm right. The Problem:

I've got hardware that should be EPP 1.9 compatible. If I write to
the port, the write()-Call returns 0 bytes written. If I read from
the port, the driver blocks in read().

To open the port I do (error checking simplified):

   fd = open(device, O_RDWR | O_NOCTTY);
   if (ioctl(fd, PPCLAIM))
       error();

Then I try for example to write to address 0x03:

   char addr = 0x03;
   int mode = IEEE1284_MODE_EPP | IEEE1284_ADDR;
   if (ioctl(fd, PPSETMODE, &mode) == -1)
       error();
   wrote = write(fd, &addr, 1);   /* here write returns 0! */
   if ( wrote < 0 )
       error();
   if ( wrote < 1 )
       warn();

   /* the following part is here for completeness */
   mode = IEEE1284_MODE_EPP | IEEE1284_DATA;
   wrote = write(fd, &data, 1);  /* here write returns 0, too */
   if ( wrote < 0 )
       error();
   if ( wrote < 1 )
       warn();

Am I right that if the write() in address mode returns zero,
the address was not written? Is this the same if i don't plug
any devices in? Then this could be a hardware issue?


More informations:

The driver seems to correctly load and detect the right hardware:
(in BIOS the parallel port is set to EPP1.9)

ppdev: user-space parallel port driver
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
parport_pc: VIA parallel port: io=0x378, irq=7

If I run my program, the kernel write:
ppdev0: registered pardevice

And if I exit my program, the kernel write:
ppdev0: unregistered pardevice

I'm using a self compiled vanilla kernel linux 2.6.14.1.

The port and the device attached works. The piece of software
I'm redesign was written with ioperm() and direct I/O from
user-space (urgs!). The old code writes to BASE + 3 (address)
and BASE + 4 (EPPDATA).

Cheers,
Andy


From andreas.stricker at fela.ch  Fri Apr 28 12:00:41 2006
From: andreas.stricker at fela.ch (Andreas Stricker)
Date: Fri Apr 28 12:02:23 2006
Subject: [Linux-parport] Problem with ppdev in EPP mode
In-Reply-To: <444E0323.7020708@fela.ch>
References: <444E0323.7020708@fela.ch>
Message-ID: <44523C29.8070902@fela.ch>

Hi

I'm narrowing the problem. It seems like the mode IEEE1284_MODE_EPP
don't work on that machine. To remind:

 > parport_pc: VIA 686A/8231 detected

If I set the software emulated mode (IEEE1284_MODE_EPPSWE) it works.

The device is definitly able to do hardware supported EPP. If
I write directly to IO. I can send addresses by writing to
base_port+3 (address) and data by writing to base_port+4 (eppdata).
(base_port set to 0x378).

I've looked at the lspci output and saw this:

0000:00:0c.1 Parallel controller: Oxford Semiconductor Ltd: Unknown device 9500
0000:00:0c.1 0701: 1415:9500

Although it's a VIA board, could it be there was not the right
driver loaded?

Host bridge: VIA Technologies VT8605 [ProSavage PM133] (1106:0605)
ISA bridge: VIA Technologies VT82C686 [Apollo Super South] (1106:0686 rev 40)
Bridge: VIA Technologies VT82C686 [Apollo Super ACPI] (1106:3057 rev 40)

I'll do further research. I think it could be possible that this
parallel port device is unknow to the driver.


Cheers,

Andy who is still reading the kernel source...

