Re: Uncle Sam Wants YOU!
Paul Mundt wrote: > > You always have a choice, work elsewhere. If you're in a position where you're > working with MS products, you were the one who made the decision to do so. > MS is not at fault, claiming so is childish. Nobody chooses to work with MS, they merely take the job that's offered. I didn't choose to use MS, I merely chose to be able to pay the rent. The choice is basically use MS or don't work in the computer industry. Hell, I'd even take a pay cut if someone had a Linux job on offer. Never seen one... never likely to either in the near future. MS completely owns the business world (and it's not like I've not looked either, I'd give anything to get out of the job I'm in now but there's very few people hiring at the moment). I don't think that MS are all wrong... I even *like* Visual Studio (not the .NET one though, beta1 was unusable). It's just the creeping vendor lockin that I hate. Tony -- "Two weeks before due date, the programmers work 22 hour days cobbling an application from... (apparently) one programmer bashing his face into the keyboard." -- Dilbert [EMAIL PROTECTED] http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
Davide Libenzi wrote: > 1) HW is cheaper than software engineers time Compared to E1000s??? You must be talking about some *really* expensive engineers! > 2) to find Java developers is easier than to find C developers Depends on where you are in the world. It's certainly not true here (everyone knows C/C++... Haven't had a java developer apply for a job in months). > 3) the ETA of the same project developed in Java is shorter than the same > project done in C Depends on the developers. Good developers can churn out the same project to roughly the same timescale in any language (except possibly assembly). Java is useful if you need the cross platform bit & the target users aren't technically savvy enough to recompile. For an in-house app where you control the hardware you'd be better off using a C/C++/RAD & doing it native. Tony (Just came back from a .NET conference... MS are currently rewriting all their apps in bytecode... whoopee... They're even porting *games* to run on it. I can see it now 'MS Flight Simulator .NET' (Requires quad Pentium 4 1.6Ghz minimum) :-o ) Tony -- "Two weeks before due date, the programmers work 22 hour days cobbling an application from... (apparently) one programmer bashing his face into the keyboard." -- Dilbert [EMAIL PROTECTED] http://www.tony.hoyle.geek [EMAIL PROTECTED] http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN is on!
Richard Gooch wrote: > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to bounce mails of the following type: > - MIME encoded > - HTML encoded > - quoted printables (those stupid "=20" things are particuarly hard to > read). Surely it'd be better to get the list to filter them through stripmime? I'd be tempted to put a message at the top at the same time: "*WARNING* The message below was sent by someone too clueless to configure their email client properly" :-) Tony -- "Two weeks before due date, the programmers work 22 hour days cobbling an application from... (apparently) one programmer bashing his face into the keyboard." -- Dilbert [EMAIL PROTECTED] http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
Matthias Andree wrote: > It's probably not. vs-13048 can usually be rectified (ugly, slow but > usually works on machines even with 256 MB RAM and 1/2 GB swap) by ls > -laR / or treescan -stat /. ls can't access the files either, so I don't see how that could rectify anything. The entire directory becomes inaccessible. This happened to /lib once. Nasty. I'd like to be able to use something like reiserfs, especially when developing (it reduces boot time a lot). However to call it 'stable' on 2.4.4 is simply wrong. If/when the nfs fix gets merged and tested *then* it stands a chance of being called stable. Tony -- Where a calculator on the ENIAC is equpped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. -- Popular Mechanics, March 1949 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
Matthias Andree wrote: > You're not getting data loss, but access denied, when hitting > incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less > of a problem. Please search the reiserfs list archives for details. > vs-13048 is a good search term, I believe. Data is lost: Root can't access the files. Reiserfsck can't repair the files. The files that are corrupted are unrelated to the ones exported over NFS (which makes me wonder if it's the same bug). File corruption would begin a couple of hours after the volume was formatted, and become catastrophic within a couple of days. Until the fix is merged I'm not going within 100 miles of reiserfs! Tony -- Where a calculator on the ENIAC is equpped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. -- Popular Mechanics, March 1949 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
Matthias Andree wrote: > ext3fs has never given me any problems, but I did not have it in > production use where I discovered major ReiserFS <-> kNFSd > incompatibilities. ext3 has a 0.0.x version number which suggests it's > not meant for production use. Hmm... Reiserfs is incompatible with knfsd? That might explain the massive data loss I was getting with reiserfs (basically I'd have to reformat and reinstall every couple of weeks). The machine this was happening with also exports my apt cache for the rest of the network. Tony -- Where a calculator on the ENIAC is equpped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. -- Popular Mechanics, March 1949 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: just-in-time debugging?
On 28 Apr 2001 13:44:48 -0700, Davide Libenzi wrote: > Sorry but why don't You run Your application with gdb ? > Once Your program crashes You'll get the prompt and You'll be able to > stack-trace and watching whatever You need. > The solution I use to be able to get inside the program even when the gdb is > not running is the one that You can find in the attached file. > Basically it install the handler that will create a script file that You can > use to automatically enter with gdb inside Your program while it's running. Because the program is invoked as part of a much larger system & I don't know which process is going to crash when. Having gdb come up automatically would greatly decrease development time. I'm trying to track down multiple bugs (caused by me, but they still need tracking down) which show up during stress testing. The bug will manifest itself in maybe the 1000th iteration... If I could hack gdb into coming up automatically when things went wrong it'd get rid of the need to have thousands of printf's in the app (which is my primary debugging tool at the moment). At work I do this all the time... Windows pops up a dialog which basically says 'the program has crashed, debug?' and drops you straight into VC with everything intact. It has assertion macros which wrap int3 instructions. You then continue your app under normal debug conditions. Tony (Fighting with evolution because Mozilla broke imap again... sigh...) -- "Two weeks before due date, the programmers work 22 hour days cobbling an application from... (apparently) one programmer bashing his face into the keyboard." -- Dilbert [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
just-in-time debugging?
Is there a way (kernel or userspace... doesn't matter) that gdb/ddd could be invoked when a program is about to dump core, or perhaps on a certain signal (that the app could deliver to itself when required). The latter case is what I need right now, as I have to debug an app that breaks seemingly randomly & I need to halt when certain assertions fail. Core dumps aren't much use as you can't resume them, otherwise I'd just force a segfault or something. I had a look at the do_coredump stuff and it looks like it could be altered to call gdb in the same way that modprobe gets called by kmod... however I don't sufficiently know the code to work out whether it'd work properly or not. A patch to glibc would perhaps be better, but I know that code even less! Something like responding to SIGTRAP would probably be ideal. Tony -- "Two weeks before due date, the programmers work 22 hour days cobbling an application from... (apparently) one programmer bashing his face into the keyboard." -- Dilbert [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic with 2.4.x and reiserfs
jason wrote: > Hello, > > As the subject would imply, I've been having problems with 2.4.x. I have > my root partition (/dev/hda1) as reiserfs and also have another harddrive > with a reiserfs partition (/dev/hdc1). Several programs write (e.g. save > files to) /dev/hdc1, and I also store files there. Under 2.4.2, whenever > manually copying files from hda1 to hdc1, I would get a kernel panic, the Reiserfs doesn't cope well with crashes Under 2.4 I wouldn't recommend using it on any kind of critical server - it seems to progressively corrupt itself (I'm looking at the second reformat and reinstall in a week, and I'm not a happy bunny). As the warning on reiserfsck says, the rebuild-tree option is a last resort. It's as likely to make the problem worse then improve it (It rounds all the file lengths up to a block size, padding with zeros, which breaks lots of stuff). Backup what you can first. I find that if you run reiserfsck -x /dev/hda1 a couple of dozen times it slowly fixes stuff that it couldn't fix on the previous pass.One thing that can't fix is the bug that seems to make random files on the FS unreadable even for root.The only way I've found around that one is a periodic format/reinstall. Tony -- Where a calculator on the ENIAC is equpped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. -- Popular Mechanics, March 1949 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resend - [PATCH] Fix SMP lockup in usbdevfs
This one didn't quite make 2.4.3, this time I've CC'd to AC. I've been using this fix for a few days now & it's cleared up a lot of problems - although I'm not 100% sure why it worked (the memset should do the same job as the spin_lock_init surely?). Tony Original Message Subject: [PATCH] Fix SMP lockup in usbdevfs Date: Fri, 30 Mar 2001 02:36:47 +0100 From: Tony Hoyle <[EMAIL PROTECTED]> Organization: Magenta Logic To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] This fixes a lockup when calling the USBDEVFS_SUBMITURB ioctl in an SMP kernel. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv --- devio.c.old Fri Mar 30 02:22:32 2001 +++ devio.c Fri Mar 30 02:12:09 2001 @@ -175,6 +175,7 @@ return NULL; memset(as, 0, assize); as->urb.number_of_packets = numisoframes; +spin_lock_init(&as->urb.lock); return as; } @@ -250,7 +251,7 @@ struct dev_state *ps = as->ps; struct siginfo sinfo; -#if 1 +#if 0 printk(KERN_DEBUG "usbdevfs: async_completed: status %d errcount %d actlen %d pipe 0x%x\n", urb->status, urb->error_count, urb->actual_length, urb->pipe); #endif
Re: How to debug an oops?
Sorry, came across a bit strong on that message. It's 2am and I'm tired. Stupid thing is I fixed the bug... Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix SMP lockup in usbdevfs
This fixes a lockup when calling the USBDEVFS_SUBMITURB ioctl in an SMP kernel. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv --- devio.c.old Fri Mar 30 02:22:32 2001 +++ devio.c Fri Mar 30 02:12:09 2001 @@ -175,6 +175,7 @@ return NULL; memset(as, 0, assize); as->urb.number_of_packets = numisoframes; +spin_lock_init(&as->urb.lock); return as; } @@ -250,7 +251,7 @@ struct dev_state *ps = as->ps; struct siginfo sinfo; -#if 1 +#if 0 printk(KERN_DEBUG "usbdevfs: async_completed: status %d errcount %d actlen %d pipe 0x%x\n", urb->status, urb->error_count, urb->actual_length, urb->pipe); #endif
How to debug an oops?
Nobody seems interested in the spinlock bugs in usb so I'm trying to track it down myself. I have a copy of an oops (posted earlier) but it doesn't give the line number of the error, so it's impossible to find out where it's failing. Will kdb be any help? Is it a source debugger or just a glorified hex editor? I need to be able to break into the kernel and single step through the calls to work out what is going on. I'm really out of my depth trying to debug this, but I hate having to boot a UP kernel just to use usb. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Repeatable lockup on SMP w/usbprocfs
I've enabled spinlock debugging, and generated a nice oops... The USB system is definately doing something wrong somewhere. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv ksymoops 2.3.7 on i686 2.4.2-ac26. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-ac26/ (default) -m /boot/System.map-2.4.2-ac26 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. eip: d28eb1b5 kernel BUG at /usr/src/linux/include/asm/spinlock.h:90! invalid operand: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0038 ebx: cff44710 ecx: c0264ba0 edx: 4e26 esi: cda794bc edi: cff44680 ebp: ffea esp: cd28ded8 ds: 0018es: 0018 ss: 0018 Process mgmt (pid: 408, stackpage=cd28d000) Stack: d28edae0 005a cda793c8 cda794a0 cda793a0 0286 cda794c8 cff44710 0292 cff44680 d28d90e6 cda794bc d28deb1f cda794bc cda793a0 bc70 <4>fdfd cfb69940 0002 8103 Call Trace: [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 f0 fe 0e 88 ee 27 00 00 8b 46 20 83 f8 8d >>EIP; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <= Trace; d28edae0 <[uhci].rodata.start+20/110c> Trace; d28d90e6 <[usbcore]usb_submit_urb+1e/30> Trace; d28deb1f <[usbcore]proc_submiturb+56f/64c> Trace; d28df627 <[usbcore]usbdev_ioctl+1ef/298> Trace; c014d588 Trace; c014d588 Trace; c010756b Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <_EIP>: Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <= 0: 0f 0b ud2a <= Code; d28eb1de <[uhci]uhci_submit_urb+136/3fc> 2: 83 c4 08 add$0x8,%esp Code; d28eb1e1 <[uhci]uhci_submit_urb+139/3fc> 5: f0 fe 0e lock decb (%esi) Code; d28eb1e4 <[uhci]uhci_submit_urb+13c/3fc> 8: 88 ee mov%ch,%dh Code; d28eb1e6 <[uhci]uhci_submit_urb+13e/3fc> a: 27daa Code; d28eb1e7 <[uhci]uhci_submit_urb+13f/3fc> b: 00 00 add%al,(%eax) Code; d28eb1e9 <[uhci]uhci_submit_urb+141/3fc> d: 8b 46 20 mov0x20(%esi),%eax Code; d28eb1ec <[uhci]uhci_submit_urb+144/3fc> 10: 83 f8 8d cmp$0xff8d,%eax 1 warning issued. Results may not be reliable.
Repeatable lockup on SMP w/usbprocfs
If an application calls the USBDEVFS_SUBMITURB ioctl to submit a read, when the async completion routine is called, the kernel goes into a hard deadlock (no response to ping, etc.). I've narrowed it down to the async_completed routine in usb.c. That's the only place where spinlocks are used. I'm not familiar enough with them to see what the error is, though. The system runs fine until the packet is returned, then it just locks solid (On the alcatel USB modem I used for testing it will not respond until it gets sync, which may be several seconds). Others have found that just compiling SMP into the kernel is enough to break it, you don't actually need two processors. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Unable to load intepreter" on login - 2.2.14-5.0
Paul Tweedy wrote: > Secondly, to get the thing running I'm assuming I can copy a working login > binary from an identical server, so I can get in & change the passwords and > sort the security out? ...and what if the 'cp' binary has been hacked to stop you doing just that? What if 'passwd' is silently emailing your root password to the hacker each time you change it? Reformat and re-install. It's the only way (and check your firewall). Tony -- The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location... and i'm not even too sure about that one"--Dennis Huges, FBI. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: spelling of disc (disk) in /devfs
Dr. Kelsey Hudson wrote: > It had always been my assumption that non-optical storage media used the > 'disk' spelling, whereas optical media, such as CDs, DVDs, and MO, were > reffered to using the 'disc' spelling. I can remember having this argument back in the days of the BBC Micro. The BBC is the only machine I have ever seen that used 'disc'... In those days I assumed it was correct. Over time, I came to accept that we used 'disk' for the same reasons we use 'program' rather than 'programme'. I haven't heard anyone in the UK spell it 'disc' for years When I last tried devfs (around the 2.4.0test era - a short and painful experience, but that's another story) I was confused by the use of 'disc'. IMHO it should be changed, because it's simply wrong, even in england (so please stop blaming us for it!). Tony -- "User DATA\tmh cannot be created because DATA\tmh does not exist." Windows -- Great UI huh? [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI slowdown...
Grover, Andrew wrote: > Since you have a symtomatic system, if you're willing to do some testing to > either prove or disprove your theory (that entering C2/C3 interrupts enabled > helps things) I would greatly appreciate it. Leaving interrupts enabled does help a little, but the machine is still unusably slow, so it's not the fix. > Also, the next ACPI update will let you disable using this code for idle (so > we have some breathing room while we fix it) and will print some more C > state info on boot, because although you don't say, it sounds like you have > a desktop system, which usually don't support C2/C3, and so should not be > trying to enter them. Disabling the idle code definitely fixes it. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI slowdown...
Tony Hoyle wrote:
I'm talking to myself :-)
OK I see that safe_halt() will re-enable interrupts. However this is only
called in S1. If your machine gets as far as S3 you have...
for (;;) {
unsigned long time;
unsigned long diff;
__cli();
if (current->need_resched)
goto out;
if (acpi_bm_activity())
goto sleep2;
time = acpi_read_pm_timer();
inb(acpi_pblk + ACPI_P_LVL3);
/* Dummy read, force synchronization with the PMU */
acpi_read_pm_timer();
diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
__sti();
if (diff < acpi_c3_exit_latency)
goto sleep2;
}
There is no halt here... the interrupts are enabled for only a couple of
instructions (one comparison and a jump) before being disabled again.
It seems to me if the computer gets into S3 it'll effectively die until
some kind of busmaster device wakes it up (DMA?).
The simple fix is to delete lines 332-337 of cpu.c, which disables the
idle process (and explains why I've had no slowdown on my SMP machine).
Lots of people (like me) only use ACPI for the power-off/shutdown
functionality anyway. Laptop users will probably have to wait for a
proper fix (unfortunately the ACPI4Linux mailing list looks dead - it's
just full of people complaining about 2.4.1...)
Tony
--
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ACPI slowdown...
I've been trying to track down what makes ACPI kill the system in 2.4.1.
In the acpi_idle function (drivers/acpi/cpu.c), it seems to spend most
of its time with interrupts disabled, only enabling them to check
need_resched occasionally.
In the 'sleep1' state the following code is executed:
for (;;) {
unsigned long time;
unsigned long diff;
__cli();
if (current->need_resched)
goto out;
time = acpi_read_pm_timer();
safe_halt();
diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
if (diff > acpi_c2_enter_latency
&& acpi_max_c_state >= 2)
goto sleep2;
}
This looks wrong to me. It's basically looping with interrupts
disabled. I can't see how current->need_resched could be updated at
all, so the loop will only terminate when the PM timer tells it to.
Isn't disabling interrupts a bad thing anyway? Wouldn't it be better to
leave them enabled (this is uniprocessor only so there shouldn't be
concurrency issues).
Tony
--
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ACPI broken in 2.4.1
In my wifes' machine 2.4.1 (both vanilla and -ac2) enabling ACPI causes the machine to run so slowly it's unusable. On my machine it's OK. 2.4.0 worked fine, so something has changed between 2.4.0 and 2.4.1 that broke it. I couldn't find anything in dmesg that looked any different, though. However since that machine has never successfully booted with ACPI on the kern.log hasn't been written so it's unlikely I'd find anything. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
Lars Marowsky-Bree wrote: > > So you also turn of PMTU and just set the MTU to 200 bytes because broken > firewalls may drop ICMP ? That doesn't affect huge numbers of websites. In the UK two of the largest ISPs - BT Internet and Freeserve - have ECN-blocking firewalls. So does theregister.co.uk for that matter. If I enable ECN I lose the ability to send emails to a huge percentage of the people on the mailing lists that run on my machine. These ISPs will *not* change simply because 1% of Linux users complain at them. They have been contacted about this and they know of the problem. I doubt they care. Firewalls dropping ICMP does not make my internet connection practically unusable. Firewalls dropping ECN does. Tony -- The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location... and i'm not even too sure about that one"--Dennis Huges, FBI. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TEST13-PRE7 - Nvidia Kernel Module Compile Problem
Tony Spinillo wrote: > > The nvidia kernel module (from www.nvidia.com) has compiled and loaded > correctly with all test13-pre series up to pre6. I just tried to > compile and load under pre7. I'm intrigued... how did you resolve the 'mem_map_inc_count' and 'mem_map_dec_count', 'put_module_symbol' and 'get_module_symbol' references? It's only of academic interest for me now as I've ditched the nvidia - not worth the hassle. Amusingly, We're breaking the EULA even by reading the supplied source code... Tony -- Can't think of a decent signature... [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: tdfx.o and -test13
Alan Cox wrote: > > I see modversions.h being included properly on the command line Me too.. make[3]: Entering directory `/usr/src/linux/drivers/char/drm' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h -c -o agpsupport.o agpsupport.c In file included from agpsupport.c:1: /usr/src/linux/include/linux/modversions.h:3: warning: ignoring pragma: "Modversions included Modversions *is* being included... putting a message into the header file shows it to be correctly included at compile time. However by the time the C file is processed it the symbols it has defined appear to no longer exist. When you put the patch into drmP.h it never re-includes modversions (the pragma is not hit, because _LINUX_MODVERSIONS_H is already defined) *but* the macros within it suddenly become active. I'm confused! Preprocessor bug? Demon possessed compiler? Tony (still coding at 20 minutes to midnight --- sad or what?) -- Can't think of a decent signature... [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: tdfx.o and -test13
Alan Cox wrote: > > > Possibly something in the auto-dependencies? Unfortunately I don't have > > the info files for gcc so > > I can't work out why the '-include' directive would be > > overridden/ignored. > > Im wondering if it is make dependant. It seems to be working here Well I'm on: make 3.79.1 gcc 2.95.2 2220 ld 2.10.91 modversions 2.3.23 Tony -- Can't think of a decent signature... [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: tdfx.o and -test13
Tony Hoyle wrote: > modversions.h is being included in the 'gcc' line, however something is > overriding it > in the case of the agpsupport.c file. If you move the include > to > the top of agpsupport.c it also works correctly. OK ignore the above putting it in agpsupport doesn't fix it. My kernel tree went a bit T-zone after I did that. Even removing the fix totally generated a completely working module! I had to 'make distclean' to restore the old (buggy) behaviour. Possibly something in the auto-dependencies? Unfortunately I don't have the info files for gcc so I can't work out why the '-include' directive would be overridden/ignored. Tony -- Can't think of a decent signature... [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: tdfx.o and -test13
Alan Cox wrote: > Wrong patch. Modversions.h should be getting automatically included. That > is what needs fixing. You've nicely located the problem and fixed the symptoms > for the module versioned case > modversions.h is being included in the 'gcc' line, however something is overriding it in the case of the agpsupport.c file. If you move the include to the top of agpsupport.c it also works correctly. Tony -- Can't think of a decent signature... [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Dieter Nützel wrote: > > Am Mittwoch, 27. Dezember 2000 11:07 schrieb Nils Philippsen: > > Hi all, > > > > On Wed, 27 Dec 2000, Dieter [iso-8859-1] Nützel wrote: > > > I got this since test13-pre1 (pre4, now): > > > > > > SunWave1>depmod -e > > > depmod: *** Unresolved symbols in > > > /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o > > > > [snipped] > > > > > Something missing in the 'new' drm/Makefile? > > This is a temporary fix: --- drmP.oldThu Dec 28 16:27:34 2000 +++ drmP.h Sat Dec 23 13:57:08 2000 @@ -40,6 +40,7 @@ #include #endif /* __alpha__ */ #include +#include #include #include #include Tony -- Can't think of a decent signature... [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test7: umount + mount = same directory (CD)
Eugene Crosser wrote: > > The problem that I reported for -test6 is still here: > I have a mounted CD. "ls -l /mount/point" shows its directory. > If I do umount /mount/point, replace CD with another one > and mount on the same point (I did not try different mount point), > "ls -l" shows the directory from the *first* CD. If I try > to "mount" and empty tray, then insert a CD and mount it, > I see the directory of the new CD. > There are several problems I've seen with recent kernels' CD access: You can mount CD in the same directory multiple times, which gets hairy when there in daemons (gnomish things) mounting them in the background as well. Door locking is broken, so you can eject a CD which is still mounted. I've also had the CD drivers randomly returning the first session of a disk - on the Redhat Pinstripe CD for example (which has a bunch of boot images on its first session). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
