* Re: emu10k1_audio_open?? 2.5.2 problem
From: Nikita Gergel @ 2002-01-15 14:19 UTC (permalink / raw)
To: Frank Jacobberger; +Cc: linux-kernel
In-Reply-To: <3C443940.8070000@xmission.com>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On Tue, 15 Jan 2002 07:14:24 -0700
Frank Jacobberger <f1j@xmission.com> wrote:
> gcc -D__KERNEL__ -I/usr/src/linux-2.5.2/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DMODVERSIONS -include
> /usr/src/linux-2.5.2/include/linux/modversions.h -c -o audio.o audio.c
> audio.c: In function `emu10k1_audio_open':
> audio.c:1101: invalid operands to binary &
> make[3]: *** [audio.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.5.2/drivers/sound/emu10k1'
> make[2]: *** [_modsubdir_emu10k1] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.5.2/drivers/sound'
> make[1]: *** [_modsubdir_sound] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.5.2/drivers'
> make: *** [_mod_drivers] Error 2
>
> What to do?
I've already contributed patch for 2.5 kernels to fix this. There are problems with 'MINOR' function.
Look in attach for the patch.
--
Nikita Gergel System Administrator
Moscow, Russia YAUZA-Telecom
[-- Attachment #2: emu10k1.diff --]
[-- Type: application/octet-stream, Size: 2645 bytes --]
diff -u --recursive --new-file v2.5.1/linux/drivers/sound/emu10k1/audio.c linux/drivers/sound/emu10k1/audio.c
--- v2.5.1/linux/drivers/sound/emu10k1/audio.c Tue Oct 9 21:53:00 2001
+++ linux/drivers/sound/emu10k1/audio.c Wed Jan 9 10:00:00 2002
@@ -1098,7 +1098,7 @@
static int emu10k1_audio_open(struct inode *inode, struct file *file)
{
- int minor = MINOR(inode->i_rdev);
+ int emu_minor = minor(inode->i_rdev);
struct emu10k1_card *card = NULL;
struct list_head *entry;
struct emu10k1_wavedevice *wave_dev;
@@ -1110,7 +1110,7 @@
list_for_each(entry, &emu10k1_devs) {
card = list_entry(entry, struct emu10k1_card, list);
- if (!((card->audio_dev ^ minor) & ~0xf) || !((card->audio_dev1 ^ minor) & ~0xf))
+ if (!((card->audio_dev ^ emu_minor) & ~0xf) || !((card->audio_dev1 ^ emu_minor) & ~0xf))
goto match;
}
@@ -1206,7 +1206,7 @@
woinst->buffer.fragment_size = 0;
woinst->buffer.ossfragshift = 0;
woinst->buffer.numfrags = 0;
- woinst->device = (card->audio_dev1 == minor);
+ woinst->device = (card->audio_dev1 == emu_minor);
woinst->timer.state = TIMER_STATE_UNINSTALLED;
woinst->num_voices = 1;
for (i = 0; i < WAVEOUT_MAXVOICES; i++) {
diff -u --recursive --new-file v2.5.1/linux/drivers/sound/emu10k1/midi.c linux/drivers/sound/emu10k1/midi.c
--- v2.5.1/linux/drivers/sound/emu10k1/midi.c Tue Oct 9 21:53:00 2001
+++ linux/drivers/sound/emu10k1/midi.c Wed Jan 9 10:00:00 2002
@@ -87,7 +87,7 @@
static int emu10k1_midi_open(struct inode *inode, struct file *file)
{
- int minor = MINOR(inode->i_rdev);
+ int emu_minor = minor(inode->i_rdev);
struct emu10k1_card *card = NULL;
struct emu10k1_mididevice *midi_dev;
struct list_head *entry;
@@ -98,7 +98,7 @@
list_for_each(entry, &emu10k1_devs) {
card = list_entry(entry, struct emu10k1_card, list);
- if (card->midi_dev == minor)
+ if (card->midi_dev == emu_minor)
goto match;
}
diff -u --recursive --new-file v2.5.1/linux/drivers/sound/emu10k1/mixer.c linux/drivers/sound/emu10k1/mixer.c
--- v2.5.1/linux/drivers/sound/emu10k1/mixer.c Tue Oct 9 21:53:00 2001
+++ linux/drivers/sound/emu10k1/mixer.c Wed Jan 9 10:00:00 2002
@@ -640,7 +640,7 @@
static int emu10k1_mixer_open(struct inode *inode, struct file *file)
{
- int minor = MINOR(inode->i_rdev);
+ int emu_minor = minor(inode->i_rdev);
struct emu10k1_card *card = NULL;
struct list_head *entry;
@@ -649,7 +649,7 @@
list_for_each(entry, &emu10k1_devs) {
card = list_entry(entry, struct emu10k1_card, list);
- if (card->ac97.dev_mixer == minor)
+ if (card->ac97.dev_mixer == emu_minor)
goto match;
}
^ permalink raw reply
* emu10k1_audio_open?? 2.5.2 problem
From: Frank Jacobberger @ 2002-01-15 14:14 UTC (permalink / raw)
To: linux-kernel
gcc -D__KERNEL__ -I/usr/src/linux-2.5.2/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/linux-2.5.2/include/linux/modversions.h -c -o audio.o audio.c
audio.c: In function `emu10k1_audio_open':
audio.c:1101: invalid operands to binary &
make[3]: *** [audio.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.5.2/drivers/sound/emu10k1'
make[2]: *** [_modsubdir_emu10k1] Error 2
make[2]: Leaving directory `/usr/src/linux-2.5.2/drivers/sound'
make[1]: *** [_modsubdir_sound] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.2/drivers'
make: *** [_mod_drivers] Error 2
What to do?
Thanks,
Frank
^ permalink raw reply
* Re: Error message after lilo on 2.4.17
From: Stephen C. Tweedie @ 2002-01-15 14:13 UTC (permalink / raw)
To: Stephen Kitchener; +Cc: linux-kernel, Stephen Tweedie
In-Reply-To: <E16OQOR-00072j-0B@finch-post-11.mail.demon.net>
Hi,
On Wed, Jan 09, 2002 at 09:36:06PM +0000, Stephen Kitchener wrote:
> I have built a 2.4.17 kernel from source on a machine here, via make
> mrproper, make xconfig, make bZimage, make mdules, make modules_install,
> ,make install. Im just repeating them here so that you can see what I have
> done :-).
Actually, you need an initrd too:
> image=/boot/vmlinuz-2.4.17
> label=2417
> root=/dev/sda1
> read-only
> optional
> vga=normal
> append=" devfs=mount quiet"
> initrd=/boot/initrd-2.4.17.img
Is your initrd set up to mount root as ext3? Under Red Hat, that
happens automatically if you have ext3 as the root fstype in
/etc/fstab when you run mkinitrd; I've no idea whether or not Mandrake
has the same magic.
Cheers,
Stephen
^ permalink raw reply
* Marvell/Galileo GT-64260 system controller data sheets
From: Clifford van Dyk @ 2002-01-15 14:11 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I noticed a mention of the Marvell/Galileo GT-64260 system controller in
a previous post. I have been trying for more than 2 weeks (email, fax,
telephone) to obtain data sheets for the device, with no success. If
anyone is able to assist me in obtaining the data sheets, please could
you contact me.
Thanks,
Clifford
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: libtool warning on redhat 7.1 native mipsel compile
From: Brian Murphy @ 2002-01-15 12:57 UTC (permalink / raw)
Cc: linux-mips
In-Reply-To: <20020114095028.C30946@lucon.org>
"H . J . Lu" wrote:
> I should have made myself clearer. I do have X rpms. In fact, my RedHat
> 7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine.
> I simply can't afford to put X on it. My mips box is used to track gcc
> 3.1, which breaks on Linux/mips almost every week, if not everyday. It
> takes 2 days for me bootstrap/check gcc 3.1 on that box. I need
> something simple to reproduce it.
>
> H.J.
Is it possible for us to help? We have some machines here (Lasat
Masquerade Pro)
which have NEC VR5000 CPU's running at 266 MHz fitted with harddisk and
running
a 2.4.17 kernel. We currently have the debian mips distribution
installed on
them. Perhaps the scripts you use to build/test gcc could be run on one
of
these machines?
/Brian
^ permalink raw reply
* [patch] O(1) scheduler, -I0
From: Ingo Molnar @ 2002-01-15 16:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Davide Libenzi
the -I0 patch is available at:
http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.2-final-I0.patch
stock 2.5.2 includes a 'interactivity estimator' method that includes most
of the things i think to be important for good interactivity:
- sleep time based priority boost/penalty.
- constant frequency runqueue sampling instead of recalculation/switch
based runqueue sampling.
- interactivity based runqueue insertion on timeslice expire.
I'm very happy about the 2.5.2 solution, it's simpler than the one i used
in -H7 - good work Davide!
There are a number of problems in 2.5.2 that need fixing though:
- renicing is broken - it does not work at all, neither up nor down, for
CPU-bound tasks. Renicing fell victim to the attempt to penalize CPU
hogs as much as possible: every CPU-bound task reaches the lowest
priority level and stays there. This also makes kernel compile times
suffer.
- RT scheduling is broken.
- the sleep average is hidden in p->prio, which makes it harder to
recover and use the true interactiveness of the task.
- the runqueue is sampled at a frequency of 20 HZ, which can misdetect
periodic user tasks that somehow correlate with 20 HZ.
I've fixed these problems/bugs by taking some of the -H7 solutions:
- introducing p->sleep_avg, which is updated in a lightweight way. No
more 'history slots'. A single counter, updated in a very simple way.
- limiting the bonus/penalty range according to nice levels - a task can
at most get a 5 priority levels penalty over the default level, in
stock 2.5.2 it can get to the nice +19 level after a few seconds
runtime. Nice levels work again.
- introducing HZ frequency runqueue sampling. Also the MAX_SLEEP_AVG
constant tells us how long into the past we are looking. This is 2
seconds right now.
- separating the RT timeslice code in scheduler_tick(), we used to break
the RT case way too often, now we can hack the SCHED_OTHER code without
having to touch the RT part.
- plus the patch also includes all the fixes and improvements from the
-H7 patch.
i've also cleaned up and commented the priority management code and have
introduced the prio_effective(p) inline function.
i've tested the patch on UP and SMP boxes. I've measured high-load
interactivity to be on equivalent levels with that of stock 2.5.2.
Bug reports, comments, suggestions welcome.
Ingo
^ permalink raw reply
* Re: MIPS64 status?
From: Maciej W. Rozycki @ 2002-01-15 13:07 UTC (permalink / raw)
To: Ralf Baechle
Cc: Kevin D. Kissell, Dominic Sweetman, Matthew Dharm, linux-mips
In-Reply-To: <20020114152355.E29242@dea.linux-mips.net>
On Mon, 14 Jan 2002, Ralf Baechle wrote:
> > The official MIPS64[tm] architecture spec from MIPS
> > Technologies also provides a bit (Status.PX) which enables
> > the 64-bit data path without affecting address generation
> > and translation, which removes this quirk. Only the very
> > most recent 64-bit cores and CPUs implement it, however.
>
> And Linux doesn't use PX at all.
Especially as there is no real need for the bit for the standard MIPS64
TLB organization. The functionality of the PX bit can be replaced by the
UX bit together with an appropriate mapping of segments to the 31-bit
address space. Of course the kernel needs to handle the XTLB exception
for UX as opposed to the TLB one for PX, but for programs it doesn't
matter.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* How can a SIGKILL'ed process make progress?
From: Roland Kuhn @ 2002-01-15 14:05 UTC (permalink / raw)
To: linux-kernel
Hi folks!
Selling the drive to a friend I did a 'time dd if=/dev/zero of=/dev/hdc &'
to erase it. Just out of curiosity I started 'fdisk -l /dev/hdc' while the
dd was going on. As expected this told me there was no valid partition
table, but then stopped in D state. I sent it a SIGKILL, started top and
was a bit puzzled: fdisk was running from time to time and consuming an
average of 5% CPU time. The SIGKILL actually happened only after the the
dd was finished. Is this the expected behaviour for kernel 2.2.18 (SuSE
7.1 boot CD)? My understanding was that fdisk should be hit by SIGKILL the
next time it gets a time slice...
TIA,
Roland
main(int k,char**p){char*q=p[2];float i,j,r,x,y,a=*q++/4;for(y=a;--y>-
a;puts(""))for(x=0;x++<*q;putchar(p[1][k%9]))for(i=k=r=0;j=r*r-i*i+(x/
*q*q[2]-q[1])/40,i=2*r*i+y/q[3],j*j+i*i<11&&++k<99;r=j);}
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Giacomo Catenazzi @ 2002-01-15 14:02 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List, esr
In-Reply-To: <20020115135756.A19738@lightning.swansea.linux.org.uk>
Alan Cox wrote:
> All of us get the CPU wrong. By using modules however I don't have to guess
> the PCI devices. My system already did that. I just need the configurator
> to hit M a lot and to work out which root devices are for the initrd.
>
> The code for that exists
It is easier to get autoconfigure in linux sources, than
modify the default (and broken) configuration from Linus.
(Sorry Linus :-) )
giacomo
^ permalink raw reply
* Re: [PATCH] 1-2-3 GB
From: rwhron @ 2002-01-15 14:07 UTC (permalink / raw)
To: linux-kernel
On Sat, Jan 12, 2002 at 07:22:23PM +0000, Hugh Dickins wrote:
> This patch is not actually what we've used. Paranoia (what other
> such bugs might there be?) drove me to set physical pages 0x3ffff
> and 0x40000 as Reserved in arch/i386/setup.c. I don't think it's
> appropriate to force that level of paranoia on others; but anyone
> configuring 3GBK should remember that it's a less-travelled path.
>
> Hugh
Thanks for the patch! I'm running on it on a 1024MB machine with
the 2GB option, and it passes LTP runalltests.sh.
The 3 patches in this thread combined into one, with a default
config option of 2GB, and help saying, if unsure, say "1GB":
diff -nur linux-2.4.18pre2aa2/Documentation/Configure.help
linux/Documentation/Configure.help
--- linux-2.4.18pre2aa2/Documentation/Configure.help Tue Jan 15 00:01:38
2002
+++ linux/Documentation/Configure.help Mon Jan 14 23:59:35 2002
@@ -376,6 +376,59 @@
Select this if you have a 32-bit processor and more than 4
gigabytes of physical RAM.
+# Choice: maxvm
+Maximum Virtual Memory
+CONFIG_1GB
+ If you have 4 Gigabytes of physical memory or less, you can change
+ where the where the kernel maps high memory. If you have less
+ than 1 gigabyte of physical memory, you should disable
+ CONFIG_HIGHMEM4G because you don't need the choices below.
+
+ If you have a large amount of physical memory, all of it may not
+ be "permanently mapped" by the kernel. The physical memory that
+ is not permanently mapped is called "high memory".
+
+ The numbers in the configuration options are not precise because
+ of the kernel's vmalloc() area, and the PCI space on motherboards
+ may vary as well. Typically there will 128 megabytes less
+ "user memory" mapped than the number in the configuration option.
+ Saying that another way, "high memory" will usually start 128
+ megabytes lower than the configuration option.
+
+ Selecting "05GB" results in a "3.5GB/0.5GB" kernel/user split:
+ 3.5 gigabytes are kernel mapped so each process sees a 3.5
+ gigabyte virtual memory space and the remaining part of the 4
+ gigabyte virtual memory space is used by the kernel to permanently
+ map as much physical memory as possible. On a system with 1 gigabyte
+ of physical memory, you may get 384 megabytes of "user memory" and
+ 640 megabytes of "high memory" with this selection.
+
+ Selecting "1GB" results in a "3GB/1GB" kernel/user split:
+ 3 gigabytes are mapped so each process sees a 3 gigabyte virtual
+ memory space and the remaining part of the 4 gigabyte virtual memory
+ space is used by the kernel to permanently map as much physical
+ memory as possible. On a system with 1 gigabyte of memory, you may
+ get 896 MB of "user memory" and 128 megabytes of "high memory"
+
+ Selecting "2GB" results in a "2GB/2GB" kernel/user split:
+ 2 gigabytes are mapped so each process sees a 2 gigabyte virtual
+ memory space and the remaining part of the 4 gigabyte virtual memory
+ space is used by the kernel to permanently map as much physical
+ memory as possible. On a system with 1 to 1.75 gigabytes of
+ physical memory, this option have all make it so no memory is
+ mapped as "high memory".
+
+ Selecting "3GB" results in a "1GB/3GB" kernel/user split:
+ 1 gigabyte is mapped so each process sees a 1 gigabyte virtual
+ memory space and the remaining part of the 4 gigabytes of virtual
+ memory space is used by the kernel to permanently map as much
+ physical memory as possible.
+
+ Options "2GB" and "3GB" may expose bugs that were dormant in
+ certain hardware, compilers, and possibly even the kernel.
+
+ If unsure, say "1GB".
+
HIGHMEM I/O support
CONFIG_HIGHIO
If you want to be able to do I/O to high memory pages, say Y.
diff -nur linux-2.4.18pre2aa2/Rules.make linux/Rules.make
--- linux-2.4.18pre2aa2/Rules.make Tue Mar 6 22:31:01 2001
+++ linux/Rules.make Mon Jan 14 23:58:55 2002
@@ -212,6 +212,7 @@
#
# Added the SMP separator to stop module accidents between uniprocessor
# and SMP Intel boxes - AC - from bits by Michael Chastain
+# Added separator for different PAGE_OFFSET memory models - Ingo.
#
ifdef CONFIG_SMP
@@ -220,6 +221,22 @@
genksyms_smp_prefix :=
endif
+ifdef CONFIG_2GB
+ifdef CONFIG_SMP
+ genksyms_smp_prefix := -p smp_2gig_
+else
+ genksyms_smp_prefix := -p 2gig_
+endif
+endif
+
+ifdef CONFIG_3GB
+ifdef CONFIG_SMP
+ genksyms_smp_prefix := -p smp_3gig_
+else
+ genksyms_smp_prefix := -p 3gig_
+endif
+endif
+
$(MODINCL)/%.ver: %.c
@if [ ! -r $(MODINCL)/$*.stamp -o $(MODINCL)/$*.stamp -ot $< ]; then
\
echo '$(CC) $(CFLAGS) $(EXTRA_CFLAGS) -E -D__GENKSYMS__ $<';
\
diff -nur linux-2.4.18pre2aa2/arch/i386/config.in linux/arch/i386/config.in
--- linux-2.4.18pre2aa2/arch/i386/config.in Tue Jan 15 00:01:38 2002
+++ linux/arch/i386/config.in Mon Jan 14 23:58:55 2002
@@ -169,7 +169,11 @@
if [ "$CONFIG_HIGHMEM64G" = "y" ]; then
define_bool CONFIG_X86_PAE y
else
- bool '3.5GB user address space' CONFIG_05GB
+ choice 'Maximum Virtual Memory' \
+ "3GB CONFIG_1GB \
+ 2GB CONFIG_2GB \
+ 1GB CONFIG_3GB \
+ 05GB CONFIG_05GB" 2GB
fi
if [ "$CONFIG_NOHIGHMEM" = "y" ]; then
define_bool CONFIG_NO_PAGE_VIRTUAL y
@@ -179,6 +183,7 @@
bool 'HIGHMEM I/O support (EXPERIMENTAL)' CONFIG_HIGHIO
fi
+
bool 'Math emulation' CONFIG_MATH_EMULATION
bool 'MTRR (Memory Type Range Register) support' CONFIG_MTRR
bool 'Symmetric multi-processing support' CONFIG_SMP
diff -nur linux-2.4.18pre2aa2/include/asm-i386/page_offset.h
linux/include/asm-i386/page_offset.h
--- linux-2.4.18pre2aa2/include/asm-i386/page_offset.h Tue Jan 15 00:01:38
2002
+++ linux/include/asm-i386/page_offset.h Mon Jan 14 23:58:55 2002
@@ -1,6 +1,10 @@
#include <linux/config.h>
-#ifndef CONFIG_05GB
-#define PAGE_OFFSET_RAW 0xC0000000
-#else
+#ifdef CONFIG_05GB
#define PAGE_OFFSET_RAW 0xE0000000
+#elif defined(CONFIG_1GB)
+#define PAGE_OFFSET_RAW 0xC0000000
+#elif defined(CONFIG_2GB)
+#define PAGE_OFFSET_RAW 0x80000000
+#elif defined(CONFIG_3GB)
+#define PAGE_OFFSET_RAW 0x40000000
#endif
diff -nur linux-2.4.18pre2aa2/mm/memory.c linux/mm/memory.c
--- linux-2.4.18pre2aa2/mm/memory.c Tue Jan 15 00:01:38 2002
+++ linux/mm/memory.c Mon Jan 14 23:59:18 2002
@@ -106,8 +106,7 @@
static inline void free_one_pgd(pgd_t * dir)
{
- int j;
- pmd_t * pmd;
+ pmd_t * pmd, * md, * emd;
if (pgd_none(*dir))
return;
@@ -118,9 +117,23 @@
}
pmd = pmd_offset(dir, 0);
pgd_clear(dir);
- for (j = 0; j < PTRS_PER_PMD ; j++) {
- prefetchw(pmd+j+(PREFETCH_STRIDE/16));
- free_one_pmd(pmd+j);
+
+ /*
+ * Beware if changing the loop below. It once used int j,
+ * for (j = 0; j < PTRS_PER_PMD; j++)
+ * free_one_pmd(pmd+j);
+ * but some older i386 compilers (e.g. egcs-2.91.66, gcc-2.95.3)
+ * terminated the loop with a _signed_ address comparison
+ * using "jle", when configured for HIGHMEM64GB (X86_PAE).
+ * If also configured for 3GB of kernel virtual address space,
+ * if page at physical 0x3ffff000 virtual 0x7ffff000 is used as
+ * a pmd, when that mm exits the loop goes on to free "entries"
+ * found at 0x80000000 onwards. The loop below compiles instead
+ * to be terminated by unsigned address comparison using "jb".
+ */
+ for (md = pmd, emd = pmd + PTRS_PER_PMD; md < emd; md++) {
+ prefetchw(md+(PREFETCH_STRIDE/16));
+ free_one_pmd(md);
}
pmd_free(pmd);
}
--
Randy Hron
^ permalink raw reply
* Re: [PATCH] O_DIRECT with hardware blocksize alignment
From: Jens Axboe @ 2002-01-15 13:55 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Joel Becker, Marcelo Tosatti, lkml
In-Reply-To: <20020115140852.I31878@suse.de>
On Tue, Jan 15 2002, Jens Axboe wrote:
> On Tue, Jan 15 2002, Andrea Arcangeli wrote:
> > actually we could also forbid merging at the ll_rw_block layer if b_size
> > is not equal, maybe that's the simpler solution to that problem after
> > all, merging between kiovec I/O and buffered I/O probably doesn't
> > matter.
>
> Agreed, this is also what I suggested.
Here's the right version, sorry. This still potentially decrements
elevator sequence wrongly for a missed front merge, but that's an issue
I can definitely live with :-)
--- /opt/kernel/linux-2.4.18-pre3/drivers/block/ll_rw_blk.c Tue Jan 15 14:06:13 2002
+++ drivers/block/ll_rw_blk.c Tue Jan 15 14:54:20 2002
@@ -694,10 +694,11 @@
switch (el_ret) {
case ELEVATOR_BACK_MERGE:
- if (!q->back_merge_fn(q, req, bh, max_segments)) {
- insert_here = &req->queue;
+ insert_here = &req->queue;
+ if (req->current_nr_sectors != count)
+ break;
+ if (!q->back_merge_fn(q, req, bh, max_segments))
break;
- }
elevator->elevator_merge_cleanup_fn(q, req, count);
req->bhtail->b_reqnext = bh;
req->bhtail = bh;
@@ -708,10 +709,11 @@
goto out;
case ELEVATOR_FRONT_MERGE:
- if (!q->front_merge_fn(q, req, bh, max_segments)) {
- insert_here = req->queue.prev;
+ insert_here = req->queue.prev;
+ if (req->current_nr_sectors != count)
+ break;
+ if (!q->front_merge_fn(q, req, bh, max_segments))
break;
- }
elevator->elevator_merge_cleanup_fn(q, req, count);
bh->b_reqnext = req->bh;
req->bh = bh;
--
Jens Axboe
^ permalink raw reply
* Re: [BUG] 2.4.18.3, ide-patch, read_dev_sector hangs in read_cache_page
From: Anton Altaparmakov @ 2002-01-15 13:54 UTC (permalink / raw)
To: preining; +Cc: linux-kernel, andre
Hi Norbert,
Could you try this patchlet to fs/partitions/check.c::read_dev_sector() and look if there is any output by dmesg? It's
a bit of a shot in the dark but will at least exclude this as the source for the peoblem...
diff -u -ur linux-2.4.18-pre3-ac2/fs/partitions/check.c linux-2.4.18-pre3-ac2-aia1/fs/partitions/check.c
--- linux-2.4.18-pre3-ac2/fs/partitions/check.c Fri Oct 12 01:25:10 2001
+++ linux-2.4.18-pre3-ac2-aia1/fs/partitions/check.c Tue Jan 15 13:21:24 2002
@@ -410,6 +410,14 @@
int sect = PAGE_CACHE_SIZE / 512;
struct page *page;
+ if (mapping->a_ops->sync_page != block_sync_page) {
+ if (mapping->a_ops->sync_page)
+ printk(KERN_CRIT "read_dev_sector: mapping->a_ops->sync_page != block_sync_page!\n");
+ else {
+ printk(KERN_CRIT "read_dev_sector: mapping->a_ops->sync_page is NULL! Setting to default block_sync_page!\n");
+ mapping->a_ops->sync_page = block_sync_page;
+ }
+ }
page = read_cache_page(mapping, n/sect,
(filler_t *)mapping->a_ops->readpage, NULL);
if (!IS_ERR(page)) {
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: David Woodhouse @ 2002-01-15 13:53 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <20020115080218.7709cef7.bruce@ask.ne.jp>
hpa@zytor.com said:
> If we have designed our kernels so that:
<...>
> b) It's not possible to add a driver without rebuilding the kernel,
> or;
<...>
> then we have screwed up.
Oops. In that case, we screwed up (130 - delta) times.
find /usr/src/linux/ -name \*.[ch] | xargs egrep \#if.*CONFIG_.*_MODULE | cut -f2- -d: | sort | uniq | wc -l
--
dwmw2
^ permalink raw reply
* RE: mpc860 vs. mpc860T
From: Steven Vacca @ 2002-01-15 13:52 UTC (permalink / raw)
To: LinuxEmbeddedMailList (E-mail)
OK, here goes.
My 860T rev is: duht-duhduh-duuuuuhh: XPC860TZP50B3 :>(
I guess that means I'll need some workarounds.
My embedded linux kernel is Redhat's mpc8xx-2.2.13, so
maybe porting in some workarounds might not be too painful.
Could I please get access to your workarounds, Magnus?
Thanks,
Steven
-----Original Message-----
From: Magnus Damm [SMTP:damm@opensource.se]
Sent: Tuesday, January 15, 2002 4:56 AM
To: svacca@valcom.com
Subject: Re: mpc860 vs. mpc860T
Early 860T cpu:s have lots of silicon bugs.
Check out the revision information and the errata.
If you have a 860TB3 or earlier you need workarounds.
Funny notice:
On one of the first 860T revisions it wasn't possible to
use the CPM and the fec at the same time...
One other problem I remember was related to SPR:s and
trashed cache...
I do have workarounds in my kernel, but they are for a
2.2.16-kernel.
Good luck /
Magnus
Steven Vacca wrote:
>
> I have 2 bds., the BD #1 is custom designed and based very
> closely on the design of the BD #2. The main difference
> is BD #1 uses an mpc860T and BD #2 uses an mpc860.
>
> Both have 32 Meg DRAM, 50MHz.
>
> I can use the exact same Flash Boot code on each,
> and download the exact same Linux kernel and app to each.
>
> BD #2 (mpc860) works perfectly, all the way thru to the app
> executing threads, etc.
>
> BD #1 (mpc860T) works up until at various points between when
> the kernel initializes itself, and the app execution begins, it gets
> exception errors, usually something similar to the following:
>
> Kernel panic: kernel access of bad area pc c0023634 lr c00235ec
> address 813F004C tsk kswapd/5
> or,
>
> Kernel panic: ramdisk: request list destroyed
>
> Does anyone know of any differences between the 2 CPU's, other than
> the mpc860T's internal FEC section and the MII interface on port D, that
> might cause such problems?
>
> Thanks,
>
> Steven
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Memory problem with bttv driver
From: Stephan von Krawczynski @ 2002-01-15 13:46 UTC (permalink / raw)
To: Gerd Knorr; +Cc: linux-kernel
In-Reply-To: <20020115142017.D8191@bytesex.org>
On Tue, 15 Jan 2002 14:20:17 +0100
Gerd Knorr <kraxel@bytesex.org> wrote:
> On Tue, Jan 15, 2002 at 12:14:24PM +0100, Stephan von Krawczynski wrote:
> > On 15 Jan 2002 10:17:03 GMT
> > Gerd Knorr <kraxel@bytesex.org> wrote:
> >
> > > MM wise it shouldn't make a difference whenever you are using 0.7.83 or
> > > 0.7.88 (I've mailed 0.7.88 patches to macelo for 2.4.18 btw). The 0.8.x
> > > versions have a complete different way to do the memory management.
> >
> > No vmallocs?
>
> Yes. Instead of remapping vmalloced kernel memory it gives you shared
> anonymous pages, then does zerocopy DMA using kiobufs. You may run in
> trouble with >4GB machines.
Interesting.
What's the problem on > 4GB ?
Regards,
Stephan
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Alan Cox @ 2002-01-15 13:57 UTC (permalink / raw)
To: Giacomo Catenazzi; +Cc: T. A., Linux Kernel Mailing List, esr
In-Reply-To: <3C4427F6.3010703@debian.org>
On Tue, Jan 15, 2002 at 02:00:38PM +0100, Giacomo Catenazzi wrote:
> How many people try new kernel with the wrong CPU configuration?
> (and mornally user know the name of own CPU, with netcards this is
> more difficult).
All of us get the CPU wrong. By using modules however I don't have to guess
the PCI devices. My system already did that. I just need the configurator
to hit M a lot and to work out which root devices are for the initrd.
The code for that exists
> PCI, USB and ISAPNP detection works well.
> ISA is a further step.
> I will send Eric the new detections and database for new probes (for ISA
> and others) drivers. So I hope also the ISA thread will end.
I suspect ISA is a dead loss - but again build all the modules, the user
system already has the right ones to load configured.
Alan
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Trond Myklebust @ 2002-01-15 13:40 UTC (permalink / raw)
To: Nikita Danilov
Cc: Neil Brown, Hans-Peter Jansen, linux-kernel, Reiserfs mail-list
In-Reply-To: <15428.14268.730698.637522@laputa.namesys.com>
>>>>> " " == Nikita Danilov <Nikita@Namesys.COM> writes:
> Yes, inode->i_generation is stored in the file handle:
> fs/reiserfs/inode.c:reiserfs_dentry_to_fh().
But what is stored in inode->i_generation? AFAICS
inode->i_generation = le32_to_cpu (INODE_PKEY (inode)->k_dir_id);
which appears not to be a unique generation count. Isn't that instead
the directory's object id?
The point of i_generation is to provide a unique number that changes
every time you reuse the inode number.
Cheers,
Trond
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: David L. Parsley @ 2002-01-15 13:40 UTC (permalink / raw)
To: Hans-Peter Jansen; +Cc: Neil Brown, Trond Myklebust, linux-kernel
In-Reply-To: <20020115115019.89B55143B@shrek.lisa.de>
Hrm, this sounds a lot like a problem I've been having as well. Server
is 2.2.19 (RedHat) + reiserfs; client is 2.4.12. There are times when I
mv the contents of public_html to a new location, then rm -rf
public_html, then make public_html a symlink to the new location. On
the client, I think what I would get is an I/O error when trying to list
or cd to public_html. On the server everything is fine, and the only
fix for this I've found is rebooting the client. The original
public_html directory is on a knfsd exported reiserfs fs.
Hopefully this is informative; the bug has only bitten me 2 or 3 times
in several months, and I've not been able to reproduce it at will. :-\
regards,
David
Hans-Peter Jansen wrote:
> Hi Neil et al.,
>
> during the last days, Trond and me was able to hunt a problem down
> to $subject, which happens as follows:
>
> It occurs with all 2.4 kernels, I've tested so far, but for reference:
>
> Server: 2.4.18-pre3 on Dual P3/500 exports reiserfs partitions
> Client: Diskless 2.4.18-pre3 on Athlon 1.2 GHz
>
> When building lm_sensors-2.6.2 on the client, I could easily reproduce
> this:
>
> gcc -shared -Wl,-soname,libsensors.so.1 -o lib/libsensors.so.1.2.0
> lib/data.lo lib/general.lo lib/error.lo lib/chips.lo lib/proc.lo
> lib/access.lo lib/init.lo lib/conf-parse.lo lib/conf-lex.lo -lc
> rm -f lib/libsensors.so.1
> ln -sfn libsensors.so.1.2.0 lib/libsensors.so.1
> make: stat:lib/libsensors.so.1: Eingabe-/Ausgabefehler
> rm -f lib/libsensors.so
> ln -sfn libsensors.so.1.2.0 lib/libsensors.so
>
> In syslog, this message appears:
> Jan 15 00:21:03 elfe kernel: nfs_refresh_inode: inode 50066 mode changed,
> 0100664 to 0120777
>
> In this case, ln managed to create an invalid link in the above sequence.
> Really bad is, you cannot get around this within the client. Within the
> server, the link is ok, but on the client, ls -l lib throws a
> ls: lib/libsensors.so.1: Eingabe-/Ausgabefehler
>
> A comment from Trond << EOC
> It is telling you that the server has a blatant bug: it is first
> telling the client that the inode 50066 is a regular file, then
> it changes it to a link.
>
> When this happens, the RFCs state that the server is supposed to
> change the NFS filehandle. The client *does* check the filehandle, so
> if the server had updated it correctly, you would not have had a
> problem.
> EOC
>
> A least, Trond was able to get me around it with this patch, but
> I would be nice to fix the real problem instead (b/c the build
> feels noticable slower with it):
>
> --- linux-2.4.18-up/fs/nfs/dir.c.orig Fri Jan 11 23:06:38 2002
> +++ linux-2.4.18-up/fs/nfs/dir.c Mon Jan 14 23:52:17 2002
> @@ -619,6 +619,8 @@
> nfs_complete_unlink(dentry);
> unlock_kernel();
> }
> + if (is_bad_inode(inode))
> + force_delete(inode);
> iput(inode);
> }
>
> --- linux-2.4.18-up/fs/nfs/inode.c.orig Fri Jan 11 23:08:00 2002
> +++ linux-2.4.18-up/fs/nfs/inode.c Mon Jan 14 23:53:10 2002
> @@ -699,6 +699,8 @@
> return 0;
> if (memcmp(&inode->u.nfs_i.fh, fh, sizeof(inode->u.nfs_i.fh)) != 0)
> return 0;
> + if (is_bad_inode(inode))
> + return 0;
> /* Force an attribute cache update if inode->i_count == 0 */
> if (!atomic_read(&inode->i_count))
> NFS_CACHEINV(inode);
>
> An noted, this is a longer standing problem here, but with libsensors build,
> I could easily reproduce this. Do yoou?
>
> Any chance to get this fixed soon?
>
> Cheers,
> Hans-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/
>
--
David L. Parsley
Network Administrator, Roanoke College
"If I have seen further it is by standing on ye shoulders of Giants."
--Isaac Newton
^ permalink raw reply
* Re: Memory problem with bttv driver
From: Gerd Knorr @ 2002-01-15 13:20 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: linux-kernel
In-Reply-To: <20020115121424.10bb89b2.skraw@ithnet.com>
On Tue, Jan 15, 2002 at 12:14:24PM +0100, Stephan von Krawczynski wrote:
> On 15 Jan 2002 10:17:03 GMT
> Gerd Knorr <kraxel@bytesex.org> wrote:
>
> > MM wise it shouldn't make a difference whenever you are using 0.7.83 or
> > 0.7.88 (I've mailed 0.7.88 patches to macelo for 2.4.18 btw). The 0.8.x
> > versions have a complete different way to do the memory management.
>
> No vmallocs?
Yes. Instead of remapping vmalloced kernel memory it gives you shared
anonymous pages, then does zerocopy DMA using kiobufs. You may run in
trouble with >4GB machines.
Gerd
--
#define ENOCLUE 125 /* userland programmer induced race condition */
^ permalink raw reply
* Re: initrd failure on Linux-2.4.17
From: Richard B. Johnson @ 2002-01-15 13:36 UTC (permalink / raw)
To: Jeff Chua; +Cc: Linux Kernel
In-Reply-To: <Pine.LNX.4.43.0201150846320.29728-100000@boston.corp.fedex.com>
On Tue, 15 Jan 2002, Jeff Chua wrote:
> On Mon, 14 Jan 2002, Richard B. Johnson wrote:
> > RAMDISK: Compressed image found at block 0
> > Freeing initrd memory: 581k freed
> > kernel panic: VFS: Unable to mount root fs on 01:00
> >
> > Has somebody fixed this or is it expected that nobody uses
> > an initial RAM disk on 2.4.17 ..or.. is this not the latest
> > "stable" version of Linux to use?
>
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 5384k freed
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 172k freed
>
> I booted with Linux-2.4.0 up to 2.4.18-pre3.
>
> Did you specify root=/dev/hda2 in your boot file?
>
No. Root is initially /dev/ram0, and will pivot-root to
/dev/scd1 once it works. The initial ram-disk, /dev/ram0
is never mounted so that's as far as it gets.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Rik van Riel @ 2002-01-15 13:32 UTC (permalink / raw)
To: m.knoblauch; +Cc: linux-kernel@vger.kernel.org, russ
In-Reply-To: <3C4414A7.8A3FF2FE@TeraPort.de>
On Tue, 15 Jan 2002, Martin Knoblauch wrote:
> How we get there I do not care to much. If -aa can solve the VM
> problems, fine. If rmap solves them, great. Just bring a working,
> maintainable solution in.
It would be nice if you could try -aa and -rmap in your
situation and give Andrea and me feedback on what needs
to be improved in our patches (it's software, I assume
it's not perfect ;)).
cheers,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
^ permalink raw reply
* Re: Penelope builds a kernel
From: David Woodhouse @ 2002-01-15 13:28 UTC (permalink / raw)
To: esr; +Cc: linux-kernel
In-Reply-To: <20020114165909.A20808@thyrsus.com>
esr@thyrsus.com said:
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
Bzzt. The PCMCIA card in question wasn't plugged in at the time so didn't
get enabled, and autoconfigure didn't realise that the software for it
actually needed CONFIG_NETLINK_DEV even though it wasn't in use at the time.
The sensible all-modules-under-the-sun vendor kernel had netlink_dev
available though, just in case. But when she calls the support person who's
responsible for the pre-installed Linux on her workstation and she
admits that she compiled her own kernel, she gets told to go away.
Pity the people who wrote the driver didn't use the saner approach:
make -C /lib/modules/`uname -r`/kernel SUBDIRS=`pwd` modules
--
dwmw2
^ permalink raw reply
* Re: Re: ACPI small patch update (20021024)
From: Pavel Machek @ 2002-01-15 13:23 UTC (permalink / raw)
To: Jan Rychter; +Cc: Grover, Andrew, acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <m2wuo7tc0g.fsf-dTJq59+VGzkkCw8IV3R6h0EOCMrvLtNR@public.gmane.org>
Hi!
> Andrew> As soon as Linus gets back, I'll be submitting all the
> Andrew> outstanding changes to him, and all the patchsets are on
> Andrew> linux-acpi.bkbits.net if anyone just wants to browse the most
> Andrew> recent changes.
>
> Not that I'm running this project, but I'd humbly suggest holding off
> those submissions until at least the recent regressions are fixed.
>
> 20021022 has blown off /proc/acpi/thermal and /proc/acpi/processor for
> me (and at least for one other person).
As these patches probably fix things for >1
person, too, I think holding them back is bad
idea. Remember, Linus likes small patches.
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --the elegant solution)
From: Giacomo Catenazzi @ 2002-01-15 13:17 UTC (permalink / raw)
To: Marco Colombo; +Cc: Alan Cox, esr, linux-kernel
In-Reply-To: <fa.k72pe6v.1tmgn1a@ifi.uio.no>
Marco Colombo wrote:
> Alan, Eric (and others, too), please.
> Of course the autoconfigurator is an useful piece of software.
> And of course Eric is posting to the wrong list here. Kernel developers
> don't need any autoconfigurator at all (yes, it's just "extra state").
The main discussion was in kbuild-devel list.
>
> Eric, Aunt Tillie doesn't need any custom-made, untested, probably not
> working kernel. QA comes at a price. The lastest VM fix may take a while
> to reach mainstream kernels. That's life.
Maybe this force kernel maintainer to merge the tested and trusted
distribution patches into the main kernel's branches.
Anyway, the target of Linux changes. If was a toy for hacker 10 year
ago, maybe in future will be the toy for Aunt Tillies. So:
Forget aunts and the other scenarios of Eric.
Let talk about what autoconfigure can do yet (aka the creation of
a /proc/drivers (better in /dev) with a list of all running
kernel drivers. aka how the modules will be in the next months)
giacomo
^ permalink raw reply
* Re: [PATCH] O_DIRECT with hardware blocksize alignment
From: Jens Axboe @ 2002-01-15 13:08 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Joel Becker, Marcelo Tosatti, lkml
In-Reply-To: <20020115132026.F22791@athlon.random>
On Tue, Jan 15 2002, Andrea Arcangeli wrote:
> actually we could also forbid merging at the ll_rw_block layer if b_size
> is not equal, maybe that's the simpler solution to that problem after
> all, merging between kiovec I/O and buffered I/O probably doesn't
> matter.
Agreed, this is also what I suggested.
--- /opt/kernel/linux-2.4.18-pre3/drivers/block/ll_rw_blk.c Tue Jan 15 14:06:13 2002
+++ drivers/block/ll_rw_blk.c Tue Jan 15 14:07:23 2002
@@ -694,10 +694,11 @@
switch (el_ret) {
case ELEVATOR_BACK_MERGE:
- if (!q->back_merge_fn(q, req, bh, max_segments)) {
- insert_here = &req->queue;
+ insert_here = &req->queue;
+ if (!q->back_merge_fn(q, req, bh, max_segments))
+ break;
+ if (req->current_nr_sectors != (bh->b_size >> 9))
break;
- }
elevator->elevator_merge_cleanup_fn(q, req, count);
req->bhtail->b_reqnext = bh;
req->bhtail = bh;
@@ -708,10 +709,11 @@
goto out;
case ELEVATOR_FRONT_MERGE:
- if (!q->front_merge_fn(q, req, bh, max_segments)) {
- insert_here = req->queue.prev;
+ insert_here = req->queue.prev;
+ if (!q->front_merge_fn(q, req, bh, max_segments))
+ break;
+ if (req->current_nr_sectors != (bh->b_size >> 9))
break;
- }
elevator->elevator_merge_cleanup_fn(q, req, count);
bh->b_reqnext = req->bh;
req->bh = bh;
--
Jens Axboe
^ 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.