Jarkko Lavinen | 2 Jan 2005 22:53
Picon
Picon
Favicon

ppa problems

I was unable to read files from Zip100 with ppa. When I tried to read
a file, a systematic and repeatable thread death occured with backtrace:

# modprobe ppa; mount -t vfat /dev/sda4 /mnt; find /mnt -type f -exec cp {} /dev/null \;
  show_stack
  show_register
  die
  do_page_fault
  error_code
  ppa_completion
  ppa_engine
  ppa_interrupt
  worker_thread
  kthread
  kernel_thread_helper

I have seen this with kernels 2.6.8.1, 2.6.9, and 2.6.9-rc3, but with
2.6.10 reading files seem to work again.

Did somebody fix something or is the improvement accidental?  At least
ppa.c has not changed between 2.6.8.1 to 2.6.10 which suggests the
problem is not related to ppa.

With recent kernels ppa.c won't compile if PPA_DEBUG is enabled.

Jarkko Lavinen
Michael Reinelt | 2 Jan 2005 23:51
Picon
Favicon

parport_serial and NetMos 9835

Hi List,

I sent this mail to Tim, but he told me that he's no longer maintaining 
the parport stuff. So I'm trying here....

Please CC me, cause I'm not on the list (btw, how do I subscribe? I 
remember the parport list somewhere at torque.net or something...)

I'm having problems to get my NetMos 9835 up and running with
kernel 2.6.10

I digged a bit into the code, and I think I found the reason: The card
provides one parallel and two serial ports, and is handled fine by
parport_serial. BUT the 9835 is handled by parport_pc, too (which is
wrong, IMHO). I'm not shure, but I suppose that parport_serial does not
touch the device if it's already handled by another driver (parport_pc,
which gets autoloaded before parport_serial) and therefore does not
enable and register the serial ports.

I commented out all the 9835 stuff in parport_pc, and now everything
works fine.

I see two possibilities for a clean solution:

a) remove all netmos cards that provide at least one serial port from
parport_pc (this is not only the 9835, but some other netmos cards, too)

b) change parport_serial so that it handles serial ports from cards
where the parallel port is already handled by parport_pc.

(Continue reading)

Ed Murray | 10 Jan 2005 12:42

ppscsi patch fails on 2.6.10


The Debian maintained ppscsi patch has has a few minor problems with the
most recent kernels. We recently changed scsi_sleep calls within the
patch to msleep in order to get it working with the 2.6.9 kernel.
Fortunately this appeared to be all that was needed. However with the
release of 2.6.10 there appears to be another problem which has cropped
up. It still compiles without a hitch but when modprobe ppscsi is called
the following error can be found in dmesg: ppscsi: Unknown symbol
parport_get_port. Can anybody give any assistance with this please?

Regards
Ed Murray
Jochen Eisinger | 10 Jan 2005 18:09

Re: ppscsi patch fails on 2.6.10

Hi,

currently i don't have a machine to test this on. I hope my new box 
arrives within the next two weeks, I'll have a look at it then

kind regards
-- jochen
Marko Kohtala | 10 Jan 2005 19:15
Favicon

[PATCH] export parport_get_port

Hi all.

I made a few patches to parport. These are all against Linus bk tree at 
http://linux.bkbits.net/linux-2.5.

Please comment on them. If someone of you gets them added to Linus's 
repository, please do.

This is propably the most obvious. Ed was already asking for this...

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/12/15 22:55:51+02:00 kohtala <at> kohtala.home.org
#   share.c:
#     Export parport_get_port for ppSCSI
#
# drivers/parport/share.c
#   2004/12/15 22:50:57+02:00 kohtala <at> kohtala.home.org +1 -0
#   Export parport_get_port for ppSCSI
#
diff -Nru a/drivers/parport/share.c b/drivers/parport/share.c
--- a/drivers/parport/share.c	2005-01-10 20:00:22 +02:00
+++ b/drivers/parport/share.c	2005-01-10 20:00:22 +02:00
 <at>  <at>  -1007,6 +1007,7  <at>  <at> 
  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);
(Continue reading)

Marko Kohtala | 10 Jan 2005 19:19
Favicon

[PATCH] parport_open to open IEEE1284.3 device

This patch is what I worry about. It seems to me that it has been always 
impossible to open daisy chain devices. Hasn't this been used or am I missing 
something?

If you have daisy chain devices, please check the
/proc/sys/dev/parport/parport0/autoprobe* files if they show any data.

I only have Kodak Advantix FD 300 film drive which seems to be very buggy.
This makes the driver try to read the IEEE1284 Device ID.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/09 23:37:22+02:00 kohtala <at> kohtala.home.org
#   Fix parport IEEE1284.3 daisy device opening to open existing devices.
#
# drivers/parport/daisy.c
#   2005/01/09 23:36:13+02:00 kohtala <at> kohtala.home.org +1 -1
#   Failed to open existing daisy devices.
#
diff -Nru a/drivers/parport/daisy.c b/drivers/parport/daisy.c
--- a/drivers/parport/daisy.c	2005-01-10 07:58:18 +02:00
+++ b/drivers/parport/daisy.c	2005-01-10 07:58:18 +02:00
 <at>  <at>  -252,7 +252,7  <at>  <at> 
  		selected = port->daisy;
  		parport_release (dev);

