Re: 2.6.11-rc3: intel8x0 alsa outputs no sound

2005-02-04 Thread Shaw
Hi John,

On Friday 04 February 2005 01:33 pm, you wrote:
> i'm using a thinkpad r40 w/ intel8x0 sound card.  it worked with 2.6.10.
> % ogg123 -d alsa09 file.ogg
> i can get no sound through either alsa or oss emulation.

I'm running 2.6.11-rc3 on a T30 also with an intel8x0 card and not 
experiencing any troubles with sound. (Using Alsa, btw)  Did you check the 
usual culprits- that your modules are being loaded, permissions 
of /dev/sound/*, that the channels are unmuted, etc?  Checkout the thinkpad 
list too, they're always very helpful.

Good luck,
Shaw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Athlon runtime problems

2001-04-16 Thread Ray Shaw


>CPU model/stepping
AMD Duron, 800mhz

>chipset
VIA KT-133; motherboard is an ABIT KT7A-RAID

>amount of RAM
256M, single PC-133 SDRAM

>/proc/mtrr output
reg00: base=0x (   0MB), size= 256MB: write-back, count=1
reg05: base=0xd000 (3328MB), size=  64MB: write-combining, count=1

>compiler used
gcc version 2.95.2

It seems to blow up when I'm doing something which probably wants lots
of memory, ie running X and opening up several mozilla windows (though
it still crashes while just running X, Enlightenment, and w3m in an
Eterm...but it does take a little longer, though still < 30 min.).

I went back to 2.2.18 and the crashing stopped.  I am using UDMA66 on
one of my drives, no DMA on the other two.

I haven't tried a non-Athlon optimised kernel, nor one with as few
options as possible; hopefully I will get the chance to do this soon.


-- 
--Ray

-
Sotto la panca la capra crepa
sopra la panca la capra campa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



NFS server difficulties

2001-06-24 Thread Ray Shaw


I thought I saw a post regarding a similar problem to mine, and
mentioning a patch, but I can't find the post anymore (and I never
found the patch), so:

I'm currently running 2.4.5-ac9.  Earlier 2.4.x kernels worked OK with
NFS, but blew up on my Athlon machine.  This kernel does _not_ work OK
with NFS.  I can mount shared directories on either of my roommate's
machines with no problems.  They can mount my shares, and perhaps do
an ls or two, but any operations beyond that will hang (at their end;
all my logs show nothing, and my machine is unaffected) until NFS
times out.

I've tried both the user and the kernel nfs server.  My roommate has
tried 2.4.5-ac7, 2.4.5-ac15, and 2.2.19, none of which worked.  My
other roommate has a machine running a 2.4pre kernel which _does_
work, and also a 2.4.1 kernel which I believe works.  We have another
machine running 2.4.3 with the XFS patch; that one doesn't work.

I have a tulip NIC and am using ext2, if that helps.  Another
interesting thing is that I'm also running Samba, and both smbfs (on
their end) and my Windows machine experience problems almost identical
to NFS.  So it really might be the NIC.

I'm not subscribed, but I read the newsgroup via Google, so there's no
pressing need to Cc me on replies.

Any help is greatly appreciated.


-- 
--Ray

-
Sotto la panca la capra crepa
sopra la panca la capra campa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



sched.h problem with kernel 2.4.3

2001-04-27 Thread Shaw Carruthers


I have just tried to upgrade to kernel 2.4.3 and my home grown modules
won't compile e.g:

The offending line 27 is:

#include 

Could some kind kernel guru point to a source which explains the error of
my ways?


In file included from lm78.c:13:
/usr/src/linux/include/linux/kernel.h:71: parse error before `int'
/usr/src/linux/include/linux/mount.h: In function `mntput':
In file included from /usr/src/linux/include/linux/dcache.h:7,
 from /usr/src/linux/include/linux/fs.h:19,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from lm78.c:27:
/usr/src/linux/include/linux/mount.h:46: warning: implicit declaration of function 
`printk_R1b7d4074'
/usr/src/linux/include/asm/semaphore.h: At top level:
In file included from /usr/src/linux/include/linux/fs.h:199,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from lm78.c:27:
/usr/src/linux/include/asm/semaphore.h:99: parse error before `void'
/usr/src/linux/include/asm/semaphore.h:100: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:101: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:102: parse error before `void'
/usr/src/linux/include/asm/semaphore.h:104: parse error before `void'
/usr/src/linux/include/asm/semaphore.h:105: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:106: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:107: parse error before `void'
In file included from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from lm78.c:27:
/usr/src/linux/include/linux/fs.h:962: parse error before `long'
/usr/src/linux/include/linux/fs.h:963: parse error before `long'
In file included from /usr/src/linux/include/linux/sched.h:10,
 from lm78.c:27:
/usr/src/linux/include/linux/personality.h:66: parse error before `long'
In file included from /usr/src/linux/include/linux/sched.h:25,
 from lm78.c:27:
/usr/src/linux/include/linux/sem.h:124: parse error before `long'
/usr/src/linux/include/linux/sem.h:125: parse error before `long'
/usr/src/linux/include/linux/sem.h:126: parse error before `long'
In file included from lm78.c:27:
/usr/src/linux/include/linux/sched.h:152: parse error before `void'
/usr/src/linux/include/linux/sched.h:569: parse error before `long'
/usr/src/linux/include/linux/vmalloc.h: In function `vmalloc':
In file included from /usr/src/linux/include/asm/io.h:108,
 from lm78.c:31:
/usr/src/linux/include/linux/vmalloc.h:35: `boot_cpu_data_R0657d037' undeclared (first 
use this function)
/usr/src/linux/include/linux/vmalloc.h:35: (Each undeclared identifier is reported 
only once
/usr/src/linux/include/linux/vmalloc.h:35: for each function it appears in.)
/usr/src/linux/include/linux/vmalloc.h: In function `vmalloc_dma':
/usr/src/linux/include/linux/vmalloc.h:44: `boot_cpu_data_R0657d037' undeclared (first 
use this function)
/usr/src/linux/include/linux/vmalloc.h: In function `vmalloc_32':
/usr/src/linux/include/linux/vmalloc.h:53: `boot_cpu_data_R0657d037' undeclared (first 
use this function)
lm78.c: At top level:
lm78.c:49: warning: initialization from incompatible pointer type
lm78.c: In function `lm78_get_info':
lm78.c:68: warning: implicit declaration of function `sprintf_R3c2c5af5'
lm78.c: In function `init_module':
lm78.c:156: warning: implicit declaration of function `proc_register'
lm78.c: In function `cleanup_module':
lm78.c:195: warning: implicit declaration of function `proc_unregister'
make: *** [lm78.o] Error 1

-- 
Shaw Carruthers - [EMAIL PROTECTED]
London SW14 7JW UK
This is not a sig( with homage to Magritte).
  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

2001-05-06 Thread Ray Shaw


I don't know if it's the motherboard, but I've got a KT7A-RAID, and I
haven't been able to run any 2.4.x that I've tried.  I was worried,
because this board also has new RAM, but 2.2.x doesn't have any
problems at all.

I've tried:

2.4.2
2.4.3
2.4.3-ac9
2.4.3-ac11

Someone else mentioned stability problems with nVida and AGP, which
I'm also using.  It's true that I've only experienced lockups under X.

Things I haven't tried, but should (and will, once finals are over):

2.4.x, unoptimised
2.4.x, optimised, disable AGP

I'm running Debian unstable (but it's not unstable with 2.2.x :)


-- 
--Ray

-
Sotto la panca la capra crepa
sopra la panca la capra campa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



2.2.19 toshiba.c won't build(PATCH)

2001-05-08 Thread Shaw Carruthers



Correcting the obvious error

#include 

still leaves:

toshiba.c:93: parse error before string constant
toshiba.c:93: warning: type defaults to `int' in declaration of `MODULE_PARM'
toshiba.c:93: warning: function declaration isn't a prototype
toshiba.c:93: warning: data definition has no type or storage class
toshiba.c: In function `tosh_open':
toshiba.c:286: `MOD_INC_USE_COUNT' undeclared (first use in this function)
toshiba.c:286: (Each undeclared identifier is reported only once
toshiba.c:286: for each function it appears in.)
toshiba.c: In function `tosh_release':
toshiba.c:294: `MOD_DEC_USE_COUNT' undeclared (first use in this function)
make[3]: *** [toshiba.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_char] Error 2
make: *** [_dir_drivers] Error 2


So needs if not built as a module:

--- /usr/src/linux-2.2.19/drivers/char/toshiba.cMon Apr 16 23:25:05 2001
+++ linux/drivers/char/toshiba.cWed May  2 20:39:54 2001
@@ -60,10 +60,8 @@
 #define TOSH_VERSION "1.9 22/3/2001"
 #define TOSH_DEBUG 0
 
-#ifdef MODULE
 #include
 #include
-#endif
 #include
 #include
 #include
@@ -78,7 +76,7 @@
 #include
 #endif
 
-#include"toshiba.h"
+#include
 
 #define TOSH_MINOR_DEV 181
 



-- 
Shaw Carruthers - [EMAIL PROTECTED]
London SW14 7JW UK
This is not a sig( with homage to Magritte).
  


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() with 4fa435018d740cb83d74c92306aa1f796da91ddd

2007-10-31 Thread Shaw Vrana
Yeah, I get the same with 2.6.24-rc1.


On Tue, Oct 23, 2007 at 05:48:54PM +0200, Thomas Meyer wrote:
> Thomas Meyer schrieb:
> > Oct 23 17:13:55 [kernel] usb 1-1: new high speed USB device using
> > ehci_hcd and address 7
> > Oct 23 17:13:55 [kernel] usb 1-1: configuration #1 chosen from 1 choice
> > Oct 23 17:13:55 [kernel] hub 1-1:1.0: USB hub found
> > Oct 23 17:13:55 [kernel] hub 1-1:1.0: 4 ports detected
> > Oct 23 17:13:55 [kernel] sysfs: duplicate filename 'bInterfaceNumber'
> > can not be created
> > Oct 23 17:13:55 [kernel] WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Oct 23 17:13:55 [kernel]  [] sysfs_add_one+0x54/0xb8
> > Oct 23 17:13:55 [kernel]  [] sysfs_add_file+0x42/0x6a
> > Oct 23 17:13:55 [kernel]  [] sysfs_create_group+0x84/0xe7
> > Oct 23 17:13:55 [kernel]  [] device_add+0x44a/0x454
> > Oct 23 17:13:55 [kernel]  []
> > usb_create_sysfs_intf_files+0x24/0x98 [usbcore]
> > Oct 23 17:13:55 [kernel]  [] usb_set_configuration+0x48f/0x4a9
> > [usbcore]
> > Oct 23 17:13:55 [kernel]  [] generic_probe+0x50/0x91 [usbcore]
> > Oct 23 17:13:55 [kernel]  [] usb_probe_device+0x32/0x37 [usbcore]
> > Oct 23 17:13:55 [kernel]  [] driver_probe_device+0xc5/0x148
> > Oct 23 17:13:55 [kernel]  [] klist_next+0x4b/0x6b
> > Oct 23 17:13:55 [kernel]  [] bus_for_each_drv+0x35/0x5c
> > Oct 23 17:13:55 [kernel]  [] device_attach+0x63/0x77
> > Oct 23 17:13:55 [kernel]  [] __device_attach+0x0/0x5
> > Oct 23 17:13:55 [kernel]  [] bus_attach_device+0x26/0x75
> > Oct 23 17:13:55 [kernel]  [] device_add+0x29b/0x454
> > Oct 23 17:13:55 [kernel]  [] usb_new_device+0x4d/0x8a [usbcore]
> > Oct 23 17:13:55 [kernel]  [] hub_thread+0x6f5/0xae2 [usbcore]
> > Oct 23 17:13:55 [kernel]  [] schedule+0x4b4/0x519
> > Oct 23 17:13:55 [kernel]  [] autoremove_wake_function+0x0/0x33
> > Oct 23 17:13:55 [kernel]  [] hub_thread+0x0/0xae2 [usbcore]
> > Oct 23 17:13:55 [kernel]  [] kthread+0x38/0x5f
> > Oct 23 17:13:55 [kernel]  [] kthread+0x0/0x5f
> > Oct 23 17:13:55 [kernel]  [] kernel_thread_helper+0x7/0x10
> > Oct 23 17:13:55 [kernel]  ===
> >
> >
> >
> >   
> Sorry. This happens with 0895e91d60ef9bdef426d1ce14bb94bd5875870d...
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE:Premiums

2015-01-11 Thread Jennifer Shaw
Good day,

Hello.We’re a metal pins manufacturing expert in China. Buyers across the US, 
the UK and France favor us. Mode design, casting, polishing and plating done 
in-house. We also produce metal crafts and other accessories. No MOQ require 
here. Waiting for your mail. I am Jennifer.

Happy New Year, 
Miss Jennifer Shaw
Sales representative  Skype ID: shaw.jennifer1
Sonier Pins Co.,Ltd
Add: No.2, JiXi ShunCheng Center, 
Xiaolan Town, Zhongshan City 528415,Guangdong,China .
Tel:(86 -760)22123680   Fax:(86 -760)22122916
Email: jennifershaw1...@yahoo.com   Website: http://sonier.en.alibaba.com/

RE:Souvenir keychains

2014-12-16 Thread Jennifer Shaw
Dear Sir/Madam,

Halo,We have done promotional gifts like souvenir coins and stones since 2003, 
we have 6 designers customized new items in just 3 hours. 11 years’ experience 
of producing metal pins could ensure the high quality of your project. If any 
require, welcome to contact us.My name is Jennifer.

Have a good day, 
Miss Jennifer Shaw
Sales representative  Skype ID: shaw.jennifer1
Sonier Pins Co.,Ltd
Add: No.2, JiXi ShunCheng Center, 
Xiaolan Town, Zhongshan City 528415,Guangdong,China .
Tel:(86 -760)22123680   Fax:(86 -760)22122916
Email: sal...@sonier-pins.com   Website :http://www.sonier-pins.com

RE:Coins supplier

2014-12-16 Thread Jennifer Shaw
Dear Madam/Sir,

Hello,very glad to got your message on website market.Our company manufacturing 
high-quality and competitively priced items .Our main products include medals 
and other promotional items.If you are interested on us,please let me know. I 
am Jennifer from Sonier.

King regards, 
Miss Jennifer Shaw
Sales representative  Skype ID: shaw.jennifer1
Sonier Pins Co.,Ltd
Add: No.2, JiXi ShunCheng Center, 
Xiaolan Town, Zhongshan City 528415,Guangdong,China .
Tel:(86 -760)22123680   Fax:(86 -760)22122916
Email: sal...@sonier-pins.com   Website: www.sonier-pins.com

[PATCH] uprobes: Fix limiting un-nested return probes

2013-09-02 Thread Hemant Kumar Shaw
Here is a sample program which shows a problem in uretprobes:
#include 

int some_work(int num)
{
while (num != 0)
num--;
return 0;
};

int main(int argc, char **argv)
{
if (argc != 2)
return EXIT_FAILURE;

int num = atoi(argv[1]);
while(num != 0) {
some_work(100);
num--;
};
return EXIT_SUCCESS;
}


$ gcc -o sample sample.c

- Add probe for returning from some_work():
$ sudo perf probe -x ./sample -a ret=some_work%return

Added new event:
 probe_sample:ret (on 0x530%return)

You can now use it in all perf tools, such as:

   perf record -e probe_sample:ret -aR sleep 1

- Record events :
$ sudo perf record -e probe_sample:ret -aR ./sample 134

- View report :
$ sudo perf report --stdio

# captured on: Wed Aug 14 17:03:42 2013
# hostname : hemant-fedora
# os release : 3.11.0-rc3+
# perf version : 3.9.4-200.fc18.x86_64
# arch : x86_64
# nrcpus online : 2
# nrcpus avail : 2
# cpudesc : QEMU Virtual CPU version 1.2.2
# cpuid : GenuineIntel,6,2,3
# total memory : 2051912 kB
# cmdline : /usr/bin/perf record -e probe_sample:ret -aR ./sample 134
# event : name = probe_sample:ret, type = 2, config = 0x38c, config1 =
0x0, config2 = 0x0,
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: software = 1, tracepoint = 2, breakpoint = 5
# 
#
# Samples: 64  of event 'probe_sample:ret'
# Event count (approx.): 64
#
# Overhead  Command  Shared ObjectSymbol
#   ...  .  
#
  100.00%   sample  sample [.] main


#
# (For a higher level overview, try: perf report --sort comm,dso)
#


>From report we can see that there were only 64 return events, but
actually it should be 134. It looks like uprobes identified return
events as recursive events and used restrictions for number of such events.
So, here is a patch which fixes this issue.

--->8---

There exists a limit to the number of nested return probes. The current limit 
is 64.
However this limit is getting enforced on even non nested return probes.
Hence, registering 64 independent non nested return probes results in failure of
return probes on the same task. The problem is utask->depth is getting 
incremented
unconditionally but decremented only if chained. So, utask->depth should be 
incremented only if chained. This should fix the issue.

Signed-off-by: Hemant Kumar Shaw 
Reported-by: Mikhail Kulemin 
---
 kernel/events/uprobes.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f356974..4fb20fe 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1442,7 +1442,8 @@ static void prepare_uretprobe(struct uprobe *uprobe, 
struct pt_regs *regs)
ri->orig_ret_vaddr = orig_ret_vaddr;
ri->chained = chained;
 
-   utask->depth++;
+   if (chained)
+   utask->depth++;
 
/* add instance to the stack */
ri->next = utask->return_instances;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC PATCH 0/2] Perf support to SDT markers

2013-09-03 Thread Hemant Kumar Shaw
This series adds support to perf to list and probe into the SDT markers.
The first patch implements listing of all the SDT markers present in
the ELFs (executables or libraries). The SDT markers are present in the
.note.stapsdt section of the elf. That section can be traversed to list
all the markers. Recognition of markers follows the SystemTap approach.

The second patch will allow perf to probe into these markers. This is
done by writing the marker name and its offset into the
uprobe_events file in the tracing directory.
Then, perf tools can be used to analyze perf.data file.

---

Hemant Kumar (2):
  SDT markers listing by perf
  Support to perf to probe on SDT markers


 tools/perf/builtin-probe.c|   33 
 tools/perf/util/probe-event.c |   17 ++
 tools/perf/util/symbol-elf.c  |  317 +
 tools/perf/util/symbol.h  |   24 +++
 4 files changed, 391 insertions(+)

-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/