/eata.o failed
/lib/modules/2.4.2-ac28/kernel/drivers/scsi/eata.o: insmod eata failed
I tried also default settings provided in eata.c, but this does not help.
If anyone had a success with this device, please let me know.
Thanks in advance.
--
Sincerely Yours,
Denis Perchine
tributed Processing Technology SmartRAID V Controller (rev
> > 2).
>
> This card isnt supported by the eata driver.
Is there any other way to make it working under 2.4.x? Only working drivers
are up to 2.2.16. I tried to compile them for 2.2.17 from RH 6.2 updates, but
they hang u
ivers for the card. I've asked them to make
> a few more changes for me but their change making cycle seems very slow and
> I'm waiting for the next round.
Is it possible to get this beta somewhere? I'd like to try it.
--
Sincerely Yours,
Denis Perchine
any plans to implement this correctly? And due to what problems it
was not implemented yet?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
-
To
On Sunday 18 February 2001 18:22, Denis Perchine wrote:
> Hello,
>
> as fas as I can see from fdatasync man page, and from the latest kernel
> sources (2.4.1ac3, fs/buffer.c), they are equivalent.
>
> Using of fdatasync in database can gain significant gain on systems which
&g
idea, but it is assumed that this program
is the only one running on the machine.
I do not want to use proc as some people can just do not mount it.
Any comments, suggestions?
Thanks in advance.
Denis Perchine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Linux
Date: Sun, 10 Dec 2000 12:51:46 +0600
From: Denis Perchine <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hello,
I have quite strange problem. It's lsof -i -n -P
postmaste 20018 postgres6u IPv4 12241380 TCP
127.0.0.1:5432->127.0.0.1:6651 (CLOSE)
And there is
h mod_perl. Actually this
connection should be closed, if there was a failure, but somehow it is not.
And possibly it is a fd in DBD::Pg code (or libpq code). I will think how to
check this...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage:
Hello,
one small question... Will O_DSYNC flag be available in Linux?
It is available at least on AIX, and HP-UX. The difference with O_SYNC is the
same as between fsync and fdatasync.
Any comments?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL
d 1.5Gb of swap... It looks like
it is again a problem with kernel does not use all possibilities before kill
a process.
And what worries me is that I found mentioned above lines in kernel log.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
time update turned off in its case. MS do this.
> http://www.spec.org/osg/web99/results/res2000q4/web99-20001127-00075.html
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
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-m
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 ha
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
<[EMAIL PROTECTED]>
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
fs/proc/base.c | 57
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7411bfb..ca0cbc2 100644
--- a/fs
101 - 200 of 1264 matches
Mail list logo
