* Re: massive compile failures w/ 2.5.51 on RH8.0
From: Dave Jones @ 2002-12-13 12:20 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Rod Van Meter, linux-kernel
In-Reply-To: <Pine.LNX.4.33L2.0212122140500.21077-100000@dragon.pdx.osdl.net>
On Thu, Dec 12, 2002 at 09:42:39PM -0800, Randy.Dunlap wrote:
> and some of these may have patches available for them on lkml.
> I know that intermezzo does, from Peter Braam, with a small
> follow-up by me, so it's fixable if you want it. Surely (Rod ;).
>From reading bugzilla #11, it seems even with your additional
patch intermezzo still has problems..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* rmap15b available for 2.4.20-ck1
From: Con Kolivas @ 2002-12-13 12:22 UTC (permalink / raw)
To: linux kernel mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just updated the optional rmap vm patch for -ck to the latest rmap15b
Get it here:
http://kernel.kolivas.net
Con
P.S. This may soon become the default vm for -ck patches
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE9+dEiF6dfvkL3i1gRAgVkAJ4wDkJeWZQ5ScKa07kN3xHxLWkwXACgpaex
B6wImGlfygTUvvpvM13mO6k=
=ttkM
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Notifier for significant events on i386
From: Vamsi Krishna S . @ 2002-12-13 12:32 UTC (permalink / raw)
To: John Levon; +Cc: Stephen Hemminger, Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021212175804.GA15860@compsoc.man.ac.uk>
On Thu, Dec 12, 2002 at 05:58:04PM +0000, John Levon wrote:
> On Thu, Dec 12, 2002 at 09:53:35AM -0800, Stephen Hemminger wrote:
>
> > The use of notifier today is limited to things that can't sleep. As far
>
> kernel/profile.c
>
> You'd have to move that to a different API if you want to force notifier
> callbacks non-sleepable
>
Yes, indeed most of the existing notifiers potentially sleep. That is why
I think we should, may be, leave the existing notifiers alone. Add a
notifier_call_chain_safe() and use that to run trap1/trap3/NMI etc
notifiers.
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
^ permalink raw reply
* Re: separation of sysctl and tcp-window-tracking patch?
From: Patrick Schaaf @ 2002-12-13 12:06 UTC (permalink / raw)
To: James Ralston; +Cc: netfilter-devel
In-Reply-To: <Pine.LNX.4.44.0212130314131.2834-100000@shieldbreaker.l33tskillz.org>
> Failing a helper, I'm unable to come up with anything better than
> adjusting timeouts on a per-port basis...
What about a single new target, CTTIMEOUT or something, having a single
parameter, a relative timeout in seconds. Whenever that target hits,
and we have a connection hanging off our skb, the connection's timeout
will be refreshed to now+the_given_timeout.
This could be equally used to lower TCP ESTABLISHED timeouts for
certain uses, and for extending the UDP timeouts discussed here.
You would use normal, arbitrary matches to select _which_ packets
should receive the treatment.
I have not thought about the interplay with the current automatic
timeout selection. Anybody?
best regards
Patrick
^ permalink raw reply
* Re: Does IPTables have a 1:1 port-forwarding capability for a DNAT port-range ?
From: Andrea Rossato @ 2002-12-13 12:02 UTC (permalink / raw)
To: netfilter
In-Reply-To: <000601c2a23f$619ffef0$0100a8c0@zultys.com>
Ranjeet Shetye wrote:
> The reason for wanting a 1:1 rule is for X windows and other fat port
> ranges. Dont want hundreds of rules in there if one can do the job. Can
> IPTables do it ? If so how ? If not, I guess I'll have to get in touch
> with the developers for tips on a good starting point.
I believe that the only way is to hack nat code.
I will start looking in
net/ipv4/netfilter/ip_nat_core.c
and the function manip_pkt that, as far as I understand, is actually
writing the NATed packet
andrea
^ permalink raw reply
* ACPI/S3: simplify assembly code a bit
From: Pavel Machek @ 2002-12-12 20:37 UTC (permalink / raw)
To: kernel list, torvalds
Hi!
Kill unused variable and simplify assembly portion a bit... Please
apply,
Pavel
--- clean/arch/i386/kernel/acpi.c 2002-12-11 23:33:53.000000000 +0100
+++ linux-swsusp/arch/i386/kernel/acpi.c 2002-12-12 19:05:13.000000000 +0100
@@ -448,10 +448,11 @@
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
+extern char wakeup_start, wakeup_end;
extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
-static void init_low_mapping(pgd_t *pgd, int pgd_ofs, int pgd_limit)
+static void init_low_mapping(pgd_t *pgd, int pgd_limit)
{
int pgd_ofs = 0;
@@ -473,7 +474,8 @@
panic("S3 and PAE do not like each other for now.");
return 1;
#endif
- init_low_mapping(swapper_pg_dir, 0, USER_PTRS_PER_PGD);
+ init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
+ memcpy((void *) acpi_wakeup_address, &wakeup_start, &wakeup_end - &wakeup_start);
acpi_copy_wakeup_routine(acpi_wakeup_address);
return 0;
@@ -506,7 +508,6 @@
*/
void __init acpi_reserve_bootmem(void)
{
- extern char wakeup_start, wakeup_end;
acpi_wakeup_address = (unsigned long)alloc_bootmem_low(PAGE_SIZE);
if ((&wakeup_end - &wakeup_start) > PAGE_SIZE)
printk(KERN_CRIT "ACPI: Wakeup code way too big, will crash on attempt to suspend\n");
--- clean/arch/i386/kernel/acpi_wakeup.S 2002-12-11 23:33:53.000000000 +0100
+++ linux-swsusp/arch/i386/kernel/acpi_wakeup.S 2002-12-05 18:02:30.000000000 +0100
@@ -239,20 +241,11 @@
#
ENTRY(acpi_copy_wakeup_routine)
- pushl %esi
- pushl %edi
-
sgdt saved_gdt
sidt saved_idt
sldt saved_ldt
str saved_tss
- movl %eax, %edi
- leal wakeup_start, %esi
- movl $(wakeup_end - wakeup_start + 3) >> 2, %ecx
-
- rep ; movsl
-
movl %cr3, %edx
movl %edx, real_save_cr3 - wakeup_start (%eax)
movl %cr4, %edx
@@ -265,10 +258,6 @@
movl %edx, video_mode - wakeup_start (%eax)
movl $0x12345678, real_magic - wakeup_start (%eax)
movl $0x12345678, saved_magic
-
- # restore the regs we used
- popl %edi
- popl %esi
ret
.data
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* ACPI/S3: fix gcc3.2 compatibility
From: Pavel Machek @ 2002-12-12 20:38 UTC (permalink / raw)
To: kernel list, torvalds, Rusty trivial patch monkey Russell
Hi!
gcc3.2 is a bit more pedantic... Please apply,
Pavel
--- clean/arch/i386/kernel/suspend_asm.S 2002-12-11 23:33:53.000000000 +0100
+++ linux-swsusp/arch/i386/kernel/suspend_asm.S 2002-12-06 17:52:18.000000000 +0100
@@ -6,7 +6,7 @@
#include <asm/segment.h>
#include <asm/page.h>
-ENTRY(do_magic):
+ENTRY(do_magic)
pushl %ebx
cmpl $0,8(%esp)
jne .L1450
@@ -66,7 +66,7 @@
.L1453:
movl $104,%eax
- movw %eax, %ds
+ movw %ax, %ds
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_eax, %eax
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Pavel Machek @ 2002-12-12 18:09 UTC (permalink / raw)
To: Denis Vlasenko
Cc: Daniel Egger, Dave Jones, Joseph, linux-kernel@vger.kernel.org
In-Reply-To: <200212110829.gBB8Tja05013@Port.imtp.ilyichevsk.odessa.ua>
Hi!
> > > I believe someone (Jeff Garzik?) benchmarked gcc code generation,
> > > and the C3 executed code scheduled for a 486 faster than it did for
> > > -m586
> > > I'm not sure about the alignment flags. I've been meaning to look
> > > into that myself...
> >
> > Interesting. I have no clue about which C3 you're talking about here
> > but a VIA Ezra has all 686 instructions including cmov and thus
> > optimising for PPro works best for me.
> >
> > Prolly I would have to do more benchmarking to find out about
> > aligment advantages.
>
> I heard cmovs are microcoded in Centaurs.
>
> s...l...o...w...
It still might be faster then a branch... or not if centaurs are
really that simple.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* 2.5.51: new warning from lilo
From: Pavel Machek @ 2002-12-12 19:34 UTC (permalink / raw)
To: kernel list
Hi!
Lilo now presents me with new warning:
Warning: Kernel & BIOS return differing head/sector geometries for
device 0x80
Kernel: 8944 cylidners, 15 heads, 63 sectors
BIOS: 525 cylinders, 255 heads, 63 sectors
lilo did not warn under 2.5.50. Now... Will it boot?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* vesafb no longer works on 2.5.50/51
From: Pavel Machek @ 2002-12-12 19:29 UTC (permalink / raw)
To: kernel list
Hi!
On one of my machines, vesafb no longer works in 2.5.51 (other machine
is okay?!).
Everything is okay, except I can not see anything on the display.
2.4. (vesafb works):
vesafb: framebuffer at 0xee000000, mapped to 0xd080d000, size 8192k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at c000:7652
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
2.5.51 (vesafb does not work):
vesafb: framebuffer at 0xee000000, mapped to 0xd0815000, size 8192k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at c000:7652
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* key "stuck" after resume
From: Pavel Machek @ 2002-12-12 19:46 UTC (permalink / raw)
To: vojtech, kernel list
Hi!
Vojtech, would it be possible to clear "keyboard down" map during
resume? It is pretty unlikely to be valid at that point :-).
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: IDE feature request & problem
From: Pavel Machek @ 2002-12-12 18:12 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Alan Cox, Milan Roubal, Petr Sebor, Linux Kernel Mailing List
In-Reply-To: <20021211210416.A506@ucw.cz>
Hi!
> > > I have got xfs partition and man fsck.xfs say
> > > that it will run automatically on reboot.
> >
> > You need to force one. Something (I assume XFS) asked the disk for a
> > stupid sector number. Thats mostly likely due to some kind of internal
> > corruption on the XFS
>
> Or the power supply doesn't give enough power to the drives anymore (my
> 350W PSU is having heavy problems with five or more drives), and the IDE
> transfers get garbled. Note that there is no CRC protection for non-data
> xfers even when UDMA is in use, which includes LBA sector addressing.
But kernel would not log bogus LBA in such case.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Andrew McGregor @ 2002-12-13 11:48 UTC (permalink / raw)
To: Bogdan Costescu, David S. Miller
Cc: dlstevens, matti.aarnio, niv, alan, stefano.andreani.ap,
linux-kernel, linux-net
In-Reply-To: <Pine.LNX.4.44.0212131233220.11129-100000@kenzo.iwr.uni-heidelberg.de>
You're going to make lots of IETFer's really annoyed by suggesting that :-)
Honestly, there are lots of other ways to solve this, and it would be nice
if the IETF's recent additions got implemented; there are many relevant
things going on there. Those interested should just talk to the draft
authors about implementing things. It's an open organisation just like
linux-kernel after all, just a bit more formal.
In a closed network, why not have SOCK_STREAM map to something faster than
TCP anyway? That is, if I connect(address matching localnet), SOCK_STREAM
maps to (eg) SCTP. That would be a far more dramatic performance hack!
Andrew
--On Friday, December 13, 2002 12:46:15 +0100 Bogdan Costescu
<bogdan.costescu@iwr.uni-heidelberg.de> wrote:
> On Thu, 12 Dec 2002, David S. Miller wrote:
>
>> This is well understood, the problem is that BSD's coarse timers are
>> going to cause all sorts of problems when a Linux stack with a reduced
>> MIN RTO talks to it.
>
> Sorry to jump into the discussion without a good understanding of inner
> workings of TCP, I just want to share my view as a possible user of this:
> one of the messages at the beginning of the thread said that this would
> be useful on a closed network and I think that this point was overlooked.
>
> Think of a closed network with only Linux machines on it (world
> domination, right :-)) like a Beowulf cluster, web frontends talking to
> NFS fileservers, web frontends talking to database backends, etc. Again
> as proposed earlier, border hosts (those connected to both the closed
> network and outside one) could change their communication parameters
> based on device or route and this would become an internal affair that
> would not affect communication with other stacks.
>
> I don't want to suggest to make this the default behaviour; rather, have
> it a parameter that can be changed by the sysadmin and have the current
> value as default.
>
> --
> Bogdan Costescu
>
> IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
> Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
> Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
> E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
>
> -
> 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.5.51 won't boot with devfs enabled
From: Gregoire Favre @ 2002-12-13 12:01 UTC (permalink / raw)
To: Helge Hafting; +Cc: linux-kernel
In-Reply-To: <3DF70CA8.CC553446@aitel.hist.no>
On Wed, Dec 11, 2002 at 11:00:08AM +0100, Helge Hafting wrote:
TREMENDOUS: without those four ligns, I can boot 2.5.51 ;-)
Thank you very much!!!
> Booting anything later than 2.5.48 with devfs configured
> either needs an extra kernel parameter, or a code change.
> Something broke when do_mounts.c were reorganized.
> It doesn't matter wether devfs is used or not, as long as it
> is configured.
>
> The lilo solution:
> lilo tend to have a "root=/dev/hda1" or similiar.
> This gets converted to "root=0301" on the kernel command line.
> (Look at dmesg after a successful boot)
>
> But this don't work for some reason when devfs is configured.
> Use the following:
>
> append="root=/dev/hda1"
>
> to solve the problem. This isn't converted to numbers and works.
> Of course if you use auto-mounted devfs then you don't
> have a /dev/hda1 but a /dev/ide/host0/bus0/target0/lun0/part1
> instead. If so, use that as root instead. You still have
> to use the append= trick.
>
> The code solution:
> Edit init/do_mounts.c
> Remove the following lines from the beginning of
> the function prepare_namespace:
> #ifdef CONFIG_DEVFS_FS
> sys_mount("devfs", "/dev", "devfs", 0, NULL);
> do_devfs = 1;
> #endif
> Then recompile, and the kernel should work with any lilo setup that
> worked for 2.5.47 and earlier. At least it worked for the setups
> I tried.
>
> This has no effect on kernels without devfs, and helps for kernels
> comiled with devfs wether devfs is used or not.
> I posted a patch for this, but there were no interest at all.
Grégoire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:greg@ulima.unil.ch
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Dave Jones @ 2002-12-13 11:57 UTC (permalink / raw)
To: Joseph; +Cc: Linux Kernel Mailing List
In-Reply-To: <004d01c2a274$915cf690$3716a8c0@taipei.via.com.tw>
On Fri, Dec 13, 2002 at 02:55:04PM +0800, Joseph wrote:
> I've checked the gcc CVS. But it seems to use i486 pluse MMX and 3DNOW
> instructions.
> * config.gcc: Treat winchip_c6-*|winchip2-*|c3-* as pentium-mmx.
> * config/i386/i386.c (processor_alias_table): Add winchip-c6, winchip2 and
> c3.
> * doc/invoke.texi: Mention new aliases.
> ** {"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW}, **
> Is there any plan to optimize for C3 CPU in future gcc released version?
Maybe if an optimisation guide appears for the C3.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Local APIC(?)+PIII mobile
From: João Seabra @ 2002-12-13 11:56 UTC (permalink / raw)
To: linux-kernel
Hi all
I have an Asus S8600.
Mobile PIII 800Mhz + 192M RAM.
If i select "Local APIC support on uniprocessors" the kernel while booting
says there's no APIC present.Why?
I know the same problem with some other laptops.
Others detect it.
At home my Athlon Tunderbird + Asus A7V133-C with local APIC enabled detects
it but doesn seem to use it ...
cat /proc/interrupts
CPU0
0: 375529 XT-PIC timer
1: 7452 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 113246 XT-PIC bttv, eth0
8: 2 XT-PIC rtc
10: 144373 XT-PIC EMU10K1
11: 382444 XT-PIC nvidia
12: 153864 XT-PIC PS/2 Mouse
14: 12346 XT-PIC ide0
15: 12 XT-PIC ide1
NMI: 0
ERR: 0
Anyway why do I need local APIC :) ?What are the advantages?Links?
Thank you very much for your kindness
Best Regards,
João Seabra
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Andrew McGregor @ 2002-12-13 11:40 UTC (permalink / raw)
To: Nivedita Singhvi, Matti Aarnio
Cc: Alan Cox, Andreani Stefano, David S. Miller,
Linux Kernel Mailing List, linux-net
In-Reply-To: <3DF965E4.95DEA1F9@us.ibm.com>
Er, wasn't that SCTP? If so, that's RFC 3309 and many, many drafts. You
might also want to look at DCCP (draft-ietf-dccp-*) and the various
documents from the IETF's PILC group. There is also a proposal for a new
TCP-style protocol with a real differential controller, the name of which I
can't recall right now.
See also draft-allman-tcp-sack for another proposal for a fix that won't
break old stacks. Also draft-ietf-tsvwg-tcp-eifel-alg,
draft-ietf-tsvwg-tcp-eifel-response and many more.
I can't claim to be a TCP expert, but TCP_RTO_MIN can certainly have a
different value for IPv6, where I believe millisecond reolution timers are
required, so 2ms would be correct.
Unfortuntately, TCP is incredibly subtle. So, the IETF are really
conservative about even suggesting modifications to it, because a common
and badly behaved stack can cause major disasters in the 'net.
Andrew
--On Thursday, December 12, 2002 20:45:24 -0800 Nivedita Singhvi
<niv@us.ibm.com> wrote:
>> You are looking for "STP" perhaps ?
>> It has a feature of waking all streams retransmits, in between
>> particular machines, when at least one STP frame travels in between
>> the hosts.
>>
>> I can't find it now from my RFC collection. Odd at that..
>> Neither as a draft. has it been abandoned ?
>
> Learn something new every day :). Thanks for the ptr. I'll
> look it up..
>
>> > It would be wonderful if we could tune TCP on a per-interface or a
>> > per-route basis (everything public, for a start, considered the
>> > internet, and non-routable networks (10, etc), could be configured
>> > suitably for its environment. (TCP over private LAN - rfc?). Trusting
>> > users would be a big issue..
>> >
>> > Any thoughts? How stupid is this? Old hat??
>>
>> More and more of STP ..
>
> thanks,
> Nivedita
^ permalink raw reply
* New device-mapper patchset for 2.5.51
From: Joe Thornber @ 2002-12-13 11:50 UTC (permalink / raw)
To: Linux Mailing List, lvm-devel, linux-lvm
If anyone was experiencing problems with dm could they please try this
patchset and give me feedback.
Thanks,
- Joe
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-3.tar.bz2
Changes
-------
Revision 1:
Four constants:
DM_DIR,
DM_MAX_TYPE_NAME,
DM_NAME_LEN,
DM_UUID_LEN
Were being declared in device-mapper.h, these are all specific to
the ioctl interface, so they've been moved to dm-ioctl.h. Nobody
in userland should ever include <linux/device-mapper.h> so remove
ifdef __KERNEL guards.
Revision 2:
An error value was not being checked correctly in open_dev().
[Kevin Corry]
Revision 3:
Return -ENOTBLK if lookup_device() finds the inode, but it
is not a block device. [Cristoph Hellwig]
Revision 4:
No need to validate the parameters if we are doing a
REMOVE_ALL command.
Revision 5:
check_device_area was comparing the bytes with sectors.
[Stefan Lauterbach]
Revision 6:
minor change for dm-strip.c. Tests for correct chunksize before it allocates
the stripe context. [Heinz Mauelshagen]
Revision 7:
There's a bug in the dm-stripe.c constructor failing top check if enough
destinations are handed in. [Heinz Mauelshagen]
Revision 8:
Give each device its own io mempool to avoid a potential
deadlock with stacked devices. [HM + EJT]
Revision 9:
queue_io() was checking the DMF_SUSPENDED flag rather than the new
DMF_BLOCK_IO flag. This meant suspend could deadlock under load.
Revision 10:
dm_suspend(): Stop holding the read lock around the while loop that
waits for pending io to complete.
Revision 11:
Add a blk_run_queues() call to encourage pending io to flush
when we're doing a dm_suspend().
Revision 12:
dec_pending(): only bother spin locking if io->error is going to be
updated. [Kevin Corry]
Revision 13:
md->pending was being incremented for each clone rather than just
once. [Kevin Corry]
Revision 14:
Some fields in the duplicated bio weren't being set up properly in
__split_page(). [Kevin Corry]
Revision 15:
Remove some paranoia in highmem.c, need to check this with Jens Axboe.
Revision 16:
Remove verbose debug message 'Splitting page'.
Revision 17:
o If there's an error you still need to call bio_endio with bio->bi_size
as the 'done' param.
o Simplify clone_endio.
[Kevin Corry]
Revision 18:
The block layer does not honour bio->bi_size when issuing io, instead
it performs io to the complete bvecs. This means we have to change
the bio splitting code slightly.
Given a bio we repeatedly apply one of the following three operations
until there is no more io left in the bio:
1) The remaining io does not cross an io/target boundary, so just
create a clone and issue all of the io.
2) There are some bvecs at the start of the bio that are not split by
a target boundary. Create a clone for these bvecs only.
3) The first bvec needs splitting, use bio_alloc() to create *two*
bios, one for the first half of the bvec, the other for the second
half. A bvec can never contain more than one boundary.
Revision 19:
For large bios it was possible to look up the wrong target. Bug
introduced by the recent splitting changes.
Revision 20:
The linear target was getting the start sector wrong when doing a
dm_get_device(). [Kevin Corry]
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Bogdan Costescu @ 2002-12-13 11:46 UTC (permalink / raw)
To: David S. Miller
Cc: dlstevens, matti.aarnio, niv, alan, stefano.andreani.ap,
linux-kernel, linux-net
In-Reply-To: <20021212.225912.115906105.davem@redhat.com>
On Thu, 12 Dec 2002, David S. Miller wrote:
> This is well understood, the problem is that BSD's coarse timers are
> going to cause all sorts of problems when a Linux stack with a reduced
> MIN RTO talks to it.
Sorry to jump into the discussion without a good understanding of inner
workings of TCP, I just want to share my view as a possible user of this:
one of the messages at the beginning of the thread said that this would be
useful on a closed network and I think that this point was overlooked.
Think of a closed network with only Linux machines on it (world
domination, right :-)) like a Beowulf cluster, web frontends talking to
NFS fileservers, web frontends talking to database backends, etc. Again as
proposed earlier, border hosts (those connected to both the closed
network and outside one) could change their communication parameters based
on device or route and this would become an internal affair that would not
affect communication with other stacks.
I don't want to suggest to make this the default behaviour; rather, have
it a parameter that can be changed by the sysadmin and have the current
value as default.
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
^ permalink raw reply
* Re: [PATCH] 2.4.20-rmap15b - compile failure
From: Rik van Riel @ 2002-12-13 11:30 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: linux-kernel
In-Reply-To: <3DF9BCAA.C96AA165@eyal.emu.id.au>
On Fri, 13 Dec 2002, Eyal Lebedinsky wrote:
> I had a failure building NVIDIA_kernel/nv.c (the nvidia driver):
> http://download.nvidia.com/XFree86_40/1.0-4191/NVIDIA_kernel-1.0-4191.tar.gz
>
> It uses
> pte = *pte_offset(pg_mid_dir, address);
> but this patch removes pte_offset().
>
> 1) what is the correct fix (use pte_offset_kernel?)?
I'd assume so, but since I don't know exactly what the nvidia
driver does I can't tell you for sure.
> 2) in general, is it wise to remove pte_offset() or should it
> be left for compatability?
It should be removed, otherwise some drivers would compile
but silently fail (because pte_offset() wouldn't be the right
choice from the two alternatives.
regards,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://guru.conectiva.com/
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Friedrich Ewaldt @ 2002-12-13 11:17 UTC (permalink / raw)
To: Thierry Vignaud; +Cc: Takashi Iwai, alsa-user, alsa-devel
In-Reply-To: <m27keexn25.fsf@vador.mandrakesoft.com>
Hi!
For new test results see the end of this mail.
Thierry Vignaud wrote:
>Takashi Iwai <tiwai@suse.de> writes:
>
>
>
>>>Mandrake Control Center recognices the card as follows (partly in
>>>german, sorry, but perhaps that's no problem in ERL/NUE ;-) ):
>>>
>>>Hersteller: Fortemedia, Inc
>>>Bus: PCI
>>>Bus: 1319:801:1319:1319
>>>Standort auf den Bus: 0:b:0
>>>Beschreibung: Xwave QS3000A [FM801]
>>>Modul: snd-fm801
>>>Medienklasse: MULTIMEDIA_AUDIO
>>>
>>>
>
>this information came frome harddrake which uses libldetect (which is
>also used by lspcidrake).
>
>bus is vendor_id:card_id:subvendor_id:subcard_id
>bus position (Standort auf den Bus) is pci_bus:pci_device:pci_function
>Beschreibung is of course description of the device and Hersteller is
>vendor
>module is of course kernel module
>
>the driver association is made by libldetect from
>/usr/share/ldetect-lst/pcitable :
>
>tv@vador ~ $ fgrep fm801 /usr/share/ldetect-lst/pcitable
>0x1319 0x0801 "snd-fm801" "Fortemedia, Inc|Xwave QS3000A [FM801]"
>0x1319 0x1000 "snd-fm801" "Fortemedia, Inc|FM801 PCI Audio"
>
>
>
>>>I had no alsa installed while running hardware detection.
>>>
>>>
>
>alsa drivers're included in mandrake kernel
>
>
No, sorry. I recompiled the kernel with sound but without alsa because I
wanted to use an alsa version newer than rc2 to check if the problem was
solved already. I already installed rc6 and a newer cvs version on
another mdk9.0 system without problems. I should have done
recompiling/installing the kernel and newer alsa version correctly.
>>you can check this also via lspci command.
>>
>>
>
>lspcidrake -v will give him the module too
>
>
I already attached my lspci -v outputs in two previous mails, but to be
sure they get to where they should ...
00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
[FM801] (rev a0)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 40, IRQ 10
I/O ports at ec00 [size=128]
Capabilities: [dc] Power Management version 1
00:0b.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801]
(rev a0)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 40, IRQ 11
Capabilities: [dc] Power Management version 1
>>in the output of lspci in your last mail, the i/o ports and irq are
>>missing. please check again?
>>
>>
>
>in order to have the full information, i would like Friedrich to send
>us the following information (what i call the classic bug sound
>tester) :
>
>"lspcidrake -v | fgrep AUDIO" will tell you which driver your card use
>by default
>
>"grep snd-slot /etc/modules.conf" will tell you what driver it
>currently uses
>
>
I threw out all entries regarding soundcards from modules.conf.
modprobing the snd-fm801 module is enough to cause the problems.
>"/sbin/lsmod" will enable you to check if its module (driver) is
>loaded or not
>
no sound module is loaded (because nothing there in modules.conf) up to
the point where I do a 'modprobe snd-fm801'. As soon as I do, the
following modules are added:
snd-fm801 9772 0 (unused)
snd-pcm 71328 0 [snd-fm801]
snd-mpu401-uart 3840 0 [snd-fm801]
snd-rawmidi 15424 0 [snd-mpu401-uart]
snd-opl3-lib 7652 0 [snd-fm801]
snd-timer 12908 0 [snd-pcm snd-opl3-lib]
snd-hwdep 5152 0 [snd-opl3-lib]
snd-ac97-codec 31620 0 [snd-fm801]
snd 36076 0 [snd-fm801 snd-pcm snd-mpu401-uart
snd-rawmidi snd-opl3-lib snd-timer snd-hwdep snd-ac97-codec]
soundcore 4068 0 [snd]
>
>"/sbin/chkconfig --list sound" and "/sbin/chkconfig --list alsa" will
>tell you if sound and alsa services're configured to be run on
>initlevel 3
>
>"aumix -q" will tell you if the sound volume is muted or not
>
>
no mixer problems
>"/sbin/fuser -v /dev/dsp" will tell which program uses the sound card.
>
>
none. I've deactivated artsd and have no other sound daemon installed.
The only programs that produce sound are controlled by me. (But now I
know that even hitting backspace once in Konsole causes a beep that
locks the system. Not really! The END of the beep does! see below)
>
>this will tell us at which stage the problem happen
>
>
>
OK. I've done new tries. Now I know that modprobing snd-fm801 causes the
following to be written in /var/log/messages:
Dec 13 11:53:24 localhost kernel: ALSA ../alsa-kernel/pci/fm801.c:922:
unable to grab region 0x0-0x7f
If I do not produce any sound output, the system does not lock up as
I've written before (I must have caused an error beep in a KDE terminal.
I've tried this: Causing a beep locks the system immediately). Sorry for
the misleading information. My fault.
After another reboot (always interesting if the filesystem was damaged
;-) ), I modprobed snd-fm801 and used aplay to play a wav file. It does
without problems. But at the same time the playback stops, the system
locks up.
So, in summary, the critical moment is stopping playback on the fm801. I
think, I've read the same problem description somewhere before. What
could I try next?
Thanks for all your help so far!
fe
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Friedrich Ewaldt @ 2002-12-13 11:15 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-user, alsa-devel
In-Reply-To: <s5h3cp3uorz.wl@alsa2.suse.de>
Takashi Iwai wrote:
>you can check this also via lspci command.
>in the output of lspci in your last mail, the i/o ports and irq are
>missing. please check again?
>
here we go...
00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
[FM801] (rev a0)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 40, IRQ 10
I/O ports at ec00 [size=128]
Capabilities: [dc] Power Management version 1
00:0b.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801]
(rev a0)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 40, IRQ 11
Capabilities: [dc] Power Management version 1
the first entry seems to be the audio functionality, the second one must
be the game port.
IRQ 10 is shared with USB controller, IRQ 11 is shared with VGA controller.
>>The soundcard is working correctly under win98 without the need to
>>change any hardware or bios settings.
>>win98 reports:
>>fm801 pci audio, IRQ 10, I/O: EC00-EC7F
>>plus
>>fm801 pci audio, IRQ 11
>>and 'no conflicts'. I.e. win98 shows up the same IRQs used as lspci,
>>that should be correct, then. But lspci doesn't name any memory regions
>>used by this card. Do you have any idea what I could try? (I'll test
>>some other bios settings, mounting the card in another slot when I find
>>some spare time).
>>
>>
>
>what is the bios configuration? pnp os is yes? then set it to no.
>is ACPI enabled on kernel?
>
>
pnp was set to 'yes' in bios. I set it to 'no', but the system still
locks after loading alsa driver. To be more precisely: I did modprobe
snd-fm801, started aplay, stopped aplay, started arecord and after some
seconds the system hang. But the system hang just some seconds after
modprobing without using the audio device in a try before.
Here's the /var/log/messages output before(after) the system hangs:
Dec 12 19:13:27 localhost kernel: PCI: Found IRQ 10 for device 00:0b.0
Dec 12 19:13:27 localhost kernel: PCI: Sharing IRQ 10 with 00:07.2
Dec 12 19:13:27 localhost kernel: PCI: Sharing IRQ 10 with 00:07.3
Dec 12 19:13:27 localhost kernel: PCI: Found IRQ 11 for device 00:0b.1
Dec 12 19:13:27 localhost kernel: ALSA ../alsa-kernel/pci/fm801.c:922:
unable to grab region 0x0-0x7f
Dec 12 19:14:56 localhost syslogd 1.4.1: restart.
ACPI is not enabled in kernel (but APM is, which should not be a
problem, I think).
Any further hints? I just don't want to crash my filesystems too often.
Hopefully, ext3 does its job.
Ahh! Perhaps I should remount read-only next time :-)
fe
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Daniel Egger @ 2002-12-13 11:04 UTC (permalink / raw)
To: Joseph; +Cc: Linux Kernel Mailing List
In-Reply-To: <004d01c2a274$915cf690$3716a8c0@taipei.via.com.tw>
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
Am Fre, 2002-12-13 um 07.55 schrieb Joseph:
> Is there any plan to optimize for C3 CPU in future gcc released version?
Certainly, as soon as some reliable (optimisation-) manual shows up.
Whether that will happen before you fixed your mailer is a different
question though.... :)
> --
> Servus,
> Daniel
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: AW: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Alan Cox @ 2002-12-13 11:05 UTC (permalink / raw)
To: Herbert Nachtnebel
Cc: NoZizzing OrDripping, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <B900970C7DD9474C972986EB3EC7C58F0D404A-PWLG29+z7hEKeIAE67mlpo2P0GrZ+RbP@public.gmane.org>
On Fri, 2002-12-13 at 09:30, Herbert Nachtnebel wrote:
> That's a really bad idea! This size checks are identented to assure, that important data which accidently follows the buffer can't be overridden by brain dead bios coders. Now you allow buffer overflow injection into linux from the bios!
> These are serious bios faults, in my DSDT I had to extend a buffer by 128 bytes to avoid a buffer overflow!
> The situation doesn't get better if we ignore such errors. We have to urge the manufacturers to correct the DSDT's. And the best way to do this is to recognise the faults and blame them.
Allocating 1 byte of slack, giving a loud warning about the problem and
erroring if we exceed the 1 byte of slack doesn't sound so bad though?
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [PATCH][2.5][CFT] ad1848 PnP updates + fixes
From: Zwane Mwaikambo @ 2002-12-13 11:15 UTC (permalink / raw)
To: Linux Kernel; +Cc: Adam Belay
In-Reply-To: <Pine.LNX.4.50.0212122048590.6931-100000@montezuma.mastecende.com>
Hi Adam,
I had the following hunk from the previous patch to this file, do
we really want to disable that device here?
On Thu, 12 Dec 2002, Zwane Mwaikambo wrote:
> #ifdef CONFIG_PNP
> - if(ad1848_dev){
> - if(audio_activated)
> - pnp_disable_dev(ad1848_dev);
> - put_device(&ad1848_dev->dev);
> +{
> + ad1848_info *p;
> +
> + if (audio_activated == 0)
> + return;
> +
> + while (--nr_ad1848_devs >= 0) {
> + p = &adev_info[nr_ad1848_devs];
> + pnp_disable_dev(p->pnp_dev); /* XXX Should this be done here? */
> + put_device(&p->pnp_dev->dev);
> }
> + pnp_unregister_driver(&ad1848_driver);
> +}
> #endif
--
function.linuxpower.ca
^ 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.