On 8/9/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > You keep claiming that hrtimers are so incredibly expensive; but for
> > msleep()... which is mostly called during driver init ... I really don't
&g
On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> You keep claiming that hrtimers are so incredibly expensive; but for
> msleep()... which is mostly called during driver init ... I really don't
> buy that it's really expensive. We're not doing this a gazilion times
> per second obviously...
On 8/2/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > > Please, copy strtonum() from BSD instead. Nobody needs another
> > > home-grown converter.
> >
> > BSD's strtonum(3) is a detestful, horrible shame.
> >
> > The strtol_check_range() I implemented here does _all_ that strtonum()
> > does, p
Hi,
Attached patch deinlines and moves big functions from .h to .c files
in drivers/scsi/aic7xxx/*. I also had to add prototypes for ahc_lookup_scb
and ahd_lookup_scb to .h files.
No other code changes made.
Compile-tested on i386 and x86-64.
Total .text size reduction: ~60k in 64 bits, ~90k in
On Wednesday 18 July 2007 22:04, Andi Kleen wrote:
> Better just write less bloated code. Perhaps mandatory bloatometer
> runs during -rc*s for kernels with minimal config with public code pig shame
> lists
> similar to the regression lists are useful. Anyone volunteering?
>
> I suspect there is a
Hi Satyam,
On Monday 23 July 2007 17:05, Satyam Sharma wrote:
> There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
> that was unnecessary and not required for the correctness of those APIs.
> All that superfluous stuff was also unnecessarily disallowing compiler
> optimizatio
On Thursday 21 June 2007 21:32, Mathieu Desnoyers wrote:
> Let's take arch/i386/boot/video.h as an example:
>
> it defines
>
> struct card_info {
> const char *card_name;
> int (*set_mode)(struct mode_info *mode);
> int (*probe)(void);
> struct mode_info *modes;
>
On Sunday 22 July 2007 00:16, Oleg Verych wrote:
> * From: Andi Kleen <[EMAIL PROTECTED]>
> * Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
> >
> > Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> > it should generate better code than the old macro. Let's try it.
>
> Unfortu
On Tuesday 17 July 2007 00:42, Bodo Eggert wrote:
> > Please note that I was not trying to remove the 8K stack option right
> > now - heck, I didn't even add anything to feature-removal-schedule.txt
> > - all I wanted to accomplish with the patch that started this threas
> > was; a) indicate that
On Thursday 05 July 2007 21:34, Andrew Morton wrote:
> On Thu, 5 Jul 2007 12:51:52 +0200
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
>
> > Using code from
> >
> > http://www.cs.uiowa.edu/~jones/bcd/decimal.html
> > (with permission from the author, Douglas
On Friday 06 July 2007 08:35, Jesper Juhl wrote:
> On 06/07/07, Kaleem Khan <[EMAIL PROTECTED]> wrote:
> > Hello Kernel experts,
> >
> > I'd like to know whether there's a way to take some action (say
> > calling a routine) in
> > response to 'kill -9' before the process is terminated. I tend to
>
On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > Removes conditional branch from schedule(). Code savings on my
> >usual config:
> >
> >textdata bss dec hex filename
> > 2921871 179895 180224 3281990 321446 vmlinux before
> > 2920141
On Monday 11 June 2007 02:56, Paul Mundt wrote:
> On Mon, Jun 11, 2007 at 01:59:00AM +0200, Denis Vlasenko wrote:
> > On Sunday 10 June 2007 20:58, Rene Herman wrote:
> > > All that stuff only serves to multiply the speed at which a fixed
> > > percentage of content
On Sunday 10 June 2007 20:58, Rene Herman wrote:
> All that stuff only serves to multiply the speed at which a fixed percentage
> of content obsoletes itself. When it's still new and shiny, sure, stuff will
> get translated but in no time at all it'll become a fragmented mess which
> nobody ever
On Thursday 24 May 2007 21:56, Uwe Bugla wrote:
> Please note:
>
> 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
>
> Questions:
>
> 1. What is the technical need / progress of module ssb please?
>
> 2. If Andrew Morton's guidelines clearly say: "Do test your patc
Theodore Tso wrote:
>
> One of the big problems of using a filesystem as a DB is the system
> call overheads. If you use huge numbers of tiny files, then each
> attempt read an atom of information from the DB takes three system
> calls --- an open(), read(), and close(), with all of the overheads
Hi Tom.
On Thursday 19 April 2007 21:00, Tom Strader wrote:
> This is the final output from my kernel as I try to launch busybox
> (/sbin/init is linked to /bin/busybox)
> As it launches the kernel looks for libraries which do not exist (not
> sure why), but it appears to find /lib/libcrypt.so.1 a
On Saturday 21 April 2007 18:00, Ingo Molnar wrote:
> correct. Note that Willy reniced X back to 0 so it had no relevance on
> his test. Also note that i pointed this change out in the -v4 CFS
> announcement:
>
> || Changes since -v3:
> ||
> || - usability fix: automatic renicing of kernel thre
Hi kernel people,
Just upgraded by home box to 2.6.20.7. Wow.
* Reiser3 mount times are drastically reduced,
even when journal replay is needed
(I have few 100Gb+ reiser3 partitions mounted at boot)
* sit pseudo-interface is gone. In previous kernel, I tried
to disable it in kernel config t
On Thursday 08 March 2007 18:28, Linus Torvalds wrote:
> The sad part is that there really is no reason why the BSD crowd couldn't
> have done recvmsg() as an "extended read with per-system call flags",
> which would have made things like O_NONBLOCK etc unnecessary, because you
> could do it jus
Hi,
On Sunday 18 March 2007 22:06, Robert P. J. Day wrote:
> p.s. just FYI, i ran my "find dead CONFIG variables" script on the
> entire tree and, as we speak, there are 316 preprocessor tests that
> are testing variables of the form "CONFIG_whatever" for which that
> option is not set anywhere i
On Saturday 10 March 2007 13:16, Mockern wrote:
> I have a problem with cat < /dev/my_ttyS0 (see strace output below).
> cat function is not blocked. I don't understand why it is not stopped
> at read(0, __ and terminated?
> Thank you
Because /dev/my_ttyS0 is probaly a null file.
Please show
On Sunday 04 February 2007 01:55, David Schwartz wrote:
>
> > That's a bug, right? I couldn't find anything to that effect in IEEE
> > Std. 1003.1, 2004 Edition...
> >
> > Ciao,
> > Roland
>
> It's not a bug, there's no rational alternative. What would two indepedent
> file d
On Tuesday 30 January 2007 04:40, Philippe Troin wrote:
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
> > return 0;
> > }
> >
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) & ~O_NONBLOCK);
> > return 0;
> > }
> >
> > If I r
On Monday 29 January 2007 18:00, Andrea Arcangeli wrote:
> On Sun, Jan 28, 2007 at 06:03:08PM +0100, Denis Vlasenko wrote:
> > I still don't see much difference between O_SYNC and O_DIRECT write
> > semantic.
>
> O_DIRECT is about avoiding the copy_user between cache an
On Sunday 28 January 2007 16:30, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
> >> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> >>> On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >>&g
On Sunday 28 January 2007 16:18, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >> Denis Vlasenko wrote:
> >>> On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >>>> Phillip Susi wrot
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include
#include
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
#include
#inc
On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >> Denis Vlasenko wrote:
> >> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
>
>
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >> Phillip Susi wrote:
> >>> Denis Vlasenko wrote:
> >>>> You mean "You can use aio_write" ?
>
On Friday 26 January 2007 18:05, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > Which shouldn't be true. There is no fundamental reason why
> > ordinary writes should be slower than O_DIRECT.
>
> Again, there IS a reason: O_DIRECT eliminates the cpu overhead of the
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> Phillip Susi wrote:
> > Denis Vlasenko wrote:
> >> You mean "You can use aio_write" ?
> >
> > Exactly. You generally don't use O_DIRECT without aio. Combining the
> > two is w
On Thursday 25 January 2007 20:28, Phillip Susi wrote:
> > Ahhh shit, are you saying that fdatasync will wait until writes
> > *by all other processes* to thios file will hit the disk?
> > Is that thue?
>
> I think all processes yes, but certainly all writes to this file by this
> process. That
On Thursday 25 January 2007 16:44, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > I will still disagree on this point (on point "use O_DIRECT, it's faster").
> > There is no reason why O_DIRECT should be faster than "normal" read/write
> > to l
On Monday 22 January 2007 17:17, Phillip Susi wrote:
> > You do not need to know which read() exactly failed due to bad disk.
> > Filename and offset from the start is enough. Right?
> >
> > So, SIGIO/SIGBUS can provide that, and if your handler is of
> > void (*sa_sigaction)(int, siginfo_t *,
On Sunday 21 January 2007 13:09, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> >> Denis Vlasenko wrote:
> >>> On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >>>> example,
On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >> example, which isn't quite possible now from userspace. But as long as
> >> O_DIRECT actually writes data before re
On Sunday 14 January 2007 10:11, Nate Diller wrote:
> On 1/12/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Most applications don't get the kind of performance analysis that
> Digeo was doing, and even then, it's rather lucky that we caught that.
> So I personally think it'd be best for libc or s
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> example, which isn't quite possible now from userspace. But as long as
> O_DIRECT actually writes data before returning from write() call (as it
> seems to be the case at least with a normal filesystem on a real block
> device - I don't t
On Thursday 11 January 2007 16:50, Linus Torvalds wrote:
>
> On Thu, 11 Jan 2007, Nick Piggin wrote:
> >
> > Speaking of which, why did we obsolete raw devices? And/or why not just
> > go with a minimal O_DIRECT on block device support? Not a rhetorical
> > question -- I wasn't involved in the di
On Wednesday 03 January 2007 21:26, Frank van Maarseveen wrote:
> On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
> > 64-bit inode numbers space is not yet implemented on Linux --- the problem
> > is that if you return ino >= 2^32, programs compiled without
> > -D_FILE_OFFSET_BIT
On Wednesday 03 January 2007 13:42, Pavel Machek wrote:
> I guess that is the way to go. samefile(path1, path2) is unfortunately
> inherently racy.
Not a problem in practice. You don't expect cp -a
to reliably copy a tree which something else is modifying
at the same time.
Thus we assume that the
On Thursday 28 December 2006 10:06, Benny Halevy wrote:
> Mikulas Patocka wrote:
> >>> If user (or script) doesn't specify that flag, it doesn't help. I think
> >>> the best solution for these filesystems would be either to add new syscall
> >>> int is_hardlink(char *filename1, char *filename2)
>
On Thursday 11 January 2007 02:02, Neil Brown wrote:
> If regs->rax is unsigned long, then I would think the compiler would
> be allowed to convert
>
>switch (regs->rax) {
> case -514 : whatever;
>}
>
> to a no-op, as regs->rax will never have a negative value.
In C, you never actu
On Thursday 04 January 2007 18:37, Linus Torvalds wrote:
> With 7+ million lines of C code and headers, I'm not interested in
> compilers that read the letter of the law. We don't want some really
> clever code generation that gets us .5% on some unrealistic load. We want
> good _solid_ code gen
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > But O_DIRECT is _not_ about cache. At least I think it was not about
> > cache initially, it was more about DMAing data directly from/to
> > application address space to/from disks, savin
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
> Hugh Dickins wrote:
> In many cases the use of O_DIRECT is purely to avoid impact on cache
> used by other applications. An application which writes a large quantity
> of data will have less impact on other applications by using O_DIRECT,
On Wednesday 03 January 2007 21:38, Linus Torvalds wrote:
> On Wed, 3 Jan 2007, Denis Vlasenko wrote:
> >
> > Why CPU people do not internally convert cmov into jmp,mov pair?
>
...
> It really all boils down to: there's simply no real reason to use cmov.
> It'
On Wednesday 03 January 2007 17:03, Linus Torvalds wrote:
> On Wed, 3 Jan 2007, Grzegorz Kulewski wrote:
> > Could you explain why CMOV is pointless now? Are there any benchmarks
> > proving
> > that?
>
> CMOV (and, more generically, any "predicated instruction") tends to
> generally a bad idea
On Saturday 30 December 2006 23:08, Robert P. J. Day wrote:
> >
> > clear_page assumes that given address is page aligned, I think. It
> > may fail if you feed it with misaligned region's address.
>
> i don't see how that can be true, given that most of the definitions
> of the clear_page() macro
On Tuesday 26 December 2006 16:18, Tejun Heo wrote:
> Hello, all.
>
> This patchset implements managed device resources, in short, devres.
I was working on a Linux device driver. Indeed, those error paths
are notoriously prone to bugs.
Patchset looks like good idea to me.
--
vda
-
To unsubscribe
On Friday 29 December 2006 07:16, Robert P. J. Day wrote:
>
> is there some reason there are so many calls of the form
>
> memset(addr, 0, PAGE_SIZE)
>
> rather than the apparently equivalent invocation of
>
> clear_page(addr)
>
> the majority of architectures appear to define the clear_
On Wednesday 27 December 2006 22:03, Rob Landley wrote:
> On Wednesday 27 December 2006 1:35 pm, Denis Vlasenko wrote:
> > This solves chroot problem. How to find path-to-yourself reliably
> > (for one, without using /proc/self/exe) is not obvious to me.
>
> Been there, done
On Wednesday 27 December 2006 06:13, Ray Lee wrote:
> On 12/26/06, Rob Landley <[EMAIL PROTECTED]> wrote:
> > I'm trying to make some nommu-friendly busybox-like tools, which means using
> > vfork() instead of fork(). This means that after I fork I have to exec in
> > the child to unblock the pare
On Wednesday 27 December 2006 00:55, David Lang wrote:
> On Tue, 26 Dec 2006, Rob Landley wrote:
>
> > I'm trying to make some nommu-friendly busybox-like tools, which means using
> > vfork() instead of fork(). This means that after I fork I have to exec in
> > the child to unblock the parent, an
On Saturday 16 December 2006 10:07, Marek Wawrzyczny wrote:
> The open source driver development is promising but it has been mentioned
> several times that the project is undermanned and the vendors are not
> forthcoming with the necessary information.
> My hardware as it stands today is still n
On Saturday 21 October 2006 20:08, Ben Greear wrote:
> > > or shouldn't rpm notice the previous process is dead and
> > > clean it up itself?
> >
> > Sounds sensible to me and you, but in the past sensible ideas and
> > rpm maintainers haven't gone hand in hand.
> >
> Ahhh :)
Well said. rpm
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 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 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 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 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 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 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
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
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
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
> > > > 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 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
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 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
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(;;)
> >>
[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 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
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 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
> > 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 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
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
> > 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 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
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
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-
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
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
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
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 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 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 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 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 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 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
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:
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
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
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 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
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 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
1 - 100 of 183 matches
Mail list logo
