Re: Linux 2.4.2-ac27
(Linus cc'ed - related thread: 243-pre[78]: mmap changes (breaks) /proc)
On Wed, 28 Mar 2001, Alan Cox wrote:
> 2.4.2-ac27
> o Revert mmap change that broke assumptions (and (Martin Diehl)
> it seems SuS)
the reason to suggest keeping the test was not due to len=0 behaviour of
mmap in general as is suggested by your comment. The breakage that I've
seen was due to mmap not returning -ENODEV for files from /proc despite
the lack of valid f_op->mmap (because the test was moved behind the len==0
check). The point is sed(1) first tries to mmap(2) the file and falls back
to read(2) in case of -ENODEV (and probably other errors too). This is
important for /proc since most files there are stat'ed size=0 but return
stuff when reading. Not getting error for mmap len=0 file makes sed behave
like at EOF. Anyway, reverting it was not addressed to cases where
f_op->mmap is valid but request is to mmap len=0 - we still return the
startaddr parameter in that case:
$ touch nullfile
$ strace sed 's/./X/' nullfile
open("nullfile", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 0, PROT_READ, MAP_PRIVATE, 4, 0) = 0
This is consistent throughout all 2.4.x at least. From your comment I've
learnt SuS v2 requires -ENODEV for the len=0 case. While this would
resolve the /proc issue as well there might be some chance to brake code
which expects mmap(len=0) to succeed.
BTW, man-pages (1.31) say, mmap(2) returns -EINVAL if called with bad
start/length/offset values - but makes no claims whether len=0 would be
valid or not.
In case we want to follow what you've said about SuS, the right thing
might simply go along
--- linux-243-pre8/mm/mmap.cWed Mar 28 13:14:19 2001
+++ linux-243p8-md/mm/mmap.cThu Mar 29 09:49:34 2001
@@ -204,8 +204,12 @@
int correct_wcount = 0;
int error;
+ /* We need to error mmaps of 0 length. The apps rely on this and
+ SuS v2 says that we return -ENODEV in this case without mentioning
+ returning 0 for 0 length mmap */
+
if ((len = PAGE_ALIGN(len)) == 0)
- return addr;
+ return -ENODEV;
if (len > TASK_SIZE || addr > TASK_SIZE-len)
return -EINVAL;
I really have no idea about what, if any, code might rely on old
beahviour. Some commonly used tools may get confused with stuff from
/var/lock/subsys tree for example. So probably it's better not to field
this change before 2.5 to be able to identify such things in time.
In this case we could add some clarification to your comment, saying that
returning error on len=0 is a future thing, leave the current len=0
semantics untouched, keep the f_op->mmap test at the very beginning (and
drop the moved one a few lines below).
Regards
Martin
-
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: Disturbing news..
Ben Ford wrote: > > There are two problems I see here. First, there are several known ways > to elevate privileges. Fixable, except from guessing the root password which is hard. > If a virus can elevate privileges, then it owns > you. Second, this is a multi-OS virus. If you dual-boot into Windows, > any ELF files accessible can be infected. With this one, that isn't a > prob, but when somebody codes in an ext2 driver to their virus, then > we've got issues. And the only cure then is not make your linux fs accessible from windows. I.e. not on a disk for which windows have a driver installed. Preferably not the same computer. Or simply "don't run untrusted executables under windows". Do so in linux only, where protection applies. Do anybody ever _need_ to run a program they got in the mail? Helge Hafting - 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: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
Hello Paul Cassella,
Once you wrote about "Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.":
PC> [1.] One line summary of the problem:
PC> Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
I have similar problem with 2.4.0, 2.4.1, 2.4.2. I tried running -ac24,25,26
and 2.4.3-pre6 and I don't have any problems so far.
PC> [2.] Full description of the problem/report:
PC> I have had hangs under 2.4.2-ac18, -ac19, and -ac24, after uptimes of
PC> 36 hours, 12 hours, and 10 hours, respectively. -ac12 has twice run
PC> for a week without crashing. I didn't see anything in the later -ac
PC> changelogs that looks responsible, but I haven't actually tried them.
My uptimes were bigger, but each of them was 16 days + X hours (X being 0-20)
PC> All the crashes were under X. The machine did not respond to pings,
PC> and no sysrq keys other than B worked; I didn't hear disk activity
PC> after S, and the disks weren't unmounted. Nothing made it to the
PC> logs. In the -ac19 crash, I had run at the console for about 12
PC> hours, and then started X; it crashed within 15 minutes.
I also have all these troubles under X.
PC> In the one crash that happened while I was at the console, X
PC> completely froze, and sound output stopped. In the others, the
PC> monitor was in power-save mode and didn't wake up.
I had it twice.
PC> The hangs don't appear to be related to IO load or anything else I can
PC> think of besides X. Each time, there was a distributed.net client
PC> running, and nothing else that was in any way intensive. I don't
PC> believe any sort of updatedb or makewhatis was running during the
PC> crashes, and it never hung overnight when these jobs run.
No distributed.net client here ;)
PC> I ran with -ac12 with nearly 1300 lines of diff narrowed down from
PC> [...skip...]
PC> - i810, (Debian unstable) X 4.0.2, with DRI
I think that the problem might be somewhere he. I am running i810,
(RedHat 7...not original anymore :)) X 4.0.1.
PC> I'll be happy to try out patches, configuration changes, and other
PC> suggestions, but I won't be able to tell for three or four days
PC> whether or not it helped.
With regular uptime of 16 days I will be very slow responsive for the testing
phase, though I am willing to try too ;)
--
Best regards,
Leonid Mamtchenkov
System Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic in 2.4.2
On Thu, Mar 29, 2001 at 12:55:50AM -0500, Alexander Viro wrote: > Check the memory - it _may_ be a hardware problem. damn. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Experience is not what happens to you; it is what you do with what happens to you. -- Aldous Huxley - 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] pae-2.4.3-C3
Ingo Molnar writes: > the attached pae-2.4.3-C3 patch fixes the PAE code to work with SLAB > FORCED_DEBUG (which enables redzoning) too. > > the problem is that redzoning is enabled unconditionally, and SLAB has no > information about how crutial alignment is in the case of any particular > SLAB cache. The CPU generates a general protection fault if in PAE mode a > non-16-byte aligned pgd is loaded into %cr3. How about just fixing the debug code to align things? Sure it wastes a bit of memory, but debug code is like that. Sane alignment might be: largest power-of-two factor of the size, or 4 bytes, which ever is larger. (adjust "4" per-arch as needed) For an SMP config, set a minimum alignment equal to the cache line size. - 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/
Linux 2.4.2-ac28
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) 2.4.2-ac28 o Fix another modules race(me) o Add basic PM hooks to agpgart (me) o Update new xircom_cb driver (Arjan van de Ven) o Fix missing lock_kernel on truncate path(Al Viro) o Update klsi usb ethernet ids(Brad Hards) o Fix missing permission check in shm code(Matthew Klahn) o Add extra doupdate() calls to menuconfig(Moritz Schulte) o Update wireless extensions (Jean Tourrilhes) o Fix cdda reading problem(Jens Axboe) o Fix potential oops in usb-uhci (David Brownell) 2.4.2-ac27 o Rely on BIOS to setup apic bits on OSB4 (me) o Disable events when unloading cardbus yenta (me) | Fixes shared irq unload hang o Fix x86 IPI replay problems (Stephen Tweedie) o Add ALS100 gameport support (Vojtech Pavlik) o Fix wrong path in comment in vesafb (Andres Salomon) o Allow slab caches to force alignment always (Ingo Molnar) and thus fix PAE+ slab poisoning o Fix problems in faulting raw I/O pages (Stephen Tweedie) o Fix rawio error handling for raw I/O(Stephen Tweedie) | + other oddments o Change default max printer ports to 8 (Tim Waugh) o Parport soft control state fixes(Tim Waugh) o Fix cpu info compile(Constantine Gavrilov) o Set warning levels on reiserfs warn etc (Paul Mundt) o Fix duplicate IOVIRT debug config help (Steven Cole) o Revert mmap change that broke assumptions (and (Martin Diehl) it seems SuS) o Clean up fpu emu warnings on gcc 3.0cvs a bit (me) 2.4.2-ac26 o Fix es1370 build bug(me) o Fix sbpcd compile warnings (me) o Update usbnet driver(Oleg Drokin) o Update Alpha to pre8 vm changes (Ivan Kokshaysky) o Fix radeonfb config selections (Chris Lawrence) o Fix vmalloc mismerge(Various) o Fix n_r3964 console panic (Andrew Morton) o Update ibm camera drivers o Support 701b toshoboe fir o New xircom_cb driver(Arjan van de Ven, Jeff Garzik, Don Becker, Doug Ledford) o Fix procfs mount point for binfmt_misc (Al Viro) o Update hpt366 ide blacklist o Further ide blacklist updates o Smooth vm balancing (Marcelo Tosatti) o Fix irda assert (Arjan van de Ven) o Keep contrack cache sizes sane (Ben LaHaise) o Fix possible file truncate/write race (Ben LaHaise) o Make bootmem panic sanely on out of memory (Ben LaHaise) o Fix unload crash in pci_socket (me) o Revert previous wrong bootmem change(Ben LaHaise) 2.4.2-ac25 o Handle PCI/ISA simple MP tables via ELCR(John William) o Fix get_sb_single (Al Viro) o Update es1370, es1371,esssolo (Thomas Sailer, Tjeerd Mulder, Nathanial Daw) o Update orinoco_cs (Jean Tourilhes) o Fix races found in the new kbd/console code (Andrew Morton) o Remove dead timer.h docs(Tim Wright) o Update ppc to new generic mm changes(Paul Mackerras) o Clean up mdacon (Paul Gortmaker) o Remove duplicate configure.help texts (Steven Cole) o Fix symbol export for shm_file_open (Keith Owens) o First batch of pointer reference bug fixes (Andrew Morton) from Stanford report o Fix de4x5 oops on Alpha XP1000 (George France) o Chipsfb update (Paul Mackerras) o Fix higmem block_prepare_write crash(Stephen Tweedie) o Bring PAE36 back up to date, handle x86 errata (Ingo Molnar) o Fix ov511 crash if opened while loading (Pete Zaitcev) o Merge Linus 2.4.3pre8 o Update Advansys scsi driver (Bob Frey) 2.4.2-ac24 o Fix build bug with tsc in ac23 (me) o Update contact info for Phil Blundell
Re: kernel panic in 2.4.2
On Thu, 29 Mar 2001, John R Lenton wrote: > When I arrived at my machine tonight it was dead, with a nice > panic on the screen as a greeting. On rebooting I found something > in the logs, which is rare because it said "not syncing". So I'm > assuming this isn't the panic that killed the box, but she > probably knows (of) him, so let's interrogate her anyway: > > Unable to handle kernel paging request at virtual address 00020008 > c0139fad > *pde = > Oops: 0002 > CPU:0 > EIP:0010:[bdput+5/96] > EFLAGS: 00010206 > eax: 0002 ebx: 0002 ecx: ca59a648 edx: c15ddfa4 > esi: c15ddfa4 edi: c97b9428 ebp: c15ddfac esp: c15ddf6c inode with ->i_bdev == 0x2. Very likely to be a one-bit memory corruption. May be hardware, may be not - unfortunately, all we know is that bit 18 in that word had been flipped. Whatever had done that had no idea that word stores the pointer - that's for sure... Check the memory - it _may_ be a hardware problem. - 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: mouse problems in 2.4.2 -> lost byte
On Wed, Mar 28, 2001 at 05:19:33PM -0600, [EMAIL PROTECTED] wrote: > It's been rumoured that Vojtech Pavlik said: > > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote: > > > [EMAIL PROTECTED] wrote: > > > > It's been rumoured that Gunther Mayer said: > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > > > > I am experiencing debilitating intermittent mouse problems & was about > > > > > > > > > > This is easily explained: some byte of the mouse protocol was lost. > > > > > > > Getting resync right is not as easy as detecting zero bytes. You > > > should account for wild protocol variations in the world wide mouse > > > population, too. > > > > The new input psmouse driver can resync when bytes are lost and also > > shouldn't lose any bytes if there are not transmission problems on the > > wire. But this is 2.5 stuff. > > umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be > years away ... and this seems 'minor', wouldn't it be better to > submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x > patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this > cant be more than a few hundred lines of code? Requireing no other > changes to the kernel? To work correctly, this requires to kill the current psaux and keyboard driver, and those two are one file, and are very very builtin into the console system. Thus it's a patch of almost thousand lines to pc_keyb.c and keyboard.c and can't easily added as a CONFIG_ option. Plus, it's very likely the new PS/2 code will break on some systems that have not-so-compatible i8042 chips, so it is really something that can't go in 2.4. And I would love to have it in 2.4, really. -- Vojtech Pavlik SuSE Labs - 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/
kernel panic in 2.4.2
When I arrived at my machine tonight it was dead, with a nice
panic on the screen as a greeting. On rebooting I found something
in the logs, which is rare because it said "not syncing". So I'm
assuming this isn't the panic that killed the box, but she
probably knows (of) him, so let's interrogate her anyway:
Unable to handle kernel paging request at virtual address 00020008
c0139fad
*pde =
Oops: 0002
CPU:0
EIP:0010:[bdput+5/96]
EFLAGS: 00010206
eax: 0002 ebx: 0002 ecx: ca59a648 edx: c15ddfa4
esi: c15ddfa4 edi: c97b9428 ebp: c15ddfac esp: c15ddf6c
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 3, stackpage=c15dd000)
Stack: ca59a640 c0146ef2 0002 ca59a640 c0146f47 ca59a640 c97b9608 c97b9600
c0147179 c15ddfa4 00010f00 0004 36dd ca59a828 c29620c8
c01471a9 c012cde3 0006 0004 0006 0004
Call Trace: [clear_inode+194/220] [dispose_list+59/84] [prune_icache+261/276]
[shrink_icache_memory+33/48] [do_try_to_free_pages+103/124] [kswapd+101/240]
[kernel_thread+40/56]
Code: f0 ff 4b 08 0f 94 c0 84 c0 74 4d f0 fe 0d 60 25 24 c0 0f 88
Using defaults from ksymoops -t elf32-i386 -a i386
Code; Before first symbol <_EIP>:
Code; Before first symbol 0: f0 ff 4b 08 lock
decl 0x8(%ebx)
Code; 0004 Before first symbol 4: 0f 94 c0 sete
%al
Code; 0007 Before first symbol 7: 84 c0 test
%al,%al
Code; 0009 Before first symbol 9: 74 4d je
58 <_EIP+0x58> 0058 Before first symbol
Code; 000b Before first symbol b: f0 fe 0d 60 25 24 c0 lock
decb 0xc0242560
Code; 0012 Before first symbol 12: 0f 88 00 00 00 00 js
18 <_EIP+0x18> 0018 Before first symbol
kernel BUG at exit.c:458!
invalid operand:
CPU:0
EIP:0010:[do_exit+668/680]
EFLAGS: 00010286
eax: 001a ebx: c023d020 ecx: 0002 edx: 0200
activating NMI Watchdog ... done.
cpu: 0, clocks: 1002544, slice: 334181
cpu: 1, clocks: 1002544, slice: 334181
oh, kernel 2.4.2. I'd be using 2.4.2-ac*, but my radeon doesn't
like it (and no I can't report a bug on that, because I have
nothing to repot on that).
Cheers!
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
What you don't know won't help you much either.
-- D. Bennett
-
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-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
I don't mean to walk on folks but I did make a patch that brings the ac27 version from aic7xxx-6.1.5 to aic7xxx-6.1.8. I've compiled it and inserted it and removed it without any of the hanging problems I encountered before. But the tests stopped there, no guarantees from me, I wish I could ;-) Please ignore this if you get something better. I included Mr. Gibbs changelog (for the changes from 6.1.5 to 6.1.8 his log is QUITE detailed.) Thanks to everyone! -- Jeffrey Hundstad Alan Cox wrote: > > What version of the aic7xxx driver is embedded in 2.4.2-ac27? This > > particular issue was fixed just after 6.1.5 was released. > > The last patch you sent to me + small other fixups for aicdb.h. I dont have > time to chase after peoples drivers. If you want a newer aic7xxx in -ac just > mail me a diff to update to it CHANGELOG-6.1.5-6.1.8.gz linux-2.4.2-ac27-aic7xxx-6.1.5-6.1.8.patch.gz
2.4.3-p8 pci_fixup_vt8363 + ASUS A7V "Optimal" = IDE disk corruption
Hi,
I'm running kernel 2.4.3-pre8 on an ASUS A7V (BIOS 1007) motherboard and
recently noticed that it sometimes corrupts my hard disk, an IBM 75GXP on
the onboard PDC20265 IDE controller. The corruption is detectable with a
simple 'dd if=/dev/urandom of=test bs=16384 count=32768; cp test test2 ;
diff test test2'.
I traced the problem to a combination of choosing "Optimal" for the System
Permorfance Setting in the BIOS and the the new pci_fixup_vt8363 added to
arch/i386/kernel/pci-pc.c in kernel 2.4.3-pre3. So I did a bunch of tests
using no pci_fixup function, the pci_fixup_vt8363 function, and the
following subset of pci_fixup_vt8363:
pci_read_config_byte(d, 0x54, );
if(tmp & (1<<2)) {
printk("PCI: Bus master Pipeline request disabled\n");
pci_write_config_byte(d, 0x54, tmp & ~(1<<2));
}
pci_read_config_byte(d, 0x70, );
if(tmp & (1<<2)) {
printk("PCI: Disabled Master Read Caching\n");
pci_write_config_byte(d, 0x70, tmp & ~(1<<2));
}
The results for me:
Normal Optimal
-- ---
no pci_fixupno corruption no corruption
pci_fixup_vt8363 subset corruption corruption
pci_fixup_vt8363no corruption corruption
At this point my skills and perseverance gave out, but if someone would
like me to do a few more specific tests, I could.
Below is the output of 'lspci -xxx -s 0:0' on this hardware, with no
pci_fixup, for both the Normal and Optimal BIOS settings, in the form of a
unified diff. Hopefully this will shed some light on what the BIOS is
doing, as we don't see to have pci_fixup_vt8363 quite right yet.
Cheers,
Wayne
[root@pizza /mnt]# diff -u --unified=20 normal optimal
--- normal Wed Mar 28 20:37:57 2001
+++ optimal Wed Mar 28 20:35:32 2001
@@ -1,18 +1,18 @@
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00
10: 08 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 33 80
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 17 a4 6b b4 07 89 20 20 80 80 10 10 10 10 20 20
-60: 33 ff 55 a0 d4 d4 d4 00 40 78 86 2f 08 23 00 00
-70: d8 c0 cc 0d 0e a1 d2 00 01 b4 09 02 00 00 00 03
+60: 33 ff 55 a0 d4 d4 d4 00 44 5c 86 2f 08 23 00 00
+70: de c0 cc 0d 0e a1 d2 00 01 b4 19 02 00 00 00 03
80: 0f 40 00 00 c0 00 00 00 03 00 25 1f 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 6e 02 14 00
b0: 62 ec 80 e5 32 33 28 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 91 06
-
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/
kernel oops during kfree_skbmem
I posted the following to tcpdump-workers. They think I should ask here... I was almost certain the following kernel oops occurred during packet capture. The packet received was an arp request. Syslog indicated the kernel received the arp request. My pcap application captures arp packet as well. The calls leading to the oops : pcap_dispatch ... sys_recvfrom ... kfree_skbmem ...free_block. The oops happened on a box running Linux 2.4.0 and libpcap-0.6.2 (which uses AF_PACKET socket). The decoded call stack of the oops is below. The oops does not happen all the time. However, on another box running 2.4.0-test7 and the same application, there is a memory leak. TOP reports memory used by my application stable at 0.3%, but system memory usage keeps going up (reaching 250M used, 4M free before staying there). Does this look like a libpcap problem or skbmem problem? Are there two copies of the same packet when I do packet capture? >>EIP; c012c504<= Trace; c011b77a Trace; c012c82a Trace; c01d00fd Trace; c01d024b <__kfree_skb+f3/f8> Trace; c01d0d1d Trace; c0203a61 Trace; c01cd441 Trace; c0203928 Trace; c01ce2fd Allen Lau - 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-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
>> What version of the aic7xxx driver is embedded in 2.4.2-ac27? This >> particular issue was fixed just after 6.1.5 was released. > >The last patch you sent to me + small other fixups for aicdb.h. I dont have >time to chase after peoples drivers. If you want a newer aic7xxx in -ac just >mail me a diff to update to it I don't recall ever sending you diffs for the driver. My guess is that 6.1.5 got integrated into -ac from Linus' tree. Up to now, I haven't been tracking -ac kernels. I started sending diffs to Linus based on the pre series kernels. No-one has requested patch sets against -ac kernels, but if I need to support this branch, I'll start generating them and passing them your way. Chasing after all of the kernel versions can be time consuming for driver developers too. ;-) -- 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/
Re: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
On Thu, 29 Mar 2001, Alan Cox wrote: > Was anything between 12 and 18 stable ? I didn't actually try them; I jumped right from 12 to 18, and when that and 19 died, I went back to 12. But a quick look suggests that the entire patch I'd applied to 12 and got a hang with was in 13, including the pm.c change. I also haven't tried anything after 24; is it likely to have been fixed? -- Paul Cassella - 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: mouse problems in 2.4.2 -> lost byte
>> The new input psmouse driver can resync when bytes are lost and also >> shouldn't lose any bytes if there are not transmission problems on the >> wire. But this is 2.5 stuff. > >umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be >years away ... and this seems 'minor', wouldn't it be better to >submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x >patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this >cant be more than a few hundred lines of code? Requireing no other >changes to the kernel? Its more than a few hundred lines. Mind you it wouldn't be hard to patch 2.4.X to use the new PS/2 drivers but it is a pretty big change. I seriously don't it would go in. Your welcomed to try out these drivers. I have personally been using these new PS/2 drivers for several months now with now problems. In fact this driver can trick my i8042 chipset to allow me to plug two PS/2 keyboards in :-) MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - 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: Plans for 2.5
> I got some questions. When are we going to develop stuff for 2.5? What >is planed? My opinion for linux 2.5 should be performance. Since linux >already is stable or well done for nature, we could thing more on >performance to be a diferencial over others. What do you people thing? 2.5.X will start once Linus see 2.4.X being stable enough for him to move on. For me I'm working on rewriting the console layer. The two biggest parts to this are one cleanup of the fbcon layer to be much smaller and leaner. This is very much needed especially for graphical embedded devices that need as small a kernel as possible. We also need to deal with the latency issues fbcon suffer so badly from. Part of the changes is that each fbdev driver will have console code moved out of it and into fbcon.c. This makes for a much smaller and faster fbdev driver. Another bonus for this is it is possible to the /dev/fb interface and not use fbcon. This means you can use vgacon and open /dev/fb and have a graphical session and then close it and get back to vgacon. This is a nice feature especially when debugging fbdev drivers. A even more important function for this is again embedded devices. Most graphical embedded devices have a graphical display but no keyboard. Instead they use a touch screen. Here a framebuffer console doesn't make sense. What does make sense is if we have /dev/fb and a /dev/event interface for the touch screen. Here we would then use for the console a serial port or maybe even a network console driver. The second part is is the porting of all the input devices over to the input api. This allows for a consistant api for all input devices. This will greatly cleanup up the mess of drivers/char/keyboard.c. The code in keyboard.c will grab events from keybaord input devices and send them to the correct VT. Again this is very important for embedded devices. Since a large part of X server design is centered around the idea of input devices this will allow the developement of micro X servers. Also with the /dev/eventX interface we can have direct input for glut with OpenGL. Like direct rendering you will get a enormous performance boost. This will very important for porting linux over to game consoles. It will also allow for fast gaming or more the more serious better interactivity for things like molecular simulators on PCs using linux. For embedded devices that can't afford to run X it can directly use /dev/fb and /dev/event without the need to mess around with the console system. Also the micro X servers will not have to as well mess with the console system as well. Of course smaller leaner graphical systems will come to the PC as well. Meaning much better X servers in the future (*hint hint*) :-) MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - 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-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
> What version of the aic7xxx driver is embedded in 2.4.2-ac27? This > particular issue was fixed just after 6.1.5 was released. The last patch you sent to me + small other fixups for aicdb.h. I dont have time to chase after peoples drivers. If you want a newer aic7xxx in -ac just mail me a diff to update to it - 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: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
> I have had hangs under 2.4.2-ac18, -ac19, and -ac24, after uptimes of > 36 hours, 12 hours, and 10 hours, respectively. -ac12 has twice run > for a week without crashing. I didn't see anything in the later -ac > changelogs that looks responsible, but I haven't actually tried them. Was anything between 12 and 18 stable ? > A few lines earlier in this function, inode->i_op->truncate() is called > without lock_kernel(). Should it also have a lock_kernel(), or is it not > needed there? Absolutely correct. The lock is missing. Bizarrely Al Viro just noticed this about 15 minutes ago - 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: Incorrect mdelay() results on Power Managed Machines x86
> I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz. > Could udelay use that, or are there other timers that are better (maybe > without the ACPI dependency)? We could use that if ACPI was present. It might be worth exploring. Is this PM timer well defined for accesses ? - 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: fbcon slowness [was NTP on 2.4.2?]
>Are you using fbcon? If so, and if it goes away after starting X, then it >is the "fbcon kills interrupt latency" problem. Ug!!! This is getting bad. Give me some time. I plan on releasing a new vesafb using MMX to help speed up the drawing routines. It will help alot with the latency issues. I also know using ARM assembly we can greatly reduce the latency issues. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - 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-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
>aic7xxx_osm.h:#define AIC7XXX_DRIVER_VERSION "6.1.5" Pick up the latest from here: http://people.FreeBSD.org/~gibbs/linux/ -- 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/
Re: mouse problems in 2.4.2 -> lost byte
>So you recommend to connect the mouse to USB (instead of psaux) because >psaux+Xfree86 are losing bytes under circumstances (e.g. some load >pattern). > >This is a fine solution for users with dual protocol mice, but doesn't >resolve the problem for other poor ps/2 mouse owners ! You misunderstood me. For 2.4.X it is: Real PS/2 mouse -> /dev/psaux -> PS/2 protocol -> X server All mice using /dev/input/mice -> PS/2 protocol -> X server Yes mice. I have had 5 mice attached and going to the X server. It was no problem. Multiple keyboards, well that is another story :-( It doesn't matter to the X server if two different devices are sending the same protocol. Since the protocol is coming in from two different devices theri is no conflict. I believe we was having problems with another type of mouse. >Even with PS/2 mouse support in the "new input" driver I wouldn't expect >the psaux-byte-lost bug to disappear magically. I see Vojtech has answered this already. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - 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: Larger dev_t
> Why do you worry about installers? New distro - new kernel - new > installer Because the same code tends to be shared with post install configuration tools too. - 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-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
aic7xxx_osm.h:#define AIC7XXX_DRIVER_VERSION "6.1.5" "Justin T. Gibbs" wrote: > >Hello, > > > >I'm using Linux-2.4.2-ac27 SMP compiled with gcc version 2.95.2 2220 > >(Debian GNU/Linux). > > What version of the aic7xxx driver is embedded in 2.4.2-ac27? This > particular issue was fixed just after 6.1.5 was released. > > -- > 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/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
>Hello, > >I'm using Linux-2.4.2-ac27 SMP compiled with gcc version 2.95.2 2220 >(Debian GNU/Linux). What version of the aic7xxx driver is embedded in 2.4.2-ac27? This particular issue was fixed just after 6.1.5 was released. -- 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/
Re: via-rhine driver: wicked 2005 problem
On Mon, Mar 26, 2001 at 11:51:02AM -0500, Jeff Garzik wrote: > > If the problem is still not solved, could you download via-diag.c and > libmii.c from ftp://www.scyld.com/pub/diag/ Compile instructions are > at the bottom of via-diag.c. I'm interested in seeing two via-diag > register snapshots, one from a cold boot (where it is working), and one > from a warm boot. > > ./via-diag -maaavvveef > via-diag-cold.txt > and > ./via-diag -maaavvveef > via-diag-warm.txt > then >diff -u v*cold.txt v*warm.txt | send mail... > > And to see if the PCI configuration registers change between warm boot > and cold boot, run lspci from pciutils: > > lspci -vvvxxx > lspci-cold.txt > and > lspci -vvvxxx > lspci-warm.txt > then > diff -u l*cold.txt l*warm.txt | send mail... I still have the boot problem, these are the diffs you asked for. I hope they are useful. (using 2.4.3-pre8) I had to include the driver in the kernel, and could not load it as module, I don't know why. == [root@twisted /root]# modprobe via-rhine /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: unresolved symbol alloc_etherdev /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: unresolved symbol unregister_netdev /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: unresolved symbol register_netdev /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: insmod /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o failed /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: insmod via-rhine failed == --- lspci-cold.txt Thu Mar 29 04:10:49 2001 +++ lspci-warm.txt Thu Mar 29 04:08:04 2001 @@ -65,7 +65,7 @@ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 -40: 08 01 00 00 00 80 60 e6 05 01 84 00 00 00 f0 f3 +40: 08 01 00 00 00 80 60 ee 05 01 84 00 00 00 f0 f3 50: 00 00 04 00 00 a0 0b f0 00 06 ff 08 50 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 05 1e 00 02 00 00 f0 40 00 00 00 00 @@ -115,7 +115,7 @@ 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 40: 20 84 5c 00 ba 70 00 00 01 40 00 00 d8 10 00 00 -50: 00 fe ff 88 50 04 00 00 00 ff ff 00 00 00 00 00 +50: 00 ff ff 88 50 04 00 00 00 ff ff 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 00 02 00 00 00 00 00 70: 01 60 00 00 01 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --- via-diag-cold.txt Thu Mar 29 04:10:31 2001 +++ via-diag-warm.txt Thu Mar 29 04:07:26 2001 @@ -1,24 +1,19 @@ via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a VIA VT3065 Rhine-II adapter at 0xec00. - Station address 00:50:ba:1e:91:1b. + Station address 00:00:00:00:00:00. Tx disabled, Rx disabled, half-duplex (0x0804). Receive mode is 0x00: Unknown/invalid. Transmit mode is 0x00: Normal transmit, 128 byte threshold. VIA VT3065 Rhine-II chip registers at 0xec00 - 0x000: 1eba5000 1b91 0804 + 0x000: 0804 0x020: 0400 0x040: ffd7dffa - 0x060: 0e091108 9f00 0880 0247 + 0x060: 0e09131f 8100 0880 0247 No interrupt sources are pending (). Access to the EEPROM has been disabled (0x80). Direct reading or writing is not possible. EEPROM contents (Assumed from chip registers): -0x100: 00 50 ba 1e 91 1b 00 00 00 00 00 00 00 00 00 00 +0x100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x110: 00 00 00 00 00 00 00 00 09 0e 00 00 47 02 73 73 - mdio_read(0xec00, 0, 1).. mdio_read(0xec00, 1, 1).. mdio_read(0xec00, 2, 1).. mdio_read(0xec00, 3, 1).. mdio_read(0xec00, 4, 1).. mdio_read(0xec00, 5, 1).. mdio_read(0xec00, 6, 1).. mdio_read(0xec00, 7, 1).. mdio_read(0xec00, 8, 1).. MII PHY found at address 8, status 0x782d. - mdio_read(0xec00, 9, 1).. mdio_read(0xec00, 10, 1).. mdio_read(0xec00, 11, 1).. mdio_read(0xec00, 12, 1).. mdio_read(0xec00, 13, 1).. mdio_read(0xec00, 14, 1).. mdio_read(0xec00, 15, 1).. mdio_read(0xec00, 16, 1).. mdio_read(0xec00, 17, 1).. mdio_read(0xec00, 18, 1).. mdio_read(0xec00, 19, 1).. mdio_read(0xec00, 20, 1).. mdio_read(0xec00, 21, 1).. mdio_read(0xec00, 22, 1).. mdio_read(0xec00, 23, 1).. mdio_read(0xec00, 24, 1).. mdio_read(0xec00, 25, 1).. mdio_read(0xec00, 26, 1).. mdio_read(0xec00, 27, 1).. mdio_read(0xec00, 28, 1).. mdio_read(0xec00, 29, 1).. mdio_read(0xec00, 30, 1).. mdio_read(0xec00, 31, 1).. MII PHY #8 transceiver registers: mdio_read(0xec00, 8, 0).. - 3000 mdio_read(0xec00, 8, 1).. 782d mdio_read(0xec00, 8, 2).. 0016 mdio_read(0xec00, 8,
Re: Linux Kernel IRC Room?
On Wed, 28 Mar 2001, David Lang wrote: > how do you hold a real-time chat with people around the world? the fact > that the key people would seldom be on at the same time severly limits > it's usefullness. the mailing list does a pretty good job as is. > > David Lang /me asks 'Dude you assume Linux Sleeps?' hahahaha Andre Hedrick Linux ATA Development - 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 Kernel IRC Room?
how do you hold a real-time chat with people around the world? the fact that the key people would seldom be on at the same time severly limits it's usefullness. the mailing list does a pretty good job as is. David Lang On Wed, 28 Mar 2001, Alexander Valys wrote: > Date: Wed, 28 Mar 2001 20:37:49 -0500 > From: Alexander Valys <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Linux Kernel IRC Room? > > Is there a kernel development irc room anywhere? If not, does anyone think > it might 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/ > - 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 Kernel IRC Room?
On Wed, 28 Mar 2001, Alexander Valys wrote: > Is there a kernel development irc room anywhere? If not, does anyone think > it might be useful? #kernelnewbies on irc.openprojects.net. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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/
Wireless Extension update...
Hi, Now that I got away from IrDA, I've been taking care of my todo list on the Wireless side. The most critical feature is versionning. Since distributions started shipping separate kernel header in /usr/include/linux, drivers and tools can be out of sync (== core dump when reading iwrange). A lot of user have been caught by that moving from 2.2.X to 2.4.X. This patch provide a way to detect that and to fix the problem. Also, I added a new extension (retry), and implemented it in the orinoco_cs driver. However, it is not enabled in orinoco_cs (has_retry=0) because we are in stable kernels ;-) Would you mind adding that in the kernel ? Thanks... Jean P.S. : A new version of Wireless Tools with all those goodies will be soon on my web page... diff -u -p linux/include/linux/wireless.25.h linux/include/linux/wireless.h --- linux/include/linux/wireless.25.h Wed Mar 28 10:33:47 2001 +++ linux/include/linux/wireless.h Wed Mar 28 17:31:42 2001 @@ -1,7 +1,7 @@ /* * This file define a set of standard wireless extensions * - * Version : 9 16.10.99 + * Version : 11 28.3.01 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> */ @@ -63,7 +63,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 10 +#define WIRELESS_EXT 11 /* * Changes : @@ -111,6 +111,11 @@ * - Add PM modifier : MAX/MIN/RELATIVE * - Add encoding option : IW_ENCODE_NOKEY * - Add TxPower ioctls (work like TxRate) + * + * V10 to V11 + * -- + * - Add WE version in range (help backward/forward compatibility) + * - Add retry ioctls (work like PM) */ /* -- IOCTL LIST -- */ @@ -162,6 +167,8 @@ #define SIOCGIWFRAG0x8B25 /* get fragmentation thr (bytes) */ #define SIOCSIWTXPOW 0x8B26 /* set transmit power (dBm) */ #define SIOCGIWTXPOW 0x8B27 /* get transmit power (dBm) */ +#define SIOCSIWRETRY 0x8B28 /* set retry limits and lifetime */ +#define SIOCGIWRETRY 0x8B29 /* get retry limits and lifetime */ /* Encoding stuff (scrambling, hardware security, WEP...) */ #define SIOCSIWENCODE 0x8B2A /* set encoding token & mode */ @@ -272,6 +279,16 @@ #define IW_TXPOW_DBM 0x /* Value is in dBm */ #define IW_TXPOW_MWATT 0x0001 /* Value is in mW */ +/* Retry limits and lifetime flags available */ +#define IW_RETRY_ON0x /* No details... */ +#define IW_RETRY_TYPE 0xF000 /* Type of parameter */ +#define IW_RETRY_LIMIT 0x1000 /* Maximum number of retries*/ +#define IW_RETRY_LIFETIME 0x2000 /* Maximum duration of retries in us */ +#define IW_RETRY_MODIFIER 0x000F /* Modify a parameter */ +#define IW_RETRY_MIN 0x0001 /* Value is a minimum */ +#define IW_RETRY_MAX 0x0002 /* Value is a maximum */ +#define IW_RETRY_RELATIVE 0x0004 /* Value is not in seconds/ms/us */ + /** TYPES **/ /* --- SUBTYPES --- */ @@ -385,6 +402,7 @@ struct iwreq struct iw_param rts;/* RTS threshold threshold */ struct iw_param frag; /* Fragmentation threshold */ __u32 mode; /* Operation mode */ + struct iw_param retry; /* Retry limits & lifetime */ struct iw_point encoding; /* Encoding stuff : tokens */ struct iw_param power; /* PM duration/timeout */ @@ -462,6 +480,19 @@ struct iw_range __u16 txpower_capa; /* What options are supported */ __u8num_txpower;/* Number of entries in the list */ __s32 txpower[IW_MAX_TXPOWER];/* list, in bps */ + + /* Wireless Extension version info */ + __u8we_version_compiled;/* Must be WIRELESS_EXT */ + __u8we_version_source; /* Last update of source */ + + /* Retry limits and lifetime */ + __u16 retry_capa; /* What retry options are supported */ + __u16 retry_flags;/* How to decode max/min retry limit */ + __u16 r_time_flags; /* How to decode max/min retry life */ + __s32 min_retry; /* Minimal number of retries */ + __s32 max_retry; /* Maximal number of retries */ + __s32 min_r_time; /* Minimal retry lifetime */ + __s32 max_r_time; /* Maximal retry lifetime */ }; /* diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c --- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001 +++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001 @@
Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
Hello, I'm using Linux-2.4.2-ac27 SMP compiled with gcc version 2.95.2 2220 (Debian GNU/Linux). After an "insmod aic7xxx" "cat /proc/bus/pci/devices" works just fine. After an "rmmod aic7xxx" "cat /proc/bus/pci/devices" fails to produce any output and never finishes. Top show the process in R state taking as much CPU as it can get. Killing the process doesn't do anything, rebooting is the only way to get rid of it. This problem does not happen with aic7xxx_old. Strace shows a "read" on the fd of /proc/bus/pci/devices that never finishes. My aic7xxx devices as reported by "lspci -vvv": 00:12.0 SCSI storage controller: Adaptec AIC-7881U (rev 01) Subsystem: Adaptec: Unknown device 7881 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux Kernel IRC Room?
Is there a kernel development irc room anywhere? If not, does anyone think it might 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: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
Earlier today, I wrote > and no sysrq keys other than B worked; I didn't hear disk activity > after S, and the disks weren't unmounted. Nothing made it to the Of course, when I rebooted this time (after SysRQ S,U,B), all the filesystems were clean. Nothing in the logs this time either though. > When I get home and reboot (following this most recent hang :( ), I'll > put the diff, .config, and more stuff from /proc at > http://manetheren.eigenray.com/~fortytwo/crash-12-18.2 This is now there. -- Paul Cassella - 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: RFC: configuring net interfaces
From: "Krzysztof Halasa" <[EMAIL PROTECTED]>
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> + unsigned int clock_rate;
> + unsigned short clock_type;
> +};
What about encoding (NRZ/NRZI)?
Plus I think the CRC type would be a good idea for
raw HDLC mode. (CRC-16, CRC-32, no CRC)
Paul Fulghum
[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: RFC: configuring net interfaces
On Wed, 28 Mar 2001, Jeff Garzik wrote: > Ivan Passos wrote: > > Maybe it's a better idea to have just two ioctl's here (GET and SET), and > > have "subioctl's" inside the structure passed to the HDLC layer (and > > defined by the HDLC layer). This would allow changes in the HDLC layer > > without having to change sockios.h (you'd still have to change HDLC's > > code and definitions, but this would be more self-contained). Again, this > > may be better, or maybe not. What do you think? > > That's essentially what's happening with ethtool > (include/linux/ethtool.h in 2.4.3-pre8) Then maybe it's really a better idea, after all. ;) Krzysztof, please let us know what you think. Regards, Ivan - 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: RFC: configuring net interfaces
Ivan Passos wrote: > Maybe it's a better idea to have just two ioctl's here (GET and SET), and > have "subioctl's" inside the structure passed to the HDLC layer (and > defined by the HDLC layer). This would allow changes in the HDLC layer > without having to change sockios.h (you'd still have to change HDLC's > code and definitions, but this would be more self-contained). Again, this > may be better, or maybe not. What do you think? That's essentially what's happening with ethtool (include/linux/ethtool.h in 2.4.3-pre8) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: Not MTRR !? was: ISSUE: very slow (factor 100) 4-way 16GByte server, with 2.4.2
Rik van Riel <[EMAIL PROTECTED]> writes: > On Wed, 28 Mar 2001, Robert Suetterlin wrote: > > reg00: base=0xfb00 (4016MB), size= 16MB: uncachable, count=1 > > reg01: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 > > reg02: base=0x ( 0MB), size=8192MB: write-back, count=1 > > reg03: base=0x2 (8192MB), size=4096MB: write-back, count=1 > > reg04: base=0x3 (12288MB), size=2048MB: write-back, count=1 > > reg05: base=0x38000 (14336MB), size=1024MB: write-back, count=1 > > reg06: base=0x3c000 (15360MB), size= 512MB: write-back, count=1 > > reg07: base=0x3e000 (15872MB), size= 256MB: write-back, count=1 >-- + > 15.75 GB > > It looks like the last 256MB isn't cached (well, it doesn't > have an MTRR at all) and Linux starts loading programs from > the top of memory ... It looks like the BIOS ran out of MTRRs. I suspect this is one of the reasons that Intel changed the PPro spec to allow overlapping MTRRs in some cases, with uncached taking precedence. The following sequence of /proc/mtrr commands should give the same uncachable range with all memory write-back cached: # cat >/proc/mtrr disable=2 disable=3 disable=4 disable=5 disable=6 disable=7 base=0 size=0x4 type=write-back base=0x4 size=0x400 type=write-back base=0x40400 size=0x100 type=write-back ^D (I think all those zeros are correct. 0x4 == 16GB, 0x400 == 64MB, 0x100 == 16MB) It's probably also worth seeing if a BIOS update is available. Dave Wragg - 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: Ideas for the oom problem
> On Wed, Mar 28, 2001 at 06:33:04PM -0500, Hacksaw wrote: > Why are they logged in as root in the first place? Is there something they > can't do over sudo? I have the "Gnome workstation" version of rawhide (7.0.xxx) on my new laptop. I don't see sudo. Of course, it's rawhide, but you'd think, if it were in 7.0, it'd make it. Or maybe they decided that the gnome workstation didn't need it... Hmmm. > I definitely remember seeing a document saying `if you find yourself needing to > `man foo', do it in another terminal as your non-root self'; it might or might > not've been the SAG. Sucks if you are trying to figure out a VT problem. > In any case, what happened to `if you use this rope you will hang yourself'? > There has to be a point where you abandon catering for all kinds of fool and > get on with writing something useful, I think. Let's accept one thing: Root, should in fact, be allowed to do anything a regular user can. The fact that hanging is a possibility might ought to be pointed out. I have my shell set up to tell me I'm root. But the fact is, the typical sys-admin is essentially always logged in as root somewhere, and changing terminals to look at man pages is sometimes not an option. For that matter, I have often figured out that something had funny permission problems by discovering that the problem goes away if I run a program as root. Assuming everything root is doing must be sacrosanct is a pipe dream. Assuming everything a regular user is doing is expendable is BOFH think. I do agree that you have to draw a line. I'm just saying that's the wrong one. > > I completely agree that doing general work as root is a bad idea. I do most > > root things via sudo. It sure would be nice if all the big dists supplied it > > (Hey, RedHat! You listening?) as part of their normal set. > > RH have been listening since v7.0. Good. I hope it comes out well in 7.1, considering my experience with rawhide. - 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: RFC: configuring net interfaces
On 28 Mar 2001, Krzysztof Halasa wrote:
>
> What about a patch like this:
> That would move interface configuration out of private ioctl range,
> making it universal for all types of interfaces (now, we have different
> configuration mechanisms even between different HDLC cards).
Yes! This would be great.
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> + unsigned int clock_rate;
> + unsigned short clock_type;
> +};
I guess 'interface' means media type (e.g. V.35, RS-232, X.21, etc.).
Maybe it would be more intuitive to call it 'media'. What do you think?
Also, for synchronous cards that have built-in DSU/CSU's (such as the
Cylades-PC300/TE), it's also necessary to configure T1/E1 parameters
(e.g. line code, frame mode, active channels, etc.). Should we make these
parameters also available here or keep them in the driver realm?? I think
we should have them here too, but maybe you see some problem with this
that I don't. Please advice.
> +struct hdlc_protocol /* 4 bytes */
> +{
> + unsigned int proto;
> +};
What are the possible protocols to be set here?? I imagine PPP, Cisco
HDLC, Raw HDLC, Frame Relay, X.25, and ... ?? Is that it??
> +struct fr_protocol /* 12 bytes */
> +{
> + unsigned short lmi_type;
> + unsigned short t391;
> + unsigned short t392;
> + unsigned short n391;
> + unsigned short n392;
> + unsigned short n393;
> +};
So we would have hdlc_protocol->proto set to PROTO_FR, and then the
details about Frame Relay would be set in this separate structure. Is that
what you have in mind??
> --- linux-2.4.orig/include/linux/sockios.hSun Nov 12 04:02:40 2000
> +++ linux-2.4/include/linux/sockios.h Wed Mar 28 16:35:23 2001
> @@ -76,6 +76,12 @@
> #define SIOCSIFDIVERT0x8945 /* Set frame diversion options */
>
> #define SIOCETHTOOL 0x8946 /* Ethtool interface*/
> +#define SIOCSHDLC_PHY0x8947 /* set physical HDLC iface */
> +#define SIOCGHDLC_PHY0x8948 /* get physical HDLC iface */
> +#define SIOCSHDLC_PROTO 0x8949 /* set HDLC protocol*/
> +#define SIOCGHDLC_PROTO 0x894A /* get HDLC protocol*/
> +#define SIOCSFR_PROTO0x894B /* set Frame-Relay protocol */
> +#define SIOCGFR_PROTO0x894C /* get Frame-Relay protocol */
Maybe it's a better idea to have just two ioctl's here (GET and SET), and
have "subioctl's" inside the structure passed to the HDLC layer (and
defined by the HDLC layer). This would allow changes in the HDLC layer
without having to change sockios.h (you'd still have to change HDLC's
code and definitions, but this would be more self-contained). Again, this
may be better, or maybe not. What do you think?
Regards,
Ivan
-
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: FWD: 3 NIC cards problem
Hi, Thanks!!! That worked. Now I have one more problem... I am using non blcking sockets (set via fcntl). And I am using select (with a 20 second timeout) to see when data is available on the socket. I have 600 clients hitting my web server. Quite frequently, what happens is that some of the sockets that I am waiting on in the select (read or write) just dont have any activity in them for more than 20 seconds or so its like the client never sent any data over or is still waiting to connect. What could I be doing wrong (what are the common mistakes?) Thanks Lee --Original Message-- From: William T Wilson <[EMAIL PROTECTED]> To: Lee Chin <[EMAIL PROTECTED]> Sent: March 28, 2001 9:58:35 PM GMT Subject: Re: FWD: 3 NIC cards problem On Wed, 28 Mar 2001, Lee Chin wrote: > I have a program listening for socket connections on 192.168.1.1, port 80. > > What I want to do is have incomming connection requets for IP 192.168.2.1 > and 192.168.3.1 on port 80 also be handled by my server running on > 192.168.1.1:80 > > How do I do this in Linux? If you use INADDR_ANY in your sockaddr struct that you pass to bind, instead of your IP address, it should listen on all network interfaces. __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - 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-usb-devel] Repeatable lockup on SMP w/usbprocfs
Tony Hoyle wrote: > > If an application calls the USBDEVFS_SUBMITURB ioctl to submit a read, > when the async completion routine is called, the kernel goes into a hard > deadlock (no response to ping, etc.). I've narrowed it down to the > async_completed routine in usb.c. That's the only place where spinlocks > are used. I'm not familiar enough with them to see what the error is, > though. It is async_completed in devio.c btw. I have looked at this too, but I am not sure whether this happens when the completion is called or when the program does a USBDEVFS_REAPURB(NDELAY). I have looked at the code, but I do not see anything obviously wrong. One thing I considered weird is the "wake_up(>wait);" in async_completed(). This will wake up the program that has submitted the urb, whether is expects to be woken or not. I am not sure what the consequences of this are, but it seems harmless enough. > The system runs fine until the packet is returned, then it just locks > solid (On the alcatel USB modem I used for testing it will not respond > until it gets sync, which may be several seconds). I have also noticed this only with the Alcatel SpeedTouch USB driver. I am not aware of any other driver that uses this although I am writing one that will be using this. It is very possible the program does something wrong (For example the code mixes the async and the sync versions of the urb ioctl's...), but even then it is not supposed to be able to lock up the whole machine. > Others have found that just compiling SMP into the kernel is enough to > break it, you don't actually need two processors. Probably because when you turn SMP off, spinlocks are disabled so deadlocks are avoided. J. - 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: Plans for 2.5
On Wednesday, 28 March 2001, at 19:44:52 -0300, Bruno Avila wrote: > Hello people, > > I got some questions. When are we going to develop stuff for 2.5? What is > planed? My opinion for linux 2.5 should be performance. Since linux already > is stable or well done for nature, we could thing more on performance to be > a diferencial over others. What do you people thing? > My two cents. I'd like to see Linux VM subsystem "stabilize". By now, with 2.4.x I have the subjective impression that memory management is a bit worse that on 2.2.x. For example, the kernel starts allocating much swap space even when there is still plenty of free physical RAM. Also, it tends not to balance well between cached/buffered data and swap space. Finally, when an application ends and releases memroy, swap space allocated by this application _seems_ not to be freed (that, AFAIK, is a know issue being addressed). Don't know if this is 2.5.x stuff or can be integrated into later 2.4.x releases. By the way, it has been mentioned in this list that work is underway to develop new capability based features for the kernel. Does it have anything to do with capabilities as provided by LIDS ?. Is there a plan on integrating this and/or other patches in the mainstream kernel ?. Argh, too many things at once, and the worst one is that I can't help a lot on anyone. I expect not to have given developers a bit of extra work :) -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Repeatable lockup on SMP w/usbprocfs
I've enabled spinlock debugging, and generated a nice oops... The USB system is definately doing something wrong somewhere. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv ksymoops 2.3.7 on i686 2.4.2-ac26. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-ac26/ (default) -m /boot/System.map-2.4.2-ac26 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. eip: d28eb1b5 kernel BUG at /usr/src/linux/include/asm/spinlock.h:90! invalid operand: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0038 ebx: cff44710 ecx: c0264ba0 edx: 4e26 esi: cda794bc edi: cff44680 ebp: ffea esp: cd28ded8 ds: 0018es: 0018 ss: 0018 Process mgmt (pid: 408, stackpage=cd28d000) Stack: d28edae0 005a cda793c8 cda794a0 cda793a0 0286 cda794c8 cff44710 0292 cff44680 d28d90e6 cda794bc d28deb1f cda794bc cda793a0 bc70 <4>fdfd cfb69940 0002 8103 Call Trace: [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 f0 fe 0e 88 ee 27 00 00 8b 46 20 83 f8 8d >>EIP; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <= Trace; d28edae0 <[uhci].rodata.start+20/110c> Trace; d28d90e6 <[usbcore]usb_submit_urb+1e/30> Trace; d28deb1f <[usbcore]proc_submiturb+56f/64c> Trace; d28df627 <[usbcore]usbdev_ioctl+1ef/298> Trace; c014d588 Trace; c014d588 Trace; c010756b Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <_EIP>: Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <= 0: 0f 0b ud2a <= Code; d28eb1de <[uhci]uhci_submit_urb+136/3fc> 2: 83 c4 08 add$0x8,%esp Code; d28eb1e1 <[uhci]uhci_submit_urb+139/3fc> 5: f0 fe 0e lock decb (%esi) Code; d28eb1e4 <[uhci]uhci_submit_urb+13c/3fc> 8: 88 ee mov%ch,%dh Code; d28eb1e6 <[uhci]uhci_submit_urb+13e/3fc> a: 27daa Code; d28eb1e7 <[uhci]uhci_submit_urb+13f/3fc> b: 00 00 add%al,(%eax) Code; d28eb1e9 <[uhci]uhci_submit_urb+141/3fc> d: 8b 46 20 mov0x20(%esi),%eax Code; d28eb1ec <[uhci]uhci_submit_urb+144/3fc> 10: 83 f8 8d cmp$0xff8d,%eax 1 warning issued. Results may not be reliable.
Re: Ideas for the oom problem
On Wed, Mar 28, 2001 at 06:33:04PM -0500, Hacksaw wrote: > > Anyone working as root is (sorry) an idiot! root's processes are normally > > quite system-relevant and so they should never be killed, if we can avoid > > it. > > The real world intrudes. Root sometimes needs to look at documentation, > which, these days is often available as html. Sometimes it's only as html. > And people in a panic who aren't trained sys-admins aren't going to remember > to log in as someone else. Why are they logged in as root in the first place? Is there something they can't do over sudo? I definitely remember seeing a document saying `if you find yourself needing to `man foo', do it in another terminal as your non-root self'; it might or might not've been the SAG. In any case, what happened to `if you use this rope you will hang yourself'? There has to be a point where you abandon catering for all kinds of fool and get on with writing something useful, I think. > I completely agree that doing general work as root is a bad idea. I do most > root things via sudo. It sure would be nice if all the big dists supplied it > (Hey, RedHat! You listening?) as part of their normal set. RH have been listening since v7.0. ~Tim - 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: 2.2.18 oops leaves umount hung in disk sleep
OK, some new information. Apparently, the ethernet traffic is getting
corrupted by heavy disk access to the second disk on my primary ALI
5229 controller. I suspect this is related to the oops, as the kernel
log messages reporting the errors tend to come roughly at the same
time as the oopses.
Here is the test: I run netpipe-tcp to the host while running bonnie
on the second disk. I then receive quite a few messages reading:
Mar 28 17:55:33 intech9 kernel: eth0: bogus packet: status=0x80 nxpg=0x6e size=1518
Mar 28 17:56:25 intech9 kernel: eth0: bogus packet: status=0x80 nxpg=0x69 size=1518
The size is always 1518. There are also other less frequent messages
which I can collate if needed. Running thee same test with bonnie on
the first disk does not produce the error. Turning dma off on both
disks does not help.
Here is my disk information:
=
intech9:/proc/ide/ide0/hda# for i in * ; do echo "---"$i"---" ; cat $i ; done
for i in * ; do echo "---"$i"---" ; cat $i ; done
---cache---
512
---capacity---
12672450
---driver---
ide-disk version 1.08
---geometry---
physical 13410/15/63
logical 788/255/63
---identify---
045a 3462 000f 003f
2020 2020 2020 2020 2020 2020
3035 3338 3232 3537 0400 0004 4544
2d30 332d 3038 4655 4a49 5453 5520 4d50
4533 3036 3441 5420 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0b00 0200 0007 3462 000f
003f 5dc2 00c1 5dc2 00c1 0007
0003 0078 0078 0078 0078
001e 346b 4008 4000 0061 4000
041f 0006
0001
---media---
disk
---model---
FUJITSU MPE3064AT
---settings---
namevalue min max mode
- --- ---
bios_cyl788 0 65535 rw
bios_head 255 0 255 rw
bios_sect 63 0 63 rw
breada_readahead4 0 127 rw
bswap 0 0 1 r
file_readahead 124 0 2097151 rw
io_32bit0 0 3 rw
keepsettings0 0 1 rw
max_kb_per_request 64 1 127 rw
multcount 0 0 8 rw
nice1 1 0 1 rw
nowerr 0 0 1 rw
pio_modewrite-only 0 255 w
slow0 0 1 rw
unmaskirq 0 0 1 rw
using_dma 0 0 1 rw
---smart_thresholds---
0010 2001 1402
1903
1004
1805 1407
1308
1409
140a 140c
18c4
14c5
14c6 00c7
14c8
2.4.3-pre8 fails with IPX module
I have tried a compile of the latest test release, and it breaks on the IPX bits. Pre7 was OK. I've got modutils 2.4.2, so it isn't that. Here is the compile log: make -C ipx modules make[2]: Entering directory `/usr/src/lx-2.4.3p8/net/ipx' gcc -D__KERNEL__ -I/usr/src/lx-2.4.3p8/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DEXPORT_SYMTAB -c af_ipx.c af_ipx.c: In function `ipxrtr_route_packet': af_ipx.c:1545: warning: passing arg 4 of `sock_alloc_send_skb' makes integer from pointer without a cast af_ipx.c:1545: too few arguments to function `sock_alloc_send_skb' af_ipx.c: At top level: af_ipx.c:2534: unknown field `sendpage' specified in initializer af_ipx.c:2534: `sock_no_sendpage' undeclared here (not in a function) af_ipx.c:2534: warning: excess elements in struct initializer af_ipx.c:2534: warning: (near initialization for `ipx_dgram_ops') make[2]: *** [af_ipx.o] Error 1 make[2]: Leaving directory `/usr/src/lx-2.4.3p8/net/ipx' make[1]: *** [_modsubdir_ipx] Error 2 make[1]: Leaving directory `/usr/src/lx-2.4.3p8/net' make: *** [_mod_net] Error 2 For any queries mail to [EMAIL PROTECTED] - I could handle a digest but the list is too busy. -- Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775 - 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: Ideas for the oom problem
> --On Wednesday, March 28, 2001 09:38:04 -0500 Hacksaw <[EMAIL PROTECTED]> > wrote: > > > > Deciding what not to kill based on who started it seems like a bad idea. > > Root can start netscape just as easily as any user, but if the choice of > > processes to kill is root's netscape or a user's experimental database, > > I'd want the netscape to go away. > > root does not use netscape -FULLSTOP- Making assumptions about what users will do is foolish. > Anyone working as root is (sorry) an idiot! root's processes are normally > quite system-relevant and so they should never be killed, if we can avoid > it. The real world intrudes. Root sometimes needs to look at documentation, which, these days is often available as html. Sometimes it's only as html. And people in a panic who aren't trained sys-admins aren't going to remember to log in as someone else. I completely agree that doing general work as root is a bad idea. I do most root things via sudo. It sure would be nice if all the big dists supplied it (Hey, RedHat! You listening?) as part of their normal set. > There can however be processes owned by other users which shouldn't be > killed in OOM-Situation, but generally root's processes are more important > than a normal user's processes. I'd suggest that this is going to change. Not to regular users, though, so it's still a good point. But we should be figuring out how to compartmentalize all our servers. Rarely do most servers need to run as root. Just login ones, and those should be limited. So which should die, the users experiment, or identd? > What about doing something really critical to avoid the upcoming OOM-situ > and get your shell killed because you were to slow? Right. I agree that roots shell should be exempt. It may be that all shells should be exempt, or maybe all recent shells. Better, though, would be to establish the idea of "linchpins". A linchpin is a process marked with a don't kill for OOM flag (a capability?). Only those in root group should be able to start one. And darn few things should be marked as such. Some very small shell, vi, ed, maybe a small emacs. Just enough so that our heroic admin can gracefully ease the OOM situ by changing a few bits of /etc or killing off a few well chosen processes. On the other hand, a flag that says "kill me first" might be even better. In any case, I'd certainly expect the OOM killer to sort by memory usage, and kill off the hogs first. I assume it does that. - 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/
[horrors] Re: 2.4.2 Patch for missing "proc_get_inode" symbol incomx driver
On Wed, 28 Mar 2001, Jeff Golds wrote: > Folks, > > Sorry if this has been addressed before, but I didn't see this in the > release notes for the latest ac drivers. > > I tried to build the comx driver in the 2.4.2 kernel, but got unresolved > external "proc_get_inode" when I attempted to load the module. Looks > like all that is missing is an EXPORT_SYMBOL entry in procfs_syms.c > > Is there some reason why this function is not being exported or is it > just an error? Yes, there is. It's a helper function used by procfs directory lookups. If you need it - why on the Earth use procfs in the first place? * You have your own directory operations (since procfs ones apparently don't satisfy your needs) * You have your own file operations (since procfs has none) In other words, what the hell does your situation have to procfs (aside of being a filesystem)? So either comx.c is actually OK with procfs directories (in that case it doesn't need proc_get_inode) _or_ it shouldn't use procfs in the first place. Uh-oh... rmdir /proc/comx/foo succeeds (and no, foo is non-empty) and $DEITY help you if it happens in the middle of write() into something in /proc/comx/foo. 'Cause write() will merrily access kfree'd data. Oh, and read() will do the same. Apparently comx.c uses mkdir /proc/comx/foo to register foo and rmdir - to unregister it. Would be nice, except that resulting directory is _not_ empty. And remove_proc_entry() doesn't abort method-in-progress, so said rmdir() leads to interesting effects. Aside of the general bogosity level of rmdir succeeding on non-empty directory. And no, unlink doesn't work on /proc/comx/foo/*. Who the hell had invented that API and could I have some of the stuff they were smoking? OK, is there anyone who would know what userland stuff uses that horror? It really looks like a API in bad need of being changed... Al - 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/
Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
[1.] One line summary of the problem:
Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
[2.] Full description of the problem/report:
I have had hangs under 2.4.2-ac18, -ac19, and -ac24, after uptimes of
36 hours, 12 hours, and 10 hours, respectively. -ac12 has twice run
for a week without crashing. I didn't see anything in the later -ac
changelogs that looks responsible, but I haven't actually tried them.
All the crashes were under X. The machine did not respond to pings,
and no sysrq keys other than B worked; I didn't hear disk activity
after S, and the disks weren't unmounted. Nothing made it to the
logs. In the -ac19 crash, I had run at the console for about 12
hours, and then started X; it crashed within 15 minutes.
In the one crash that happened while I was at the console, X
completely froze, and sound output stopped. In the others, the
monitor was in power-save mode and didn't wake up.
The hangs don't appear to be related to IO load or anything else I can
think of besides X. Each time, there was a distributed.net client
running, and nothing else that was in any way intensive. I don't
believe any sort of updatedb or makewhatis was running during the
crashes, and it never hung overnight when these jobs run.
I ran with -ac12 with nearly 1300 lines of diff narrowed down from
"interdiff -h ac12 ac18" for about 36 hours in console mode; it hung
within 3 hours of starting X.
When I get home and reboot (following this most recent hang :( ), I'll
put the diff, .config, and more stuff from /proc at
http://manetheren.eigenray.com/~fortytwo/crash-12-18.2
This should be sometime around 8PM CST. (If someone wants the diff
now, email me. I have it here, but I don't want to spam the list with
it.)
This diff wasn't "complete"; some modules (ide-cd, at least) weren't
able to load due to missing symbols.
The diff included all the changes referencing bust_spinlocks(), and
everything to do with the console_sem and the console tasklet/tq. This
included all the changes to printk.c.
It also included the following. In -ac18, this is a BUG(), not a
printk(), but I wanted something I could see while X was running. The
message never showed up. I didn't look to see what the effect of
returning -1 here is, though.
diff -u linux.ac/kernel/pm.c linux.ac/kernel/pm.c
--- linux.ac/kernel/pm.c
+++ linux.ac/kernel/pm.c
@@ -150,6 +154,10 @@
{
int status = 0;
int prev_state, next_state;
+
+ if (in_interrupt())
+ {printk("pm_send called from interrupt (0x%p)!\n",
+__builtin_return_address(0)); return -1; }
+
switch (rqst) {
case PM_SUSPEND:
case PM_RESUME:
AFAICT there was nothing else in the diff.
[7.1.] Software (add the output of the ver_linux script here)
Linux manetheren 2.4.2-ac12 #8 Mon Mar 5 20:02:30 CST 2001 i686 unknown
Gnu C 2.95.2
Gnu make 3.79.1
binutils 2.11.90.0.1
util-linux 2.11a
modutils 2.4.2
e2fsprogs 1.19
Linux C Library2.2.2
Dynamic linker (ldd) 2.2.2
Procps 2.0.7
Net-tools 1.59
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded usb-uhci parport_pc lp parport binfmt_misc rtc usbcore
Since I didn't think to copy my .config off the machine, I won't be
able to get to it until tonight. In the meantime, I do remember that
- It's a UP kernel on a UP box
- Celeron kernel and processor
- The hang happens with USB completely disabled
(Though I don't think I ever turned off hotplugging.)
- VTs, console on VT, and console on serial configured
(console was not on serial)
- i810, (Debian unstable) X 4.0.2, with DRI
- PIIX tuning enabled
- Auto-DMA
- No kernel debugging other than SysRq
- No SCSI
- APM was off; don't remember the other pm stuff.
- ecn was on, syncookies off.
- no ip masquerading or firewalling or anything fancy.
- 128M RAM; no HIGHMEM stuff.
I'll be happy to try out patches, configuration changes, and other
suggestions, but I won't be able to tell for three or four days
whether or not it helped.
[7.2.] Processor information (from /proc/cpuinfo):
Single processor,
cpu family : 6
model : 6
model name : Celeron (Mendocino) (466Mhz/66Mhz FSB)
stepping: 5
cpu MHz : 465.265
cache size : 128 KB
[7.3.] Module information (from /proc/modules):
The modules loaded at the -ac24 crash appear to have been
visor 8400 1
usbserial 17488 1 [visor]
parport_pc 18480 1 (autoclean)
lp 6096 1 (autoclean)
parport24704 1 (autoclean) [parport_pc lp]
uhci 21920 0 (unused)
binfmt_misc 5600 0
rtc 5056 0 (autoclean)
usbcore50480 1 (autoclean) [visor usbserial uhci]
from Debian's /var/log/ksymoops
[7.4.] Loaded driver and hardware information
Re: mouse problems in 2.4.2 -> lost byte
It's been rumoured that Vojtech Pavlik said: > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote: > > [EMAIL PROTECTED] wrote: > > > It's been rumoured that Gunther Mayer said: > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > > I am experiencing debilitating intermittent mouse problems & was about > > > > > > > > This is easily explained: some byte of the mouse protocol was lost. > > > > > Getting resync right is not as easy as detecting zero bytes. You > > should account for wild protocol variations in the world wide mouse > > population, too. > > The new input psmouse driver can resync when bytes are lost and also > shouldn't lose any bytes if there are not transmission problems on the > wire. But this is 2.5 stuff. umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be years away ... and this seems 'minor', wouldn't it be better to submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this cant be more than a few hundred lines of code? Requireing no other changes to the kernel? --linas - 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: Incorrect mdelay() results on Power Managed Machines x86
Sounds like the TSC makes a lousy calibration method ;-) I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz. Could udelay use that, or are there other timers that are better (maybe without the ACPI dependency)? Regards -- Andy > -Original Message- > From: Pavel Machek [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 25, 2001 4:07 PM > To: Alan Cox > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Incorrect mdelay() results on Power Managed Machines x86 > > > Hi! > > > > On the ThinkPad 600E (at least), we get a Power Status > Change APM event. > > > > Any reason we couldn't recalibrate the bogomips on a power > status change, > > at least for laptops we know appear to need it (I can make > the DMI code look > > for matches there..) > > Notice that this is not 100% solution. APM is async, and you > might already > did few wrong delays by the time apm event is delivered to you. > > Also notice that at least my toshiba goes low speed (150MHz) on > *) batteries going low > *) overheat > > It goes back to 300MHz at ac power. Another crazy thing: it > goes down to > 35MHz on extreme overheat -- that's factor of 10 change. > -- > Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, > details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. > > - > 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: IDE and APM (standby) incompatibility on thinkpad T21?
Nope, thats not itmy kernel already has that set. Here are the
relevant lines from /usr/src/linux/.config:
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
CONFIG_APM_REAL_MODE_POWER_OFF=y
On Wed, 28 Mar 2001, Tim Wright wrote:
> Rebuild your kernel and make sure CONFIG_APM_ALLOW_INTS is set to "Y".
>
> Tim
>
> On Wed, Mar 28, 2001 at 12:52:05PM -0500, D. Sen wrote:
> > Attempting to 'standby' the machine generates the following
> > syslog messages:
> >
> > Mar 27 23:58:56 localhost kernel: ide_dmaproc: chipset supported
> > ide_dma_lostirq func only: 13
> > Mar 27 23:58:56 localhost kernel: hda: lost interrupt
> >
> > This seems to corrupt the filesystem..
> >
> > Kernel: 2.4.2
> >
> > hdparm -i /dev/hda:
> > /dev/hda:
> > multcount= 16 (on)
> > I/O support = 1 (32-bit)
> > unmaskirq= 1 (on)
> > using_dma= 1 (on)
> > keepsettings = 1 (on)
> > nowerr = 0 (off)
> > readonly = 0 (off)
> > readahead= 8 (on)
> > geometry = 4134/240/63, sectors = 62506080, start = 0
> >
> > Model=IBM-DJSA-232, FwRev=JS8IAD1A, SerialNo=48YBWLA6226
> > Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> > RawCHS=16383/15/63, TrkSize=0, SectSize=0, ECCbytes=4
> > BuffType=DualPortCache, BuffSize=1874kB, MaxMultSect=16, MultSect=16
> > CurCHS=16383/15/63, CurSects=1011810540, LBA=yes, LBAsects=62506080
> > IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> > PIO modes: pio0 pio1 pio2 pio3 pio4
> > DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
> > AdvancedPM=yes: mode=0x9F (159)
> > Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4
> > ATA-5
> >
> > Please CC any responses to [EMAIL PROTECTED]
> >
> > DS
> >
> > -
> > 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/
>
> --
> Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
> IBM Linux Technology Center, Beaverton, Oregon
> Interested in Linux scalability ? Look at http://lse.sourceforge.net/
> "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
>
-
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: RFC: configuring net interfaces
Francois Romieu <[EMAIL PROTECTED]> writes:
> > +struct hdlc_physical /* 10 bytes */
> > +{
> > + unsigned int interface;
> > + unsigned int clock_rate;
> > + unsigned short clock_type;
> > +};
>
> What do you mean with 'interface' ?
That's a physical interface like V.35 or RS232.
> [...]
> > +struct fr_protocol /* 12 bytes */
> > +{
> > + unsigned short lmi_type;
> > + unsigned short t391;
> > + unsigned short t392;
> > + unsigned short n391;
> > + unsigned short n392;
> > + unsigned short n393;
> > +};
> > +
> > +
>
> * n200, t200 ?
What's that?
> Do we put the crc type here ?
I don't think so. Frame Relay uses only standard CRC. Correct me if I'm
wrong.
> > /*
> > * Interface request structure used for socket
> > * ioctl's. All interface ioctl's must have parameter
> > @@ -95,6 +121,9 @@
> > charifru_slave[IFNAMSIZ]; /* Just fits the size */
> > charifru_newname[IFNAMSIZ];
> > char * ifru_data;
> > + struct hdlc_physical hdlc_phy;
> > + struct hdlc_protocol hdlc_proto;
> > + struct fr_protocol fr_proto;
> > } ifr_ifru;
> > };
>
> All the structs or just an union of ?
An (existing) union, of course. That's part of ifmap struct, with
meaning determined by ioctl command code.
> That is: is an SIOCXXX allowed to poke into different structs or not ?
Only one struct at a time :-)
> > --- linux-2.4.orig/include/linux/sockios.h Sun Nov 12 04:02:40 2000
> > +++ linux-2.4/include/linux/sockios.h Wed Mar 28 16:35:23 2001
> > @@ -76,6 +76,12 @@
> > #define SIOCSIFDIVERT 0x8945 /* Set frame diversion options */
> >
> > #define SIOCETHTOOL0x8946 /* Ethtool interface*/
> > +#define SIOCSHDLC_PHY 0x8947 /* set physical HDLC iface */
> > +#define SIOCGHDLC_PHY 0x8948 /* get physical HDLC iface */
>
> What type of operation do you mean by get/set ?
Get/set all device characteristics described by the struct.
For example, get/set interface type, clock type and rate. Or, with
other command(s), get/set Frame-Relay related parameters.
> While we're here, could we agree on the notion of raw hdlc, i.e. :
> - no address, no command. crc present (ARPHRD_RAWHDLC ?);
> - no address, no command, no crc (ARPHRD_PATHOLOGICHDLC ?).
Do we really need another ARPHRD for that?
BTW: What protocol(s) use such CRC-less HDLC?
--
Krzysztof Halasa
Network Administrator
-
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 Patch for missing "proc_get_inode" symbol in comx driver
Folks, Sorry if this has been addressed before, but I didn't see this in the release notes for the latest ac drivers. I tried to build the comx driver in the 2.4.2 kernel, but got unresolved external "proc_get_inode" when I attempted to load the module. Looks like all that is missing is an EXPORT_SYMBOL entry in procfs_syms.c Is there some reason why this function is not being exported or is it just an error? Here's the patch if anyone is interested. *** linux-2.4.2.orig/fs/proc/procfs_syms.c Mon Sep 11 08:41:07 2000 --- linux/fs/proc/procfs_syms.c Wed Mar 28 11:48:17 2001 *** *** 19,24 --- 19,25 EXPORT_SYMBOL(proc_net); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); + EXPORT_SYMBOL(proc_get_inode); static DECLARE_FSTYPE(proc_fs_type, "proc", proc_read_super, FS_SINGLE); -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/
Plans for 2.5
Hello people, I got some questions. When are we going to develop stuff for 2.5? What is planed? My opinion for linux 2.5 should be performance. Since linux already is stable or well done for nature, we could thing more on performance to be a diferencial over others. What do you people thing? Bruno Avila PS: Not a good english. I know! :) - 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: menuconfig snafu?
Dennis writes: > I KNOW this..my point is that menuconfig is not intuitive in providing the > choices. Linux kernel configuration isn't intuitive. menuconfig isn't there to handhold newbies through the process. - 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: New gigabit cards
At 04:20 PM 03/28/2001, Jeff Garzik wrote: >Scott Laird wrote: > > According to the drivers, the 1000TPC uses the NS DP83820. According to > > the DP83820's datasheet, it has a 8k Tx buffer and a 32k Rx buffer. > > That's a bit shy of the 512k-1M that older cards use :-(. At wire speed, > > that means that you'll have to service the NIC's interrupt within ~60 us > > on transmit and ~250 us on receive. That seems rather optimistic. > >Are you assuming one interrupt per packet? > >GigE drivers employ interrupt mitigation, large rings, and sometimes >resort to polling instead of servicing interrupts, and other >techniques. Tiny buffers are ugly, but you can deal with them... No, thats wrong. Its not about servicing the interrupt, its about access to the bus. The cards are busmasters, so the rings and data get pushed into memory directly from the controller. A 32-bit PCI bus is only a 1GB bus...but not really because you cant burst continuously so you can never achieve sustained throughtput of 1Gb.. The data must be output to system ram, but the card must "get" the bus before it can transfer, and there are other devices on the bus. The "buffer" is to handle the backup, ie the time that the card cant transfer data to ram because it doesnt have the bus because another card or your ide controller has it. The larger the buffer, the longer the hold-off period before you have to abort frames. If you fill the buffer, you have to dump the frame and clear the buffer for the next one because there is nowhere to store the bits. On a 64 bit, 66mhz bus (its 8 times faster than 32bit), you can burst data out and you only need the bus 1/8th of the time. On a 32bit bus, you need more buffer space because you need the bus all the time to keep up with the data, which is not actually possible. Ring failures are local issues (ie you must service data faster than it comes in), but thats not hard with todays processors. but having large rings will not alleviate bus failures. As an example, you can do T1 on a PCI bus with almost no buffer (maybe 64 bytes) because the bus is so much faster then the transfer rate that there is very little chance of falling behind. At 1Gb its much different. Dennis - 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: menuconfig snafu?
At 03:36 PM 03/28/2001, you wrote: >On Wednesday 28 March 2001 22:17, Dennis wrote: > > its seems that "make menuconfig" only allows you to select 1 processor > > type. it seems impossible that you cant build a generic kernel that > > supports different processors. Its this just a menuconfig bug? > > > > Dennis > >You pick the lowest common denominator. If you want a kernel that runs >everywhere (x86 arch), pick the plain old 386. > >Or, read the menuconfig help :-) > >CONFIG_M386: >This is the processor type of your CPU. This information is used for >optimizing purposes. In order to compile a kernel that can run on all x86 CPU >types (albeit not optimally fast), you can specify "386" here. > >The kernel will not necessarily run on earlier architectures than the one you >have chosen, e.g. a Pentium optimized kernel will run on a PPro, but not >necessarily on a i486. I KNOW this..my point is that menuconfig is not intuitive in providing the choices. DB >Regards, >also Dennis :-) - 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: FWD: 3 NIC cards problem
On Wed, 28 Mar 2001, Lee Chin wrote: > I have a program listening for socket connections on 192.168.1.1, port 80. > > What I want to do is have incomming connection requets for IP 192.168.2.1 > and 192.168.3.1 on port 80 also be handled by my server running on > 192.168.1.1:80 > > How do I do this in Linux? If you use INADDR_ANY in your sockaddr struct that you pass to bind, instead of your IP address, it should listen on all network interfaces. - 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: Larger dev_t
Alan Cox wrote: > > > Exactly. It's just that for historical reasons, I think the major for > > "disk" should be either the old IDE or SCSI one, which just can show more > > devices. That way old installers etc work without having to suddenly start > > knowing about /dev/disk0. > > They will mostly break. Installers tend to parse /proc/scsi and have fairly > complex ioctl based relationships based on knowing ide v scsi. > > /dev/disc/ is a little un-unix but its clean Why do you worry about installers? New distro - new kernel - new installer that's they job to worry about it. They will change the installer anyway and this kind of change actually is going to simplyfy the code there, I think, a bit. Just kill the old device major suddenly and place it in the changelog of the new kernel that the user should mknod and add it to /dev/fstab before rebooting into the new kernel. Hey that's developement anyway :-) If the developer boots back into the old kernel just other mounts in /dev/fstab will fail no problem for transition here in sight... - 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: mouse problems in 2.4.2 -> lost byte
On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote: > [EMAIL PROTECTED] wrote: > > > > It's been rumoured that Gunther Mayer said: > > > > > > > I am experiencing debilitating intermittent mouse problems & was about > > > ... > > > > Symptoms: > > > > After a long time of flawless operation (ranging from nearly a week to > > > > as little as five minutes), the X11 pointer flies up to top-right corner, > > > > > > > and mostly wants to stay there. Moving the mouse causes a cascade of > > > > spurious button-press events get generated. > > > > > > This is easily explained: some byte of the mouse protocol was lost. > > > > Bing! > > > > That's it! This would also explain why gpm seems to work i.e. correctly > > process the events, even when X11 can't. I will take this up on the > > Xf86 lists ... > > > > > (Some mouse protocols are even designed to allow > > > easy resync/recovery by fixed bit patterns!) > > > > This mouse seems to set every fourth byte to zero, which should allow > > syncing ... > > The fourth byte is propably the wheel or 5 button support, see > http://www.microsoft.com/hwdev/input/5b_wheel.htm > to get a hint about mouse protocol variations. > > Getting resync right is not as easy as detecting zero bytes. You > should account for wild protocol variations in the world wide mouse > population, too. The new input psmouse driver can resync when bytes are lost and also shouldn't lose any bytes if there are not transmission problems on the wire. But this is 2.5 stuff. -- Vojtech Pavlik SuSE Labs - 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: menuconfig snafu?
note also smp is enabled by default... While that's won't break most boxes it will prevent some other things like apm from working... You sorta got to pick your battles... no default kernel config is gonna work for everyone. joelja On Wed, 28 Mar 2001, Brad Johnson wrote: > On Wed, Mar 28, 2001 at 04:07:23PM -0500, Doug McNaught wrote: > > Dennis <[EMAIL PROTECTED]> writes: > > > > > I also find it interesting that the default at kernel.org wont boot on a > > > Pentium...generic should be the default. > > > > The default config is what boots on Linus' machine. Once you realise > > that your life get a lot easier. ;) > > Hmmm... wonder why that's not a Crusoe? ;-} > > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - 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: Larger dev_t
On Wed, 28 Mar 2001, H. Peter Anvin wrote: > Martin Dalecki wrote: > > > > > > devfs -- in the abstract -- really isn't that bad of an idea; after all, > > > > Devfs is from a desing point of view the duplication for the bad /proc > > design for devices. If you need a good design for general device > > handling with names - network interfaces are the thing too look at. > > mount() should be more like a select()... accept()! > > > > And what on earth makes this better? I have always thought the socket > interface to be hideously ugly and full of ad-hockery. Its abstractions > for handle multiple address families by and large don't work, and it > introduces new system calls left, right and center -- sometimes for good > reasons, but please do tell me why I can't open() an AF_UNIX socket, but > have to use a special system call called connect() instead. Aye. The real problem with mount is that it always had been pretty heavy-weight. Especially mount(8). I've done some (very rough) testing on my tree - for ramfs-style filesystem latency of mount(2) is about 20% worse than latency of open(2). And it definitely can be improved - right now I'm interested in getting the code cleaned. mount(8) is a problem, but in nosuid namespace we can seriously cut down on checks in the thing. And I'm very interested in designs that would allow killing /etc/mtab - dropping it would allow very easy mounting. - 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: menuconfig snafu?
At 04:07 PM 03/28/2001, Doug McNaught wrote: >Dennis <[EMAIL PROTECTED]> writes: > > > I also find it interesting that the default at kernel.org wont boot on a > > Pentium...generic should be the default. > >The default config is what boots on Linus' machine. Once you realise >that your life get a lot easier. ;) not THAT makes sense! - 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: Larger dev_t
On Wed, 28 Mar 2001, Martin Dalecki wrote:
> Then please please please demangle other cases as well!
> IDE is the one which is badging my head most. SCSI as well...
>
> Granted I wouldn't mind a rebot with new /dev/* once!
diff -urN linux-2.4.3-p8-pristine/include/linux/major.h
linux-2.4.3-p8/include/linux/major.h
--- linux-2.4.3-p8-pristine/include/linux/major.h Sat Dec 30
11:23:14 2000+++ linux-2.4.3-p8/include/linux/major.hSun Mar 25
22:16:42 2001
@@ -171,4 +171,18 @@
return SCSI_BLK_MAJOR(m);
}
+/*
+ * Tests for IDE devices
+ */
+#define IDE_DISK_MAJOR(M) ((M) == IDE0_MAJOR || (M) == IDE1_MAJOR || \
+ (M) == IDE2_MAJOR || (M) == IDE3_MAJOR || \
+ (M) == IDE4_MAJOR || (M) == IDE5_MAJOR || \
+ (M) == IDE6_MAJOR || (M) == IDE7_MAJOR || \
+ (M) == IDE8_MAJOR || (M) == IDE9_MAJOR)
+
+static __inline__ int ide_blk_major(int m)
+{
+ return IDE_DISK_MAJOR(m);
+}
+
#endif
Well I banged my head and learned a scsi-trick
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: Larger dev_t
Martin Dalecki wrote: > > Then please please please demangle other cases as well! > IDE is the one which is badging my head most. SCSI as well... > > Granted I wouldn't mind a rebot with new /dev/* once! > This seems to me to really be the kind of thing devfs does better than trying to play number games. devfs (and I'm talking in the abstract, not necessarily the existing implementation) can present things in multiple views, using hard links. This is a Good Thing, because it lets you ask different questions and get appropriate answers (one question is "what are my disks", another is "what are my SCSI devices".) As far as IDE is concerned, I repeat my call for "generic ATAPI" to go along with "generic SCSI"... -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: Larger dev_t
> what do other vaguely unix-like systems do? does, say, plan9 have a > better way of dealing with all this? Yes. Normal UNIX has as well. For reffernece see: block ver raw devices on docs.sun.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: New gigabit cards
On Wed, 28 Mar 2001, Gregory Maxwell wrote: > Some of the products seem so new that their manufactuors have little to no > information available about them on their webpage. One that I found, had > conflicting specs and claimed to only have a 32kbyte recieve buffer. Thats the hardware FIFO size. The chained descriptors can of course handle much larger data. FWIW 10/100 chips usually only have 32-128 bytes hardware FIFO, so 32kbytes hardware FIFO is pretty generous. -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/
Re: menuconfig snafu?
On Wed, Mar 28, 2001 at 04:07:23PM -0500, Doug McNaught wrote: > Dennis <[EMAIL PROTECTED]> writes: > > > I also find it interesting that the default at kernel.org wont boot on a > > Pentium...generic should be the default. > > The default config is what boots on Linus' machine. Once you realise > that your life get a lot easier. ;) Hmmm... wonder why that's not a Crusoe? ;-} -- Brad GPG Public Key available at http://mrpenguin.org/keys.php or from certserver.pgp.com PGP signature
Re: Larger dev_t
Alan Cox wrote: > > > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not > > hogging a major number, but letting low-level drivers get at _their_ > > requests directly. > > A major for 'disk' generically makes total sense. Classing raid controllers > as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also > solve a lot of misery And IDE disk ver CD-ROM f and block vers. raw devices and so so at perpetuum. Those are the reaons why the density of majros ver. minors is exactly revers in solaris with respect to the proposal of Linus.. And then we have all those VERY SPARSE static arrays of major versus minor devices information (if you look at which cells from those arrays are used on a running system which maybe about 6-8 devices actually attached!) The main sheer practical problem to changing kdev_t is the HUGE number of in fact entierly differnt drivers sharing the same major and splitting up the minor number space and then hooking devices with differnt block sizes and such on the same major. Many things in the block device layer handling could be simplefied significalty if one could assume for example that all the devices on one single major have the same block size and so on... - 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: Larger dev_t
Linus Torvalds wrote: > > On Tue, 27 Mar 2001, Andre Hedrick wrote: > > > > Am I hearing you state you want dynamic device points and dynamic majors? > > Yes and no. > > We need static structures for user space - from a user perspective it > makes a ton more sense to say "I want to see all disks" than it does to > know that you have to do /dev/hd*, /dev/sd* plus all the extra magic > combinations that can happen (USB etc). > > So in a sense what I'm arguing for is for _stricter_ device numbers to the > outside world. > > But internally, it would be reasonably easy to make a mapping from those > user-visible numbers to a much looser version. > > One example of this is going to happen very early in 2.5.x: the whole > "partitioning" stuff is going to go away from the driver, and into the > ll_rw_block layer as just another disk re-mapping thing. We already do > those kinds of re-mappings for LVM reasons anyway, and partitioning is not > something a disk driver should know about, really. > > And that kind of partitioning mapping automatically means that we'd need > to remap minor numbers, and do it on a per-major basis (because the > partitioning mapping right now is not actually the same between SCSI and > IDE: IDE uses six bits of partitioning, while SCSI uses just four bits). > And once you do that, you might as well start "remapping" major numbers > too. > > So let's say that you have two separate SCSI controllers - they would both > show up on major #8, and different minor numbers. Right now, for example, > controller 1 might have one disk, with minors 0-15 (for the whole disk and > 15 partitions), and controller 2 might have two disks using minors 16-47. > > As it stands now, the SCSI layer needs to do the remapping, and because > the SCSI layer does the remapping, nothing but SCSI layer devices can use > major #8. > > But once you start doing partition mapping in ll_rw_block.c, you might as > well get rid of the notion that "SCSI is major 8". You could easily have > many different drivers, with many different queues, and remap them all to > have major 8 (and different minors) so that it looks simple for a user > that just wants to see SCSI disks. > > Which is not to say that the same disk might not show up somewhere else > too, if anybody wants it to. The _driver_ should just know "unit x on > queue y", and then the driver might do whatever it wants (it might be, for > example, that the driver actually wants to show multiple controllers as > one queue, if the driver really wants to for some reason). And it should > be possible to have two drivers that really have no idea at ALL about each > other to just share the same major numbers. Then please please please demangle other cases as well! IDE is the one which is badging my head most. SCSI as well... Granted I wouldn't mind a rebot with new /dev/* once! - 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: OOM killer???
Szaka writes: > On Tue, 27 Mar 2001, Andreas Dilger wrote: > > Every time this subject comes up, I point to AIX and SIGDANGER - a signal > > sent to processes when the system gets OOM. > > And every time the SIGDANGER comes up, the issue that AIX provides > *both* early and late allocation mechanism even on per-process basis > that can be controlled by *both* the programmer and the admin is > completely ignored. Linux supports none of these... If Linux provided both of those, then people would probably already be happy. > ...with the current model it's quite possible the handler code is still > sitting on the disk and no memory will be available to page it in. Actually, I see SIGDANGER being useful at the time we hit freepages.min (or maybe even freepages.low), rather than actual OOM so that the apps have a chance to DO something about the memory shortage, rather than just waiting around to die. On AIX, if a process gets SIGDANGER without a registered signal handler, the process is terminated. It would be nice to send SIGDANGER to processes when we hit freepages.low (signal ignored by unsupporting apps), and again when we hit freepages.min (signal will terminate usupporting apps), and only after that do we start SIGKILLing processes. However, I'm not sure if the kernel can affect the SIG_DFL actions for apps or not. > at present the SIGDANGER bloat would be just a fake excuse but wouldn't > address the root of problems at all. I see SIGDANGER as being complementary to any other changes to the OOM killer. Obviously, there are some issues with the VM/OOM killer when it is killing processes rather than flushing dirty buffers and such. But even when this is fixed, SIGDANGER is useful for applications which optimistically allocate RAM/swap for cache that can be freed easily. Yes, applications need to be changed to use SIGDANGER, but high-end applications that also run on AIX likely have such code already under "#ifdef SIGDANGER" or similar (I'm thinking Oracle, etc). If not, then you can't expect anyone to start putting it into Linux apps until SIGDANGER actually exists... 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: Can't find modules after moving to 2.4.2
Marcus Ramos <[EMAIL PROTECTED]> writes: > Hello, > > I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except > for the fact that none of the modules in "/etc/modules.conf" are loaded > anymore (although modules were enabled in kernel config). In > "/lib/modules" I see two directories: 2.2.16 and 2.4.2 (which I assume > is the default for modules.conf). However, the "/lib/modules/2.4.2" > contains almost no files, differently from 2.2.16. I guess I've missed > some important step during the installation of 2.4.2, but now I am > confused and can't recover. Can anyboy point me what the missing step is > ? I will be most grateful. Upgrade your modutils. See Documentation/CHANGES. -Doug - 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: Can't find modules after moving to 2.4.2
Make sure you have up to date modutils package. Current version is 2.4.5 - later, jjs Marcus Ramos wrote: > Hello, > > I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except > for the fact that none of the modules in "/etc/modules.conf" are loaded > anymore (although modules were enabled in kernel config). In > "/lib/modules" I see two directories: 2.2.16 and 2.4.2 (which I assume > is the default for modules.conf). However, the "/lib/modules/2.4.2" > contains almost no files, differently from 2.2.16. I guess I've missed > some important step during the installation of 2.4.2, but now I am > confused and can't recover. Can anyboy point me what the missing step is > ? I will be most grateful. > > Thanks in advance, > 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/
slow video since 2.4.2-ac21
After compiling 2.4.2-ac21 I noticed, that aviplay works much slower than before. "benchmark" from avifile shows that video output is about 3 times slower. I tested -ac22, -ac23, ..., -ac27, then 2.4.1, 2.4.2 and few other versions earlier than -ac21. 2.4.2-ac20 x11perf -putimage100 8000 reps @ 0.7736 msec ( 1290.0/sec): PutImage 100x100 square 2.4.2-ac27 x11perf -putimage100 3600 reps @ 1.3980 msec ( 715.0/sec): PutImage 100x100 square 2.2.19 - same result like 2.4.2-ac20 only "-putimage100" shows diffrences, results of "x11perf -scroll100" and "x11perf -rect100" for all kernel versions were similiar My hardware: VIA VT82C586B, K6-2, Voodoo3. My software: XFree86 Version 4.0.99.1 (CVS), glibc-2.1.3, gcc-2.95.3. - 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: porting lmbench test-suit from intel to mips platform.
On Wed, Mar 28, 2001 at 10:22:22AM -0800, Vikash Kumar wrote: > linux kernel- 2.2.12 > processor - pentirum III, 64 MB RAM, 667MHz. Yeah, that's the latest MIPS processor ... > lmbench test suit - used to test the memory bandwidth and latency > measurement for a system. downloaded from : http://www.bitmover.com/lmbench/ > I downloaded and ran this lmbench test suit successfully on intel i386 > platform and i got the result. > Then i installed cross-compiler ( egfcs-mips-linux-1.0.3a-1.i386.rpm and > binutils-mips-linux-2.8.1-1.i386.rpm ) in my intel box for mips platform. > After compiling the suit in intel box ; when i run the test (on mips > platform) the system hangs and the message appears " Setting flush to zero > for ".. > this message is comming from traps.c file in the kernel. > could u please let me know.. > 1. The reason for this message Reason is dirt rotten old or missconfigured kernel. Run a kernel with fpu emulator enabled. > and why the mips system hangs up. Not related to this message. You also didn't say at all what hardware you're running on. > 3. Is there any site where test suites for testing various drivers are > present for MIPS platform. test suite for > network driver(eepro100- 82559) , flash , ide. eepro100 is successfully being used in at least one MIPS system. 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: Larger dev_t
Martin Dalecki wrote: > > > > devfs -- in the abstract -- really isn't that bad of an idea; after all, > > Devfs is from a desing point of view the duplication for the bad /proc > design for devices. If you need a good design for general device > handling with names - network interfaces are the thing too look at. > mount() should be more like a select()... accept()! > And what on earth makes this better? I have always thought the socket interface to be hideously ugly and full of ad-hockery. Its abstractions for handle multiple address families by and large don't work, and it introduces new system calls left, right and center -- sometimes for good reasons, but please do tell me why I can't open() an AF_UNIX socket, but have to use a special system call called connect() instead. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: Larger dev_t
"H. Peter Anvin" wrote: > > Alan Cox wrote: > > > > > Another example: all the stupid pseudo-SCSI drivers that got their own > > > major numbers, and wanted their very own names in /dev. They are BAD for > > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d] > > > and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI > > > > Sorry here I have to disagree. This is _policy_ and does not belong in the > > kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of > > major/minor encoding. If you dont mind kernel based policy then devfs > > with /dev/disc already sorts this out nicely. > > > > IMHO more procfs crud is also not the answer. procfs is already poorly > > managed with arbitary and semi-random namespace. Its a beautiful example of > > why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's > > per device file systems solve that. > > > > In some ways, they make matters worse -- now you have to effectively keep > a device list in /etc/fstab. Not exactly user friendly. > > devfs -- in the abstract -- really isn't that bad of an idea; after all, Devfs is from a desing point of view the duplication for the bad /proc design for devices. If you need a good design for general device handling with names - network interfaces are the thing too look at. mount() should be more like a select()... accept()! - 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: Disturbing news..
On Wed, 28 Mar 2001 [EMAIL PROTECTED] wrote: > Jesse Pollard writes: > > Absolutely true. The only help the checksumming etc stuff is good for is > > detecting the fact afterward by external comparison. > > Don't we already have that to some extent? rpm -ya or rpm -y > on a RedHat system? I'm sure that there is a Debian equivalent. http://www.tripwire.com does exactly this afik. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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/
Ethernet driver tweak for error correction codes
Is it possible to use up the src, dest MAC addresses (12B) and the CRC field (4B?) on a point-to-point full duplex Ethernet link for my own data? I would like to implement an error correction on this, because I'm gonna build a freespace laser link which would run just this way. And i want to use it on foggy days too when there will be a lot of bits fallen out. Is it possible to do it in the kernel somehow cleanly? How should I try to do it? - 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: New gigabit cards
Scott Laird wrote: > According to the drivers, the 1000TPC uses the NS DP83820. According to > the DP83820's datasheet, it has a 8k Tx buffer and a 32k Rx buffer. > That's a bit shy of the 512k-1M that older cards use :-(. At wire speed, > that means that you'll have to service the NIC's interrupt within ~60 us > on transmit and ~250 us on receive. That seems rather optimistic. Are you assuming one interrupt per packet? GigE drivers employ interrupt mitigation, large rings, and sometimes resort to polling instead of servicing interrupts, and other techniques. Tiny buffers are ugly, but you can deal with them... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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/
53c400a datasheet
Hello does anybody here have the datasheet for the 53c400a SCSI bus interface cotroller? I tried to find it on the Net but did not succeed. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - 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: Promise RAID controller howto?
Andre Hedrick wrote: > > On Tue, 27 Mar 2001, Henning P. Schmiedehausen wrote: > > I know, that "input high == UltraATA core, input low = RAID core" > > according to Andre Hedrick but I really don't care about the RAID > > core. I want to use this controller to drive JBOD. > > Wrong, if Promise will opensource the signatures then we map the software > raid against that location and use Linux's soft-raid. FreeBSD supports this ATA-RAID. I have got a printout of the sources here. From where did they get the permissions/code/docs... to put it into their kernel? Currently I am working on kernel 2.4 RAID support for HPT370 (also included in FreeBSD). I hope it will work soon. I want to upgrade to debian-woody. regards, Wilfried PS: You are right, these IDE-RAID "controllers" are pain. - 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: menuconfig snafu?
Dennis <[EMAIL PROTECTED]> writes: > I also find it interesting that the default at kernel.org wont boot on a > Pentium...generic should be the default. The default config is what boots on Linus' machine. Once you realise that your life get a lot easier. ;) -Doug - 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: Larger dev_t
"H. Peter Anvin" wrote: > > This is my opinion on the issue. Short summary: "I'm sick of the > administrative burden associated with keeping dev_t dense." > > Linus Torvalds wrote: > > > > And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every > > device needs a unique number. Do you ever envision seeing that "ls -l" > > taking about 500 billion years to complete? I don't. I don't think you do. > > But that's how ludicrous a 64-bit device number is. > > > > That's how ludicrous a *dense* 64-bit device number is. I have to say I > disagree with you that sparse number spaces are a bad idea. The > IPv4->IPv6 transition people have looked at the issues of number spaces > and how much harder they get to keep dense when the size of the > numberspace grows, because your lookup operation becomes so much more > painful. Any time you have to take a larger number space and squeeze it > into a smaller number space, you get some serious pain. > > Part of the reason we haven't -- quite -- run out of 8-bit majors yet is > because I have been an absolute *bastard* with registrants lately. It > would cut down on my workload if I could assign majors without worrying > too much about whether or not that particular driver is really going to > be made public. > > 64 bits is obviously excessive, but I really don't feel comfortable > saying that only 12 bits of major is sufficient. 16 I would buy, but I > don't think 16 bits of minor is sufficient. Given that, it seems to me > -- especially since dev_t isn't exactly the most accessed data type in > the universe -- that the conceptual simplicity of keeping the major and > minor separate in individual 32-bit words really is just as well. YES, > it's overengineering, but the cost is very small; the cost of > underengineering is having to go through yet another painful transition. > Unfortunately, the Linux community seems to have some serious problems > with getting system-wide transitions to happen, especially the ones that > involve ABI changes. This needs to be taken into account. > > -hpa Then just tell me please why the PCI name space is just 32 bit? Majros are for drivers Minors are for device driver instances (yes linux does split minors in a stiupid way by forexample using the same major for IDE disks and ide CD-ROM, which are in fact compleatly different devices just sharing driver code... (Dirrerent block sizes, different interface protokoll and so on) Those are the reaons solaris is using a split 24/12 (Major/Minor) and they don't have our problems here. > > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > 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/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - 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: Can't find modules after moving to 2.4.2
On Wed, 28 Mar 2001, Marcus Ramos wrote: > I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except > for the fact that none of the modules in "/etc/modules.conf" are loaded > anymore (although modules were enabled in kernel config). In upgrade modutils. current is 2.4.5 -- -- 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: New gigabit cards
On Wed, 28 Mar 2001, Gregory Maxwell wrote: > > Asante: > FriendlyNet GigaNIX 1000TPC (Cu) $149.99 > Interesting -- this seems to be the only card of the set that actually has drivers available for download, although the D-Link card has drivers for an older GigE card listed. According to the drivers, the 1000TPC uses the NS DP83820. According to the DP83820's datasheet, it has a 8k Tx buffer and a 32k Rx buffer. That's a bit shy of the 512k-1M that older cards use :-(. At wire speed, that means that you'll have to service the NIC's interrupt within ~60 us on transmit and ~250 us on receive. That seems rather optimistic. Scott - 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: Incorrect mdelay() results on Power Managed Machines x86
Hi! > > During resume the IBM thinkpad with the cs46xx driver needs > > to delay 700 > > milleseconds, so if the machine is booted up on battery power, then to > > ensure that the delay is long enough, then a value of 3000 > > milleseconds is > > must be programmed into the driver (3 seconds!). all the > > mdelay and udelay > > wait times are incorrect by the same factor, resulting in some serious > > problems when attempting to wait specific delay times in > > other parts of the > > driver. > > Well yes this is a problem, but only when starting out with a low effective > CPU freq and going high - the reverse is usually OK because longer than > anticipated waits are OK. > > However, you can alleviate this problem by not using udelay (or mdelay) but > using a kernel timer. I would think you should be doing this anyway (700ms > is a LONG TIME) but this should also work regardless of effective CPU freq. Going from 59usec to 19usec is probably as fatal as going from 10sec to 3sec. > A grep of the kernel source shows cs46xx isn't even doing the biggest > mdelay. I can understand the use of spinning on a calibrated loop for less > than a clock tick, but I gotta think there are better ways for longer > periods. > > I wonder if there is a way to modify mdelay to use a kernel timer if > interval > 10msec? I am not familiar with this section of the kernel, but I > do know that Microsoft's similar function KeStallExecutionProcessor is not > recommended for more than 50 *micro*seconds. You can't use kernel timer from within interrupts. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: Incorrect mdelay() results on Power Managed Machines x86
Hi! > > On the ThinkPad 600E (at least), we get a Power Status Change APM event. > > Any reason we couldn't recalibrate the bogomips on a power status change, > at least for laptops we know appear to need it (I can make the DMI code look > for matches there..) Notice that this is not 100% solution. APM is async, and you might already did few wrong delays by the time apm event is delivered to you. Also notice that at least my toshiba goes low speed (150MHz) on *) batteries going low *) overheat It goes back to 300MHz at ac power. Another crazy thing: it goes down to 35MHz on extreme overheat -- that's factor of 10 change. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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/
FWD: 3 NIC cards problem
I am posting this mail here because I have tried posting on many news groups, but no one seems to know how. Also, I did read documentation but could not figure out how to do this in Linux 2.4 kernel --Original Message-- From: Lee Chin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: 3 NIC cards problem Hi, I have a system with 3 NIC cards, each on a seperate subnet, with IP addresses 192.168.1.1, 192.168.2.1 and 192.168.3.1. I have a program listening for socket connections on 192.168.1.1, port 80. What I want to do is have incomming connection requets for IP 192.168.2.1 and 192.168.3.1 on port 80 also be handled by my server running on 192.168.1.1:80 How do I do this in Linux? Thanks Lee __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - 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 for 2.5] preemptible kernel
Dipankar Sarma wrote: > > Nigel Gamble wrote: > > > > On Wed, 21 Mar 2001, Keith Owens wrote: > > > I misread the code, but the idea is still correct. Add a preemption > > > depth counter to each cpu, when you schedule and the depth is zero then > > > you know that the cpu is no longer holding any references to quiesced > > > structures. > > > > A task that has been preempted is on the run queue and can be > > rescheduled on a different CPU, so I can't see how a per-CPU counter > > would work. It seems to me that you would need a per run queue > > counter, like the example I gave in a previous posting. > > Also, a task could be preempted and then rescheduled on the same cpu > making > the depth counter 0 (right ?), but it could still be holding references > to data > structures to be updated using synchronize_kernel(). There seems to be > two > approaches to tackle preemption - > > 1. Disable pre-emption during the time when references to data > structures > updated using such Two-phase updates are held. Doesn't this fly in the face of the whole Two-phase system? It seems to me that the point was to not require any locks. Preemption disable IS a lock. Not as strong as some, but a lock none the less. > > Pros: easy to implement using a flag (ctx_sw_off() ?) > Cons: not so easy to use since critical sections need to be clearly > identified and interfaces defined. also affects preemptive behavior. > > 2. In synchronize_kernel(), distinguish between "natural" and preemptive > schedules() and ignore preemptive ones. > > Pros: easy to use > Cons: Not so easy to implement. Also a low priority task that keeps > getting > preempted often can affect update side performance significantly. Actually is is fairly easy to distinguish the two (see TASK_PREEMPTED in state). Don't you also have to have some sort of task flag that indicates that the task is one that needs to sync? Something that gets set when it enters the area of interest and cleared when it hits the sync point? George - 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/
Possible patch for Dell keyboard lockup
Hello, All:
I have a situation where a Dell laptop would loose its
keyboard after resume (thanks to Ben LaHaise for
diagnosing this probelm). BIOS enables touchpad
when resumed and if a user touches touchpad, "hardware"
delivers IRQ 12 and will not deliver IRQ 1 until we
process the mouse event. Which we do not (in case
a USB mouse is used, for instance).
I may do what BIOS ought to do upon suspend, but it
does not feel right. So... do we need anything like that?
If yes, I may polish it up w.r.t. non-x86 etc.
-- Pete
diff -ur -X dontdiff linux-2.4.2-0.1.32/drivers/char/keyboard.c
linux-2.4.2-0.1.32-p3/drivers/char/keyboard.c
--- linux-2.4.2-0.1.32/drivers/char/keyboard.c Mon Mar 26 16:59:28 2001
+++ linux-2.4.2-0.1.32-p3/drivers/char/keyboard.c Wed Mar 28 15:33:47 2001
@@ -162,6 +162,14 @@
static struct pm_dev *pm_kbd;
+static int pm_kbd_request(struct pm_dev *dev, pm_request_t req, void *data)
+{
+ if (req == PM_RESUME) {
+ kbd_pm_resume();
+ }
+ return 0;
+}
+
/*
* Many other routines do put_queue, but I think either
* they produce ASCII, or they produce some user-assigned
@@ -934,7 +942,7 @@
tasklet_enable(_tasklet);
tasklet_schedule(_tasklet);
- pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, NULL);
+ pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, pm_kbd_request);
return 0;
}
diff -ur -X dontdiff linux-2.4.2-0.1.32/drivers/char/pc_keyb.c
linux-2.4.2-0.1.32-p3/drivers/char/pc_keyb.c
--- linux-2.4.2-0.1.32/drivers/char/pc_keyb.c Mon Mar 26 17:00:03 2001
+++ linux-2.4.2-0.1.32-p3/drivers/char/pc_keyb.cWed Mar 28 15:41:06 2001
@@ -530,6 +530,31 @@
}
}
+void pckbd_pm_resume(void)
+{
+ unsigned int flags;
+
+/* P3 */ printk("pckbd_pm_resume: queue %p aux_count %d\n", queue, aux_count);
+ if (queue) {/* Aux port detected */
+ if (aux_count == 0) { /* Mouse not in use */
+ spin_lock_irqsave(_controller_lock, flags);
+ /*
+* Dell Lat. C600 A06 enables mouse after resume.
+* When user touches the pad, it posts IRQ 12
+* (which we do not process), thus holding keyboard.
+*/
+ kbd_write_command(KBD_CCMD_MOUSE_DISABLE);
+ /* kbd_write_cmd(AUX_INTS_OFF); */ /* Config & lock */
+ kb_wait();
+ kbd_write_command(KBD_CCMD_WRITE_MODE);
+ kb_wait();
+ kbd_write_output(AUX_INTS_OFF);
+ spin_unlock_irqrestore(_controller_lock, flags);
+/* P3 */ printk("pckbd_pm_resume: done\n");
+ }
+ }
+}
+
/*
* In case we run on a non-x86 hardware we need to initialize both the
* keyboard controller and the keyboard. On a x86, the BIOS will
diff -ur -X dontdiff linux-2.4.2-0.1.32/include/asm-i386/keyboard.h
linux-2.4.2-0.1.32-p3/include/asm-i386/keyboard.h
--- linux-2.4.2-0.1.32/include/asm-i386/keyboard.h Wed Feb 21 19:11:45 2001
+++ linux-2.4.2-0.1.32-p3/include/asm-i386/keyboard.h Wed Mar 28 15:11:13 2001
@@ -26,6 +26,7 @@
char raw_mode);
extern char pckbd_unexpected_up(unsigned char keycode);
extern void pckbd_leds(unsigned char leds);
+extern void pckbd_pm_resume(void);
extern void pckbd_init_hw(void);
extern unsigned char pckbd_sysrq_xlate[128];
@@ -34,6 +35,7 @@
#define kbd_translate pckbd_translate
#define kbd_unexpected_up pckbd_unexpected_up
#define kbd_leds pckbd_leds
+#define kbd_pm_resume pckbd_pm_resume
#define kbd_init_hwpckbd_init_hw
#define kbd_sysrq_xlatepckbd_sysrq_xlate
-
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: NTP on 2.4.2?
Hi! > I'm having problems getting my 2.4.2 kernel to synchronise properly. For > some reason, NTP is insisting on making time offset adjustments. Are you using fbcon? If so, and if it goes away after starting X, then it is the "fbcon kills interrupt latency" problem. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: Serial port latency
Hi! > Is the computer otherwise idle? > I've seen one unexplainable report with atm problems that disappeared > (!) if a kernel compile was running. I've seen similar bugs. If you hook something on schedule_tq and forget to set current->need_resched, this is exactly what you get. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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/
Repeatable lockup on SMP w/usbprocfs
If an application calls the USBDEVFS_SUBMITURB ioctl to submit a read, when the async completion routine is called, the kernel goes into a hard deadlock (no response to ping, etc.). I've narrowed it down to the async_completed routine in usb.c. That's the only place where spinlocks are used. I'm not familiar enough with them to see what the error is, though. The system runs fine until the packet is returned, then it just locks solid (On the alcatel USB modem I used for testing it will not respond until it gets sync, which may be several seconds). Others have found that just compiling SMP into the kernel is enough to break it, you don't actually need two processors. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't find modules after moving to 2.4.2
Hello, I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except for the fact that none of the modules in "/etc/modules.conf" are loaded anymore (although modules were enabled in kernel config). In "/lib/modules" I see two directories: 2.2.16 and 2.4.2 (which I assume is the default for modules.conf). However, the "/lib/modules/2.4.2" contains almost no files, differently from 2.2.16. I guess I've missed some important step during the installation of 2.4.2, but now I am confused and can't recover. Can anyboy point me what the missing step is ? I will be most grateful. Thanks in advance, 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: menuconfig snafu?
On Wednesday 28 March 2001 22:17, Dennis wrote: > its seems that "make menuconfig" only allows you to select 1 processor > type. it seems impossible that you cant build a generic kernel that > supports different processors. Its this just a menuconfig bug? > > Dennis You pick the lowest common denominator. If you want a kernel that runs everywhere (x86 arch), pick the plain old 386. Or, read the menuconfig help :-) CONFIG_M386: This is the processor type of your CPU. This information is used for optimizing purposes. In order to compile a kernel that can run on all x86 CPU types (albeit not optimally fast), you can specify "386" here. The kernel will not necessarily run on earlier architectures than the one you have chosen, e.g. a Pentium optimized kernel will run on a PPro, but not necessarily on a i486. Regards, also Dennis :-) - 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: 53c400a status
> I got a HP Scanjet 3p with a SCSI card that got a 53c400a SCSI interface chip with >only > one jumper without a label. The card was shipped with the scanner. I tried to insert > the module and it does the same that was written in this archive earlier: complaint >about > business of the bus and then the machine stopped. You need the options right. You must tell g_NCR5380 its a 400a, it has no irq and a suitable I/O port - 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: IDE and APM (standby) incompatibility on thinkpad T21?
Rebuild your kernel and make sure CONFIG_APM_ALLOW_INTS is set to "Y".
Tim
On Wed, Mar 28, 2001 at 12:52:05PM -0500, D. Sen wrote:
> Attempting to 'standby' the machine generates the following
> syslog messages:
>
> Mar 27 23:58:56 localhost kernel: ide_dmaproc: chipset supported
> ide_dma_lostirq func only: 13
> Mar 27 23:58:56 localhost kernel: hda: lost interrupt
>
> This seems to corrupt the filesystem..
>
> Kernel: 2.4.2
>
> hdparm -i /dev/hda:
> /dev/hda:
> multcount= 16 (on)
> I/O support = 1 (32-bit)
> unmaskirq= 1 (on)
> using_dma= 1 (on)
> keepsettings = 1 (on)
> nowerr = 0 (off)
> readonly = 0 (off)
> readahead= 8 (on)
> geometry = 4134/240/63, sectors = 62506080, start = 0
>
> Model=IBM-DJSA-232, FwRev=JS8IAD1A, SerialNo=48YBWLA6226
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/15/63, TrkSize=0, SectSize=0, ECCbytes=4
> BuffType=DualPortCache, BuffSize=1874kB, MaxMultSect=16, MultSect=16
> CurCHS=16383/15/63, CurSects=1011810540, LBA=yes, LBAsects=62506080
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
> AdvancedPM=yes: mode=0x9F (159)
> Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4
> ATA-5
>
> Please CC any responses to [EMAIL PROTECTED]
>
> DS
>
> -
> 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/
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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] Re: 2.4.3-pre8: IPX not building
Sorry to bother but it seems that the patchlet is still not good enough... problems at linkage or something: O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon -c -o iodebug.o iodebug.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-pre8/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon -c -o memcpy.o memcpy.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-pre8/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon -c -o mmx.o mmx.c rm -f lib.a ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o putuser.o iodebug.o memcpy.o mmx.o make[2]: Leaving directory `/usr/src/linux-2.4.3-pre8/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux-2.4.3-pre8/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux-2.4.3-pre8/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/parport/driver.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/net/fc/fc.o drivers/net/appletalk/appletalk.o drivers/net/tokenring/tr.o drivers/atm/atm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/ieee1394/ieee1394drv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/net/hamradio/hamradio.o drivers/i2o/i2o.o drivers/i2c/i2c.o drivers/md/mddev.o \net/network.o \ /usr/src/linux-2.4.3-pre8/arch/i386/lib/lib.a /usr/src/linux-2.4.3-pre8/lib/lib.a /usr/src/linux-2.4.3-pre8/arch/i386/lib/lib.a \ --end-group \ -o vmlinux net/network.o(.data+0x5f04): undefined reference to `sysctl_ipx_pprop_broadcasting' make: *** [vmlinux] Error 1 [root@bigfoot linux-2.4.3-pre8]# On Tue, 27 Mar 2001, Eran Man wrote: > Date: Tue, 27 Mar 2001 21:43:28 +0200 > From: Eran Man <[EMAIL PROTECTED]> > To: Robert-Velisav MICIOVICI <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: [patch] Re: 2.4.3-pre8: IPX not building > > The following patchlet solves it: > > --- linux-2.4.3pre8.orig/net/ipx/af_ipx.c Mon Mar 26 13:17:08 2001 > +++ linux/net/ipx/af_ipx.c Mon Mar 26 13:14:52 2001 > @@ -1542,7 +1542,7 @@ > ipx_offset = intrfc->if_ipx_offset; > size = sizeof(struct ipxhdr) + len + ipx_offset; > > - skb = sock_alloc_send_skb(sk, size, noblock, ); > + skb = sock_alloc_send_skb(sk, size, 0, noblock, ); > if (!skb) > goto out_put; > > @@ -2531,7 +2531,6 @@ > sendmsg:ipx_sendmsg, > recvmsg:ipx_recvmsg, > mmap: sock_no_mmap, > - sendpage: sock_no_sendpage, > }; > > #include > > > Robert-Velisav MICIOVICI wrote: > > > > Hi, > > > > Just a build problem report. > > > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-pre8/include -Wall > > -Wstrict-prototypes -O2 -fomit-frame-pointer > > -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 > > -march=athlon -DMODULE -DMODVERSIONS -include > > /usr/src/linux-2.4.3-pre8/include/linux/modversions.h -c -o > > ip6table_mangle.o ip6table_mangle.c > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-pre8/include -Wall > > -Wstrict-prototypes -O2 -fomit-frame-pointer > > -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 > > -march=athlon -DMODULE -DMODVERSIONS -include > > /usr/src/linux-2.4.3-pre8/include/linux/modversions.h -c -o > > ip6t_MARK.o ip6t_MARK.c > > make[2]: Leaving directory /usr/src/linux-2.4.3-pre8/net/ipv6/netfilter' > > make -C ipx modules > > make[2]: Entering directory /usr/src/linux-2.4.3-pre8/net/ipx' > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-pre8/include -Wall > > -Wstrict-prototypes -O2 -fomit-frame-pointer > > -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 > > -march=athlon -DMODULE -DMODVERSIONS -include > > /usr/src/linux-2.4.3-pre8/include/linux/modversions.h -DEXPORT_SYMTAB > > -c af_ipx.c > > af_ipx.c: In function pxrtr_route_packet': > > af_ipx.c:1545: warning: passing arg 4 of `sock_alloc_send_skb_R7094cf19' > > makes integer from pointer without a cast > > af_ipx.c:1545: too few arguments to function > > `sock_alloc_send_skb_R7094cf19' > > af_ipx.c: At top level: > > af_ipx.c:2534: unknown field `sendpage' specified in initializer > > af_ipx.c:2534: `sock_no_sendpage' undeclared here (not in a function) > > af_ipx.c:2534: warning: excess elements in struct initializer > > af_ipx.c:2534: warning: (near initialization forpx_dgram_ops') > > make[2]: *** [af_ipx.o] Error 1 > > make[2]:
