* [PATCH 2/2] correct dev_alloc_skb kerneldoc
From: Christoph Hellwig @ 2006-07-07 9:09 UTC (permalink / raw)
To: davem; +Cc: netdev
dev_alloc_skb is designated for RX descriptors, not TX. (Some drivers
use it for the latter anyway, but that's a different story)
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/include/linux/skbuff.h
===================================================================
--- linux-2.6.orig/include/linux/skbuff.h 2006-07-07 11:05:30.000000000 +0200
+++ linux-2.6/include/linux/skbuff.h 2006-07-07 11:06:31.000000000 +0200
@@ -1067,7 +1067,7 @@
}
/**
- * __dev_alloc_skb - allocate an skbuff for sending
+ * __dev_alloc_skb - allocate an skbuff for receiving
* @length: length to allocate
* @gfp_mask: get_free_pages mask, passed to alloc_skb
*
@@ -1088,7 +1088,7 @@
}
/**
- * dev_alloc_skb - allocate an skbuff for sending
+ * dev_alloc_skb - allocate an skbuff for receiving
* @length: length to allocate
*
* Allocate a new &sk_buff and assign it a usage count of one. The
^ permalink raw reply
* Re: [Qemu-devel] Pentium D with guest Ubuntu 6.06 server kernel panic with kqemu
From: Joachim Henke @ 2006-07-07 9:06 UTC (permalink / raw)
To: qemu-devel; +Cc: R. Armiento
In-Reply-To: <44AD28AA.7050301@armiento.net>
Yes, this patch was included, but it doesn't solve that problem. As
this message [http://www.mail-archive.com/qemu-devel@nongnu.org/
msg03972.html] states, the 'monitor' and the 'mwait' instructions
have not been added. But your guest OS assumes them to be present,
because your host cpu has the MONITOR flag set in CPUID.
Jo.
R. Armiento wrote:
> The error looks very similar to the one reported here:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg03964.html
> But I believe that reported issue should not appear in recent qemu,
> since SSE3 is now emulated (right?). (At least the patch in the end
> of that thread seems to already be included in the sources?)
>
> So, my hypothesis is that there is some other feature that appears
> in my host CPUID, which the booting linux image tries to make use
> of, but which qemu does not emulate.
--
Joachim Henke
http://he-jo.net/
^ permalink raw reply
* Re: linux-2.6.17-mm6: strange kobject message
From: Arjan van de Ven @ 2006-07-07 9:07 UTC (permalink / raw)
To: Paul Drynoff; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060707125942.fe3d467b.pauldrynoff@gmail.com>
On Fri, 2006-07-07 at 12:59 +0400, Paul Drynoff wrote:
> Here is dmesg which I got during boot,
> the first part not interesting I already reported about it,
> and I don't remember one of two things: Arjan van de Ven's patch was
> lost or not good enough.
it didn't make -mm6, but got added later...
^ permalink raw reply
* Re: Areca driver recap + status
From: Andrew Morton @ 2006-07-07 9:04 UTC (permalink / raw)
To: erich
Cc: James.Bottomley, rdunlap, hch, brong, dax, linux-kernel,
linux-scsi, robm
In-Reply-To: <001601c6a1a1$34a17180$0132a8c0@erich2003>
On Fri, 7 Jul 2006 16:41:53 +0800
"erich" <erich@areca.com.tw> wrote:
> From: Erich Chen <erich@areca.com.tw>
>
> 1- fix sysfs has more than one value per file
> 2- PAE issues (cast of dma_addr_t to unsigned long)
> 3- unblock SYNCHRONIZE_CACHE
>
> Signed-off-by: Erich Chen <erich@areca.com.tw>
>
> Areca had tested its arcmsr linux raid driver on ppc machines G5 and it
> worked fine.
Thanks.
> +static ssize_t
> +arcmsr_sysfs_iop_message_clear(struct kobject *kobj, char *buf, loff_t off,
> + size_t count)
> +{
> + struct class_device *cdev = container_of(kobj,struct class_device,kobj);
> + struct Scsi_Host *host = class_to_shost(cdev);
> + struct AdapterControlBlock *acb = (struct AdapterControlBlock *) host->hostdata;
> + struct MessageUnit __iomem *reg = acb->pmu;
> + uint8_t *pQbuffer;
> +
> + if (!capable(CAP_SYS_ADMIN) || (count && off) == 0)
> + return 0;
That (count && off) == 0 looks odd. Are you sure that's what you meant to
do?
Also, a write() handler shouldn't return zero if it didn't write anything.
Some applications will see that the write() returned less than expected and
didn't return an error so they'll just loop around and try to write more
data. They'll hang up when writing to your sysfs file.
http://www.opengroup.org/onlinepubs/009695399/functions/write.html says
RETURN VALUE
Upon successful completion, write() and pwrite() shall return the
number of bytes actually written to the file associated with fildes.
This number shall never be greater than nbyte. Otherwise, -1 shall be
returned and errno set to indicate the error.
So you should return -EINVAL here, and perhaps -EACCES or -EPERM. Because
nothing was written.
^ permalink raw reply
* SIU_INT_IRQ4 in MPC 8260
From: jagannathanjay @ 2006-07-07 9:05 UTC (permalink / raw)
To: linuxppc-embedded
Hi all
I am trying to set up a interrupt handler for SIU_INT_IRQ4.
The target I am using is MPC 8260 , emmbedded planet Evaluation board.
The OS is Embedded Linux .
-------------------------------------------------------------------------
------------
void my_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
{
printk("*********** \n");
}
if( request_irq(SIU_INT_IRQ4,my_interrupt_handler,0,0,0) < 0)
{
printk("\n unable to register the interrupt handler \n");
}
-------------------------------------------------------------------------
------------
But my_interrupt_handler isn't getting called .
Can anyone help me to fix this problem
Regards
Jagan
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and
industry-leading spam and email virus protection.
^ permalink raw reply
* Re: snd-aoa: g5 tas codec problems
From: Johannes Berg @ 2006-07-07 9:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, alsa-devel
In-Reply-To: <1152262585.9862.61.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Fri, 2006-07-07 at 18:56 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-07-07 at 10:49 +0200, Johannes Berg wrote:
> > On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> > > Also, we should try
> > > (if not already the case) to cache our clock/i2s state so that
> > > subsequent prepare() don't try to change things that are already ok.
> >
> > I do that, the function reads the dws and sfr registers and exits early
> > if they match.
>
> Ok. Be careful that I've removed the initial init of TAS thinking we
> always get to clock restart to do it in prepare()... might need to be
> put back.
Oh yes, we do, wonder why it even worked then since most of the time
we'll be using whatever the firmware does (44.1KHz,16bit).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: snd-aoa: g5 tas codec problems
From: Johannes Berg @ 2006-07-07 9:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, alsa-devel
In-Reply-To: <1152262585.9862.61.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]
On Fri, 2006-07-07 at 18:56 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-07-07 at 10:49 +0200, Johannes Berg wrote:
> > On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> > > Also, we should try
> > > (if not already the case) to cache our clock/i2s state so that
> > > subsequent prepare() don't try to change things that are already ok.
> >
> > I do that, the function reads the dws and sfr registers and exits early
> > if they match.
>
> Ok. Be careful that I've removed the initial init of TAS thinking we
> always get to clock restart to do it in prepare()... might need to be
> put back.
Oh yes, we do, wonder why it even worked then since most of the time
we'll be using whatever the firmware does (44.1KHz,16bit).
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 299 bytes --]
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
^ permalink raw reply
* Re: Problem with suspend to RAM
From: Pavel Machek @ 2006-07-07 9:04 UTC (permalink / raw)
To: rasmit.ranjan; +Cc: linux-pm
In-Reply-To: <380D9721A8E2114485644D71E87C6AB2022138F8@PNE-HJN-MBX01.wipro.com>
Hi!
> I have some problem with suspend t RAM. I tried suspend to RAM
> with different laptops. I am using kernel 2.6.15.4.
>
> The problem is sometimes it works and sometimes it does not. Sometimes
> only the system suspends to RAM but does not resume. I read somewhere
> that suspend to RAM behaves in this way. It is not stable in the
> kernel. Is it so or is there something specific to do to make suspend
> to RAM work? Please suggest.
It is stable, but there are problems with video handling. see
suspend.sf.net. Any problem outside video handling should go to kernel
bugzilla.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [Xenomai-core] [RFC, PATCH] per-thread exec-time stats
From: Jan Kiszka @ 2006-07-07 9:03 UTC (permalink / raw)
To: rpm; +Cc: xenomai-core
In-Reply-To: <1152262158.5017.22.camel@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 3722 bytes --]
Philippe Gerum wrote:
> On Fri, 2006-07-07 at 10:09 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Thu, 2006-07-06 at 18:36 +0200, Jan Kiszka wrote:
>>>> Jan Kiszka wrote:
>>>>> Philippe Gerum wrote:
>>>>>> On Thu, 2006-07-06 at 17:09 +0200, Jan Kiszka wrote:
>>>>>>>> We could do that from the current loop below, given that the
>>>>>>>> accumulation routine is changed to use thread->sched implicitely.
>>>>>>> The idea is avoid adding even further load to the nklock-protected loop.
>>>>>>> And we only update the current thread, not each and every.
>>>>>>>
>>>>>> Yes, but why? I mean, accumulated time so far remains significant even
>>>>>> for non-running threads.
>>>>> Update must only happen for the currently running thread on each cpu,
>>>>> otherwise you skew the stats up.
>>>>>
>>>>>
>>>>> But looking at the whole code in stat_seq_open() again, I now wonder if
>>>>> that whole routine isn't
>>>>>
>>>>> a) fragile on task removal and
>>>>> b) still poorly scaling.
>>>>>
>>>>> The thread name is only copied by reference, a disappearing instance my
>>>>> cause troubles on printing it. And, instead of holding the lock all the
>>>>> time, shouldn't we better
>>>>>
>>>>> 1. pick some element from the queue and mark it somehow
>>>>> in-use under lock
>>>>> 2. print or copy the entry
>>>>> 3. reacquire the lock to proceed to the next one - after checking if
>>>>> that element happened to be removed from the queue meanwhile (in that
>>>>> case we could abort the output or try to resync)
>>>> Not feasible (threads may not always be prevented from being deleted),
>>>> but what about this:
>>>>
>>>> - maintain a modification counter for nkpod->threadq
>>>> - in our /proc-loops (sched and latency e.g.):
>>>> 1. take nklock
>>>> 2. get current counter
>>>> 3. compare with previous, restart whole loop if not matching
>>>> 4. copy current element (including the name...)
>>>> 5. forward element pointer
>>>> 6. release nklock
>>>> 7. goto 1 if not end-of-list
>>>>
>>>> As modifications on threadq should be fairly rare, I don't see a risk of
>>>> looping endlessly here.
>>>>
>>> The more I think of it, the more I'm convinced that we are trying to
>>> tweak /proc/xenomai/stats for the wrong purpose. Actually, some xeno_top
>>> tool would rather need the equivalent of individual /proc/<pid> files,
>>> thus reducing the contention on access, and the need for weird grepping
>>> on the output. e.g. /proc/xenomai/threads/<pid> could emit per-thread
>>> data in some easily greppable form by a user-space tool.
>> Far too complex in my eyes for this simple purpose (what's the pid of
>> kernel-only threads?) -
>
> It's symbolic name. It's not a matter of simplicity, your patch for that
> purpose is rather complex already.
Haven't measured, but the amount of code added for collecting the data
and printing just another column should be marginal as yet. Introducing
a new infrastructure for more /proc subdirs with probably multiple
entries would certainly cost more.
>
>> and we need to solve the latency problem of
>> /sched and /stat anyway.
>
> That's separate issues. Solving the scalability issue
> of /proc/xenomai/stats and friends does not improve their usability in
> the context of user-space tools monitoring thread activity. E.g. how are
> we going to extend the reporting about such activity if need be, adding
> yet another column to /stats and /sched?
As long as there are no stand-alone tools relying on the layout, just
only our own ones - fairly simple. But before speculating more, I will
have a look now how simple such tool/script may actually be.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: Large number of mount request.
From: Ian Kent @ 2006-07-07 9:03 UTC (permalink / raw)
To: Latrell; +Cc: autofs, ramana
In-Reply-To: <00b201c6a17a$8050d160$251a17ac@ZyXEL.com>
On Fri, 7 Jul 2006, Latrell wrote:
> There will be an automount daemon for 1 ftp session (used to mount shares
> under home directory).
> I sent SIGTERM to automount when my FTP session close (because the
> corresponding automount daemod need to be killed).
> In my scenario, there should be multi-sessions need to be closed. Thus,
> SIGTERM will not be unique.
I'm a little confused.
What I was suggesting is that according to the log entry below automount
received one of the above signals which caused the mount to fail. That was
why I asked about where the signals might have come from. If you send a
termination signal to version 4 and a mount is busy it usually won't exit
but I would expect any mounts in progress to fail in this manner as well.
>
> My autofs version is 4.1.4 with patch autofs4-2.4.29-20050404.patch.
> kernel is 2.4.31 (no autofs patch for 2.4.31)
You should consider appling the patches for 4.1.4 available on kernel.org.
At least apply autofs-4.1.4-locking-fix-1.patch.
However, the locking problem that this addresses results in lock timeout
log entries not lock interrupted messages. The reason bieng that automount
dosn't wiat for the lock.
>
> Thanks, for your comment,
> Latrell.
> ----- Original Message ----- From: "Ian Kent" <raven@themaw.net>
> To: "Latrell" <is85022@cis.nctu.edu.tw>
> Cc: <ramana@intraperson.com>; <autofs@linux.kernel.org>
> Sent: Thursday, July 06, 2006 7:58 PM
> Subject: Re: [autofs] Large number of mount request.
>
>
> > On Thu, 2006-07-06 at 11:52 +0800, Latrell wrote:
> > > Do you mean my ghost option didn't make it in time thus "cd share1"
> > > failed?
> > > I got the following message whenever there's "Failed to change directory"
> > > error:
> > >
> > > automount[2306]: aquire_lock: can't lock lock file interrupted:
> > > /var/lock/autofs
> >
> > And what is sending the SIGQUIT, SIGTERM or SIGINT to autofs to cause it
> > to stop waiting and return a interrupted fail?
> >
> > > automount[2306]: failed to mount autofs path /tmp/users/shares/1034
> > >
> > > automount[2306]: /ramdisk/mnt/var1/tmp/users/shares/1034: mount failed!
> > >
> > > I also checked the ghost did create directory share1 under the home
> > > directory. Could the lock problem cause cd share1 fail?
> > >
> > > Thanks for your comment,
> > > Latrell.
> > >
> > > ----- Original Message ----- From: "ramana" <intraperson@yahoo.com>
> > > To: "Latrell" <is85022@cis.nctu.edu.tw>; <autofs@linux.kernel.org>
> > > Sent: Friday, June 23, 2006 7:27 PM
> > > Subject: Re: [autofs] Large number of mount request.
> > >
> > >
> > > > --- Latrell <is85022@cis.nctu.edu.tw> wrote:
> > > >
> > > >> Hi, all:
> > > >>
> > > >> I have a problem with the mount and umount packet.
> > > >> My problem is when I have a large number of mount requests, some
> > > >> mount request packets are missing. Thus, when I "cd share1", I will
> > > >> get "fail to change directory" because share1 is not mounted. Fewer
> > > >> mount requests work normally.
> > > >
> > > > I am afraid, this is ENOENT bug.
> > > >
> > > > Thanks in advance.
> > > >
> > > > Regards
> > > > ramana
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > >
> > > _______________________________________________
> > > autofs mailing list
> > > autofs@linux.kernel.org
> > > http://linux.kernel.org/mailman/listinfo/autofs
> >
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
>
^ permalink raw reply
* [U-Boot-Users] ld error : EABI version defference
From: Peter Pearse @ 2006-07-07 9:00 UTC (permalink / raw)
To: u-boot
Yun-Sik Woo
arm-none-linux-gnueabi-gcc from
arm-2006q1-6-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.gz2
defaults to producing binaries compliant to the ARM ABI.
Add the following line to u-boot/cpu/arm926ejs/config.mk to force use of the
gnu api.
PLATFORM_CPPFLAGS += -mabi=apcs-gnu
Peter Pearse
P.S. I believe posting HTML to this list is (strongly) deprecated....
^ permalink raw reply
* [ALSA - driver 0002263]: All sound plays in an endless loop
From: bugtrack @ 2006-07-07 8:58 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2263>
======================================================================
Reported By: NathanF
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2263
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: Grafpup Linux
Kernel Version: 2.6.17.3
======================================================================
Date Submitted: 07-07-2006 08:06 CEST
Last Modified: 07-07-2006 10:58 CEST
======================================================================
Summary: All sound plays in an endless loop
Description:
dmesg reports 'snd_via82xx_modem: Unknown symbol snd_verbose_printk'
Playing a sound file results in the first second repeating in an endless
loop until the process is killed. Some applications will not play at all,
flash animations in a browser play silently.
======================================================================
----------------------------------------------------------------------
vsu - 07-07-06 10:58
----------------------------------------------------------------------
This looks like an IRQ problem. Did sound work with older kernels (e.g.,
2.6.16)?
Please attach dmesg output - it may contain useful information to diagnose
the problem.
Also you may try to revert (patch -p1 -R <file.patch) these patches from
your 2.6.17.3 kernel:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=a7b862f663d81858531dfccc0537bc9d8a2a4121
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=75cf7456dd87335f574dcd53c4ae616a2ad71a11
These patches were supposed to stop VIA IRQ setup code from running on
non-motherboard devices, but they seem to break IRQ routing on many
systems.
Issue History
Date Modified Username Field Change
======================================================================
07-07-06 08:06 NathanF New Issue
07-07-06 08:06 NathanF Distribution => Grafpup Linux
07-07-06 08:06 NathanF Kernel Version => 2.6.17.3
07-07-06 10:58 vsu Note Added: 0010902
======================================================================
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: Strange intermittant errors + RAID doesn't fail the disk.
From: Mattias Wadenstein @ 2006-07-07 8:58 UTC (permalink / raw)
To: Neil Brown; +Cc: Christian Pernegger, linux-raid
In-Reply-To: <17581.35131.123710.652968@cse.unsw.edu.au>
On Fri, 7 Jul 2006, Neil Brown wrote:
> On Thursday July 6, pernegger@gmail.com wrote:
>>>> I suggest you find a SATA related mailing list to post this to (Look
>>>> in the MAINTAINERS file maybe) or post it to linux-kernel.
>>
>> linux-ide couldn't help much, aside from recommending a bleeding-edge
>> patchset which should fix a lot of things SATA:
>> http://home-tj.org/files/libata-tj-stable/
>>
>> What fixed the error, though, was exchanging one of the cables. (Just
>> my luck, it was new and supposedly quality, ... oh well)
>>
>> I'm still interested in why the md code didn't fail the disk. While it
>> was 'up' any access to the array would hang for a long time,
>> ultimately fail and corrupt the fs to boot. When I failed the disk
>> manually everything was fine (if degraded) again.
>
> md is very dependant on the driver doing the right thing. It doesn't
> do any timeouts or anything like that - it assumes the driver will.
> md simply trusts the return status from the drive, and fails a drive
> if and only if a write to the drive is reported as failing (if a read
> fails, md trys to over-write with good data first).
Hmm.. Perhaps a bit of extra logic there might be good? If you try to
re-write the failing bit with good data, try to read the recently written
data back (perhaps after a bit of wait). If that still fails, then fail
the disk.
If it can't remember recently written data, it is clearly unsuitable for a
running system. But the occasional block going bad (and getting remapped
at a write) wouldn't trigger it.
/Mattias Wadenstein
^ permalink raw reply
* Re: G5 troubles booting powerpc-git (July 6)
From: Benjamin Herrenschmidt @ 2006-07-07 8:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20060707015237.68c768f2.akpm@osdl.org>
> > If it doesn't fix it, then it's indeed a completely different issue that I'll have to track down tomorrow
> > hopefully.
>
> Needs this to compile:
Yeah, it's a powermac-only patch at the moment... thanks for doing part
of my work tho :)
Cheers,
Ben.
> diff -puN arch/powerpc/platforms/pseries/ras.c~a-fix arch/powerpc/platforms/pseries/ras.c
> --- a/arch/powerpc/platforms/pseries/ras.c~a-fix
> +++ a/arch/powerpc/platforms/pseries/ras.c
> @@ -93,8 +93,7 @@ static void request_ras_irqs(struct devi
> for (i = 0; i < opicplen; i++) {
> if (count > 15)
> break;
> - virqs[count] = irq_create_mapping(NULL, *(opicprop++),
> - IRQ_TYPE_NONE);
> + virqs[count] = irq_create_mapping(NULL, *(opicprop++));
> if (virqs[count] == NO_IRQ)
> printk(KERN_ERR "Unable to allocate interrupt "
> "number for %s\n", np->full_name);
> diff -puN arch/powerpc/platforms/pseries/xics.c~a-fix arch/powerpc/platforms/pseries/xics.c
> --- a/arch/powerpc/platforms/pseries/xics.c~a-fix
> +++ a/arch/powerpc/platforms/pseries/xics.c
> @@ -757,7 +757,7 @@ void xics_request_IPIs(void)
> {
> unsigned int ipi;
>
> - ipi = irq_create_mapping(xics_host, XICS_IPI, 0);
> + ipi = irq_create_mapping(xics_host, XICS_IPI);
> BUG_ON(ipi == NO_IRQ);
>
> /*
> diff -puN drivers/char/hvsi.c~a-fix drivers/char/hvsi.c
> --- a/drivers/char/hvsi.c~a-fix
> +++ a/drivers/char/hvsi.c
> @@ -1299,7 +1299,7 @@ static int __init hvsi_console_init(void
> hp->inbuf_end = hp->inbuf;
> hp->state = HVSI_CLOSED;
> hp->vtermno = *vtermno;
> - hp->virq = irq_create_mapping(NULL, irq[0], 0);
> + hp->virq = irq_create_mapping(NULL, irq[0]);
> if (hp->virq == NO_IRQ) {
> printk(KERN_ERR "%s: couldn't create irq mapping for 0x%x\n",
> __FUNCTION__, irq[0]);
> _
>
> But it still doesn't help.
>
>
> These:
>
> arch/powerpc/sysdev/i8259.c:222: warning: initialization from incompatible pointer type
> arch/powerpc/platforms/pseries/xics.c:555: warning: initialization from incompatible pointer type
> arch/powerpc/platforms/pseries/xics.c:561: warning: initialization from incompatible pointer type
>
> look like super-serious box-killers. Hope I'm not using either of those.
As I said, it's powermac only for now. I need to fix the above among
others. It's simple changes in most case. In the meantime, try on your
quad using a g5_defconfig
Ben.
^ permalink raw reply
* RE: [PATCH 1/3] Freescale QE UCC gigabit ethernet driver
From: Li Yang-r58472 @ 2006-07-07 8:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, netdev, jgarzik, linuxppc-dev
In-Reply-To: <FA983307-6A01-4FCB-A15A-ACC0E7B068A9@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, July 06, 2006 9:45 PM
> To: Li Yang-r58472
> Cc: Andrew Morton; jgarzik@pobox.com; netdev@vger.kernel.org;
> linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/3] Freescale QE UCC gigabit ethernet driver
>=20
> Nack. Here are some high level things that should be addressed:
> * There is a ton of debug code that should probably be stripped out,
> such as dump_regs, etc..
The reason I left these debug code in is that, QE is very flexible.
User probably needs to fine tune parameters for their own application.
It will be good to give them some clue doing that. It's fine to remove
them, if you do think they are too verbose.
> * The phy support should use the phylib instead
I'll do this when I do get some time. ;)
> * convert from being a platform_device to of_device
I'm not up against moving to use of_device. But why are we putting
extra effort in closing the door to backward compatibility with ppc
arch, and doesn't provide any new feature. ;)
>=20
> - kumar
>=20
^ permalink raw reply
* RE: [PATCH 1/3] Freescale QE UCC gigabit ethernet driver
From: Li Yang-r58472 @ 2006-07-07 8:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, jgarzik, netdev, linuxppc-dev
In-Reply-To: <FA983307-6A01-4FCB-A15A-ACC0E7B068A9@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, July 06, 2006 9:45 PM
> To: Li Yang-r58472
> Cc: Andrew Morton; jgarzik@pobox.com; netdev@vger.kernel.org;
> linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/3] Freescale QE UCC gigabit ethernet driver
>
> Nack. Here are some high level things that should be addressed:
> * There is a ton of debug code that should probably be stripped out,
> such as dump_regs, etc..
The reason I left these debug code in is that, QE is very flexible.
User probably needs to fine tune parameters for their own application.
It will be good to give them some clue doing that. It's fine to remove
them, if you do think they are too verbose.
> * The phy support should use the phylib instead
I'll do this when I do get some time. ;)
> * convert from being a platform_device to of_device
I'm not up against moving to use of_device. But why are we putting
extra effort in closing the door to backward compatibility with ppc
arch, and doesn't provide any new feature. ;)
>
> - kumar
>
^ permalink raw reply
* Re: [Bluez-devel] New bluez headset implementation
From: Mayank Batra @ 2006-07-07 8:57 UTC (permalink / raw)
To: bluez-devel
In-Reply-To: <446CDD43.3050604@free.fr>
[-- Attachment #1.1: Type: text/plain, Size: 12044 bytes --]
Hi Fabien,
I was testing this application (basichspd) with two headsets.
But it seems that I am able to connect on RFCOMM but there is no SCO
connection establishment taking place.
On the application side, it says SCO connected but when I see the hcidump
logs, there is no SetupSynchronousConnection Command going out.
Please suggest what is the problem.
hciconfig -a shows:
hci0: Type: UART
BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 1021:7 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN AUTH ENCRYPT
RX bytes:4740 acl:108 sco:0 events:238 errors:0
TX bytes:2923 acl:117 sco:0 commands:55 errors:0
Features: 0xff 0xeb 0x8d 0xfe 0x9b 0xe9 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: ''
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: n/a (0x3) HCI Rev: 0x402 LMP Ver: n/a (0x3) LMP Subver:
0x520
hciconfig hci0 features shows:
hci0: Type: UART
BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 1021:7 SCO MTU: 64:0
Features: 0xff 0xeb 0x8d 0xfe 0x9b 0xe9 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <SCO link> <HV3 packets> <u-law log>
<A-law log> <CVSD> <power control> <transparent SCO>
<broadcast encrypt> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps>
<enhanced iscan> <interlaced iscan> <interlaced pscan>
<inquiry with RSSI> <extended SCO> <EV4 packets> <EV5
packets>
<AFH cap. slave> <AFH class. slave> <3-slot EDR ACL>
<5-slot EDR ACL> <AFH cap. master> <EDR eSCO 2 Mbps>
<EDR eSCO 3 Mbps> <3-slot EDR eSCO>
hciconfig hci0 revision does not print anything about SCO mapping :(
The hcidump -X shows:
HCI sniffer - Bluetooth packet analyzer ver 1.30
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
0000: d3 52 23 89 03 00 18 cc 00 00 00 00 01 .R#..........
> HCI Event: Command Status (0x0f) plen 4
0000: 00 01 05 04 ....
> HCI Event: Connect Complete (0x03) plen 11
0000: 00 01 00 d3 52 23 89 03 00 01 00 ....R#.....
> HCI Event: Command Status (0x0f) plen 4
0000: 00 02 00 00 ....
< ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0040
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
0000: 01 00 0f 00 ....
> HCI Event: Command Complete (0x0e) plen 6
0000: 02 0d 08 00 01 00 ......
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0040 result 0 status 0
Connection successful
< ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 1024
> ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 328
< ACL data: handle 1 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> ACL data: handle 1 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
< ACL data: handle 1 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 4 frame_type 0 credit_flow 15 pri 0 ack_timer 0
frame_size 323 max_retrans 0 credits 7
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> ACL data: handle 1 flags 0x02 dlen 18
L2CAP(d): cid 0x0040 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
dlci 4 frame_type 0 credit_flow 14 pri 0 ack_timer 0
frame_size 100 max_retrans 0 credits 3
< ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 4 pf 1 ilen 0 fcs 0x96
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> HCI Event: PIN Code Request (0x16) plen 6
0000: d3 52 23 89 03 00 .R#...
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
0000: d3 52 23 89 03 00 04 30 30 30 30 00 00 00 00 00 .R#....0000.....
0010: 00 00 00 00 00 00 00 .......
> HCI Event: Command Complete (0x0e) plen 10
0000: 02 0d 04 00 d3 52 23 89 03 00 .....R#...
> HCI Event: Link Key Notification (0x18) plen 23
0000: d3 52 23 89 03 00 52 71 66 24 06 e6 dd 31 f8 66 .R#...Rqf$...1.f
0010: ee cc a2 e5 46 4e 00 ....FN.
> ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 4 pf 1 ilen 0 fcs 0x5d
< ACL data: handle 1 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
< ACL data: handle 1 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 4 pf 1 ilen 0 fcs 0x79 credits 33
< ACL data: handle 1 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 4 pf 0 ilen 4 fcs 0x65
0000: 52 49 4e 47 RING
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
> ACL data: handle 1 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
> ACL data: handle 1 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
< ACL data: handle 1 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
> ACL data: handle 1 flags 0x02 dlen 9
L2CAP(d): cid 0x0040 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 4 pf 1 ilen 0 fcs 0xa3 credits 1
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 01 00 01 00 .....
Thanks.
Regards,
Mayank
On 5/19/06, Fabien Chevalier <fabchevalier@free.fr> wrote:
>
>
> Hello all, i've been spending most of my spare time in the past
> month writing an alternative implementation to btsco for headsets support.
> The starting point was me being frustrated not to be able to use my
> laptop for VoIP because of crappy microphones the manufacturers usually
> put in. So my goal now is to go wireless with bluetooth. :-)
> So here i am. The software i wrote is now mature enough to be shared
> with others.
>
> What i'm looking for now is peer review from experienced bluez
> developpers about it. But that's enough about me, let's talk about the
> software :-)
>
> So What's In ?
>
> What is implemented is the AG side of the headset profile. Both Headset
> initiated connections and access gateway initiated connections are
> supported. It does not support A2DP, as it is another profile, and
> moreover people here are already working on the subject :-)
>
> The spirit that governed the design was the following:
> - be able to handle voice over IP applications well (this means
> keeping buffering at a minimum for a reduced latency)
> - make it easy to use for open source VoIp apps developpers (the idea
> is that it should be very easy for the apps to provide some basic
> support for bluetooth headsets with no change to the application itself)
> - support 100% of bluetooth headset profile (device
> connect/disconnect, headset button push)
>
> The architecture is the following:
> - 1 daemon, responsible for doing SDP, handling RFCOMM and SCO
> channels, parsing AT commands, sending DBUS signals when things happen.
> The daemon handles application requests (referred to as AG initiated
> connection in HSP spec) or headset connection requests (referred to as
> HS initiated connection in HSP spec)
> The daemon also handles session caching between PCM open/close.
> - 2 ALSA user space IO plugins (1 control, 1 PCM). Both of them
> communicate with the daemon using unix sockets. The PCM also has an
> instance of the SCO socket, so that it can reads/write data directly to
> it.
>
> Compared to btsco, it differs in the following way:
> - it is 100% userspace. No more kernel module.
> - all parameters are supplied by the application to the alsa pcm
> plugin, that will eventually forward them to the daemon. This will make
> implementation of user friendly MMI much easier (in particular, there
> is no need to lauch the daemon separately with a predefined BD address.
> The gui will thus be able to provide bd address).
> - it handles only one active headset at a time
> - it supports HS initiated connections as well
> - codebase cleaner. It should be possible with minimal pain to
> support handsfree profile.
>
> Still to be done :
> 1) more testing
> 2) DBUS signalling to tell the world about connected /
> disconnected / button pushed events.
> 3) some kind of switching from headset to an alternate sound device
> in case the headset is unavailable.
> 4) interoperability testing against a variety of devices.
> 5) document the design
> 6) debug kernel sco support (more on that on a separate e-mail)
>
> I'm likely to do 3), 5), however 1 and 2 might be better handled
> by somebody else, and 4 is just everybody's work :-)
>
> Where to get the software:
> Simple! On my hard disk!! No i'm kidding... but in fact not
> completely. ;-)
> I don't wanna start a whole open source project for such a small
> thing. So for now i will send it by private e-mail to developers
> interested in giving it a try. Just reply to this e-mail if you are
> interested.
>
> How to play with the software:
> - use standard aplay/arecord tools (not very funny)
> - use xmms (a litte more funny :-) )
> - use ekiga 2.0.1 (top fun!- however you will need to patch it and
> rebuild it)
>
>
> Fabien
>
>
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
[-- Attachment #1.2: Type: text/html, Size: 19820 bytes --]
[-- Attachment #2: Type: text/plain, Size: 299 bytes --]
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: snd-aoa: g5 tas codec problems
From: Benjamin Herrenschmidt @ 2006-07-07 8:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, alsa-devel
In-Reply-To: <1152262148.15068.30.camel@localhost>
On Fri, 2006-07-07 at 10:49 +0200, Johannes Berg wrote:
> On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> > Also, we should try
> > (if not already the case) to cache our clock/i2s state so that
> > subsequent prepare() don't try to change things that are already ok.
>
> I do that, the function reads the dws and sfr registers and exits early
> if they match.
Ok. Be careful that I've removed the initial init of TAS thinking we
always get to clock restart to do it in prepare()... might need to be
put back.
Ben.
^ permalink raw reply
* Re: snd-aoa: g5 tas codec problems
From: Benjamin Herrenschmidt @ 2006-07-07 8:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, alsa-devel
In-Reply-To: <1152262148.15068.30.camel@localhost>
On Fri, 2006-07-07 at 10:49 +0200, Johannes Berg wrote:
> On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> > Also, we should try
> > (if not already the case) to cache our clock/i2s state so that
> > subsequent prepare() don't try to change things that are already ok.
>
> I do that, the function reads the dws and sfr registers and exits early
> if they match.
Ok. Be careful that I've removed the initial init of TAS thinking we
always get to clock restart to do it in prepare()... might need to be
put back.
Ben.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* linux-2.6.17-mm6: strange kobject message
From: Paul Drynoff @ 2006-07-07 8:59 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
Here is dmesg which I got during boot,
the first part not interesting I already reported about it,
and I don't remember one of two things: Arjan van de Ven's patch was
lost or not good enough. The second part is related to kobject,
I'm not sure is it normal when kobject tell about -EEXIST and print stack?
Note that this is happened only once per 100 normal booting, I mean the second part.
=================================
[ INFO: inconsistent lock state ]
---------------------------------
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
dhclient/1952 [HC1[1]:SC0[1]:HE0:SE0] takes:
(&ei_local->page_lock){+...}, at: [<c039d78d>] ei_interrupt+0x39/0x32c
{hardirq-on-W} state was registered at:
[<c0133f5b>] lock_acquire+0x57/0x74
[<c05b15c2>] _spin_lock+0x1a/0x28
[<c039d558>] ei_start_xmit+0x74/0x270
[<c053ecc9>] dev_hard_start_xmit+0x1a9/0x1f8
[<c05499be>] __qdisc_run+0xb6/0x1a8
[<c05403fd>] dev_queue_xmit+0x115/0x23c
[<c059e441>] packet_sendmsg_spkt+0x195/0x1d0
[<c05348cb>] sock_sendmsg+0xcf/0xf0
[<c0534c8a>] sys_sendto+0xb6/0xf0
[<c0535e07>] sys_socketcall+0x11f/0x194
[<c010336f>] syscall_call+0x7/0xb
irq event stamp: 8667
hardirqs last enabled at (8666): [<c05b18b1>] _spin_unlock_irqrestore+0x3d/0x48
hardirqs last disabled at (8667): [<c0103553>] common_interrupt+0x1b/0x2c
softirqs last enabled at (8632): [<c011f23b>] __do_softirq+0x97/0xa8
softirqs last disabled at (8660): [<c0540323>] dev_queue_xmit+0x3b/0x23c
other info that might help us debug this:
1 lock held by dhclient/1952:
#0: (&dev->_xmit_lock){-+..}, at: [<c054993f>] __qdisc_run+0x37/0x1a8
stack backtrace:
[<c0103b3e>] show_trace+0x16/0x1c
[<c010412a>] dump_stack+0x1a/0x20
[<c0132037>] print_usage_bug+0x1d7/0x1e4
[<c0132802>] mark_lock+0x432/0x548
[<c0133542>] __lock_acquire+0x53e/0xc68
[<c0133f5b>] lock_acquire+0x57/0x74
[<c05b15c2>] _spin_lock+0x1a/0x28
[<c039d78d>] ei_interrupt+0x39/0x32c
[<c013b150>] handle_IRQ_event+0x24/0x58
[<c013c4e4>] handle_level_irq+0x6c/0xd0
[<c0104ed1>] do_IRQ+0x55/0xa8
[<c010355d>] common_interrupt+0x25/0x2c
[<c013b957>] enable_irq+0x4b/0x9c
[<c039d5f3>] ei_start_xmit+0x10f/0x270
[<c053ecc9>] dev_hard_start_xmit+0x1a9/0x1f8
[<c05499be>] __qdisc_run+0xb6/0x1a8
[<c05403fd>] dev_queue_xmit+0x115/0x23c
[<c059e441>] packet_sendmsg_spkt+0x195/0x1d0
[<c05348cb>] sock_sendmsg+0xcf/0xf0
[<c0534c8a>] sys_sendto+0xb6/0xf0
[<c0535e07>] sys_socketcall+0x11f/0x194
[<c010336f>] syscall_call+0x7/0xb
kobject_add failed for vcs1 with -EEXIST, don't try to register things with the same name in the same directory.
[<c0103b3e>] show_trace+0x16/0x1c
[<c010412a>] dump_stack+0x1a/0x20
[<c02c9774>] kobject_add+0x114/0x1b4
[<c037455f>] class_device_add+0xb3/0x484
[<c0374943>] class_device_register+0x13/0x18
[<c03749d2>] class_device_create+0x8a/0xbc
[<c032d016>] vcs_make_devfs+0x26/0x54
[<c0332bd9>] con_open+0x61/0x88
[<c0327e7f>] tty_open+0x16f/0x348
[<c0164507>] chrdev_open+0x63/0x168
[<c015a634>] __dentry_open+0x8c/0x164
[<c015a790>] nameidata_to_filp+0x30/0x3c
[<c015a7d7>] do_filp_open+0x3b/0x44
[<c015a81b>] do_sys_open+0x3b/0xc4
[<c015a8cf>] sys_open+0x13/0x18
[<c010336f>] syscall_call+0x7/0xb
kobject_add failed for vcsa1 with -EEXIST, don't try to register things with the same name in the same directory.
[<c0103b3e>] show_trace+0x16/0x1c
[<c010412a>] dump_stack+0x1a/0x20
[<c02c9774>] kobject_add+0x114/0x1b4
[<c037455f>] class_device_add+0xb3/0x484
[<c0374943>] class_device_register+0x13/0x18
[<c03749d2>] class_device_create+0x8a/0xbc
[<c032d03c>] vcs_make_devfs+0x4c/0x54
[<c0332bd9>] con_open+0x61/0x88
[<c0327e7f>] tty_open+0x16f/0x348
[<c0164507>] chrdev_open+0x63/0x168
[<c015a634>] __dentry_open+0x8c/0x164
[<c015a790>] nameidata_to_filp+0x30/0x3c
[<c015a7d7>] do_filp_open+0x3b/0x44
[<c015a81b>] do_sys_open+0x3b/0xc4
[<c015a8cf>] sys_open+0x13/0x18
[<c010336f>] syscall_call+0x7/0xb
^ permalink raw reply
* Re: G5 troubles booting powerpc-git (July 6)
From: Andrew Morton @ 2006-07-07 8:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1152260824.9862.57.camel@localhost.localdomain>
On Fri, 07 Jul 2006 18:27:04 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2006-07-07 at 01:23 -0700, Andrew Morton wrote:
> > On Fri, 07 Jul 2006 08:56:27 +1000
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > If you look at arch/powerpc/kernel/irq.c from line 479:
> > >
> > > /* Check if mapping already exist, if it does, call
> > > * host->ops->map() to update the flags
> > > */
> > > virq = irq_find_mapping(host, hwirq);
> > > if (virq != IRQ_NONE) {
> > > pr_debug("irq: -> existing mapping on virq %d\n", virq);
> > > host->ops->map(host, virq, hwirq, flags);
> > > return virq;
> > > }
> > >
> > > What if you comment out the host->ops->map(...) call in there ? Does it
> > > help ?
> >
> > No, there's no change in behaviour.
>
> Doh ! Ok, looks like a different issue. Can you try this patch ? Please,
> do _not_ apply it to your tree as, as it is it will break non-powermac.
> It's some work I'm doing to clean up a couple of rough edges in my irq
> rework and fix a little misdesign.
>
> If it doesn't fix it, then it's indeed a completely different issue that I'll have to track down tomorrow
> hopefully.
Needs this to compile:
diff -puN arch/powerpc/platforms/pseries/ras.c~a-fix arch/powerpc/platforms/pseries/ras.c
--- a/arch/powerpc/platforms/pseries/ras.c~a-fix
+++ a/arch/powerpc/platforms/pseries/ras.c
@@ -93,8 +93,7 @@ static void request_ras_irqs(struct devi
for (i = 0; i < opicplen; i++) {
if (count > 15)
break;
- virqs[count] = irq_create_mapping(NULL, *(opicprop++),
- IRQ_TYPE_NONE);
+ virqs[count] = irq_create_mapping(NULL, *(opicprop++));
if (virqs[count] == NO_IRQ)
printk(KERN_ERR "Unable to allocate interrupt "
"number for %s\n", np->full_name);
diff -puN arch/powerpc/platforms/pseries/xics.c~a-fix arch/powerpc/platforms/pseries/xics.c
--- a/arch/powerpc/platforms/pseries/xics.c~a-fix
+++ a/arch/powerpc/platforms/pseries/xics.c
@@ -757,7 +757,7 @@ void xics_request_IPIs(void)
{
unsigned int ipi;
- ipi = irq_create_mapping(xics_host, XICS_IPI, 0);
+ ipi = irq_create_mapping(xics_host, XICS_IPI);
BUG_ON(ipi == NO_IRQ);
/*
diff -puN drivers/char/hvsi.c~a-fix drivers/char/hvsi.c
--- a/drivers/char/hvsi.c~a-fix
+++ a/drivers/char/hvsi.c
@@ -1299,7 +1299,7 @@ static int __init hvsi_console_init(void
hp->inbuf_end = hp->inbuf;
hp->state = HVSI_CLOSED;
hp->vtermno = *vtermno;
- hp->virq = irq_create_mapping(NULL, irq[0], 0);
+ hp->virq = irq_create_mapping(NULL, irq[0]);
if (hp->virq == NO_IRQ) {
printk(KERN_ERR "%s: couldn't create irq mapping for 0x%x\n",
__FUNCTION__, irq[0]);
_
But it still doesn't help.
These:
arch/powerpc/sysdev/i8259.c:222: warning: initialization from incompatible pointer type
arch/powerpc/platforms/pseries/xics.c:555: warning: initialization from incompatible pointer type
arch/powerpc/platforms/pseries/xics.c:561: warning: initialization from incompatible pointer type
look like super-serious box-killers. Hope I'm not using either of those.
^ permalink raw reply
* Re: [Xenomai-core] [RFC, PATCH] per-thread exec-time stats
From: Philippe Gerum @ 2006-07-07 8:49 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <44AE16B3.80901@domain.hid>
On Fri, 2006-07-07 at 10:09 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2006-07-06 at 18:36 +0200, Jan Kiszka wrote:
> >> Jan Kiszka wrote:
> >>> Philippe Gerum wrote:
> >>>> On Thu, 2006-07-06 at 17:09 +0200, Jan Kiszka wrote:
> >>>>>> We could do that from the current loop below, given that the
> >>>>>> accumulation routine is changed to use thread->sched implicitely.
> >>>>> The idea is avoid adding even further load to the nklock-protected loop.
> >>>>> And we only update the current thread, not each and every.
> >>>>>
> >>>> Yes, but why? I mean, accumulated time so far remains significant even
> >>>> for non-running threads.
> >>> Update must only happen for the currently running thread on each cpu,
> >>> otherwise you skew the stats up.
> >>>
> >>>
> >>> But looking at the whole code in stat_seq_open() again, I now wonder if
> >>> that whole routine isn't
> >>>
> >>> a) fragile on task removal and
> >>> b) still poorly scaling.
> >>>
> >>> The thread name is only copied by reference, a disappearing instance my
> >>> cause troubles on printing it. And, instead of holding the lock all the
> >>> time, shouldn't we better
> >>>
> >>> 1. pick some element from the queue and mark it somehow
> >>> in-use under lock
> >>> 2. print or copy the entry
> >>> 3. reacquire the lock to proceed to the next one - after checking if
> >>> that element happened to be removed from the queue meanwhile (in that
> >>> case we could abort the output or try to resync)
> >> Not feasible (threads may not always be prevented from being deleted),
> >> but what about this:
> >>
> >> - maintain a modification counter for nkpod->threadq
> >> - in our /proc-loops (sched and latency e.g.):
> >> 1. take nklock
> >> 2. get current counter
> >> 3. compare with previous, restart whole loop if not matching
> >> 4. copy current element (including the name...)
> >> 5. forward element pointer
> >> 6. release nklock
> >> 7. goto 1 if not end-of-list
> >>
> >> As modifications on threadq should be fairly rare, I don't see a risk of
> >> looping endlessly here.
> >>
> >
> > The more I think of it, the more I'm convinced that we are trying to
> > tweak /proc/xenomai/stats for the wrong purpose. Actually, some xeno_top
> > tool would rather need the equivalent of individual /proc/<pid> files,
> > thus reducing the contention on access, and the need for weird grepping
> > on the output. e.g. /proc/xenomai/threads/<pid> could emit per-thread
> > data in some easily greppable form by a user-space tool.
>
> Far too complex in my eyes for this simple purpose (what's the pid of
> kernel-only threads?) -
It's symbolic name. It's not a matter of simplicity, your patch for that
purpose is rather complex already.
> and we need to solve the latency problem of
> /sched and /stat anyway.
That's separate issues. Solving the scalability issue
of /proc/xenomai/stats and friends does not improve their usability in
the context of user-space tools monitoring thread activity. E.g. how are
we going to extend the reporting about such activity if need be, adding
yet another column to /stats and /sched?
>
> Jan
--
Philippe.
^ permalink raw reply
* Re: snd-aoa: g5 tas codec problems
From: Johannes Berg @ 2006-07-07 8:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, alsa-devel
In-Reply-To: <1152258426.9862.44.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> Also, we should try
> (if not already the case) to cache our clock/i2s state so that
> subsequent prepare() don't try to change things that are already ok.
I do that, the function reads the dws and sfr registers and exits early
if they match.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: snd-aoa: g5 tas codec problems
From: Johannes Berg @ 2006-07-07 8:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, alsa-devel
In-Reply-To: <1152258426.9862.44.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]
On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> Also, we should try
> (if not already the case) to cache our clock/i2s state so that
> subsequent prepare() don't try to change things that are already ok.
I do that, the function reads the dws and sfr registers and exits early
if they match.
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 299 bytes --]
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH] Integrate asus_acpi LED's with new LED subsystem
From: Richard Purdie @ 2006-07-07 8:46 UTC (permalink / raw)
To: Thomas Tuttle; +Cc: Linux Kernel Mailing List, Andrew Morton
In-Reply-To: <20060707012025.GB8900@phoenix>
On Thu, 2006-07-06 at 21:20 -0400, Thomas Tuttle wrote:
> +/* These functions are called by the LED subsystem to update the desired
> + * state of the LED's. */
> +static void led_set_mled(struct led_classdev *led_cdev,
> + enum led_brightness value);
> +static void led_set_wled(struct led_classdev *led_cdev,
> + enum led_brightness value);
> +static void led_set_tled(struct led_classdev *led_cdev,
> + enum led_brightness value);
I don't think you need these anymore.
> +#else
> +
> +static inline int led_initialize(struct device *parent)
> +{
> +}
> +
This turns the code into a game of Russian roulette when
CONFIG_ACPI_ASUS_NEW_LED isn't set (think return values). I'm sure
Andrew was just testing with that ;-)
If you fix these issues, you can add an
Acked-by: Richard Purdie <rpurdie@rpsys.net>
Richard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.