-		if (selected != port->daisy) {
+		if (selected != daisy) {
  			/* No corresponding device. */
(Continue reading)

Marko Kohtala | 10 Jan 2005 19:28
Favicon

[PATCH] IEEE1284.3 chain end detection fix

My Kodak Advantix FD 300 does not detect itself as last device in chain. This 
patch fixes the address assignment stop when it sees status from non 
IEEE1284.3 device. Also the logic for last_dev was broken because it assigned 
address one past the last device.

It now correctly finds my one broken DC device, but I have no working device 
to test it with. Please test.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/09 23:31:28+02:00 kohtala <at> kohtala.home.org
#   Fix parport IEEE1284.3 daisy chain end detection.
#
# drivers/parport/daisy.c
#   2005/01/09 23:31:15+02:00 kohtala <at> kohtala.home.org +17 -10
#   Some buggy daisy chain devices do not implement last_dev. Detect the end of
#   chain from other false status lines. It used to assign address to device past
#   the last.
#
diff -Nru a/drivers/parport/daisy.c b/drivers/parport/daisy.c
--- a/drivers/parport/daisy.c	2005-01-10 07:58:34 +02:00
+++ b/drivers/parport/daisy.c	2005-01-10 07:58:34 +02:00
 <at>  <at>  -436,7 +436,7  <at>  <at> 

  static int assign_addrs (struct parport *port)
  {
-	unsigned char s, last_dev;
+	unsigned char s;
  	unsigned char daisy;
(Continue reading)

Marko Kohtala | 10 Jan 2005 19:33
Favicon

[PATCH] IEEE1284 Device ID read fixes

I have no working device to test this patch with, so please test it if you 
have one.

My device has this feature broken and it gives all nibbles as value 8, 
forever. This now stops reading the ID sooner and does not overflow the buffer.

I rearranged the code a little to keep it easier to follow.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/09 23:19:37+02:00 kohtala <at> kohtala.home.org
#   Bugfixes to parport IEEE1284 device ID reading.
#
# drivers/parport/probe.c
#   2005/01/09 23:16:56+02:00 kohtala <at> kohtala.home.org +74 -61
#   parport_device_id fixes:
#   - Fix a bug in recent change that could leave the device in nibble mode in
#     failed device ID read.
#   - Fix buffer overflow in case of long device ID and buggy device.
#   - Change to match documentation and return the Device ID length in first 
two bytes.
#   - Handle some devices better that do not implement Device ID but negotiate
#     into the mode.
#
diff -Nru a/drivers/parport/probe.c b/drivers/parport/probe.c
--- a/drivers/parport/probe.c	2005-01-10 07:58:48 +02:00
+++ b/drivers/parport/probe.c	2005-01-10 07:58:48 +02:00
 <at>  <at>  -137,8 +137,78  <at>  <at> 
  	kfree(txt);
(Continue reading)

Marko Kohtala | 10 Jan 2005 19:38
Favicon

[PATCH] fix compilation with DEBUG_PARPORT

The code did not compile with DEBUG_PARPORT defined. I also added a missing 
const to have the pointers in the array in .rodata segment.

This I could have propably sent directly without review.

Who should I send these to or will someone pick these up from this mailing 
list and send to Linus?

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/09 23:43:34+02:00 kohtala <at> kohtala.home.org
#   Fix parport driver to compile with debugging defined.
#
# include/linux/parport_pc.h
#   2005/01/09 23:43:20+02:00 kohtala <at> kohtala.home.org +2 -2
#   Fix to compile when debugging.
#
diff -Nru a/include/linux/parport_pc.h b/include/linux/parport_pc.h
--- a/include/linux/parport_pc.h	2005-01-10 07:57:30 +02:00
+++ b/include/linux/parport_pc.h	2005-01-10 07:57:30 +02:00
 <at>  <at>  -85,8 +85,8  <at>  <at> 
  	unsigned char ecr = inb (ECONTROL (p));
  	unsigned char dcr = inb (CONTROL (p));
  	unsigned char dsr = inb (STATUS (p));
-	static char *ecr_modes[] = {"SPP", "PS2", "PPFIFO", "ECP", "xXx", "yYy", 
"TST", "CFG"};
-	const struct parport_pc_private *priv = (parport_pc_private 
*)p->physport->private_data;
+	static char *const ecr_modes[] = {"SPP", "PS2", "PPFIFO", "ECP", "xXx", 
(Continue reading)

Marko Kohtala | 10 Jan 2005 19:41
Favicon

[PATCH] add const to some static variables

This is only a cleanup. Should not really change anything except move some 
read-only data to read-only section.

Please comment.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/09 23:42:01+02:00 kohtala <at> kohtala.home.org
#   Add some missing "const" from static variables in parport driver.
#
# drivers/parport/probe.c
#   2005/01/09 23:41:49+02:00 kohtala <at> kohtala.home.org +3 -3
#   Add some missing "const"
#
# drivers/parport/parport_pc.c
#   2005/01/09 23:41:49+02:00 kohtala <at> kohtala.home.org +22 -16
#   Add some missing "const"
#
diff -Nru a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
--- a/drivers/parport/parport_pc.c	2005-01-10 07:57:49 +02:00
+++ b/drivers/parport/parport_pc.c	2005-01-10 07:57:49 +02:00
 <at>  <at>  -1160,7 +1160,7  <at>  <at> 

  /* GCC is not inlining extern inline function later overwriten to non-inline,
     so we use outlined_ variants here.  */
-static struct parport_operations parport_pc_ops =
+static const struct parport_operations parport_pc_ops =
  {
  	.write_data	= parport_pc_write_data,
(Continue reading)


Gmane