* Re: detecting hyperthreading in linux 2.4.19
From: Mikael Pettersson @ 2003-01-10 7:05 UTC (permalink / raw)
To: jamesclv; +Cc: Jason Lunz, linux-kernel
In-Reply-To: <200301091337.04957.jamesclv@us.ibm.com>
James Cleverdon writes:
> On Thursday 09 January 2003 12:02 pm, Jason Lunz wrote:
> > Is there a way for a userspace program running on linux 2.4.19 to tell
> > the difference between a single hyperthreaded xeon P4 with HT enabled
> > and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos
> > for the two cases are indistinguishable.
> >
> > Jason
> >
> > -
>
> In the kernel that's no problem:
>
> A) If the BIOS writers followed Intel's guidelines, just look at the physical
> APIC IDs. HT siblings have odd IDs, the real ones have even.
>
> B) Check the siblings table built up at boot time and used by the scheduler.
>
> I don't know of any way to do this in userland. The whole point is that the
> sibling processors are supposed to look like real ones.
If the kernel has sched_setaffinity() or some other way of binding a process
to a given CPU (as numbered by the kernel, which may or may not be related
to any physical CPU numbers), then this will do it: execute CPUID on each
CPU and check the initial APIC ID field. If you find one that's non-zero,
then HT is enabled.
My performance monitoring counters driver uses this approach in kernel-space
using smp_call_function(). I don't use the siblings tables because they suck :-)
[I don't think they distinguish between logical CPUs #0 and #1, and they aren't
exported to modules. The CPUID check is simple and portable across kernel versions.]
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Tim Timmerman @ 2003-01-10 7:04 UTC (permalink / raw)
To: Val Henson; +Cc: linux-kernel
In-Reply-To: <20030109072043.GE26010@boardwalk>
>>>>> "Val" == Val Henson <val@nmt.edu> writes:
Val> On Wed, Jan 08, 2003 at 11:29:47AM +0900, Miles Bader wrote:
>>
>> If someone's mom (having heard the gossip) asks their computer-literate
>> child, `What is this XXX thing, anyway?', the answer is likely to be
>> very different when XXX is "GNU" as opposed to when XXX is "Linux".
Val> How come no one ever talks about a Linux distribution so easy that
Val> your grandfather could install it? Or a kernel configuration tool so
Val> simple that even Uncle Timmy can use it?
'make xconfig' works just fine for me.
(Uncle) Timmy
--
tim.timmerman@asml.nl 040-2683613
timt@timt.org Voodoo Programmer/Keeper of the Rubber Chicken
I've never seen electricity, so I don't pay for it. I write right on
the bill, 'I'm sorry, I haven't seen it all month.'
^ permalink raw reply
* Re: ymfpci, big-endian, and spdif out
From: Troy Benjegerdes @ 2003-01-10 6:55 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Takashi Iwai, alsa-devel@lists.sourceforge.net
In-Reply-To: <Pine.LNX.4.33.0301081229000.531-200000@pnote.perex-int.cz>
>
> > On Tue, Jan 07, 2003 at 05:02:53PM +0100, Takashi Iwai wrote:
> > > At Thu, 2 Jan 2003 22:22:34 -0600,
> > > Troy Benjegerdes wrote:
> > > >
> > > > I have a mac G4 (running debian testing), a ymfpci card (MaxiSound
> > > > Fortissimo) with optical TOSlink out, and a yamaha HTR-5540 receiver with
>
> There were a few bad assumtions in the spdif code. Could you try the
> latest CVS code of ac3dec (or attached patch)?
Okay, I've dumped some printk's in core/pcm_memory.c, and found that the
following error:
hozer@narn ac3dec$ ./ac3dec -C ~/testac3/THX.ac3
Using PCM device 'iec958:AES0=0x2,AES1=0x82,AES2=0x0,AES3=0x2'
ALSA lib pcm_hw.c:297:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS
failed: Cannot allocate memory
PCM hw_params failed: Cannot allocate memory
Output open failed
results in alsa-kernel/core/pcm_memory.c:alloc_pcm_pages() getting
called with substream->dma_type= SNDRV_PCM_DMA_TYPE_UNKNOWN.
This definitely seems to be a driver problem.. Do you think this is
related to PowerPC, or a general ymfpci driver problem?
Thanks.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: strange sparc64 -> i586 intermittent but reproducible NFS write errors to one and only one fs
From: Denis Vlasenko @ 2003-01-10 6:57 UTC (permalink / raw)
To: Nix, Linux Kernel Development
In-Reply-To: <87bs2q3paq.fsf@amaterasu.srvr.nix>
On 10 January 2003 00:56, Nix wrote:
> When I rebooted my systems into 2.4.20 (from 2.4.19), I started
> seeing EIO write() errors to files in my ext3 home directory
> (NFS-mounted, exported async).
>
> So I knocked up a test program (included below) to try to track the
> failing writes down, and got more confused.
>
> The properties of the failing writes that I've been able to determine
> thus far are as follows; look out, they're weird as hell:
>
> - the failures are definitely from write(), not open().
>
> - writes from sparc64 to one filesystem, and only one filesystem, on
> i586, both running 2.4.20, UDP NFSv3; rquotad and quotas are on,
> but I am well within my quota. (quota 3.06, nfs-utils 1.0). Writes to
> other filesystems on the same machine, even if they too are using
> ext3, even if they too have user quotas for the same user.
>
> What differs between filesystems that work and the one that fails
> I can't tell; other FSen *on the same block device* work... (the
> block device is an un-RAIDed SCSI disk.)
>
> - local writes to the same filesystem, with the same test program,
> never fail.
>
> - writes from another IA32 box (all these boxes are near-clones of
> each other as far as software is concerned) to the NFS server box
> never fail.
>
> - It happens if I mount the fs with -o soft (my default for all NFS
> mounts for robustness-in-the-presence-of-machine-failure reasons),
> but also if I mount with -o hard :(( besides, the timeouts happen
> far too fast for it to be major timeout expiry that casues the EIOs.
>
> - The failure always occurs for writes that cross the 2^21 byte
> boundary, but not all such writes fail. You seem to need to have
> done a lot of write()s before, perhaps even starting with O_TRUNC
> and write()ing like mad from there on up (the WRITES_PER_OPEN
> #define is a way to test that; I've never had a failure for a file
> opened with O_APPEND, even if it crossed the 2^21 byte boundary).
>
> - It happens whether _LARGEFILE_SOURCE / _FILE_OFFSET_BITS are
> defined or not (I'd be amazed if this affected it, actually, but
> it never hurts to check).
>
> - Despite the EIO, the write actually *succeeds* most of the time
> (perhaps not all the time; again, I'm not sure yet). In fact...
>
> - It is quite thoroughly inconsistent. If you #define REPRODUCE to 1
> in the test program and fill out sizes_to_reproduce[] with a set
> of write() sizes that have caused the error in the past, the error
> happens again, but not always:
This beast is most probably Sparc64 or 64-bit arch specific.
Try to pin down the first 2.4.20-preN where it appears.
Then inform NFS and Sparc64 folks.
If you won't get any useful hint by then, you can continue playing
patch-o-rama by reading changelog and slowly mutating last working
2.4.20-preN into first non-working pre.
--
vda
^ permalink raw reply
* reiserfsck --rebuild-tree aborted
From: John Fettig @ 2003-01-10 6:53 UTC (permalink / raw)
To: reiserfs-list
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
A brief explanation of my woes:
Upgrading hd, so was testing out a boot cd. Boot cd has Keeper Linux on
it, with 2.4.18 kernel. I mounted the the reiserfs partition, looked
around a bit, and rebooted. I forgot to unmount (and it was mounted
rw)...
The kernel on the drive (2.4.20) panics when I try to boot it without
the cd. I pop the cd back in, and try reiserfsck. It tells me to
backup (which was hopefully successful) and run reiserfsck
--rebuild-tree. I was using the reiserfsck from the mangled partition,
it allowed me to mount (this time read only) and some of the data was
still acessable. I believe the version was 3.x.0b, but not certain.
As per FAQ, I grabbed 3.6.4, tried it, and also the latest pre. All of
the versions give me the same error: it starts Pass 0, the meter goes to
100%, then on to Pass 1. It gives these errors:
build_the_tree: Nothing but leaves are expected. Block 8532-??22683
build_the_tree: Nothing but leaves are expected. Block 8580-??22660
pass1.c 405 pass1_correct_leaf
pass1_correct_leaf: block 8581, item 0, pointer 22: The wrong pointer
(944715855) in the file [7471218 636]. Must be fixed on pass0.
Aborted
The logfile is attached. If I you are already aware of the bug, and can
offer me a solution that will recover my data, I'll gladly pay you $25.
John
[-- Attachment #2: LOGFILE.LOG --]
[-- Type: text/plain, Size: 7566 bytes --]
####### Pass 0 #######
pass0: block 8432, item 110 114 0x26a10000 DIR (3), len 1600, location 2496 entry count 50, fsck need 1, format old: 8 entries were deleted
pass0: block 8479, item 7209070 114 0x6ae6d400 DIR (3), len 3040, location 1056 entry count 95, fsck need 1, format old: 11 entries were deleted
pass0: vpf-10460: block 8503, item 6: Wrong order of items - change the dir_id of the key [7471218 23200098 0x0 SD (0)] to 114
pass0: vpf-10600: block 8503, item 6: Wrong order of items - change the object_id of the key [114 23200098 0x0 SD (0)] to 354
pass0: vpf-10210: block 8532, item 0: The item with wrong offset or length found [7471218 470 0x1990199 DRCT (2)], len 880 - deleted
pass0: block 8553, item 7209070 114 0x47046280 DIR (3), len 3264, location 832 entry count 102, fsck need 1, format old: 10 entries were deleted
pass0: block 8558, item 110 114 0x3273aa80 DIR (3), len 2848, location 1248 entry count 89, fsck need 1, format old: 11 entries were deleted
pass0: vpf-10450: block 8565, item 0: Wrong order of items - change the dir_id of the key [7471218 582 0x1 DRCT (2)] to 114
pass0: block 8605, item 7209070 7471218 0x1 DIR (3), len 2928, location 1168 entry count 92, fsck need 1, format old: 13 entries were deleted
pass0: block 8609, item 3 13 0x1 DIR (3), len 104, location 3244 entry count 4, fsck need 1, format old: 1 entries were deleted
pass0: block 8624, item 110 114 0x58cd2500 DIR (3), len 2912, location 1184 entry count 91, fsck need 1, format old: 6 entries were deleted
pass0: block 8634, item 110 7471218 0x11b51e00 DIR (3), len 3072, location 1024 entry count 96, fsck need 1, format old: 14 entries were deleted
pass0: block 8661, item 1: StatData item of wrong length found 114 1023032570 0x0 SD (0), len 8, location 4044 entry count 0, fsck need 1, format new - deleted
pass0: vpf-10170: block 8661: item 1: Wrong order of items - the item
114 81146 0x2001 DRCT (2), len 656, location 3396 entry count 65535, fsck need 1, format new fixed to
114 81146 0x1 DRCT (2), len 656, location 3396 entry count 65535, fsck need 1, format new
pass0: block 8990, item 2 81888 0x1 DIR (3), len 2728, location 1368 entry count 102, fsck need 0, format old: 7 entries were deleted
pass0: vpf-10460: block 11903, item 2: Wrong order of items - change the dir_id of the key [554705168 1014447223 0x0 SD (0)] to 8464
pass0: vpf-10550: block 11903, item 2: Wrong order of items - change the object_id of the key [8464 1014447223 0x0 SD (0)] to 15479
pass0: block 30619, item 81888 81996 0x1 DIR (3), len 304, location 3568 entry count 11, fsck need 0, format old: 1 entries were deleted
pass0: vpf-10590: block 30619, item 10: Wrong order of items - change the object_id of the key [81888 1079787612 0x10001 DRCT (2)] to 82012
pass0: vpf-10170: block 30619: item 10: Wrong order of items - the item
81888 82012 0x10001 DRCT (2), len 424, location 2876 entry count 65535, fsck need 0, format new fixed to
81888 82012 0x1 DRCT (2), len 424, location 2876 entry count 65535, fsck need 0, format new
pass0: vpf-10160: block 30619: item 12: No "." entry found in the first item of a directory
block 30619: item 12: ".." is 0-th entry
pass0: block 30619, item 81888 82025 0x1 DIR (3), len 472, location 1632 entry count 19, fsck need 0, format old: 4 entries were deleted
86 directory entries were hashed with not set hash.
96202 directory entries were hashed with "r5" hash.
####### Pass 1 #######
pass1: block 8432, item 0, entry 2: The entry "E177E7E7d01" of the [110 114 0x26a10000 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8432, item 0, entry 27: The entry "5C573232d0d0" of the [110 114 0x26a10000 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8479, item 0, entry 14: The entry "A3A30808d0d0" of the [7209070 114 0x6af4ff00 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8479, item 0, entry 23: The entry "E5E74899d01" of the [7209070 114 0x6af4ff00 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8479, item 0, entry 39: The entry "E5E53737d0d0" of the [7209070 114 0x6af4ff00 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8479, item 0, entry 49: The entry "14B8B721d01" of the [7209070 114 0x6af4ff00 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8479, item 0, entry 53: The entry "9292B7B7d0d0" of the [7209070 114 0x6af4ff00 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8479, item 0, entry 70: The entry "7C7C5DC1d01" of the [7209070 114 0x6af4ff00 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
zero_nlink: The StatData [114 354 0x0 SD (0)] of the wrong format version (3112) - corrected to (1)
pass1: block 8553, item 0, entry 0: The entry "F0F05A98d01" of the [7209070 114 0x47046280 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 12: The entry "9F9FE998d01" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 39: The entry "0606E8E8d0d0" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 62: The entry "D0D04176d01" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 64: The entry "9620CB91d01" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 68: The entry "55901761d0d0" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 74: The entry "A6A67056d01" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 77: The entry "93491999d01" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8553, item 0, entry 81: The entry "EAEED5D5d0d0" of the [7209070 114 0x47417780 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8558, item 0, entry 11: The entry "1515DADAd0d0" of the [110 114 0x3273aa80 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8558, item 0, entry 16: The entry "CFD5E93Ed01" of the [110 114 0x3273aa80 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8558, item 0, entry 38: The entry "A61C80DDd0d0" of the [110 114 0x3273aa80 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8558, item 0, entry 54: The entry "67A81D95d0d0" of the [110 114 0x3273aa80 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8558, item 0, entry 56: The entry "4A2AFCC5d01" of the [110 114 0x3273aa80 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
pass1: block 8558, item 0, entry 64: The entry "A7679889d0d0" of the [110 114 0x3273aa80 DIR (3)] is hashed with not set whereas proper hash is "r5" - deleted
is_leaf_bad: block 8565 items 5 and 6: Wrong order of items:
7471218 585 0x0 SD (0), len 44, location 2876 entry count 65535, fsck need 1, format new
114 585 0x1 DRCT (2), len 368, location 2508 entry count 65535, fsck need 1, format new
is_leaf_bad: WARNING: The leaf (8565) is formatted badly. Will be handled on the the pass2.
^ permalink raw reply
* 2.4.19 USB Yes, 2.4.20 USB No
From: brian @ 2003-01-10 7:00 UTC (permalink / raw)
To: linux-kernel
Anyone know why USB support for my FXA32 disappeared between Linux kernel
2.4.19 to 2.4.20?
When I boot with 2.4.19 I get:
Jan 9 22:35:25 top kernel: usb-uhci.c: $Revision: 1.275 $ time 12:19:03 Nov 23 2002
Jan 9 22:35:25 top kernel: usb-uhci.c: High bandwidth mode enabled
Jan 9 22:35:25 top kernel: PCI: Setting latency timer of device 00:07.2 to 64
Jan 9 22:35:25 top kernel: usb-uhci.c: USB UHCI at I/O 0x1c00, IRQ 9
Jan 9 22:35:25 top kernel: usb-uhci.c: Detected 2 ports
Jan 9 22:35:25 top kernel: usb.c: new USB bus registered, assigned bus number 1
Jan 9 22:35:25 top kernel: hub.c: USB hub found
Jan 9 22:35:25 top kernel: hub.c: 2 ports detected
Jan 9 22:35:25 top kernel: PCI: Setting latency timer of device 00:07.3 to 64
Jan 9 22:35:25 top kernel: usb-uhci.c: USB UHCI at I/O 0x1c20, IRQ 9
Jan 9 22:35:25 top kernel: usb-uhci.c: Detected 2 ports
Jan 9 22:35:25 top kernel: usb.c: new USB bus registered, assigned bus number 2
Jan 9 22:35:25 top kernel: hub.c: USB hub found
Jan 9 22:35:25 top kernel: hub.c: 2 ports detected
Jan 9 22:35:25 top kernel: usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
Jan 9 22:35:26 top kernel: hub.c: USB new device connect on bus1/1, assigned device number 2
Jan 9 22:35:26 top kernel: dc2xx.c: USB Camera #0 connected, major/minor 180/80
Jan 9 22:35:29 top /etc/hotplug/usb.agent: ... no modules for USB product 0/0/0
Jan 9 22:35:29 top /etc/hotplug/usb.agent: ... no modules for USB product 0/0/0
Jan 9 22:35:29 top /etc/hotplug/usb.agent: Setup dc2xx for USB product 40a/111/100
Jan 9 22:35:29 top /etc/hotplug/usb.agent: Setup usbcam for USB product 40a/111/100
Jan 9 22:35:29 top /etc/hotplug/usb.agent: Module setup usbcam for USB product
When I boot with 2.4.20 I get:
Jan 9 22:54:00 top kernel: usb-uhci.c: $Revision: 1.275 $ time 23:08:09 Dec 23 2002
Jan 9 22:54:00 top kernel: usb-uhci.c: High bandwidth mode enabled
Jan 9 22:54:00 top kernel: usb-uhci.c: USB UHCI at I/O 0x1c00, IRQ 9
Jan 9 22:54:00 top kernel: usb-uhci.c: Detected 2 ports
Jan 9 22:54:01 top kernel: usb.c: new USB bus registered, assigned bus number 1
Jan 9 22:54:01 top kernel: hub.c: USB hub found
Jan 9 22:54:01 top kernel: hub.c: 2 ports detected
Jan 9 22:54:01 top kernel: usb-uhci.c: USB UHCI at I/O 0x1c20, IRQ 9
Jan 9 22:54:01 top kernel: usb-uhci.c: Detected 2 ports
Jan 9 22:54:01 top kernel: usb.c: new USB bus registered, assigned bus number 2
Jan 9 22:54:01 top kernel: hub.c: USB hub found
Jan 9 22:54:01 top kernel: hub.c: 2 ports detected
Jan 9 22:54:01 top kernel: usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
Jan 9 22:54:04 top /etc/hotplug/usb.agent: ... no modules for USB product 0/0/0
Jan 9 22:54:04 top /etc/hotplug/usb.agent: ... no modules for USB product 0/0/0
It is completely repeatable.
--
Brian Litzinger
^ permalink raw reply
* [PATCH] VISWS support for 2.5.55
From: Andrey Panin @ 2003-01-10 6:50 UTC (permalink / raw)
To: linux-visws-devel; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 226 bytes --]
Hi all,
attached patch brings SGI Visws support in 2.5.55 back to life.
Testers and comment are welcome :)
Best regards.
--
Andrey Panin | Embedded systems software developer
pazke@orbita1.ru | PGP key: wwwkeys.pgp.net
[-- Attachment #2: patch-visws-2.5.55-10.01.2003.bz2 --]
[-- Type: application/octet-stream, Size: 26185 bytes --]
^ permalink raw reply
* getting linux 7.3 to see scsi devices lun0 &lun1
From: Wayne @ 2003-01-10 6:47 UTC (permalink / raw)
To: gadio, linux-scsi
To whoever is in the mood;
Help..
Have read the 'howto' on the scsi section and can not get the os to see
lun1.
We are using a dual PIII 700mhz system 500meg of memory. This system
was running
linux 6.0 . We had a raid device attached to this system and the os saw
the raid as /dev/sda and
/dev/sdb. That was good. But only to find out that we were loosing
several hundred meg of space.
The file system was the /ext2 file system.
We needed to go to the /ext3 file system that creates the journald file
system so it would know how to handle the larger file sizes.
Tried changing the .config file for the kernel to look for multiple luns
by repacing the line;
CONFIG_SCSI=Y to read CONFIG_SCSI_MULTI_LUN
(from the document about scsi). No luck, still only lun0 shows up.
Were unable to try the
scsidev command. Tried the make config command, tried the
rescan-scsi-bus.sh command as well. No luck.
The scsi adaptor card is the adaptec high voltage aha-2944uw.
The raid is a tera-byte in size, has been used by a sun ultra as its
controller, reformatted and recreated to go from solaris to linux.
Again, linux 6.0 saw both raid data sets that were created.
Help, if you could, please.
Regards,
Wayne Arnold
^ permalink raw reply
* Re: Can't build sound drivers as modules (2.5.55)
From: Mikael Pettersson @ 2003-01-10 6:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Kernel Mailing List
In-Reply-To: <1042147153.4870.66.camel@dell_ss3.pdx.osdl.net>
Stephen Hemminger writes:
> When I try to install with sound as a configured module:
>
> WARNING: /lib/modules/2.5.55/kernel/sound/soundcore.ko needs unknown
> symbol
> errno
>
> This is new in 2.5.55, not sure where the missing bogus definition is.
> It looks like soundcore.ko contains sound_firmware.o which is seems to
> be more of an application than a driver (open/close)...
Someone removed the 'static int errno;' declaration in sound_firmware.c.
The sys calls it uses are apparently user-space versions with errno references.
The real fix is to delete the file altogether :-) Like the comments in it
say, firmware should be inserted by a user-space application.
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: Matti Aarnio @ 2003-01-10 6:52 UTC (permalink / raw)
To: David D. Hagood; +Cc: linux-kernel
In-Reply-To: <3E1E06A3.8050607@sktc.net>
On Thu, Jan 09, 2003 at 05:32:51PM -0600, David D. Hagood wrote:
> Well, I found out that while we have the DTMF test tape at work, it is
> exactly that - a cassette tape that is copyrighted. So, no easy/legal
> way to make it available for testing...
What does such tape contain ?
- DTMF tones buried in various degrees of distortions,
which should be decodable ?
- DTMF tones buried in varying noises which should not be
decodable ?
- Other multi-tone signals which should not decode ?
For the last, I know of cases where test was done by playing a radio
station on the decoder for 2-3 days, and seeing when does it trigger
DTMFs (if ever).
For that matter, the Linux kernel ISDN audio DTMF detection is exactly
of the last variant.
/Matti Aarnio
^ permalink raw reply
* [NEOFB, 2.5.54] panic when initializing
From: Jochen Hein @ 2003-01-10 6:39 UTC (permalink / raw)
To: linux-kernel
The boot messages are (I use vga=0x317 as command line)
Video mode to be used for restore is 317
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000005fd0000 (usable)
BIOS-e820: 0000000005fd0000 - 0000000005fdf000 (ACPI data)
BIOS-e820: 0000000005fdf000 - 0000000005fe0000 (ACPI NVS)
BIOS-e820: 0000000005fe0000 - 0000000006000000 (reserved)
BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
95MB LOWMEM available.
[...]
neofb: mapped io at c680d000
Autodetected internal display
Panel is a 1024x768 color TFT display
neofb: mapped framebuffer at c6a0e000
neofb v0.4.1: 2048kB VRAM, using 1024x768, 48.361kHz, 60Hz
fb0: MagicGraph 128XD frame buffer device
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0261cfb
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c0261cfb>] Not tainted
EFLAGS: 00010202
EIP is at neofb_check_var+0x7d3/0x844
eax: c5ecdd7c ebx: 00000325 ecx: 00000000 edx: 000003d5
esi: c5ecdd7c edi: c5ecdc00 ebp: c5f79f48 esp: c5f79ef0
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=c5f78000 task=c5f76040)
Stack: c5ec9800 00000010 c5ecdc00 c5f79f28 000000a5 0000007b c5ecdc0c 0000005e
c01354f4 00000000 0000fde6 00000400 00000418 000004a0 00000540 00000300
00000303 00000309 00000326 00000003 00000000 00000000 c5f79f68 c025bda8
Call Trace:
[<c01354f4>] poison_obj+0x30/0x58
[<c025bda8>] accel_cursor+0x1e8/0x22c
[<c022b517>] clear_buffer_attributes+0x17/0x180
[<c0105096>] do_pre_smp_initcalls+0x2e/0x178
[<c0105068>] do_pre_smp_initcalls+0x0/0x178
[<c0107211>] show_regs+0x5/0xc
Code: 8b 01 a8 01 74 08 89 ca 8b 02 a8 01 75 fa 8b 55 c0 8b 42 18
<0>Kernel panic: Attempted to kill init!
--
#include <~/.signature>: permission denied
^ permalink raw reply
* Re: 2.5.55: local symbols in net/ipv6/af_inet6.o
From: David S. Miller @ 2003-01-10 6:40 UTC (permalink / raw)
To: andersg; +Cc: Niels.denOtter, linux-kernel
In-Reply-To: <20030109231834.GD3345@gagarin>
From: Anders Gustafsson <andersg@0x63.nu>
Date: Fri, 10 Jan 2003 00:18:34 +0100
On Thu, Jan 09, 2003 at 10:10:26AM +0100, Niels den Otter wrote:
> The reference_discarded.pl script says following:
> pangsit:/usr/src/linux/net> perl ~otter/reference_discarded.pl
> Finding objects, 245 objects, ignoring 0 module(s)
> Finding conglomerates, ignoring 11 conglomerate(s)
> Scanning objects
> Error: ./ipv6/af_inet6.o .init.text refers to 000003e4 R_386_PC32 .exit.text
> Done
>
> I tried both gcc-2.95 & gcc-3.2.2 .
This patch shoul fix it, the problem is that cleanup_ipv6_mibs can't be
__exit as it's called on ipv6_init's errorpath.
I've applied your patch, thanks.
^ permalink raw reply
* Re: DMA timeouts on Promise 20267 IDE card
From: Manish Lachwani @ 2003-01-10 6:47 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <233C89823A37714D95B1A891DE3BCE5202AB1B7F@xch-a.win.zambeel.com>
check the CRC count on the first drive, hda. Its
65584 !!! Thats huge. This
CRC values result in UDMA downgrades. Also, check
the reallocation sector
count. A high value here means possible timeouts.
With high reallocation
sector count, there could be multiple mappings a
drive would have to look
into to get to the proper sector. You should change
the drive hda and also
the cable. Then try again.
Thanks
Manish
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: ISO-9660 Rock Ridge gives different links different inums
From: Denis Vlasenko @ 2003-01-10 6:34 UTC (permalink / raw)
To: Peter Chubb, Andrew McGregor; +Cc: eric, linux-kernel
In-Reply-To: <15902.16227.924630.143293@wombat.chubb.wattle.id.au>
On 10 January 2003 05:34, Peter Chubb wrote:
> >> I don't know enough about the ISO9660 standard to be sure what's
> >> best to do about this.
>
> Andrew> Change it to be the offset to the data area, which should be
> Andrew> the same for all of them?
>
> I thought about that, but I'm unsure if there's any way to get from
> that offset to the directory information. As far as I can tell,
> there's no concept of an inode separate from directory entry on
> iso9660 --- the directory entry/entries all contain all the
> information that describes a file. Which means that the inumber has
> to point to some directory node.
>
> Preferably, all the inumbers for the same file would point to the
> same directory entry; but I can see no easy way to do that. Keeping
> an in-memory table for files with multiple links might be the best
> way, as there aren't that many on a typical filesystem.
And what will happen on a non-typical filesystem with 1 million hardlinks?
The root of the problem is a fundamental layering violation in
traditional Unix filesystems: inode numbers should NOT be visible
to userspace. Userspace just needs a way to tell hardlinks from separate
files, that's all. Exposing inumbers does that, but creates tons
of problems for filesystems which do NOT have such a concept.
There is at least one way to redesign it:
* provide hash number instead of an inumber for each file
with the following semantics:
- hardlinks ALWAYS have equal hash numbers
- different files MAY have equal hash numbers (but rarely)
* provide is_hardlink(file1,file2) system call
But this will cause very long migration period (~10 years?)
and incompatibilities with other Unix variants...
--
vda
^ permalink raw reply
* ksoftirqd_CPU0 causing severe latency
From: Jim Roland @ 2003-01-10 6:41 UTC (permalink / raw)
To: linux-kernel
I am running a RH7.2 router with kernel 2.4.18-19.7.x and upgraded from
2.4.18-17 in hopes this would fix the problem, but it hasn't.
The problem I am experiencing is that after a while, the system begins to
lag badly, and running "ps -ax" writes to a SSH console like a terminal
running at 14.4kbps. This only seems to have occurred after the box
started procesing a network load.
The box is a router, with a Supermicro (model=?) motherboard with embedded
Intel EEpro/100 NICs using the eepro100 module. This box is also serving
as an iptables filter for the network as well. It's processing
approximately 60Mbps sustained traffic outbound, and about 10-15Mbps
traffic inbound.
The box also lags SEVERLY when I'm trying to use the state matching in the
kernel (as module), lagging badly when ip_conntrack is loaded.
In contrast, I am running the same OS and kernel versions on another box
(same modules) and am not having the same problem (it is only handling
about 5Mbps sustained out, and 1Mbps sustained inbound).
I need HELP!
Here are the specs on the troubled system:
Intel P3-1.0GHz, 512MB RAM, 2x Intel EEPro/100 (eepro100 module)
Dual CPU board, w/o 2nd CPU, running non-smp kernel (uniprocessor kernel).
Module List (system runnin at its best):
Module Size Used by Not tainted
cls_route 5056 0 (unused)
cls_u32 5764 1
cls_fw 3264 0 (unused)
sch_prio 3552 0 (unused)
sch_sfq 4512 0 (unused)
sch_tbf 3264 2
sch_cbq 14080 1
autofs 11172 0 (autoclean) (unused)
eepro100 20240 2
ipt_REJECT 3744 22 (autoclean)
iptable_filter 2464 1 (autoclean)
ip_tables 13696 2 [ipt_REJECT iptable_filter]
ext3 64768 5
jbd 47892 5 [ext3]
PID TTY STAT TIME COMMAND
1 ? S 1:43 init [3]
2 ? SW 0:00 [keventd]
3 ? SW 2:17 [kapmd]
4 ? RWN 506:27 [ksoftirqd_CPU0]
5 ? SW 1:34 [kswapd]
6 ? SW 0:00 [bdflush]
7 ? SW 0:31 [kupdated]
8 ? SW 0:00 [mdrecoveryd]
12 ? SW 0:56 [kjournald]
134 ? SW 0:00 [kjournald]
135 ? SW 0:00 [kjournald]
136 ? SW 0:47 [kjournald]
137 ? SW 0:27 [kjournald]
598 ? S 0:21 syslogd -m 0
603 ? S 0:01 klogd -2
641 ? SL 7:34 ntpd -U ntp
695 ? S 0:49 /usr/sbin/snmpd -s -l /dev/null -P
/var/run/snmpd -a
713 ? S 0:07 /usr/sbin/sshd
746 ? S 0:00 xinetd -stayalive -reuse -pidfile
/var/run/xinetd.pid
787 ? S 0:15 crond
823 ? S 0:00 /usr/sbin/atd
829 ? S 0:00 /etc/bkupexec/agent.be -c
/etc/bkupexec/agent.cfg
843 ? SN 2:01 /etc/bkupexec/agent.be -c
/etc/bkupexec/agent.cfg
850 ? S 0:16 rhnsd --interval 120
891 ? S 2:24 /usr/bin/perl /usr/libexec/webmin/miniserv.pl
/etc/we
895 tty1 S 0:00 /sbin/mingetty tty1
896 tty2 S 0:00 /sbin/mingetty tty2
897 tty3 S 0:00 /sbin/mingetty tty3
898 tty4 S 0:00 /sbin/mingetty tty4
899 tty5 S 0:00 /sbin/mingetty tty5
900 tty6 S 0:00 /sbin/mingetty tty6
5409 ? S 1:42 /usr/sbin/sshd
5410 pts/0 S 0:22 -bash
5552 ? S 0:11 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5558 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5559 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5560 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5561 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5562 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5563 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5564 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5565 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5653 pts/0 R 0:01 ps -ax
4:23pm up 1 day, 22:33, 1 user, load average: 0.66, 0.73, 0.81
43 processes: 41 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 1.3% user, 1.3% system, 0.0% nice, 20.4% idle
Mem: 513032K av, 183252K used, 329780K free, 0K shrd, 105560K
buff
Swap: 257000K av, 0K used, 257000K free 47172K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
5655 root 19 0 1028 1024 824 R 33.6 0.1 0:01 top
4 root 35 19 0 0 0 RWN 18.8 0.0 506:40
ksoftirqd_CPU0
641 ntp 15 0 1932 1932 1732 S 0.6 0.3 7:35 ntpd
1 root 15 0 508 508 440 S 0.0 0.0 1:43 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 15 0 0 0 0 SW 0.0 0.0 2:17 kapmd
5 root 15 0 0 0 0 SW 0.0 0.0 1:34 kswapd
6 root 25 0 0 0 0 SW 0.0 0.0 0:00 bdflush
7 root 15 0 0 0 0 SW 0.0 0.0 0:31 kupdated
8 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd
12 root 15 0 0 0 0 SW 0.0 0.0 0:56 kjournald
134 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald
135 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald
136 root 15 0 0 0 0 SW 0.0 0.0 0:47 kjournald
137 root 16 0 0 0 0 SW 0.0 0.0 0:27 kjournald
598 root 15 0 612 612 516 S 0.0 0.1 0:21 syslogd
603 root 15 0 1208 1208 448 S 0.0 0.2 0:01 klogd
695 root 16 0 2940 2940 1844 S 0.0 0.5 0:49 snmpd
^ permalink raw reply
* Re: PMS messaging program: where?
From: pa3gcu @ 2003-01-10 6:27 UTC (permalink / raw)
To: Tim Neu, Jacques Chion, Tim Neu; +Cc: linux-hams
In-Reply-To: <20030109220627.M32751@tneu.visi.com>
On Thursday 09 January 2003 22:06, Tim Neu wrote:
> On Thu, 9 Jan 2003 22:04:19 +0100 (CET), Jacques Chion wrote
>
> > Hello,
> > you can find that program in ax25-utils-2.1.42.a-3 package.
> > Best 73
>
> Hmm. When I try to intstall ax25-utils on debian, it claims that ax25utils
> is replaced by ax25-tools...
>
> I _do_ have ax25-tools installed, though, but it does not have pms.
> Evidently ax25-tools does not completely replace all funtionality of
> ax25-utils, or the debian package folks have their wires crossed.
>
> I will give a search for ax25-utils. Thanks for the help.
As Tomi explained PMS is not part of anything thesedays, however i still use
it on my system, i can suplly you with a binary, however there is no garentee
it will work, it works on a slackware 8.0 system using;
ax25-apps-0.0.4.
ax25-tools-0.0.5
libax25-0.0.7
node-0.3.0
Let me know if you want it.
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Miles Bader @ 2003-01-10 6:31 UTC (permalink / raw)
To: Andre Hedrick; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.10.10301092202210.31168-100000@master.linux-ide.org>
Andre Hedrick <andre@linux-ide.org> writes:
> Only when LKML can remove the advertising value of the wars cached on all
> the web search engines will this forum be free of off topics. The bad
> press is still press. People's self interest to rack up hits in a search
> engine, is why much of the self promotion happens.
Are you on drugs, or just joking?
The reason these flame wars get so big is because people feel strongly
about their point of view (no matter how misguided it may be), and
morever, many people simply like to argue.
-Miles
--
Love is a snowmobile racing across the tundra. Suddenly it flips over,
pinning you underneath. At night the ice weasels come. --Nietzsche
^ permalink raw reply
* NFS client stall within __lock_page()
From: miyoshi @ 2003-01-10 6:19 UTC (permalink / raw)
To: nfs; +Cc: tanaka-h
Hi, all.
I am using kernel 2.4.17 as an NFS client (server is HP-UX)
and one of client processes hangs and never wakes up.
>From kdb backtrace (attached), I found that the client process
stalls within nfs write and never returns (kill -9 is not accepted.)
It sleeps on __lock_page.
sys_write
->nfs_file_write
->generic_file_write
->__find_lock_page
->lock_page
-> __lock_page
I am not so sure that this is actually the nfs problem (because the
process stalls on upper layer than nfs) but other processes or kernel
daemons seem to sleep normally, compared with live-and-well system.
So, I think the acitivity of the NFS client just before the stall
may be suspicious (?)
The machine itself is alive and I can log into it and get information
via lcrash. I appreciate if you provide me where to investigate.
BTW, Filesystem in question is mounted as:
file:/xxxx/yyyy on /xxxx/yyyy type nfs
(rw,rsize=16384,wsize=16384,timeo=14,nfsvers=3,intr,
bg,addr=zzz.zzz.zzz.zzz)
Do you have any idea??
- whole backtrace of the client in question
Stack traceback for pid 5172
0xe0000000044ee740 schedule+0xbe0
args (0xe000000102faf618, 0xe00000000452b140, 0x50c, 0xe0000004a5e94ec0, 0x0)
kernel .text 0xe000000004400000 0xe0000000044edb60 0xe0000000044ee920
0xe00000000452b160 __lock_page+0x160
args (0xe000000102faf600, 0xe000000004c4f340, 0xe0000001176b0000, 0xe000000102faf630, 0xe000000102faf610)
kernel .text 0xe000000004400000 0xe00000000452b000 0xe00000000452b220
0xe00000000452b2a0 lock_page+0x80
args (0xe000000102faf600, 0xe00000000452b6e0, 0x307)
kernel .text 0xe000000004400000 0xe00000000452b220 0xe00000000452b2c0
0xe00000000452b6e0 __find_lock_page_helper+0x140
args (0xe0000004a5e95000, 0x5c78, 0xe000000102faf600, 0xe000000102faf600, 0xe00000000452b860)
kernel .text 0xe000000004400000 0xe00000000452b5a0 0xe00000000452b7e0
0xe00000000452b860 __find_lock_page+0x80
args (0xe0000004a5e95000, 0x5c78, 0xe0000002fd6c7e18, 0xe000000004cb4d80, 0xe000000004531ad0)
kernel .text 0xe000000004400000 0xe00000000452b7e0 0xe00000000452b880
0xe000000004531ad0 generic_file_write+0x750
args (0xe0000006fd760900, 0x6000000000718cb0, 0x4000, 0xe0000006fd760938, 0x0)
kernel .text 0xe000000004400000 0xe000000004531380 0xe000000004532080
0xe0000000045f2130 nfs_file_write+0x230
args (0xe0000006fd760900, 0x6000000000718cb0, 0x4000, 0xe0000006fd760938, 0xe0000004a5e94ec0)
kernel .text 0xe000000004400000 0xe0000000045f1f00 0xe0000000045f2160
0xe000000004551bf0 sys_write+0x210
args (0x8, 0x6000000000718cb0, 0x4000, 0x60000000005d7afc, 0x2fa11)
kernel .text 0xe000000004400000 0xe0000000045519e0 0xe000000004551ca0
0xe0000000044922e0 ia64_ret_from_syscall
args (0x8, 0x6000000000718cb0, 0x4000)
kernel .text 0xe000000004400000 0xe0000000044922e0 0xe000000004492300
Regards,
--
MIYOSHI Kazuto <miyoshi@hpc.bs1.fc.nec.co.jp>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Ethernet Conexant LANfinity doesnt send anything
From: Adriano Carvalho @ 2003-01-10 6:12 UTC (permalink / raw)
To: linux-kernel
--
Hi,
I need some help. I have a Compaq Laptop 1400 14xl244, with Modem HCF
conexant , and ethernet card Conexant LANfinity. They are COMBO, and they
use IRQ 11.
When I startup module (tulip) for my ethernet card, its ok. But when I try
send or receive anything, I dont get. PCMCIA card uses IRQ 11 too, so I
get
it out from kernel, but it doesnt solve. Here is my /proc/interrupts :
11: 20 XT-PIC hcf, eth0
this was after a time of try ping, and the number "20" after stays 1691,
after 2000...
Donald Becker (tulip developer) told me to send these lines :
Compaq 12XL125 machine detected. Enabling interrupts during APM calls.
...
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
..
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
PCI: Found IRQ 11 for device 00:0a.0
PCI: Sharing IRQ 11 with 00:09.0
PCI: Sharing IRQ 11 with 00:09.1
PCI: Disabling Via external APIC routing
anybody can help me ??
Thanks for all.
Adriano Carvalho.
PS: Sorry if it wasnt to put anything in Subject.
_________________________________________________________________
MSN Messenger: converse com os seus amigos online.
http://messenger.msn.com.br
^ permalink raw reply
* Re: Megaraid crash (Blocked mailbox......!!) with 2.4.19-aa and 2.4.20-aa
From: Andy Johnson @ 2003-01-10 6:13 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <fa.i7lhfnc.1ulm3ac@ifi.uio.no>
Pasi Kärkkäinen wrote:
> Hello!
>
> I've seen this at least 5 times now in one month.. One of our boxes die
> when postgresql maintenance script AND backup cron jobs are ran at the =
> same
> time (by mistake - normally they are not ran at the same time)..
>
> So it seems to be related to high disk i/o. The adapter is
> HP NetRAID 1M with latest firmware. There is one RAID5 array with 3 dis=
> ks
> configured to it.
>
> Usually this crash happens 1 to 2 times a week.. always when cron start=
> s to
> run the stuff at the night. The console will be flooded with "Blocked
> mailbox......!!" text (which surprisingly means that the megaraid firmw=
> are
> has stopped responding.. according to google)
>
> This box doesn't have high disk i/o at the daytime, only at the night w=
> hen
> cron starts to do things..
>
> When the cron jobs are not ran at the same time, the box is stable.
>
>
> Other box using the same kind of adapter, but RAID1 array instead, havi=
> ng
> high disk i/o all the time doesn't have any problems.. (with the same k=
> ernels).
>
>
> Kernels are compiled with gcc 2.95.4 (Debian 3.0).
>
>
> Any thoughts?
I saw this on one of our boxes running RH 6.2 with the 2.2.16 kernel
a few times in one month. Software doesn't get old and break, usually,
so I turned the box off, reseated all the drives, and after I turned it
back on, we never had that problem again. I think this is one of those
intermittent hardware problems. The kind that are the most "fun" to
solve.
Good Luck,
Andy Johnson
>
>
> -- Pasi Kärkkäinen
>
> ^
> . .
> Linux
> / - \
> Choice.of.the
> .Next.Generation.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [TRIVIAL] Squash unused function in fs/nfs/mount_clnt.c
From: David Gibson @ 2003-01-10 6:11 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel; +Cc: trivial
Linus, please apply. The xdr_error() function in fs/nfs/mount_clnt.c
is never used, so this patch removes it.
diff -urN /home/dgibson/kernel/linuxppc-2.5/fs/nfs/mount_clnt.c linux-bluefish/fs/nfs/mount_clnt.c
--- /home/dgibson/kernel/linuxppc-2.5/fs/nfs/mount_clnt.c 2002-12-04 10:58:01.000000000 +1100
+++ linux-bluefish/fs/nfs/mount_clnt.c 2003-01-10 16:43:03.000000000 +1100
@@ -93,12 +93,6 @@
* XDR encode/decode functions for MOUNT
*/
static int
-xdr_error(struct rpc_rqst *req, u32 *p, void *dummy)
-{
- return -EIO;
-}
-
-static int
xdr_encode_dirpath(struct rpc_rqst *req, u32 *p, const char *path)
{
p = xdr_encode_string(p, path);
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Andre Hedrick @ 2003-01-10 6:07 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030110053305.GD14778@waste.org>
Only when LKML can remove the advertising value of the wars cached on all
the web search engines will this forum be free of off topics. The bad
press is still press. People's self interest to rack up hits in a search
engine, is why much of the self promotion happens.
I am looking in the mirror and wonder why did I even reply or expose the
benefits of such debate.
GAK!
On Thu, 9 Jan 2003, Oliver Xymoron wrote:
> On Thu, Jan 09, 2003 at 06:14:37PM -0500, Richard Stallman wrote:
> [GNU/Linux stuff deleted]
>
> Can we all agree that this is indeed the kernel list and that the
> kernel is indeed known as simply 'Linux' and that therefore the
> GNU/Linux debate is off-topic here?
>
> --
> "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Brian Tinsley @ 2003-01-10 5:45 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <20030110052439.GL23814@holomorphy.com>
>
>
>Okay, can you try with either 2.4.x-aa or 2.5.x-CURRENT?
>
Yes, I *just* booted a machine with 2.4.20-aa1 in our lab. I was having
problems compiling the Linux Virtual Server code, but it's fixed now.
>I'm suspecting either bh problems or lowpte problems.
>
>Also, could you monitor your load with the scripts I posted?
>
>
Yes, they are already uploaded to a customer site and ready to go. I
need to flex the -aa1 kernel a bit before I load it there as well.
Thanks!
^ permalink raw reply
* Re: Reg iptables Connection tracking
From: Joel Newkirk @ 2003-01-10 5:32 UTC (permalink / raw)
To: Amit Kumar Gupta, netfilter
In-Reply-To: <4223A04BF7D1B941A25246ADD0462FF5647695@blr-m3-msg.wipro.com>
On Friday 10 January 2003 12:03 am, Amit Kumar Gupta wrote:
> Hi List,
>
> I am getting a problem with iptables :-
>
> I have added some rules in which I check the states of the packets
> which I receive i.e. whether it is NEW, ESTABLISHED or INVALID and
> then do some actions.
>
> Now the problem which I am getting is :- (However I have already
> posted a si ilar query reg this but I think this will be more
> elaborative).
>
> As soon as somebody pings to my m/c , that fellow doesn't get the
> reply and on my m/c , kernel keeps dumping certain messages which are
> like this :-
>
> Ip_contrack: maximum limit of 1016 entries exceeded.
Well, that's what's happening then. The conntrack table is filling. The
real question is "why"? How many machines are connected to/through this
one, how many interfaces, subnets, etc? Ping from LAN to firewall box,
internet to LAN, what? Just this box on the internet? You need to
elaborate still further for anyone to have much chance figuring out the
source of your problem. Since the conntrack limit is being reached, try
"cat /proc/net/conntrack" and see what it's filled with. (Probably 1016
entries, but are they all legitimate traffic, or what?)
Conntrack is used for state and NAT both. It might help if you also
included the new state rules you added, and any NAT or state rules that
were already in place.
j
^ permalink raw reply
* Re: [Lse-tech] Minature NUMA scheduler
From: Michael Hohnbaum @ 2003-01-10 5:36 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Erich Focht, Robert Love, Ingo Molnar, linux-kernel, lse-tech
In-Reply-To: <52570000.1042156448@flay>
On Thu, 2003-01-09 at 15:54, Martin J. Bligh wrote:
> I tried a small experiment today - did a simple restriction of
> the O(1) scheduler to only balance inside a node. Coupled with
> the small initial load balancing patch floating around, this
> covers 95% of cases, is a trivial change (3 lines), performs
> just as well as Erich's patch on a kernel compile, and actually
> better on schedbench.
>
> This is NOT meant to be a replacement for the code Erich wrote,
> it's meant to be a simple way to get integration and acceptance.
> Code that just forks and never execs will stay on one node - but
> we can take the code Erich wrote, and put it in seperate rebalancer
> that fires much less often to do a cross-node rebalance.
I tried this on my 4 node NUMAQ (16 procs, 16GB memory) and got
similar results. Also, added in the cputime_stats patch and am
attaching the matrix results from the 32 process run. Basically,
all runs show that the initial load balancer is able to place the
tasks evenly across the nodes, and the better overall times show
that not migrating to keep the nodes balanced over time results
in better performance - at least on these boxes.
Obviously, there can be situations where load balancing across
nodes is necessary, but these results point to less load balancing
being better, at least on these machines. It will be interesting
to repeat this on boxes with other interconnects.
$ reportbench hacksched54 sched54 stock54
Kernbench:
Elapsed User System CPU
hacksched54 29.406s 282.18s 81.716s 1236.8%
sched54 29.112s 283.888s 82.84s 1259.4%
stock54 31.348s 303.134s 87.824s 1247.2%
Schedbench 4:
AvgUser Elapsed TotalUser TotalSys
hacksched54 21.94 31.93 87.81 0.53
sched54 22.03 34.90 88.15 0.75
stock54 49.35 57.53 197.45 0.86
Schedbench 8:
AvgUser Elapsed TotalUser TotalSys
hacksched54 28.23 31.62 225.87 1.11
sched54 27.95 37.12 223.66 1.50
stock54 43.14 62.97 345.18 2.12
Schedbench 16:
AvgUser Elapsed TotalUser TotalSys
hacksched54 49.29 71.31 788.83 2.88
sched54 55.37 69.58 886.10 3.79
stock54 66.00 81.25 1056.25 7.12
Schedbench 32:
AvgUser Elapsed TotalUser TotalSys
hacksched54 56.41 117.98 1805.35 5.90
sched54 57.93 132.11 1854.01 10.74
stock54 77.81 173.26 2490.31 12.37
Schedbench 64:
AvgUser Elapsed TotalUser TotalSys
hacksched54 56.62 231.93 3624.42 13.32
sched54 72.91 308.87 4667.03 21.06
stock54 86.68 368.55 5548.57 25.73
hacksched54 = 2.5.54 + Martin's tiny NUMA patch +
03-cputimes_stat-2.5.53.patch +
02-numa-sched-ilb-2.5.53-21.patch
sched54 = 2.5.54 + 01-numa-sched-core-2.5.53-24.patch +
02-ilb-2.5.53-21.patch02 +
03-cputimes_stat-2.5.53.patch
stock54 - 2.5.54 + 03-cputimes_stat-2.5.53.patch
Detailed results from running numa_test 32:
Executing 32 times: ./randupdt 1000000
Running 'hackbench 20' in the background: Time: 4.557
Job node00 node01 node02 node03 | iSched MSched | UserTime(s)
1 100.0 0.0 0.0 0.0 | 0 0 | 57.12
2 0.0 100.0 0.0 0.0 | 1 1 | 55.89
3 100.0 0.0 0.0 0.0 | 0 0 | 55.39
4 0.0 0.0 100.0 0.0 | 2 2 | 56.67
5 0.0 0.0 0.0 100.0 | 3 3 | 57.08
6 0.0 100.0 0.0 0.0 | 1 1 | 56.31
7 100.0 0.0 0.0 0.0 | 0 0 | 57.11
8 0.0 0.0 0.0 100.0 | 3 3 | 56.66
9 0.0 100.0 0.0 0.0 | 1 1 | 55.87
10 0.0 0.0 100.0 0.0 | 2 2 | 55.83
11 0.0 0.0 0.0 100.0 | 3 3 | 56.01
12 0.0 100.0 0.0 0.0 | 1 1 | 56.56
13 0.0 0.0 100.0 0.0 | 2 2 | 56.31
14 0.0 0.0 0.0 100.0 | 3 3 | 56.40
15 100.0 0.0 0.0 0.0 | 0 0 | 55.82
16 0.0 100.0 0.0 0.0 | 1 1 | 57.47
17 0.0 0.0 100.0 0.0 | 2 2 | 56.76
18 0.0 0.0 0.0 100.0 | 3 3 | 57.10
19 0.0 100.0 0.0 0.0 | 1 1 | 57.26
20 0.0 0.0 100.0 0.0 | 2 2 | 56.48
21 0.0 0.0 0.0 100.0 | 3 3 | 56.65
22 0.0 100.0 0.0 0.0 | 1 1 | 55.81
23 0.0 0.0 100.0 0.0 | 2 2 | 55.77
24 0.0 0.0 0.0 100.0 | 3 3 | 56.91
25 0.0 100.0 0.0 0.0 | 1 1 | 56.86
26 0.0 0.0 100.0 0.0 | 2 2 | 56.62
27 0.0 0.0 0.0 100.0 | 3 3 | 57.16
28 0.0 0.0 100.0 0.0 | 2 2 | 56.36
29 100.0 0.0 0.0 0.0 | 0 0 | 55.72
30 100.0 0.0 0.0 0.0 | 0 0 | 56.00
31 100.0 0.0 0.0 0.0 | 0 0 | 55.48
32 100.0 0.0 0.0 0.0 | 0 0 | 55.59
AverageUserTime 56.41 seconds
ElapsedTime 117.98
TotalUserTime 1805.35
TotalSysTime 5.90
Runs with 4, 8, 16, and 64 processes all showed the same even
distribution across all nodes and 100% time on node for each
process.
--
Michael Hohnbaum 503-578-5486
hohnbaum@us.ibm.com T/L 775-5486
^ 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.