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
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 var
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 n
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 gad
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 answ
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() has
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 ra
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 bConfigurationValu
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 c64'
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 dev
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
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 de
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
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 th
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 quit
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 ($C
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 b
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 identifie
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
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 co
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 ch
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
> in
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
drivers/usb/storage/unusual_devs.h
(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.
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
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 keyboa
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
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 fam
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"
> ins
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
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.
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 gadgetf
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
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) mad
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'
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 use
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 S
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
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 bot
49 matches
Mail list logo
