On Sunday 03 April 2005 01:38, Jesper Juhl wrote:
> On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
>
> > Hi,
> >
> > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
> > I found one:
> >
> > # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" *
> > net/ieee80211/ieee80211_tx.c:226:
[disregard my previous mail. I should have read the whole thread first]
On Saturday 02 April 2005 07:50, Robert Hancock wrote:
> As it turns out, the memset in my version of glibc x86_64 is not using
> such a string instruction though - it seems to be using two different
> sets of instructions d
On Tuesday 05 April 2005 19:34, Christophe Saout wrote:
> Hi Denis,
>
> the new i386 memcpy macro is a ticking timebomb.
>
> I've been debugging a new mISDN crash, just to find out that a memcpy
> was not inlined correctly.
>
> Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed)
On Tuesday 05 April 2005 21:00, Jörn Engel wrote:
> On Tue, 5 April 2005 17:26:31 +0100, Paulo Marques wrote:
> >
> > Would this be a good thing to clean up, or isn't it worth the effort at all?
>
> I would welcome such a stream of patches. But in spite of the calloc
> interface being rather stu
On Wednesday 06 April 2005 16:18, Richard B. Johnson wrote:
>
> Attached is inline ix86 memcpy() plus test code that tests its
> corner-cases. The in-line code makes no jumps, but uses longword
> copies, word copies and any spare byte copy. It works at all
> offsets, doesn't require alignment but
On Tuesday 05 April 2005 19:34, Christophe Saout wrote:
> the new i386 memcpy macro is a ticking timebomb.
>
> I've been debugging a new mISDN crash, just to find out that a memcpy
> was not inlined correctly.
>
> Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
Updated patc
On Monday 11 July 2005 18:34, Sander wrote:
> Michael S. Tsirkin wrote (ao):
> > Use tabs, not spaces, for indentation. Tabs should be 8
> > characters wide.
>
> A tab is a tab. The editor/viewer can be configured to show 2, 3, 4, 8,
> any amount of characters, right?
text with 8-char tab
> 3c. * in types
> Leave space between name and * in types.
> Multiple * dont need additional space between them.
>
> struct foo **bar;
unless you declare a fuction:
int*
function_style_for_easy_grep(...)
{
...
}
I like this style because I can grep for ^function_style
On Monday 11 July 2005 19:36, Martin Schwidefsky wrote:
> [patch 7/12] s390: fba dasd i/o errors.
>
> From: Horst Hummel <[EMAIL PROTECTED]>
>
> The FBA discipline does not use retries for failed requests. A request
> fails after the first unsuccessful start attempt. There are some rare
> conditi
On Tuesday 12 July 2005 13:36, Martin Schwidefsky wrote:
> > > @@ -354,6 +354,8 @@ dasd_fba_build_cp(struct dasd_device * d
> > > }
> > > cqr->device = device;
> > > cqr->expires = 5 * 60 * HZ; /* 5 minutes */
> > > +cqr->retries = 32;
> >
> > 2..4 maybe,
On Tuesday 12 July 2005 22:36, Bodo Eggert wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
>
> > text with 8-char tabs:
> >
> > struct s {
> > int n; /* comment */
> > unsigned int u; /* comment */
> > };
> &g
Hi folks,
I reported earlied that around linux-2.6.11-rc5 my home box sometimes
does not want to send anything over ethetnet. That report is repeated below
sig.
I finally managed to nail down where this happens.
I instrumented sch_generic.c to trace what happens with packets
to be sent over inter
On Tuesday 19 July 2005 19:58, Etienne Lorrain wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.
>
> What I would like is to treat completely differently writing to
> FAT (writing to a removeable drive) which need a complet
On Wednesday 20 July 2005 12:25, Ivan Yosifov wrote:
> > > > Also, I believe that the -march=pentium4 option /was/ actually used up
> > > > until kernel 2.6.10 where it was dropped because of a risk that some
> > > > versions of gcc would cause the kernel to use SSE registers for data
> > > > movem
On Wednesday 20 July 2005 15:16, Bastiaan Naber wrote:
> Hi,
>
> I am not sure if I can ask this here but I could not find any other place
> where I could fine anyone with this knowledge.
>
> I have a 15 GB file which I want to place in memory via tmpfs. I want to do
> this because I need to ha
On Friday 22 July 2005 09:25, Ralf Hildebrandt wrote:
> * Ralf Hildebrandt <[EMAIL PROTECTED]>:
>
> > The one message strinking me as odd during the boot-process is:
> > Jul 21 19:50:01 kasbah kernel: AC'97 warm reset still in progress?
> > [0x]
>
> More details: If I unload the sounddri
On Saturday 23 July 2005 00:43, John Pearson wrote:
> Wouldn't having (practically) all your memory used for cache slow down
> starting a new program? First it would have to free up that space, and then
> put stuff in that space, taking potentially twice as long. I think there
> should be a system
[resend. Did not reach mailing lists, most probably due
to KMail's unstoppable desire to use base64 encoding :)]
Hi folks,
I reported earlied that around linux-2.6.11-rc5 my home box sometimes
does not want to send anything over ethetnet. That report is repeated below
sig.
I finally managed to n
On Monday 25 July 2005 08:28, David S. Miller wrote:
>
> Probably your link is never coming up. We won't send packets
> over the wire unless the device is in the link-up state.
>
> However, if ->dequeue() is returning NULL, there really aren't
> any packets in the device queue to be sent.
>
> If y
On Thursday 04 August 2005 23:45, Tommy Christensen wrote:
> Denis Vlasenko wrote:
> > Hi,
> >
> > As reported earlier, sometimes my home box don't want
> > to send anything.
> >
> > # ip r
> > 1.1.5.5 dev tun0 proto kernel scope link src
On Saturday 06 August 2005 18:57, Jeff Garzik wrote:
> On Sat, Aug 06, 2005 at 09:50:13AM +0100, Matthew Wilcox wrote:
> > On Fri, Aug 05, 2005 at 11:34:55PM -0400, Jeff Garzik wrote:
> > > FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> > > really tough to do optimally, whereas
On Monday 01 August 2005 01:36, David S. Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Mon, 1 Aug 2005 00:26:07 +0200
>
> > - my impression is that the older compilers are only rarely
> > used, so miscompilations of a driver with an old gcc might
> > not be detected for a longe
On Sunday 07 August 2005 22:15, Russell King wrote:
> On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote:
> > I'm getting lots of errors like this nowadays:
> >
> > drivers/serial/8250.c:2651: warning: `register_serial' is deprecated
> > (declared at drivers/serial/8250.c:2607)
> >
On Monday 08 August 2005 03:39, Alejandro Bonilla Beeche wrote:
> On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote:
> > Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS)
> > supported?
>
> Normally, linksys doesn't care much about Linux and they won't even
> release info for a driv
On Tuesday 09 August 2005 12:33, Thomas Habets wrote:
> -
> typedef struct me_s {
> char name[] = { "Thomas Habets" };
> char email[] = { "[EMAIL PROTECTED]" };
> char kernel[]= { "Linux" };
> char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
> char pgp[]
On Sunday 07 August 2005 21:02, Udo van den Heuvel wrote:
> Hello,
>
> In january of this year I mentioned a problem with the Linux kernel
> driver for VIA Rhine ethernet chips. (see http://lkml.org/lkml/2005/1/15/47)
> In the mean time this bug was reproduced quite a number of times on my
> Fedor
Sample of my kernel's mostly useless symbols
(starting_with:# of symbols):
__func__: 624
__vendorstr_: 1760
__pci_fixup_PCI_: 116
__ksymtab_: 2597
__kstrtab_: 2597
__kcrctab_: 2597
__initcall_: 236
__devicestr_: 4686
__devices_: 1760
Total: 16973
Lines in System.map: 39735
Excluding them from in-
On Thursday 11 August 2005 14:16, Paulo Marques wrote:
> Denis Vlasenko wrote:
> > Sample of my kernel's mostly useless symbols
> > (starting_with:# of symbols):
> >
> > __func__: 624
> > __vendorstr_: 1760
> > __pci_fixup_PCI_: 116
> > __ksymta
I think I finally know what's going on.
Again, the recipe:
* have via-rhine NIC
* unplug network cable
* reboot box
* force HDX (I do in with ethtool -s if autoneg off duplex half)
* plug cable back
* kernel still thinks that carrier is off despite "ethtool if"
saying that link is detected.
Why
These functions are not called frequently, let's save some space.
# grep -r 'netif_carrier_o[nf]' linux-2.6.12 | wc -l
246
# size vmlinux.org vmlinux.carrier
textdata bss dec hex filename
4339634 1054414 259296 5653344 564360 vmlinux.org
4337710 1054414 259296 5651420 563bdc v
On Monday 15 August 2005 08:52, Florian Hars wrote:
> I have an NForce4 board with an Athlon 64 and use the 2.6.8 kernel from
> the inofficial debian AMD64 port, and everything works, except that the
> proprietary nvidia driver for my geforce card complains about "Your
> Linux kernel has problems
> > It was explained to me that the !pointer test wasn't guaranteed to be
> > equivalent because of the way that the test is handled.
>
> Whoever explained that to you was wrong. 6.5.3.3 is the final word on
> how "!x" is interpreted, and it *says* in the *text* that
> "!x" === "x!=0". I don't s
On Tuesday 09 August 2005 01:38, Adrian Bunk wrote:
> kcalloc() doesn't do much more than calling kzalloc(), and gcc has
> better optimizing opportunities when it's inlined.
>
> The result of this patch with a fulll kernel compile (roughly equivalent
> to "make allyesconfig") shows a minimal siz
On Monday 15 August 2005 11:14, Arjan van de Ven wrote:
> On Mon, 2005-08-15 at 11:06 +0300, Denis Vlasenko wrote:
>
> > > +static inline void *kcalloc(size_t n, size_t size, unsigned int __nocast
> > > flags)
> > > +{
> > > + if (n != 0 &&am
> > static inline void *kcalloc(size_t n, size_t size, unsigned int __nocast
> > flags)
> > {
> > if (__builtin_constant_p(n)) {
> > if (n != 0 && size > INT_MAX / n)
> > return NULL;
> > return kzalloc(n * size, flags);
> > }
> > return kcal
On Monday 15 August 2005 12:41, Arjan van de Ven wrote:
> On Mon, 2005-08-15 at 12:33 +0300, Denis Vlasenko wrote:
>
> > gcc can optimize that away with non-const n?! I don't think so.
>
> due to the wonders of "value range propagation" it actually can, if the
&g
On Sunday 17 April 2005 22:04, Andreas Hartmann wrote:
> Willy Tarreau schrieb:
> > Well, if the application does not touch most of the data, either it
> > is playing as a relay, and the data will at least have to be copied,
> > or it will play as a client or server which reads from/writes to disk,
On Monday 18 April 2005 12:01, Andreas Steinmetz wrote:
> Denis Vlasenko wrote:
> > On Sunday 17 April 2005 22:20, Andreas Steinmetz wrote:
> >
> >>The attached patch contains Gladman's in-kernel code for key schedule
> >>and table generation modified
On Monday 18 April 2005 13:56, Ehud Shabtai wrote:
> On 4/18/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > On Mon, 18 Apr 2005, Jesper Juhl wrote:
> >
> > > On Mon, 18 Apr 2005, Alexander Nyberg wrote:
> > >
> > > > Sounds like a job for Documentation/networking/netconsole.txt
> > > >
> > > or Do
modprobe tcrypt hangs the box on both kernels.
The last printks are:
testing wp384
NNUnable to handle kernel paging request at virtual address eXXX
Nothing is printed after this and system locks up solid.
No Sysrq-B.
IIRC, 2.6.9 was okay.
Just a heads-up.
--
vda
-
To unsubscribe from thi
This is done because on 32bit arch gcc generates suboptimal code
from C implementation:
old:
40: 83 ea 80sub$0xff80,%edx
43: 89 95 50 ff ff ff mov%edx,0xff50(%ebp)
49: 8b bd 50 ff ff ff mov0xff50(%ebp),%edi
This + next patch were "modprobe tcrypt" tested.
See next mail.
--
vda
diff -urpN 2.6.12-rc2.0.orig/crypto/sha512.c 2.6.12-rc2.1.be/crypto/sha512.c
--- 2.6.12-rc2.0.orig/crypto/sha512.c Tue Apr 19 00:20:12 2005
+++ 2.6.12-rc2.1.be/crypto/sha512.c Mon Apr 18 23:31:54 2005
@@ -105,7 +105,7 @@ static
this results in following code size changes on i386:
# size sha512_org.o sha512_be.o sha512_ror.o
textdata bss dec hex filename
5339 364 057031647 sha512_org.o
5221 364 0558515d1 sha512_be.o
5122 364 05486156e sha512
While we're at it, fix inconsistent tab/space usage.
No code changes.
--
vda
diff -urpN 2.6.12-rc2.2.ror/crypto/sha512.c 2.6.12-rc2.3.ws/crypto/sha512.c
--- 2.6.12-rc2.2.ror/crypto/sha512.c Mon Apr 18 23:37:20 2005
+++ 2.6.12-rc2.3.ws/crypto/sha512.c Mon Apr 18 23:48:18 2005
@@ -35,42 +35,42 @@ st
Remove local 64bit rotation function, use generic one.
Patch is untested.
I believe there is no more 64bit rotations in the kernel.
--
vda
diff -urpN 2.6.12-rc2.3.ws/arch/ia64/kernel/ptrace.c 2.6.12-rc2.4.ia64/arch/ia64/kernel/ptrace.c
--- 2.6.12-rc2.3.ws/arch/ia64/kernel/ptrace.c Mon Apr 18 22:5
On Tuesday 19 April 2005 09:46, YOSHIFUJI Hideaki wrote:
> Please keep using __inline__, not inline.
Updated patch follows.
--
vda
diff -urpN 2.6.12-rc2.1.be/include/asm-i386/bitops.h 2.6.12-rc2.2.ror/include/asm-i386/bitops.h
--- 2.6.12-rc2.1.be/include/asm-i386/bitops.h Tue Oct 19 00:54:36 2004
On Tuesday 19 April 2005 08:42, Denis Vlasenko wrote:
> modprobe tcrypt hangs the box on both kernels.
> The last printks are:
>
>
>
> testing wp384
> NNUnable to handle kernel paging request at virtual address eXXX
>
> Nothing is printed after this and system l
On Tuesday 19 April 2005 12:04, Jesper Juhl wrote:
> On Tue, 19 Apr 2005, Denis Vlasenko wrote:
>
> > This + next patch were "modprobe tcrypt" tested.
> > See next mail.
>
> Could you please send patches inline instead of as attachments.
> Attachments mean
On Tuesday 19 April 2005 17:41, Jesper Juhl wrote:
> On Tue, 19 Apr 2005, Denis Vlasenko wrote:
>
> > On Tuesday 19 April 2005 12:04, Jesper Juhl wrote:
> > > On Tue, 19 Apr 2005, Denis Vlasenko wrote:
> > >
> > > > This + next patch were "
[resending to lkml for wider audience]
> > > modprobe tcrypt hangs the box on both kernels.
> > > The last printks are:
> > >
> > >
> > >
> > > testing wp384
> > > NNUnable to handle kernel paging request at virtual address eXXX
> > >
> > > Nothing is printed after this and system locks up
On Friday 22 April 2005 01:02, Yum Rayan wrote:
> This patch reduces the stack usage of the function smc91c92_event() in
> smc91c92_cs driver from 3540 to 132. Currently this is the highest
> stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
> 3.4.3 on i386 with -fno-unit-at-a-tim
wp512 uses more than 3k of stack if compiled by gcc 3.4.3 with -O2.
Work around that.
Also use BYTE macros where appropriate.
--
vda
diff -urpN linux-2.6.12-rc2.1.be_le/crypto/wp512.c linux-2.6.12-rc2.2.wp/crypto/wp512.c
--- linux-2.6.12-rc2.1.be_le/crypto/wp512.c Thu Apr 21 23:21:24 2005
+++ linu
Patch replaces numerous be<->cpu and le<->cpu
conversions in crypto. Per lkml comments,
it is done with macros:
block[i] = load_be64(ptr,i);
store_be64(out,i, block[i]);
where i is an index: load_be64 will load i'th
big-endian value pointed by ptr (typically a char*).
Same for store.
This result
This one is for comments only.
These changes were found to bring small size/speed
improvements by use of BYTEn() and other changes.
des.c can be less heavily unrolled, 10k -> 5k in object size.
Any objections to this?
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Currently twofish is the largest crypto module (~38k).
Most of that is a result of unrolling in key setup routine.
Converting some of it to loop brings module size down to 15k while
slowing key setup only by 7%.
Patches 1-3 were tested with tcrypt. Please apply.
--
vda
diff -urpN linux-2.6.12-rc2
On Friday 22 April 2005 12:59, Denis Vlasenko wrote:
> This one is for comments only.
>
> These changes were found to bring small size/speed
> improvements by use of BYTEn() and other changes.
>
> des.c can be less heavily unrolled, 10k -> 5k in object size.
>
> An
> > > > NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
> > > > include gcc version in your reports.
> > >
> > > But this can't occur in the kernel.
> >
> > It can. I saw the OOPS myself.
> > One of the functions in crypto/wp512.c was compiled with 3k+ stack usage.
>
> Stran
On Wednesday 06 July 2005 20:27, Richard B. Johnson wrote:
> Only the 127.0.0.0 network should be routed through the loop-back
> device.
This is the normal dose of disinformation embedded into
otherwise useful reply from Richard. Sometimes I wonder
whether he does this for fun for for some other d
On Thursday 07 July 2005 15:34, Richard B. Johnson wrote:
> >> Only the 127.0.0.0 network should be routed through the loop-back
> >> device.
> >
> > Again: All the IP addresses mentioned are local to this box.
> >
> > If you ping an IP address on your eth0, the traffic will "go"
> > over loopback.
> The problem is, I can't see what is causing this misconfiguration
> or whatever. I wasn't able to capture such a packet so far either --
> it never happened while tcpdump was running.
You may try to add printk("bad boy is: %s\n", current()->comm)),
or dump_stack(), or something like that in icm
On Saturday 09 July 2005 01:08, Linus Torvalds wrote:
>
> On Fri, 8 Jul 2005, Andrew Morton wrote:
> > >
> > > The previous value here i386 is 1000 --- so why is the default 250.
> >
> > Because 1000 is too high.
>
> Yes. I chose 1000 originally partly as a way to make sure that people that
> a
On Friday 08 July 2005 19:57, Roman Zippel wrote:
> Hi,
>
> On Fri, 8 Jul 2005, Bryan Henderson wrote:
>
> > I wasn't aware anyone preferred defines to enums for declaring enumerated
> > data types.
>
> If it's really enumerated data types, that's fine, but this example was
> about bitfield ma
On Tuesday 26 July 2005 13:15, Stefan Seyfried wrote:
> Puneet Vyas wrote:
>
> > ide : failed opcode was : unknown
> > hdc : status error: status 0x00 { }
>
> This is _not_ an USB cd writer but an IDE drive.
> You may not just pull it out.
Interesting how he's connecting floppy to IDE ;]
--
vda
Linux 2.6.12
Was running for months with this simple iptables rule:
iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport
9100 -j REDIRECT --to 9123
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
00 REDIRECT tcp -- * * 172.17.6.44
On Friday 29 July 2005 14:23, Jan Engelhardt wrote:
>
> >iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport
> >9100 -j REDIRECT --to 9123
> >
> >Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> > 00 REDIRECT tcp -- * * 172.17.6.44
On Friday 29 July 2005 22:37, David S. Miller wrote:
> From: Denis Vlasenko <[EMAIL PROTECTED]>
> Date: Fri, 29 Jul 2005 12:11:52 +0300
>
> > Linux 2.6.12
> >
> > Was running for months with this simple iptables rule:
> ...
> > But now I need to bri
On Monday 25 July 2005 08:17, Denis Vlasenko wrote:
> I reported earlied that around linux-2.6.11-rc5 my home box sometimes
> does not want to send anything over ethernet. That report is repeated below
> sig.
>
> I finally managed to nail down where this happens.
> I instrumente
Hi,
I am working on a wireless driver. It seems to deadlock
on flush_scheduled_work while iface is being downed.
I've put debug printks in code:
static void
acx_s_down(netdevice_t *dev)
{
wlandevice_t *priv = acx_netdev_priv(dev);
unsigned long flags;
FN_ENTER;
printk("a
Hi,
As reported earlier, sometimes my home box don't want
to send anything.
# ip r
1.1.5.5 dev tun0 proto kernel scope link src 1.1.5.6
1.1.4.0/24 dev if proto kernel scope link src 1.1.4.6
default via 1.1.5.5 dev tun0
# ping 1.1.4.1 -i 0.01
kernel log:
2005-07-30_21:28:25.15338 kern.info:
On Thursday 04 August 2005 12:38, Rolf Eike Beer wrote:
> Saripalli, Venkata Ramanamurthy (STSD) wrote:
> >Patch 1 of 2
> >
> >This patch fixes the "#error this is too much stack" in 2.6 kernel.
> >Using kmalloc to allocate memory to ulFibreFrame.
>
> Good idea.
>
> >Please consider this for incl
On Sunday 21 August 2005 23:21, Danial Thom wrote:
> > You problem could very well be something else
> > entirely, but try a
> > kernel build with PREEMPT_NONE and HZ=100 and
> > see if it makes a big
> > difference (or if that's your current config,
> > then try the opposite,
> > HZ=1000 and PREEM
On Friday 12 August 2005 01:54, Chris Wright wrote:
> -stable review patch. If anyone has any objections, please let us know.
> --
>
> The module code assumes noone will ever ask for a per-cpu area more than
> SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks somet
[CCing maintaner]
On Monday 22 August 2005 20:29, Udo van den Heuvel wrote:
> Hello,
>
> It appears that the VIA Rhine chipset has some sort of bug which shows
> up in both the standard Linux VIA-Rhine driver and the Rhinefet driver
> that VIA itself provides.
>
> The difference is that the conn
On Tuesday 23 August 2005 14:17, linux-os \(Dick Johnson\) wrote:
>
> On Mon, 22 Aug 2005, Robert Hancock wrote:
>
> > linux-os (Dick Johnson) wrote:
> >> I reported thet sched_yield() wasn't working (at least as expected)
> >> back in March of 2004.
> >>
> >>for(;;)
> >>
On Friday 26 August 2005 06:43, Patrick Draper wrote:
> On 8/23/05, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > >Since it happens less than once a day, why not just add a code
> > >to reset the NIC completely in this case, like it is
> > >typically done in t
Hi folks,
We have ~2k of printf format specs like this:
"%s: Transmit timed out, status %4.4x, PHY status %4.4x, resetting...\n"
IIRC %04x and %4.4x are totally equivalent. %04 is shorter.
Patches are at http://195.66.192.167/linux/printf_patch/
Largest ones are:
# ls -l | sort -r
total 1012
On Friday 26 August 2005 10:49, Jeff Garzik wrote:
> Denis Vlasenko wrote:
> > May be a known problem. A buglet in MII common code.
> > Via-rhine maintainer knows about it, as does Jeff.
>
> You don't speak for me, sir.
>
> I know of no such problem. Please sub
> > > > Currently snsc_event for Altix systems sends SIGPWR to init (and
> > > > abuses tasklist_lock..) while the sbus drivers call execve for
> > > > /sbin/shutdown (which is also ugly, it should at least use
> > > > call_usermodehelper) With normal sysvinit both will end up the same,
> > > > but
On Wednesday 31 August 2005 11:16, Mateusz Berezecki wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> -> The FTC issues are shared by many (most?) wireless drivers. The
> -> copyright/trade secret issues might be worked around by basing the
> -> work on the OpenBSD version of that driver (and
Not tested, but it's rather obvious.
--
vda
--- linux-2.6.12.src/drivers/i2c/chips/via686a.c.orig Sun Jun 19 16:10:10 2005
+++ linux-2.6.12.src/drivers/i2c/chips/via686a.c Tue Aug 30 00:21:39 2005
@@ -205,7 +205,7 @@ static inline u8 FAN_TO_REG(long rpm, in
but the function is very linear in the
Hi,
http://195.66.192.167/linux/trailing_spaces_patch/
There are 290 patches like this:
- printk ("scsi%d : not initializing, no I/O or memory mapping known \n",
+ printk ("scsi%d : not initializing, no I/O or memory mapping known\n",
Largest ones are:
# ls -l | sort -r
total 1256
On Thursday 01 September 2005 18:59, Greg KH wrote:
> On Thu, Sep 01, 2005 at 09:10:14AM +0300, Denis Vlasenko wrote:
> > Not tested, but it's rather obvious.
>
> Except you forgot a "Signed-off-by:" line...
>
> > --- linux-2.6.12.src/drivers/i2c/chips/via
On Saturday 03 September 2005 11:26, Jean Delvare wrote:
> Hi Denis,
>
> BTW...
>
> > Please be informed that there are lots of intNN_t's in i2c dir
> > tho...
>
> I couldn't find any. What were you refering to exactly?
Sorry I was wrong. While kernel has ~15000 [u]intNN_t's
they are all _not_
On Friday 02 September 2005 23:56, Dave Hansen wrote:
>
> A little helper that we use in the hotplug code.
>
> Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
> ---
>
> memhotplug-dave/include/linux/mmzone.h | 25 +
> 1 files changed, 25 insertions(+)
>
> diff -puN inc
On Saturday 03 September 2005 08:55, Kyle Moffett wrote:
> On Sep 3, 2005, at 00:28:59, Erik Andersen wrote:
> >> Absolutely not. This would be a POSIX namespace violation; they
> >> *must* use double-underscore types.
> >
> > I assume you are worried about the stuff under asm that ends up
> > bei
On Saturday 03 September 2005 19:33, Kyle Moffett wrote:
> On Sep 3, 2005, at 11:36:22, Denis Vlasenko wrote:
> > Is this an exercise in academia? Userspace app which defines
> > uint32_t to anything different than 'typedef '
> > deserves the punishment, and o
On Friday 02 September 2005 09:08, Alex Davis wrote:
> ndiswrapper and driverloader will not work reliably with 4k stacks.
> This is because of the Windoze drivers they use, to which, obviously,
> they do not have the source. Since quite a few laptops have built-in
> wireless cards by companies who
On Tuesday 06 September 2005 07:37, Andi Kleen wrote:
> Running with tight stack is just a fundamentally fragile configuration
> and will come back to bite you later. Even with 8k we regularly
> had overflows reported and with 4k it will be much worse.
I think one of the reasons is:
"No matter ho
On Sunday 13 March 2005 15:24, Alexander Gran wrote:
> Hi,
>
> Well, of course it cannot handle that large files (I wouldn't expect that,
> either). My Problem is that when I open the file, it's not just kwrite but
> other processes that need so much cpu time. That kwrite is eating cpu is ok.
This memcpy() is 2 bytes shorter than one currently in mainline
and it have one branch less. It is also 3-4% faster in microbenchmarks
on small blocks if block size is multiple of 4. Mainline is slower
because it has to branch twice per memcpy, both mispredicted
(but branch prediction hides that in
On Thursday 17 March 2005 03:33, Christoph Lameter wrote:
> On Fri, 11 Mar 2005, Denis Vlasenko wrote:
>
> > Andi Kleen (iirc) says that non-temporal stores seem to be
> > big win in microbenchmarks (and I second that), but they are
> > a net loss when we are going to us
On Friday 18 March 2005 11:21, Denis Vlasenko wrote:
> This memcpy() is 2 bytes shorter than one currently in mainline
> and it have one branch less. It is also 3-4% faster in microbenchmarks
> on small blocks if block size is multiple of 4. Mainline is slower
> because it has to bran
On Friday 18 March 2005 21:28, Andi Kleen wrote:
> On Fri, Mar 18, 2005 at 07:00:06AM -0800, Christoph Lameter wrote:
> > On Fri, 18 Mar 2005, Denis Vlasenko wrote:
> >
> > > NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> > > the fact
On Sunday 20 March 2005 15:17, Adrian Bunk wrote:
> Hi Denis,
>
> what do your benchmarks say about replacing the whole assembler code
> with a
>
> #define __memcpy __builtin_memcpy
It generates call to out-of-line memcpy()
if count is non-constant.
# cat t.c
extern char *a, *b;
extern int n
Patch kills spurious empty line in the kernel log
ans also glues together some back-to-back printks.
--
vda
--- linux-2.6.11.src/drivers/ide/ide-lib.c.orig Thu Mar 3 09:30:33 2005
+++ linux-2.6.11.src/drivers/ide/ide-lib.c Tue Mar 22 12:37:39 2005
@@ -487,8 +487,7 @@ static u8 ide_dump_ata_status(
dd if=/dev/hdc of=/dev/null with this disk
kills the system. Drive may do it's work
for minute or two, but then it does 'klak' sound.
With udma5 (default) Linux froze solid, no SysRq key, nothing.
Powercycling helps.
With udma3, it did not die, but still spews IDE errors.
I will try to collect mor
On Wednesday 23 March 2005 00:55, Jesper Juhl wrote:
>
> Remove a redundant NULL pointer check prior to kfree(). kfree() has no
> problem with NULL pointers.
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>
> --- linux-2.6.12-rc1-mm1-orig/fs/devfs/base.c 2005-03-02 08:37:49.0
>
On Tuesday 22 March 2005 16:21, Bodo Eggert wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
>
> > dd if=/dev/hdc of=/dev/null with this disk
> > kills the system. Drive may do it's work
> > for minute or two, but then it does 'klak' sound.
>
>
On Wednesday 23 March 2005 12:38, Andrew Morton wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> >
> > dd if=/dev/hdc of=/dev/null with this disk
> > kills the system. Drive may do it's work
> > for minute or two, but then it does 'klak' sound.
On Tuesday 22 March 2005 04:44, Dave Jones wrote:
> You wouldn't believe how many instances of this bug I've
> seen in the last few days in both userspace and kernelspace.
>
> - memset(&target_route->rcu, sizeof(struct rcu_head), 0);
> + memset(&target_route->rcu, 0, sizeof
1 - 100 of 183 matches
Mail list logo
