All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] PCMCIA: make Pretec CF Wifi use hostap_cs by default
From: Marcin Juszkiewicz @ 2006-04-09 20:39 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jouni Malinen, Pavel Roskin


I use two Zaurus palmtops - one run 2.4.18 kernel (it's sl-5500) and second 
run 2.6.16. Both are running under control of OpenZaurus distribution 
(I'm Release Manager of it).

When I use pcmcia-cs then my Pretec WiFi card is handled by hostap driver
and everything is working fine. Recently I switched to pcmciautils and after
card insert orinoco modules are loaded. I prefer to use hostap modules
because they work the same under 2.4 and 2.6 kernels (with orinoco I have to
use 0.13e ones because never ones does not work under 2.4/arm).

This patch adds definition of my card to hostap_cs cardlist. It was tested on
Sharp Zaurus C760 palmtop running 2.6.16 + pcmciautils 010 + udev 084


PS - I'm not subscribed to that list - so please Cc: me on reply.

Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>

--- drivers/net/wireless/hostap/hostap_cs.c.orig
+++ drivers/net/wireless/hostap/hostap_cs.c
@@ -912,6 +912,9 @@ static struct pcmcia_device_id hostap_cs
        PCMCIA_DEVICE_PROD_ID123(
                "SMC", "SMC2632W", "Version 01.02",
                0xc4f8b18b, 0x474a1f2a, 0x4b74baa0),
+       PCMCIA_DEVICE_PROD_ID123(
+               "Pretec", "CompactWLAN Card 802.11b", "2.5",
+               0x1cadd3e5, 0xe697636c, 0x7a5bfcf1),
        PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-CF-S11G",
                                0x2decece3, 0x82067c18),
        PCMCIA_DEVICE_PROD_ID12("Compaq", "WL200_11Mbps_Wireless_PCI_Card",


-- 
JID: hrw-jabber.org
Palmtop: Sharp Zaurus C760
OpenEmbedded/OpenZaurus developer

Vi has two modes: the one in which it beeps, and the one in which it doesn't.

^ permalink raw reply

* Re: [Qemu-devel] [PATCH] SPARC target : Fix carry flag update in addxcc and subxcc ops
From: Paul Brook @ 2006-04-09 20:38 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <200604081546.48408.even.rouault@mines-paris.org>

On Saturday 08 April 2006 14:46, Even Rouault wrote:
> I send a patch that should fix a bug in the update of carry flag for addxcc
> and subxcc instructions when the carry flag is set before the evaluation of
> the instruction.
> (the fix is identical to what is done in the similar instruction
> op_adcl_T0_T1_cc for arm target)

    if ((T0 & 0xffffffff) < (src1 & 0xffffffff))
        env->psr |= PSR_CARRY;

Doesn't this condition in addx and the corresponding line in subx need similar 
treatment?

Paul

^ permalink raw reply

* shrink_all_memory tweaks (was: Re: Userland swsusp failure (mm-related))
From: Rafael J. Wysocki @ 2006-04-09 20:36 UTC (permalink / raw)
  To: Con Kolivas; +Cc: linux-kernel, Pavel Machek, Fabio Comolli, Nick Piggin
In-Reply-To: <200604090924.04951.kernel@kolivas.org>

Hi Con,

On Sunday 09 April 2006 01:24, Con Kolivas wrote:
> On Sunday 09 April 2006 08:47, Rafael J. Wysocki wrote:
> > On Saturday 08 April 2006 18:15, Pavel Machek wrote:
> > > > > This is my first (and unique) failure since I began testing uswsusp
> > > > > (2.6.17-rc1 version). It happened (I think) because more than 50% of
> > > > > physical memory was occupied at suspend time (about 550 megs out og
> > > > > 1G) and that was what I was trying to test. After freeing some memory
> > > > > suspend worked (there was no need to reboot).
> > > >
> > > > Well, it looks like we didn't free enough RAM for suspend in this case.
> > > > Unfortunately we were below the min watermark for ZONE_NORMAL and
> > > > we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
> > > > ZONE_DMA in this case?).
> > > >
> > > > I think we can safely ignore the watermarks in swsusp, so probably
> > > > we can set PF_MEMALLOC for the current task temporarily and reset
> > > > it when we have allocated memory.  Pavel, what do you think?
> > >
> > > Seems little hacky but okay to me.
> > >
> > > Should not fixing "how much to free" computation to free a bit more be
> > > enough to handle this?
> >
> > Yes, but in that case we'll leave some memory unused. ;-)
> 
> How's the shrink_all_memory tweaks I sent performing for you Rafael? It may 
> theoretically be prone to the same issue but I tried to make it less likely.

Well, I don't think it would help in this particular case.  The memory got divided
almost ideally in swsusp_shrink_memory() and we were hit by the lowmem
reserve in ZONE_DMA, apparently.

Still I've been doing a crash course in mm internals recently and I can say a
bit more about your patch now. ;-)

First, I agree that using balance_pgdat() for freeing memory by swsusp is
overkill, so the removal of its second argument seems to be a good idea to
me.  However, I'd rather avoid modifying struct scan_control and shrink_zone()
and reimplement the shrink_zone()'s logic directly in shrink_all_memory(),
with some modifications (eg. we can explicitly avoid shrinking of the active
list until we decide it's worth it) -- or we can define a separate function for
this purpose.

Second, there are a couple of details I'd do in a different way.  For example
I think we should call shrink_slab() with the non-zero first argument
(otherwise it'll use SWAP_CLUSTER_MAX) and instead of setting
zone->prev_priority to 0 I'd set vm_swappiness to 100 temporarily
(or maybe l'd left it to the user to set swappiness before suspend?).

Also I think we can try to avoid slab shrinking until we start to shrink the
active zone or IOW until we can't get any more pages from the inactive
list alone.

If you don't mind, I'll try to rework your patch a bit in accordance with
the above remarks in the next couple of days.

Greetings,
Rafael

^ permalink raw reply

* Re: 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Nick Orlov @ 2006-04-09 19:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <20060409113240.630b9a24.akpm@osdl.org>

On Sun, Apr 09, 2006 at 11:32:40AM -0700, Andrew Morton wrote:
> Nick Orlov <bugfixer@list.ru> wrote:
> >
> > The following patch: x86-kmap_atomic-debugging.patch exposed a badness
> > in 3w_xxx driver.
> 
> Sweet, thanks.
> 
[[ skipped ]]
> 
> From: Andrew Morton <akpm@osdl.org>
> 
> We must disable local IRQs while holding KM_IRQ0 or KM_IRQ1.  Otherwise, an
> IRQ handler could use those kmap slots while this code is using them,
> resulting in memory corruption.
> 
> Thanks to Nick Orlov <bugfixer@list.ru> for reporting.
> 
> Cc: <linuxraid@amcc.com>
> Cc: James Bottomley <James.Bottomley@SteelEye.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
> 
>  drivers/scsi/3w-xxxx.c |    3 +++
>  1 files changed, 3 insertions(+)
> 
> diff -puN drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix drivers/scsi/3w-xxxx.c
> --- devel/drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix	2006-04-09 11:28:08.000000000 -0700
> +++ devel-akpm/drivers/scsi/3w-xxxx.c	2006-04-09 11:29:21.000000000 -0700
> @@ -1508,10 +1508,12 @@ static void tw_transfer_internal(TW_Devi
>  	struct scsi_cmnd *cmd = tw_dev->srb[request_id];
>  	void *buf;
>  	unsigned int transfer_len;
> +	unsigned long flags = 0;
>  
>  	if (cmd->use_sg) {
>  		struct scatterlist *sg =
>  			(struct scatterlist *)cmd->request_buffer;
> +		local_irq_save(flags);
>  		buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
>  		transfer_len = min(sg->length, len);
>  	} else {
> @@ -1526,6 +1528,7 @@ static void tw_transfer_internal(TW_Devi
>  
>  		sg = (struct scatterlist *)cmd->request_buffer;
>  		kunmap_atomic(buf - sg->offset, KM_IRQ0);
> +		local_irq_restore(flags);
>  	}
>  }
>  
> _

Confirmed, this patch solves the "badness" problem for me.
I still experiencing a weird hangs though (the box just hangs, no
messages on console/syslog, nothing). I'll try to nail it down.

2.6.16-mm2 works like a charm with the same config.
Do you know which patches should I try to revert first?

-- 
With best wishes,
	Nick Orlov.


^ permalink raw reply

* Re: [Qemu-devel] Gentlemen we have absolute movement! was:Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Anthony Liguori @ 2006-04-09 20:31 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <44396E20.6010103@wasp.net.au>

That's absolutely awesome Brad!

Good job!  I'll see how it works with the new Xorg driver.

Regards,

Anthony Liguori

Brad Campbell wrote:
> Brad Campbell wrote:
>> Lonnie Mendez wrote:
>>
>>>   Please see the patch posted yesterday to this mailing list:
>>>
>>> http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
>>
>> Ta for that.. not sure how I missed it.
>> Now to try and get it to work..
>>
>
> Ok.. 1st cut.. it's not great, and it's not hooked up to anything at 
> the moment (the mouse just tootles around the screen on a timer) BUT! 
> we have absolute movement.
>
> The *stunning* news is it's resolution independent.. 640x480 - 800x600 
> - 1024x768
> 0,0 is top left and 7fff.7fff is bottom right.. no client scaling 
> required..
>
> Think I've figured out the Z axis thing also.. and we are good for 
> relative movement on that still
> (The Z axis below is way wrong, but I think I have figured it out)
>
> static const uint8_t qemu_mouse_hid_report_descriptor[] = {
>         0x05, 0x01, /* Usage Page Generic Desktop */
>         0x09, 0x01, /* Usage Mouse */
>         0xA1, 0x01, /* Collection Application */
>         0x09, 0x01, /* Usage Pointer */
>         0xA1, 0x00, /* Collection Physical */
>         0x05, 0x09, /* Usage Page Button */
>         0x19, 0x01, /* Usage Minimum Button 1 */
>         0x29, 0x03, /* Usage Maximum Button 3 */
>         0x15, 0x00, /* Logical Minimum 0 */
>         0x25, 0x01, /* Logical Maximum 1 */
>         0x95, 0x03, /* Report Count 3 */
>         0x75, 0x01, /* Report Size 1 */
>         0x81, 0x02, /* Input (Data, Var, Abs) */
>         0x95, 0x01, /* Report Count 1 */
>         0x75, 0x05, /* Report Size 5 */
>         0x81, 0x01, /* Input (Cnst, Var, Abs) */
>         0x05, 0x01, /* Usage Page Generic Desktop */
>         0x09, 0x30, /* Usage X */
>         0x09, 0x31, /* Usage Y */
>         0x15, 0x00, /* Logical Minimum 0 */
>         0x27, 0xFF, 0xFF, 0x00, 0x00, /* Logical Maximum 0xffff */
>         0x75, 0x10, /* Report Size 32 */
>         0x95, 0x02, /* Report Count 2 */
>         0x81, 0x02, /* Input (Data, Var, Abs) */
> //      0x09, 0x32, /* Usage Z */
> //      0x15, 0x81, /* Logical Minimum -127 */
> //      0x25, 0x7F, /* Logical Maximum 127 */
> //      0x75, 0x08, /* Report Size 8 */
> //      0x95, 0x01, /* Report Count 1 */
>         0xC0,       /* End Collection */
>         0xC0,       /* End Collection */
> };
> #endif
>
> static int usb_mouse_poll(USBMouseState *s, uint8_t *buf, int len)
> {
>     int dx, dy, dz, b, l, aa, bb, cc, dd;
>
>     dx = int_clamp(s->dx, -128, 127);
>     dy = int_clamp(s->dy, -128, 127);
>     dz = int_clamp(s->dz, -128, 127);
>
>     s->dx -= dx;
>     s->dy -= dy;
>     s->dz -= dz;
>     b = 0;
>     if (s->buttons_state & MOUSE_EVENT_LBUTTON)
>         b |= 0x01;
>     if (s->buttons_state & MOUSE_EVENT_RBUTTON)
>         b |= 0x02;
>     if (s->buttons_state & MOUSE_EVENT_MBUTTON)
>         b |= 0x04;
>
>     buf[0] = b;
>     buf[1] = s->X & 0xff;
>     buf[2] = s->X >> 8;
>     buf[3] = s->Y & 0xff;
>     buf[4] = s->Y >> 8;
>     aa=buf[1];
>     bb=buf[2];
>     cc=buf[3];
>     dd=buf[4];
>     l = 5;
>
>     return l;
> }
>

^ permalink raw reply

* Re: add new code section for kernel code
From: Russell King @ 2006-04-09 20:30 UTC (permalink / raw)
  To: saeed bishara
  Cc: Arjan van de Ven, Paolo Ornati, linux-kernel, linux-arm-kernel,
	Linux-arm-toolchain
In-Reply-To: <c70ff3ad0604090253n7fe4de4che67f18380ffa2efd@mail.gmail.com>

On Sun, Apr 09, 2006 at 12:53:56PM +0300, saeed bishara wrote:
> > I'd prefer not to paper over such bugs.  Maybe the following patch will
> > fix the decompressor for saeed?
> 
> yes, this patch fixed the problem.

Thanks for testing; I've applied this patch so 2.6.17-rc2 onwards will
have this fixed.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply

* [Qemu-devel] Gentlemen we have absolute movement! was:Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Brad Campbell @ 2006-04-09 20:27 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <44395EE9.3040403@wasp.net.au>

Brad Campbell wrote:
> Lonnie Mendez wrote:
> 
>>   Please see the patch posted yesterday to this mailing list:
>>
>> http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
> 
> Ta for that.. not sure how I missed it.
> Now to try and get it to work..
> 

Ok.. 1st cut.. it's not great, and it's not hooked up to anything at the moment (the mouse just 
tootles around the screen on a timer) BUT! we have absolute movement.

The *stunning* news is it's resolution independent.. 640x480 - 800x600 - 1024x768
0,0 is top left and 7fff.7fff is bottom right.. no client scaling required..

Think I've figured out the Z axis thing also.. and we are good for relative movement on that still
(The Z axis below is way wrong, but I think I have figured it out)

static const uint8_t qemu_mouse_hid_report_descriptor[] = {
         0x05, 0x01, /* Usage Page Generic Desktop */
         0x09, 0x01, /* Usage Mouse */
         0xA1, 0x01, /* Collection Application */
         0x09, 0x01, /* Usage Pointer */
         0xA1, 0x00, /* Collection Physical */
         0x05, 0x09, /* Usage Page Button */
         0x19, 0x01, /* Usage Minimum Button 1 */
         0x29, 0x03, /* Usage Maximum Button 3 */
         0x15, 0x00, /* Logical Minimum 0 */
         0x25, 0x01, /* Logical Maximum 1 */
         0x95, 0x03, /* Report Count 3 */
         0x75, 0x01, /* Report Size 1 */
         0x81, 0x02, /* Input (Data, Var, Abs) */
         0x95, 0x01, /* Report Count 1 */
         0x75, 0x05, /* Report Size 5 */
         0x81, 0x01, /* Input (Cnst, Var, Abs) */
         0x05, 0x01, /* Usage Page Generic Desktop */
         0x09, 0x30, /* Usage X */
         0x09, 0x31, /* Usage Y */
         0x15, 0x00, /* Logical Minimum 0 */
         0x27, 0xFF, 0xFF, 0x00, 0x00, /* Logical Maximum 0xffff */
         0x75, 0x10, /* Report Size 32 */
         0x95, 0x02, /* Report Count 2 */
         0x81, 0x02, /* Input (Data, Var, Abs) */
//      0x09, 0x32, /* Usage Z */
//      0x15, 0x81, /* Logical Minimum -127 */
//      0x25, 0x7F, /* Logical Maximum 127 */
//      0x75, 0x08, /* Report Size 8 */
//      0x95, 0x01, /* Report Count 1 */
         0xC0,       /* End Collection */
         0xC0,       /* End Collection */
};
#endif

static int usb_mouse_poll(USBMouseState *s, uint8_t *buf, int len)
{
     int dx, dy, dz, b, l, aa, bb, cc, dd;

     dx = int_clamp(s->dx, -128, 127);
     dy = int_clamp(s->dy, -128, 127);
     dz = int_clamp(s->dz, -128, 127);

     s->dx -= dx;
     s->dy -= dy;
     s->dz -= dz;
     b = 0;
     if (s->buttons_state & MOUSE_EVENT_LBUTTON)
         b |= 0x01;
     if (s->buttons_state & MOUSE_EVENT_RBUTTON)
         b |= 0x02;
     if (s->buttons_state & MOUSE_EVENT_MBUTTON)
         b |= 0x04;

     buf[0] = b;
     buf[1] = s->X & 0xff;
     buf[2] = s->X >> 8;
     buf[3] = s->Y & 0xff;
     buf[4] = s->Y >> 8;
     aa=buf[1];
     bb=buf[2];
     cc=buf[3];
     dd=buf[4];
     l = 5;

     return l;
}

-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

^ permalink raw reply

* Re: linear writes to raid5
From: Mark Hahn @ 2006-04-09 20:24 UTC (permalink / raw)
  To: Alex Tomas; +Cc: linux-raid
In-Reply-To: <m37j60udi8.fsf@bzzz.home.net>

> is there a way to batch explicitely write requests raid5 issues?

sort of like TCP_CORK?

> for example, there is a raid5 built from 3 disks with chunk=64K.
> one types dd if=/dev/zero of=/dev/md0 bs=128k count=1

OK, so this is an aligned, whole-stripe write.

>and 128K
> bio gets into the raid5. raid5 processes the request, does xor
> for parity stripe, then issues 2 64KB requests down to lower level.

don't you mean _3_ chunk-sized writes?  if so, are you actually
asking about the case when you issue an aligned two-stripe write?
(which might get broken into 6 64K writes, not sure, rather than 
three 2-chunk writes...)

_not_ that I know this code at all!


^ permalink raw reply

* Re: Masquerading problems - XenU 3.0 on x86_64
From: Jim Pick @ 2006-04-09 20:18 UTC (permalink / raw)
  To: Keir Fraser; +Cc: xen-devel Devel, netfilter-devel
In-Reply-To: <6677c9ee1b32caad4ff87bf462512ee3@cl.cam.ac.uk>

Keir Fraser wrote:
> 
> On 9 Apr 2006, at 01:01, Jim Pick wrote:
> 
>> I'm trying to migrate my Xen sessions installed on 32-bit Xen 2.0 
>> server to a 64-bit Xen 3.0 server.
>>
>> On the Xen 2.0 server (32-bit), I built a DomU kernel with 
>> masquerading, and I use that to do NAT for some private networks 
>> running on the same box.
>>
>> When I tried to do it with Xen 3.0 (64-bit), I couldn't get it to 
>> work.  I had to build a custom DomU kernel (from xen-3.0-testing.hg, 
>> 2.6.16, 2 days ago) in order to include the netfilter/iptables code.  
>> ICMP works.  TCP doesn't.  Non-masquerading traffic is OK.  I had the 
>> same problems with the 2.6.12 kernel from Xen 3.0.1.
>>
>> I captured some of the traffic, and ethereal is showing that the 
>> masqueraded traffic being output has bad TCP checksums.
>>
>> I'm going to have to do some debugging to try to figure out what's 
>> going wrong.
>>
>> Has anybody else encountered this?  Also, if it's already been fixed 
>> somewhere, I'd love to know.  Any Netfilter debugging tips would also 
>> be appreciated.
> 
> 
> Turn off tx checksum offload in your domU's using ethtool. We had fixed 
> some forms of NAT with our checksum offload, but maybe not for your type 
> of setup.

That fixed it.  Thanks!

Cheers,

  - Jim

^ permalink raw reply

* Re: Technical information requested on MultiPath module of Linux
From: Christophe Varoqui @ 2006-04-09 20:09 UTC (permalink / raw)
  To: Joanne Neil; +Cc: dm-devel
In-Reply-To: <b043f1b00604091015w7468d9ecjf729c3188761f295@mail.gmail.com>

Joanne Neil a écrit :
> Hello,
>
>       I was in search of technical details on MultiPath module of Linux. I found
> the excellent page of  christophe. I apologize for sending the email to you
> directly. Can I know:
>
> a. Which will be the right email forum to send technical/development questions
> on MultiPath for Linux?
>
>   
dm-devel@redhat.com
> b. I was looking at Linux 2.6.11 MultiPath code and found EMC CX/AX
> specific code. This is where I am most interested in. Does it require that
> a storage vendor has to implement specific hooks for the generic MultiPath
> code to work with their product in Linux?. If yes, can I be pointed link or
> references or document on what a storage vendor has to implement to
> have their storage work on Linux.
>
>   
I guess you refer to "hardware handlers" modules. Those are needed only 
if special host-initiated action is needed for the storage hardware to 
activate failback paths.

This is often the case with asymmetric arrays.
> c. From what I have read, the MultiPath architecture has changed from
> Linux 2.4 and Linux 2.6. Is this correct?. And the device mapper architecture
> was introduced in Linux 2.6.
>
>   
The DM multipath driver is lk2.6 only. The MD multipath driver was 
available in lk2.4, and is still maintained in lk2.6. The 
multipath-tools interface the DM framework only.
> d. Will Linux 2.6 MultiPath code be applicable to Linux 2.4?
>
>   
There is no plan for userspace tools to support lk2.4 (pre-sysfs 
kernels, pre-kevents).
Hardware handlers use a "lk2.6 DM" specific API.
> Appreciate any help
>
> Regards
> Joanne
>   

^ permalink raw reply

* Re: 2.4.32: unresolved symbol unregister_qdisc
From: George P Nychis @ 2006-04-09 20:06 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: davem, linux-kernel, netdev
In-Reply-To: <20060409130315.50daaec9.rdunlap@xenotime.net>


> On Sun, 9 Apr 2006 13:37:25 -0400 (EDT) George P Nychis wrote:
> 
>> Thanks for the help.
>> 
>> Here is the makefile: http://rafb.net/paste/results/auchPH75.html
>> 
>> And here is the full errors I receive: 
>> http://rafb.net/paste/results/Qplpqw74.html
>> 
>> Greatly appreciate it
>> 
>> - George
> 
> [repeat: please don't top-post]
> 
> I don't know how much I can help you.  It's been a long time since I've
> built external modules on 2.4.x.
> 
> Problems that I see: - the Makefile does not use the expected 2.4 kernel
> build infrastructure; - kernel Makefile uses -nostdinc to prevent use of
> userspace headers; - Makefile is trying to include userspace headers
> instead of kernel headers, e.g.: In file included from
> /usr/include/linux/if_ether.h:107, from /usr/include/linux/netdevice.h:29,
>  from sch_xcp.c:8: - this specified include directory is only in 2.6.x,
> not 2.4.x: -I/lib/modules/`uname -r`/build/include/asm/mach-default
> 
> It's not clear to me how this makefile could work with 2.4.x at all. Is it
> supposed to, or that's just what you want to see it do?
> 
> You could try to fix the Makefile based on makefile-changes articles at
> lwn.net. E.g.: http://lwn.net/Articles/151784/ 
> http://lwn.net/Articles/79984/ http://lwn.net/Articles/74767/ 
> http://lwn.net/Articles/69148/ http://lwn.net/Articles/21823/
> 
> 
> 
>>> On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:
>>> 
>>>> Yeah, this module is unfortunately not under the GPL, it was made
>>>> for research and i am not the author, I was only given the code for
>>>> my own research.
>>>> 
>>>> I enabled that support in the kernel, and then tried to recompile
>>>> and get tons of errors/warnings... so maybe I am missing something
>>>> else to be enabled in the kernel... here are a few examples of
>>>> errors: /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such
>>>> file or directory /usr/include/asm/irq.h:16:25: irq_vectors.h: No
>>>> such file or directory /usr/include/linux/irq.h:72: error: `NR_IRQS'
>>>> undeclared here (not in a function) /usr/include/asm/hw_irq.h:28:
>>>> error: `NR_IRQ_VECTORS' undeclared here (not in a function)
>>>> 
>>>> I think those are the top most errors, so if i can fix those
>>>> hopefully the rest shall vanish!
>>> 
>>> Looks like a Makefile problem then.  Can you post the Makefile?
>>> Hopefully it is using a Makefile and not just an elaborate gcc command
>>> line.
>>> 
>>> [and please don't top-post]
>>> 
>>>> - George
>>>> 
>>>> 
>>>>> From: "George P Nychis" <gnychis@cmu.edu> Date: Sat, 8 Apr 2006 
>>>>> 18:47:34 -0400 (EDT)
>>>>> 
>>>>>> Hey,
>>>>>> 
>>>>>> I have a kernel module that uses unregister_qdisc and 
>>>>>> register_qdisc, whenever i try to insert the module I get: 
>>>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
>>>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved
>>>>>> symbol unregister_qdisc
>>>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
>>>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved
>>>>>> symbol register_qdisc
>>>>>> 
>>>>>> Am i missing some sort of support in the kernel?
>>>>> 
>>>>> Make sure CONFIG_NET_SCHED is enabled and that you compiled your 
>>>>> module against that kernel.
>>>>> 
>>>>> Where does this sch_xcp come from?  It's not in the vanilla
>>>>> sources.
>>>>> 
>>>>> Also, please direct networking questions to the 
>>>>> netdev@vger.kernel.org mailing list which I have added to the
>>>>> CC:.
> 
> --- ~Randy
> 
> 

Sorry, I thought when you said top-post, I thought you were telling me about only posting the "top" most errors in my original e-mail, thats why i pasted full error output.


The thing is, it compiles successfully when CONFIG_NET_SCHED is not enabled in the kernel.  But when its not enabled, i get the external symbol errors.

As soon as I enable CONFIG_NET_SCHED ... it no longer compiles.

I will look into this, it is supposed to work... the code has been used by others before.

If you or anyone else come up with anything, please let me know

Thanks!
George


^ permalink raw reply

* Re: [Xenomai-core] GDB 6.x + simulator
From: Bruno Rouchouse @ 2006-04-09 20:04 UTC (permalink / raw)
  To: xenomai
In-Reply-To: <443941A3.20909@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

Works fine here now with gdb 6.3 and svn trunk version.

Thanks !

--
Bruno


On 4/9/06, Philippe Gerum <rpm@xenomai.org> wrote:
>
>
> The following patch enables GDB 6.x for the simulator. Please give this
> a try if you happen to use the Xenosim. TIA,
>
> --- sim/scope/gdbhelper.cc      (revision 904)
> +++ sim/scope/gdbhelper.cc      (working copy)
> @@ -423,6 +423,8 @@
>
>       char *ibuf = gdb_ibuf.gets(), *estart = gdb_ibuf.gets();
>
> +    Tcl_ResetResult(tclInterp);
> +
>       for (;;)
>         {
>         if (*ibuf == '\0' || *ibuf == '\n')
> @@ -504,7 +506,7 @@
>                 // the contents of the log did not match anything known to
>                 // the caller. We cannot return -1, which value is
> reserved
>                 // to indicate that the connection with GDB has been lost.
> -
> +
>                 Tcl_AppendElement(tclInterp,CString(rc2 ? rc2 :
> nre).gets());
>                 Tcl_AppendElement(tclInterp,matched);
>                 Tcl_AppendElement(tclInterp,Tcl_DStringValue(&gdb_ilog));
> Index: sim/scope/tcl/gdb.tcl
> ===================================================================
> --- sim/scope/tcl/gdb.tcl       (revision 904)
> +++ sim/scope/tcl/gdb.tcl       (working copy)
> @@ -850,8 +850,10 @@
>         regexp "\[^\"\]+.(\[^\"\]+).*" $matched mvar curfocus
>       }
>
> -    # query stack information
> -    set rl [gdb:command where ls]
> +    # query stack information -- auto-limit to the inner last 32
> +    # frames in order to work-around the issue GDB 6.x has with
> +    # ucontext(2) driven co-routines.
> +    set rl [gdb:command "where 32" ls]
>       set stackinfo [lindex $rl 2]
>
>       if {$stackinfo == {}} {
>
> --
>
> Philippe.
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
>

[-- Attachment #2: Type: text/html, Size: 3395 bytes --]

^ permalink raw reply

* Re: 2.4.32: unresolved symbol unregister_qdisc
From: Randy.Dunlap @ 2006-04-09 20:03 UTC (permalink / raw)
  To: George P Nychis; +Cc: davem, linux-kernel, netdev
In-Reply-To: <1786.128.2.140.234.1144604245.squirrel@128.2.140.234>

On Sun, 9 Apr 2006 13:37:25 -0400 (EDT) George P Nychis wrote:

> Thanks for the help.
> 
> Here is the makefile:
> http://rafb.net/paste/results/auchPH75.html
> 
> And here is the full errors I receive:
> http://rafb.net/paste/results/Qplpqw74.html
> 
> Greatly appreciate it
> 
> - George

[repeat: please don't top-post]

I don't know how much I can help you.  It's been a long time since
I've built external modules on 2.4.x.

Problems that I see:
- the Makefile does not use the expected 2.4 kernel build infrastructure;
- kernel Makefile uses -nostdinc to prevent use of userspace headers;
- Makefile is trying to include userspace headers instead of kernel headers, e.g.:
  In file included from /usr/include/linux/if_ether.h:107,
                 from /usr/include/linux/netdevice.h:29,
                 from sch_xcp.c:8:
- this specified include directory is only in 2.6.x, not 2.4.x:
  -I/lib/modules/`uname -r`/build/include/asm/mach-default

It's not clear to me how this makefile could work with 2.4.x at all.
Is it supposed to, or that's just what you want to see it do?

You could try to fix the Makefile based on makefile-changes articles at lwn.net.
E.g.:
http://lwn.net/Articles/151784/
http://lwn.net/Articles/79984/
http://lwn.net/Articles/74767/
http://lwn.net/Articles/69148/
http://lwn.net/Articles/21823/



> > On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:
> > 
> >> Yeah, this module is unfortunately not under the GPL, it was made for
> >> research and i am not the author, I was only given the code for my own
> >> research.
> >> 
> >> I enabled that support in the kernel, and then tried to recompile and
> >> get tons of errors/warnings... so maybe I am missing something else to
> >> be enabled in the kernel... here are a few examples of errors: 
> >> /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or
> >> directory /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or
> >> directory /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here
> >> (not in a function) /usr/include/asm/hw_irq.h:28: error:
> >> `NR_IRQ_VECTORS' undeclared here (not in a function)
> >> 
> >> I think those are the top most errors, so if i can fix those hopefully
> >> the rest shall vanish!
> > 
> > Looks like a Makefile problem then.  Can you post the Makefile? Hopefully
> > it is using a Makefile and not just an elaborate gcc command line.
> > 
> > [and please don't top-post]
> > 
> >> - George
> >> 
> >> 
> >>> From: "George P Nychis" <gnychis@cmu.edu> Date: Sat, 8 Apr 2006
> >>> 18:47:34 -0400 (EDT)
> >>> 
> >>>> Hey,
> >>>> 
> >>>> I have a kernel module that uses unregister_qdisc and
> >>>> register_qdisc, whenever i try to insert the module I get: 
> >>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
> >>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
> >>>> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
> >>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
> >>>> register_qdisc
> >>>> 
> >>>> Am i missing some sort of support in the kernel?
> >>> 
> >>> Make sure CONFIG_NET_SCHED is enabled and that you compiled your
> >>> module against that kernel.
> >>> 
> >>> Where does this sch_xcp come from?  It's not in the vanilla sources.
> >>> 
> >>> Also, please direct networking questions to the
> >>> netdev@vger.kernel.org mailing list which I have added to the CC:.

---
~Randy

^ permalink raw reply

* [ALSA - driver 0001765]: Issue 001595 does not fix Audigy 4
From: bugtrack @ 2006-04-09 19:57 UTC (permalink / raw)
  To: alsa-devel


The following issue has been CLOSED
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1765> 
======================================================================
Reported By:                alexholkner
Assigned To:                jcdutton
======================================================================
Project:                    ALSA - driver
Issue ID:                   1765
Category:                   PCI - emu10k1
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Distribution:               
Kernel Version:             
Resolution:                 open
Fixed in Version:           
======================================================================
Date Submitted:             01-21-2006 01:49 CET
Last Modified:              04-09-2006 21:57 CEST
======================================================================
Summary:                    Issue 001595 does not fix Audigy 4
Description: 
I have an Audigy 4 with the same device/subsystem as khampf from issue
1595.  I applied his patch, but it does NOT work unless I change
.ca0102_chip = 1 to .ca0108_chip = 1.

I did experience the same confusion where loading one driver with ca0108
will make any subsequent driver work (e.g., ca0102) until the next reboot.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0001595 Audigy 4 (bulk, non-Pro) unsupported (p...
======================================================================

----------------------------------------------------------------------
 jprk - 02-05-06 13:25 
----------------------------------------------------------------------
As 0001595 has been closed, I would just like to confirm, that Audigy 4
_partially_ works with entry

{.vendor = 0x1102, .device = 0x0008,
 .driver = "Audigy2", .name = "Audigy 2 Value [Unknown]", 
 .id = "Audigy2",
 .emu10k2_chip = 1,
 .ca0108_chip = 1,
 .ac97_chip = 1}

I have a 5.1 speaker set and I do not get sound from front left and front
right speakers. I tried to set up reasonable levels on every output with
alsamixer, but without success. I tried patching the Audigy 2 entry in
emu10k1_main.c to specify .spk71 = 1 - it did not have any influence.
Replugging front left/right minijack from its corresponding socket (L1)
into the center/subwoofer socket (L3) as reported by 'kjes' in discussion
for 0001595 is not a solution as then I loose subwoover and central
speaker.  

I am now running unpathced 2.6.15.2 on AMD-64 (64-bit kernel) with Audigy
4 being the first of two soundcards (the second one is an integrated AC97
clone on the motherboard). 

-----
cat /proc/asound/version:
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07
13:30:21 2005 UTC).

(I had exactly the same experience with 1.0.11rc2 and kernel 2.6.12)

-----
cat /proc/asound/cards:
0 [Audigy2        ]: Audigy2 - Audigy 2 Value [Unknown]
                     Audigy 2 Value [Unknown] (rev.0, serial:0x10211102)
at 0xdf00, irq 217
1 [CK804          ]: NFORCE - NVidia CK804
                     NVidia CK804 with ALC850 at 0xfebfd000, irq 233

----------------------------------------------------------------------
 jcdutton - 04-09-06 21:57 
----------------------------------------------------------------------
Fixed in alsa cvs on 9-4-2006
Fixed in alsa cvs version 1.0.11rc5 or above.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
01-21-06 01:49 alexholkner    New Issue                                    
01-22-06 00:06 jcdutton       Status                   new => assigned     
01-22-06 00:06 jcdutton       Assigned To               => jcdutton        
01-22-06 00:06 jcdutton       Relationship added       related to 0001595  
01-22-06 00:19 jcdutton       Note Added: 0007741                          
01-22-06 00:19 jcdutton       Status                   assigned => feedback
02-05-06 13:25 jprk           Note Added: 0007933                          
04-09-06 21:57 jcdutton       Status                   feedback => closed  
04-09-06 21:57 jcdutton       Note Added: 0009186                          
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: [PATCH] i386/x86-64: Return defined error value for bad PCI config space accesses
From: Andi Kleen @ 2006-04-09 19:55 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Andrew Morton, Linux Kernel Mailing List
In-Reply-To: <44395DD2.8080700@garzik.org>

On Sunday 09 April 2006 21:17, Jeff Garzik wrote:

> As the code check indicates, value might be NULL.
> 
> Please fix.

It should never be NULL.  If anything that's a BUG_ON, but crashing on it is ok
too. 

But I'll change it to a BUG_ON in the next patch thanks.

-Andi

^ permalink raw reply

* [2.6 patch] remove the obsolete IDEPCI_FLAG_FORCE_PDC
From: Adrian Bunk @ 2006-04-09 19:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Bartlomiej Zolnierkiewicz


This patch removes the obsolete IDEPCI_FLAG_FORCE_PDC.

Noted by Sergei Shtylylov <sshtylyov@ru.mvista.com>

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

---

This patch was already sent on:
- 7 Apr 2006

 drivers/ide/pci/pdc202xx_old.c |    2 --
 drivers/ide/setup-pci.c        |   13 -------------
 include/linux/ide.h            |    1 -
 3 files changed, 16 deletions(-)

--- linux-2.6.17-rc1-mm1-full/include/linux/ide.h.old	2006-04-07 00:51:49.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/ide.h	2006-04-07 00:52:03.000000000 +0200
@@ -1221,7 +1221,6 @@
 enum {
 	/* Uses ISA control ports not PCI ones. */
 	IDEPCI_FLAG_ISA_PORTS		= (1 << 0),
-	IDEPCI_FLAG_FORCE_PDC		= (1 << 1),
 };
 
 typedef struct ide_pci_device_s {
--- linux-2.6.17-rc1-mm1-full/drivers/ide/pci/pdc202xx_old.c.old	2006-04-07 00:52:13.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ide/pci/pdc202xx_old.c	2006-04-07 00:52:19.000000000 +0200
@@ -798,7 +798,6 @@
 		.autodma	= AUTODMA,
 		.bootable	= OFF_BOARD,
 		.extra		= 48,
-		.flags		= IDEPCI_FLAG_FORCE_PDC,
 	},{	/* 2 */
 		.name		= "PDC20263",
 		.init_setup	= init_setup_pdc202ata4,
@@ -819,7 +818,6 @@
 		.autodma	= AUTODMA,
 		.bootable	= OFF_BOARD,
 		.extra		= 48,
-		.flags		= IDEPCI_FLAG_FORCE_PDC,
 	},{	/* 4 */
 		.name		= "PDC20267",
 		.init_setup	= init_setup_pdc202xx,
--- linux-2.6.17-rc1-mm1-full/drivers/ide/setup-pci.c.old	2006-04-07 00:52:27.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ide/setup-pci.c	2006-04-07 00:54:28.000000000 +0200
@@ -580,7 +580,6 @@
 	int port;
 	int at_least_one_hwif_enabled = 0;
 	ide_hwif_t *hwif, *mate = NULL;
-	static int secondpdc = 0;
 	u8 tmp;
 
 	index->all = 0xf0f0;
@@ -592,21 +591,9 @@
 	for (port = 0; port <= 1; ++port) {
 		ide_pci_enablebit_t *e = &(d->enablebits[port]);
 	
-		/* 
-		 * If this is a Promise FakeRaid controller,
-		 * the 2nd controller will be marked as 
-		 * disabled while it is actually there and enabled
-		 * by the bios for raid purposes. 
-		 * Skip the normal "is it enabled" test for those.
-		 */
-		if ((d->flags & IDEPCI_FLAG_FORCE_PDC) &&
-		    (secondpdc++==1) && (port==1))
-			goto controller_ok;
-			
 		if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
 		    (tmp & e->mask) != e->val))
 			continue;	/* port not enabled */
-controller_ok:
 
 		if (d->channels	<= port)
 			break;


^ permalink raw reply

* Re: [LARTC] tc counters "problem"
From: Andreas Klauer @ 2006-04-09 19:50 UTC (permalink / raw)
  To: lartc
In-Reply-To: <200604091624.20565.ranmakun@arnet.com.ar>

On Sun, Apr 09, 2006 at 04:24:20PM -0300, Francisco wrote:
> I expected that meassuring the root class I would get values similar that 
> the ones I get measuring the interface counters but they differ by a 
> large amount.

The statistics you posted seem to be fine. Which interface counters are 
you talking about? tc starts counting only after the qdiscs/classes were 
created, so if you have a separate count somewhere which started counting 
some other time, the difference will of course be huge (as far as total 
packet count is concerned).

Regards
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply

* Re: Watch Performance
From: Steve Grubb @ 2006-04-09 19:48 UTC (permalink / raw)
  To: linux-audit; +Cc: redhat-lspp
In-Reply-To: <200604081221.58080.sgrubb@redhat.com>

Hi,

Based on finding an unnecessary function call to selinux_task_ctxid when 
evaluating syscall rules, I built a new kernel and re-ran the same tests.

rules  seconds    loss
0        47            0%
10      53            11%
25      68            43%
50      99            109%
75      132          178%
90      157          232%

The 75 rule performance hit is now 178% instead of 184%. So there is some 
notable improvement in performance. 

For comparison, I also loaded the 90 rules config into RHEL4. There is only a 
6% performance hit compared to no rules. I think the bulk of that comes from 
evaluating the 10 syscall rules rather than the file system audit code.

-Steve

^ permalink raw reply

* [ALSA - driver 0001331]: MSI K8N's SB Live 24 bit, no sound from line-in
From: bugtrack @ 2006-04-09 19:42 UTC (permalink / raw)
  To: alsa-devel


The following issue has been CLOSED
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1331> 
======================================================================
Reported By:                Cimmo
Assigned To:                jcdutton
======================================================================
Project:                    ALSA - driver
Issue ID:                   1331
Category:                   PCI - ca0106
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     closed
Distribution:               Fedora Core 4
Kernel Version:             2.6.12-1.1398-x86_64
Resolution:                 open
Fixed in Version:           
======================================================================
Date Submitted:             08-13-2005 01:27 CEST
Last Modified:              04-09-2006 21:42 CEST
======================================================================
Summary:                    MSI K8N's SB Live 24 bit, no sound from line-in
Description: 
I have a MSI K8N Platinum motherboard that has a SBLive! 24 bit
integrated.
(Un)fortunatelly this motherboard provide two different jacks for Mic and
Line-In instead of one single jack like the pci version of the sb live 24
bit.

With this card I cannot hear any sound that come from line-in.
For Example I have a tv card, its output audio go into line-in: result is
I cannot hear nothing from the tv, I can only see channels without audio.

The "Capture feedback into playback" in the mixer change the mic's
volume.
There is nothing that change line-in's volume.
======================================================================

----------------------------------------------------------------------
 Cimmo - 12-13-05 13:34 
----------------------------------------------------------------------
Of course send to you a sample means that I have to pay for this and can't
do this :)
The only thing I can do is to give and ssh login to my pc to try via
remote, it can help you?

----------------------------------------------------------------------
 jcdutton - 04-09-06 21:42 
----------------------------------------------------------------------
Fixed in alsa cvs on 9-4-2006
Fixed in alsa cvs 1.0.11rc5 or above.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
08-13-05 01:27 Cimmo          New Issue                                    
08-13-05 01:27 Cimmo          Distribution              => Fedora Core 4   
08-13-05 01:27 Cimmo          Kernel Version            => 2.6.12-1.1398-x86_64
08-13-05 01:41 jcdutton       Note Added: 0005798                          
08-13-05 01:42 jcdutton       Status                   assigned => feedback
08-13-05 18:30 Cimmo          Note Added: 0005807                          
08-31-05 15:14 Cimmo          Note Added: 0005989                          
08-31-05 18:59 rlrevell       Note Added: 0005991                          
09-10-05 10:31 jcdutton       Note Added: 0006107                          
10-19-05 19:13 Cimmo          Note Added: 0006496                          
11-07-05 00:02 jcdutton       Note Added: 0006610                          
11-07-05 11:07 Cimmo          Note Added: 0006612                          
11-11-05 19:33 Cimmo          Note Added: 0006678                          
12-13-05 13:16 jcdutton       Note Added: 0007007                          
12-13-05 13:34 Cimmo          Note Added: 0007015                          
04-09-06 21:40 jcdutton       Status                   feedback => assigned
04-09-06 21:42 jcdutton       Status                   assigned => closed  
04-09-06 21:42 jcdutton       Note Added: 0009185                          
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* [ALSA - driver 0001331]: MSI K8N's SB Live 24 bit, no sound from line-in
From: bugtrack @ 2006-04-09 19:40 UTC (permalink / raw)
  To: alsa-devel


The following issue has been ASSIGNED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1331> 
======================================================================
Reported By:                Cimmo
Assigned To:                jcdutton
======================================================================
Project:                    ALSA - driver
Issue ID:                   1331
Category:                   PCI - ca0106
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     assigned
Distribution:               Fedora Core 4
Kernel Version:             2.6.12-1.1398-x86_64
======================================================================
Date Submitted:             08-13-2005 01:27 CEST
Last Modified:              04-09-2006 21:40 CEST
======================================================================
Summary:                    MSI K8N's SB Live 24 bit, no sound from line-in
Description: 
I have a MSI K8N Platinum motherboard that has a SBLive! 24 bit
integrated.
(Un)fortunatelly this motherboard provide two different jacks for Mic and
Line-In instead of one single jack like the pci version of the sb live 24
bit.

With this card I cannot hear any sound that come from line-in.
For Example I have a tv card, its output audio go into line-in: result is
I cannot hear nothing from the tv, I can only see channels without audio.

The "Capture feedback into playback" in the mixer change the mic's
volume.
There is nothing that change line-in's volume.
======================================================================

----------------------------------------------------------------------
 jcdutton - 08-13-05 01:41 
----------------------------------------------------------------------
In order to help me implement support for what you want, please try the
following:
arecord -fdat -Dhw:0,0 | aplay
arecord -fdat -Dhw:0,1 | aplay
arecord -fdat -Dhw:0,2 | aplay
arecord -fdat -Dhw:0,3 | aplay

Please tell me which one works for the "line in".
If should record from the line in and then play it to the speakers with a
small delay.

----------------------------------------------------------------------
 Cimmo - 08-13-05 18:30 
----------------------------------------------------------------------
There are some problems, none of the 4 lines works, this is what I have
done:

[cimmo@localhost ~]$ arecord -fdat -Dhw:0,0 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Aborted by signal Interrupt...
Aborted by signal Interrupt...
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,1 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Aborted by signal Interrupt...
Aborted by signal Interrupt...
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,2 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
arecord: pcm_read:1252: read error: Input/output error
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,3 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
arecord: pcm_read:1252: read error: Input/output error

----------------------------------------------------------------------
 Cimmo - 08-31-05 15:14 
----------------------------------------------------------------------
What I have to do? Waiting for an answer...

----------------------------------------------------------------------
 rlrevell - 08-31-05 18:59 
----------------------------------------------------------------------
It's clearly a driver bug so all you can do at this point is wait for a
response from the driver developer.

----------------------------------------------------------------------
 jcdutton - 09-10-05 10:31 
----------------------------------------------------------------------
You might have an older version of the kernel driver.
Please post the output of: http://alsa.opensrc.org/TroubleShooting
Do Questions 1,2,3 and 4 and post the output here.

If you find that you do not have the latest alsa-driver, please try to
upgrade to it.

Please note that Line-in has never ever worked for your motherboard based
sound card in Linux, due to lack of enough information to implement it.
So, it is not really a bug, but instead a feature that we don't know how
to implement yet.

----------------------------------------------------------------------
 Cimmo - 10-19-05 19:13 
----------------------------------------------------------------------
1) Alsa is installed via module. Actually I've kernel v2.6.12.9
2) Advanced Linux Sound Architecture Driver Version 1.0.9 (Sun May 29
07:31:02 2005 UTC).
3) 1.0.9
4)
0 [CA0106         ]: CA0106 - CA0106
                     MSI K8N Diamond MB [SB0438] at 0xde00 irq 16
1 [Camera         ]: USB-Audio - Camera
                     Camera at usb-0000:00:02.0-8, full speed

----------------------------------------------------------------------
 jcdutton - 11-07-05 00:02 
----------------------------------------------------------------------
The version of alsa-driver you have is too old.
Support for your sound card was only added recently.
Please upgrade your version of alsa-driver.
If you compiled your own kernel, then simply installing alsa-driver will
update them for you.

----------------------------------------------------------------------
 Cimmo - 11-07-05 11:07 
----------------------------------------------------------------------
So I've to switch to development version 1.0.10rc2?

----------------------------------------------------------------------
 Cimmo - 11-11-05 19:33 
----------------------------------------------------------------------
Ok I've compiled and installed succesfully alsa-driver and alsa-lib
1.0.10rc3

I've retested everything:
putting TV audio output to mic it works great, I can listen to TV!
With this configuration I'm be able to record and play with these 2
commands:
arecord -fdat -Dhw:0,1 | aplay
arecord -fdat -Dhw:0,2 | aplay

with line-in there is no chance: audio doesn't work, and none of the four
0,x works.

I've to stress Creative for documentation?

Tell me something

Thanx
Marco

----------------------------------------------------------------------
 jcdutton - 12-13-05 13:16 
----------------------------------------------------------------------
Ok, so now the mic in works, but line in does not.
The only way to fix this is if I get a hardware sample.
The connections of the mic and line in are hardware specific and different
from all other SB Live 24bit cards.
You could try and get MSI to send me a hardware sample if you wish to fix
this.

----------------------------------------------------------------------
 Cimmo - 12-13-05 13:34 
----------------------------------------------------------------------
Of course send to you a sample means that I have to pay for this and can't
do this :)
The only thing I can do is to give and ssh login to my pc to try via
remote, it can help you?

Issue History
Date Modified  Username       Field                    Change              
======================================================================
08-13-05 01:27 Cimmo          New Issue                                    
08-13-05 01:27 Cimmo          Distribution              => Fedora Core 4   
08-13-05 01:27 Cimmo          Kernel Version            => 2.6.12-1.1398-x86_64
08-13-05 01:41 jcdutton       Note Added: 0005798                          
08-13-05 01:42 jcdutton       Status                   assigned => feedback
08-13-05 18:30 Cimmo          Note Added: 0005807                          
08-31-05 15:14 Cimmo          Note Added: 0005989                          
08-31-05 18:59 rlrevell       Note Added: 0005991                          
09-10-05 10:31 jcdutton       Note Added: 0006107                          
10-19-05 19:13 Cimmo          Note Added: 0006496                          
11-07-05 00:02 jcdutton       Note Added: 0006610                          
11-07-05 11:07 Cimmo          Note Added: 0006612                          
11-11-05 19:33 Cimmo          Note Added: 0006678                          
12-13-05 13:16 jcdutton       Note Added: 0007007                          
12-13-05 13:34 Cimmo          Note Added: 0007015                          
04-09-06 21:40 jcdutton       Status                   feedback => assigned
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* RE: PAE in 3.0.2
From: Ian Pratt @ 2006-04-09 19:31 UTC (permalink / raw)
  To: Brian Hays, xen-devel

> I've noticed that the download repo doesn't have a PAE (32p) 
> install build. Is PAE currently broken in 3.0.2?

No, it just a really anoying bug with the autobuild system, and I've
been sick and haven't gotten around to fixing it.

[The 'make oldconfig' is bailing out because it needs keyboard input]
Ian

^ permalink raw reply

* Re: [Xenomai-core] Proposal to use buildbot for Xenomai
From: Wolfgang Grandegger @ 2006-04-09 19:31 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <4438E90F.6070304@domain.hid>

Jan Kiszka wrote:
> Niklaus Giger wrote:
>> Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka:
>>> Niklaus Giger wrote:
>>>> Hi everybody
>> <..>
>>> This is a really great idea! Of course, I already have another test
>>> candidate in mind: RTnet 8). Specifically the PPC environment would be
>>> interesting, as our "buildbot" (sorry, Wolfgang G. ;) ) is typically
>>> very busy so that build regressions are sometimes only detected with
>>> delay on that platform. Is it also possible to explicitly trigger an
>>> update and rebuild?
>> Yes of course. Just select a buildslave (e.g. ppc or hcu3 -> 
>> http://ngiger.dyndns.org/buildbot/hcu3) and you may manually trigger it. I 
>> intentionally left this facility open for everybody to test it. But it would 
>> of course be possible to restrict it only to a few selected developers. 
>>
>> If you want, I can help you to setup the master.cfg for a rtnet buildbot.
> 
> I would love to, but you know - time...
> 
>>> But also for Xenomai I would see this as a very useful tool, e.g. for
>>> 2.4 build tests (I must confess I only test sporadically against this
>>> kernel).
>> I will add one. Could you please e-mail me (privately if you want) a working 
>> config (ppc, no cross compiling if possible). Or do you want to add a build 
>> slave under your control?
> 
> Hmm, I would prefer to just use something, especially as my PPC
> experiences are quite limited :). But I guess here are qualified people
> listening who can quickly dig out some config.

In arch/ppc/configs of the (DENX) 2.4 kernel are plenty of 
configurations for the PowerPC boards, e.g. TQM8620_defconfig, 
icecube_5200_defconfig, TQM866M_defconfig, etc. But we need cross 
compilation for most of the embedded boards. Do you need the 
configuration with IPIPE and Xenomai options enabled?

> 
>> <..>
>>> Is there no reset button you could control via a master station, e.g. by
>>> attaching some cheap electronic to a parallel or serial port?
>> There is a reset button, but then you have it running and consuming 
>> electricity all the times.
> 
> Yep, understandable.
> 
>>> I just remember that DENX once had or still have a remote PPC test-lab
>>> running. I CC'ed Wolfgang, maybe he could comment on this if and how it
>>> could be used.
>> I would be willing to setup a buildbot for the u-boot, too, as my board boots 
>> with a very outdated version of u-boot.

We simply use remote controllable power switches to switch the boards on 
and off.

Wolfgang.



^ permalink raw reply

* Re: net interface renaming issue (+fix?)
From: Thomas de Grenier de Latour @ 2006-04-09 19:28 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <20060409192140.73644723@eusebe>

On Sun, 9 Apr 2006 22:00:49 +0400,
Andrey Borzenkov <arvidjaar@mail.ru> wrote:

> net/core/dev.c:netdev_run_todo():
>                         err = netdev_register_sysfs(dev);
>                         if (err)
>                                 printk(KERN_ERR "%s: failed sysfs
> registration (%d)\n",
>                                        dev->name, err);
>                         dev->reg_state = NETREG_REGISTERED;
>                         break;
> 
> So basically there is a window between net device appearing in sysfs
> and 'address' returning usable value. To test you could move
> dev->reg_state assignment before netdev_register_sysfs call; if this
> helps it makes sense ask on net list if this is safe change.

As far as i can test, yes, it works fine.  I will forward your
suggestion to -netdev@.

Btw, many thanks to both of you, Andrey and Sergey, for the fast
answers and crystal-clear explanations of the actual issue.

-- 
TGL.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* Re: Black box flight recorder for Linux
From: Eric W. Biederman @ 2006-04-09 19:25 UTC (permalink / raw)
  To: Andi Kleen; +Cc: James Courtier-Dutton, Robert Hancock, linux-kernel
In-Reply-To: <200604091704.47566.ak@suse.de>

Andi Kleen <ak@suse.de> writes:

> On Saturday 08 April 2006 18:28, James Courtier-Dutton wrote:
>> Andi Kleen wrote:
>> > On Saturday 08 April 2006 16:05, Robert Hancock wrote:
>> >> Andi Kleen wrote:
>> >>> James Courtier-Dutton <James@superbug.co.uk> writes:
>> >>>> Now, the question I have is, if I write values to RAM, do any of those
>> >>>> values survive a reset?
>> >>> They don't generally.
>> >>>
>> >>> Some people used to write the oopses into video memory, but that
>> >>> is not portable.
>> >> I wouldn't think most BIOSes these days would bother to clear system RAM
>> >> on a reboot. Certainly Microsoft was encouraging vendors not to do this
>> >> because it slowed down system boot time.to
>> > 
>> > Reset button is like a cold boot and it generally ends up with cleared 
>> > RAM.
>> > 
>> > -Andi
>> 
>> Thank you. That saved me 30mins hacking. :-)

Actually clearing the memory can be done at full memory bandwidth
which can happen in seconds.  On systems with ECC you need initialize
all of the check bits so some kind of write to memory needs to happen.

In practice a reset does not clear the memory and only a few bits
tend to get flipped.  Unless you can get support from the
BIOS/firmware developers it isn't a practical approach though.

> First if you're not aware of this - the "official" way right now
> to solve this problem is kexec + kdump + a preloaded crash kernel. But in 
> practice it still has many problems because a lot of drivers cannot 
> reinitialize the hardware properly. And of course it will users need
> to load the crash kernel in advance and lose about 64MB of RAM.

Does a kernel really need 64M?  That number seems insanely large
to me.  8M should be more than sufficient if someone actually
tried to be small.  If you are aiming for a dedicated hardware
solution you don't need even need a kernel in there and the
amount reserved could be reduced to less than a meg.

The size etc becomes a trade off between what is expedient
and maintainable.

Eric

^ permalink raw reply

* Re: [PATCH] git log [diff-tree options]...
From: Linus Torvalds @ 2006-04-09 19:26 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bgmbm8b.fsf@assigned-by-dhcp.cox.net>



On Sun, 9 Apr 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > Well, on the other hand, the new "git log --diff" should get the revision 
> > counting right even if it's _not_ done by the caller.
> 
> Not if the user uses --diff-filter and/or --pickaxe, and after
> we start omitting the log message part when no diff is output.

Fair enough. At that point the counting does have to be done in the 
caller, I guess.

> A merge commit touching a path but not actually changing the contents of 
> the path from parents might be a significant event.

Yes. The fact that git-whatchanged happens to ignore such things right now 
is just a implementation detail, not a "good thing". The new git log seems 
to be better in pretty much all respects.

The bigger conceptual difference is actually that once you do revision 
pruning based on the pathname limiter, we prune away parents of merges 
that seem "uninteresting". So before, when you had the same change come 
through two different branches, "git-whatchanged" would actually show it 
twice, while the new "git log" approach would tend to show it just once 
(because it would pick one of the histories and ignore the other).

I think that's fine (and probably even preferable), but it's another 
example of something where we might want to have an option to not 
simplify the merge history. It's likely that nobody will ever care, but 
who knows..

			Linus

^ permalink raw reply


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.