from:"Adam Kropelin"

Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

2007-08-03 Thread Adam Kropelin


Dave Jones wrote:

On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:


Plus if you're connected to such a device for monitoring purposes
you're probably powered by it as well, so you have little to gain
from suspend even if it works.


I currently don't have any HID UPS by hand to verify, but I'd be
surprised if they would advertise remote wakeup capability ... ?


Looks like mine does..
[...]
 idVendor   0x051d American Power Conversion
 idProduct  0x0002 Back-UPS Pro 500/1000/1500


*notes to self to send pci.ids patch again*


 bcdDevice1.06
 iManufacturer   3 APC
 iProduct1 Back-UPS ES 500 FW:801.e6.D USB FW:e6


Yup, I have one of those in my arsenal and see the same thing.


 iSerial 2 AB0530291763
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   34
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  0
   bmAttributes 0xe0
 Self Powered
 Remote Wakeup


I have reports of APC UPS remote wakeup working properly on "recent" 
PowerMac G5s running OS X, but was never able to duplicate that success 
on my cruddy old G3. I never figured out if it was a deficiency of the 
UPS, the G3, or the OS. So it is possible that with appropriate OS 
support this feature may actually work on certain UPSes (APC has a habit 
of messing up the firmware differently on each model, so it's likely 
hit-or-miss, but they are improving).


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

2007-08-03 Thread Adam Kropelin


Dave Jones wrote:

On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:

On Fri, 3 Aug 2007, Matthew Garrett wrote:


Windows will autosuspend hubs, bluetooth devices, HID devices


Hi Matthew,

are you sure about windows suspending the HID devices in runtime? I
have never seen LEDs of USB keyboard connected to windows host to go
off after some time of not using it.


Not so sure about keyboards, but I've seen the LEDs on USB mice dim
or go off after a few seconds of inactivity under Windows, but under
Linux they stay on.


We have been playing with runtime autosuspend of HID devices, are
currently postponed the full support, as it turns out that many
devices don't support this feature properly (probably due to not
being tested in Windows).


Interesting.  Which devices did you notice failing?
Was it a case that they would sleep and not come back out of that
state?


Although I have no proof immediately at hand, I suspect at a minimum HID 
power class devices should be blacklisted from autosuspend. Given the 
spotty USB implementations on many such devices I'd be surprised if 
suspend worked reliably. Plus if you're connected to such a device for 
monitoring purposes you're probably powered by it as well, so you have 
little to gain from suspend even if it works.


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

2007-08-03 Thread Adam Kropelin


Dave Jones wrote:

On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:

On Fri, 3 Aug 2007, Matthew Garrett wrote:


Windows will autosuspend hubs, bluetooth devices, HID devices


Hi Matthew,

are you sure about windows suspending the HID devices in runtime? I
have never seen LEDs of USB keyboard connected to windows host to go
off after some time of not using it.


Not so sure about keyboards, but I've seen the LEDs on USB mice dim
or go off after a few seconds of inactivity under Windows, but under
Linux they stay on.


We have been playing with runtime autosuspend of HID devices, are
currently postponed the full support, as it turns out that many
devices don't support this feature properly (probably due to not
being tested in Windows).


Interesting.  Which devices did you notice failing?
Was it a case that they would sleep and not come back out of that
state?


Although I have no proof immediately at hand, I suspect at a minimum HID 
power class devices should be blacklisted from autosuspend. Given the 
spotty USB implementations on many such devices I'd be surprised if 
suspend worked reliably. Plus if you're connected to such a device for 
monitoring purposes you're probably powered by it as well, so you have 
little to gain from suspend even if it works.


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

2007-08-03 Thread Adam Kropelin


Dave Jones wrote:

On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:


Plus if you're connected to such a device for monitoring purposes
you're probably powered by it as well, so you have little to gain
from suspend even if it works.


I currently don't have any HID UPS by hand to verify, but I'd be
surprised if they would advertise remote wakeup capability ... ?


Looks like mine does..
[...]
 idVendor   0x051d American Power Conversion
 idProduct  0x0002 Back-UPS Pro 500/1000/1500


*notes to self to send pci.ids patch again*


 bcdDevice1.06
 iManufacturer   3 APC
 iProduct1 Back-UPS ES 500 FW:801.e6.D USB FW:e6


Yup, I have one of those in my arsenal and see the same thing.


 iSerial 2 AB0530291763
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   34
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  0
   bmAttributes 0xe0
 Self Powered
 Remote Wakeup


I have reports of APC UPS remote wakeup working properly on recent 
PowerMac G5s running OS X, but was never able to duplicate that success 
on my cruddy old G3. I never figured out if it was a deficiency of the 
UPS, the G3, or the OS. So it is possible that with appropriate OS 
support this feature may actually work on certain UPSes (APC has a habit 
of messing up the firmware differently on each model, so it's likely 
hit-or-miss, but they are improving).


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [1/3] 2.6.23-rc1: known regressions with patches v3

2007-07-30 Thread Adam Kropelin

Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Here is a list of some known regressions in 2.6.23-rc1
> with patches available.

I don't know which list this belongs in (good: 2.6.20.6, bad 2.6.22.1),
but here's a clear regression with patch:

Subject : Edgeport UPS Monitoring Problems
References  : http://lkml.org/lkml/2007/7/27/334
Last known good : 2.6.20.6
Submitter   : Nick Pasich <[EMAIL PROTECTED]>
Caused-By   : 
Handled-By      : Adam Kropelin <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/7/29/164
Status  : patch available

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [1/3] 2.6.23-rc1: known regressions with patches v3

2007-07-30 Thread Adam Kropelin

Michal Piotrowski [EMAIL PROTECTED] wrote:
 Here is a list of some known regressions in 2.6.23-rc1
 with patches available.

I don't know which list this belongs in (good: 2.6.20.6, bad 2.6.22.1),
but here's a clear regression with patch:

Subject : Edgeport UPS Monitoring Problems
References  : http://lkml.org/lkml/2007/7/27/334
Last known good : 2.6.20.6
Submitter   : Nick Pasich [EMAIL PROTECTED]
Caused-By   : 
Handled-By  : Adam Kropelin [EMAIL PROTECTED]
Patch   : http://lkml.org/lkml/2007/7/29/164
Status  : patch available

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] usb-serial: Fix edgeport regression on non-EPiC devices

2007-07-29 Thread Adam Kropelin

Fix serious regression on non-EPiC edgeport usb-serial devices. Baud 
rate and MCR/LCR registers are not being written on these models due 
to apparent copy-n-paste errors introduced with EPiC support.

Failure reported by Nick Pasich <[EMAIL PROTECTED]>.

Signed-off-by: Adam Kropelin <[EMAIL PROTECTED]>

--
Assuming this is a right and proper fix, it should go in the -stable
tree ASAP.

--- linux-2.6.22.1/drivers/usb/serial/io_edgeport.c 2007-07-10 
14:56:30.0 -0400
+++ linux-2.6.22.1.new/drivers/usb/serial/io_edgeport.c 2007-07-29 
09:45:18.0 -0400
@@ -2366,9 +2366,8 @@
int status;
unsigned char number = edge_port->port->number - 
edge_port->port->serial->minor;
 
-   if ((!edge_serial->is_epic) ||
-   ((edge_serial->is_epic) &&
-(!edge_serial->epic_descriptor.Supports.IOSPSetBaudRate))) {
+   if (edge_serial->is_epic &&
+   !edge_serial->epic_descriptor.Supports.IOSPSetBaudRate) {
dbg("SendCmdWriteBaudRate - NOT Setting baud rate for port = 
%d, baud = %d",
edge_port->port->number, baudRate);
return 0;
@@ -2461,18 +2460,16 @@
 
dbg("%s - write to %s register 0x%02x", (regNum == MCR) ? "MCR" : 
"LCR", __FUNCTION__, regValue);
 
-   if ((!edge_serial->is_epic) ||
-   ((edge_serial->is_epic) &&
-(!edge_serial->epic_descriptor.Supports.IOSPWriteMCR) &&
-(regNum == MCR))) {
+   if (edge_serial->is_epic &&
+   !edge_serial->epic_descriptor.Supports.IOSPWriteMCR &&
+   regNum == MCR) {
dbg("SendCmdWriteUartReg - Not writing to MCR Register");
return 0;
}
 
-   if ((!edge_serial->is_epic) ||
-   ((edge_serial->is_epic) &&
-(!edge_serial->epic_descriptor.Supports.IOSPWriteLCR) &&
-(regNum == LCR))) {
+   if (edge_serial->is_epic &&
+   !edge_serial->epic_descriptor.Supports.IOSPWriteLCR &&
+   regNum == LCR) {
dbg ("SendCmdWriteUartReg - Not writing to LCR Register");
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] Edgeport UPS Monitoring Problems

2007-07-29 Thread Adam Kropelin


From: "Nick Pasich" <[EMAIL PROTECTED]>

Here's the dmesg output ..

[...]
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: LCR - 
write to send_cmd_write_uart_register register 0x03
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: MCR - 
write to send_cmd_write_uart_register register 0x0b
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
change_port_settings - baud rate = 9600
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteBaudRate - NOT Setting baud rate for port = 0, baud = 9600


Yup, there's what I expected. Not setting the baud rate and not writing 
status registers is unlikely to produce working results. This 9600 must 
be the default setting being applied.


Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: MCR - 
write to send_cmd_write_uart_register register 0x0b
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
change_port_settings - baud rate = 2400
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteBaudRate - NOT Setting baud rate for port = 0, baud = 2400


Here's apcupsd trying to set 2400 baud.

Please try the attached patch (against 2.6.22.1). This will allow 
writing to the baud rate and MCR/LCR registers on non-EPIC adapters. I 
suspect the previous code was a copy-paste error.


--Adam


usb-serial-edgeport-non-epic-baud-rate-fix.patch
Description: Binary data

Re: [linux-usb-devel] Edgeport UPS Monitoring Problems

2007-07-29 Thread Adam Kropelin


From: Nick Pasich [EMAIL PROTECTED]

Here's the dmesg output ..

[...]
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: LCR - 
write to send_cmd_write_uart_register register 0x03
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: MCR - 
write to send_cmd_write_uart_register register 0x0b
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
change_port_settings - baud rate = 9600
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteBaudRate - NOT Setting baud rate for port = 0, baud = 9600


Yup, there's what I expected. Not setting the baud rate and not writing 
status registers is unlikely to produce working results. This 9600 must 
be the default setting being applied.


Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: MCR - 
write to send_cmd_write_uart_register register 0x0b
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteUartReg - Not writing to MCR Register
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
change_port_settings - baud rate = 2400
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: 
SendCmdWriteBaudRate - NOT Setting baud rate for port = 0, baud = 2400


Here's apcupsd trying to set 2400 baud.

Please try the attached patch (against 2.6.22.1). This will allow 
writing to the baud rate and MCR/LCR registers on non-EPIC adapters. I 
suspect the previous code was a copy-paste error.


--Adam


usb-serial-edgeport-non-epic-baud-rate-fix.patch
Description: Binary data

[PATCH] usb-serial: Fix edgeport regression on non-EPiC devices

2007-07-29 Thread Adam Kropelin

Fix serious regression on non-EPiC edgeport usb-serial devices. Baud 
rate and MCR/LCR registers are not being written on these models due 
to apparent copy-n-paste errors introduced with EPiC support.

Failure reported by Nick Pasich [EMAIL PROTECTED].

Signed-off-by: Adam Kropelin [EMAIL PROTECTED]

--
Assuming this is a right and proper fix, it should go in the -stable
tree ASAP.

--- linux-2.6.22.1/drivers/usb/serial/io_edgeport.c 2007-07-10 
14:56:30.0 -0400
+++ linux-2.6.22.1.new/drivers/usb/serial/io_edgeport.c 2007-07-29 
09:45:18.0 -0400
@@ -2366,9 +2366,8 @@
int status;
unsigned char number = edge_port-port-number - 
edge_port-port-serial-minor;
 
-   if ((!edge_serial-is_epic) ||
-   ((edge_serial-is_epic) 
-(!edge_serial-epic_descriptor.Supports.IOSPSetBaudRate))) {
+   if (edge_serial-is_epic 
+   !edge_serial-epic_descriptor.Supports.IOSPSetBaudRate) {
dbg(SendCmdWriteBaudRate - NOT Setting baud rate for port = 
%d, baud = %d,
edge_port-port-number, baudRate);
return 0;
@@ -2461,18 +2460,16 @@
 
dbg(%s - write to %s register 0x%02x, (regNum == MCR) ? MCR : 
LCR, __FUNCTION__, regValue);
 
-   if ((!edge_serial-is_epic) ||
-   ((edge_serial-is_epic) 
-(!edge_serial-epic_descriptor.Supports.IOSPWriteMCR) 
-(regNum == MCR))) {
+   if (edge_serial-is_epic 
+   !edge_serial-epic_descriptor.Supports.IOSPWriteMCR 
+   regNum == MCR) {
dbg(SendCmdWriteUartReg - Not writing to MCR Register);
return 0;
}
 
-   if ((!edge_serial-is_epic) ||
-   ((edge_serial-is_epic) 
-(!edge_serial-epic_descriptor.Supports.IOSPWriteLCR) 
-(regNum == LCR))) {
+   if (edge_serial-is_epic 
+   !edge_serial-epic_descriptor.Supports.IOSPWriteLCR 
+   regNum == LCR) {
dbg (SendCmdWriteUartReg - Not writing to LCR Register);
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] Edgeport UPS Monitoring Problems

2007-07-28 Thread Adam Kropelin


Andrew Morton wrote:

On Fri, 27 Jul 2007 13:37:08 -0700
Nick Pasich <[EMAIL PROTECTED]> wrote:



Greg/Peter/Al,


added linux-usb-devel.


I've been using the edgeport 4 port USB to Serial Converter
to monitor APC Smart UPS's via apcupsd for quite awhile on
various Linux boxes.

I just upgraded to Kernel Version 2.6.22.1 from 2.6.20.6 on a
couple of systems and both the edgeports stopped communicating.

I tried applying various patches, "PATCH 026/149" and "PATCH 082/149"
and one by Alan Cox..  but they didn't fix the problem.

I copied the 2.6.20.6 edgeport module sources to the new
2.6.22.1 tree and everything works again.

  linux/drivers/usb/serial/io_edgeport.c
  linux/drivers/usb/serial/io_edgeport.h
  linux/drivers/usb/serial/io_edgeport.mod.c
  linux/drivers/usb/serial/io_tables.h


Straightforward regression, most serious.  Thanks for reporting it.


I don't know much of anything about usb-serial, but I'll take a whack at 
it. Could you enable debug for that driver, launch apcupsd, and report 
any intersting messages that show up in dmesg? I'd be especially 
interested in any "Not setting..." or "Not writing..." messages, because 
some critical-looking code for baud rate setting and similar became 
conditional in 2.6.22.1 whereas it was always executed before. Apcupsd 
is going to be rather unhappy if the baud rate doesn't change when it 
asks. The debug should show if the these operations are being ignored on 
your hw.


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] Edgeport UPS Monitoring Problems

2007-07-28 Thread Adam Kropelin


Andrew Morton wrote:

On Fri, 27 Jul 2007 13:37:08 -0700
Nick Pasich [EMAIL PROTECTED] wrote:



Greg/Peter/Al,


added linux-usb-devel.


I've been using the edgeport 4 port USB to Serial Converter
to monitor APC Smart UPS's via apcupsd for quite awhile on
various Linux boxes.

I just upgraded to Kernel Version 2.6.22.1 from 2.6.20.6 on a
couple of systems and both the edgeports stopped communicating.

I tried applying various patches, PATCH 026/149 and PATCH 082/149
and one by Alan Cox..  but they didn't fix the problem.

I copied the 2.6.20.6 edgeport module sources to the new
2.6.22.1 tree and everything works again.

  linux/drivers/usb/serial/io_edgeport.c
  linux/drivers/usb/serial/io_edgeport.h
  linux/drivers/usb/serial/io_edgeport.mod.c
  linux/drivers/usb/serial/io_tables.h


Straightforward regression, most serious.  Thanks for reporting it.


I don't know much of anything about usb-serial, but I'll take a whack at 
it. Could you enable debug for that driver, launch apcupsd, and report 
any intersting messages that show up in dmesg? I'd be especially 
interested in any Not setting... or Not writing... messages, because 
some critical-looking code for baud rate setting and similar became 
conditional in 2.6.22.1 whereas it was always executed before. Apcupsd 
is going to be rather unhappy if the baud rate doesn't change when it 
asks. The debug should show if the these operations are being ignored on 
your hw.


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC] HID bus design overview.

2007-04-05 Thread Adam Kropelin


Jiri Kosina wrote:

On Wed, 4 Apr 2007, Adam Kropelin wrote:

On Apcupsd we've recently introduced a libusb-based driver that does
all HID parsing in userspace. Not only does that free us from
hiddev, it also frees us from the umpteen other proprietary HID
interfaces across various platforms. Although the hiddev-based
driver is still the default for Linux platforms, I plan to change
that in the next major release and thus begin migrating folks off of
hiddev.


Great. Do you use libusb to obtain raw hid events?


We do, along with libusbhid from *BSD to handle report descriptor 
parsing and report field extraction/insertion.



Could you by any
chance look at current implementation of hidraw (it's in -mm or I can
send it to you as a separate patch) and check whether you have any
comments on this?


I pulled down 2.6.21-rc5-mm4 and took a look at hidraw. I like the 
simplicity of it for sure. One feature that seems to be missing is the 
ability to force an input report to be fetched via a control transfer. 
Several APC UPSes have the unfortunate tendency to change report values 
without sending an interrupt report to notify you, so you have to poll 
them occasionally. Also, how does one fetch string descriptors via 
hidraw?



It would be good if you could use hidraw rather
than reading raw usb data through libusb.


I have to admit I don't see much value in switching Apcupsd to hidraw 
rather than libusb. (I see lots of value switching it away from hiddev, 
though :) We need a HID engine in userspace to handle descriptor parsing 
with any non-hiddev solution. Plus, APC UPSes tend to have buggy HID 
implementations that require a bit of care to communicate with properly. 
Having an "intelligent" kernel layer in the middle tends to just get in 
the way (see the truncated report handling patch for hid-core I just 
sent).
But honestly, the deal-breaker is that with libusb I can hit Linux, all 
the *BSDs, Darwin, Solaris, and even Windows with a single userspace 
driver. That's just too valuable to ignore.


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC] HID bus design overview.

2007-04-05 Thread Adam Kropelin


Jiri Kosina wrote:

On Wed, 4 Apr 2007, Adam Kropelin wrote:

On Apcupsd we've recently introduced a libusb-based driver that does
all HID parsing in userspace. Not only does that free us from
hiddev, it also frees us from the umpteen other proprietary HID
interfaces across various platforms. Although the hiddev-based
driver is still the default for Linux platforms, I plan to change
that in the next major release and thus begin migrating folks off of
hiddev.


Great. Do you use libusb to obtain raw hid events?


We do, along with libusbhid from *BSD to handle report descriptor 
parsing and report field extraction/insertion.



Could you by any
chance look at current implementation of hidraw (it's in -mm or I can
send it to you as a separate patch) and check whether you have any
comments on this?


I pulled down 2.6.21-rc5-mm4 and took a look at hidraw. I like the 
simplicity of it for sure. One feature that seems to be missing is the 
ability to force an input report to be fetched via a control transfer. 
Several APC UPSes have the unfortunate tendency to change report values 
without sending an interrupt report to notify you, so you have to poll 
them occasionally. Also, how does one fetch string descriptors via 
hidraw?



It would be good if you could use hidraw rather
than reading raw usb data through libusb.


I have to admit I don't see much value in switching Apcupsd to hidraw 
rather than libusb. (I see lots of value switching it away from hiddev, 
though :) We need a HID engine in userspace to handle descriptor parsing 
with any non-hiddev solution. Plus, APC UPSes tend to have buggy HID 
implementations that require a bit of care to communicate with properly. 
Having an intelligent kernel layer in the middle tends to just get in 
the way (see the truncated report handling patch for hid-core I just 
sent).
But honestly, the deal-breaker is that with libusb I can hit Linux, all 
the *BSDs, Darwin, Solaris, and even Windows with a single userspace 
driver. That's just too valuable to ignore.


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC] HID bus design overview.

2007-04-04 Thread Adam Kropelin


Jiri Kosina wrote:

On Wed, 4 Apr 2007, Adam Kropelin wrote:


I apologize for picking up this thread late and asking what may be a
question with an obvious answer... Will hiddev still exist after
hidraw and the HID bus redesign work is done? I have a
widely-deployed userspace app that relies on hiddev, and I'm looking
for reassurance that it will still work as it always has...


Hi Adam,

hiddev will have to stay for quite some time, exactly because of
backward compatibility with userspace applications/drivers that use
it (I am not aware of many of them though, but apparently there are
some).


Apcupsd is the one on my mind, but I believe there are others.


I won't allow it to vanish, don't worry.


Thanks!


We just have to make sure that new users will use hidraw instead, as
it provides more flexibility for the user, is not dependent on the
underlying transport protocol, etc.


On Apcupsd we've recently introduced a libusb-based driver that does all 
HID parsing in userspace. Not only does that free us from hiddev, it 
also frees us from the umpteen other proprietary HID interfaces across 
various platforms. Although the hiddev-based driver is still the default 
for Linux platforms, I plan to change that in the next major release and 
thus begin migrating folks off of hiddev.


I appreciate your pledge to keep hiddev functioning in the mean time :)

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC] HID bus design overview.

2007-04-04 Thread Adam Kropelin


Jiri Kosina wrote:

On Tue, 3 Apr 2007, Li Yu wrote:


What's the position of hidraw? It only is used when all other driver
is not usable on some report? or, it should be stick every working
device.


Current implementation (as you can see it in -mm or in my hid.git
tree) is creating hidraw interface for just every HID
device/interface. But this will get changed before merge.

Passing just everything to hidraw is not a good option, as this could
lead to confusion and duplicating of input events (i.e. in-kernel hid
driver processes the report and generates input_event(), and also
userland driver obtains data from hidraw and generates input event
through uinput ... not good).


I apologize for picking up this thread late and asking what may be a 
question with an obvious answer...


Will hiddev still exist after hidraw and the HID bus redesign work is 
done? I have a widely-deployed userspace app that relies on hiddev, and 
I'm looking for reassurance that it will still work as it always has...


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC] HID bus design overview.

2007-04-04 Thread Adam Kropelin


Jiri Kosina wrote:

On Tue, 3 Apr 2007, Li Yu wrote:


What's the position of hidraw? It only is used when all other driver
is not usable on some report? or, it should be stick every working
device.


Current implementation (as you can see it in -mm or in my hid.git
tree) is creating hidraw interface for just every HID
device/interface. But this will get changed before merge.

Passing just everything to hidraw is not a good option, as this could
lead to confusion and duplicating of input events (i.e. in-kernel hid
driver processes the report and generates input_event(), and also
userland driver obtains data from hidraw and generates input event
through uinput ... not good).


I apologize for picking up this thread late and asking what may be a 
question with an obvious answer...


Will hiddev still exist after hidraw and the HID bus redesign work is 
done? I have a widely-deployed userspace app that relies on hiddev, and 
I'm looking for reassurance that it will still work as it always has...


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [RFC] HID bus design overview.

2007-04-04 Thread Adam Kropelin


Jiri Kosina wrote:

On Wed, 4 Apr 2007, Adam Kropelin wrote:


I apologize for picking up this thread late and asking what may be a
question with an obvious answer... Will hiddev still exist after
hidraw and the HID bus redesign work is done? I have a
widely-deployed userspace app that relies on hiddev, and I'm looking
for reassurance that it will still work as it always has...


Hi Adam,

hiddev will have to stay for quite some time, exactly because of
backward compatibility with userspace applications/drivers that use
it (I am not aware of many of them though, but apparently there are
some).


Apcupsd is the one on my mind, but I believe there are others.


I won't allow it to vanish, don't worry.


Thanks!


We just have to make sure that new users will use hidraw instead, as
it provides more flexibility for the user, is not dependent on the
underlying transport protocol, etc.


On Apcupsd we've recently introduced a libusb-based driver that does all 
HID parsing in userspace. Not only does that free us from hiddev, it 
also frees us from the umpteen other proprietary HID interfaces across 
various platforms. Although the hiddev-based driver is still the default 
for Linux platforms, I plan to change that in the next major release and 
thus begin migrating folks off of hiddev.


I appreciate your pledge to keep hiddev functioning in the mean time :)

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin


Eric W. Biederman wrote:

"Adam Kropelin" <[EMAIL PROTECTED]> writes:


Can I get the corresponding lspci -xxx output.  I suspect the BIOS
did not program the hypertransport MSI mapping capabilities
correctly. All it has to do is set the enable but still,
occasionally BIOS writers miss the most amazing things.


Here you go. This is from 2.6.20-rc7.


Thanks.  Conclusion.  I could not find bit 16 (the enable bit) set in
any of your hypertransport msi mapping capabilities.

So MSI interrupts won't work until someone enables your chipset
to transform them into hypertransport interrupts.


Naive question... Can the pci layer (or e1000) detect that MSI is not 
enabled in the hardware and avoid using it in that case? With the number 
of MSI problems showing up it seems risky to assume it's usable on any 
given platform without some sort of sanity check.


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin


Eric W. Biederman wrote:

Auke Kok <[EMAIL PROTECTED]> writes:


maybe I've been unclear, but here's how e1000 detects link changes:

1) by checking every 2 seconds in the watchdog by reading PHY
registers 2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register

if the link is down to start with, the watchdog will obviously spot
a 'link up' change since it doesn't use any interrupts.

The link interrupt (LSI) is a generic interrupt that comes over the
same vector (be it MSI or not) as RX interrupts, and in your case
doesn't arrive at all, which should be demonstrateable if you set
e.g. the watchdog interval to 30 seconds and unplug the cable - the
driver won't spot the link change until the watchdog fires a lot
later than you unplugged the cable.


The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link
status interrupts seem to work but rx/tx does not. A few more
details here:





Can I get the corresponding lspci -xxx output.  I suspect the BIOS
did not program the hypertransport MSI mapping capabilities correctly.
All it has to do is set the enable but still, occasionally BIOS
writers miss the most amazing things.


Here you go. This is from 2.6.20-rc7.

--Adam


lspci-2.6.20-rc7
Description: Binary data

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin

Auke Kok wrote:

Adam Kropelin wrote:

I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.

maybe I've been unclear, but here's how e1000 detects link changes:

1) by checking every 2 seconds in the watchdog by reading PHY
registers

That would explain why I see link status changes but 0 interrupt count
in /proc/interrupts. However, on >= 2.6.19 the link state never changes.
Ever. It's always down. On <= 2.6.18 the link state does change but with
0 interupt count.

2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register

if the link is down to start with, the watchdog will obviously spot a
'link up' change since it doesn't use any interrupts.

This does not seem to work on 2.6.19+. Unless the watchdog interval is
tens of minutes. I've waited at least 5 minutes and link never went up.

The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link
status interrupts seem to work but rx/tx does not. A few more
details here:

<http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450_name=linux_kernel>

I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report
back any variations in behavior I notice.

that would be a good start, but I still think that you might have a
broken bridge on that system. Anyway, thanks for digging into this.

Will continue to dig.

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin


Eric W. Biederman wrote:

Auke Kok <[EMAIL PROTECTED]> writes:

None of the MSI code in e1000 has changed significantly either. as
far as I can see, the msi code in e1000 has not changed since
2.6.18. Nonetheless there's no way I can debug any of this without a
system.
[...]
Perhaps Adam can git-bisect this issue? Adam?


Do we have any explanation about the weird /proc/interrupts output?
i.e. Multiple MSI irqs being assigned to the same card?

Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything
to do with the duplication in /proc/interrupts?

I can't see any way for a pci device that doesn't support msi-x to be
assigned multiple interrupts simultaneously.

I just skimmed through the code and there hasn't been any significant
generic MSI work since 2.6.19.

Did this device really work with MSI enabled in 2.6.19?


I've never had this device work 100% with MSI on any kernel version I've 
tested so far. But I'm not the original reporter of the problem, and I 
believe for him it was a true regression where a previous kernel wored 
correctly.


The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status 
interrupts seem to work but rx/tx does not. A few more details here:



I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report 
back any variations in behavior I notice.


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin

Eric W. Biederman wrote:

Auke Kok [EMAIL PROTECTED] writes:

None of the MSI code in e1000 has changed significantly either. as
far as I can see, the msi code in e1000 has not changed since
2.6.18. Nonetheless there's no way I can debug any of this without a
system.
[...]
Perhaps Adam can git-bisect this issue? Adam?

Do we have any explanation about the weird /proc/interrupts output?
i.e. Multiple MSI irqs being assigned to the same card?

Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything
to do with the duplication in /proc/interrupts?

I can't see any way for a pci device that doesn't support msi-x to be
assigned multiple interrupts simultaneously.

I just skimmed through the code and there hasn't been any significant
generic MSI work since 2.6.19.

Did this device really work with MSI enabled in 2.6.19?

I've never had this device work 100% with MSI on any kernel version I've
tested so far. But I'm not the original reporter of the problem, and I
believe for him it was a true regression where a previous kernel wored
correctly.

The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status
interrupts seem to work but rx/tx does not. A few more details here:

http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450db_name=linux_kernel

I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report
back any variations in behavior I notice.

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin

Auke Kok wrote:

Adam Kropelin wrote:

maybe I've been unclear, but here's how e1000 detects link changes:

1) by checking every 2 seconds in the watchdog by reading PHY
registers

That would explain why I see link status changes but 0 interrupt count
in /proc/interrupts. However, on = 2.6.19 the link state never changes.
Ever. It's always down. On = 2.6.18 the link state does change but with
0 interupt count.

2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register

if the link is down to start with, the watchdog will obviously spot a
'link up' change since it doesn't use any interrupts.

This does not seem to work on 2.6.19+. Unless the watchdog interval is
tens of minutes. I've waited at least 5 minutes and link never went up.

The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link
status interrupts seem to work but rx/tx does not. A few more
details here:

http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450db_name=linux_kernel

I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report
back any variations in behavior I notice.

that would be a good start, but I still think that you might have a
broken bridge on that system. Anyway, thanks for digging into this.

Will continue to dig.

--Adam

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin


Eric W. Biederman wrote:

Auke Kok [EMAIL PROTECTED] writes:


maybe I've been unclear, but here's how e1000 detects link changes:

1) by checking every 2 seconds in the watchdog by reading PHY
registers 2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register

if the link is down to start with, the watchdog will obviously spot
a 'link up' change since it doesn't use any interrupts.

The link interrupt (LSI) is a generic interrupt that comes over the
same vector (be it MSI or not) as RX interrupts, and in your case
doesn't arrive at all, which should be demonstrateable if you set
e.g. the watchdog interval to 30 seconds and unplug the cable - the
driver won't spot the link change until the watchdog fires a lot
later than you unplugged the cable.


The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link
status interrupts seem to work but rx/tx does not. A few more
details here:


http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450db_name=linux_kernel


Can I get the corresponding lspci -xxx output.  I suspect the BIOS
did not program the hypertransport MSI mapping capabilities correctly.
All it has to do is set the enable but still, occasionally BIOS
writers miss the most amazing things.


Here you go. This is from 2.6.20-rc7.

--Adam


lspci-2.6.20-rc7
Description: Binary data

Re: 2.6.20-rc7: known regressions (v2) (part 1)

2007-02-03 Thread Adam Kropelin


Eric W. Biederman wrote:

Adam Kropelin [EMAIL PROTECTED] writes:


Can I get the corresponding lspci -xxx output.  I suspect the BIOS
did not program the hypertransport MSI mapping capabilities
correctly. All it has to do is set the enable but still,
occasionally BIOS writers miss the most amazing things.


Here you go. This is from 2.6.20-rc7.


Thanks.  Conclusion.  I could not find bit 16 (the enable bit) set in
any of your hypertransport msi mapping capabilities.

So MSI interrupts won't work until someone enables your chipset
to transform them into hypertransport interrupts.


Naive question... Can the pci layer (or e1000) detect that MSI is not 
enabled in the hardware and avoid using it in that case? With the number 
of MSI problems showing up it seems risky to assume it's usable on any 
given platform without some sort of sanity check.


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))

2007-02-02 Thread Adam Kropelin

On Fri, Feb 02, 2007 at 09:25:38AM -0800, Auke Kok wrote:
> Adrian Bunk wrote:
> > On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote:
> >> (cc: list trimmed and thread moved to linux-pci)
> >>
> >> I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 
> >> unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that 
> >> the PHY state is correct, it's just that the interrupt is not getting 
> >> thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok 
> >> with MSI enabled (link status responds appropriately) but packet tx 
> >> fails with timeout errors, implying that perhaps MAC interrupts are not 
> >> arriving.
> >>
> >> I've attached the contents dmesg, 'lspci -vvv', and 'cat 
> >> /proc/interrupts' from 2.6.20-rc5.
> >>
> >> This is an nForce 430 based chipset on a Dell E521 which has had 
> >> interrupt routing issues before. Prior to 2.6.19 it had to be booted 
> >> with 'noapic' in order to come up at all. It also had USB lockup 
> >> problems until I applied the latest BIOS update (v1.1.4). So a BIOS 
> >> interrupt routing bug with MSI is not out of the question.
> >>
> >> I'm happy to gather more data or run tests...
> > 
> > Was this regression fixed by Eric's patch that is included in -rc7?
> 
> no, this is a different issue afaics. Eric's patch solves a msi vector leak 
> where MSI's were no longer recovered after all 256 of them were handed out. 
> The 
> issue here seems to be a very different regression (no vector at all or 
> vector 
> not setup correctly to begin with).
> 
> I do suggest re-testing the issue with 2.6.20rc7, but it's unlikely it fixes 
> the 
> problem for Adam.

Your thought is correct: 2.6.20-rc7 still fails.

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))

2007-02-02 Thread Adam Kropelin

On Fri, Feb 02, 2007 at 09:25:38AM -0800, Auke Kok wrote:
 Adrian Bunk wrote:
  On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote:
  (cc: list trimmed and thread moved to linux-pci)
 
  I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 
  unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that 
  the PHY state is correct, it's just that the interrupt is not getting 
  thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok 
  with MSI enabled (link status responds appropriately) but packet tx 
  fails with timeout errors, implying that perhaps MAC interrupts are not 
  arriving.
 
  I've attached the contents dmesg, 'lspci -vvv', and 'cat 
  /proc/interrupts' from 2.6.20-rc5.
 
  This is an nForce 430 based chipset on a Dell E521 which has had 
  interrupt routing issues before. Prior to 2.6.19 it had to be booted 
  with 'noapic' in order to come up at all. It also had USB lockup 
  problems until I applied the latest BIOS update (v1.1.4). So a BIOS 
  interrupt routing bug with MSI is not out of the question.
 
  I'm happy to gather more data or run tests...
  
  Was this regression fixed by Eric's patch that is included in -rc7?
 
 no, this is a different issue afaics. Eric's patch solves a msi vector leak 
 where MSI's were no longer recovered after all 256 of them were handed out. 
 The 
 issue here seems to be a very different regression (no vector at all or 
 vector 
 not setup correctly to begin with).
 
 I do suggest re-testing the issue with 2.6.20rc7, but it's unlikely it fixes 
 the 
 problem for Adam.

Your thought is correct: 2.6.20-rc7 still fails.

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))

2007-01-20 Thread Adam Kropelin


Adam Kropelin wrote:

I've attached the contents dmesg, 'lspci -vvv', and 'cat
/proc/interrupts' from 2.6.20-rc5.


Actually attached this time.

--Adam


proc-irq-2.6.20-rc5
Description: Binary data


dmesg-2.6.20-rc5
Description: Binary data


lspci-2.6.20-rc5
Description: Binary data

MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))

2007-01-20 Thread Adam Kropelin


(cc: list trimmed and thread moved to linux-pci)

I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 
unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that 
the PHY state is correct, it's just that the interrupt is not getting 
thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok 
with MSI enabled (link status responds appropriately) but packet tx 
fails with timeout errors, implying that perhaps MAC interrupts are not 
arriving.


I've attached the contents dmesg, 'lspci -vvv', and 'cat 
/proc/interrupts' from 2.6.20-rc5.


This is an nForce 430 based chipset on a Dell E521 which has had 
interrupt routing issues before. Prior to 2.6.19 it had to be booted 
with 'noapic' in order to come up at all. It also had USB lockup 
problems until I applied the latest BIOS update (v1.1.4). So a BIOS 
interrupt routing bug with MSI is not out of the question.


I'm happy to gather more data or run tests...

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))

2007-01-20 Thread Adam Kropelin


(cc: list trimmed and thread moved to linux-pci)

I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 
unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that 
the PHY state is correct, it's just that the interrupt is not getting 
thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok 
with MSI enabled (link status responds appropriately) but packet tx 
fails with timeout errors, implying that perhaps MAC interrupts are not 
arriving.


I've attached the contents dmesg, 'lspci -vvv', and 'cat 
/proc/interrupts' from 2.6.20-rc5.


This is an nForce 430 based chipset on a Dell E521 which has had 
interrupt routing issues before. Prior to 2.6.19 it had to be booted 
with 'noapic' in order to come up at all. It also had USB lockup 
problems until I applied the latest BIOS update (v1.1.4). So a BIOS 
interrupt routing bug with MSI is not out of the question.


I'm happy to gather more data or run tests...

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))

2007-01-20 Thread Adam Kropelin


Adam Kropelin wrote:

I've attached the contents dmesg, 'lspci -vvv', and 'cat
/proc/interrupts' from 2.6.20-rc5.


Actually attached this time.

--Adam


proc-irq-2.6.20-rc5
Description: Binary data


dmesg-2.6.20-rc5
Description: Binary data


lspci-2.6.20-rc5
Description: Binary data

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

2007-01-19 Thread Adam Kropelin


Auke Kok wrote:

Adam Kropelin wrote:

I haven't been able to test rc5-mm yet because it won't boot on this
box. Applying git-e1000 directly to -rc4 or -rc5 results in a number
of rejects that I'm not sure how to fix. Some are obvious, but the
others I'm unsure of.


that won't work. You either need to start with 2.6.20-rc5 (and pull
the changes pending merge in netdev-2.6 from Jeff Garzik),


I thought that's what I was doing when I applied git-e1000 to 
2.6.20-rc5, but I guess not.



or start
with 2.6.20-rc4-mm1 and manually apply that patch I sent out on
monday. A different combination of either of these two will not work,
as they are completely different drivers.


I'll try to work something out.


can you include `ethtool ethX` output of the link down message and
`ethtool -d ethX` as well? I'll need to dig up an 82572 and see
what's up with that, I've not seen that problem before.


ethtool output attached.


More importantly, I suspect that *again* the issue is caused by
interrupts not arriving or getting lost.


Smells that way to me, too.


Can you try running with MSI disabled in your kernel config?


That fixes it! The link comes up and tx/rx works well. I get about 300 
Mbps using default iperf settings with a nearby windows box.



FYI the driver gives an interrupt to signal to the driver that link
is up. no interrupt == no link detected. So that explains the symptom.


Yep, makes sense. I've worked with a number of PHYs like that.

--Adam


ethtool-eth1
Description: Binary data


ethtool-d-eth1
Description: Binary data

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

2007-01-19 Thread Adam Kropelin


Auke Kok wrote:

Adam Kropelin wrote:

I am experiencing the no-link issue on a 82572EI single port copper
PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a
regression or not yet. Will test older kernel soon.

Can provide details/logs if you want 'em.


we've already established that Allen's issue is not due to the driver
and caused by interrupts being mal-assigned on his system, possibly a
pci subsystem bug. You also have a completely different board
(82572EI instead of 82571EB), so I'd like to see the usual debugging
info as well as hearing from you whether 2.6.19.any works correctly.


On 2.6.19 the link status is working (follows cable plug/unplug), but no 
tx or rx packets get thru. Attempts to transmit occasionally result in 
tx timed out errors in dmesg, but I cannot seem to generate these at 
will.


On 2.6.20-rc5, the link status does not work (link is always down), and 
as expected no tx or rx. No tx timed out errors this time, presumably 
because it thinks the link is down. Note that both the switch and the 
LEDs on the NIC  indicate a good 1000 Mbps link.


dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. 
The data from 2.6.19 is essentially the same.



On top of that I posted a patch to rc5-mm yesterday that fixes a few
significant bugs in the rc5-mm driver, so please apply that patch too
before trying, so we're not wasting our time finding old bugs ;)


I haven't been able to test rc5-mm yet because it won't boot on this 
box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of 
rejects that I'm not sure how to fix. Some are obvious, but the others 
I'm unsure of.


--Adam


dmesg-2.6.20-rc5
Description: Binary data


lspci-2.6.20-rc5
Description: Binary data


proc-irq-2.6.20-rc5
Description: Binary data

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

2007-01-19 Thread Adam Kropelin


Auke Kok wrote:

Adam Kropelin wrote:

I am experiencing the no-link issue on a 82572EI single port copper
PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a
regression or not yet. Will test older kernel soon.

Can provide details/logs if you want 'em.


we've already established that Allen's issue is not due to the driver
and caused by interrupts being mal-assigned on his system, possibly a
pci subsystem bug. You also have a completely different board
(82572EI instead of 82571EB), so I'd like to see the usual debugging
info as well as hearing from you whether 2.6.19.any works correctly.


On 2.6.19 the link status is working (follows cable plug/unplug), but no 
tx or rx packets get thru. Attempts to transmit occasionally result in 
tx timed out errors in dmesg, but I cannot seem to generate these at 
will.


On 2.6.20-rc5, the link status does not work (link is always down), and 
as expected no tx or rx. No tx timed out errors this time, presumably 
because it thinks the link is down. Note that both the switch and the 
LEDs on the NIC  indicate a good 1000 Mbps link.


dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. 
The data from 2.6.19 is essentially the same.



On top of that I posted a patch to rc5-mm yesterday that fixes a few
significant bugs in the rc5-mm driver, so please apply that patch too
before trying, so we're not wasting our time finding old bugs ;)


I haven't been able to test rc5-mm yet because it won't boot on this 
box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of 
rejects that I'm not sure how to fix. Some are obvious, but the others 
I'm unsure of.


--Adam


dmesg-2.6.20-rc5
Description: Binary data


lspci-2.6.20-rc5
Description: Binary data


proc-irq-2.6.20-rc5
Description: Binary data

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

2007-01-19 Thread Adam Kropelin


Auke Kok wrote:

Adam Kropelin wrote:

I haven't been able to test rc5-mm yet because it won't boot on this
box. Applying git-e1000 directly to -rc4 or -rc5 results in a number
of rejects that I'm not sure how to fix. Some are obvious, but the
others I'm unsure of.


that won't work. You either need to start with 2.6.20-rc5 (and pull
the changes pending merge in netdev-2.6 from Jeff Garzik),


I thought that's what I was doing when I applied git-e1000 to 
2.6.20-rc5, but I guess not.



or start
with 2.6.20-rc4-mm1 and manually apply that patch I sent out on
monday. A different combination of either of these two will not work,
as they are completely different drivers.


I'll try to work something out.


can you include `ethtool ethX` output of the link down message and
`ethtool -d ethX` as well? I'll need to dig up an 82572 and see
what's up with that, I've not seen that problem before.


ethtool output attached.


More importantly, I suspect that *again* the issue is caused by
interrupts not arriving or getting lost.


Smells that way to me, too.


Can you try running with MSI disabled in your kernel config?


That fixes it! The link comes up and tx/rx works well. I get about 300 
Mbps using default iperf settings with a nearby windows box.



FYI the driver gives an interrupt to signal to the driver that link
is up. no interrupt == no link detected. So that explains the symptom.


Yep, makes sense. I've worked with a number of PHYs like that.

--Adam


ethtool-eth1
Description: Binary data


ethtool-d-eth1
Description: Binary data

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

2007-01-17 Thread Adam Kropelin

