Am Mittwoch, 14. März 2007 23:44 schrieb David Howells:
Pete Zaitcev [EMAIL PROTECTED] wrote:
I think he is concerned about CPU A executing an interrupt handler, its
stores getting stuck in its store buffer or its write-back cache, the IRQ
finished, IRQ get migrated to CPU B, CPU B taking
Am Donnerstag, 15. März 2007 09:16 schrieb Greg KH:
On Wed, Mar 14, 2007 at 08:44:22PM +0100, Oliver Neukum wrote:
It is called in interrupt and uses no locking. What happens if the next
irq is processed on another cpu? Is that cpu guaranteed to see the updates
to the incremented
Oliver Neukum wrote:
OK, thanks. I am relieved.
Should I add a section concerning this to Documentation?
Is that a trick question? :-)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay
Am Donnerstag, 15. März 2007 09:57 schrieb Robert Marquardt:
Oliver Neukum wrote:
OK, thanks. I am relieved.
Should I add a section concerning this to Documentation?
Is that a trick question? :-)
No.
Regards
Oliver
Oliver Neukum wrote:
OK, thanks. I am relieved.
Should I add a section concerning this to Documentation?
Is that a trick question? :-)
No.
Your question if it should be documented bears itself the answer.
Of course!
If an expert has doubts then lesser experts and common folk do not
with plain 2.6.20.2 I get events / called from udev for /proc/bus/usb devices.
with rsdl 0.30 added to the kernel I no longer get called for those devices
(but I do get called for the new /dev/usbdev devices - except that I can't use
them).
any idea why and what to do? might be related to a race
Andreas Jellinghaus [EMAIL PROTECTED] writes:
with plain 2.6.20.2 I get events / called from udev for /proc/bus/usb devices.
with rsdl 0.30 added to the kernel I no longer get called for those devices
(but I do get called for the new /dev/usbdev devices - except that I can't
use
them).
hi all,
i have sent u this mail once and
there is no answer, i have made a progress on testing gadgetfs on OMAP 5912 OSK.
i have made the following steps:
1. connect my pc to the OMAP kit using usb cable A-A.
2.load the omap_udc module by writting: insmod omap_udc.ko
3.i have made a directory
Am Donnerstag, 15. März 2007 10:39 schrieb Robert Marquardt:
Oliver Neukum wrote:
OK, thanks. I am relieved.
Should I add a section concerning this to Documentation?
Is that a trick question? :-)
No.
Your question if it should be documented bears itself the answer.
Of course!
Hi,
it seems to me that for several usb serial drivers it is currently
impossible to cleanly handle disconnect, because usb_serial_driver
lacks a needed method.
As we often discussed, before a disconnect handler may return, it has
to finish all IO to the device. That means that usb_kill_urb()
Hi,
I am looking at code in which an interrupt completion handler can either
a) resubmit itself
b) submit a control URB
the control URB will in turn submit the interrupt URB again.
It seems to me that usb_kill_urb() alone cannot be used to cancel IO
without a race condition, as the following
Oliver:
Suppose the superuser has suspended a USB device and disabled autoresume.
Then what should happen under the following circumstances?
1. The device's usbfs file is opened (or already was open
and now gets accessed).
2. The user writes to the
Hi list,
i do have an ugly problem. I have built yet another avr-software-usb based
device
to connect an c64 disk drive to usb to be able to read and write those old c64
disks
(see http://www.harbaum.org/till/xu1541).
Sowhere during development i recognized that there are things inside the
Am Donnerstag, 15. März 2007 14:31 schrieb Alan Stern:
Oliver:
Suppose the superuser has suspended a USB device and disabled autoresume.
Then what should happen under the following circumstances?
1. The device's usbfs file is opened (or already was open
and now gets
Hi,
this one is getting so large that I'd appreciate some early comments and
reviews. In fact, I don't like to make so many changes without a device
for testing. So please speak up if you can test.
This fixes:
- breaking DMA rules about buffers
- usage of _global_ variables to save a single
Hi,
io_edgeport is using a global variable without locking.
This is _the_ classical race condition. This patch switches to atomic_t.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/serial/io_edgeport.c 2007-03-12 19:31:50.0
On Thu, 15 Mar 2007, Oliver Neukum wrote:
Hi,
I am looking at code in which an interrupt completion handler can either
a) resubmit itself
b) submit a control URB
the control URB will in turn submit the interrupt URB again.
It seems to me that usb_kill_urb() alone cannot be used to
On Thu, 15 Mar 2007, Till Harbaum wrote:
Hi list,
i do have an ugly problem. I have built yet another avr-software-usb based
device
to connect an c64 disk drive to usb to be able to read and write those old
c64 disks
(see http://www.harbaum.org/till/xu1541).
Sowhere during
On Thu, 15 Mar 2007, Oliver Neukum wrote:
Am Donnerstag, 15. März 2007 14:31 schrieb Alan Stern:
Oliver:
Suppose the superuser has suspended a USB device and disabled autoresume.
Then what should happen under the following circumstances?
1. The device's usbfs file is opened
This email lists known regressions in Linus' tree compared to 2.6.20
with patches available.
If possible, the patches should be included in 2.6.21-rc4 for reducing
the number of known regressiond in -rc4 a little bit.
If you find your name in the Cc header, you are either submitter of one
of
Oliver Neukum [EMAIL PROTECTED] wrote:
+ (*) entering and returning from interrupt handlers implies a full barrier
That shouldn't really be under the MISCELLANEOUS FUNCTIONS subheading as
it's not precisely describing a callable function that has barrier effects.
Hmmm... also it isn't quite
Am Donnerstag, 15. März 2007 15:35 schrieb Alan Stern:
To get rid of those messages, all you need to do is turn off
CONFIG_USB_DEBUG.
Oops ... i just didn't expect debugging to be enabled in stock ubuntu
kernels ...
Sorry, i should have looked for that before asking.
Till
On Wednesday 23 August 2006 21:35 am, David Brownell wrote:
Both the UDC driver and gadgetfs are built as loadable modules. After
successfully loading these two modules, I was able to mount gadget fs by
doing mount -t gadgetfs gadgetfs /dev/gadget. However only my UDC
driver name ($CHIP?)
On Thu, 15 Mar 2007 14:15:14 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
completion handlers:
spin_lock(lock)
if (!flag)
usb_submit_urb([ab], GFP_ATOMIC);
spin_unlock(flag);
Well big DUH, you have to check for shutdown poisoning before
resubmitting.
-- Pete
On Thu, 15 Mar 2007 10:32:52 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
Comments? Should I add a warning to Documentation/URB.txt?
It wouldn't be a bad idea to do so.
I'm concerned that we'd try to document every derivative idea which
should be obvious to anyone who understands
On Fri, 09 Mar 2007 20:27:30 -0600, Bryan Headley [EMAIL PROTECTED] wrote:
+ /* We now will look for the evdev device which is mapped to
+ * the tablet. The partial name is kept in the link list of
+ * input_handles associated with this input device.
+ * What identifies an evdev
Pete Zaitcev wrote:
It's probably BIOS or ACPI. In theory, SMM should be unfazed by whatever
OS does, but in practice perhaps our timer programming does something
to it. But usually ACPI code is affected the most when HZ is bumped up,
because it runs in kernel mode and thus is a subject to
This patch (as870) adds a delay to ehci-hcd's bus_resume routine.
Apparently there are controllers and/or BIOSes out there which need
such a delay to get the ports back into their correct state. This
fixes Bugzilla #8190.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
David:
I'm a little
Am Donnerstag, 15. März 2007 19:39 schrieb Pete Zaitcev:
On Thu, 15 Mar 2007 14:15:14 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
completion handlers:
spin_lock(lock)
if (!flag)
usb_submit_urb([ab], GFP_ATOMIC);
spin_unlock(flag);
Well big DUH, you have to check for shutdown
Am Donnerstag, 15. März 2007 17:29 schrieb David Howells:
How about the following:
INTERRUPT HANDLING
--
Execution of the interrupt handler chain for an interrupt not bound to a CPU
is bounded by a lock/unlock at either side. Furthermore, recurrence of that
interrupt
Many thanks for the reply Alan!
Well I finally had a chance to compile debugfs and usbmon into my 2.6.20
kernel just now. I also took out my hack of
sd_read_write_protect_flag() in drivers/scsi/sd.c to reintroduce the
write protect problem. I left the device in
(added linux-usb-devel@lists.sourceforge.net to CC)
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
I have multiple AMD 64-bit servers in several configurations, with
several different motherboards, which fail to recognize a USB keyboard
when booted from a stock Linux kernel. They only
On 3/15/07, Jiri Kosina [EMAIL PROTECTED] wrote:
(added linux-usb-devel@lists.sourceforge.net to CC)
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
I have multiple AMD 64-bit servers in several configurations, with
several different motherboards, which fail to recognize a USB
On Thu, 15 Mar 2007, Jiri Kosina wrote:
(added linux-usb-devel@lists.sourceforge.net to CC)
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
I have multiple AMD 64-bit servers in several configurations, with
several different motherboards, which fail to recognize a USB keyboard
when
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
Ouch! I can't do anything by copy from a screen! There is no way to get
`dmesg` without the keyboard! That's why I sent a request to
linux-kernel, hoping that the problem would sound familiar. All I can do
is boot the system (off a
On Thu, 15 Mar 2007, Alan Stern wrote:
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
Ouch! I can't do anything by copy from a screen! There is no way to get
`dmesg` without the keyboard! That's why I sent a request to
linux-kernel, hoping that the problem would sound familiar. All I
On 3/15/07, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote:
echo Loading uhci-hcd.ko module
insmod /lib/uhci-hcd.ko
echo Loading ehci-hcd.ko module
insmod /lib/ehci-hcd.ko
I don't see you loading OHCI and I thought AMD boxes used that flavor.
echo Loading usbhid.ko module
insmod
On Thu, 15 Mar 2007, Dmitry Torokhov wrote:
On 3/15/07, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote:
echo Loading uhci-hcd.ko module
insmod /lib/uhci-hcd.ko
echo Loading ehci-hcd.ko module
insmod /lib/ehci-hcd.ko
I don't see you loading OHCI and I thought AMD boxes used that
Am Donnerstag, 15. März 2007 23:10 schrieb Greg KH:
On Thu, Mar 15, 2007 at 01:59:30PM +0100, Oliver Neukum wrote:
Hi,
it seems to me that for several usb serial drivers it is currently
impossible to cleanly handle disconnect, because usb_serial_driver
lacks a needed method.
As we
Am Donnerstag, 15. März 2007 23:10 schrieb Greg KH:
As we often discussed, before a disconnect handler may return, it has
to finish all IO to the device. That means that usb_kill_urb() has to be
called on all URBs that might be active.
The serial driver does kill all standard URBs
On Thursday 15 March 2007 11:01 am, Wael Adel wrote:
On Wednesday 23 August 2006 21:35 am, David Brownell wrote:
Both the UDC driver and gadgetfs are built as loadable modules. After
successfully loading these two modules, I was able to mount gadget fs by
doing mount -t gadgetfs gadgetfs
Am Freitag, 16. März 2007 00:02 schrieb Greg KH:
However, shouldn't we just be calling shutdown here instead? Lots of
Currently the locking is not good enough to call shutdown() so early.
It could be strengthened. Make your choice. I can and will do it
either way. Just the current
Hi,
product i'm talking about:
http://www.devolo.com/co_EN/produkte/dlan/mldlanduo.html
Introduction:
Due to some cabeling constrains, i decided connecting some clients over
powerline communication (PLC) to my network would be the solution to my
problems. Additional constrains (-EOUTOFSLOTS)
On Thu, 15 Mar 2007, Alan Stern wrote:
On Thu, 15 Mar 2007, Dmitry Torokhov wrote:
On 3/15/07, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote:
echo Loading uhci-hcd.ko module
insmod /lib/uhci-hcd.ko
echo Loading ehci-hcd.ko module
insmod /lib/ehci-hcd.ko
I don't see you loading OHCI
On Thu, 15 Mar 2007, Dmitry Torokhov wrote:
On 3/15/07, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote:
echo Loading uhci-hcd.ko module
insmod /lib/uhci-hcd.ko
echo Loading ehci-hcd.ko module
insmod /lib/ehci-hcd.ko
I don't see you loading OHCI and I thought AMD boxes used that flavor.
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
[...]
The initrd linuxrc file that loads the modules is here. One can see
the order in which the modules are loaded. We had to make our own shell
to replace 'nash' because the SCSI drivers spawned children that
confused nash with SIGCHLD
On Thu, 15 Mar 2007, Jiri Kosina wrote:
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
[...]
The initrd linuxrc file that loads the modules is here. One can see
the order in which the modules are loaded. We had to make our own shell
to replace 'nash' because the SCSI drivers spawned
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
Yes! I will try it in the morning. It's now past quitting time and,
following this thread, you will note that the ohci module needed to be
loaded for this AMD unit so the keyboard now works! I will remove the
Oh I see, looks like I have
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
It's not the same hardware and all the machines that I tried that
have keyboards end up WORKING with the USB keyboard as well! But
Dmitry Torokhov was right! I just burned a CD with all three modules,
and the keyboard works! I didn't bother
49 matches
Mail list logo
