Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > 3. Make sure usbcore doesn't probe the devices in the wrong mode with the
> > option driver
>
> This fixes duplicat
Am Donnerstag, 29. November 2007 08:52:37 schrieb Pete Zaitcev:
> On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > > The problem stems from the fact that both option and us
Am Donnerstag, 29. November 2007 07:33:03 schrieb Johann Wilhelm:
> But in my opinion the the modul-load-order should be forced by udev...
> this should work and we only have 1 position to keep in mind if we eg.
> get a new E220, support for the E270 or something else...
No, udev cannot help h
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> The problem stems from the fact that both option and usb-storage can bind
> to the modem when in storage mode: the former binds because of the storage
> class, the latter binds because of VID/PID match. The modprobe loads both,
Isn'
Am Dienstag 27 November 2007 schrieb ming lei:
> It seems oom happenes when VM(page frame reclaim) try to reclaim much
> more memory by writing back dirty pages, but there is not enough ram
> for usb disk related driver to finish the writeback operation. (usb
> disk related driver: scsi_mod, usb
Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> I would like to know why this is not so, and if someone has a cleaner
> proposal than the "try spinlock" approach?
Keep the semaphore.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe lin
Am Mittwoch 21 November 2007 schrieb Laurent Pinchart:
> I like the RESET_RESUME quirk best. Adding a new quirk to the uvcvideo driver
> doesn't really make sense when the USB subsystem is already able to handle
> this situation.
Not the driver but teh system wide quirks table. We have to reset
Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > Which URB is usb_kill_urb() called for?
> >
>
> it's the usb_control_message which calls usb_kill_urb if I haven't got
> it wrong. (if you're looking for some other information please let me
> know)
> Although, I got a bit further with it
Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> > Do you know any good way for performing a softreset within the driver?
> > The video application should get a continuous datastream after
> > resuming the notebook, so the driver shouldn't be unloaded.
> > The driver also keeps a list of previo
Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> Hi,
>
> On Wed, 21 Nov 2007 15:37:20 +0100, "Markus Rechberger"
> <[EMAIL PROTECTED]> wrote:
> > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > it wrong. (if you're looking for some other information please let me
>
Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > > I'm looking at the linux uvc driver, and noticed after resuming my
> >
Am Freitag 16 November 2007 schrieb Maciej W. Rozycki:
> On Fri, 16 Nov 2007, Oliver Neukum wrote:
>
> > > > On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt
> > > > on 20
> > > > there's a spurious interrupt on 19.
Am Freitag 16 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:
>
> > On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
> > there's a spurious interrupt on 19. USB devices on bus of the controller on
&g
Am Donnerstag 15 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:
> > I am seeing an interrupt for an UHCI on #20 CPU1 also arriving on
> > #19 CPU0, triggering the spurious interrupt detection.
>
> Well, if you see spurious interrup
Am Donnerstag 15 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:
>
> > is there a way to so misprogramm an APIC that a physical interrupt results
> > in two interrupts delivered?
>
> Certainly. One possibility is to have multiple
Hi,
is there a way to so misprogramm an APIC that a physical interrupt results
in two interrupts delivered?
Regards
Oliver
-
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:/
Am Montag 12 November 2007 schrieb Adrian Bunk:
> On Mon, Nov 05, 2007 at 09:40:43PM +0100, Oliver Neukum wrote:
> > Am Montag 05 November 2007 schrieb Adrian Bunk:
> > > This patch containsthe following cleanups:
> > > - make the needlessly global send_data() stati
Am Dienstag 06 November 2007 schrieb David Griffith:
> On Mon, 5 Nov 2007, Andrew Morton wrote:
>
> > On Thu, 1 Nov 2007 10:20:24 -0700 (PDT) David Griffith <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Thu, 1 Nov 2007, Vitaliy Ivanov wrote:
> >
> > Lots of cc's added.
> >
> > > > David,
> > > >
>
Am Montag 05 November 2007 schrieb Adrian Bunk:
> This patch containsthe following cleanups:
> - make the needlessly global send_data() static
> - an author without anemail address is OK, not a FIXME
That should be up to the author. If he thinks it should be there it might
be worth a FIXME
> - di
Am Dienstag 30 Oktober 2007 schrieb Harald Dunkel:
> Is this anything to worry about? Please mail if I can help to track this
> down.
This is a known problem. A fix is in the queue.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Am Montag 29 Oktober 2007 schrieb Tilman Schmidt:
> From: Tilman Schmidt <[EMAIL PROTECTED]>
>
> Add basic suspend/resume support to the usb_gigaset driver.
>
> Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]>
> ---
>
> drivers/isdn/gigaset/usb-gigaset.c | 69
> +
Am Mittwoch 24 Oktober 2007 schrieb Pete Zaitcev:
> Oliver, thanks for the inftdata catch. I also fixed the sleep_on.
But you are leaving a function while still on a waitqueue left on the stack.
Here's a patch on top of yours.
Regards
Oliver
--- work/drivers/usb/mis
Am Dienstag 23 Oktober 2007 schrieb Pete Zaitcev:
> On Tue, 23 Oct 2007 11:38:37 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > + /* XXX Anchor these instead */
> > > + spin_lock_irqsave(&dev->buflock, flags);
Am Dienstag 23 Oktober 2007 schrieb Pete Zaitcev:
> Two main issues fixed here are:
> - An improper use of in-struct lock to protect an open count
> - Use of urb status for -EINPROGRESS
> + /* XXX Anchor these instead */
> + spin_lock_irqsave(&dev->buflock, flags);
> + if (!dev->read
Am Donnerstag 18 Oktober 2007 schrieb Adrian Bunk:
> The Coverity checker spotted that we have already oops'ed if "dev"
> was NULL in these places.
>
> Since "dev" being NULL isn't possible at these places this patch removes
> the NULL checks.
Looking good.
Regards
Olive
Am Donnerstag 18 Oktober 2007 schrieb Adrian Bunk:
> The Coverity checker spotted that we have already oops'ed if "dev"
> was NULL.
>
> Since "dev" being NULL doesn't seem to be possible here this patch
> removes the NULL check.
Looking good.
Regards
Oliver
-
To unsubsc
Am Mittwoch 17 Oktober 2007 schrieb Phil Lello:
> I've been looking into a problem with my HP ScanJet 5300C not being
> detected by the USB stack, with a 2.6.20 kernel.
This device is known to crash when string descriptors are requested.
The current kernel has a quirk entry for this device.
Hi,
I got the following report in syslog:
Oct 17 10:56:35 oenone kernel: =
Oct 17 10:56:35 oenone kernel: [ INFO: possible recursive locking detected ]
Oct 17 10:56:35 oenone kernel: 2.6.23-default #1
Oct 17 10:56:35 oenone kernel: -
Am Freitag 12 Oktober 2007 schrieb Frank Kingswood:
> Hallo!
>
> I haven't seen anything on linux.kernel about what the merge plans are
> for the USB subsystem going into 2.6.24.
>
> Should I be submitting my driver as a patch to linux.kernel or are Alan
> or Greg going to push their changes?
Am Dienstag 09 Oktober 2007 schrieb Lennart Sorensen:
> Now if you were trying to transfer a lot of data to the laptop, would it
> be more power efficient to do it at gigabit speeds so you can finish
> sooner and shut down the machine entirely, or to slow to 100mbit and
> take longer to do it, and
Am Dienstag 09 Oktober 2007 schrieb Pavel Machek:
> Question is, how to implement it correctly? Daemon that would watch
> data rates and switch speeds using mii-tool would be simple, but is
> that enough?
Do you only want to affect true ethernet devices this way? It seems
to me that the savings fo
Hi,
I am getting this warning compiling rc9:
CC [M] drivers/isdn/i4l/isdn_common.o
drivers/isdn/i4l/isdn_common.c: In function ‘isdn_write’:
drivers/isdn/i4l/isdn_common.c:990: warning: array subscript is above array
bounds
drivers/isdn/i4l/isdn_common.c: In function ‘isdn_read’:
drivers/isdn
Am Montag 01 Oktober 2007 schrieb Miguel:
> but only when I unplug and plug manually, the modem starts up ...
> Because of that i wanted to unplug/plug via scripting (software way)
You can use the bind & unbind attributes in sysfs.
Regards
Oliver
-
To unsubscribe from thi
The pwc driver is defficient in locking, which can trigger an oops
when disconnecting.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Regards
Oliver
---
--- a/drivers/media/video/pwc/pwc-if.c 2007-08-24 10:16:38.0 +0200
+++ b/drivers/media/video/pwc/pw
The pwc driver is defficient in locking, which can trigger an oops
when disconnecting.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Regards
Oliver
---
--- a/drivers/media/video/pwc/pwc-if.c 2007-08-24 10:16:38.0 +0200
+++ b/drivers/media/video/pwc/pw
Am Montag 24 September 2007 schrieb Hans de Goede:
> Oliver Neukum wrote:
> > Am Freitag 21 September 2007 schrieb Jiri Kosina:
> >> On Fri, 21 Sep 2007, Hans de Goede wrote:
> >>
> >>> Thats not what I had in mind, autosuspend doesn't work (presumabl
Am Freitag 21 September 2007 schrieb Jiri Kosina:
> On Fri, 21 Sep 2007, Hans de Goede wrote:
>
> > Thats not what I had in mind, autosuspend doesn't work (presumably
> > because hal keeps polling for media change) maybe I should fix hal to
> > not keep polling for devices which don't have remov
Am Freitag 21 September 2007 schrieb Hans de Goede:
> Thats not what I had in mind, autosuspend doesn't work (presumably because
> hal
> keeps polling for media change) maybe I should fix hal to not keep polling
> for
> devices which don't have removable media?
If you find a way to tell which
Am Freitag 21 September 2007 schrieb Werner Cornelius:
> Hello,
>
> attached you will find the patch against the 2.6.23-rc6-mm1
>
> Changed fetaures:
>
> 1. All baudrates possible (dynamic baudfactor calculation)
> 2. Added support of modem control and status lines.
Cool. Could you resend with
n good : ?
> > Submitter : Oliver Neukum <[EMAIL PROTECTED]>
> > Caused-By : ?
> > Handled-By : ?
> > Status : unknown
>
> I'm still waiting to hear from Oliver whether or not this is actually a
> regression.
OK, I've done tes
Am Dienstag 18 September 2007 schrieb Jan Kara:
> > Subject : umount triggers a warning in jfs and takes almost a minute
> > References : http://lkml.org/lkml/2007/9/4/73
> > Last known good : ?
> > Submitter : Oliver Neukum <[EMAI
Hi,
using jfs on a flash drive (which is a bit unusual: 2K sectors) unmounting
triggers a warning and takes 52 second, if I have used the filesystem. (ls -l)
is sufficient. This is 2.6.23-rc4 on x86_64.
mkfs.jfs version 1.1.11, 05-Jun-2006
Regards
Oliver
Sep 4 16:18:57
Am Montag 03 September 2007 schrieb Michal Piotrowski:
> Hi Alex,
>
> On 02/09/07, Alex Smith <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I found an old Philips Askey VC010 webcam and attempted to get it
> > working on Linux (latest git, x86_64).
>
> Is this a regression? Does 2.6.22 work fine?
2
Am Sonntag 02 September 2007 schrieb Alex Smith:
> Hi,
>
> I found an old Philips Askey VC010 webcam and attempted to get it
> working on Linux (latest git, x86_64). It worked fine, I could view
> the camera in mplayer. But, however, when I went to move the camera, I
> unplugged it and forgot to c
Am Freitag 31 August 2007 schrieben Sie:
> On Fri, Aug 31, 2007 at 10:37:28AM +0200, Oliver Neukum wrote:
> > Hi,
> >
> > I only touched sound/usb/usbaudio.c
> > Nevertheless the whole subtree und sound/ is recompiling. What's
> > happening?
>
> The
Am Freitag 31 August 2007 schrieb Jan Engelhardt:
> On Aug 31 2007 11:51, Oliver Neukum wrote:
> >Am Freitag 31 August 2007 schrieb Sam Ravnborg:
> >> On Fri, Aug 31, 2007 at 01:14:26PM +0400, Alexey Dobriyan wrote:
> >> > On 8/31/07, Oliver Neukum <[EMAIL P
Am Freitag 31 August 2007 schrieb Sam Ravnborg:
> On Fri, Aug 31, 2007 at 01:14:26PM +0400, Alexey Dobriyan wrote:
> > On 8/31/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > I only touched sound/usb/usbaudio.c
> > > Nevertheless the whole subtree
Hi,
I only touched sound/usb/usbaudio.c
Nevertheless the whole subtree und sound/ is recompiling. What's
happening?
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Am Mittwoch 29 August 2007 schrieb Hugh Dickins:
> On Wed, 29 Aug 2007, Oliver Neukum wrote:
> > Am Mittwoch 29 August 2007 schrieb Arjan van de Ven:
> > > Another question, if this is during system shutdown, maybe that's a
> > > valid case for flushing most of the
Am Mittwoch 29 August 2007 schrieb Arjan van de Ven:
> Another question, if this is during system shutdown, maybe that's a
> valid case for flushing most of the pagecache first (from userspace)
> since most of what's there won't be used again anyway. If that's enough
> to make this go faster...
Is
Am Freitag 24 August 2007 schrieb Alan Stern:
> On Fri, 24 Aug 2007, Oliver Neukum wrote:
>
> > This schedules the change via a workqueue, so you'll be reprobed. If you
> > fire of the first vendor command you are doing so before the configuration
> > is changed.
Am Freitag 24 August 2007 schrieb Greg KH:
Hi,
> +static int select_configuration(struct usb_device *udev)
> +{
> + char *dummy_buffer = kzalloc(2, GFP_KERNEL);
> + int retval;
> +
> + if (!dummy_buffer)
> + return -ENOMEM;
> +
> + dbg(&udev->dev, "Calling se
Am Dienstag 21 August 2007 schrieb Oliver Neukum:
> [ 60.756730] usb 1-9: usb auto-resume
> Did you hit a key at that time?
>
>
> It looks like your keyboard gets autosuspended. But how can that happen?
> Keyboards should never autosuspend, as they are always open.
>
Am Dienstag 21 August 2007 schrieb Florin Iucha:
> On Wed, Aug 15, 2007 at 04:58:33PM +0200, Jiri Kosina wrote:
> > On Wed, 15 Aug 2007, Florin Iucha wrote:
> >
> > > [See my message to Alan]: It happened twice, within 15 minutes of
> > > boot+login, with 2.6.23-rc3-$whatever . I does not happen
Am Montag 20 August 2007 schrieb Zhang Rui:
> Files name must be unique in the same directory.
>
> Bug is reported here:
> http://bugzilla.kernel.org/show_bug.cgi?id=8798
Then I'd say fix the callers. This will paper over bugs.
Regards
Oliver
-
To unsubscribe from this
Am Montag 20 August 2007 schrieb Jean Delvare:
> If I rmmod "ehci-hcd" then the power consumption is back to 69 W. This
> confirms that this is really USB-related. I have to admit that I did
> not expect an external drive to eat that much power from the system,
> especially when not used. I am told
Am Montag 20 August 2007 schrieb Michal Piotrowski:
> This patch (against 2.6.23-rc3-git2) disables auto-suspend for this device.
Why would you want that? Not every log that has "autosuspend" in it
is a power management quirk. These devices simply need a patch to
be recognised as rndis devices.
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
> On Tue, 14 Aug 2007 17:46:16 +0200
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Am Dienstag 14 August 2007 schrieb Paolo Ornati:
> > > Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage)
> >
>
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
> Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage)
Please try this patch.
Regards
Oliver
-
--- a/drivers/usb/core/quirks.c 2007-08-14 17:42:22.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-08-14 17:43:5
t is
> adapted from a patch by Oliver Neukum. Autosuspend is allowed except
> during LUN scanning, resets, and command execution.
>
>
> my USB photo-camera gets automagically disconnected before I can do
> anything with it ;)
>
hi,
I need vendor:product. Please pro
Am Sonntag 05 August 2007 schrieb Tino Keitel:
> On Thu, Jul 26, 2007 at 10:06:40 +0200, Oliver Neukum wrote:
> > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> > > On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote:
> > > > Am Mittwoch 25 Juli 2007 sch
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > Which is why I didn't suggest doing that, of course. The only
> > one making that kind of straw man argument seems to be you.
>
> But however you phrase it, that's effectively what it is. "Does your
> device work?" just makes users wonder wh
Am Freitag 03 August 2007 schrieb Dave Jones:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>
> > Kernel developers are a diverser lot than you think ;-)
> > We don't enable autosuspend in drivers we can't test, except where
> > the lack o
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote:
>
> > Seems to me it ought to be practical to organize a database that can
> > be consulted by an outcall from udev, disabling autosuspend on devices
> > which are known to be broke
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > Also, we have udev rules for SANE that disables their autosuspend
> > settings, which handles the majority of the devices we have seen with
> > problems.
>
> Several printers seem to have the issue as well, and the blacklist seems
> to contai
Am Dienstag 31 Juli 2007 schrieb Rafael J. Wysocki:
> Well, the people on linux-pm seem to agree that the .suspend() and .resume()
> callbacks are not suitable for runtime power management, so having them
> built without SUSPEND or HIBERNATION wouldn't be very useful. ;-)
These are what USB runti
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
> On 29/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > This patch makes sure we don't dereference a NULL pointer in
> > > drivers/net/usb/pegasus.c::write_bulk_c
Am Donnerstag 26 Juli 2007 schrieb Greg KH:
> Alan and Oliver, was this caused by the autosuspend changes for
> usb-storage?
The oops itself looks like refcounting. What caused the initial io error
does not become clear from the log. It is possible that the device cannot
stand suspension. But ther
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote:
> > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> > > Hi,
> > >
> > > I just tried 2.6.23-rc1 and shortly after the boot my e
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> Hi,
>
> I just tried 2.6.23-rc1 and shortly after the boot my external USB hard
> disk went mad.
>
> I all started with these kernel messages:
>
> kern.info: usb 1-6: USB disconnect, address 5
> kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 dr
> Clearly there's a bug in
> drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
> kref_put() while holding a spinlock.
As I was reminded, I polluted the namespace. Here's a better
version. Does it fix your problem?
Regards
Oliv
Am Montag 23 Juli 2007 schrieb Alan Stern:
> Now here's an idea which might work. Can we require every caller of
> device_add() to hold some existing device's semaphore? Normally it
> would be the semaphore of the new device's parent, but it could be a
> higher ancestor. There even could be a si
> Clearly there's a bug in
> drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
> kref_put() while holding a spinlock.
Yes, these functions need to sleep.
Does this work?
Regards
Oliver
---
--- a/drivers/usb/serial/usb-serial.c 2007-07-23 08:47:35.0
Am Samstag 21 Juli 2007 schrieb Alan Stern:
> On Fri, 20 Jul 2007, Oliver Neukum wrote:
>
> > > We already have a pre-suspend notification available for drivers that
> > > need to allocate large amounts of memory.
> >
> > Is that facility fine grained eno
Am Montag 23 Juli 2007 schrieb Miklos Szeredi:
> > The reason is that we want them to "park" in safe places, ie. where there
> > are no locks held etc. Thus, these safe places need to be chosen somehow
> > and since they are not marked throughout the code, we choose the obvious
> > one. :-)
>
> W
he code it also doesn't seem to have been intended to always
> return 0.
Coverity is right. The check for NULL is wrongly done and the error
return is lost.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- a/drivers/usb/serial/usb-s
Am Freitag 20 Juli 2007 schrieb Alan Stern:
> On Fri, 20 Jul 2007, Oliver Neukum wrote:
>
> > Am Freitag 20 Juli 2007 schrieb Alan Stern:
> > > Some drivers need the ability to schedule. Some will need the ability
> > > to allocate memory (although GFP_ATOMIC
Am Freitag 20 Juli 2007 schrieb Alan Stern:
> Some drivers need the ability to schedule. Some will need the ability
> to allocate memory (although GFP_ATOMIC is probably sufficient). Some
> will need timers to run.
Some will have to request firmware. It can add up to some megabytes.
In additio
Am Dienstag 17 Juli 2007 schrieb Joseph Fannin:
> On Tue, Jul 17, 2007 at 07:44:07AM +0200, Oliver Neukum wrote:
> >
> > If yoi want to go the kexec route to hibernation, the dumping kernel
> > would need to mount the filesystem to write to a file. Therefore the
> > susp
Am Dienstag 17 Juli 2007 schrieb Joseph Fannin:
> Why are all these workarounds preferred, instead of proper suspend
> support for swap files?
>
> IOW, what reasons are there to *not* support swap files, other than the
> hit-and-miss Linux suspend support?
If yoi want to go the kexec route to hib
Am Freitag 13 Juli 2007 schrieb Kevin Lloyd:
> +int sierra_probe(struct usb_interface *iface, const struct usb_device_id *id)
> +{
> + int result;
> + struct usb_device *udev;
> +
> + udev = usb_get_dev(interface_to_usbdev(iface));
> +
> + /* Check if in installer mode
Am Donnerstag, 12. Juli 2007 schrieb Kevin Lloyd:
> From: Kevin Lloyd <[EMAIL PROTECTED]>
>
> This patch adds compatibility with Sierra Wireless' new TRU-Install feature.
> Future devices that use this feature will not work unless this patch has been
> applied.
Is this some type of CD-ROM simul
Am Dienstag, 10. Juli 2007 schrieb Satyam Sharma:
> But, I'm not sure they'd be operating against a known target -- I don't
> really know what exactly would be hashed, but if it's kernel printk()
> messages (the format string, obviously), then please remember that
> new messages would get added all
Am Montag, 9. Juli 2007 schrieb Jeremy Maitin-Shepard:
> Oliver Neukum <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > Hm, once the new kernel is booted, this decision is irrevocable, isn't it?
> > Is there any way to deal with errors by handing control back?
>
Am Montag, 9. Juli 2007 schrieb Pavel Machek:
> Hi!
>
> > >> This approach eliminates the need for the freezer, as it would make
> > >> hibernate look a lot a bit like suspend to ram from the perspective of
> > >> the "old" kernel (the kernel being hibernated), as the hibernate
> > >> operation it
Am Montag, 9. Juli 2007 schrieb Miklos Szeredi:
> In that case the "we need suspend to be invisible to userspace" as a
> reason to use the freezer would also be moot, since if you don't
> schedule userspace after offlining the CPUs, it can't notice this.
After? Can you do the offlining atomically?
Am Montag, 9. Juli 2007 schrieb Benjamin Herrenschmidt:
> On Mon, 2007-07-09 at 08:47 +0200, Oliver Neukum wrote:
> > Am Sonntag, 8. Juli 2007 schrieb Benjamin Herrenschmidt:
> > > > But I'm not sure it's a good idea in the long run. Think of a printer
> > &
Am Montag, 9. Juli 2007 schrieb Kunai, Takashi:
> (b)printk hashes and (c)Format strings. (a) seems difficult to get
> supports from kernel developers and (c) lacks uniqueness of each
> message. Though (b) also lacks uniqueness, adding component id and/or
We have generators for hash functions that
Am Sonntag, 8. Juli 2007 schrieb Benjamin Herrenschmidt:
> Another issue that's been a problem forever with suspend is the
> synchronous request_firmware interface. Lots of drivers do that in
> resume() which will generally not work.
Unfortunately yes they do. We now have the notifier chains, whic
Am Sonntag, 8. Juli 2007 schrieb Benjamin Herrenschmidt:
> > But I'm not sure it's a good idea in the long run. Think of a printer
> > daemon, for example. It shouldn't have to experience unexpected I/O
> > problems merely because someone has decided to put the system to sleep.
>
> Why not ? P
Am Freitag, 6. Juli 2007 schrieb Oleg Nesterov:
> Rafael J. Wysocki wrote:
> >
> > This patch makes the freezer skip uninterruptible user space tasks (ie. such
> > that have an mm of their own) when counting the tasks to be frozen. As a
> > result, these tasks have the TIF_FREEZE and TIF_SIGPENDIN
Am Freitag, 6. Juli 2007 schrieb Benny Amorsen:
> >>>>> "ON" == Oliver Neukum <[EMAIL PROTECTED]> writes:
>
> ON> Because we will be unable to escape that job. Let's assume that we
> ON> remove the freezer from the STR path. The next complaint
Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> On Fri, 2007-07-06 at 09:13 +0200, Rafael J. Wysocki wrote:
> >
> > The only reason (I know of) why we don't handle uninterruptible tasks in the
> > freezer is that we're afraid of the suspend process deadlocking with an
> > uninterruptibl
Am Freitag, 6. Juli 2007 schrieb Miklos Szeredi:
> > > You're missing the point. I'm arguing that a sync from within the freezer
> > > should guarantee that there is no data loss.
> >
> > Well, it should, but it doesn't ...
> >
> > Moreover, if FUSE implements syncing, then the sync from within
Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> > Yes, fuse could handle being frozen there. However that would only
> > solve part of the problem: an operation waiting for a reply could be
> > holding a VFS mutex and some other task may be blocked on that mutex.
> >
> > How would you
Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
>
> > There is that.
> >
> > OK, bite the bullet. Tasks involved in fuse are special. Give them a flag
> > and teach the freezer to put them on ice only after all other task are
> > frozen. In a way they are kernel, there's no use denying t
Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> On Thu, 5 Jul 2007, Miklos Szeredi wrote:
>
> > I fear, that your efforts to "save" the freezer are in vain. It is
> > already moderately hackish with that PF_FREEZER_SKIP and the kernel
> > dotted randomly with try_to_freeze() calls, but adding b
Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> On Thu, 5 Jul 2007, Oliver Neukum wrote:
>
> > > Obviously. Â But I wasn't about the server trying to acquire a lock
> > > held by a client. Â I was talking about a client trying to acquire a
> > > lock hel
Am Donnerstag, 5. Juli 2007 schrieb Oliver Neukum:
> Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > Yes, fuse could handle being frozen there. However that would only
> > > > solve part of the problem: an operation waiting for a reply could be
> >
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > Yes, fuse could handle being frozen there. However that would only
> > > solve part of the problem: an operation waiting for a reply could be
> > > holding a VFS mutex and some other task may be blocked on that mutex.
> > >
> > > How would
701 - 800 of 1050 matches
Mail list logo
