Re: 2.2.19 + ide 2.2.19 03252001 patch problem
On Fri, 6 Apr 2001, Willy Tarreau wrote:
> Quoting "Robert A. Morris" <[EMAIL PROTECTED]>:
> [snip]
> > Apr 5 18:15:14 ryoko kernel: hdb: task_no_data_intr: status=0x51 {
> > DriveReady SeekComplete Error }
> > Apr 5 18:15:14 ryoko kernel: hdb: task_no_data_intr: error=0x04 {
> > DriveStatusError }
> > Apr 5 18:15:14 ryoko kernel: hdb: Write Cache FAILED Flushing!
Oh well forgot to parse bits for older drives..drat!
> [snip]
> > This did NOT happen with 2.2.18 and the corresponding
> > ide.2.2.18.1209.patch. It does NOT seem to happen on
> > /dev/hda or /dev/hdc, which is lucky, since /dev/hdb
> > is unused. I'm using lilo.conf to specify idebus=33.
> [snip]
> > The controller is a VIA 82C686A (Asus K7V mainboard).
This is a problem the old via-code did "82C686A" fine but knew nothing
about "82C686B" and the new code does not do well with "82C686A" but good
with "82C686B".
> > hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=3739/255/63, UDMA(66)
> > hdb: WDC AC28400R, 8063MB w/512kB Cache, CHS=1027/255/63, (U)DMA
Why are we mixing drives this class?
> > hdc: WDC WD307AA-00BAA0, 29333MB w/2048kB Cache, CHS=59598/16/63,
> > UDMA(66)
>
> same problem observed here on same motherboard. The hard disk is a WDC AC23200L
> configured as hda. I have tested several ide/kernel combinations and all I can
> say is that 2.2.18 and 2.2.19 behave the same, but it worked till
> ide.2.2.18.1221 included, and the bug appeared since ide.2.2.18.02122001.
> I tried with and without vojtech's via patches (3.2, 4.2 and 4.3), but this
> didn't change anything (to be honest, some combinations were obviously not made
> to live together, and I had so many problems fitting all patches in one kernel
> that it sometimes even didn't boot).
>
> I can also say that this problem didn't show up on other chipsets (ali and
> intel) with the same kernel+ide patch.
>
> finally, I made my kernel with ide.2.2.18.1221 and all seems to be OK (one week
> now). The diffs between the 2 versions were too important and I have not
> investigated further into this, but I'm ready to make some tests if needed.
>
> Regards,
> Willy
>
> PS: BTW Andre, could you please name your patches ide-2.2.19-MMDD so that a
> directory listing show the chronological order ?
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
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: 2.2.19 + ide 2.2.19 03252001 patch problem
Quoting "Robert A. Morris" <[EMAIL PROTECTED]>:
[snip]
> Apr 5 18:15:14 ryoko kernel: hdb: task_no_data_intr: status=0x51 {
> DriveReady SeekComplete Error }
> Apr 5 18:15:14 ryoko kernel: hdb: task_no_data_intr: error=0x04 {
> DriveStatusError }
> Apr 5 18:15:14 ryoko kernel: hdb: Write Cache FAILED Flushing!
[snip]
> This did NOT happen with 2.2.18 and the corresponding
> ide.2.2.18.1209.patch. It does NOT seem to happen on
> /dev/hda or /dev/hdc, which is lucky, since /dev/hdb
> is unused. I'm using lilo.conf to specify idebus=33.
[snip]
> The controller is a VIA 82C686A (Asus K7V mainboard).
> hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=3739/255/63, UDMA(66)
> hdb: WDC AC28400R, 8063MB w/512kB Cache, CHS=1027/255/63, (U)DMA
> hdc: WDC WD307AA-00BAA0, 29333MB w/2048kB Cache, CHS=59598/16/63,
> UDMA(66)
same problem observed here on same motherboard. The hard disk is a WDC AC23200L
configured as hda. I have tested several ide/kernel combinations and all I can
say is that 2.2.18 and 2.2.19 behave the same, but it worked till
ide.2.2.18.1221 included, and the bug appeared since ide.2.2.18.02122001.
I tried with and without vojtech's via patches (3.2, 4.2 and 4.3), but this
didn't change anything (to be honest, some combinations were obviously not made
to live together, and I had so many problems fitting all patches in one kernel
that it sometimes even didn't boot).
I can also say that this problem didn't show up on other chipsets (ali and
intel) with the same kernel+ide patch.
finally, I made my kernel with ide.2.2.18.1221 and all seems to be OK (one week
now). The diffs between the 2 versions were too important and I have not
investigated further into this, but I'm ready to make some tests if needed.
Regards,
Willy
PS: BTW Andre, could you please name your patches ide-2.2.19-MMDD so that a
directory listing show the chronological order ?
-
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/
sorry about that (Old email address)
Sorry about that, that last email had an old address on it, this address should work for replies/cc's: [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/
lockup/crash in 2.4.3 (kernel BUG at exit.c:458!)
After I installed 2.4.3, my system would seemingly randomly hadn, about once a day. It hung at least 3 times, but it looks like theres only entries in my syslog for 2 of those times, my system is an AMD Thununderbird 1Ghz, 256MB RAM, VIA KX133A chipset (Abit KT7A), if there's any other info you need let me know, and please CC me any responses, I'm not subscribed to the list. I'm not exactly up on kernel internals, and I can't really provide any info about what could have caused it. Here's what showed up in my syslog: Apr 1 08:05:00 chutz kernel: Unable to handle kernel paging request at virtual address 1030 Apr 1 08:05:00 chutz kernel: printing eip: Apr 1 08:05:00 chutz kernel: c01343a6 Apr 1 08:05:00 chutz kernel: *pde = Apr 1 08:05:00 chutz kernel: Oops: 0002 Apr 1 08:05:00 chutz kernel: CPU:0 Apr 1 08:05:00 chutz kernel: EIP:0010:[try_to_free_buffers+150/816] Apr 1 08:05:00 chutz kernel: EFLAGS: 00210206 Apr 1 08:05:00 chutz kernel: eax: 1000 ebx: c9fb19c0 ecx: edx: cfd5d740 Apr 1 08:05:00 chutz kernel: esi: c9fb19c0 edi: c9fb19c0 ebp: esp: c1479f54 Apr 1 08:05:00 chutz kernel: ds: 0018 es: 0018 ss: 0018 Apr 1 08:05:00 chutz kernel: Process bdflush (pid: 5, stackpage=c1479000) Apr 1 08:05:00 chutz kernel: Stack: 0003 c1479f88 ceff87c0 0008 0001 00200213 Apr 1 08:05:00 chutz kernel:0001 01de c012ad43 c1073490 0007 c0129e27 Apr 1 08:05:00 chutz kernel:c1073490 0004 0001 2f99 Apr 1 08:05:00 chutz kernel: Call Trace: [free_shortage+35/208] [page_launder+871/2208] [bdflush+140/288] [init+0/384] [init+0/384] [kernel_thread+38/48] [bdflush+0/288] Apr 1 08:05:00 chutz kernel: Apr 1 08:05:00 chutz kernel: Code: 89 50 30 8b 53 30 8b 03 89 02 c7 43 30 00 00 00 00 8b 53 24 Apr 1 08:05:00 chutz kernel: kernel BUG at exit.c:458! Apr 1 08:05:00 chutz kernel: invalid operand: Apr 1 08:05:00 chutz kernel: CPU:0 Apr 1 08:05:00 chutz kernel: EIP:0010:[do_exit+512/528] Apr 1 08:05:00 chutz kernel: EFLAGS: 00010282 Apr 1 08:05:00 chutz kernel: eax: 001a ebx: ecx: 0001 edx: c0256308 Apr 1 08:05:00 chutz kernel: esi: c1478000 edi: 000b ebp: c0218880 esp: c1479e40 Apr 1 08:05:00 chutz kernel: ds: 0018 es: 0018 ss: 0018 Apr 1 08:05:00 chutz kernel: Process bdflush (pid: 5, stackpage=c1479000) Apr 1 08:05:00 chutz kernel: Stack: c0219c05 c0219c9c 01ca c0218880 c01077a9 c02145e1 c021472d Apr 1 08:05:00 chutz kernel:0002 1030 c0110858 000b c1479f20 0002 c1478000 Apr 1 08:05:00 chutz kernel:c1478000 c147200c 0047 00030001 c02cb620 c1473000 0001 c02cb7b4 Apr 1 08:05:00 chutz kernel: Call Trace: [die+57/80] [do_page_fault+824/1056] [__make_request+311/1680] [__make_request+616/1680] [__make_request+640/1680] [ide_do_request+675/752] [do_page_fault+0/1056] Apr 1 08:05:00 chutz kernel:[error_code+52/60] [try_to_free_buffers+150/816] [free_shortage+35/208] [page_launder+871/2208] [bdflush+140/288] [init+0/384] [init+0/384] [kernel_thread+38/48] Apr 1 08:05:00 chutz kernel:[bdflush+0/288] Apr 1 08:05:00 chutz kernel: Apr 1 08:05:00 chutz kernel: Code: 0f 0b 83 c4 0c e9 57 fe ff ff 8d b6 00 00 00 00 55 57 56 53 Apr 1 08:05:00 chutz kernel: kernel BUG at exit.c:458! Apr 1 08:05:00 chutz kernel: invalid operand: Apr 1 08:05:00 chutz kernel: CPU:0 Apr 1 08:05:00 chutz kernel: EIP:0010:[do_exit+512/528] Apr 1 08:05:00 chutz kernel: EFLAGS: 00013282 Apr 1 08:05:00 chutz kernel: eax: 001a ebx: ecx: 0001 edx: c0256308 Apr 1 08:05:00 chutz kernel: esi: c1478000 edi: 000b ebp: c0218880 esp: c1479d18 Apr 1 08:05:00 chutz kernel: ds: 0018 es: 0018 ss: 0018 Apr 1 08:05:00 chutz kernel: Process bdflush (pid: 5, stackpage=c1479000) Apr 1 08:05:00 chutz kernel: Stack: c0219c05 c0219c9c 01ca c1479e0c c0107ab0 c0218880 c1479e0c Apr 1 08:05:00 chutz kernel: c0107ab0 c0107b62 000b c024ab80 3000 c1479d64 Apr 1 08:05:00 chutz kernel: c1479d6c c1479d74 c024ab80 2000 00343538 Apr 1 08:05:00 chutz kernel: Call Trace: [do_invalid_op+0/192] [do_invalid_op+0/192] [do_invalid_op+178/192] [do_exit+512/528] [do_notify_parent+197/224] [vsprintf+908/960] [error_code+52/60] Apr 1 08:05:00 chutz kernel:[do_exit+512/528] [die+57/80] [do_page_fault+824/1056] [__make_request+311/1680] [__make_request+616/1680] [__make_request+640/1680] [ide_do_request+675/752] [do_page_fault+0/1056] Apr 1 08:05:00 chutz kernel:[error_code+52/60] [try_to_free_buffers+150/816] [free_shortage+35/208] [page_launder+871/2208] [bdflush+140/288] [init+0/384] [init+0/384] [kernel_thread+38/48] Apr 1 08:05:00 chutz kernel:[bdflush+0/288] Apr 1 08:05:00
Re: Arch specific/multiple Configure.help files?
I went ahead and implemented the change last night anyway and I will submit the patches and see if it will be accepted or not. The idea is that it first check in arch/$ARCH/Configure.help and if the file or the help is not found there, check Documentation/Configure.help. I believe there is an advantage from a maintenance point of view. It least for our CRIS architecture, I don't think it's any benefit to "bloat" the Documentation/Configure.help with a lot of CONFIG_ETRAX entries for the various hardware inerfaces when the help and config can be kept locally. BTW: I added this to scripts/Configure and scripts/Menuconfig but I know to little tcl/tk to get it to work for the xconfig case. The variable $ARCH was not found and I don't know how to make it get it from the environment variables. /Johan - Original Message - From: Rogier Wolff <[EMAIL PROTECTED]> To: Erik Mouw <[EMAIL PROTECTED]> Cc: Johan Adolfsson <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 11:56 PM Subject: Re: Arch specific/multiple Configure.help files? > Erik Mouw wrote: > > On Thu, Apr 05, 2001 at 07:28:33PM +0200, Johan Adolfsson wrote: > > > Would it be a good idea to have support for multiple Configure.help > > > files in the config system? > > > The main advantage would be that arch specific settings could > > > have an arch specific help file as well. > > > > I don't see why this would be an advantage. IMHO Documentation belongs > > in the Documentation tree and configuration documentation belongs in > > Configure.help. You almost never read that file yourself, only the > > various kernel configure tools read it, and tools don't have a problem > > with large files. It's better to have the documentation at a single > > point, not scattered around in the kernel tree. > > Well, the configure help is now "scattered around": The configuration > options are in the "configure.in" files, and hte docs for them are > somewhere else, even if it's in one large file. > > I'm not sure if Larry's CML2 has the help for the options near the > options or not, but that's how I'd like it to be if I were designing > the thing from scratch. (a bit like emacs' functions: there too, you > give the help text near the definition of a functions!) > > Roger. > > -- > ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > * There are old pilots, and there are bold pilots. > * There are also old, bald pilots. > - > 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/ > - 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: [PATCH] Revised memory-management stuff
You write: > Can you copy me your reply(s) to my post? For some unknown reason, I am > getting very few messages from the list, and I saw your reply in the > archives. So far I haven't even got my own post back... That's because the last time I replied to your email, it bounced. Something bad with your outgoing mail headers, or your ISP. I'm cc'ing you twice. > >I'm not sure I follow this one. Granted it punishes larger programs, > >but is this really good? If I read it correctly, it essentially means > >that it is impossible for a single process to use > 80% of the VM. > > The rationale for the 4x rule is that 4/5ths of the VM space is usually > bigger than the physical memory of a machine (thanks to swap). For most > applications, allowing a single process to grow beyond the physical memory > size is a poor idea and will normally lead to thrashing. If you absolutely > need your application to be able to grow to that kind of size, add more > swap or turn vm_overcommit_memory to 1 with it's associated warnings. I suppose it makes sense if you consider you don't want a single application using > 80% of RAM + SWAP. I was more thinking about a limit of 80% RAM, which would be a big hassle. > >If you allow process names into the picture, it opens an easy DOS attack. > >A memory hog simply runs under one of the "protected" names and is > >immune from being killed, but causes every other process on the box to > >die. I'm pretty sure this idea was suggested and previously shot down > >at least once. > > Noted, but I would expect the sysadmin to be aware of this and thus only > use the PID-based system on machines with untrusted local users. Having > the ability to specify process names should make it easier on sysadmins who > *don't* have untrusted local users but *do* have rapidly-changing lists of > PIDs that need protection. I still dislike the use of a static list, because as soon as you put any PIDs on it, you end up with stale entries at some point. Names may help in this regard, but then there is the issue that some processes change their process name, etc... > >The OOM-unkillable trait would be stored as a per-process flag, rather > >than a list to be checked against. It means that we don't have stale > >OOM-unkillable entries in the list. The non-OOM trait would be inherited > >across fork() (but cleared on set*uid(), or maybe it should be a capability) > >so that processes (e.g. httpd) which spawn/kill helper tasks do not have > >to keep updating a list. This also prevents the situation where PID X is > >protected from OOM, but is stopped and later another process takes its PID. > > Interesting idea, which does sound sensible. There would have to be a > mechanism for an external process to set this flag, so that the application > need not explicitly have to support this in order to use it. Cf. nice and > renice. > > I don't quite agree on the "clear on setuid()" idea though. Critical > processes can and do drop su privileges for normal operation, which doesn't > make them non-critical in any way. If the critical process needs to spawn > a non-critical thread or new process, have it explicitly drop the flag > after forking. OK, that was just something I put in there, because I was thinking if you make init() OOM-unkillable, then everything it spawns would inherit this trait. There are probably standard ways that processes inherit or drop other priveleges (i.e. capabilities), so no point in inventing something new. I just wanted to point out that not everything should inherit this. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: syslog insmod please!
On Thu, 5 Apr 2001, Andreas Dilger wrote: > Why do it from user space? Simply add a printk() to sys_init_module() or > similar. Agreed, but at that point the solution has absolutely nothing to do with insmod anymore. :-) Besides, as you said, I don't really see the point. It certainly doesn't help with logging the actions of an attacker, and on the other hand kmod already logs its own actions. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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: syslog insmod please!
Ion writes: > Andrew Daviel <[EMAIL PROTECTED]> wrote: > > Is there a good reason why insmod should not call syslog() to log > > any module that gets installed ? > > Simple: you'll have quite a bit of a problem if you are trying to insmod > the module with support for AF_UNIX sockets. :-) Why do it from user space? Simply add a printk() to sys_init_module() or similar. Granted, this will only help until the lusers install a patched sysklog before installing a backdoor module, but so would the user-space solution. At least the kernel message will stay in kernel memory until it is flushed out with more messages (which itself might be detectable). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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/
Oopsen everywhere in open_namei, kernel 2.4.3
Right after a boot, I got 5 oopsen within about 8 minutes. There are only two unique ones, which are attached. Each one occured at least twice. Someone know what's going on? -- -Steven Freedom is the freedom to say that two plus two equals four. ksymoops 2.3.4 on i586 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (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. Unable to handle kernel paging request at virtual address 78e85047 c01378c3 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: ebx: c3121460 ecx: 0001 edx: 03e8 esi: edi: 0001 ebp: 0001 esp: c4b43f4c ds: 0018 es: 0018 ss: 0018 Process modemlights_app (pid: 301, stackpage=c4b43000) Stack: 080be760 0001 c72e4000 0004 c47d0ac0 c012c87e c72e4000 0001 01b6 c4b43f84 0010 c47d0ac0 c1241240 0001 c72e4000 0001 0001 c012cb89 c72e4000 Call Trace: [] [] [] Code: ff 89 46 50 e8 78 3b ff ff 89 46 54 8b 4d e0 8b 7d 0c 89 4d >>EIP; c01378c3<= Trace; c012c87e Trace; c012cb89 Trace; c0106d73 Code; c01378c3 <_EIP>: Code; c01378c3<= 0: ff 89 46 50 e8 78 decl 0x78e85046(%ecx) <= Code; c01378c9 6: 3b ff cmp%edi,%edi Code; c01378cb 8: ff 89 46 54 8b 4d decl 0x4d8b5446(%ecx) Code; c01378d1 e: e0 8b loopne ff9b <_EIP+0xff9b> c013785e Code; c01378d3 10: 7d 0c jge1e <_EIP+0x1e> c01378e1 Code; c01378d5 12: 89 4d 00 mov%ecx,0x0(%ebp) 1 warning issued. Results may not be reliable. ksymoops 2.3.4 on i586 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (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. Unable to handle kernel paging request at virtual address 78e8504a c01378c3 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210293 eax: ebx: c7f2f260 ecx: 0004 edx: esi: edi: 0001 ebp: 0001 esp: c317ff4c ds: 0018 es: 0018 ss: 0018 Process gpm (pid: 462, stackpage=c317f000) Stack: 08058240 0001 c784b000 00200286 0004 c76e1f40 c012c87e c784b000 0001 0001 c317ff84 0002 c76e1f40 c1241240 0001 c784b000 0001 0001 c012cb89 c784b000 Call Trace: [] [] [] Code: f6 75 77 f7 c5 00 02 00 00 74 5c 53 e8 ec ec ff ff 89 c6 83 >>EIP; c01378c3<= Trace; c012c87e Trace; c012cb89 Trace; c0106d73 Code; c01378c3 <_EIP>: Code; c01378c3<= 0: f6 75 77 div0x77(%ebp),%al <= Code; c01378c6 3: f7 c5 00 02 00 00 test $0x200,%ebp Code; c01378cc 9: 74 5c je 67 <_EIP+0x67> c013792a Code; c01378ce b: 53push %ebx Code; c01378cf c: e8 ec ec ff ffcall ecfd <_EIP+0xecfd> c01365c0 Code; c01378d4 11: 89 c6 mov%eax,%esi Code; c01378d6 13: 83 00 00 addl $0x0,(%eax) 1 warning issued. Results may not be reliable.
PROBLEM: OOPS report for L2 cacheable size setting at 512MB on TD5TH dual P200
[1.] One line summary of the problem: OOPS report for L2 cacheable size setting at 512MB on TD5TH dual P200 [2.] Full description of the problem/report: My system board BIOS has two settings for L2 cacheable size: 64MB and 512MB. Previous kernels would lock when initialising the framebuffer. This one initialises framebuffer but crashes later. [3.] Keywords (i.e., modules, networking, kernel): kernel initialisation [4.] Kernel version (from /proc/version): Linux version 2.4.3cc (root@heathen) (gcc version 2.95.3 20010315 (Debian release)) #1 SMP Fri Mar 30 14:22:48 PST 2001 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) ksymoops 2.3.7 on i586 2.4.3cc. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3cc/ (default) -m /boot/System.map-2.4.3cc (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. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(cuecat_process_scancode) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): snd symbol pm_register not found in /usr/lib/alsa-modules/2.4.3cc/0.5/snd.o. Ignoring /usr/lib/alsa-modules/2.4.3cc/0.5/snd.o entry Warning (compare_maps): snd symbol pm_send not found in /usr/lib/alsa-modules/2.4.3cc/0.5/snd.o. Ignoring /usr/lib/alsa-modules/2.4.3cc/0.5/snd.o entry Warning (compare_maps): snd symbol pm_unregister not found in /usr/lib/alsa-modules/2.4.3cc/0.5/snd.o. Ignoring /usr/lib/alsa-modules/2.4.3cc/0.5/snd.o entry Reading Oops report from the terminal Unable to handle kernel paging request at virtual address 418146e0 c02f5407 *pde = Oops: 0002 CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: c02f5468 ebx: c02f53fc ecx: c02f53f4 edx: c02f53f4 esi: c02f5404 edi: ebp: c02ecc60 esp: c1229ef8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c1229000) Stack: c011db55 c02f53fc c03056a0 0020 c02ecc60 c018021e 0286 c122bda0 c011a4be c03056a0 0020 c011a3a7 0001 c02ed060 0020 000e c011a24d c02ed060 c0305a00 c02ea9c0 000e c1229f74 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: c0 04 54 2f c0 0c 54 2f c0 0c 54 2f c0 f4 53 2f c0 68 60 2a >>EIP; c02f5407<= Trace; c011db55 Trace; c018021e Trace; c011a4be Trace; c011a3a7 Trace; c011a24d Trace; c01089aa Trace; c0107050 Trace; c0105170 Trace; c010519c Trace; c0105202 Trace; c011a24d Trace; c01089aa Code; c02f5407 <_EIP>: Code; c02f5407<= 0: c0 04 54 2f rolb $0x2f,(%esp,%edx,2) <= Code; c02f540b 4: c0 0c 54 2f rorb $0x2f,(%esp,%edx,2) Code; c02f540f 8: c0 0c 54 2f rorb $0x2f,(%esp,%edx,2) Code; c02f5413 c: c0(bad) Code; c02f5414 d: f4hlt Code; c02f5415 e: 53push %ebx Code; c02f5416 f: 2fdas Code; c02f5417 10: c0 68 60 2a shrb $0x2a,0x60(%eax) Kernel panic: Aiee, killing interrupt handler! 5 warnings issued. Results may not be reliable. [6.] A small shell script or example program which triggers the problem (if possible) TMC TD5TH v1.1 motherboard. L2 cacheable size set to 512MB in the BIOS. SMP configuration. [7.] Environment [7.1.] Software (add the output of the ver_linux script here) [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 4 model name : Pentium MMX stepping: 4 cpu MHz : 199.434 fdiv_bug: no hlt_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic mmx bogomips: 398.13 processor : 1 vendor_id : GenuineIntel cpu family : 5 model : 4 model name : Pentium MMX stepping: 4 cpu MHz : 199.434 fdiv_bug: no hlt_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic mmx bogomips: 398.13 [7.3.] Module information (from /proc/modules): No modules loading at the time it crashes. [7.4.] Loaded driver and hardware information (/proc/ioports,
Re: [CHECKER] 3 kmalloc underallocation bugs
Dawson Engler <[EMAIL PROTECTED]> writes:
> enclosed are three bugs found in the 2.4.1 kernel by an extension
> that checks that kmalloc calls allocate enough memory. It examines all
> callsites of the form:
> p = [kv]malloc(nbytes);
> and issues an error if
> sizeof *p < nbytes
[...]
> struct midi_hdr *midihdr;
>
> Error --->
> if ((midihdr = (struct midi_hdr *) kmalloc(sizeof(struct midi_hdr *), GF
> P_KERNEL)) == NULL) {
This sort of thing is why the comp.lang.c approved way to call
malloc() is
foo *x = malloc (sizeof *x);
No cast is required and the sizeof usage resembles the
declaration. The following is what I say on comp.lang.c when
someone does it another way. AFAICS the recommendations apply
equally to [kv]malloc().
--
When calling malloc(), I recommend using the sizeof operator on the
object you are allocating, not on the type. For instance, *don't*
write this:
int *x = malloc (sizeof (int) * 128); /* Don't do this! */
Instead, write it this way:
int *x = malloc (sizeof *x * 128);
There's a few reasons to do it this way:
* If you ever change the type that `x' points to, it's not
necessary to change the malloc() call as well.
This is more of a problem in a large program, but it's still
convenient in a small one.
* Taking the size of an object makes your sizeof call more
similar to your declaration, which makes writing the
statement less error-prone.
For instance, above, the declaration syntax is `*x' and the
sizeof operation is also written `*x'. This provides a
visual clue that the malloc() call is correct.
I don't recommend casting the return value of malloc():
* The cast is not required in ANSI C.
* Casting its return value can mask a failure to #include
, which leads to undefined behavior.
* If you cast to the wrong type by accident, odd failures can
result.
--
--
Ben Pfaff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MSU Student - Debian GNU/Linux Maintainer - GNU Developer
Personal webpage: http://www.msu.edu/user/pfaffben
-
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: a quest for a better scheduler
--On Thursday, April 05, 2001 15:38:41 -0700 "Timothy D. Witham" <[EMAIL PROTECTED]> wrote: > Database performance: > Raw storage I/O performance >OLTP workload You probably want to add an OLAP scenario as well. --Chris - 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/
2.2.19 + ide 2.2.19 03252001 patch problem
I recently upgraded my desktop machine to 2.2.19 plus
the ide.2.2.19.03252001.patch available from kernel.org
so that I may use DMA with my VIA 82C686A controller.
Now, when I attempt to mount or otherwise access
/dev/hdb, I get the following error:
Apr 5 18:15:14 ryoko kernel: hdb: task_no_data_intr: status=0x51 {
DriveReady SeekComplete Error }
Apr 5 18:15:14 ryoko kernel: hdb: task_no_data_intr: error=0x04 {
DriveStatusError }
Apr 5 18:15:14 ryoko kernel: hdb: Write Cache FAILED Flushing!
This did NOT happen with 2.2.18 and the corresponding
ide.2.2.18.1209.patch. It does NOT seem to happen on
/dev/hda or /dev/hdc, which is lucky, since /dev/hdb
is unused. I'm using lilo.conf to specify idebus=33.
The controller is a VIA 82C686A (Asus K7V mainboard).
hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=3739/255/63, UDMA(66)
hdb: WDC AC28400R, 8063MB w/512kB Cache, CHS=1027/255/63, (U)DMA
hdc: WDC WD307AA-00BAA0, 29333MB w/2048kB Cache, CHS=59598/16/63,
UDMA(66)
I'm using SCSI emulation on the secondary slave device,
identified as:
Vendor: TOSHIBA Model: DVD-ROM SD-M1402 Rev: 1008
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 0, lun 0
I include the complete dmesg log and some proc output below.
Please let me know if more is required. Thanks in advance!
Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
19990314/
Linux (egcs-1.1.2 release)) #1 Thu Apr 5 17:38:40 PDT 2001
USER-provided physical RAM map:
USER: 0009f000 @ (usable)
USER: 13f0 @ 0010 (usable)
Detected 800035 kHz processor.
ide_setup: idebus=33
Console: colour VGA+ 80x25
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 322280k/327680k available (1388k kernel code, 416k reserved,
3520k data,
76k init)
Dentry hash table entries: 65536 (order 7, 512k)
Buffer cache hash table entries: 524288 (order 9, 2048k)
Page cache hash table entries: 131072 (order 7, 512k)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: L1 I Cache: 64K L1 D Cache: 64K
CPU: L2 Cache: 512K
CPU: AMD Athlon(tm) Processor stepping 01
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xf1010
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 263M
agpgart: Detected Via Apollo Pro chipset
agpgart: AGP aperture is 64M @ 0xe400
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 524288 bhash 65536)
Starting kswapd v 1.5
parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP]
matroxfb: Matrox unknown G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x8bpp (virtual: 1024x16380)
matroxfb: framebuffer at 0xE200, mapped to 0xd480a000, size 16777216
Console: switching to colour frame buffer device 128x48
fb0: MATROX VGA frame buffer device
Detected PS/2 Mouse Port.
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 256 Unix98 ptys configured
lp0: using parport0 (interrupt-driven).
js: Joystick driver v1.2.15 (c) 1999 Vojtech Pavlik <[EMAIL PROTECTED]>
i2c: initialized
Linux video capture interface: v1.00
bttv0: Brooktree Bt878 (rev 2) bus: 0, devfn: 72, irq: 9, memory:
0xe100.
bttv: 1 Bt8xx card(s) found.
bttv0: Hauppauge eeprom: tuner=Philips FM1236 (2)
bttv0: audio chip: TDA9850
bttv0: NO fader chip: TEA6300
bttv0: model: BT878(Hauppauge new)
loop: registered device at major 7
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD307AA, ATA DISK drive
hdb: WDC AC28400R, ATA DISK drive
hdc: WDC WD307AA-00BAA0, ATA DISK drive
hdd: TOSHIBA DVD-ROM SD-M1402, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=3739/255/63, UDMA(66)
hdb: WDC AC28400R, 8063MB w/512kB Cache, CHS=1027/255/63, (U)DMA
hdc: WDC WD307AA-00BAA0, 29333MB w/2048kB Cache, CHS=59598/16/63,
UDMA(66)
Floppy drive(s): fd0 is 2.88M AMI BIOS
FDC 0 is a post-1991 82077
(scsi0) found at PCI 0/12/0
(scsi0) Narrow Channel, SCSI ID=7, 3/255 SCBs
(scsi0) Cables present (Int-50 YES, Ext-50 YES)
(scsi0) Downloading sequencer code... 415 instructions downloaded
scsi0 : Adaptec
Re: kernel BUG at page_alloc.c:75! / exit.c
On Thu, 5 Apr 2001 [EMAIL PROTECTED] wrote: > "Albert D. Cahalan" wrote: > > > > > I'm running the 2.4.3 kernel and my system always (!) crashes when I try > > > to generate the "Linux kernel poster" from lgp.linuxcare.com.au. After > > > working for one hour, the kernel printed this message: > > > > I'd guess you have a heat problem. Check for dust, a slow fan, > > an overclocked CPU, memory chips with airflow blocked by cables, > > motherboard chips that are too hot to touch... This is *not* a hardware problem. We're tracking something fishy in the vm code that is resulting in exactly the same BUG() tripping up on a number of boxes (4 and 8 way SMP). -ben - 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: gcc-2.95.3
On Fri, Apr 06, 2001 at 08:49:51AM +0800, Jeff Chua wrote: > > Does anybody have bad experience with gcc-2.95.3? > > I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. I've built and using 2.4.2 with 2.95.3 with no issues. [I should say, with no more issues than I have normally with this cheesey motherboard :-]. At least the long long computation bug on non i686 compilations is fixed with 2.95.3. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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/
2.4.2-ac18 Severworks AGP
I have a Tyan S1867 (Server Set III HE) for which I'd like to have AGP support. Here's the relevant output of lspci -v : 00:00.0 Host bridge: ServerWorks CNB20HE (rev 22) Flags: fast devsel Memory at fa00 (32-bit, prefetchable) [disabled] [size=32M] Memory at feafb000 (32-bit, non-prefetchable) [disabled] [size=4K] 00:00.1 PCI bridge: ServerWorks CNB20HE (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fd00-fdff Prefetchable memory behind bridge: f000-f7ff Capabilities: [80] AGP version 2.0 ... ... ... 01:00.0 VGA compatible controller: nVidia Corporation NV15 Bladerunner (Geforce2 GTS) (rev a4) (prog-if 00 [VGA]) Subsystem: Elsa AG: Unknown device 0c56 Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 17 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at f000 (32-bit, prefetchable) [size=128M] Expansion ROM at [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 The first thing to be noted is that the Capabilities Pointer for this chipset is on the AGP bridge not on the Host bridge like it is for currently supported chips. If I change the line if ((dev = pci_find_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) == NULL) to if ((dev = pci_find_class(PCI_CLASS_BRIDGE_PCI << 8, NULL)) == NULL) in the agp_find_supported_device routine then I am able to load the patched agpgart module. But, unfortunately, it is clear that the intel_generic setup routines won't work. Eg, intel_fetch_size returns 256 MB no matter what I have the aperture set to in the BIOS. Just poking around I notice that the byte at 0x8c changes from 1,3,5,7,9,11,13 as I change the aperture to 32,64,128,.256,512,1G,2G. Does anyone have the relevant documentation for the ServerWorks AGP configuration registers? Thanks, Marvin - 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/
Problems with serial driver 5.05, kernel 2.4.3
I'm getting some interesting behavior with the 2.4.3 serial driver and agetty. This system uses the onboard serial port (ttyS0) for a serial console (console=ttyS0,38400) along with the VGA port. If I try to start an agetty on this line (agetty -L ttyS0 38400), it gets as far as outputting "Debian GNU/Linux", etc, before freezing in ioctl(0, SNDCTL_STOP...), this according to strace. According to "ps -eo wchan", it's hanging in tty_wait_until_sent. fd 0 is /dev/ttyS0. This happens if the port is connected via null-modem cable to another computer, a null-modem cable connected to no other computer, or no cable at all. This seems to be a kernel problem to me, since its hanging in kernel space. However, the problem can be worked around somewhat by starting agetty as "agetty -n -L ttyS0 38400". In this mode of operation, the login prompt gets printed (though the banner doesn't), and I can log in. It seems to work well, except that large sustained transfers seem to lock the program on this end. For example, "dmesg" will print out a considerable amount of text, and then simply stop. Ctrl+C returns me to a bash prompt. It stops at the same spot every time, unless I start typing between "dmesg" and stoppage. It never varies by more than a few (10-15) characters. Interestingly enough, characters are still echoed between stoppage and return to bash. I wouldn't blame the cable or the remote computer, though, as I've tried using an entirely different computer complete with different OS as the terminal, with precisely the same behavior. I've also used the cable between the two other computers, in which it works correctly. (The kernel used in which it works correctly is 2.2.14 on an RH 5.2 system.) I hope I've given you enough information to make a useful evaluation, and hopefully a fix. If I've left something out, please ask, and I'll be happy to give you whatever I can. I'm also willing to try out possible fixes. Thanks -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: ov511 problem
ov511 supports compression, but it doesn't always work yet. Even with compression, you will only get 12-15 FPS at 640x480 at most. USB just can't do better than that with this type of compression algorithm. If you want to try compression, use the "compress=1" and "ttpp=1" parameters with the ov511 1.35 module. You will likely get garbage, but this will give you an idea of what the frame rate will be like once I have it working. Erik Gustavsson wrote: > On Thu, 5 Apr 2001, Thomas Speck wrote: > > IIRC the driver doesn't support compression, and there is no way you can > get 640x480 uncompressed at 30 fps over USB... > > > I am trying to get working a Spacec@m 300 (USB) by Trust. I tried this > > under 2.2.18 and 2.4.3. In order to get the camera detected I can use the > > usb-uhci or uhci module (the result is the same). The camera gets detected > > (some OV7610 gets probed - I don't know if this is the correct one) and > > after loading the ov511 module I get the picture of the camera displayed > > with xawt-3.38 (resolution 640x480 - the camera is able to this). > > The problem I am running into is that the framerate is extremely slow > > (maybe 3 fps), however, from the specifications it should work with 30 > > fps. My system is a Pentium II with 300 Mhz. Some Miro TV card with a > > BT848 chip works fine with the bttv driver. > > Do you have any idea ? > > If you need more info, just let me know. I am also willing to do some > > tests... -- Mark McClelland [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/
2.4.3 fails to boot with initrd - solved
PROBLEM: kernel 2.4.3 will not boot on systems with initrd files DESCRIPTION Building kernel 2.4.3 and attempting to boot it failed. The problem turned out to be in the modutils-2.4.5 rpm for i386. DETAIL After building the 2.4.3 kernel and moving the boot modules to the initrd image, it was noted the the system stopped when trying to load modules for the root filesystem device. First solution attempted was to get the i386 rpm from kernel.org for the latest (2.4.5) modutils and install, copying the insmod program to the initrd image. This fails, with the message "insmod: no such program" at boot. Examination showed that the binary provided was not static linked. Got the source from kernel.org and built. By default this still isn't static linked! Changed the common Makfile to set LDFLAGS to "-static -s" and built again. After install and copy to initrd image this resulted in a bootable system. While it is possible to copy the libraries needed to the initrd image, it becomes larger than the default ramdisk size (at least on my system). And including the drivers in the kernel hurts portability and makes the kernel too large to boot from floppy. SYSTEMS AFFECTED Redhat 7.x and similar using configurations which have the root device driver loaded from modules. SUGGESTED FIX None needed, but the kernel "Changes" file should include a note that people using initrd will need to rebuild them static along with the note that a newer modutils is needed. Even for people who build their own initrd files, this is NOT obvious! -- bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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: syslog insmod please!
On Thu, 5 Apr 2001 17:57:48 -0700 (PDT), Andrew Daviel <[EMAIL PROTECTED]> wrote: > Is there a good reason why insmod should not call syslog() to log > any module that gets installed ? Simple: you'll have quite a bit of a problem if you are trying to insmod the module with support for AF_UNIX sockets. :-) Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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: gcc-2.95.3
You should be ok :) On Fri, 6 Apr 2001, Jeff Chua wrote: > > Does anybody have bad experience with gcc-2.95.3? > > I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. > > > Thanks, > Jeff > [ [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/ > > - 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: [WISHLIST] Addition of suspend patch into 2.5?
Hi! > > Any idea if suspend/hybernation will be in future kernels? > > I'd like it included, too. Some toshiba laptops support sleep but not > suspend, and battery runs out within few hours if it was low before > suspend. That's bad. > > And the patch was pretty clean last time I checked. > Pavel Clean? I think it is impossible to write hibernation properly without adding suspend/resume hooks to all drivers. And I doubt anybody is able to do it. If we don't rewrite all drivers, hibernation will be just a 'cool feature' that doesn't work most time. Mikulas - 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/
syslog insmod please!
Is there a good reason why insmod should not call syslog() to log any module that gets installed ? I know things like bttv get very verbose in the module itself, and I tried patching insmod to log the first argument and it seemed to work for me. I was looking at the knark LKM rootkit and wondering how to detect this beast. Typically it seemss one does "insmod knark.o" then maybe "insmod modhide.o" to prevent it showing in /proc/modules (seems to remove the last loaded module from a linked list if I read it aright). Adding a syslog call to the insmod binary might get this logged on a remote host with a bit of luck. On a more esoteric note, how would one detect that this kind of module has been installed (modhide) ? I presume one could dive into /dev/mem or load another module to go look, but I've no idea where to start. -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 [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/
gcc-2.95.3
Does anybody have bad experience with gcc-2.95.3? I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. Thanks, Jeff [ [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: a quest for a better scheduler
Timothy D. Witham wrote : [...] > I propose that we work on setting up a straight forward test harness > that allows developers to quickly test a kernel patch against > various performance yardsticks. [... (proposed large server testbeds) ...] I like this idea, but could the testbeds also include some resource-constrained "embedded" or appliance-style systems, and include performance yardsticks for latency and responsiveness? It would be unfortunate if work on a revised scheduler resulted in Linux being a monster web server on 4-way systems, but having lousy interactive performance on web pads, hand helds, and set top boxes. How about a 120Mhz Pentium with 32MB of RAM and a flash disk, a 200 Mhz PowerPC with 64 MB? Maybe a Transmeta web pad? For the process load, something that tests responsiveness and latency - how about a set of processes doing multicast network transfers, CPU-intensive MPEG video and audio encode / decode, and a test app that measures "user response", i.e. if X Windows was running, would the mouse pointer move smoothly or jerkily? The "better" scheduler for these applications would make sure that multicast packets were never dropped, the MPEG decode never dropped frames, and the "user interface" stayed responsive, etc. Also, I would not mind a bit if the kernel had tuning options, either in configuration or through /proc to adjust for these very different situations. Torrey Hoffman [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: [Problem] 3c90x on 2.4.3-ac3
On Thu, Apr 05, 2001 at 11:40:36AM -0700, Grover, Andrew wrote:
> I'm confused. 3c59x.c has a little acpi WOL stuff, but that's it.
I tried "#ifdef 0"-ing the set_WOL function body( empty function ) in
3c59x.c and enabled acpi and built another kernel
and I still have the problem.
So its NOT a problem with the ACPI code in 3c59x.c per se.
I noticed that the following message was from net/core/netfilter.c( i
got this message on running dhclient )
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
so i diabled netfilter also, and I still had the issue.
I assigned a static IP. ifconfig showed me the right info.
"route" however froze most of the times. I have 2 routes
172.16.12.0 * 255.255.252.0 U 0 00 eth0
default 172.16.12.1 0.0.0.0 UG0 00 eth0
It would freeze after the first one most often. If it did'nt, do a ping www.google.com,
which will drop all the packets, and try route again, and it would freeze after the
first route.
I strace'd route and noticed that I was waiting on "poll". I have attached the strace
info on route.
>
> What specifically is ACPI doing to break things? Are ACPI and the NIC
> sharing any resources?
I dont know about sharing resources. I have attached my dmesg.
The whole thing works like a charm under APM however.
I'm gonna try increasing vortex_debug level to see what happens.
would be glad to furnish more info...
-Prasanna Subash
[EMAIL PROTECTED]
>
> Regards -- Andy
>
> > -Original Message-
> > From: Prasanna P Subash [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, April 05, 2001 11:12 AM
> > To: Marcus Meissner
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [Problem] 3c90x on 2.4.3-ac3
> > Importance: High
> >
> >
> > Thats right. ACPI was what made 3c90x not work :( With APM it
> > works perfectly.
> >
> > Thanks Marcus.
> >
> > On Thu, Apr 05, 2001 at 10:14:56AM +0200, Marcus Meissner wrote:
> > > In article <[EMAIL PROTECTED]> you wrote:
> > >
> > > > hi lkml,
> > > > I just built 2.4.3-ac3 with my old 2.4.2 .config and
> > somehow networking does not work.
> > > > dhclient eventually froze the machine.
> > >
> > > > here is what dhclient complains.
> > >
> > > > [root@psubash linux]# cat /tmp/error.txt
> > > > skb: pf=2 (unowned) dev=lo len=328
> > > > PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0
> > F=0x T=16
> > > > DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 14
> > > > ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> > > > skb: pf=2 (unowned) dev=lo len=328
> > > > PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0
> > F=0x T=16
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
> > > > DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 12
> > > > ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> > > > skb: pf=2 (unowned) dev=lo len=328
> > >
> > > > Here is my ver_linux info
> > >
> > > ...
> > > > CONFIG_ACPI=y
> > >
> > > The ACPI powermanagement for the 3c59x devices appears to
> > be a bit broken.
> > >
> > > Disable ACPI support. Recompile. Reboot. Watch problem
> > disappear hopefully.
> > >
> > > Ciao, Marcus
> > -
> > 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/
> >
execve("/sbin/route", ["route"], [/* 26 vars */]) = 0
brk(0) = 0x80527a8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=33735, ...}) = 0
old_mmap(NULL, 33735, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=5173447, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\215\1"..., 4096) = 4096
old_mmap(NULL, 947548, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000
mprotect(0x400fd000, 30044, PROT_NONE) = 0
old_mmap(0x400fd000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xdf000) =
0x400fd000
old_mmap(0x40101000, 13660, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x40101000
close(3)= 0
mprotect(0x4001d000, 917504, PROT_READ|PROT_WRITE) = 0
mprotect(0x4001d000, 917504, PROT_READ|PROT_EXEC) = 0
munmap(0x40014000, 33735) = 0
personality(PER_LINUX) = 0
getpid()= 490
brk(0) = 0x80527a8
brk(0x80527c8) = 0x80527c8
brk(0x8053000) = 0x8053000
open("/proc/net/route", O_RDONLY) = 3
fstat64(1, {st_mode=S_IFCHR|0600,
Re: [CHECKER] 3 kmalloc underallocation bugs
Andrรฉ Dahlqvist wrote: > > Dawson Engler <[EMAIL PROTECTED]> wrote: > > enclosed are three bugs found in the 2.4.1 kernel by an extension > > Why are you guys running these tests against an already old kernel? > I would suggest running it against at least Linus' latest version, or > preferably Alan's -ac tree. At least the two bugs in emu10k1/midi.c still exist in 2.4.3. Just because 2.4.3 is a later version, doesn't mean all the bugs are fixed from earlier versions. -Jeff -- Jeff Golds [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: [CHECKER] 15 potential pointer dereference errors in 2.4.3
Andy Chou wrote: > [BUG] > /u2/acc/oses/linux/2.4.3/drivers/net/tokenring/tmsisa.c:274:tms_isa_probe: >ERROR:NULL:273:274: Using > unknown ptr "card" illegally! set by 'kmalloc':273 fixed > [BUG] > /u2/acc/oses/linux/2.4.3/drivers/pcmcia/rsrc_mgr.c:199:do_io_probe: >ERROR:NULL:191:199: Using > unknown ptr "b" illegally! set by 'kmalloc':191 fixed -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: [CHECKER] 3 kmalloc underallocation bugs
Dawson Engler <[EMAIL PROTECTED]> wrote: > enclosed are three bugs found in the 2.4.1 kernel by an extension Why are you guys running these tests against an already old kernel? I would suggest running it against at least Linus' latest version, or preferably Alan's -ac tree. -- Andrรฉ Dahlqvist <[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: "linux" terminal type
On Thu, Apr 05, 2001 at 08:36:27PM +0200, Ralf Baechle wrote: > Somebody reminded me in private email that we finally have a reasonable > console documentation in console_codes(4). To me "finally" sounds as if this happy state was achieved only recently. But console_codes.4 is from Mon Oct 31 22:13:04 1996. - 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: a quest for a better scheduler
Exellent idea Assuming that you have set up these environments already, what would be a real treat is to get the average runqueue length at a given time, for instance every second or so, while running some of these more sophisticated server oriented applications that you mention. >From that we can see which of the various assumption regarding runqueue length is holding up, when the runqueue is not empty. This would help the current discussion trememdously as we don't seem to be able to even agree on this. Simple bincount could do. If you want a kernel patch that counts every scheduling cycle I'll write it. Hubertus Franke Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) , OS-PIC (Chair) email: [EMAIL PROTECTED] (w) 914-945-2003(fax) 914-945-4425 TL: 862-2003 "Timothy D. Witham" <[EMAIL PROTECTED]>@vger.kernel.org on 04/05/2001 06:38:41 PM Sent by: [EMAIL PROTECTED] To: Linux Kernel List <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: a quest for a better scheduler I have been following this thread and thinking that everybody has some truth in what they are saying but with the absence of a repeatable test environment there really isn't a way of arriving at a data driven decision. Given the following conditions. 1)The diversity of the problem sets that developers are working on results in a real concern that another developers solution to their performance issue might result in a worsening of my performance situation. 2)Most of the developers have a given set of tests that they use when they make changes to determine if they change did what they want. 3)The Open Source Development Lab has the faculties for providing a large scale testing environment on several different configurations that remain the same over time. I propose that we work on setting up a straight forward test harness that allows developers to quickly test a kernel patch against various performance yardsticks. If we use the same set of hardware for the generation of the performance data from patch to patch there will be a correlation between the runs allowing for a real comparison of the different changes. The following should be taken only as a starting point. As for the base hardware configurations I propose: 2 way with 1 GB main memory and 2 IDE drives 4 way with 4 GB main memory and 16 disk drives 8 way with 8 GB main memory and 24 disk drives The types of applications that I have heard people express concern are: Web infrastructure: Apache TUX Jabber Corporate infrastructure: NFS raw TCP/IP performance Samba Database performance: Raw storage I/O performance OLTP workload General usage: compile speed (usually measured by kernel compile) The OSDL also has the ability to make some of the "for fee" benchmarks available for use for testing that is done onsite (network access to OSDL machines counts as onsite) so that people don't have to purchase individual copies. Things like SECMAIL2001, SPECSFS2.0 and SEPCWEB99 come to mind. Comments, suggestions, volunteers? -- Timothy D. Witham - Lab Director - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006 (503)-626-2455 x11 (office)(503)-702-2871 (cell) (503)-626-2455 (fax) On Wed, Apr 04, 2001 at 03:54:54PM -0700, Christopher Smith wrote: > --On Wednesday, April 04, 2001 15:16:32 -0700 Tim Wright <[EMAIL PROTECTED]> > wrote: > > On Wed, Apr 04, 2001 at 03:23:34PM +0200, Ingo Molnar wrote: > >> nope. The goal is to satisfy runnable processes in the range of NR_CPUS. > >> You are playing word games by suggesting that the current behavior > >> prefers 'low end'. 'thousands of runnable processes' is not 'high end' > >> at all, it's 'broken end'. Thousands of runnable processes are the sign > >> of a broken application design, and 'fixing' the scheduler to perform > >> better in that case is just fixing the symptom. [changing the scheduler > >> to perform better in such situations is possible too, but all solutions > >> proposed so far had strings attached.] > > > > Ingo, you continue to assert this without giving much evidence to back it > > up. All the world is not a web server. If I'm running a large OLTP > > database with thousands of clients, it's not at all unreasonable to > > expect periods where several hundred (forget the thousands) want to be > > serviced by the database engine. That sounds like hundreds of schedulable > > entities be they processes or threads or whatever. This sort of load is > > regularly run on machine with 16-64 CPUs. > > Actually, it's not just OLTP, anytime you are doing time sharing between > hundreds of users (something POSIX systems are supposed to be good at) this > will happen. > > > Now I will admit that it is conceivable that you can design an >
Parport probe
Hi all. Ok, maybe this isn't the right list for this question. In 2.2.x the parport_probe module extracted the ieee1284 device id correctly and added to the proc fs. However this doesn't seem to work for me in 2.4.x I only have one device to test it on and since I know there have been some difficulties regarding the device string's length bytes etc I post my device_id string here the first two bytes says that length is 96 and the following is the string "MFG:Winbond;MDL:SA5459B;CLS:DIGCAM;DES:Winbond's DIGCAM driver can not be found in the system;" I have tested to build, parport, parport_pc and ieee1284 both as modules and static into the kernel. Is there some option I need to enable. As far as I understand the CONFIG_PARPORT_1284 should be enough?? Bye Jakob - 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: ufs fs at 2.2.x and 2.4.x
Why is it that 2.2.x UFS write support is considered (experimental)? -Andrew On Sun, 17 Sep 2000 [EMAIL PROTECTED] wrote: > > > FWIW, I downloaded install 'floppyC28.fs' from openbsd web site. > > > > OK. So did I. > > > > % md5sum floppyC28.fs > > 2ae3c61008df5accdfb132f20e744bfb floppyC28.fs > > same here.. > [root@pepsi openbsd]# md5sum floppyC28.fs > 2ae3c61008df5accdfb132f20e744bfb floppyC28.fs > > > > > mount /dev/fd0 /mnt -t ufs -o ufstype=44bsd,ro > > > > OK. So did I. Afterwards: > > > > % ls -l /mnt > > total 1332 > > -r-xr-xr-x 1 root root53248 Sep 12 13:18 boot > > -rw-r--r-- 1 root root 1301229 Sep 12 13:18 bsd > > still problems... > > [root@pepsi /]# df /mnt > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/fd0 1407 133275 95% /mnt > [root@pepsi /]# mount /mnt > [root@pepsi /]# mount | grep mnt > /dev/fd0 on /mnt type ufs (ro,ufstype=44bsd) > > [root@pepsi /]# ls /mnt > [root@pepsi /]# dmesg | tail -3 > UFS-fs error (device 02:00): ufs_readdir: bad entry in directory #2, size > 512: reclen is too small for namlen - offset=0, inode=2, reclen=12, > namlen=260 > UFS-fs error (device 02:00): ufs_readdir: bad entry in directory #2, size > 512: reclen is too small for namlen - offset=0, inode=2, reclen=12, > namlen=260 > UFS-fs error (device 02:00): ufs_readdir: bad entry in directory #2, size > 512: reclen is too small for namlen - offset=0, inode=2, reclen=12, > namlen=260 > > > > This was Linux version 2.4.0-test8 (aeb@mette) (gcc version 2.95.2 19991024 >(release)) > > So, questions: > > 1. Are we talking about the same file (same md5sum)? > > yes. > > > 2. Do things improve with 2.4.0-test8? > > Will try it ... sometime. not right now though.. > > (obtw: i can mount /mnt multiple times.. ) > > [root@pepsi /]# umount /mnt > [root@pepsi /]# mount /dev/fd0 /mnt -t ufs -o ufstype=44bsd,ro > [root@pepsi /]# mount /dev/fd0 /mnt -t ufs -o ufstype=44bsd,ro > [root@pepsi /]# mount /dev/fd0 /mnt -t ufs -o ufstype=44bsd,ro > /dev/fd0 on /mnt type ufs (ro,ufstype=44bsd) > /dev/fd0 on /mnt type ufs (ro,ufstype=44bsd) > /dev/fd0 on /mnt type ufs (ro,ufstype=44bsd) > > Is this feature? > > - 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/
APIC errors ...
Hi, lately having upgraded my DUal-BX motherboard to two PIII-850 CPUs, I run into some trouble. FIrst, I had had an assymetric configuration (iPIII-850 + iPII-350) , which Linux did not support; I created a fix and sent it to LKML. It worked perfectly, i.e. without the problems described below. Now, I have two iPIII-850, but I run into different kind of troubles: (a) The BIOS will sometimes not recognize the second CPU (b) Linux reports APIC errors and occasionally stops to process IRQs on the second CPU or crashes (2.4.x kernel). Some details: DFI P2XBL/D, i440BX, BIOS Award mid 2000 (MPS 1.4), microcode patches end 2000 patched into BIOS (which yields the rev. 08 for my pIII (868)). The board is unable to supply the needed 1.7V for the CPUs, therefore the Slot Adapter (from PowerLeap) contains voltage regulators and VID is faked to 2.2V. The mainboard by specs supports up to 800MHz (max multiplier 8 with FSB 100MHz). The config should be fine; the nmultipliers are fixe anyway nowadays. However: (a) If I explicitly specify 100, 103 or 112 MHz FSB freq., the second CPU is not recognized by the BIOS (and subsequently not by Linux) most of the times. If set to automatic (yields 100MHz), it always recognizes the 2nd CPU. Strange! Setting 83, 75, or 66 MHz FSB, the 2nd CPU is recognized as well. (b) The 2.2.16 kernel seems to be happy (did not run long enough to really check stability), but the 2.4.x kernels reports lots of APIC errors. Lots is smth in between 1/minute (almost idle computer) and more than 1/second (gears Meas demo running). After some time, eventually the 2nd CPU does not get IRQs any more; I've even seen some lockups (after a day or so) of Linux, which I'm not used to :-( Going back to 83/75/66 MHz FSB seems to also solve this problem, but is not considered a solution by me. Here's some excerpt: (dmesg) APIC error on CPU1: 02(02) APIC error on CPU0: 01(01) APIC error on CPU1: 02(02) APIC error on CPU0: 01(05) APIC error on CPU1: 02(02) unexpected IRQ trap at vector d0 unexpected IRQ trap at vector 88 APIC error on CPU1: 02(02) APIC error on CPU0: 05(01) APIC error on CPU1: 02(02) APIC error on CPU0: 01(01) APIC error on CPU1: 02(02) APIC error on CPU0: 01(01) APIC error on CPU0: 01(01) APIC error on CPU1: 02(02) APIC error on CPU0: 01(01) pckurt:~ # cat /proc/interrupts CPU0 CPU1 0:51805222357505IO-APIC-edge timer 1: 24284 15803IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 2 0IO-APIC-edge 4: 0 2IO-APIC-edge serial 5: 35031 27240IO-APIC-edge snd-card-als100 - DSP 6: 1 2IO-APIC-edge 7: 2 0IO-APIC-edge parport0 8: 0 1IO-APIC-edge rtc 10: 1 0IO-APIC-edge snd-card-als100 - MPU-401 12: 5124 5959IO-APIC-edge PS/2 Mouse 14: 18953 18258IO-APIC-edge ide0 17: 21728 20208 IO-APIC-level eth0 18: 23418 22327 IO-APIC-level sym53c8xx 19: 9553 9442 IO-APIC-level aic7xxx, bttv 28: 0 13none 136: 0 35none 140: 0 3none 152: 0 1none 156: 0 2none 160: 0 2none 172: 0 14none 200: 0 1none 204: 0 2none 208: 0 13none NMI: 0 0 LOC:75387667538742 ERR:777 (Note that I patched the IRQ reporting stuff, so you can get a count for bogus IRQ vectors.) The AGP slot (MGA400) is mapped to IRQ16. (Not visible above.) As you can see, the APIC on CPU1 seems eems to suffer under noise! It gets APIC errors (which it acknowledges and causes CPU0 to also get an error) and occasionally receives bogus IRQ vectors. So this looks like a HW problem. Some reports on LKML seem to indicate that this is indeed the case. Somebody is talking about the voltage regulators not giving a really stable voltage (without load?) causing the noise. A resistor with a capacitor should help then ... However, sensors reports 2.20V without any flakiness. Any details on this known? It could also be that the MoBo chipset (IO-APIC?) has problems to recognize the signals from 1.7V CPUs expecting at least 1.8 (or 2.2) V. Maybe faking the VID to 2.0V instead of 2.2V would be useful then. I would be thankful for any knowledge on this issue! (As this is slightly off-topic, you may reply via PM. If I happen to solve my problems, I'll post a summary to LKML.) Regards, -- Kurt Garloff <[EMAIL PROTECTED]> [Eindhoven, NL] Physics: Plasma simulations <[EMAIL PROTECTED]> [TU Eindhoven, NL] Linux: SCSI, Security
[CHECKER] 3 kmalloc underallocation bugs
enclosed are three bugs found in the 2.4.1 kernel by an extension
that checks that kmalloc calls allocate enough memory. It examines all
callsites of the form:
p = [kv]malloc(nbytes);
and issues an error if
sizeof *p < nbytes
I think they're all currently harmless because of kmalloc & friends
exuberant approach to padding.
Dawson
drivers/sound/emu10k1/midi.c
drivers/telephony/ixj.c
-
[BUG] should allocate sizeof *midihdr
/u2/engler/mc/oses/linux/2.4.1/drivers/sound/emu10k1/midi.c:59:midiin_add_buffer
: ERROR:SIZE-CHECK:59:59: midihdr = 'kmalloc'(4 bytes), need 32
static int midiin_add_buffer(struct emu10k1_mididevice *midi_dev, struct midi_hd
r **midihdrptr)
{
struct midi_hdr *midihdr;
Error --->
if ((midihdr = (struct midi_hdr *) kmalloc(sizeof(struct midi_hdr *), GF
P_KERNEL)) == NULL) {
ERROR();
return -EINVAL;
}
-
[BUG] same
/u2/engler/mc/oses/linux/2.4.1/drivers/sound/emu10k1/midi.c:331:emu10k1_midi_wri
te: ERROR:SIZE-CHECK:331:331: midihdr = 'kmalloc'(4 bytes), need 32
struct midi_hdr *midihdr;
ssize_t ret = 0;
unsigned long flags;
DPD(4, "emu10k1_midi_write(), count=%x\n", (u32) count);
if (pos != >f_pos)
return -ESPIPE;
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;
Error --->
if ((midihdr = (struct midi_hdr *) kmalloc(sizeof(struct midi_hdr *), GF
P_KERNEL)) == NULL)
return -EINVAL;
-
[BUG] should be sizeof(IXJ_FILTER_CADENCE) as with the copy_from_user
/u2/engler/mc/oses/linux/2.4.1/drivers/telephony/ixj.c:4511:ixj_build_filter_cad
ence: ERROR:SIZE-CHECK:4511:4511: lcp = 'kmalloc'(12 bytes), need 32
... DELETED 7 lines ...
IXJ_FILTER_CADENCE *lcp;
IXJ *j = [board];
Error --->
lcp = kmalloc(sizeof(IXJ_CADENCE), GFP_KERNEL);
if (lcp == NULL)
return -ENOMEM;
if (copy_from_user(lcp, (char *) cp, sizeof(IXJ_FILTER_CADENCE)))
return -EFAULT;
-
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: a quest for a better scheduler
I have been following this thread and thinking that everybody has some truth in what they are saying but with the absence of a repeatable test environment there really isn't a way of arriving at a data driven decision. Given the following conditions. 1)The diversity of the problem sets that developers are working on results in a real concern that another developers solution to their performance issue might result in a worsening of my performance situation. 2)Most of the developers have a given set of tests that they use when they make changes to determine if they change did what they want. 3)The Open Source Development Lab has the faculties for providing a large scale testing environment on several different configurations that remain the same over time. I propose that we work on setting up a straight forward test harness that allows developers to quickly test a kernel patch against various performance yardsticks. If we use the same set of hardware for the generation of the performance data from patch to patch there will be a correlation between the runs allowing for a real comparison of the different changes. The following should be taken only as a starting point. As for the base hardware configurations I propose: 2 way with 1 GB main memory and 2 IDE drives 4 way with 4 GB main memory and 16 disk drives 8 way with 8 GB main memory and 24 disk drives The types of applications that I have heard people express concern are: Web infrastructure: Apache TUX Jabber Corporate infrastructure: NFS raw TCP/IP performance Samba Database performance: Raw storage I/O performance OLTP workload General usage: compile speed (usually measured by kernel compile) The OSDL also has the ability to make some of the "for fee" benchmarks available for use for testing that is done onsite (network access to OSDL machines counts as onsite) so that people don't have to purchase individual copies. Things like SECMAIL2001, SPECSFS2.0 and SEPCWEB99 come to mind. Comments, suggestions, volunteers? -- Timothy D. Witham - Lab Director - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006 (503)-626-2455 x11 (office)(503)-702-2871 (cell) (503)-626-2455 (fax) On Wed, Apr 04, 2001 at 03:54:54PM -0700, Christopher Smith wrote: > --On Wednesday, April 04, 2001 15:16:32 -0700 Tim Wright <[EMAIL PROTECTED]> > wrote: > > On Wed, Apr 04, 2001 at 03:23:34PM +0200, Ingo Molnar wrote: > >> nope. The goal is to satisfy runnable processes in the range of NR_CPUS. > >> You are playing word games by suggesting that the current behavior > >> prefers 'low end'. 'thousands of runnable processes' is not 'high end' > >> at all, it's 'broken end'. Thousands of runnable processes are the sign > >> of a broken application design, and 'fixing' the scheduler to perform > >> better in that case is just fixing the symptom. [changing the scheduler > >> to perform better in such situations is possible too, but all solutions > >> proposed so far had strings attached.] > > > > Ingo, you continue to assert this without giving much evidence to back it > > up. All the world is not a web server. If I'm running a large OLTP > > database with thousands of clients, it's not at all unreasonable to > > expect periods where several hundred (forget the thousands) want to be > > serviced by the database engine. That sounds like hundreds of schedulable > > entities be they processes or threads or whatever. This sort of load is > > regularly run on machine with 16-64 CPUs. > > Actually, it's not just OLTP, anytime you are doing time sharing between > hundreds of users (something POSIX systems are supposed to be good at) this > will happen. > > > Now I will admit that it is conceivable that you can design an > > application that finds out how many CPUs are available, creates threads > > to match that number and tries to divvy up the work between them using > > some combination of polling and asynchronous I/O etc. There are, however > > a number of problems with this approach: > > Actually, one way to semi-support this approach is to implement > many-to-many threads as per the Solaris approach. This also requires > significant hacking of both the kernel and the runtime, and certainly is > significantly more error prone than trying to write a flexible scheduler. > > One problem you didn't highlight that even the above case does not happily > identify is that for security reasons you may very well need each user's > requests to take place in a different process. If you don't, then you have > to implement a very well tested and secure user-level security mechanism to > ensure things like privacy (above and beyond the time-sharing).
Re: how to let all others run
On Thu, 5 Apr 2001 12:52:28 -0400 (EDT), Richard B. Johnson <[EMAIL PROTECTED]>
wrote:
> Only an observation:
>
>
> main()
> {
>nice(19);
>for(;;)
>sched_yield();
> }
>
> does...
>
[...]
>
> It consumes 99.1 percent CPU, just spinning.
And, umm, what *exactly* would you expect it to do? It's the only process
consuming cpu, and sched_yield() certainly doesn't yield to the idle
task. So it's basically the same as a "for(;;);" program, except it
spends more time in kernel space and schedules faster when something
else needs the cpu.
It's 100% expected behavior.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
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: Arch specific/multiple Configure.help files?
Rogier Wolff wrote: > I'm not sure if Larry's CML2 has the help for the options near the ^^ ehhhm. That's Eric. Sorry. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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: Arch specific/multiple Configure.help files?
Erik Mouw wrote: > On Thu, Apr 05, 2001 at 07:28:33PM +0200, Johan Adolfsson wrote: > > Would it be a good idea to have support for multiple Configure.help > > files in the config system? > > The main advantage would be that arch specific settings could > > have an arch specific help file as well. > > I don't see why this would be an advantage. IMHO Documentation belongs > in the Documentation tree and configuration documentation belongs in > Configure.help. You almost never read that file yourself, only the > various kernel configure tools read it, and tools don't have a problem > with large files. It's better to have the documentation at a single > point, not scattered around in the kernel tree. Well, the configure help is now "scattered around": The configuration options are in the "configure.in" files, and hte docs for them are somewhere else, even if it's in one large file. I'm not sure if Larry's CML2 has the help for the options near the options or not, but that's how I'd like it to be if I were designing the thing from scratch. (a bit like emacs' functions: there too, you give the help text near the definition of a functions!) Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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: 2.4.3 (and possibly 2.4.2) don't enter S5 (ACPI) on shutdown
> From: Trever L. Adams [mailto:[EMAIL PROTECTED]] > I do have a question that you might be able to answer. > > Since I left the 2.2.x series of kernels, my harddrives never > spin down > now. I do not know what else doesn't sleep. This is the > case with APM > (on a box that doesn't crash from it) as well as ACPI. What could be > the cause? I would like the system to go to sleep as much as > possible > when it is idle. Well, I am not an expert on HD spin-down (yet). Under ACPI it's simple - we don't have the power policy to tell the HDs to standby yet. Under APM, the BIOS should be telling them to do so (I think) so if they're not spinning down, then it's because Linux is accessing the disk. If I recall correctly, syslog and/or atime were involved...? You might try forcing a HD spindown with hdparm's -y option, and see if it stays down, or spins back up for something. > TrevEr Adams ^ Yeah, I noticed that right as I hit Send. Sorry. ;-) Regards -- Andy - 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: 2.0.39 oopses in sys_new(l)stat
On Thu, Apr 05, 2001 at 06:09:28PM +0300, Ville Herva wrote: > I wonder if there might still be a bug in 2.0.39 sys_new(l)stat. > Today, one of my trustworthy servers crashed (see details below), and > it has actually given me two slightly similar looking oopses before. > > While this might be a hardware problem (I'll run memory test asap), it > seems that the oopses are quite similar and could perhaps be caused by > a kernel bug. > > This is vanilla 2.0.39 (2.0.37 before), gcc-2.7.2.3, Ppro-200, Intel > motherboard etc. It has been very reliable in past. These oopses are > the _only_ problems. It runs qmail, samba, cvs, rsync, apache, pop, > sshd and oracle. All local fs's are plain ext2. > > I hope somebody (with more kernel hacking experience than me) is still > interested in the 2.0.39. I'll be happy to provide any additional > details or try something. The oops will propably be hard to reproduce, > however. I'll look into it. A note, however: the additional oops:es that follow the first one are almost never ever useful, because the system is no longer in a consistent state after the first one. /David, maintainer of the v2.0.xx kernel series _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ov511 problem
On Thu, 5 Apr 2001, Thomas Speck wrote: IIRC the driver doesn't support compression, and there is no way you can get 640x480 uncompressed at 30 fps over USB... /cyr > > Hi > > I am trying to get working a Spacec@m 300 (USB) by Trust. I tried this > under 2.2.18 and 2.4.3. In order to get the camera detected I can use the > usb-uhci or uhci module (the result is the same). The camera gets detected > (some OV7610 gets probed - I don't know if this is the correct one) and > after loading the ov511 module I get the picture of the camera displayed > with xawt-3.38 (resolution 640x480 - the camera is able to this). > The problem I am running into is that the framerate is extremely slow > (maybe 3 fps), however, from the specifications it should work with 30 > fps. My system is a Pentium II with 300 Mhz. Some Miro TV card with a > BT848 chip works fine with the bttv driver. > Do you have any idea ? > If you need more info, just let me know. I am also willing to do some > tests... > > -- > Thomas > > - > 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/ > > > --- Holly: I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. - 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: how to let all others run
On Thu, 5 Apr 2001 [EMAIL PROTECTED] wrote: > > Doesn't even show on `top`. Further, it gets the CPU about 100 times > > a second (HZ). This is normally what you want for something that > > polls, buts needs to give up the CPU so that whatever it's waiting > > for can get done as soon as possible. > > Hi, > > first of all I want to do this in kernel. > I need to do this to prevent a race. To handle removal of a hotpluggable > scsi device. On SMP there's a race between the task blocking the scsi > device and killing obsolete requests and other tasks queueing no requests. > If a task has passed the block before it comes into effect, but the > killing task is done with killing requests before the new request can be > queued the system will oops. > Simply calling the kernel equivalent of sched_yield() is not an option as > the number of runnable tasks can be smaller than the number of CPUs in > which case sched_yield is a nop. > You never mentioned doing things within the kernel. It's a lot easier within the kernel. cd ../linux/drivers/char grep schedule *.c | more This will give an idea of the many options available. In the simpist case, you can spin-lock entry into your code, set a semaphore, then schedule() until it changes. You have down() to do the whole thing, or you can do it yourself as in serial.c: When the last requst to the device has been aborted, your code sets "my_semaphore" to FALSE. You have to do in under the "my_lock" lock to be free of all races. spin_lock_irqsave(_lock, flags); my_semaphore = FALSE; spin_lock_irqrestore(_lock, flags); driver wait-thread does: spin_lock_irqsave(_lock, flags); my_semaphore = TRUE; spin_lock_irqrestore(_lock, flags); set_current_state(TASK_INTERRUPTIBLE); while(my_semaphore == TRUE) schedule(); Note that you can even schedule with the interrupts OFF, but you can't schedule from an interrupt-service routine. There is a difference! Even if queued requests get cleared before you even look at your semaphore, there is no race. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Groups maximum
Stephen Burns wrote: > > Hey all, > > I have checked out the archives, and I found an old post regarding this. > The solution in the post, however, did not work for me. I am attempting to > raise the maximum 32 group per user limit on my 2.4.2 kernel. I patched > both linux/include/linux/limits.h and the asm-i386/param.h, replacing the > default "32" with "256." My glibc is 2.1.2. When I make clean, and > recompile the kernel, it boots fine but I am still limited to 32 groups. I > don't need to do anything with glibc since it is of the 2.1 or greater > category, correct? Any ideas, hints, tricks? Thanks a ton for your help, > please CC me as I've not been approved yet as a member of this list. You gotta change the task struct... -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: [CHECKER] 15 potential pointer dereference errors in 2.4.3
Here's one more potential bug for 2.4.3.
-Andy
[BUG]
/u2/acc/oses/linux/2.4.3/drivers/isdn/hysdn/hysdn_net.c:309:hysdn_net_create:
ERROR:NULL:302:309: Using
NULL ptr "dev" illegally! set by 'kmalloc_Rsmp_93d4cfe6':302
Start --->
if ((dev = kmalloc(sizeof(struct net_local), GFP_KERNEL)) ==
NULL) {
printk(KERN_WARNING "HYSDN: unable to allocate mem\n");
if (card->debug_flags & LOG_NET_INIT)
return (-ENOMEM);
}
memset(dev, 0, sizeof(struct net_local)); /* clean the structure
*/
Error --->
spin_lock_init(&((struct net_local *) dev)->lock);
-
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: how to let all others run
> Doesn't even show on `top`. Further, it gets the CPU about 100 times > a second (HZ). This is normally what you want for something that > polls, buts needs to give up the CPU so that whatever it's waiting > for can get done as soon as possible. Hi, first of all I want to do this in kernel. I need to do this to prevent a race. To handle removal of a hotpluggable scsi device. On SMP there's a race between the task blocking the scsi device and killing obsolete requests and other tasks queueing no requests. If a task has passed the block before it comes into effect, but the killing task is done with killing requests before the new request can be queued the system will oops. Simply calling the kernel equivalent of sched_yield() is not an option as the number of runnable tasks can be smaller than the number of CPUs in which case sched_yield is a nop. Regards Oliver - 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: 2.4.3 (and possibly 2.4.2) don't enter S5 (ACPI) on shutdown
Grover, Andrew wrote: >> From: Trever L. Adams [mailto:[EMAIL PROTECTED]] >> 2.4.3 no longer shuts down automatically with S5. >> >> [2.] Full description of the problem/report: >> >> 2.4.3 no longer shuts down automatically with S5. I have an Athlon >> based system using the FIC-SD11 motherboard. In 2.4.1 and possibly >> 2.4.2 the system used to shut down just fine. > > > This is the most likely culprit. Trevor please let me know if this does it: > > --- linux/drivers/acpi/hardware/hwsleep.c.origFri Feb 9 11:45:58 2001 > +++ linux/drivers/acpi/hardware/hwsleep.c Thu Apr 5 12:11:54 2001 > @@ -179,8 +179,6 @@ > > acpi_hw_register_write(ACPI_MTX_LOCK, PM1_a_CONTROL, PM1_acontrol); > acpi_hw_register_write(ACPI_MTX_LOCK, PM1_b_CONTROL, PM1_bcontrol); > - acpi_hw_register_write(ACPI_MTX_LOCK, PM1_CONTROL, > - (1 << acpi_hw_get_bit_shift (SLP_EN_MASK))); > > enable(); Thank you Andrew. This fixed it perfectly. I wish I understood what the different PM controls were, but it sure did the trick. I do have a question that you might be able to answer. Since I left the 2.2.x series of kernels, my harddrives never spin down now. I do not know what else doesn't sleep. This is the case with APM (on a box that doesn't crash from it) as well as ACPI. What could be the cause? I would like the system to go to sleep as much as possible when it is idle. TrevEr Adams - 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: Config printk buffer size
Alan Cox wrote:
>
> Looks ok to me but given the ability of the average kernel hacker to read
> help texts I;d rather it was a choice menu of say
OK, I guess I gave too much credit :)
This gives 4 options, 4K, 8K, 16K, and 32K.
4K is for the embedded guys, but they might want even less.
32K is enought for 9 RAID1 and RAID0 volumes.
64K seams like overkill too me. But if anyone wants/needs it,
I'll add it in. Same for smaller buffers.
Now to work on using a boot param, and reducing after
booting with dmesg. That'll take me a while I'm sure.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/Documentation/Configure.help
linux-2.4.3-ac2/Documentation/Configure.help
--- linux-2.4.3-ac2.orig/Documentation/Configure.help Wed Apr 4 15:22:43 2001
+++ linux-2.4.3-ac2/Documentation/Configure.helpThu Apr 5 14:12:00 2001
@@ -15192,6 +15192,14 @@
keys are documented in Documentation/sysrq.txt. Don't say Y unless
you really know what this hack does.
+Printk buffer size
+CONFIG_PRINTK_BUF_LEN_4K
+ Printk buffer size in K bytes.
+ The 2.2.x kernels used a default of 8. The 2.4.x kernels
+ use a default of 16. Systems with many Software-RAID volumes
+ should increase since the md.o drivers have a lot of printk
+ output during boot.
+
ISDN subsystem
CONFIG_ISDN
ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/config.in
linux-2.4.3-ac2/arch/alpha/config.in
--- linux-2.4.3-ac2.orig/arch/alpha/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/alpha/config.inThu Apr 5 10:53:07 2001
@@ -361,7 +361,11 @@
fi
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
-
bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
+choice 'Printk buffer size (in K bytes)' \
+ "4K CONFIG_PRINTK_BUF_LEN_4K \
+8K CONFIG_PRINTK_BUF_LEN_8K \
+16KCONFIG_PRINTK_BUF_LEN_16K \
+32KCONFIG_PRINTK_BUF_LEN_32K" 16K
endmenu
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/defconfig
linux-2.4.3-ac2/arch/alpha/defconfig
--- linux-2.4.3-ac2.orig/arch/alpha/defconfig Wed Apr 4 15:12:44 2001
+++ linux-2.4.3-ac2/arch/alpha/defconfigThu Apr 5 10:58:14 2001
@@ -635,3 +635,7 @@
CONFIG_MATHEMU=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_ALPHA_LEGACY_START_ADDRESS=y
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/config.in
linux-2.4.3-ac2/arch/arm/config.in
--- linux-2.4.3-ac2.orig/arch/arm/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/arm/config.in Thu Apr 5 10:53:20 2001
@@ -414,6 +414,7 @@
bool 'Verbose user fault messages' CONFIG_DEBUG_USER
bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+
if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
fi
@@ -427,4 +428,10 @@
fi
fi
fi
+
+choice 'Printk buffer size (in K bytes)' \
+ "4K CONFIG_PRINTK_BUF_LEN_4K \
+8K CONFIG_PRINTK_BUF_LEN_8K \
+16KCONFIG_PRINTK_BUF_LEN_16K \
+32KCONFIG_PRINTK_BUF_LEN_32K" 16K
endmenu
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k
linux-2.4.3-ac2/arch/arm/def-configs/a5k
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/a5kThu Apr 5 11:09:28 2001
@@ -534,3 +534,7 @@
CONFIG_MAGIC_SYSRQ=y
CONFIG_NO_PGT_CACHE=y
CONFIG_DEBUG_LL=y
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet
linux-2.4.3-ac2/arch/arm/def-configs/assabet
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/assabetThu Apr 5 11:09:02 2001
@@ -567,3 +567,7 @@
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/brutus
linux-2.4.3-ac2/arch/arm/def-configs/brutus
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/brutusMon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/brutus Thu Apr 5 11:08:49 2001
@@ -294,3 +294,7 @@
CONFIG_DEBUG_INFO=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
Re: [SOLVED]Re: 2.2.19 && ppa: total lockup. No problem with 2.2.17
Tim Waugh escribiรณ: > > On Wed, Apr 04, 2001 at 12:59:33AM +0200, Juan wrote: > > > I have the same problem in two different machines but they both are UP. > > However, my kernel configuration has SMP support enabled. > > Could you build a kernel without SMP support and see if the problem > still happens? Without SMP support, the machine doesn't hang but I can't load the ppa module. See messages below. > > > options parport_pc io=0x378 irq=7 > > You could remove this line, just to see if it makes a difference (it > shouldn't, but it might). I will try this tomorrow. > > > I stop klogd and syslogd services (that causes to display all kernel > > messages on screen, doesn't it? > > Better is something like 'dmesg -n 8'. OK. -- D. Juan Piernas Cรกnovas Departamento de Ingenierรญa y Tecnologรญa de Computadores Facultad de Informรกtica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34968367657Fax: +34968364151 email: [EMAIL PROTECTED] PGP public key: http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index [root@localhost /root]# modprobe ppa ppa: Version 2.07 (for Linux 2.2.x) WARNING - no ppa compatible devices found. As of 31/Aug/1998 Iomega started shipping parallel port ZIP drives with a different interface which is supported by the imm (ZIP Plus) driver. If the cable is marked with "AutoDetect", this is what has happened. scsi : 0 hosts. /lib/modules/2.2.19/scsi/ppa.o: init_module: Device or resource busy Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.2.19/scsi/ppa.o: insmod /lib/modules/2.2.19/scsi/ppa.o failed /lib/modules/2.2.19/scsi/ppa.o: insmod ppa failed There are the following lines in my modules.conf alias scsi_hostadapter ppa alias parport_lowlevel parport_pc options parport_pc io=0x378 irq=7
Re: kernel/sched.c questions
On Wed, Apr 04, 2001 at 04:52:32PM -0300, Sarda?ons, Eliel wrote:
> switch (prev->state) {
> case TASK_INTERRUPTIBLE:
> if (signal_pending(prev)) {
> prev->state = TASK_RUNNING;
> break;
> }
> default:
> del_from_runqueue(prev);
> case TASK_RUNNING:
> }
I'm not sure about the other two, but this one is pretty straight
forward: its listed explicitly because we don't want tasks with
p->state TASK_RUNNING to fall into the default case, that is, getting
deleted from the runqueue. This would be bad.
--
-Steven
Freedom is the freedom to say that two plus two equals four.
-
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: Contacts within AMD? AMD-756 USB host-controller blacklisted dueto
Alan Cox wrote:
>
> Since we expect to get errata docs very soon Im not that worried. As an
> implementation I'd rather a module option of 'ignore_blacklist' or similar
> so that it is runtime
This seamed to work here.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c
linux-2.4.3-ac2/drivers/usb/usb-ohci.c
--- linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c Wed Apr 4 15:23:15 2001
+++ linux-2.4.3-ac2/drivers/usb/usb-ohci.c Thu Apr 5 14:02:08 2001
@@ -92,6 +92,10 @@
static LIST_HEAD (ohci_hcd_list);
static spinlock_t usb_ed_lock = SPIN_LOCK_UNLOCKED;
+static int overrideBlacklist = 0;
+MODULE_PARM(overrideBlacklist, "i");
+MODULE_PARM_DESC(overrideBlacklist, " override blacklisted controlers");
+
/*-*
* URB support functions
*-*/
@@ -2333,12 +2337,13 @@
void *mem_base;
/* blacklisted hardware? */
- if (id->driver_data) {
- info ("%s (%s): %s", dev->slot_name,
+ if (overrideBlacklist != 1){
+ if (id->driver_data) {
+ info ("%s (%s): %s", dev->slot_name,
dev->name, (char *) id->driver_data);
return -ENODEV;
+ }
}
-
if (pci_enable_device(dev) < 0)
return -ENODEV;
RE: 2.4.3 (and possibly 2.4.2) don't enter S5 (ACPI) on shutdown
> From: Trever L. Adams [mailto:[EMAIL PROTECTED]] > 2.4.3 no longer shuts down automatically with S5. > > [2.] Full description of the problem/report: > > 2.4.3 no longer shuts down automatically with S5. I have an Athlon > based system using the FIC-SD11 motherboard. In 2.4.1 and possibly > 2.4.2 the system used to shut down just fine. This is the most likely culprit. Trevor please let me know if this does it: --- linux/drivers/acpi/hardware/hwsleep.c.orig Fri Feb 9 11:45:58 2001 +++ linux/drivers/acpi/hardware/hwsleep.c Thu Apr 5 12:11:54 2001 @@ -179,8 +179,6 @@ acpi_hw_register_write(ACPI_MTX_LOCK, PM1_a_CONTROL, PM1_acontrol); acpi_hw_register_write(ACPI_MTX_LOCK, PM1_b_CONTROL, PM1_bcontrol); - acpi_hw_register_write(ACPI_MTX_LOCK, PM1_CONTROL, - (1 << acpi_hw_get_bit_shift (SLP_EN_MASK))); enable(); - 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: How to embed linux into a board based on QED rm5230 mips cpu?
On Thu, 5 Apr 2001, J . A . Magallon wrote: > On 04.05 Miao Qingjun wrote: > > Can anybody help me? > > How to embed linux into a board based on QED rm5230 > > mips cpu? > http://www.uclinux.org/ rm5230 isnt a microcontroller. -Dan - 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/
Groups maximum
Hey all, I have checked out the archives, and I found an old post regarding this. The solution in the post, however, did not work for me. I am attempting to raise the maximum 32 group per user limit on my 2.4.2 kernel. I patched both linux/include/linux/limits.h and the asm-i386/param.h, replacing the default "32" with "256." My glibc is 2.1.2. When I make clean, and recompile the kernel, it boots fine but I am still limited to 32 groups. I don't need to do anything with glibc since it is of the 2.1 or greater category, correct? Any ideas, hints, tricks? Thanks a ton for your help, please CC me as I've not been approved yet as a member of this list. - 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: Arch specific/multiple Configure.help files?
On Thu, Apr 05, 2001 at 07:28:33PM +0200, Johan Adolfsson wrote: > Would it be a good idea to have support for multiple Configure.help > files in the config system? > The main advantage would be that arch specific settings could > have an arch specific help file as well. I don't see why this would be an advantage. IMHO Documentation belongs in the Documentation tree and configuration documentation belongs in Configure.help. You almost never read that file yourself, only the various kernel configure tools read it, and tools don't have a problem with large files. It's better to have the documentation at a single point, not scattered around in the kernel tree. > Anybody who knows: Would it be a easy to add support for this if > this is considered a good idea? Shouldn't be too hard. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: st corruption with 2.4.3-pre4
BTW, my 2.4.3-pre8 kernel just said
| sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).
| sym53c875-0: script cmd = 1100
| sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 21 80 01 09 09 00 30 4e 00 08
|ff ff ff.
| sym53c875-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 16)
during the boot process, and continued without problems. What does this mean?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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/
Userspace TCP sequence number control?
Hello, If there's a forum more specifically dedicated to 2.4 networking, please point me in the right direction, otherwise please consider the following. (I'm on lkml so you don't need to CC: me) Is there a way to set the sequence number sent in the SYN response to an incoming connnection request (an incoming SYN) to a specific value with listen()? It may sound like a security risk, but consider the problem of trying to do http load balancing using 2.4 netfilter, (ie in kernel, packet/conntrack-based) but trying to maintain session affinity to a specific backend server. Clearly, the load balancer must open a http (and thus TCP) connection to determine the client that is connecting, in order to determine which back-end server is already servicing the user session. Typically, from this point on, the load balancer must just copy the data back and forth between the socket connected to the client and another socket. This could be userspace or kernelspace, but it's copying either way. What if the connection could be handed off via DNAT *after* it had been established? The load balancer could establish a connection with the backend server, posing as the client, setup an iptable entry directing the client connection's packets to the backend server, then close it's connection (somehow without sending FIN)... the (big) part missing is that the backend server's sequence number will differ from the one used by the load-balancer. (whereas the load balancer can just copy the last sequence number recieved by the client) Does this functionality exist already? Or can iptables re-write the sequence numbers ? (Cisco's PIX does this to re-randomize them for hosts inside firewall that have poor random number generation) Am I talking crazy talk already? (I know I should research the tunneling method more) Regards, Jeremy - 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: How to embed linux into a board based on QED rm5230 mips cpu?
On 04.05 Miao Qingjun wrote: > Hi, > > Can anybody help me? > > How to embed linux into a board based on QED rm5230 > mips cpu? > http://www.uclinux.org/ -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686 - 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/
2.4.3 (and possibly 2.4.2) don't enter S5 (ACPI) on shutdown
[1.] One line summary of the problem:
2.4.3 no longer shuts down automatically with S5.
[2.] Full description of the problem/report:
2.4.3 no longer shuts down automatically with S5. I have an Athlon
based system using the FIC-SD11 motherboard. In 2.4.1 and possibly
2.4.2 the system used to shut down just fine.
[3.] Keywords (i.e., modules, networking, kernel):
ACPI, S5, acpid-071100
[4.] Kernel version (from /proc/version):
Linux version 2.4.3 (root@aurora) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #4 Sat Mar 31 13:21:44 EST 2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
No oops
[6.] A small shell script or example program which triggers the
problem (if possible)
Simply tell the machine to halt and I get a message saying cannot enter
S5 and the machine stays alive.
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux aurora 2.4.3 #4 Sat Mar 31 13:21:44 EST 2001 i686 unknown
Gnu C 2.96
Gnu make 3.79.1
binutils 2.10.0.18
util-linux 2.10m
modutils 2.3.21
e2fsprogs 1.18
PPP2.3.11
Linux C Library> libc.2.2
Dynamic linker (ldd) 2.2
Procps 2.0.7
Net-tools 1.56
Console-tools 0.3.3
Sh-utils 2.0
acpi daemon acpid-071100
Modules Loaded af_packet agpgart
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 2
model name : AMD Athlon(tm) Processor
stepping : 1
cpu MHz : 798.478
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1592.52
[7.3.] Module information (from /proc/modules):
af_packet 11200 0 (autoclean)
agpgart14640 0 (unused)
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0400-040f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
0cf8-0cff : PCI conf1
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
8000-8fff : PCI Bus #01
c000-c0ff : Symbios Logic Inc. (formerly NCR) 53c875
c000-c07f : sym53c8xx
cc00-ccff : Trident Microsystems 4DWave NX
cc00-ccff : Trident 4DWave NX
d000-d07f : Digital Equipment Corporation DECchip 21140 [FasterNet]
d000-d07f : eth0
d400-d403 : Advanced Micro Devices [AMD] AMD-751 [Irongate] System
Controller
d800-d8ff : Symbios Logic Inc. (formerly NCR) 53c875 (#2)
d800-d87f : sym53c8xx
ffa0-ffaf : VIA Technologies, Inc. Bus Master IDE
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
cat /proc/iomem
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07fe : System RAM
0010-002155f5 : Kernel code
002155f6-00278f37 : Kernel data
07ff-07ff7fff : ACPI Tables
07ff8000-07ff : ACPI Non-volatile Storage
e9c0-e9cf : PCI Bus #01
ea00-ebff : Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller
eddff000-eddf : Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller
ede0-efef : PCI Bus #01
ee80-eeff : Texas Instruments TVP4020 [Permedia 2]
ef00-ef7f : Texas Instruments TVP4020 [Permedia 2]
efee-efef : Texas Instruments TVP4020 [Permedia 2]
efffc000-efffcfff : Symbios Logic Inc. (formerly NCR) 53c875
efffd000-efffdfff : Trident Microsystems 4DWave NX
efffe000-efffefff : Symbios Logic Inc. (formerly NCR) 53c875 (#2)
ed00-edff : Symbios Logic Inc. (formerly NCR) 53c875
ee80-eeff : Digital Equipment Corporation DECchip 21140 [FasterNet]
ee80-eeff : eth0
ef00-efff : Symbios Logic Inc. (formerly NCR) 53c875 (#2)
- : reserved[7.5.] PCI information ('lspci -vvv' as root)
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi1 Channel: 00 Id: 05 Lun: 00
Vendor: NEC Model: CD-ROM DRIVE:464 Rev: 1.05
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: RICOHModel: MP6200S Rev: 2.40
Type: CD-ROM ANSI SCSI revision: 02
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
2.4.3 Easy to make Mozilla go into D State
[1.] One line summary of the problem:
Mozilla and other programs easily get in D State
[2.] Full description of the problem/report:
Mozilla is easy to get into D State. Simply start it 2001040414 build.
This is not the only program that I have doing this. It is just the
easiest to make do it.
[3.] Keywords (i.e., modules, networking, kernel):
D State
[4.] Kernel version (from /proc/version):
Linux version 2.4.3 (root@aurora) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #4 Sat Mar 31 13:21:44 EST 2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
No oops
[6.] A small shell script or example program which triggers the
problem (if possible)
Simply use Mozilla or another large program I suppose.
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux aurora 2.4.3 #4 Sat Mar 31 13:21:44 EST 2001 i686 unknown
Gnu C 2.96
Gnu make 3.79.1
binutils 2.10.0.18
util-linux 2.10m
modutils 2.3.21
e2fsprogs 1.18
PPP2.3.11
Linux C Library> libc.2.2
Dynamic linker (ldd) 2.2
Procps 2.0.7
Net-tools 1.56
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded af_packet agpgart
[7.2.] Processor information (from /proc/cpuinfo):
processor
: 0
vendor_id
: AuthenticAMD
cpu family : 6
model
: 2
model name : AMD Athlon(tm) Processor
stepping
: 1
cpu MHz : 798.478
cache size : 512 KB
fdiv_bug
: no
hlt_bug
: no
f00f_bug
: no
coma_bug
: no
fpu
: yes
fpu_exception
: yes
cpuid level : 1
wp
: yes
flags
: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx
fxsr syscall mmxext 3dnowext 3dnow
bogomips
: 1592.52
[7.3.] Module information (from /proc/modules):
af_packet 11200 0 (autoclean)
agpgart14640 0 (unused)
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0400-040f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
0cf8-0cff : PCI conf1
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
8000-8fff : PCI Bus #01
c000-c0ff : Symbios Logic Inc. (formerly NCR) 53c875
c000-c07f : sym53c8xx
cc00-ccff : Trident Microsystems 4DWave NX
cc00-ccff : Trident 4DWave NX
d000-d07f : Digital Equipment Corporation DECchip 21140 [FasterNet]
d000-d07f : eth0
d400-d403 : Advanced Micro Devices [AMD] AMD-751 [Irongate] System
Controller
d800-d8ff : Symbios Logic Inc. (formerly NCR) 53c875 (#2)
d800-d87f : sym53c8xx
ffa0-ffaf : VIA Technologies, Inc. Bus Master IDE
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
cat /proc/iomem
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07fe : System RAM
0010-002155f5 : Kernel code
002155f6-00278f37 : Kernel data
07ff-07ff7fff : ACPI Tables
07ff8000-07ff : ACPI Non-volatile Storage
e9c0-e9cf : PCI Bus #01
ea00-ebff : Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller
eddff000-eddf : Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller
ede0-efef : PCI Bus #01
ee80-eeff : Texas Instruments TVP4020 [Permedia 2]
ef00-ef7f : Texas Instruments TVP4020 [Permedia 2]
efee-efef : Texas Instruments TVP4020 [Permedia 2]
efffc000-efffcfff : Symbios Logic Inc. (formerly NCR) 53c875
efffd000-efffdfff : Trident Microsystems 4DWave NX
efffe000-efffefff : Symbios Logic Inc. (formerly NCR) 53c875 (#2)
ed00-edff : Symbios Logic Inc. (formerly NCR) 53c875
ee80-eeff : Digital Equipment Corporation DECchip 21140 [FasterNet]
ee80-eeff : eth0
ef00-efff : Symbios Logic Inc. (formerly NCR) 53c875 (#2)
- : reserved[7.5.] PCI information ('lspci -vvv' as root)
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi1 Channel: 00 Id: 05 Lun: 00
Vendor: NEC Model: CD-ROM DRIVE:464 Rev: 1.05
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: RICOHModel: MP6200S Rev: 2.40
Type: CD-ROM ANSI SCSI revision: 02
-
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/
How to embed linux into a board based on QED rm5230 mips cpu?
Hi, Can anybody help me? How to embed linux into a board based on QED rm5230 mips cpu? How can I do step by step? Its configuration is rm5230 cpu galileo controller rom flash ram nvram/rtc uart Thanks in advance. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - 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 BUG at page_alloc.c:75! / exit.c
"Albert D. Cahalan" wrote: > > > I'm running the 2.4.3 kernel and my system always (!) crashes when I try > > to generate the "Linux kernel poster" from lgp.linuxcare.com.au. After > > working for one hour, the kernel printed this message: > > I'd guess you have a heat problem. Check for dust, a slow fan, > an overclocked CPU, memory chips with airflow blocked by cables, > motherboard chips that are too hot to touch... none of the above, but the CPU (Athlon) temperature is at ~65 ยฐC. Is this ok? thanks, Felix - 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: st corruption with 2.4.3-pre4
On Thu, 22 Mar 2001, Geert Uytterhoeven wrote:
> On Tue, 20 Mar 2001, Gรฉrard Roudier wrote:
> > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > I did some more tests:
> > > - The problem also occurs when tarring up files from a disk on the Sym53c875.
> > > - The corrupted data always occurs at offset 32*x (the `+1' above was caused
> > > by hexdump, starting counting at 1).
> > > - The 32 bytes of corrupted data at offset 32*x are always a copy of the data
> > > at offset 32*x-10240.
> > > - Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball
> > > on disk instead of on tape, but no corruption.
> > > - 32 is the size of a cacheline on PPC. Is there a missing cacheflush
> > > somewhere in the Sym53c875 driver? But then it should happen on disk as
> > > well?
>
> BTW, I tried my good old 2.4.0-test1-ac10 kernel from June 2000, and it also
> suffered from the same problem. Also note that I did read/write tests on the
> tape drive when I just bought it and when I installed the Sym53c875 later, and
> I never noticed the problem. So I'm still willing to believe it's a software
> bug in recent(?) kernels...
Status update:
- When I connect my DDS1 to the MESH, I see no corruption (as long as I get
no `lost arbitration' messages from the MESH driver. I never get those with
the disk BTW. Anyone who knows what needs to be done to make the MESH
driver recover from lost arbitration errors?). So the tape drive seems to
be fine.
- I wanted to try different tape drives, but all retired DDS drives I found
at work seem to be in a non-functional state. I tried 3 of them, without
any luck.
- I wanted to try a 2.2.x kernel, but linuxppc_2_2 (2.2.19-pre3) just says
`illegal instruction' and returns me to the OF prompt.
- Adding more eieio/syncs to the sym53c8xx driver doesn't help. In fact there
are already memory barriers where I'd expect them (as could be expected, of
course :-)
[...]
OK, I managed to compile an old 2.2.13 kernel from the PPC bk repository that
boots more or less (no video) on my box.
Surprise! So far no corruption!! Time to let Amanda make some dumps tonight :-)
So something broke the st/sym53c8xx combination on my box between 2.2.13 and
2.4.0-test1-ac10...
I'm still waiting for other reports of st/sym53c8xx on PPC under 2.4.x. BTW,
does it work on other big-endian platforms, like sparc?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: [linux-fbdev] Looking for a card with working TV-out in linux
David Balazic wrote: > > Requirements : > - working TV-out ( S-Video or composite-video ), I mean really working >and supported in linux, not "it works if the BIOS initializes it and >Linux doesn't touch it" G400 (not G450, TVout on G450 is not supported and maybe never will). But you should preffer XF3.3.x over XF4 (and if you are going to use XF4, you must use HAL from Matrox). > - video support ( in HW and linux-SW ) is desired ( color space conversion, >video overlays and stuff ) G400 hardware can do that, but nobody bothered with implementation. > - PCI interface ( I plan later to multihead with another AGP card and also >want to keep the price low ) G400. If you do not need opensource, then Matrox HAL driver can initialize secondary heads from scratch too. > - 3D acceleration welcome ( with XFree86 support ), but not that important G400. > - low price :-) Sorry. Something else than Matrox ;-) Petr Vandrovec [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: [Problem] 3c90x on 2.4.3-ac3
I'm confused. 3c59x.c has a little acpi WOL stuff, but that's it. What specifically is ACPI doing to break things? Are ACPI and the NIC sharing any resources? Regards -- Andy > -Original Message- > From: Prasanna P Subash [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 11:12 AM > To: Marcus Meissner > Cc: [EMAIL PROTECTED] > Subject: Re: [Problem] 3c90x on 2.4.3-ac3 > Importance: High > > > Thats right. ACPI was what made 3c90x not work :( With APM it > works perfectly. > > Thanks Marcus. > > On Thu, Apr 05, 2001 at 10:14:56AM +0200, Marcus Meissner wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > > > > hi lkml, > > > I just built 2.4.3-ac3 with my old 2.4.2 .config and > somehow networking does not work. > > > dhclient eventually froze the machine. > > > > > here is what dhclient complains. > > > > > [root@psubash linux]# cat /tmp/error.txt > > > skb: pf=2 (unowned) dev=lo len=328 > > > PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 > F=0x T=16 > > > DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 14 > > > ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN > > > skb: pf=2 (unowned) dev=lo len=328 > > > PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 > F=0x T=16 > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 > > > DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 12 > > > ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN > > > skb: pf=2 (unowned) dev=lo len=328 > > > > > Here is my ver_linux info > > > > ... > > > CONFIG_ACPI=y > > > > The ACPI powermanagement for the 3c59x devices appears to > be a bit broken. > > > > Disable ACPI support. Recompile. Reboot. Watch problem > disappear hopefully. > > > > Ciao, Marcus > - > 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/ > - 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 bug in 2.4.2-ac28, patched with 6.1.8 aic drivers
On Thu, 5 Apr 2001, John Jasen wrote: > got this on booting up 2.4.2-ac28: > Apr 5 09:36:37 grim kernel: kernel BUG at slab.c:1244! > Apr 5 09:36:37 grim kernel: invalid operand: errr ... belay that one. a) I said I didn't get it in 2.4.3-ac3, which was only about 30% correct. (I've gotten it 7 out of 9 times, since then). and b) it occured on a 2.4.2-ac28 tree without the aic7xxx driver update (which shouldn'tve mattered anyway, in theory) and c) It happened right after webmin (don't ask!) started, and just for giggles, I shut off webmin, rebooted, and -- no more problem. *shrug* -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: "linux" terminal type
On Wed, Apr 04, 2001 at 08:42:32PM -0700, James Simmons wrote: > Also take a look at http://www.vt100.net . Since linux tries to emulate > the Dec vt100 at this site you will find the vt100 manuals. They are quite > good and the esc codes are well described in them. > > MS: (n) 1. A debilitating and surprisingly widespread affliction that > renders the sufferer barely able to perform the simplest task. 2. A disease. Somebody reminded me in private email that we finally have a reasonable console documentation in console_codes(4). Ralf - 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: pcnet32 (maybe more) hosed in 2.4.3
Carsten Langgaard wrote: > > Petr Vandrovec wrote: > > Current Linux driver switches them to 16bit mode in pcnet_probe1: > > > > pcnet_dwio_reset(); // reset to 16bit mode when in 32bit, ignore in > > 16bit mode > > pcnet_wio_reset(); // device is for sure in 16bit mode, but reset it > > again to > I'm afraid that's not true. > The above only do a software reset and that doesn't effect the I/O mode. > Only a hardware reset effects the I/O mode. > An because any firmware might changes to 32bit mode after reset (of the whole > system), we need to support both modes. Oops. I misinterpreted what code does. Really stupid hardware. Thanks, Petr Vandrovec [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/
PROBLEM: buz.c, 6pack.c use nonexistant KMALLOC_MAXSIZE in 2.4.3
[1.] One line summary of the problem:
buz.c, 6pack.c use nonexistant KMALLOC_MAXSIZE in 2.4.3
[2.] Full description of the problem/report:
buz.c:2837: `KMALLOC_MAXSIZE' undeclared (first use in this function)
in kernel-source-2.4.3:
$ find . -name '*.h' | xargs grep KMALLOC_MAXSIZE
$ find . -name '*.c' | xargs grep KMALLOC_MAXSIZE
./drivers/media/video/buz.c: * If v4l_bufsize <= KMALLOC_MAXSIZE we use kmalloc
./drivers/media/video/buz.c:if (v4l_bufsize <= KMALLOC_MAXSIZE) {
./drivers/media/video/buz.c: * If the requested buffer size is smaller than
KMALLOC_MAXSIZE,
./drivers/media/video/buz.c: * size to KMALLOC_MAXSIZE in that case (which forces
contiguous allocation).
./drivers/media/video/buz.c:alloc_contig = (zr->jpg_bufsize < KMALLOC_MAXSIZE);
./drivers/media/video/buz.c:alloc_contig = (zr->jpg_bufsize < KMALLOC_MAXSIZE);
./drivers/media/video/buz.c:if (zr->need_contiguous && br.size >
KMALLOC_MAXSIZE)
./drivers/media/video/buz.c:br.size = KMALLOC_MAXSIZE;
./drivers/net/hamradio/6pack.c: if (sixpack_maxdev * sizeof(void*) >= KMALLOC_MAXSIZE)
{
$ find ../kernel-source-2.2.19 -name '*.h' | xargs grep KMALLOC_MAXSIZE
[3.] Keywords (i.e., modules, networking, kernel):
kernel, release engineering, drivers
[4.] Kernel version (from /proc/version):
2.4.3
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
N/A
[6.] A small shell script or example program which triggers the
problem (if possible)
make-kpkg
[7.] Environment
debian, kernel-source-2.4.2 patched up to 2.4.3
[7.1.] Software (add the output of the ver_linux script here)
N/A
[7.2.] Processor information (from /proc/cpuinfo):
N/A
[7.3.] Module information (from /proc/modules):
N/A
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
N/A
[7.5.] PCI information ('lspci -vvv' as root)
N/A
[7.6.] SCSI information (from /proc/scsi/scsi)
N/A
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
N/A
[X.] Other notes, patches, fixes, workarounds:
Doing at least a "christmas tree" build ("all lights on", though in
this case "build *everything* that can be built as a module, and use
the config defaults for the rest" would be quite enough to catch
these) before it goes out the door would be useful...
-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: > On Thu, 5 Apr 2001, Geert Uytterhoeven wrote: > > > > 32bit writes on a bus with a word size of 64 or more bits. By the way > > > does anyone know who didn't implement MTRR's or the equivalent on > > > alpha so we can shoot them? > > > > People never get shot in Open Source projects. Not when they write buggy code, > > > not when they don't implement some features. > > Was DEC Alpha an Open Source project? ;-) > > Memory barriers are more RISC-styled and more flexible anyway (e.g. you > can't run out of them ;-) ), though they require a greater care when > writing code. MTRRs are the Intel style of complicating designs. Still > they are probably a reasonable solution to preserve DOS compatibility. The point is on the Alpha all ram is always cached, and i/o space is completely uncached. You cannot do write-combing for video card memory. Memory barriers are a separate issue. On the alpha the natural way to implement it would be in the page table fill code. Memory barriers are o.k. but the really don't help the case when what you want to do is read the latest value out of a pci register. Eric - 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: [Problem] 3c90x on 2.4.3-ac3
Thats right. ACPI was what made 3c90x not work :( With APM it works perfectly. Thanks Marcus. On Thu, Apr 05, 2001 at 10:14:56AM +0200, Marcus Meissner wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > hi lkml, > > I just built 2.4.3-ac3 with my old 2.4.2 .config and somehow networking does >not work. > > dhclient eventually froze the machine. > > > here is what dhclient complains. > > > [root@psubash linux]# cat /tmp/error.txt > > skb: pf=2 (unowned) dev=lo len=328 > > PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x T=16 > > DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 14 > > ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN > > skb: pf=2 (unowned) dev=lo len=328 > > PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x T=16 > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 > > DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 12 > > ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN > > skb: pf=2 (unowned) dev=lo len=328 > > > Here is my ver_linux info > > ... > > CONFIG_ACPI=y > > The ACPI powermanagement for the 3c59x devices appears to be a bit broken. > > Disable ACPI support. Recompile. Reboot. Watch problem disappear hopefully. > > Ciao, Marcus - 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: AIC7xxx in Kernel 2.4.3
> >Hi > >This driver seems to be pretty broken, the way it is. It does not compile. >The new author, Justin T. Gibbs, has been careful in avoiding to mention >his e-mail address in his code :-( I actually don't believe in putting email address in code. They become stale far too easily. If you ever want to find me, type my name into a Yahoo search. I did this today and was a little surprised at the number of acurate hits. ;-) >Hence the post to this list. You should really check the archives before posting to LK. This has been discussed *a lot*. The version that was released in 2.4.3 was stale weeks prior to that final kernel cut. I'm working on getting revised versions into 2.4.4. If you want to upgrade to something newer, try the 6.1.9 release from here: http://people.FreeBSD.org/~gibbs/linux/ Just be sure to configure the bus settle delay to 5000ms as the default in that release causes a timeout. You can also configure the aic7xxx_old driver. -- Justin - 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/
AIC7xxx in Kernel 2.4.3
Hi This driver seems to be pretty broken, the way it is. It does not compile. The new author, Justin T. Gibbs, has been careful in avoiding to mention his e-mail address in his code :-( Hence the post to this list. As the first problem, the compile stops in aicasm_gram.c because in aicasm_gram.y the author forgot a function prototype. The compiler assumed an implicit declaration which was incompatible with the final definition of the function. The fix was easy of course. Next, the code #includes a file called db1/db.h. To me this seems to be a header file for the Berkeley database version 1. Debian does not provide development packages for this rather old version, in fact, not even my old cds from earlier linux distributions had this file. db2/db.h does not work. Possibly people by accident had this old file on their machine when the new kernel was test-compiled. So far, all kernels I compiled by myself did not seem to depend on any even remotely unusual header files. So this surprises me a lot. Does not look good for a release that's meant to be "stable", does it ? Cheers Peter - 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/
Looking for a card with working TV-out in linux
Hi ! I am looking for a gfx card to purchase for use with Linux. Requirements : - working TV-out ( S-Video or composite-video ), I mean really working and supported in linux, not "it works if the BIOS initializes it and Linux doesn't touch it" - video support ( in HW and linux-SW ) is desired ( color space conversion, video overlays and stuff ) - PCI interface ( I plan later to multihead with another AGP card and also want to keep the price low ) - 3D acceleration welcome ( with XFree86 support ), but not that important - low price :-) ( message posted to [EMAIL PROTECTED], [EMAIL PROTECTED] and to [EMAIL PROTECTED] mail lists , please CC me the replies and excuse me if some of them are inappropriate ) -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - 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: asm/unistd.h
On 04.05 Andreas Schwab wrote:
>
> Try this and watch your compiler complaining:
>
> #define foo() { }
> #define bar() do { } while (0)
> void mumble ()
> {
> if (1) foo(); else bar();
> if (2) bar(); else foo();
> }
>
Perhaps it is time to USE gcc, yet the kernel can be built only with gcc.
IE, use statement expressions.
Try this:
#define foo() ({ })
#define bar() do { } while (0)
void mumble ()
{
if (1) foo(); else bar();
if (2) bar(); else foo();
}
and see you compiler shutup.
You can even declare vars inside the ({ ... }) block,
so all the
#define bar(x) do { use_1(x); use_2(x); } while (0)
could be written like:
#define bar(x) ({ use_1(x); use_2(x); })
Even you can use :
#define swap(a,b) \
({ typeof(a) tmp = a; \
a = b; \
b = tmp; \
})
int main()
{
int a,b;
double c,d;
swap(a,b);
swap(c,d);
}
Its correct in egcs-1.1.2 and up, so it is safe for use in kernel 2.4.
Do not know if previuous gcc eats it up.
--
J.A. Magallon # Let the source
mailto:[EMAIL PROTECTED] # be with you, Luke...
Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686
-
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/
Arch specific/multiple Configure.help files?
Would it be a good idea to have support for multiple Configure.help files in the config system? The main advantage would be that arch specific settings could have an arch specific help file as well. Anybody who knows: Would it be a easy to add support for this if this is considered a good idea? /Johan - 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: [QUESTION] 2.4.x nice level
LA Walsh <[EMAIL PROTECTED]> writes: > I was running 2 copies of setiathome on a 4 CPU server >@ work. The two processes ran nice'd -19. The builds we were >running still took 20-30% longer as opposed to when setiathome wasn't >running (went from 45 minutes up to about an hour). This machine >has 1G, so I don't think it was hurting from swapping. It would be nice to have IRIX weightless processes on Linux.. setiathome on SGI computers don't affect anything else except in extreme cases. -Tor - 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: how to let all others run
On 5 Apr 2001, John Fremlin wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
>
> > On 4 Apr 2001, John Fremlin wrote:
> > >
> > > Hi Oliver!
> > >
> > > Oliver Neukum <[EMAIL PROTECTED]> writes:
> > >
> > > > is there a way to let all other runable tasks run until they block
> > > > or return to user space, before the task wishing to do so is run
> > > > again ?
> > >
> > > Are you trying to do this in kernel or something? From userspace you
> > > can use nice(2) then sched_yield(2), though I don't know if the linux
> > > implementations will guarrantee anything.
> > >
> >
> > I recommend using usleep(0) instead of sched_yield(). Last time I
> > checked, sched_yield() seemed to spin and eat CPU cycles, usleep(0)
> > always gives up the CPU.
>
> What is wrong with this? sched_yield only yields to processes with
> lower priority (hence suggestion to use nice(2)). Does sched_yield()
> fail to yield in cases when a higher priority process wants to run?
> usleep() wastes time if no other such process is waiting, surely?
>
> [...]
Only an observation:
main()
{
nice(19);
for(;;)
sched_yield();
}
does...
[H[J[H[1m 12:45pm up 19:10, 6 users, load average: 0.66, 0.19, 0.06[K
31 processes: 29 sleeping, 2 running, 0 zombie, 0 stopped[K
CPU states: 44.1% user, 56.9% system, 99.1% nice, 0.0% idle[K
Mem: 320368K av, 309608K used, 10760K free, 0K shrd, 12688K buff[K
Swap: 0K av, 0K used, 0K free188272K cached[K
[m[K
[7m PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND[K[m
15902 root 20 19 212 212 176 R N 0 99.1 0.0 1:05 xxx[K
15921 root 13 0 568 568 432 R 0 1.9 0.1 0:00 top[K
1 root 8 0 148 148 116 S 0 0.0 0.0 0:00 init[K
It consumes 99.1 percent CPU, just spinning.
However,
for(;;)
usleep(0);
Doesn't even show on `top`. Further, it gets the CPU about 100 times
a second (HZ). This is normally what you want for something that
polls, buts needs to give up the CPU so that whatever it's waiting
for can get done as soon as possible.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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: tulip (was RE: Kernel 2.4.3 fails to compile)
"Manuel A. McLure" wrote: > > Jeff Garzik wrote: > > On Fri, 30 Mar 2001, Manuel A. McLure wrote: > > > It looks like the tulip driver isn't as up-to-date as the one from > > > 2.4.2-ac20 - when is 2.4.3-ac1 due? :-) I got NETDEV > > WATCHDOG errors shortly > > > after rebooting with 2.4.3, although these were of the > > "slow/packet lossy" > > > type I got with 2.4.2-ac20 instead of the "network > > completely unusable" type > > > I got with 2.4.2-ac11 and earlier. > > > > I'm betting that the latest ac (ac28?) is broken for you, too. > > > > I had to revert the changes in 'ac' tulip -- they fixed Comet > > and 21041 > > cards, but broke some others. sigh. > > > > sigh. More testing and debugging for Jeffro... Comet (your chip, I > > am guessing?) should be fixed ASAP, it's pretty easy. 21041 is not as > > easy, but should be fixed quickly as well. > > Yes, mine is a Comet - here's the exact detection message: > > Mar 30 13:09:06 ulthar kernel: Linux Tulip driver version 0.9.14 (February > 20, 2 > 001) > Mar 30 13:09:06 ulthar kernel: PCI: Found IRQ 5 for device 00:0c.0 > Mar 30 13:09:06 ulthar kernel: eth0: ADMtek Comet rev 17 at 0xb000, > 00:20:78:0D: > D2:E1, IRQ 5. Ok, this should be fixed in the latest patches sent to Alan and Linus. -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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/
PCI address space collision
Hi, is this something to worry about ? in dmesg: PCI: Address space collision on region 9 of device VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [8080:808f] I know it might be unrelated with ACPI being experimental but if the kernel is compiled with ACPI instead of APM the machine (Presario 12XL300) "cannot enter S5" when halting. kernels 2.4.1 - 2.4.3 Thanks. - 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: ERESTARTSYS question.
On Thu, 5 Apr 2001, Bjorn Wesen wrote: > > ERESTARTSYS is a part of the api between the driver and the > signal-handling code in the kernel. It does not reach user-space (provided > of course that it's used appropriately in the drivers :) As an example sound/via82cxxx_audio.c returns ERESTARTSYS from via_dsp_open() .I suppose this _does_ reach userland right? > When a driver needs to wait, and get awoken by a signal (as opposed to > what it's really waiting for) the driver should in most cases abort the > system call so the signal handler can be run (like, you push ctrl-c while > running somethinig that's stuck in a wait for an interrupt). The kernel > uses the ERESTARTSYS as a "magic" value saying it's ok to restart the > system call automagically after the signal handling is done. The actual > return-code is switched to EINTR if the system call could not be > restarted. > > -Bjorn > Thanks, and by the way the comments in arch/cris regarding the issue are useful too ;) Jani. - 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: /dev/loop0 over lvm... leading to d-state :-(
On Thu, Apr 05, 2001 at 05:54:30PM +0200, Jens Axboe wrote: > On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote: > > > Where? Calling buffer_IO_error would be ok, but there are no such calls > > > in 2.4.3. I just stated elsewhere that submit_bh should probably be > > > clearing the dirty bit, not ll_rw_block, in which case the b_end_io > > > is fine. But buffer_IO_error is probably more clear. I trust you'll > > > take care of that part then. > > > > Sorry, didn't mention that you need to patch the driver with the recent > > LVM software in order to get it. > > Ah ok, so the b_dev/b_blocknr is all then. Good. > > > I've send the patch a while ago to Linus to get it into 2.4.3 > > but he obviously didn't include it (likely because he thought it was too > > large ;-) > > Maybe you're hanging on to fixes and submitting huge chunks of them? We want to change that, sorry :) > > > He didn't comment back to me at all though :-( > > Maybe this will help. > > Two things that usually help -- submit small and often, then resubmit, > resubmit, resubmit until he takes it or complains loudly :-) I know, I know, I know ;-) > > -- > Jens Axboe > -- Regards, Heinz-- The LVM Guy -- *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - 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: cannot compile kernel
[EMAIL PROTECTED] said: > compiler (gcc --version): pgcc-2.95.2 > I hope i have included enough information for you and that you will be > able to solve my problem. grep --context pgcc Documentation/Changes See also http://www.tux.org/lkml/#s8-9, #s8-5 and indeed most of the rest of ยง8. -- dwmw2 - 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: how to let all others run
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > On 4 Apr 2001, John Fremlin wrote: > > > > Hi Oliver! > > > > Oliver Neukum <[EMAIL PROTECTED]> writes: > > > > > is there a way to let all other runable tasks run until they block > > > or return to user space, before the task wishing to do so is run > > > again ? > > > > Are you trying to do this in kernel or something? From userspace you > > can use nice(2) then sched_yield(2), though I don't know if the linux > > implementations will guarrantee anything. > > > > I recommend using usleep(0) instead of sched_yield(). Last time I > checked, sched_yield() seemed to spin and eat CPU cycles, usleep(0) > always gives up the CPU. What is wrong with this? sched_yield only yields to processes with lower priority (hence suggestion to use nice(2)). Does sched_yield() fail to yield in cases when a higher priority process wants to run? usleep() wastes time if no other such process is waiting, surely? [...] -- http://www.penguinpowered.com/~vii - 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: [2.4.3] PPP errors
On Wed, 04 Apr 2001, Jean Paul Sartre wrote: > On Wed, 4 Apr 2001, Manfred H. Winter wrote: > > > Apr 4 02:05:21 marvin pppd[1227]: Couldn't set tty to PPP discipline: Invalid a > > rgument > > Apr 4 02:05:21 marvin pppd[1227]: Exit. > > Did you load the 'ppp_async.o' module? > Sorry, I forget to look for that, but: I have the following line in /etc/modules/conf: alias char-major-108 ppp_async alias tty-ldisc-3 ppp alias ppp0 ppp_generic alias ppp1 ppp_generic alias ppp ppp_generic alias ppp-compress-18 ppp_mppe alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate So it should be autoloaded. I've added now "probe tty-ldisc-3 ppp_async ppp" and hope it helps. So, if ppp_async gets not autoloaded, why? And why does'nt this happen not allways but only sometimes? Bye, Manfred -- /"\| PGP-Key available at Public Key Servers \ / ASCII ribbon campaign | or at "http://www.mahowi.de/" X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA / \ and postings | GPG: 0x88BC3576 * ICQ: 61597169 - 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: /dev/loop0 over lvm... leading to d-state :-(
On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote: > > Where? Calling buffer_IO_error would be ok, but there are no such calls > > in 2.4.3. I just stated elsewhere that submit_bh should probably be > > clearing the dirty bit, not ll_rw_block, in which case the b_end_io > > is fine. But buffer_IO_error is probably more clear. I trust you'll > > take care of that part then. > > Sorry, didn't mention that you need to patch the driver with the recent > LVM software in order to get it. Ah ok, so the b_dev/b_blocknr is all then. Good. > I've send the patch a while ago to Linus to get it into 2.4.3 > but he obviously didn't include it (likely because he thought it was too > large ;-) Maybe you're hanging on to fixes and submitting huge chunks of them? > He didn't comment back to me at all though :-( > Maybe this will help. Two things that usually help -- submit small and often, then resubmit, resubmit, resubmit until he takes it or complains loudly :-) -- Jens Axboe - 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: /dev/loop0 over lvm... leading to d-state :-(
On Thu, Apr 05, 2001 at 05:37:31PM +0200, Jens Axboe wrote: > On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote: > > > Irks, another one. lvm_make_request_fn also needs to call b_end_io > > > if a map fails. > > > > This is wrong. > > > > In case of an io error we do already call buffer_IO_error() on 2.4 in > > lvm_map(). > > Where? Calling buffer_IO_error would be ok, but there are no such calls > in 2.4.3. I just stated elsewhere that submit_bh should probably be > clearing the dirty bit, not ll_rw_block, in which case the b_end_io > is fine. But buffer_IO_error is probably more clear. I trust you'll > take care of that part then. Sorry, didn't mention that you need to patch the driver with the recent LVM software in order to get it. I've send the patch a while ago to Linus to get it into 2.4.3 but he obviously didn't include it (likely because he thought it was too large ;-) He didn't comment back to me at all though :-( Maybe this will help. Linus? > > -- > Jens Axboe > -- Regards, Heinz-- The LVM Guy -- *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - 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: uninteruptable sleep
> Its a kernel bug if it gets stuck like this. You need to provide more info > though - what file system, what devices, how much memory. Also ps can give you > the wait address of a process stuck in 'D' state which is valuable for debug Let's see if I'm getting this right, processes in D state should be killable? I do not know if this is related, but I had two occurrences of those within the last 48 hours, albeit on 2.2.18. 1. starting tin (1.4.1) as a user - nothing happened, but the ssh session froze. Same on second try and a third with mutt (1.2.5) The three processes ended up D and unkillable by root. A few seconds later the sytem became totally unresponsive, with the kernel spewing 'VM: do_try_to_free_pages faild for cupsd' (sp?) at top speed... reboot. 2. The cups (1.1.4) usb backend ended up in this state after I did a 'rmmod printer; insmod printer' Regards Christian Kernel: linux-2.2.18 + raid-2.2.17-A0 System: Pentium III 600 w/ 256MB RAM hard disks: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DDRS-34560D Rev: DC1B Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: YAMAHA Model: CRW4260 Rev: 1.0q Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 08 Lun: 00 Vendor: QUANTUM Model: ATLAS_V_18_WLS Rev: 0230 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 09 Lun: 00 Vendor: QUANTUM Model: ATLAS_V_18_WLS Rev: 0230 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 10 Lun: 00 Vendor: QUANTUM Model: ATLAS_V_18_WLS Rev: 0230 Type: Direct-AccessANSI SCSI revision: 03 RAID info: Personalities : [raid5] read_ahead 1024 sectors md0 : active raid5 sdd1[2] sdc1[1] sdb1[0] 35069824 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] unused devices: Layout of RAID disks (sdb-sdd): Disk /dev/sdb: 64 heads, 32 sectors, 17510 cylinders Units = cylinders of 2048 * 512 bytes Device BootStart EndBlocks Id System /dev/sdb1 387 17510 17534976 fd Linux raid autodetect /dev/sdb3 130 386263168 83 Linux /dev/sdb4 1 129132095+ 82 Linux swap lspci -vvv: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:08.0 VGA compatible controller: Cirrus Logic GD 5430/40 [Alpine] (rev 48) 00:09.0 SCSI storage controller: Adaptec 7892A (rev 02) 00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) jesus:/raid/home/chris# lspci -vvv 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B+ 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: asm/unistd.h
Steve Grubb writes: > It would seem to me that after hearing how the macros are used in practice, > wouldn't turning them into inline functions be an improvement? This is > something gcc supports, it accomplishes the same thing, and has the added > advantage of type checking. > http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92 Two reasons: 1) Sometimes I don't want any type checking because it would create the necessity of adding a new include to a file --> a circular dependency to resolve. Macros hide the types except in the cases where they are actually invoked :-) 2) Historically GCC was very bad with code generation with inline functions, so at that time the GCC manual statement "inline functions are just like a macro" was technically false :-) Yes, I know this is much different in today's gcc tree, but there hasn't been a gcc release in over 2 years so... Later, David S. Miller [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: asm/unistd.h
On Thu, 5 Apr 2001, Steve Grubb wrote: > It would seem to me that after hearing how the macros are used in practice, > wouldn't turning them into inline functions be an improvement? This is > something gcc supports, it accomplishes the same thing, and has the added > advantage of type checking. > http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92 > > Or perhaps type checking macro arguments would be another fertile area for > the Stanford Checker... There are benefits to macros too. One that I like for debuggin is that the C parser will unravel a macro within the context of the execution: #ifdef DEBUG #define KMALLOC(x,y) \ printk(__FILE__ ":%d: kmalloc(%d,%d")\n", __LINE__,x,y); \ kmalloc(x,y); #else #define KMALLOC(x,y) \ kmalloc(x,y); #endif I think the benefit of a macro here is quite visible... you cannot do this with an inline. You may also look at some better reasons: http://www.uwsg.iu.edu/hypermail/linux/kernel/9810.3/0323.html [btw I found this by looking for 'macros vs inline' on google/linux] Bart. -- WebSig: http://www.jukie.net/~bart/sig/ - 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: /dev/loop0 over lvm... leading to d-state :-(
On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote: > > Irks, another one. lvm_make_request_fn also needs to call b_end_io > > if a map fails. > > This is wrong. > > In case of an io error we do already call buffer_IO_error() on 2.4 in > lvm_map(). Where? Calling buffer_IO_error would be ok, but there are no such calls in 2.4.3. I just stated elsewhere that submit_bh should probably be clearing the dirty bit, not ll_rw_block, in which case the b_end_io is fine. But buffer_IO_error is probably more clear. I trust you'll take care of that part then. -- Jens Axboe - 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: 2.4.3-ac3 XIRCOM_CB only working as module
On Thu, 5 Apr 2001, Alessandro Suardi wrote: > It looks like the new xircom_cb driver only works as module - if built > in kernel there is no sign of eth0 setup. Built as a module works beutifully :) No need to "ifconfig -promisc" to make it work after a suspend. Anyway, you still have to unload the card and reload it again to get back the network working. I'm using hotplug. Pau - 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: ERESTARTSYS question.
On Thu, 5 Apr 2001, Jani Monoses wrote: > although the comments in errno.h say that ERESTARTSYS should not be seen > by userland,many drivers seam to return it from their > file_operations.Should glibc convert this errno so that the user program > sees something meaningful?Because it does not.Is EINTR not a better errno > to return from the drivers? ERESTARTSYS is a part of the api between the driver and the signal-handling code in the kernel. It does not reach user-space (provided of course that it's used appropriately in the drivers :) When a driver needs to wait, and get awoken by a signal (as opposed to what it's really waiting for) the driver should in most cases abort the system call so the signal handler can be run (like, you push ctrl-c while running somethinig that's stuck in a wait for an interrupt). The kernel uses the ERESTARTSYS as a "magic" value saying it's ok to restart the system call automagically after the signal handling is done. The actual return-code is switched to EINTR if the system call could not be restarted. -Bjorn - 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: /dev/loop0 over lvm... leading to d-state :-(
Jens,
thanks for the b_dev hint you provided.
On Thu, Apr 05, 2001 at 04:49:42PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Jens Axboe wrote:
> > To the LVM folks: you can't use b_dev or b_blocknr inside your
> > make_request_fn, it destroys stacking drivers such as loop. And
> > is just plain wrong in the general case too.
>
> Irks, another one. lvm_make_request_fn also needs to call b_end_io
> if a map fails.
This is wrong.
In case of an io error we do already call buffer_IO_error() on 2.4 in lvm_map().
In 2.2 ll_rw_block() does change the state of the buffer and calls
b_end_io() for us at the end of the function:
sorry:
for (i = 0; i < nr; i++) {
if (bh[i]) {
clear_bit(BH_Dirty, [i]->b_state);
clear_bit(BH_Uptodate, [i]->b_state);
bh[i]->b_end_io(bh[i], 0);
}
}
> Updated patch attached, I'll collate further
> patches if I find more :-)
Please do that. Thanks again.
Regards,
Heinz-- The LVM Guy --
>
>
> --
> Jens Axboe
>
> --- /opt/kernel/linux-2.4.3/drivers/md/lvm.c Mon Jan 29 01:11:20 2001
> +++ drivers/md/lvm.c Thu Apr 5 16:48:52 2001
> @@ -148,6 +148,9 @@
> * procfs is always supported now. (JT)
> *12/01/2001 - avoided flushing logical volume in case of shrinking
> * because of unecessary overhead in case of heavy updates
> + *05/04/2001 - lvm_map bugs: don't use b_blocknr/b_dev in lvm_map, it
> + * destroys stacking devices. call b_end_io on failed maps.
> + * (Jens Axboe)
> *
> */
>
> @@ -1480,14 +1483,14 @@
> */
> static int lvm_map(struct buffer_head *bh, int rw)
> {
> - int minor = MINOR(bh->b_dev);
> + int minor = MINOR(bh->b_rdev);
> int ret = 0;
> ulong index;
> ulong pe_start;
> ulong size = bh->b_size >> 9;
> - ulong rsector_tmp = bh->b_blocknr * size;
> + ulong rsector_tmp = bh->b_rsector;
> ulong rsector_sav;
> - kdev_t rdev_tmp = bh->b_dev;
> + kdev_t rdev_tmp = bh->b_rdev;
> kdev_t rdev_sav;
> vg_t *vg_this = vg[VG_BLK(minor)];
> lv_t *lv = vg_this->lv[LV_BLK(minor)];
> @@ -1676,8 +1679,12 @@
> */
> static int lvm_make_request_fn(request_queue_t *q,
> int rw,
> -struct buffer_head *bh) {
> - return (lvm_map(bh, rw) < 0) ? 0 : 1;
> +struct buffer_head *bh)
> +{
> + int ret = lvm_map(bh, rw);
> + if (ret)
> + bh->b_end_io(bh, test_bit(BH_Uptodate, >b_state));
> + return ret;
> }
>
>
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[EMAIL PROTECTED] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
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: asm/unistd.h
It would seem to me that after hearing how the macros are used in practice, wouldn't turning them into inline functions be an improvement? This is something gcc supports, it accomplishes the same thing, and has the added advantage of type checking. http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92 Or perhaps type checking macro arguments would be another fertile area for the Stanford Checker... Cheers, Steve Grubb - 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: 2.4 kernel on LH4
On Thursday 05 April 2001 16:57, you wrote: > At some Kernel release between 2.4.2 and 2.4.3 I succeeded to install > Mandrake Cooker (Devel-Tree) out of the box. > However, we have switched to another SCSI RAID controller as the AMI > MegaRAID driver in conjunction with I2O seems to be very buggy/broken. > Apart from it, the AMI is does not perform that good. We now use an > ICP Vortex 4 Chanel RAID controller that has a very good Linux support. > However it's not I2O, it outperforms the AMI by at least 250% ... > So we simply leave the on-board AMI unused :-) I have disabled (don't ask me why, it was not my decision) the raid controller. I had a look at the old (2.2.18) config and I see the SCSI_MEGA_RAID is torned on, while I forgot this with the new kernel. I thought that, having the raid controller disabled in the bios, I don't need it anymore. But probably I'm in fail... As soon as I can (probably next week) I try another time. Do you think that this could be the problem? If yes, so why it have some problem with: PCI: cannot allocate resource region 0 for 0:1.4 I remember that according to lspci of kernel 2.2.18: 01:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] 01:06.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c895 01:07.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c895 > Second, BigMem support (>2GB RAM) seems to be a problem with recent > initial RAM disks (the ones current distributions use for their graphical Well I have only 512Mb for the moment, so I don't think this is the problem. Anyway, thanks a lot. gianpaolo racca [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/
ERESTARTSYS question.
Hi, although the comments in errno.h say that ERESTARTSYS should not be seen by userland,many drivers seam to return it from their file_operations.Should glibc convert this errno so that the user program sees something meaningful?Because it does not.Is EINTR not a better errno to return from the drivers? Thanks. - 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/
2.0.39 oopses in sys_new(l)stat
I wonder if there might still be a bug in 2.0.39 sys_new(l)stat. Today, one of my trustworthy servers crashed (see details below), and it has actually given me two slightly similar looking oopses before. While this might be a hardware problem (I'll run memory test asap), it seems that the oopses are quite similar and could perhaps be caused by a kernel bug. This is vanilla 2.0.39 (2.0.37 before), gcc-2.7.2.3, Ppro-200, Intel motherboard etc. It has been very reliable in past. These oopses are the _only_ problems. It runs qmail, samba, cvs, rsync, apache, pop, sshd and oracle. All local fs's are plain ext2. I hope somebody (with more kernel hacking experience than me) is still interested in the 2.0.39. I'll be happy to provide any additional details or try something. The oops will propably be hard to reproduce, however. == It began with this: Apr 5 05:33:35 some kernel: general protection: Apr 5 05:33:36 some kernel: CPU:0 Apr 5 05:33:36 some kernel: EIP:0010:[__iget+60/544] Apr 5 05:33:36 some kernel: EFLAGS: 00010292 Apr 5 05:33:36 some kernel: eax: 0341 ebx: 9a0004b6 ecx: 000203e5 edx: 001c7658 Apr 5 05:33:36 some kernel: esi: 001ba164 edi: ebp: 001c7658 esp: 06436ef0 Apr 5 05:33:36 some kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Apr 5 05:33:36 some kernel: Process rsync (pid: 15624, process nr: 76, stackpage=06436000) Apr 5 05:33:36 some kernel: Stack: 05144d00 07ff1418 0004 03070004 07ff1418 00154f27 001c7658 000203e5 Apr 5 05:33:36 some kernel:0001 05144d00 06436f74 06436f74 0004 0897eaf8 000203e5 0012ce12 Apr 5 05:33:36 some kernel:05144d00 03070004 0004 06436f74 06436f74 06436fb4 bfffdb30 Apr 5 05:33:36 some kernel: Call Trace: [ext2_lookup+343/368] [lookup+222/248] [_namei+90/228] [lnamei+48/72] [sys_newlstat+41/88] [system_call+85/124] Apr 5 05:33:36 some kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84 fa 00 00 00 8b 5b Apr 5 05:33:36 some kernel: general protection: Apr 5 05:33:36 some kernel: CPU:0 Apr 5 05:33:36 some kernel: EIP:0010:[__iget+60/544] Apr 5 05:33:36 some kernel: EFLAGS: 00010292 Apr 5 05:33:36 some kernel: eax: 0341 ebx: 9a0004b6 ecx: 000203e5 edx: 000203e5 Apr 5 05:33:36 some kernel: esi: 001ba164 edi: ebp: 001c7658 esp: 01083ef0 Apr 5 05:33:36 some kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Apr 5 05:33:36 some kernel: Process rsync (pid: 15278, process nr: 77, stackpage=01083000) Apr 5 05:33:36 some kernel: Stack: 05144d00 01083f74 0004 09036004 00154e51 00154e84 001c7658 000203e5 Apr 5 05:33:36 some kernel:0001 05144d00 01083f74 01083f74 0004 05144d00 000203e5 0012ce12 Apr 5 05:33:36 some kernel:05144d00 09036004 0004 01083f74 01083f74 01083fb4 b1f8 Apr 5 05:33:36 some kernel: Call Trace: [ext2_lookup+129/368] [ext2_lookup+180/368] [lookup+222/248] [_namei+90/228] [lnamei+48/72] [sys_newlstat+41/88] [system_call+85/124] Apr 5 05:33:36 some kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84 fa 00 00 00 8b 5b Apr 5 05:33:37 some kernel: general protection: Apr 5 05:33:37 some kernel: CPU:0 Apr 5 05:33:37 some kernel: EIP:0010:[__iget+60/544] Apr 5 05:33:37 some kernel: EFLAGS: 00010212 Apr 5 05:33:37 some kernel: eax: 0301 ebx: 6a000973 ecx: 01fbc598 edx: 001c6b4c Apr 5 05:33:37 some kernel: esi: 001b9d34 edi: ebp: 001c6b4c esp: 054b4ef0 Apr 5 05:33:37 some kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Apr 5 05:33:37 some kernel: Process cvs (pid: 15623, process nr: 70, stackpage=054b4000) Apr 5 05:33:37 some kernel: Stack: 0191c400 01fbc598 0008 0320f000 01fbc598 00154f27 001c6b4c 000c2b1f Apr 5 05:33:37 some kernel:0001 0191c400 054b4f74 054b4f74 0008 075f4cc0 000c2b1f 0012ce12 Apr 5 05:33:37 some kernel:0191c400 0320f000 0008 054b4f74 054b4f74 054b4fb4 b670 Apr 5 05:33:37 some kernel: Call Trace: [ext2_lookup+343/368] [lookup+222/248] [_namei+90/228] [lnamei+48/72] [sys_newlstat+41/88] [system_call+85/124] Apr 5 05:33:37 some kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84 fa 00 00 00 8b 5b Apr 5 05:33:43 some kernel: general protection: Apr 5 05:33:43 some kernel: CPU:0 Apr 5 05:33:43 some kernel: EIP:0010:[__iget+60/544] Apr 5 05:33:43 some kernel: EFLAGS: 00010292 Apr 5 05:33:43 some kernel: eax: 1605 ebx: 9a000945 ecx: 098eb398 edx: 001c7330 Apr 5 05:33:43 some kernel: esi: 001ba0ac edi: ebp: 001c7330 esp: 01ce5ec4 Apr 5 05:33:43 some kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Apr 5 05:33:43 some kernel: Process smbd (pid: 23077, process nr: 72,
kernel bug in 2.4.2-ac28, patched with 6.1.8 aic drivers
got this on booting up 2.4.2-ac28: Apr 5 09:36:37 grim kernel: kernel BUG at slab.c:1244! Apr 5 09:36:37 grim kernel: invalid operand: Apr 5 09:36:37 grim kernel: CPU:0 Apr 5 09:36:37 grim kernel: EIP:0010:[kmalloc+303/472] Apr 5 09:36:37 grim kernel: EFLAGS: 00010086 Apr 5 09:36:37 grim kernel: eax: 001b ebx: c1447768 ecx: c02900a0 edx: 16ea Apr 5 09:36:37 grim kernel: esi: cea5a000 edi: cea5a9aa ebp: 00012800 esp: cf27de30 Apr 5 09:36:37 grim kernel: ds: 0018 es: 0018 ss: 0018 Apr 5 09:36:37 grim kernel: Process mingetty (pid: 672, stackpage=cf27d000) Apr 5 09:36:37 grim kernel: Stack: c023a56b 04dc c02ffae0 0403 0403 cea5a000 1000 Apr 5 09:36:37 grim kernel:0015 0246 c01b1dfe 0c3c 0007 c02ffae0 0403 c01b2a6a Apr 5 09:36:37 grim kernel: cf011a30 cff0de74 0001 cf27dee8 c0291080 cf27c000 Apr 5 09:36:37 grim kernel: Call Trace: [alloc_tty_struct+14/40] [init_dev+138/1088] [tty_open+475/944] [cached_l ookup+16/84] [get_chrfops+106/232] [permission+43/48] [chrdev_open+64/76] Apr 5 09:36:37 grim kernel:[dentry_open+198/336] [filp_open+82/92] [sys_open+56/180] [system_call+51/56] Apr 5 09:36:37 grim kernel: Apr 5 09:36:37 grim kernel: Code: 0f 0b 83 c4 08 8b 6b 10 f7 c5 00 04 00 00 74 53 b8 a5 c2 0f Console was half dead -- got the login prompt, but a whole lot of nothing afterwards, but I was able to SysRQ-sync and reboot into another kernel. This problem does not appear in 2.4.3-ac3, FWIW. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: /dev/loop0 over lvm... leading to d-state :-(
On Thu, Apr 05 2001, Jens Axboe wrote:
> To the LVM folks: you can't use b_dev or b_blocknr inside your
> make_request_fn, it destroys stacking drivers such as loop. And
> is just plain wrong in the general case too.
Irks, another one. lvm_make_request_fn also needs to call b_end_io
if a map fails. Updated patch attached, I'll collate further
patches if I find more :-)
--
Jens Axboe
--- /opt/kernel/linux-2.4.3/drivers/md/lvm.cMon Jan 29 01:11:20 2001
+++ drivers/md/lvm.cThu Apr 5 16:48:52 2001
@@ -148,6 +148,9 @@
* procfs is always supported now. (JT)
*12/01/2001 - avoided flushing logical volume in case of shrinking
* because of unecessary overhead in case of heavy updates
+ *05/04/2001 - lvm_map bugs: don't use b_blocknr/b_dev in lvm_map, it
+ *destroys stacking devices. call b_end_io on failed maps.
+ *(Jens Axboe)
*
*/
@@ -1480,14 +1483,14 @@
*/
static int lvm_map(struct buffer_head *bh, int rw)
{
- int minor = MINOR(bh->b_dev);
+ int minor = MINOR(bh->b_rdev);
int ret = 0;
ulong index;
ulong pe_start;
ulong size = bh->b_size >> 9;
- ulong rsector_tmp = bh->b_blocknr * size;
+ ulong rsector_tmp = bh->b_rsector;
ulong rsector_sav;
- kdev_t rdev_tmp = bh->b_dev;
+ kdev_t rdev_tmp = bh->b_rdev;
kdev_t rdev_sav;
vg_t *vg_this = vg[VG_BLK(minor)];
lv_t *lv = vg_this->lv[LV_BLK(minor)];
@@ -1676,8 +1679,12 @@
*/
static int lvm_make_request_fn(request_queue_t *q,
int rw,
- struct buffer_head *bh) {
- return (lvm_map(bh, rw) < 0) ? 0 : 1;
+ struct buffer_head *bh)
+{
+ int ret = lvm_map(bh, rw);
+ if (ret)
+ bh->b_end_io(bh, test_bit(BH_Uptodate, >b_state));
+ return ret;
}
