the CPU up from
power saving idle a lot more than needed...
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/usb/core/hcd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6.22-rc2/driver
On Mon, 2006-11-06 at 15:46 +0300, Andrey Borzenkov wrote:
> I presume this is lockdep; this looks initially truncated,
> unfortunately this
> is how it was stored in messages. I will try to get more complete
> output ig
> required.
the interesting bits are missing unfortunately (the first 10 l
On Tue, 2006-10-31 at 20:56 +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> that are not yet fixed in Linus' tree.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsyste
On Thu, 2006-07-13 at 13:12 +0530, [EMAIL PROTECTED] wrote:
> We've written a device driver in linux for a pcmcia card with usb and
> serial functionality. I need to test this driver on a dual core/SMP
> machine. We work on kernel 2.6.15.4. I have recompiled this kernel
> version on my dual core ma
> > tty_insert_flip_string() returns number of bytes it has actually
> > inserted, but I don't believe one can do much if it returns less than
> > has been requested as it means that we are out of kernel memory.
>
> Yes. I've been wondering if we should log the failure case somewhere,
> either as
t need discussing. Just a few remarks and questions:
>
> On 27.02.2006, Arjan van de Ven wrote:
> > as a general review remark: you seem to use a LOT of atomic variables.
> > This I think is not too good an approach in general, because you get
> > into all kinds of race situa
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
> The following patches add drivers for the Siemens Gigaset 3070 family of
> ISDN DECT PABXes connected via USB, either directly or over a DECT link
> using a Gigaset M105 or compatible DECT data adapter. The devices are
> integrated as ISDN
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
> + struct semaphore sem; /* locks this structure:
> + * connected is not changed,
> + * hardware_up is not changed,
> +
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
> + }
> +
> + spin_lock_irqsave(&cs->lock, flags);
> + ret = kmalloc(sizeof(struct at_state_t), GFP_ATOMIC);
> + if (ret) {
> + gigaset_at_init(ret, NULL, cs, cid);
>
if you move the kmalloc one
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
> +static inline void new_index(atomic_t *index, int max)
> +{
> + if (atomic_read(index) == max) //FIXME race?
> + atomic_set(index, 0);
> + else
> + atomic_inc(index);
> +}
yes.. that's a race.
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
> +#define IFNULL(a) \
> + if (unlikely(!(a)))
please please get rid of this!
first of all, gcc ALREADY treats null pointer checks as unlikely,
second of all this makes code entirely unreadable, so please just
use "if (!a)" where you
> reports than the usptream developers, yet we hear so little about it>
the number of quality reports (eg enough information to do anything)
isn't that high; Dave is pretty good in sending the good ones on, it
often takes time though to get all the basic info..
--
On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > >
> > > I think we can assume that it will be seen there. 2.6.16 is going
On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> "Brown, Len" <[EMAIL PROTECTED]> wrote:
> >
> > My point is that it that on the grand scale of bugs serious enough
> > to have an effect on the course of 2.6.16, this one doesn't qualify
> > unless the same issue is seen on other systems.
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
didn't this got nailed down to a 2.6.15 specific queueing bug, fixed in
2.6.16-rc ?
--
etfs_fill_super':
> > > drivers/usb/gadget/inode.c:2035: warning: passing arg 3 of
> > `gadgetfs_make_inode' discards qualifiers from pointer target type
> >
> > In current GIT trees that line seems to be several lines earlier in the
> > file, and
On Wed, 2005-12-07 at 11:01 -0500, Alan Stern wrote:
> On Wed, 7 Dec 2005, Arjan van de Ven wrote:
>
> > > On the other hand, Oliver needs to be careful about claiming too much.
> > > In
> > > general atomic_t operations _are_ superior to the spinlock approa
> > No they're not. Both are just about equally expensive cpu wise,
> > sometimes the atomic_t ones are a bit more expensive (like on parisc
> > architecture). But on x86 in either case it's a locked cycle, which is
> > just expensive no matter which side you flip the coin...
>
> But if a lock i
On Wed, 2005-12-07 at 16:37 +0100, Oliver Neukum wrote:
> Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven:
> > > On the other hand, Oliver needs to be careful about claiming too much.
> > > In
> > > general atomic_t operations _are_ superior to the
> On the other hand, Oliver needs to be careful about claiming too much. In
> general atomic_t operations _are_ superior to the spinlock approach.
No they're not. Both are just about equally expensive cpu wise,
sometimes the atomic_t ones are a bit more expensive (like on parisc
architecture).
On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote:
> On Wed, 07 Dec 2005 13:27:13 +0100
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> |
> | > Isn't it right? Is the URB write so fast that switching to atomic_t
> | > doesn't pay-off?
&g
> Isn't it right? Is the URB write so fast that switching to atomic_t
> doesn't pay-off?
an atomic_t access and a spinlock are basically the same price... so
what's the payoff ?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
On Tue, 2005-12-06 at 09:57 -0200, Luiz Fernando Capitulino wrote:
> Introduces URB write locking macros.
ugh.. WHY ?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJ
On Mon, 2005-11-14 at 18:37 +0100, Harald Welte wrote:
> Make usbdevice_fs.h (again) useable from userspace
>
> If we have CONFIG_COMPAT enabled, then userspace programs using
> usbdevice_fs.h won't compile anymore.
how does the userspace application set CONFIG_COMPAT??
--
On Tue, 2005-10-18 at 11:49 -0700, Pete Zaitcev wrote:
>
> The problem here is that compat_ptr does NOT turn user data pointer
> into a kernel pointer. It's still a user pointer, only sized
> differently. So, when you do set_fs(KERNEL_DS), this pointer
> is invalid (miraclously, it does work on A
On Tue, 2005-07-05 at 12:36 +0200, Duncan Sands wrote:
> > I wonder why the invocations of kmalloc are needed in these functions.
>
> Because some architectures can't do DMA to/from the stack.
doing dma to/from kmalloc also isn't too nice... should be using
dma_alloc_*() API I guess
-
26 matches
Mail list logo
