* Re: [parisc-linux] Re: floating point exception error
From: John David Anglin @ 2003-01-10 18:48 UTC (permalink / raw)
To: jim.hull; +Cc: randolph, parisc-linux
In-Reply-To: <003101c2b8d3$477c8bb0$6763f40f@cup.hp.com>
> What it does not explain is why the original message reported a
> difference between a PA-8600 and a PA-8700. According to every internal
> HP processor document and PA-RISC FP designer I've been able to track
> down, this area of the design hasn't been changed since the original
> PA-8000, so there shouldn't be any differences in behavior.
I looked at the assembly code. The original test was done under hpux.
I see that the call to ull2dbl has been optimized out of the loop. It
is just called once. So, the code probably is trapping there as well.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440) [rescued]
From: Brian Tinsley @ 2003-01-10 18:34 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
>William Lee Irwin III wrote:
>
>
>>>IMHO multiprogramming is as valid a use for memory as any other. Or
>>>even otherwise, it's not something I care to get in design debates
>>>about, it's just how the things are used.
>>>
>>>
>
>On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
>
>
>>I agree with the philosophy in general, but if I sit down to write a
>>threaded application for Linux on IA-32 and wind up with a design that
>>uses 800+ threads in any instance (other than a bug, which was our
>>case), it's time to give up the day job and start riding on the back of
>>the garbage truck ;)
>>
>>
>
>I could care less what userspace does: mechanism, not policy. Userspace
>wants, and I give if I can, just as the kernel does with system calls.
>
>800 threads isn't even a high thread count anyway, the 2.5.x testing
>was with a peak thread count of 100,000. 800 threads, even with an 8KB
>stack, is no more than 6.4MB of lowmem for stacks and so shouldn't
>stress the system unless many instances of it are run.
>
I understand your perspective here. I won't get into application design
issues as it is far out of context from this list.
>I suspect your issue is elsewhere. I'll submit accounting patches for Marcelo's and/or Andrea's trees so you can find out what's actually going on.
>
Much appreciated! I look forward to it.
>On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
>
>
>>In all honesty, I would enjoy nothing more than contributing to kernel
>>development. Unfortunately it's a bit out of my scope right now (but not forever). If I only believed aliens seeded our gene pool with clones, I could hook up with those folks that claim to have cloned a human and get one of me made! ;)
>>
>>
>
>I don't know what to tell you here. I'm lucky that this is my day job
>and that I can contribute so much. However, there are plenty who
>contribute major changes (many even more important than my own) without
>any such sponsorship. Perhaps emulating them would satisfy your wish.
>
It would!
I cannot say thanks enough for the efforts of you and everyone else out
there. Frankly, I would not have my day job and would not have been able
to make Emageon what it is today were it not for you all!
Oh, please excuse the stupid humor tonight. I'm in a giddy mood for some
reason. Must be the excitement from the prospect of getting resolution
to this problem!
-
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
* Stupid SMBUS question...
From: Michael Knigge @ 2003-01-10 18:56 UTC (permalink / raw)
To: linux-kernel
Hi,
I'm working on a tool that can display information of a computer's
hardware. For this I want to parse the SMBIOS-Structure. I know that I
could search /proc/kcore for the "_SM_" eyecatcher, but I wonder if
there is a "easier" way to get the information (so the tool don't have
to run setuid-root).
Is there a way?
Thank you in advance and have a nice weekend,
Michael
^ permalink raw reply
* [linux-lvm] pvcreate -- device "/dev/hdc" has a partition table: force check bypass?
From: Donald Gordon @ 2003-01-10 18:51 UTC (permalink / raw)
To: linux-lvm
Hi
I'm trying to setup LVM, but have run into trouble:
unibus:~# blockdev --rereadpt /dev/hdc;dmesg|tail -n 1
/dev/ide/host0/bus1/target0/lun0: unknown partition table
unibus:~# pvcreate /dev/hdc
pvcreate -- device "/dev/hdc" has a partition table
as you can see, Linux knows that there's no partition, yet pvcreate
insists that there is; this was after dd-ing 1GB of /dev/zero over the
start of the disk, too :-(
Is there any way to force a bypass of this partition table test?
don
^ permalink raw reply
* Re: 2.4.19 -- ac97_codec failure ALi 5451 [rescued]
From: Peter @ 2003-01-10 18:37 UTC (permalink / raw)
To: 200301100250.h0A2olE20795; +Cc: linux-kernel
> > Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio,
> > version 0.14.9d, 00:57:19 Jan 9 2003
> > PCI: Enabling device 00:06.0 (0000 -> 0003)
> > PCI: Assigned IRQ 10 for device 00:06.0
> > trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
> > ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
>
> So far so good.
>
> > ali: AC97 CODEC read timed out.
> > last message repeated 127 times
> > ali: AC97 CODEC write timed out.
> > ac97_codec: AC97 codec, id: 0x0000:0x0000 (Unknown)
>
> Something lost the codec. Could be power management - was the laptop
> suspended before it went funny ?
No, this happens very reliably every time on a large number of occasions, whether
trident is compiled in or as a module, or with ALSA's snd-ali5451. Dozens of read
and write timeouts. In fact when the codec loads, it tends to freeze the whole
system for a short time (from a few seconds to a minute).
That said, it's close to working. There have been times when I've been able to get
sound -- typically by doing a manual insmod ac97_codec and trident. I had hoped the
ALSA module would work more reliably, but it seems the problem is with the ac97
codec.
Is the driver for the ac97 codec the same for OSS and ALSA? They appear to fail in
very similar ways.
Peter
-
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: What's in a name?
From: Valdis.Kletnieks @ 2003-01-10 18:57 UTC (permalink / raw)
To: root; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.3.95.1030110133730.27408B-100000@chaos.analogic.com>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Fri, 10 Jan 2003 13:42:52 EST, "Richard B. Johnson" said:
> No doubt a gcc compiler. I built my house with a Stanley hammer
> and a Skill saw. Neither Stanley nor Skill own the house (the
> bank does).
Actually, *YOU* probably own the house. What the bank has is a mortgage -
a promise by you that if you don't pay them, they *then* get to own the house.
Most banks try VERY hard to avoid actually owning houses.
This is actually somewhat germane, as it reflects back on the "GPL the
source after N units have been sold" business model, and code escrow, and
related thigns...
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Grant Grundler @ 2003-01-10 19:00 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Ivan Kokshaysky, Benjamin Herrenschmidt, Alan Cox,
Paul Mackerras, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <m1y95tzbdq.fsf@frodo.biederman.org>
On Fri, Jan 10, 2003 at 12:56:17AM -0700, Eric W. Biederman wrote:
> For what it is worth these cards exist though.
yes.
> Quadris cards have a 256MB bar, and dolphin cards default to having a 512MB bar.
> Both are high performance I/O adapters.
I'm not familiar with "dolphin" cards.
I'm aware of "Quadrics" but I've not heard anyone try those with parisc-linux.
Quadrics cards do work on ia64 (for some definition of "work").
> If someone leaves a big enough hole for hotplug cards I guess it can work...
Or dynamically assigns windows to PCI Bus controllers as PCI devices
are brought on-line. For PCI Hotplug, the role of managing MMIO/IRQ
resources has moved to the OS since these services are needed
after the OS has taken control of the box.
> How you define a potential boot device, and what it saves you to not assign
> it resources I don't know.
You have it backwards. firmware only assigns resources to boot devices
and "console" devices. ie firmware does minimal configuration.
Why? An OS with hotplug support can do it anyway.
A "potential boot device" has firmware support which the primary boot
loader can use to load the OS or a secondary boot loader. But firmware
only needs to configure a single boot/console device that is
actually being used.
> I am still recovering from putting a 256MB bar and 4GB of ram in a 4GB hole,
> with minimal loss on x86, so my imagination of what can be sanely done
> on a 64bit arch may be a little stunted..
both ia64 and later parisc boxes from HP reserve GB's of LMMIO address space
for IO uses (LMMIO == MMIO < 4GB). AFAIK, physical memory behind that address
space gets remapped to higher "physical" addresses by the memory controller.
But making 256MB still fit in that space can still be a challenge.
One 256MB BAR isn't so bad. It's when the customer wants to have a central
server that has 2 or more such cards...64-bit BARs on 64-bit architecture
make life alot easier.
grant
^ permalink raw reply
* testers wanted: new sg-buffer handler
From: Takashi Iwai @ 2003-01-10 18:56 UTC (permalink / raw)
To: alsa-devel
Hi,
i updated the SG-buffer handling routines to use vm-mapping.
if you have emu10k1, via82xx or trident 4DNX, please try the patch at
http://www.alsa-project.org/~iwai/vm-sgbuf.dif
it includes patches to both alsa-kernel and alsa-tree (the very latest
cvs version).
at least, it works fine on emu10k1 with 2.4.20.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: VIA8233/8235 testers wanted
From: Takashi Iwai @ 2003-01-10 18:57 UTC (permalink / raw)
To: Joachim Blaabjerg; +Cc: alsa-devel
In-Reply-To: <200301101109.32329.styx@gentoo.org>
At Fri, 10 Jan 2003 11:09:32 +0100,
Joachim Blaabjerg wrote:
>
> On Friday 10 January 2003 10:27, you wrote:
> > there are small bugs regarding the calculation of hw-pointer.
> > i hope now this choppy sounds fixed. could you try to grab via82xx.c
> > again from the same url?
>
> Yes, works great! Everything I use my card for works 100% now, for the first
> time I can remember. On my previous box, I had an Aureal card that didn't
> really have any good drivers either.
ok, now the new driver was committed to the cvs tree.
thanks for your test!
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Randy.Dunlap @ 2003-01-10 19:01 UTC (permalink / raw)
To: Andi Kleen; +Cc: Valdis.Kletnieks, linux-kernel
In-Reply-To: <20030110171950.GA6064@wotan.suse.de>
On Fri, 10 Jan 2003, Andi Kleen wrote:
| On Fri, Jan 10, 2003 at 12:13:48PM -0500, Valdis.Kletnieks@vt.edu wrote:
| > On Fri, 10 Jan 2003 17:12:12 +0100, Andi Kleen <ak@suse.de> said:
| > >
| > > > So the end-result of the discussion is, "What should really happen here?"
| > > > and "What, if anything, do you want me to do?"
| > >
| > > IMHO best would be to get rid of /proc/*/wchan and keep the kallsyms
| > > lookup slow, simple and stupid.
| >
| > And replace the current /proc/*/wchan functionality with what?
|
| Ctrl-Rollen (or whatever the key is called on your keyboard) on the console,
| like in all previous linux releases.
Ctrl-ScrollLock on mine if I'm following you correctly.
Same as Sysrq-P if sysrq is enabled, except that the former
is always available.
Are there other similar functions that are available without
Sysrq enabled? If so, where can I find info about them?
(other than drivers/char/keyboard.c :)
| Note /proc/*/wchan is not in 2.4.
|
| Also you still have WCHAN in ps, just not a full backtrace.
--
~Randy
^ permalink raw reply
* Re: FW: Fastest possible UDMA - how?
From: Manish Lachwani @ 2003-01-10 19:04 UTC (permalink / raw)
To: linux-kernel, Michael.Knigge
In-Reply-To: <233C89823A37714D95B1A891DE3BCE5202AB1B88@xch-a.win.zambeel.com>
Take a look at the drive IDENTIFY data. From the ATA
spec, it can be seen that word# 88 in the IDENTIFY
data can help you find out the UDMA mode selected and
UDMA mode supported.
The UDMA mode supported is the maximum supported by
the drive.
Thanks
Manish
> Hi all,
>
> is it somehow possible to determine what is the
> fastest UDMA-Mode my
> IDE-Controller supports - independant of the
> chipset?
>
> Thanks,
> Michael
>
>
>
> -
> 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/
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: Fastest possible UDMA - how?
From: Alan Cox @ 2003-01-10 19:56 UTC (permalink / raw)
To: Michael Knigge; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030110.18485381@knigge.local.net>
On Fri, 2003-01-10 at 18:48, Michael Knigge wrote:
> Hi all,
>
> is it somehow possible to determine what is the fastest UDMA-Mode my
> IDE-Controller supports - independant of the chipset?
Not really. You have to know the specific device to know how to
query the modes it supports (if indeed you can query and don't have
the driver knowing by type)
^ permalink raw reply
* 2.4.20-acpi: NMI received for unknown reason 2d/3d
From: Pascal Schmidt @ 2003-01-10 19:11 UTC (permalink / raw)
To: linux-kernel
Hi all,
Kernel is 2.4.20 with akpm's ext3 fixes and acpi-20021212-2.4.20.diff.gz
patched in.
I just upgraded from a Duron 1 GHz processor to an Athlon XP 1700+. The
only other change to the system is an updated BIOS to support the new
processor.
Motherboard is a Soyo K7ADA, using the ALi Magik 1 chipset.
Since the CPU and BIOS upgrade, I get the following message(s) from
the kernel:
> Uhhuh. NMI received for unknown reason 2d.
> Dazed and confused, but trying to continue
> Do you have a strange power saving mode enabled?
The reason is 2d most of the time, with a few 3d inbetween. About 8 of
these messages pile up in dmesg until my system (Red Hat 7.2) is
completely done running sysinit. After that, new messages only appear
seldomly and minutes apart with no pattern I could regocnize.
I don't think it's a memory problem because memtest86 (I only tried a
single run since the memory worked fine before) doesn't show up errors
and memory-related NMIs are not "unknown reason"s to the kernel as far
as I know.
Everything that shows up in the BIOS setup related to power management
is turned off.
Running with or without local APIC support does not change anything. Same
for ACPI support or not.
What can this be? Do I have to worry or is this just some fancy power
management stuff supported by the AthlonXP that the kernel does not know
about?
Again, this is an AthlonXP 1700+ (CPU family 6, model 8, stepping 0).
--
Ciao,
Pascal
^ permalink raw reply
* Oops with Linux 2.4.21-pre3-ac2
From: Gabor Z. Papp @ 2003-01-10 19:07 UTC (permalink / raw)
To: linux-kernel
System.map not presents due nfs mount problem, but maybe its
usable.
Same kernel produces total freeze on a longtime stable
system.
ksymoops 2.4.8 on i686 2.4.21-pre3-ac2-gzp2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-pre3-ac2-gzp2/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
Unable to handle kernel NULL pointer dereference at virtual address 00000004
c0129350
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0129350>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: c121e404 ecx: c121e404 edx: dd33e000
esi: 00000000 edi: 00000020 ebp: 00000200 esp: dd33fe48
ds: 0018 es: 0018 ss: 0018
Process mc (pid: 517, stackpage=dd33f000)
Stack: cc54bba0 c121e404 00000020 00000200 c0132e0e c121e404 000001d2 00000020
00000200 c013136c cc54bba0 cc54bba0 cc54bba0 c0129983 c0128a6c 00000020
000001d2 00000020 00000006 00000006 dd33e000 000044b9 000001d2 c0210ed4
Call Trace: [<c0132e0e>] [<c013136c>] [<c0129983>] [<c0128a6c>] [<c0128be0>]
[<c0128c42>] [<c0129608>] [<c0129892>] [<c0125011>] [<c01295b6>] [<c012502d>]
[<c014ef37>] [<c012f636>] [<c0106b53>]
Code: 89 58 04 89 03 8d 42 5c 89 43 04 89 5a 5c 89 73 0c ff 42 68
>>EIP; c0129350 <kmem_find_general_cachep+165c/18ac> <=====
>>ebx; c121e404 <___strtok+fa11f8/205b7e54>
>>ecx; c121e404 <___strtok+fa11f8/205b7e54>
>>edx; dd33e000 <___strtok+1d0c0df4/205b7e54>
>>esp; dd33fe48 <___strtok+1d0c2c3c/205b7e54>
Trace; c0132e0e <try_to_free_buffers+92/17c>
Trace; c013136c <set_bh_page+1e8/1ec>
Trace; c0129983 <__free_pages+1b/1c>
Trace; c0128a6c <kmem_find_general_cachep+d78/18ac>
Trace; c0128be0 <kmem_find_general_cachep+eec/18ac>
Trace; c0128c42 <kmem_find_general_cachep+f4e/18ac>
Trace; c0129608 <_alloc_pages+68/1e0>
Trace; c0129892 <__alloc_pages+112/160>
Trace; c0125011 <generic_file_write+3e9/20b4>
Trace; c01295b6 <_alloc_pages+16/1e0>
Trace; c012502d <generic_file_write+405/20b4>
Trace; c014ef37 <grok_partitions+215f/ade0>
Trace; c012f636 <default_llseek+39e/9f8>
Trace; c0106b53 <__up_wakeup+101f/13e4>
Code; c0129350 <kmem_find_general_cachep+165c/18ac>
00000000 <_EIP>:
Code; c0129350 <kmem_find_general_cachep+165c/18ac> <=====
0: 89 58 04 mov %ebx,0x4(%eax) <=====
Code; c0129353 <kmem_find_general_cachep+165f/18ac>
3: 89 03 mov %eax,(%ebx)
Code; c0129355 <kmem_find_general_cachep+1661/18ac>
5: 8d 42 5c lea 0x5c(%edx),%eax
Code; c0129358 <kmem_find_general_cachep+1664/18ac>
8: 89 43 04 mov %eax,0x4(%ebx)
Code; c012935b <kmem_find_general_cachep+1667/18ac>
b: 89 5a 5c mov %ebx,0x5c(%edx)
Code; c012935e <kmem_find_general_cachep+166a/18ac>
e: 89 73 0c mov %esi,0xc(%ebx)
Code; c0129361 <kmem_find_general_cachep+166d/18ac>
11: ff 42 68 incl 0x68(%edx)
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000004
c0129350
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0129350>] Not tainted
EFLAGS: 00010246
eax: 00000000 ebx: c1374d74 ecx: c1374d90 edx: dd33e000
esi: 00000000 edi: dd8f126c ebp: 0849b000 esp: dd33fc80
ds: 0018 es: 0018 ss: 0018
Process mc (pid: 517, stackpage=dd33f000)
Stack: c1374d74 00000000 dd8f126c 0849b000 00000080 014c5c48 c0278850 c019151c
c0278850 c15a1540 c0278850 c15ab160 00000286 c0129983 c0129d53 c1374d74
c011f3d0 c1374d74 00003000 c011f7b3 141c2067 dd8fe180 de6ccb20 00003000
Call Trace: [<c019151c>] [<c0129983>] [<c0129d53>] [<c011f3d0>] [<c011f7b3>]
[<c0121d92>] [<c0111f2e>] [<c011617f>] [<c0107126>] [<c010fcd7>] [<c010f9d8>]
[<c0152e36>] [<c0158aac>] [<c015091b>] [<c01584bf>] [<c0106c44>] [<c0129350>]
[<c0132e0e>] [<c013136c>] [<c0129983>] [<c0128a6c>] [<c0128be0>] [<c0128c42>]
[<c0129608>] [<c0129892>] [<c0125011>] [<c01295b6>] [<c012502d>] [<c014ef37>]
[<c012f636>] [<c0106b53>]
Code: 89 58 04 89 03 8d 42 5c 89 43 04 89 5a 5c 89 73 0c ff 42 68
>>EIP; c0129350 <kmem_find_general_cachep+165c/18ac> <=====
>>ebx; c1374d74 <___strtok+10f7b68/205b7e54>
>>ecx; c1374d90 <___strtok+10f7b84/205b7e54>
>>edx; dd33e000 <___strtok+1d0c0df4/205b7e54>
>>edi; dd8f126c <___strtok+1d674060/205b7e54>
>>esp; dd33fc80 <___strtok+1d0c2a74/205b7e54>
Trace; c019151c <ide_do_request+260/2a8>
Trace; c0129983 <__free_pages+1b/1c>
Trace; c0129d53 <free_pages+3cf/1c7c>
Trace; c011f3d0 <pm_find+dc/5d0>
Trace; c011f7b3 <pm_find+4bf/5d0>
Trace; c0121d92 <do_brk+352/5b0>
Trace; c0111f2e <remove_wait_queue+2a2/1228>
Trace; c011617f <exit_mm+303/4ac>
Trace; c0107126 <dump_stack+20e/f30>
Trace; c010fcd7 <__verify_write+407/774>
Trace; c010f9d8 <__verify_write+108/774>
Trace; c0152e36 <grok_partitions+605e/ade0>
Trace; c0158aac <journal_dirty_metadata+154/174>
Trace; c015091b <grok_partitions+3b43/ade0>
Trace; c01584bf <journal_unlock_updates+4a7/4cc>
Trace; c0106c44 <__up_wakeup+1110/13e4>
Trace; c0129350 <kmem_find_general_cachep+165c/18ac>
Trace; c0132e0e <try_to_free_buffers+92/17c>
Trace; c013136c <set_bh_page+1e8/1ec>
Trace; c0129983 <__free_pages+1b/1c>
Trace; c0128a6c <kmem_find_general_cachep+d78/18ac>
Trace; c0128be0 <kmem_find_general_cachep+eec/18ac>
Trace; c0128c42 <kmem_find_general_cachep+f4e/18ac>
Trace; c0129608 <_alloc_pages+68/1e0>
Trace; c0129892 <__alloc_pages+112/160>
Trace; c0125011 <generic_file_write+3e9/20b4>
Trace; c01295b6 <_alloc_pages+16/1e0>
Trace; c012502d <generic_file_write+405/20b4>
Trace; c014ef37 <grok_partitions+215f/ade0>
Trace; c012f636 <default_llseek+39e/9f8>
Trace; c0106b53 <__up_wakeup+101f/13e4>
Code; c0129350 <kmem_find_general_cachep+165c/18ac>
00000000 <_EIP>:
Code; c0129350 <kmem_find_general_cachep+165c/18ac> <=====
0: 89 58 04 mov %ebx,0x4(%eax) <=====
Code; c0129353 <kmem_find_general_cachep+165f/18ac>
3: 89 03 mov %eax,(%ebx)
Code; c0129355 <kmem_find_general_cachep+1661/18ac>
5: 8d 42 5c lea 0x5c(%edx),%eax
Code; c0129358 <kmem_find_general_cachep+1664/18ac>
8: 89 43 04 mov %eax,0x4(%ebx)
Code; c012935b <kmem_find_general_cachep+1667/18ac>
b: 89 5a 5c mov %ebx,0x5c(%edx)
Code; c012935e <kmem_find_general_cachep+166a/18ac>
e: 89 73 0c mov %esi,0xc(%ebx)
Code; c0129361 <kmem_find_general_cachep+166d/18ac>
11: ff 42 68 incl 0x68(%edx)
1 warning and 1 error issued. Results may not be reliable.
^ permalink raw reply
* Re: Suggestion
From: Valdis.Kletnieks @ 2003-01-10 19:08 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel
In-Reply-To: <6382.1042218032@passion.cambridge.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Fri, 10 Jan 2003 17:00:32 GMT, David Woodhouse said:
> Note that you can buy replacement non-nVidia graphics cards for the I8x00
> as spare parts fairly cheaply, and they're very easy to install.
It's easier to get my employer to pay for my time to fix software issues
with the laptop they paid for than it is to get them to shell out money
for what they'd consider a hardware workaround. And even at "fairly
cheaply", I'm not going to buy it out of my own pocket. It's a hell of
a lot easier to simply skip ACPI till somebody (perhaps I) figure out how
to fix it... ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Samuel Flory @ 2003-01-10 19:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: John Jasen, Philip Dodd, linux-kernel
In-Reply-To: <20030110024710.GA19760@gtf.org>
Jeff Garzik wrote:
>On Thu, Jan 09, 2003 at 09:40:50PM -0500, John Jasen wrote:
>
>
>>On Thu, 9 Jan 2003, Philip Dodd wrote:
>>
>>
>>
>>>Jeff Garzik wrote:
>>>
>>>
>>>>Anybody know where the source rpm for UnitedLinux kernel is?
>>>>[to be distinguished from kernel-source rpm]
>>>>
>>>>
>>if they supply the kernel source rpm, how are they in violation? Since you
>>can compile a kernel from the source rpm.
>>
>>
>
>Read the GPL :) The source code "preferred form" is clearly not an
>on-disk kernel tree with no information about the changes [patches]
>that were processed in a specific sequence, to produce that end result.
>
>
>
Actually the reverse could be much more easily said to be true. If
they only supplied the src.rpm, and not the source rpm more people
would scream than the reverse. The number of people who know how to
produce a custom kernel from a src.rpm is fairly limited. Keep in mind
most of UL's customer are not kernel hackers.
Of course the correct thing to do is simply provide both and make
people happy. A determined person can still get what ever they want out
of either form. Making it hard just leads to your customers and the
community hating you.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <sflory@rackable.com>
^ permalink raw reply
* Where is lilo.conf in the kernel source tree?
From: Khai Trinh @ 2003-01-10 19:11 UTC (permalink / raw)
To: linuxppc-embedded
I would like to reserve a piece of High RAM memory for
DMA. The Linux 2.4 Drivers book show to appand
MEM=reserve_size to the lilo.conf file.
Would someone please let me know where this file is in
the kernel tree? I couldn't seem to locate it.
Thanks,
--Khai
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [2.5.55, PCI, PCMCIA, XIRCOM]
From: Jochen Hein @ 2003-01-10 19:00 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
In-Reply-To: <200301101713.h0AHDYLK010367@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu writes:
> On Fri, 10 Jan 2003 17:21:51 +0100, Jochen Hein <jochen@jochen.org> said:
>> Jan 10 11:35:24 gswi1164 kernel: PCI: Device 01:00.0 not available because of
> resource collisions
>
> The problem is (as I understand it) that drivers/pcmcia/cardbus.c ends up
> not allocating the onboard ROM resource for some cards before trying to
> enable it. I've attached a patch that worked for me on 2.5.52, although
> said patch caused a lot of discussion here about the *right* way to do it
> (even *I* admit it's a hack)
For reference, this is already filed in bugzilla as
http://bugzilla.kernel.org/show_bug.cgi?id=134 . I should have
searched there.
> - and I've seen a report it causes an OOPS
> on 2.5.53. I've not tried it on post-52, but I had a -54 kernel OOPS
> right around that point in bootup (right after IDE and somewhere in PCI
> init). Haven't chased that one at all...
It Oopses for me too:
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
PCI: Found IRQ 11 for device 00:02.0
PCI: Sharing IRQ 11 with 00:03.0
Module yenta_socket cannot be unloaded due to unsafe usage in
include/linux/module.h:420
Yenta IRQ list 06b8, PCI irq11
Socket status: 30000020
PCI: Found IRQ 11 for device 00:02.1
Yenta IRQ list 06b0, PCI irq11
Socket status: 30000006
cs: cb_alloc(bus 1): vendor 0x115d, device 0x0003
PCI: Enabling device 01:00.0 (0000 -> 0003)
PCI: Setting latency timer of device 01:00.0 to 64
Unable to handle kernel NULL pointer dereference at virtual address
00000004
printing eip:
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x1000-0x17ff: excluding 0x15e8-0x15ef
cs: IO port probe 0x0a00-0x0aff: clean.
c010e02e
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c010e02e>] Not tainted
EFLAGS: 00010282
EIP is at .text.lock.sys_i386+0x1e/0x88
eax: 00000020 ebx: c571f44c ecx: 00000000 edx: c571f44c
esi: 00002000 edi: c5e17840 ebp: c5defedc esp: c5defecc
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 310, threadinfo=c5dee000 task=c1125280)
Stack: c571f44c c571f400 c5e17840 c571f400 c5deff08 c6a6d1c3 c571f44c 00002000
c5e177b4 c6a6f288 00000000 c571f44c c5e177ac c571f44c 02100388 c5deff2c
c01d6983 c571f400 c6a6f210 ffffffed c6a6f288 c571f44c c571f400 c6a6f260
Call Trace:
[<c6a6d1c3>] xircom_probe+0xff/0xfffaff53 [xircom_cb]
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c01d6983>] pci_match_device+0x47/0x64
[<c6a6f210>] xircom_pci_table+0x0/0xfffade07 [xircom_cb]
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c6a6f260>] xircom_ops+0x0/0xfffaddb7 [xircom_cb]
[<c0218088>] device_bind_driver+0x38/0x64
[<c0218156>] device_attach+0x42/0x70
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c0218413>] bus_remove_device+0x87/0xa4
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c6a6f300>] +0x0/0xfffadd17 [xircom_cb]
[<c6a6f2a8>] xircom_ops+0x48/0xfffaddb7 [xircom_cb]
[<c021877a>] put_driver+0x36/0x3c
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c01d6a84>] pci_device_resume+0x44/0x54
[<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
[<c6a1d00d>] 0xc6a1d00d
[<c6a6f260>] xircom_ops+0x0/0xfffaddb7 [xircom_cb]
[<c012c9d6>] load_module+0x13a/0x1cc
[<c0108d9b>] system_call+0x7/0xb
Code: 8b 51 04 85 d2 77 09 75 05 83 39 fe 77 02 0c 01 8d 5e ff c1
--
#include <~/.signature>: permission denied
^ permalink raw reply
* Re: FW: Fastest possible UDMA - how?
From: Valdis.Kletnieks @ 2003-01-10 19:20 UTC (permalink / raw)
To: Manish Lachwani; +Cc: linux-kernel, Michael.Knigge
In-Reply-To: <20030110190403.2127.qmail@web20510.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Fri, 10 Jan 2003 11:04:03 PST, Manish Lachwani <m_lachwani@yahoo.com> said:
> Take a look at the drive IDENTIFY data. From the ATA
> spec, it can be seen that word# 88 in the IDENTIFY
> data can help you find out the UDMA mode selected and
> UDMA mode supported.
>
> The UDMA mode supported is the maximum supported by
> the drive.
Will this DTRT if the IDE *controller* does UDMA-5 but the drives are UDMA-2
at best?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH] 2.5.55 fix etherleak in 8390.c [rescued]
From: Matti Aarnio @ 2003-01-10 19:25 UTC (permalink / raw)
To: Rudmer van Dijk; +Cc: Paul Gortmaker, linux-kernel
In-Reply-To: <200301101835.h0AIZA704332@mail.intergenia.de>
On Fri, Jan 10, 2003 at 07:35:10PM +0100, Rudmer van Dijk wrote:
> this is the fix which went in 2.4.21-pre3-ac2, rediffed against 2.5.55
> Rudmer
That scratch[] allocation is 60 bytes, taken off the stack.
It isn't very large, and isn't recursive, but still...
> --- linux-2.5.55/drivers/net/8390.c.orig 2003-01-10 16:23:44.000000000 +0100
> +++ linux-2.5.55/drivers/net/8390.c 2003-01-10 16:23:00.000000000 +0100
> @@ -270,6 +270,7 @@
> struct ei_device *ei_local = (struct ei_device *) dev->priv;
> int length, send_length, output_page;
> unsigned long flags;
> + char scratch[ETH_ZLEN];
>
> length = skb->len;
/Matti Aarnio
^ permalink raw reply
* Re: FW: Fastest possible UDMA - how?
From: Manish Lachwani @ 2003-01-10 19:27 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel, Michael.Knigge
In-Reply-To: <200301101921.h0AJLFLK012541@turing-police.cc.vt.edu>
If the drives support UDMA 2, then the controller will
operate in UDMA 2. In that case, the IDENTIFY
information will show UDMA 2 for UDMA mode selected
and UDMA 2 for UDMA mode supported.
Now, say that I have a drive that supports UDMA 6 and
the controller supports UDMA 5. Then, from the
IDENTIFY information, the UDMA selected would be UDMA
5 while the UDMA supported would be UDMA 6.
Thanks
manish
--- Valdis.Kletnieks@vt.edu wrote:
> On Fri, 10 Jan 2003 11:04:03 PST, Manish Lachwani
> <m_lachwani@yahoo.com> said:
> > Take a look at the drive IDENTIFY data. From the
> ATA
> > spec, it can be seen that word# 88 in the IDENTIFY
> > data can help you find out the UDMA mode selected
> and
> > UDMA mode supported.
> >
> > The UDMA mode supported is the maximum supported
> by
> > the drive.
>
> Will this DTRT if the IDE *controller* does UDMA-5
> but the drives are UDMA-2
> at best?
>
> ATTACHMENT part 2 application/pgp-signature
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: FW: Fastest possible UDMA - how?
From: Alan Cox @ 2003-01-10 20:15 UTC (permalink / raw)
To: Manish Lachwani; +Cc: Linux Kernel Mailing List, Michael.Knigge
In-Reply-To: <20030110190403.2127.qmail@web20510.mail.yahoo.com>
On Fri, 2003-01-10 at 19:04, Manish Lachwani wrote:
> Take a look at the drive IDENTIFY data. From the ATA
> spec, it can be seen that word# 88 in the IDENTIFY
> data can help you find out the UDMA mode selected and
> UDMA mode supported.
>
> The UDMA mode supported is the maximum supported by
> the drive.
Not always true. There are a wide number of cases where the
UDMA mode being used is not the highest one the drive
or controller supports. The most simple example is if we
decide the cabling is not suitable for UDMA66 and higher.
^ permalink raw reply
* Re: Very slow shell from internal MPC8241 UART
From: Jim Thompson @ 2003-01-10 19:21 UTC (permalink / raw)
To: Frederic Soulier; +Cc: linuxppc-embedded
In-Reply-To: <160c01c2b8c3$0db674f0$9900010a@aztec.local>
The solution is to make the interrupt actually register.
They're 137 and 138, if memory serves.
Code is on musenki.com's CVS tree.
jim
Frederic Soulier writes:
>
> Hi,
>
> I'm using kernel linux-2.4.17-mvl21 on a custom board based on a MPC8241.
> Everything looks ok until my ramdisk shell is executed : it is *very*
> slow.
> For my tests I use simple-Ramdisk (available on the Denx ftp site).
>
> I use the internal UART of the MPC8241 (IRQ 137). It looks to work fine
> for U-Boot and for displaying Linux boot messages.
>
> I've found some threads from this mailing-list about the same problem.
> Solutions were about EPIC configuration.
> I use only the internal EPIC (no external 8259), my EPIC configuration is
> very simple and no external interrupts are generated at this time.
>
> Here are the modifications that I've applied to my kernel in order to take
> care of the internal UART (as described in
> http://lists.linuxppc.org/linuxppc-embedded/200202/msg00056.html)
>
> 1. Leave EUMBAR @ 0xFC000000
> 2. Call io_block_mapping(0xfc000000, 0xfc000000, 0x04000000, _PAGE_IO); in
> <platform>_map_io()
> 3. Call mpc10x_bridge_init() w/ 0xfc000000 as the last parameter in
> <platform>_find_bridge()
>
> I've alse defined this UART to work with IRQ 137 :
>
> #define STD_SERIAL_PORT_DFNS \
> { 0, BASE_BAUD, PPC200_SERIAL, 137, STD_COM_FLAGS, \
> iomem_base: (u8 *)PPC200_SERIAL, io_type: SERIAL_IO_MEM }
>
> w/ PPC200_SERIAL == 0xFC004500 (internal DUART channel #1)
>
> After that the UART was working for the kernel boot messages before the
> shell is executed.
> The shell is awfully slow (16 caracters in one time every 30 seconds
> approx.).
>
> I've tried to add the openpic_set_sources() as described in other threads
> in order to take care of the IRQ #137 :
>
> 1. Add openpic_set_sources(0, 138, NULL); in <platform>_init_irq() but in
> this case there is no more display from the shell.
>
> Please note that to do this modification I've had to replace
> arch/ppc/kernel/open_pic.c and arch/ppc/kernel/open_pic_defs.h in order to
> add the openpic_set_sources() function.
> The new open_pic.c and open_pic_defs.h came from linuxppc-2.4.18.
>
> Any advice will be welcomed,
>
> Best regards,
>
> Frederic Soulier
>
>
>
>
--
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] SCSI Core patches
From: Luben Tuikov @ 2003-01-10 19:23 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
In-Reply-To: <200301101706.h0AH6rr03943@localhost.localdomain>
James Bottomley wrote:
> I got around to looking at the patch.
>
> I think the idea of slab allocation for Scsi_Cmnds is generally worth the
> effort. There are several issues with the current patch, though:
>
> 1) The command for the device has to be allocated in space that respects the
> dma_mask for the device (on a non MMIO bus). Pretty much for scsi, this
> translates to using GFP_DMA as the allocation flag if unchecked_isa_dma is
> set. GFP_DMA has to be passed in at kmem_cache_create time. We therefore
> probably need the capacity to use a different kmem_cache on a per Scsi_Host
> basis and the ability to set up a GFP_DMA kmem_cache if a host with
> unchecked_isa_dma appears.
Some of our machines have 128 SCSI hosts.
I think that the slab cache can acknowledge a GFP_DMA flag even after
creation of the slab, but not 100% sure on this. I.e. in scsi_get_command()
a check of host->unchecked_isa_dma can be performed and the kmem_flags
OR-ed with GFP_DMA.
We can also have 2 slabs -- one for DMA capable hosts (current) and
another for non-DMA capable hosts.
Actually, I had this in the 2.5.52 version of this patch but decided that
the LLDD code will run as normal kernel code and that the actual PCI HOST
will never have to access the struct scsi_cmnd directly over the PCI bus;
but will only need to access the sg list. For this reason I decided to leave
it out. I.e. struct scsi_cmnd will alway be accessed in normal operation
of the kernel, and thus no need for GFP_DMA.
(I'd so much rather it be that way, so much... :-)
I've no problem changing the slab alloc. just let's decide if we
want a slab per host (kind of inefficient) or 2 slabs (DMA, and non-DMA)
or OR-ing the mask upon scsi_get_command().
> 2) scsi_get_command takes the host lock when obtaining a command from it's
> free_list. Unfortunately, scsi_get_command looks to be called from places
> (like the prep_fn) where the lock is already held => deadlock.
Absolutely correct.
In this case I'll create a new spinlock which will be specifically for use
with the slab allocation. In fact, my preferred choice -- ``a lock for an object''.
In my version of mini-scsi-core I do not use spinlocks when accessing the slab
cache, but instead set the flag to GFP_ATOMIC or GFP_KERNEL as need be.
I can easily imagine a deadlock when we access it when our own spinlock
is obtained but the flag is GFP_KERNEL.
But the spinlock will be needed only to acess the backup store of command
structs (list), so I've no problem creating a scsi_cache_lock. Consider it done.
> 3) The free_list employs all the list machinery for potentially storing
> multiple commands, but in practice it looks like it only ever stores one of
> them. Is there a plan to make this free_list size tuneable (probably tuneable
> per device)?
Yes -- this was my intention (0:N commands in the backup store), and this was my
plan to make this tuneable in the (far) future.
Though I left it at one command when setting up the host, since I couldn't
assume much.
The problem is that the number of backup stored commands depends on quite a few
factors, and that will be one hell of a heuristic. So I'd imagine
it has to do with the available memory and the throughput (both in and out) of
commands between SCSI Core and LLDD. I.e. that number will be dynamically changing.
For this reason I left it at one.
--
Luben
^ permalink raw reply
* Re: FW: Fastest possible UDMA - how?
From: Michael Knigge @ 2003-01-10 19:31 UTC (permalink / raw)
To: Alan Cox; +Cc: Manish Lachwani, Linux Kernel Mailing List
In-Reply-To: <1042229748.32431.13.camel@irongate.swansea.linux.org.uk>
> Not always true. There are a wide number of cases where the
> UDMA mode being used is not the highest one the drive
> or controller supports. The most simple example is if we
> decide the cabling is not suitable for UDMA66 and higher.
Thank you all for your support....
Bye
Michael
^ 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.