> Allen Parker wrote:
>> Allen Parker wrote:
>>>  From what I've been able to gather, other Intel Pro/1000 chipsets 
>>> work fine in 2.6.20-rc5. If the e1000 guys need any assistance 
>>> testing, I'll be more than happy to volunteer myself as a guinea pig 
>>> for patches.
>> 
>> I wasn't aware that I was supposed to post this as a regression, so 
>> changed the subject, hoping that someone will pick this up and run with 
>> it. Primary issue being that link is not seen on this chipset under 
>> 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig 
>> $eth up && ethtool $eth | grep link && ifconfig $eth down. Tested on 2 
>> machines with identical hardware.
>
> I asked Allen to report this here. I'm working on the issue as we speak
> but for now I'll treat the link issue as a known regression once I 
> confirm it. If others have seen it then I'd like to know ASAP of course

I am experiencing the no-link issue on a 82572EI single port copper
PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a
regression or not yet. Will test older kernel soon.

Can provide details/logs if you want 'em.

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

2007-01-17 Thread Adam Kropelin

 Allen Parker wrote:
 Allen Parker wrote:
  From what I've been able to gather, other Intel Pro/1000 chipsets 
 work fine in 2.6.20-rc5. If the e1000 guys need any assistance 
 testing, I'll be more than happy to volunteer myself as a guinea pig 
 for patches.
 
 I wasn't aware that I was supposed to post this as a regression, so 
 changed the subject, hoping that someone will pick this up and run with 
 it. Primary issue being that link is not seen on this chipset under 
 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig 
 $eth up  ethtool $eth | grep link  ifconfig $eth down. Tested on 2 
 machines with identical hardware.

 I asked Allen to report this here. I'm working on the issue as we speak
 but for now I'll treat the link issue as a known regression once I 
 confirm it. If others have seen it then I'd like to know ASAP of course

I am experiencing the no-link issue on a 82572EI single port copper
PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a
regression or not yet. Will test older kernel soon.

Can provide details/logs if you want 'em.

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/block/nbd.c: don't defer compile error to runtime

2005-09-02 Thread Adam Kropelin

Adrian Bunk wrote:
> If we can detect a problem at compile time, the compilation should
> fail.

[...] 

>   if (sizeof(struct nbd_request) != 28) {
> - printk(KERN_CRIT "nbd: sizeof nbd_request needs to be 28 in 
> order to work!\n" );
> - return -EIO;
> + extern void nbd_request_wrong_size(void);
> + nbd_request_wrong_size();

BUILD_BUG_ON(sizeof(struct nbd_request) != 28);

...perhaps?

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/block/nbd.c: don't defer compile error to runtime

2005-09-02 Thread Adam Kropelin

Adrian Bunk wrote:
 If we can detect a problem at compile time, the compilation should
 fail.

[...] 

   if (sizeof(struct nbd_request) != 28) {
 - printk(KERN_CRIT nbd: sizeof nbd_request needs to be 28 in 
 order to work!\n );
 - return -EIO;
 + extern void nbd_request_wrong_size(void);
 + nbd_request_wrong_size();

BUILD_BUG_ON(sizeof(struct nbd_request) != 28);

...perhaps?

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] hiddev: output reports are dropped when HIDIOCSREPORT is called in short succession

2005-08-22 Thread Adam Kropelin


Stefan Nickl wrote:

Hi,

when trying to make the hiddev driver issue several Set_Report control
transfers to a custom device with 2.6.13-rc6, only the first transfer
in a row is carried out, while others immediately following it are
silently dropped.

This happens where hid_submit_report() (in hid-core.c) tests for
HID_CTRL_RUNNING, which seems to be still set because the first
transfer is not finished yet.

As a workaround, inserting a delay between the two calls to
ioctl(HIDIOCSREPORT) in userspace "solves" the problem.
The straightforward fix is to add a call to hid_wait_io() to the
implementation of HIDIOCSREPORT (in hiddev.c), just like for
HIDIOCGREPORT. Works fine for me.


Yup, I've seen the same issue on the apcupsd project. I added the 
hid_wait_io() call to HIDIOCGREPORT a while back since it used to suffer 
from the same problem. I'd have no objection to making HIDIOCSREPORT 
synchronous as well.


--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] hiddev: output reports are dropped when HIDIOCSREPORT is called in short succession

2005-08-22 Thread Adam Kropelin


Stefan Nickl wrote:

Hi,

when trying to make the hiddev driver issue several Set_Report control
transfers to a custom device with 2.6.13-rc6, only the first transfer
in a row is carried out, while others immediately following it are
silently dropped.

This happens where hid_submit_report() (in hid-core.c) tests for
HID_CTRL_RUNNING, which seems to be still set because the first
transfer is not finished yet.

As a workaround, inserting a delay between the two calls to
ioctl(HIDIOCSREPORT) in userspace solves the problem.
The straightforward fix is to add a call to hid_wait_io() to the
implementation of HIDIOCSREPORT (in hiddev.c), just like for
HIDIOCGREPORT. Works fine for me.


Yup, I've seen the same issue on the apcupsd project. I added the 
hid_wait_io() call to HIDIOCGREPORT a while back since it used to suffer 
from the same problem. I'd have no objection to making HIDIOCSREPORT 
synchronous as well.


--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] inotify for 2.6.11

2005-04-05 Thread Adam Kropelin

I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.

To that end I sat down tonight a threw together a simple command line
interface. Before I tell you where the code is, please note that I wrote
it while half asleep and more than a little high on cough syrup, so it's
undoubtedly chock full of buffer overflows, infinite loops, segfaults,
and other gremlins just waiting to eat your data, so PLEASE FOR THE LOVE
OF MIKE don't use it on, around, under, or in the general vicinity of,
anything important.

http://www.kroptech.com/~adk0212/watchf.c

The basic usage is...

watchf [-i] [-e]  [-- ...>]  

-i says stay in an infinite loop, don't exit after one event
-e gives the list of events to wait for (see the code)
 is the file or directory to be watched
Everything after -- is taken as a command to run each time an
event ocurrs with any ocurrences of {} being replaced with the
name of the affected file, as returned in the inotify_event
structure.

So what's it good for? Well, besides making fun of my coding skills,
it can be used to watch a directory and run a command when something
changes. For example, a one-line auto-gzip daemon that will haul off and
gzip anything you drop into ./gzipme:

watchf -i -eWT gzipme -- gzip gzipme/{}

Where to go from here? The code is relatively half-baked at the moment,
but I imgaine this could be turned into a relatively useful generic
tool. For example, it should send the filename to stdout and return the
event mask when in single-shot mode. That would make it useful as part
of a longer pipeline.  You should be able to use it to wait for a specific
file to be created --although that will be interesting if one or more 
segments of the path don't exist yet.  Ultimately I'd like to get rid of
the  argument(s), but I can't think of any way to do it
that isn't going to end up missing events.

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] inotify for 2.6.11

2005-04-05 Thread Adam Kropelin

I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.

To that end I sat down tonight a threw together a simple command line
interface. Before I tell you where the code is, please note that I wrote
it while half asleep and more than a little high on cough syrup, so it's
undoubtedly chock full of buffer overflows, infinite loops, segfaults,
and other gremlins just waiting to eat your data, so PLEASE FOR THE LOVE
OF MIKE don't use it on, around, under, or in the general vicinity of,
anything important.

http://www.kroptech.com/~adk0212/watchf.c

The basic usage is...

watchf [-i] [-eevents] file-to-watch [-- command-to-run...]  

-i says stay in an infinite loop, don't exit after one event
-e gives the list of events to wait for (see the code)
file-to-watch is the file or directory to be watched
Everything after -- is taken as a command to run each time an
event ocurrs with any ocurrences of {} being replaced with the
name of the affected file, as returned in the inotify_event
structure.

So what's it good for? Well, besides making fun of my coding skills,
it can be used to watch a directory and run a command when something
changes. For example, a one-line auto-gzip daemon that will haul off and
gzip anything you drop into ./gzipme:

watchf -i -eWT gzipme -- gzip gzipme/{}

Where to go from here? The code is relatively half-baked at the moment,
but I imgaine this could be turned into a relatively useful generic
tool. For example, it should send the filename to stdout and return the
event mask when in single-shot mode. That would make it useful as part
of a longer pipeline.  You should be able to use it to wait for a specific
file to be created --although that will be interesting if one or more 
segments of the path don't exist yet.  Ultimately I'd like to get rid of
the command-to-run argument(s), but I can't think of any way to do it
that isn't going to end up missing events.

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFQ] Rules for accepting patches into the linux-releases tree

2005-03-06 Thread Adam Kropelin

Andres Salomon <[EMAIL PROTECTED]> wrote:
> On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
> > On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> >>  - It must fix a real bug that bothers people (not a, "This could be a
> >>problem..." type thing.)
>
> An obvious fix is an obvious fix.  It shouldn't matter whether people have
> triggered a bug or not; why discriminate?

Because the sucker tree is purposely driven by real bug reports, not by
developers who happen across a theoretical problem while traversing the
code. If users aren't hitting it today, the fix can wait for 2.6.n+1.

> >>  - It must fix a problem that causes a build error (but not for things
> >>marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
> >>  - No "theoretical race condition" issues, unless an explanation of how
> >>the race can be exploited.
>
> I disagree w/ this; if it's an obvious fix, there should be no need for
> this.  Either it's a race that is clearly incorrect (after tracing through
> the relevant code), or it's not.

The sucker tree is not a dumping ground for every fix under the sun
(even obvious ones). It's for solving problems hit by real users, right
now.

> >>  - It can not contain any "trivial" fixes in it (spelling changes,
> >>whitespace cleanups, etc.)
> 
> This and the "it must fix a problem" are basically saying the same
> thing.

No. There's an important distinction and the key word is "contain". This
rule specifically forbids patches that do fix a real problem but _also_
contain unrelated trivial changes. See "setup_per_zone_lowmem_reserve()
oops fix" for an example of a patch that could theoretically be rejected 
due to this rule.

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFQ] Rules for accepting patches into the linux-releases tree

2005-03-06 Thread Adam Kropelin

Andres Salomon [EMAIL PROTECTED] wrote:
 On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
  On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
   - It must fix a real bug that bothers people (not a, This could be a
 problem... type thing.)

 An obvious fix is an obvious fix.  It shouldn't matter whether people have
 triggered a bug or not; why discriminate?

Because the sucker tree is purposely driven by real bug reports, not by
developers who happen across a theoretical problem while traversing the
code. If users aren't hitting it today, the fix can wait for 2.6.n+1.

   - It must fix a problem that causes a build error (but not for things
 marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
   - No theoretical race condition issues, unless an explanation of how
 the race can be exploited.

 I disagree w/ this; if it's an obvious fix, there should be no need for
 this.  Either it's a race that is clearly incorrect (after tracing through
 the relevant code), or it's not.

The sucker tree is not a dumping ground for every fix under the sun
(even obvious ones). It's for solving problems hit by real users, right
now.

   - It can not contain any trivial fixes in it (spelling changes,
 whitespace cleanups, etc.)
 
 This and the it must fix a problem are basically saying the same
 thing.

No. There's an important distinction and the key word is contain. This
rule specifically forbids patches that do fix a real problem but _also_
contain unrelated trivial changes. See setup_per_zone_lowmem_reserve()
oops fix for an example of a patch that could theoretically be rejected 
due to this rule.

--Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Does kernel require IDE enabled in BIOS to access HD, FS errors?

2001-07-08 Thread Adam Kropelin


Jim Roland said:
>I expect someone will rebut my comments about the kernel (which is fine, I'm 
>not a Kernel hacker

Okay, I'll take the bait, but I'm not a kernel hacker, either, so someone 
should feel free to rebut *my* comments as well.

>but it is my understanding that the kernel uses your system BIOS for actual 
>reads/writes at the hardware level, 

No. There are many reasons this isn't done, but a big one is:

BIOS = real mode
Kernel = protected mode

The kernel makes use of some BIOS *tables* (which are coped to known 
locations before the Big Switch), but actual BIOS interrupt routines are used 
only during the early stages of boot. Aside from the RM/PM issue, the BIOS 
isn't used because it is 16-bit, slow, and generally buggy.

See Alan Cox's paper on kernel BIOS usage posted back on 6/22/01 for a nice 
discussion of what use the kernel has for the BIOS.

>When you turn BIOS to  the OS does what it can, but 
>the BIOS in your system *SHOULD* refuse to process the call, instead it's 
>doing the read/writes, but not the same way as if IDE was turned on. 

An interesting theory, but off the mark.

That said, I don't know what the Right Answer for Martin is, but here are a 
few ideas:

* I notice the boot log shows a CMD646 IDE controller. Make sure the CMD640 
bug-fix support is enabled in your kernel (assuming this applies to 64x 
chips). If you're using a vendor's kernel it almost certainly is already, but 
if you built your own, make sure.

* It is possible that when a drive is assigned in the BIOS, the BIOS will do 
some configuration of the controller or the drive itself which the kernel is 
not doing on its own. I don't know what the state of kernel support for that 
646 chipset is.

* That's a pretty old drive, so I wouldn't rule out hardware problems. 
Strange that it only fails when not configured in the BIOS, though.

Regards,
Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Does kernel require IDE enabled in BIOS to access HD, FS errors?

2001-07-08 Thread Adam Kropelin


Jim Roland said:
I expect someone will rebut my comments about the kernel (which is fine, I'm 
not a Kernel hacker

Okay, I'll take the bait, but I'm not a kernel hacker, either, so someone 
should feel free to rebut *my* comments as well.

but it is my understanding that the kernel uses your system BIOS for actual 
reads/writes at the hardware level, 

No. There are many reasons this isn't done, but a big one is:

BIOS = real mode
Kernel = protected mode

The kernel makes use of some BIOS *tables* (which are coped to known 
locations before the Big Switch), but actual BIOS interrupt routines are used 
only during the early stages of boot. Aside from the RM/PM issue, the BIOS 
isn't used because it is 16-bit, slow, and generally buggy.

See Alan Cox's paper on kernel BIOS usage posted back on 6/22/01 for a nice 
discussion of what use the kernel has for the BIOS.

When you turn BIOS to NONE the OS does what it can, but 
the BIOS in your system *SHOULD* refuse to process the call, instead it's 
doing the read/writes, but not the same way as if IDE was turned on. 

An interesting theory, but off the mark.

That said, I don't know what the Right Answer for Martin is, but here are a 
few ideas:

* I notice the boot log shows a CMD646 IDE controller. Make sure the CMD640 
bug-fix support is enabled in your kernel (assuming this applies to 64x 
chips). If you're using a vendor's kernel it almost certainly is already, but 
if you built your own, make sure.

* It is possible that when a drive is assigned in the BIOS, the BIOS will do 
some configuration of the controller or the drive itself which the kernel is 
not doing on its own. I don't know what the state of kernel support for that 
646 chipset is.

* That's a pretty old drive, so I wouldn't rule out hardware problems. 
Strange that it only fails when not configured in the BIOS, though.

Regards,
Adam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

48 matches

Mail list logo