Re: strange nonmonotonic behavior of gettimeoftheday -- seen similar problem on PPC
On Fri, 2 Mar 2001, Richard B. Johnson wrote: > Yes and no. It takes microseconds to call the kernel for anything (time > getpid() ), so it seldom loops. All the kernel has to do is remember Hi, c0109286 system_call +<22/40> (0.21) pid(4265) c011c7e7 sys_gettimeofday +<13/a8> (0.27) pid(4265) c010e3b2 do_gettimeofday + (0.48) pid(4265) c01092aa ret_from_sys_call +<6/21> (0.76) pid(4265) c0109286 system_call +<22/40> (0.19) pid(4265) c0120b45 sys_getpid + (0.18) pid(4265) c01092aa ret_from_sys_call +<6/21> (0.77) pid(4265) time in usecs This is a 500Mhz PIII. It wouldn't take much more cpu/memory speed to get under a usec. The overhead of calling the kernel on this box is almost exactly 1 usec. -Mike - 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/
RFC: changing precision control setting in initial FPU context
A question recently came up in "c.o.l.d.s"; actually, it was a comment
on Slashdot that had been cross-posted to 15 Usenet groups by some
ignoramus. It concerned a snippet of C code that cast a double to int
in such a way as to get a different answer under i386 Linux than under
the i386 free BSDs and most non-i386 architectures. In fact, the
exact same assembly, running under Linux and under FreeBSD on the same
machine, reportedly gave different results.
For those who might care,
#include
int main()
{
int a = 10;
printf("%d %d\n",
/* now for some BAD CODE! */
(int)( a*.3 + a*.7), /* first expression */
(int)(10*.3 + 10*.7)); /* second expression */
return 0;
}
when compiled under GCC *without optimization*, will print "9 10" on
i386 Linux and "10 10" most every place else. (And, by the way, if
you sit down with a pencil and paper, you'll find that IEEE 754
arithmetic in 32-bit, 64-bit, or 80-bit precision tells us that
floor(10*.3 + 10*.7) == 10, not 9.)
It boils down to the fact that, under i386 Linux, the FPU control word
has its precision control (PC) set to 3 (for 80-bit extended
precision) while under i386 FreeBSD, NetBSD, and others, it's set to 2
(for 64-bit double precision). On other architectures, I assume
there's usually no mismatch between the C "double" precision and the
FPU's default internal precision.
To be specific, under Linux, the first expression takes 64-bit
versions of the constants 0.3 and 0.7 (each slightly less than the
true values of 0.3 and 0.7), and does 80-bit multiplies and an add
to get a number slightly less than 10. This gets truncated to 9.
On the other hand, under the BSDs, the 64-bit add rounds upward
before the truncation, giving the answer "10".
The second expression always produces 10 (and, with -O2, the first
also produces 10), probably because GCC itself either does all the
constant optimization arithmetic (including forming the constants
0.3 and 0.7) in 80 bits or stores the interim results often enough
in 64-bit registers to make it come out "right".
Initially, I was quick to dismiss the whole thing as symptomatic of a
severe floating-point-related cluon shortage. However, the more I
think about it, the better the case seems for changing the Linux
default:
1. First, PC=3 is a dangerous setting. A floating point program
using "double"s, compiled with GCC without attention to
FPU-related compilation options, won't do IEEE arithmetic running
under this setting. Instead, it will use a mixture of 80-bit and
64-bit IEEE arithmetic depending rather unpredictably on compiler
register allocations and optimizations.
2. Second, PC=3 is a mostly *useless* setting for GCC-compiled
programs. There can obviously be no way to guarantee reliable
IEEE 80-bit arithmetic in GCC-compiled code when "double"s are
only 64 bits, so our only hope is to guarantee reliable IEEE
64-bit arithmetic. But, then we should have set PC=2 in the first
place.
Worse yet, I don't know of any compilation flags that *can*
guarantee IEEE 64-bit arithmetic. I would have thought
-ffloat-store would do the trick, but it doesn't change the
assembly generated for the above example, at least on my Debian
potato build of gcc 2.95.2.
The only use for PC=3 is in hand-assembled code (or perhaps using
GCC "long double"s); in those cases, the people doing the coding
(or the compiler) should know enough to set the required control
word value.
2. Finally, the setting is incompatible with other Unixish platforms.
As mentioned, Free/NetBSD both use PC=2, and most non-IA-64 FPU
architectures appear to use a floating point representation that
matches their C "double" precision which prevents these kinds of
surprises.
The case against, as I see it, boils down to this:
1. The current setting is the hardware default, so it somehow "makes
sense" to leave it.
2. It could potentially break existing code. Can anyone guess
how badly?
3. Implementation is a bit of a pain. It requires both kernel and
libc changes.
On the third point, Ulrich and Adam hashed out weirdness with the FPU
control word setting some time ago in the context of selecting IEEE or
POSIX error handling behavior with "-lieee" without thwarting the
kernel's lazy FPU context initialization scheme.
So, on a related note, is it reasonable to consider resurrecting the
"sys_setfpucw" idea at this point, to push the decision on the correct
initial control word up to the C library level where it belongs? (For
those who don't remember the proposal, the idea is that the C library
can use "sys_setfpucw" to set the desired initial control word. If
the C program actually executes an FPU instruction, the kernel will
use that saved control word to initialize the FPU context in
"init_fpu()"; otherwise, lazy FPU initialization
Re: OOPS-kernel 2.4.3-pre1
[sorry for sel-followup, but...] > Lovely. sb->s_op == NULL in iget(). The thing being, proc_read_super() > explicitly sets ->s_op to non-NULL. Oh, and that area hadn't changed since > 2.4.2, so I'd rather suspect the b0rken build. Can you reproduce it? More specifically, make sure that you are not using the old fs/proc/inode.o. That looks like the most probable cause - Linus had merged the ->s_maxbytes patch from -ac and offsets of struct super_block fields had been changed. Looks like you've either got screwed timestamps or screwed make dep. Cheers, 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/
Re: OOPS-kernel 2.4.3-pre1
On Fri, 2 Mar 2001, TimO wrote: > eax: ebx: ecx: edx: [snip] > >>EIP; c0142a52<= > Trace; c0142ca6 > Trace; c0145f01 > Trace; c014601a > Trace; c01349a4 > Trace; c0134f7a > Trace; c0107007 > Trace; c01074b8 > Code; c0142a52 > <_EIP>: > Code; c0142a52<= [snip] Lovely. sb->s_op == NULL in iget(). The thing being, proc_read_super() explicitly sets ->s_op to non-NULL. Oh, and that area hadn't changed since 2.4.2, so I'd rather suspect the b0rken build. Can you reproduce it? Cheers, 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/
OOPS-kernel 2.4.3-pre1
[1] Oops when booting kernel 2.4.3-pre1
[2] Kernel oopses just after starting kswapd
[3]
[4]
Linux nexxus.deenc.com 2.4.3-pre1 #2 Tue Jan 30 12:32:52 MST 2001 i686
unknown
Gnu C 2.95.2
Gnu make 3.79
binutils 2.10.1
util-linux 2.10r
modutils 2.4.3
e2fsprogs 1.19
PPP2.3.10 not used
Linux C Library2.1.3
Dynamic linker (ldd) 2.1.3
Linux C++ Library 2.8.1
Procps 2.0.6
Net-tools 1.55
Kbd0.94
Sh-utils 2.0
Modules Loaded None at oops time
[5]
ksymoops 2.3.5 on i686 2.4.1. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.1/ (default)
-m /boot/System.map-2.4.3-pre1 (specified)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address
0004
c0142a52
*pde =
Oops:
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ebx: ecx: edx:
esi: c12ef840 edi: c12f1e28 ebp: c122e800 esp: c122bf18
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 1, stackpage=c122b000)
Stack: c12f1e28 0001 c122e800 c0142ca6 c122e800 0001
c12f1e28
c0200d80 c122e800 c0201440 c0145f01
c122e800
0001 c122e800 c122e800 c014601a c122e800
0001
Call Trace: [] [] [] []
[] [] []
Code: 83 78 04 00 74 10 8b 54 24 24 52 56 8b 40 04 ff d0 83 c4 08
>>EIP; c0142a52<=
Trace; c0142ca6
Trace; c0145f01
Trace; c014601a
Trace; c01349a4
Trace; c0134f7a
Trace; c0107007
Trace; c01074b8
Code; c0142a52
<_EIP>:
Code; c0142a52<=
0: 83 78 04 00 cmpl $0x0,0x4(%eax) <=
Code; c0142a56
4: 74 10 je 16 <_EIP+0x16> c0142a68
Code; c0142a58
6: 8b 54 24 24 mov0x24(%esp,1),%edx
Code; c0142a5c
a: 52push %edx
Code; c0142a5d
b: 56push %esi
Code; c0142a5e
c: 8b 40 04 mov0x4(%eax),%eax
Code; c0142a61
f: ff d0 call *%eax
Code; c0142a63
11: 83 c4 08 add$0x8,%esp
kernel panic: Attempted to kill init!
[6]
[7]
[7.2]
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 2
model name : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 751.714
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1500.77
[7.5]
nexxus:/usr/src/linux# lspci -vvv
00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- [disabled] [size=64K]
01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev
15) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2
Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=
[7.6]
nexxus:/usr/src/linux# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ARCHIVE Model: VIPER
Re: 2.4 and 2GB swap partition limit
On Fri, 2 Mar 2001 [EMAIL PROTECTED] wrote: > Linus has spoken, and 2.4.x now requires swap = 2x RAM. I think I missed this. What possible value does this have? (Not even Sun, the original purveyors of the 2x RAM rule, need this any more). - 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: TCP window shrinkers
David wrote: > http://stuph.org/tcp-window-shrinkers.txt is a list of 825 systems > that generate this message. Following up.., I scripted an nmap run, it is in html ;) http://stuph.org/tcp-window-shrinkers.nmap.html Format is: IP dns lookup nmap results [OS type] [Identified] The script is running now, DNS is tacked in which makes the cycle take longer but helps to identify probable dynamic dialups. Please use Mozilla or IE. The output is usable in Netscape 4.x but suffers. -d - 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: [LARTC] 1 adsl + 1 sdsl + masq + simultaneous incomming routes]
> > >>> The problem: I am able to have the web server use one or the other dsl, but not >>> both at the same time. >>> >>> If I have web set to sdsl, replies to queries that came from adsl go out on the >>> sdsl link. Also since masq is involved, it also responds with the sdsl ip. >>> >>> How can I have replies go back on the correct internet link? OH, btw, the web >>> server is NT, so I won't be able to modify any packets there... >> >> What I've done is to put two IPs on the server (your web server, in this >> case). You would then have the gateway send one IP out via ADSL, and the >> out via SDSL. > > There has to be a better way. I'm forwarding this to LKML. Maybe they have a > better idea... > > I know the kernel keeps a route cache, is there something like a reverse MASQ > feature somewhere. Storing which incoming route + port number and keeping a > dynamic list... It all looks very easy if the web server has two IPs. Making it simple, use the following example after modifying the necessary information: Web server public IPs: 99.0.0.5/32(ADSL), 100.0.0.5/32(SDSL), and set default via 10.0.0.1 Gateway: 10.0.0.1 on all interfaces, no default unless you choose to have one ADSL: 99.0.0.1/24, SDSL: 100.0.0.1/24 Routing setup on web server is to point to the default gateway, nothing special needed. Routing on *DSL isn't under your control. All control is handled on the gateway. (web/eth2, SDSL/eth1, ADSL/eth0) Gateway: (establish interfaces) ip a a 10.0.0.1/32 brd + dev eth0; ip link set eth0 up ip a a 10.0.0.1/32 brd + dev eth1; ip link set eth1 up ip a a 10.0.0.1/32 brd + dev eth2; ip link set eth2 up (add routing for the web server IPs - inbound traffic) ip route add 99.0.0.5 dev eth2 ip route add 100.0.0.5 dev eth2 (make packet matching rules, tie them to given tables) ip rule add from 99.0.0.5/32 to 0.0.0.0/0 table 99 prio 99 ip rule add from 100.0.0.5/32 to 0.0.0.0/0 table 100 prio 100 (add the routing based on the table - outbound traffic) ip route add via 99.0.0.1 table 99 dev eth0 onlink ip route add via 100.0.0.1 table 100 dev eth1 onlink This is off the top of my head but it should work fine. Of course if the *DSL arrives on the gateway via a hub, simply combine the interfaces as appropriate. -d p.s. those in the know, feel free to correct me - 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: [LARTC] 1 adsl + 1 sdsl + masq + simultaneous incommingroutes]
On Fri, 2 Mar 2001, Mike Fedyk wrote: > There has to be a better way. It's the one I use; it works and works well. Asking someone who deals with "network appliance" routers (ie Cisco) might lead to some ideas. But the Cisco folks I asked recommended the solution I told you about. You might have better luck asking someone else. > I'm forwarding this to LKML. Maybe they have a better idea... [EMAIL PROTECTED] (or something like that) is actually a better place > I know the kernel keeps a route cache, is there something like a reverse MASQ > feature somewhere. Storing which incoming route + port number and keeping a > dynamic list... -- --- Phil Brutsche [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: MM docs...
> Is there any chance that some knowledgeable people could write docs for > the public functions in 2.4's linux/mm directory? I am currently doing some memory-related research. I would be very grateful if someone could write such documents. Btw, may I know some significant differences in terms of MM between kernel 2.4 and kernel 2.2.1x family? Thanks in advance! -- Cheers! --Zou Min [EMAIL PROTECTED]URL: http://www.comp.nus.edu.sg/~zoum - I don't always know what I'm talking about, but I'm always pretty much convinced that I'm right. -- musician Mojo Nixon - 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: strange nonmonotonic behavior of gettimeoftheday -- seen similar problem on PPC
"Richard B. Johnson" wrote: > >I think it's a math problem in the test code. Try this: > [code deleted] > >Note that two subsequent calls to gettimeofday() must not return the >same time even if your CPU runs infinitely fast. I haven't seen any >kernel in the past few years that fails this test. I find that claim to be pretty ridiculous, I have never seen such a thing in any standard. I was writing code allowing the for '=' condition five years ago, because I was assuming that it might live long enough for this sort of thing to start happening. Simple defensive programming (probably smart even if POSIX was to declare this to be the case) So then I was I was curious if I could find any systems fast enough to violate this. I didn't have to look far, my new laptop with a 600MHz Pentium III (running kernel 2.2.16, not that it matters) hits the "break" in your program (i.e., same time from the two gettimeofday() calls) every single time I run it. If I add another identical call to gettimeofday() immediately after the second one, that makes the result of the (now) third call 1us greater so the code loops as you intended. What you claim may have been true due to the inability of CPUs to execute two system calls within a microsecond, but that horse has now left the barn. You will need to request a getnanotimeofday() be created if you want to allow two consecutive calls to always return different values (modulo SMP systems and ~13 more years of Moore's Law) -- Douglas Siebert [EMAIL PROTECTED] A computer without Microsoft software is like chocolate cake without ketchup. - 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: [LARTC] 1 adsl + 1 sdsl + masq + simultaneous incomming routes]
Mike Fedyk wrote: > [EMAIL PROTECTED] wrote: > > > > On Fri, 2 Mar 2001, Mike Fedyk wrote: > > > > > I have two dsl links, each with one ip, and a single gateway is assigned the ip > > > for each. > > > > > > ____ > > > | ADSL | | SDSL | > > > |__| |__| > > >\ / > > > \/ > > > ___|| > > > | gateway | > > > |_| > > > || > > > || > > > || > > >_||__ > > > | web | > > > |_| > > > > > > OK. > > > > > > The problem: I am able to have the web server use one or the other dsl, but not > > > both at the same time. > > > > > > If I have web set to sdsl, replies to queries that came from adsl go out on the > > > sdsl link. Also since masq is involved, it also responds with the sdsl ip. > > > > > > How can I have replies go back on the correct internet link? OH, btw, the web > > > server is NT, so I won't be able to modify any packets there... > > > > What I've done is to put two IPs on the server (your web server, in this > > case). You would then have the gateway send one IP out via ADSL, and the > > out via SDSL. > > > > There is no way I know of to make that work. > > > > -- > > --- > > Phil Brutsche [EMAIL PROTECTED] > > There has to be a better way. I'm forwarding this to LKML. Maybe they have a > better idea... > > I know the kernel keeps a route cache, is there something like a reverse MASQ > feature somewhere. Storing which incoming route + port number and keeping a > dynamic list... try www.liuxdoc.org search for iproute2 and netfilter. with 2.4. kernel, you can mark packets *before* they go through routing table, and the routing tablecan use mark value to choose which route to use, so if you use set up the NT box with two IP's, your firewall can mark packets based on destination (on webserver) IP. think of it like having two default routes... - 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/
VT82C586B USB PCI card, Linux USB
I have a USB PCI card, which shows up as this in `lspci`: 00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04) ... it appears that they tossed the whole southbridge chip onto a pci board, and disabled everything but USB. Anyway, this device seems to be semi-functional under 2.2.18 USB. I have a cheapie IBM usb camera that works, but a USB scanner that does not -- always gives the following errors: usb_control/bulk_msg: timeout scanner.c: write_scanner: NAK received. The firmware upload seems to work ok, but nothing else does. The sane tools actually segfault, and once the kernel oopsed (didn't manage to get the output :( ). I noticed a config setting for that chipset, but it was under block devices, so I left it turned off. Judging form reading the LKML, VIA chipsets are problematic. Has anyone has any positive experiences getting this device to do the thing it's supposed to do under Linux? Any tips? -M - 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: [LARTC] 1 adsl + 1 sdsl + masq + simultaneous incomming routes]
[EMAIL PROTECTED] wrote: > > On Fri, 2 Mar 2001, Mike Fedyk wrote: > > > I have two dsl links, each with one ip, and a single gateway is assigned the ip > > for each. > > > > ____ > > | ADSL | | SDSL | > > |__| |__| > >\ / > > \/ > > ___|| > > | gateway | > > |_| > > || > > || > > || > >_||__ > > | web | > > |_| > > > > OK. > > > > The problem: I am able to have the web server use one or the other dsl, but not > > both at the same time. > > > > If I have web set to sdsl, replies to queries that came from adsl go out on the > > sdsl link. Also since masq is involved, it also responds with the sdsl ip. > > > > How can I have replies go back on the correct internet link? OH, btw, the web > > server is NT, so I won't be able to modify any packets there... > > What I've done is to put two IPs on the server (your web server, in this > case). You would then have the gateway send one IP out via ADSL, and the > out via SDSL. > > There is no way I know of to make that work. > > -- > --- > Phil Brutsche [EMAIL PROTECTED] There has to be a better way. I'm forwarding this to LKML. Maybe they have a better idea... I know the kernel keeps a route cache, is there something like a reverse MASQ feature somewhere. Storing which incoming route + port number and keeping a dynamic list... TIA, Mike - 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/
Oddity with /proc/sys/net/ipv4/conf/all
According to Documentation/networking/ip-sysctl.txt: conf/all/* is special and changes the settings for all interfaces. However, I did this: mercury:~# echo 1 >/proc/sys/net/ipv4/conf/all/log_martians mercury:~# cat /proc/sys/net/ipv4/conf/all/log_martians 1 mercury:~# cat /proc/sys/net/ipv4/conf/lo/log_martians 0 mercury:~# cat /proc/sys/net/ipv4/conf/eth0/log_martians 0 So it looks like the changes are not reflected in the individual interfaces. What's going on? Also, can anyone tell me how to test whether these options are working? (For instance, how can I send myself a martian packet, to see if it is logged?) I considered the possibility that the option really is on, and sysctl just doesn't report it, but I didn't know how to find out. This is kernel 2.4.2-ac7. -- Nate Eldredge [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac5 IDE Software Raid(ata/100) Problem..Kernel Oops?
On Friday March 2, [EMAIL PROTECTED] wrote: > 1. Problem description > 2. Machine details > a) Hardware > b) Software > 3. System log during the incident > > 1. Problem Description: > snip > Mar 2 13:44:38 bertha kernel: Unable to handle kernel NULL pointer > dereference at virtual address 0038 > Mar 2 13:44:38 bertha kernel: printing eip: > Mar 2 13:44:38 bertha kernel: c01ed5ee > Mar 2 13:44:38 bertha kernel: *pde = > Mar 2 13:44:38 bertha kernel: Oops: > Mar 2 13:44:38 bertha kernel: CPU:0 > Mar 2 13:44:38 bertha kernel: EIP:0010:[raid5_diskop+910/1520] snip > Using Linux Kernel 2.4.2-ac5 Fixed in 2.4.2-ac6 NeilBrown - 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/
TCP window shrinkers
http://stuph.org/tcp-window-shrinkers.txt is a list of 825 systems that generate this message. -d - 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: report bug: System reboots when accessing a loop-device over a second loop-device with 2.4.2-ac7
On Fri, Mar 02 2001, Mario Hermann wrote: > But with old 2.2 - Material stored on DVD-RAM. > > losetup -e blowfish /dev/loop0 /dev/sr3 > lsoetup -e serpent /dev/loop1 /dev/loop0 > > it doesn't work. (replied to Mario earlier, for reference here's the patch). Yet another miscount and IV off, I apparently missed the latter when the other IV calculations were fixed. I've verified block crypto here now. -- Jens Axboe --- /opt/kernel/linux-2.4.2-ac10/drivers/block/loop.c Sat Mar 3 04:16:23 2001 +++ drivers/block/loop.cSat Mar 3 04:18:54 2001 @@ -345,8 +345,6 @@ struct buffer_head *rbh = bh->b_private; rbh->b_end_io(rbh, uptodate); - if (atomic_dec_and_test(>lo_pending)) - up(>lo_bh_mutex); loop_put_buffer(bh); } else loop_add_bh(lo, bh); @@ -479,6 +477,7 @@ IV = (bh->b_rsector / (bh->b_size >> 9)); IV += lo->lo_offset / bh->b_size; + IV >>= 2; ret = lo_do_transfer(lo, READ, bh->b_data, rbh->b_data, bh->b_size, IV);
[Announce] SnapFS Snapshot File System alpha release
SnapFS - Snapshot File System Release: alpha1 Requires: Linux 2.2.18 or later, Ext3 and EA. WWW site: http://www.mountainviewdata.com/technology/snapfs Mountain View Data, Inc is announcing the first release of SnapFS. SnapFS is a file system enhancement of Ext3 to bring fully featured snapshots to Linux. (You can use SnapFS with Ext2 but there is no file system recovery tool.) Making a snapshot of a file system allows the file and directory layout at particular points in time to remain available read only. This is done through careful management of multiple versions of inodes. SnapFS manages modifications to files and versions of files at the block level to avoid space and CPU overhead. Our white papers describe the design in more detail. Snapshots are made almost instantaneously and typical usage is to make a snapshot before a backup or major system administration. SnapFS allows dynamic creation and removal of snapshots, and can roll back a file system to a snapshot. SnapFS comes with utilities that can find incremental backup data extremely fast and SnapFS manages disk block layout in such a way that LAN free backup programs can take advantage of it. SnapFS relies on Ext3 for recovery and on the Extended Attribute package for storing versioning information. The current release is usable, but has some known and likely some unknown bugs. Please backup your file systems before playing with SnapFS and play at your own risk. SnapFS is provided under the GPL. Mountain View Data plans to release additional configuration and management tools for SnapFS as commercial products. Acknowledgements: Stephen Tweedie has been instrumental in providing a journal interface that supports filtering file systems like InterMezzo and SnapFS. Andreas Dilger wrote the first version of the Ext2 snap api, and Andreas Gruenbacher has helped us with extended attribute code. Others are helping us with possible ports to 2.4, ReiserFS, XFS and JFS. SnapFS is being developed by Mountain View Data. It was designed and partially written by Peter Braam. The development is led by Harrison Xing <[EMAIL PROTECTED]> and Eric Mei <[EMAIL PROTECTED]> in the Beijing office of Mountain View Data. William Wei <[EMAIL PROTECTED]> has helped with initial QA. Michael Gao and Thomas Corley have helped with the WWW site and documentation. Brian Murrell packaged SnapFS for a demo at LinuxWorld. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add Epson Perfection 1640SU scanner to scanner.c
Just purchased an Epson Perfection 1640SU (SCSI/USB) scanner (1600 dpi optical),
and found in some tips (forgot where now) on getting it recognized by the USB code:
(I made the change in a vanilla 2.4.2 kernel.)
diff -urNb linux-2.4.2/drivers/usb/scanner.c linux-2.4.2.modified/drivers/usb/scanner.c
--- linux-2.4.2/drivers/usb/scanner.c Thu Jan 4 13:15:32 2001
+++ linux-2.4.2.modified/drivers/usb/scanner.c Sat Feb 24 22:49:21 2001
@@ -303,6 +303,7 @@
{ USB_DEVICE(0x04b8, 0x0104) }, /* Perfection 1200U and 1200Photo*/
{ USB_DEVICE(0x04b8, 0x0106) }, /* Stylus Scan 2500 */
{ USB_DEVICE(0x04b8, 0x0107) }, /* Expression 1600 */
+ { USB_DEVICE(0x04b8, 0x010a) }, /* Perfection 1640SU and 1640SUPhoto */
/* Umax */
{ USB_DEVICE(0x1606, 0x0010) }, /* Astra 1220U */
{ USB_DEVICE(0x1606, 0x0030) }, /* Astra 2000U */
FYI, it works well with the latest SANE packages; some of my friends of the Windows
persuasion find it easier to use (XSane) than other scanner packages they're used to.
And more stable. :)
-jesse
Jesse Wyant - [EMAIL PROTECTED]
If there was any justice in the world, "trust" would be a four-letter word.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 TCP window shrinking
David S. Miller wrote: > We need desperately to know exactly what OS the xxx.xxx.1.14 machine > is running. Because you've commented out the first two octets, I > cannot check this myself using nmap. I see them all the time on my sites. I have active mirrors so they abound. Here are a few, I've also attached nmap's guesses. TCP: peer 148.75.156.238:1025/7000 shrinks window 3317772066:0:3317772330. Bad, what else can I say? TCP: peer 195.226.233.21:1774/6660 shrinks window 2502834461:2920:2502837525. Bad, what else can I say? TCP: peer 195.39.136.145:1702/7000 shrinks window 2750401402:2920:2750405782. Bad, what else can I say? TCP: peer 213.189.87.228:1190/6660 shrinks window 2933193691:1072:2933194827. Bad, what else can I say? #1, unknown #2, running proxy squid/2.3.stable4, can't tell what OS is on it. #3, unknown #4, unknown #2 and #4 both have the following in http headers: Via: 1.1 netcache (NetCache 4.1R6) -d - 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: kmod error
On Fri, 2 Mar 2001 20:55:37 -0500 , "MEHTA,HIREN (A-SanJose,ex1)" <[EMAIL PROTECTED]> wrote: >kmod: failed to exec /sbin/modprobe -s -l binfmt-464c, errno = 8. You must have support for elf binaries built into the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 TCP window shrinking
Similar situation here: vanilla 2.4.2, with web serving/ftp/hotline/napster/etc., and I get this: TCP: peer 148.75.118.138:1360/6699 shrinks window 3200785160:0:3200795086. Bad, what else can I say? TCP: peer 148.75.118.138:1359/6699 shrinks window 3054879436:0:3054885108. Bad, what else can I say? TCP: peer 148.75.118.138:1360/6699 shrinks window 3201450202:0:3201458710. Bad, what else can I say? TCP: peer 148.75.118.138:1361/6699 shrinks window 3317649733:0:3317653987. Bad, what else can I say? TCP: peer 148.75.118.138:1359/6699 shrinks window 3054934738:0:3054940410. Bad, what else can I say? TCP: peer 148.75.118.138:1357/6699 shrinks window 2520518983:0:2520527491. Bad, what else can I say? TCP: peer 148.75.118.138:1359/6699 shrinks window 3054990040:0:3054995712. Bad, what else can I say? TCP: peer 148.75.118.138:1359/6699 shrinks window 3055011310:0:3055014146. Bad, what else can I say? TCP: peer 148.75.118.138:1360/6699 shrinks window 3201522520:0:3201528192. Bad, what else can I say? TCP: peer 148.75.118.138:1357/6699 shrinks window 2520598391:0:2520599809. Bad, what else can I say? TCP: peer 148.75.118.138:1359/6699 shrinks window 3055146020:0:3055148856. Bad, what else can I say? TCP: peer 148.75.118.138:1361/6699 shrinks window 3317713543:0:3317723469. Bad, what else can I say? TCP: peer 148.75.118.138:1360/6699 shrinks window 3201592002:0:3201599092. Bad, what else can I say? TCP: peer 148.75.118.138:1360/6699 shrinks window 3201593420:0:3201599092. Bad, what else can I say? TCP: peer 148.75.118.138:1357/6699 shrinks window 2520676381:0:2520680635. Bad, what else can I say? TCP: peer 148.75.118.138:1360/6699 shrinks window 3201607600:0:3201614690. Bad, what else can I say? Running nmap (v2.53) on that IP doesn't resolve to a known OS, so that doesn't help. Version 2.54BETA7 gives this output: Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ ) Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port All 1534 scanned ports on vsat-148-75-118-138.ssa7.mcl.starband.net (148.75.118.138) are: filtered Remote OS guesses: Apple LaserWriter 16/600 PS, HP 6P, or HP 5 Printer, Apple LaserWriter 8500 (PostScript version 3010.103), MultiTech MultiVOIP Version 2.01A Firmware, Mulit-Tech standalone firewall box, version 3, MultiTech CommPlete (modem server) RAScard, Xerox 8830 Plotter, Xerox DocuPrint C55, Xerox DocuPrint N40 Nmap run completed -- 1 IP address (1 host up) scanned in 163 seconds So that doesn't appear to help too much either. > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A long time ago, in a galaxy far, far way, someone said... > > > > > Jim Woodward writes: > > > This has probably been covered but I saw this message in my logs and > > > wondered what it meant? > > > > > > TCP: peer xxx.xxx.1.11:41154/80 shrinks window 2442047470:1072:2442050944. > > > Bad, what else can I say? > > > > > > Is it potentially bad? - Ive only ever seen it twice with 2.4.x > > > > We need desperately to know exactly what OS the xxx.xxx.1.14 machine > > is running. Because you've commented out the first two octets, I > > cannot check this myself using nmap. > > I'm seeing similar messages on a web server running 2.4.2. > > Some of hosts I've seen it with are: > > 205.188.208.172 > 209.240.220.172 > 209.240.220.173 > 209.240.220.174 > 209.240.220.176 > 209.240.220.177 > 216.239.46.17 > 216.239.46.27 > 216.239.46.34 > 216.239.46.168 > 130.239.126.113 > 206.190.23.112 > 193.130.225.253 > > - -- > - -- > Phil Brutsche [EMAIL PROTECTED] > > GPG fingerprint: 9BF9 D84C 37D0 4FA7 1F2D 7E5E FD94 D264 50DE 1CFC > GPG key id: 50DE1CFC > GPG public key: http://tux.creighton.edu/~pbrutsch/gpg-public-key.asc > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE6oEie/ZTSZFDeHPwRAg4UAKChgEkHgE84Q1OWsB5faZczFrFLjACdGkul > sViRgWXfFAlKa3W9V8+RAYs= > =wkJl > -END PGP SIGNATURE- > > - > 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/ > Jesse Wyant - [EMAIL PROTECTED] I never met a man I didn't want to fight. -- Lyle Alzado, professional football lineman - 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/
kmod error
Greetings. I built a 2.4.0 kernel and installed th bzImage in boot, configured in lilo, etc. I also upgraded my modutils to 2.4.3. After that when I tried to boot from the new kernel, I am getting the following error message continuously. kmod: failed to exec /sbin/modprobe -s -l binfmt-464c, errno = 8. Is there any other package in addition to modutils, that also needs upgrade ? or is there anything wrong with the image ? Any help is appreciated. -hiren - 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: scsi vs ide performance on fsync's
On Fri, 2 Mar 2001, Chris Mason wrote: > For why ide is beating scsi in this benchmark...make sure tagged queueing > is on (or increase the queue length?). For the xlog.c test posted, I would > expect scsi to get faster than ide as the size of the write increases. I have seen that many drives either have a pathetically small queue or have completely broken tagged queueing. I guess thats what happens when most vendors target their hardware for micro$oft. -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: [Re: paging behavior in Linux]
Manfred Spraul wrote: > Neelam Saboo wrote: > > > > hi, > > > > After I installed a newer version of Kernel (2.4.2) and enable DMA option in Ah hah! There's a huge difference in performance (in my experience) with DMA. also, using hdparm utility, *most* drives work fine with dma, irq unmasking, multisector transfers, and 32bit access. hdparm -i /dev/hda or such will tell you maximum multisector supported. the only reason these aren't enabled AFAIK is that SOME drives don't, and when there's a problem it could cause data loss. The worker thread may just have been overtaking the prefetcher because dma was off and disk was slow. > > > hardware configuration, the behavior changes. > > I can see performance improvements when another thread is used. Also, i can > > see timing overlaps between two threads. i.e. when one thread is blocked on a > > page fault, other thread keeps working. > > Now, how can this behavior be explained , given the earlier argument. > > Is it that, a newer version of kernel has fixed the problem of the semaphore > > ? > > > No, that change won't happen until 2.5 > > I can only guess: > the other thread keeps working until it causes a page fault - with both > 2.4.1 and 2.4.2. > > I haven't followed the threads about the mm changes closely, but I > assume that the swapout behaviour changed, and that your worker thread > now runs without causing page faults. - 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: VFS: Cannot open root device
Jeremy wrote: This is going to get confusing! > Hello all, > HELP, I have a new server that I am trying to put > Redhat 7.0 on. It is a Compaq Proliant ML530 Dual PIII > 1Ghz with a Gig of RAM. It has a Compaq smart array > 5300 in it also. It boots just fine with the default > Redhat 7 kernel 2.2.16smp but when I compiled my own > 2.4.2 kernel I get the following message. > > request_module[scsi_host_adapter]: Root FS not mounted > request_module[scsi_host_adapter]: Root FS not mounted 2 possibilities: you misconfigured kernel or didn't make an initial ramdisk to load scsi modules. to make a good configuration, you may wish to use the config files that redhat used to build the kernel you say works, and then just tweak a few things like processor type. they're installed (i think) in /usr/src/linux/configs if you install kernel-source package. try command 'man mkinitrd' under redhat for hints about initial ramdisk. > > > Then some standard lines Then: > > NET 4: Unix domain sockets 1.0/SMP for Linux NET 4.0 > request_module[block-major-104]: Root FS not mounted > VFS: Cannot open root device "6802" or 68:02 > Please append a correct "root=" boot option > Kernel Panic: VFS: Unable to mount root FS on 68:02 > > When I boot 2.2.16 the only modules that are loaded > are cciss, NCR53C8XX, eepro100 and tlan. I have triple > checked and I have built cciss and NCR53C8XX into the > kernel, I even tried them as modules. It almost looks > like it just isn't loading the NCR53C8XX and then it > cant mount the File system. > If you need any more info please let me know. > > Please CC anything to me directly since I am not on > the mailing list. > > Thanks, >Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ advice (2.4.2-ac7)
Favre Gregoire wrote: > Hello, > > as I boot some times under windows, i have to change my IRQ for my PCI > devices to (all) 9... and all the times I tried to boot that way under linux, > it doesn't boot... > > So I haven't tested it that way for ages... and now with 2.4.2-ac7 i booted > without any problem that way: > cat /proc/interrupts 03.03 1:52 >CPU0 > 0:3051534 XT-PIC timer > 1: 37390 XT-PIC keyboard > 2: 0 XT-PIC cascade > 8: 1 XT-PIC rtc > 9:6193814 XT-PIC HiSax, aic7xxx, EMU10K1, usb-uhci, saa7146(1), bttv > 12: 314048 XT-PIC PS/2 Mouse > 14: 11820 XT-PIC ide0 > 15: 42041 XT-PIC ide1 > NMI: 27599 > LOC:3051630 > ERR: 0 > MIS: 0 > > Is it safe to do it that way? I personally don't like sharing interrupts unles absolutely necessary. Can you tell me why you need to do this? I would recommend disabling any devices you aren't using in the BIOS, to free up interrupts. (IE 2nd serial port, USB, 1st serial if you only use PS/2 mouse) If you don't use the floppy you might be able to disable it in BIOS. I have one board that will use irq 6 for something more useful in this case. Also, changing PCI slot assignment of some cards (if you have spare slots) can prevent sharing as well. The BIOS on many boards will show PCI interrupt assignment on the bootup screen. Otherwise check in windows device manager - double click on Computer node. according to the above usage, you could use 4 (com1) (if not mouse or modem) 3 com2 5 unused 9,10,11 for devices. Good luck! - 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/
Nasty bug in the IrDA stack
Hi,
I've found a really convoluted bug in the IrDA stack (spend
the week chasing it). As it is not trivial, I would like you to check
and comment on my description and my fix.
My patch definitely fix the problem on the PC where I was
seeing it, and I can't crash it anymore (whereas it was very
reproducible before).
The crash :
---
-> irda_release(); // Close IrDA socket
<- irda_release()
-> irlap_update_nr_received(); // Receive IrLAP ack
-> kfree_skb(); // Free acked packet
-> sock_wfree();
-> sock_def_write_space(); // Increase socket write buffer
-> __wake_up(); // Wake up writer
Crash
What I believe is happening :
The socket is closing. We remove all the packet associated
with the socket instance (in IrTTP and the socket layer).
Unfortunately, there are packets in IrLAP, waiting for
retransmission, and as IrLAP doesn't know about sockets, those packets
are not freed at this point.
When IrLAP try to free those packets, they refer to a socket
that no longer exist, and we go into the cosmos.
In fact, it was worse. The packet still had a reference to the
socket when we were calling dev_queue_xmit(skb), and as the device
layer can also queue skbs, the same problem can happen (even if it
would be much more difficult to trigger).
The fix :
skb_clone() and skb_free() the packet before passing them to
the LAP layer. This way, they don't refer any socket.
Alan :
Is there in the kernel a function doing the equivalent of the
following but optimised (avoiding malloc/free of the skb structure) :
---
skb2 = skb_clone(skb1);
kfree_skb(skb1);
skb1 = skb2;
---
The point there is to remove the reference to skb->sk, so I
want something that do the opposite of skb_set_owner_w(). Something I
would call skb_set_owner_none()...
Thanks, and good week end...
Jean
P.S. : I also removed all the skb_set_owner_w() in IrLAP, they are now
totally useless.
P.S.2 : Dag : Do not put this patch yet in the kernel, we need a bit
more testing and comments...
diff -u -p linux/net/irda/irttp.j2.c linux/net/irda/irttp.c
--- linux/net/irda/irttp.j2.c Fri Mar 2 14:10:29 2001
+++ linux/net/irda/irttp.c Fri Mar 2 14:22:10 2001
@@ -404,6 +404,7 @@ int irttp_data_request(struct tsap_cb *s
static void irttp_run_tx_queue(struct tsap_cb *self)
{
struct sk_buff *skb;
+ struct sk_buff *tx_skb;
unsigned long flags;
int n;
@@ -454,7 +455,40 @@ static void irttp_run_tx_queue(struct ts
*/
skb->data[0] |= (n & 0x7f);
- irlmp_data_request(self->lsap, skb);
+ /* Detach from socket.
+* The current skb has a reference to the socket that sent
+* it (skb->sk). When we pass it to IrLMP, the skb will be
+* stored in in IrLAP (self->wx_list). When we are within
+* IrLAP, we loose the notion of socket, so we should not
+* have a reference to a socket. So, we drop it here.
+*
+* Why does it matter ?
+* When the skb is freed (kfree_skb), if it is associated
+* with a socket, it release buffer space on the socket
+* (through sock_wfree() and sock_def_write_space()).
+* If the socket no longer exist, we may crash. Hard.
+* When we close a socket, we make sure that associated packets
+* in IrTTP are freed. However, we have no way to cancel
+* the packet that we have passed to IrLAP. So, if a packet
+* remains in IrLAP (retry on the link or else) after we
+* close the socket, we are dead !
+* Jean II */
+ if (skb->sk != NULL) {
+ IRDA_DEBUG(4, __FUNCTION__ "() : Detaching SKB from
+socket.\n");
+ /* Get another skb on the same buffer, but without
+* a reference to the socket (skb->sk = NULL) */
+ tx_skb = skb_clone(skb, GFP_ATOMIC);
+ if (tx_skb != NULL) {
+ /* Release the skb associated with the
+* socket, and use the new skb insted */
+ kfree_skb(skb);
+ }
+ } else {
+ IRDA_DEBUG(3, __FUNCTION__ "() : Got SKB not attached to a
+socket.\n");
+ tx_skb = skb;
+ }
+
+ irlmp_data_request(self->lsap, tx_skb);
self->stats.tx_packets++;
/* Check if we can accept more frames from client */
diff
Re: 2.4.2 TCP window shrinking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A long time ago, in a galaxy far, far way, someone said... > > Jim Woodward writes: > > This has probably been covered but I saw this message in my logs and > > wondered what it meant? > > > > TCP: peer xxx.xxx.1.11:41154/80 shrinks window 2442047470:1072:2442050944. > > Bad, what else can I say? > > > > Is it potentially bad? - Ive only ever seen it twice with 2.4.x > > We need desperately to know exactly what OS the xxx.xxx.1.14 machine > is running. Because you've commented out the first two octets, I > cannot check this myself using nmap. I'm seeing similar messages on a web server running 2.4.2. Some of hosts I've seen it with are: 205.188.208.172 209.240.220.172 209.240.220.173 209.240.220.174 209.240.220.176 209.240.220.177 216.239.46.17 216.239.46.27 216.239.46.34 216.239.46.168 130.239.126.113 206.190.23.112 193.130.225.253 - -- - -- Phil Brutsche [EMAIL PROTECTED] GPG fingerprint: 9BF9 D84C 37D0 4FA7 1F2D 7E5E FD94 D264 50DE 1CFC GPG key id: 50DE1CFC GPG public key: http://tux.creighton.edu/~pbrutsch/gpg-public-key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6oEie/ZTSZFDeHPwRAg4UAKChgEkHgE84Q1OWsB5faZczFrFLjACdGkul sViRgWXfFAlKa3W9V8+RAYs= =wkJl -END PGP SIGNATURE- - 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-ac5 IDE Software Raid(ata/100) Problem..Kernel Oops?
1. Problem description 2. Machine details a) Hardware b) Software 3. System log during the incident 1. Problem Description: I have a software raid 5 with 1 spare. (9 total drives dedicated for raid) with a seperate Boot drive for the system. Before this new problem, I had many problems with DMA timing out, and the notorious CRC errors. None of these problems exist now. The problem now is related to the raid code or something in the kernel. One of the raid drives had problems and died, the spare disk (/dev/hdc) took over without a problem. I went back to the shop and got a brand new disk and replaced the old one. Started up the raid and wanted to make /dev/hdi an active disk again and /dev/hdc1 as the spare disk. This isn't really possible because the old-spare drive is now part of the active array. So my only choice is to set the drive as faulty and replace it with /dev/hdi and then re-add it and use it as a spare. The next step was to use the "raidsetfaulty" command to mark /dev/hdc as a bad drive and then take it offline with "raidhotremove". Then I added /dev/hdi to the raid and it was marked as the new spare disk. This step didnt cause any problems untill sync was completed. After the sync finally completed, this was recorded in the syslog: Mar 2 13:44:38 bertha kernel: md: md0: sync done. Mar 2 13:44:38 bertha kernel: RAID5 conf printout: Mar 2 13:44:38 bertha kernel: --- rd:8 wd:7 fd:1 Mar 2 13:44:38 bertha kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1 Mar 2 13:44:38 bertha kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 Mar 2 13:44:38 bertha kernel: disk 2, s:0, o:0, n:2 rd:2 us:1 dev:[dev 00:00] Mar 2 13:44:38 bertha kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1 Mar 2 13:44:38 bertha kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1 Mar 2 13:44:38 bertha kernel: disk 5, s:0, o:1, n:5 rd:5 us:1 dev:hdo1 Mar 2 13:44:38 bertha kernel: disk 6, s:0, o:1, n:6 rd:6 us:1 dev:hdq1 Mar 2 13:44:38 bertha kernel: disk 7, s:0, o:1, n:7 rd:7 us:1 dev:hds1 Mar 2 13:44:38 bertha kernel: Unable to handle kernel NULL pointer dereference at virtual address 0038 Mar 2 13:44:38 bertha kernel: printing eip: Mar 2 13:44:38 bertha kernel: c01ed5ee Mar 2 13:44:38 bertha kernel: *pde = Mar 2 13:44:38 bertha kernel: Oops: Mar 2 13:44:38 bertha kernel: CPU:0 Mar 2 13:44:38 bertha kernel: EIP:0010:[raid5_diskop+910/1520] Mar 2 13:44:38 bertha kernel: EFLAGS: 00010086 Mar 2 13:44:38 bertha kernel: eax: ebx: cdbf04f0 ecx: edx: 0008 Mar 2 13:44:38 bertha kernel: esi: ce39189c edi: 0008 ebp: cdbf0448 esp: cfeb3ed4 Mar 2 13:44:38 bertha kernel: ds: 0018 es: 0018 ss: 0018 Mar 2 13:44:38 bertha kernel: Process mdrecoveryd (pid: 7, stackpage=cfeb3000) Mar 2 13:44:38 bertha kernel: Stack: cde62100 cde62400 cdbf0438 cdbf04e0 cde62600 cde62300 cde62000 cdbf0400 Mar 2 13:44:38 bertha kernel: 0002 0008 b00f cfeb3f24 090a 04797300 Mar 2 13:44:38 bertha kernel: cfeb2000 cfec6e78 cfec6e78 047680e0 0476d9c8 04772964 04777e68 Mar 2 13:44:38 bertha kernel: Call Trace: [md_do_recovery+457/560] [md_thread+238/336] [md_thread+0/336] [kernel_thread+43/64] Mar 2 13:44:38 bertha kernel: Mar 2 13:44:38 bertha kernel: Code: 8b 41 38 89 46 38 89 51 38 8d 7c 24 2c 8b 74 24 10 fc b9 20 Now, here's a snapshot from /proc/mdstat after /dev/hdc and /dev/hdi were added to the raid and the syn was completed Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md0 : active raid5 hdc1[9] hdi1[8] hds1[7] hdq1[6] hdo1[5] hdm1[4] hdk1[3] hdg1[1] hde1[0] 525477120 blocks level 5, 4k chunk, algorithm 2 [8/7] [UU_U] unused devices: This says that one device is still faulty and simply will not recognize that /dev/hdi is now back online. The drive has been added to the array, is functioning properly, is reported as active by /proc/mdstat (check md0 3rd line above). Also note that in the syslog, since the disk has failed, the second disk (/dev/hdi) is always reported as Mar 2 10:48:17 bertha kernel: disk 2, s:0, o:0, n:2 rd:2 us:1 dev:[dev 00:00] which should be (from a previous log): Jan 29 06:12:11 bertha kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1 Any Ideas? Hardware Details: Motherboard : ASUS A7V With the VIA KT133 Chipset Processor+RAM: AMD Athalon Tbird 1GHz with 512MB RAM Onboard IDE : 2 IDE Ports ata/33 (UNUSED) : 2 UDMA ATA/100 ports Promise PDC20265) hda: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63, UDMA(100) hdb: hdc: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdd: PCI CARD 1 : Promise ATA/100 PDC20267 hde: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdf: hdg:
VFS: Cannot open root device
Hello all, HELP, I have a new server that I am trying to put Redhat 7.0 on. It is a Compaq Proliant ML530 Dual PIII 1Ghz with a Gig of RAM. It has a Compaq smart array 5300 in it also. It boots just fine with the default Redhat 7 kernel 2.2.16smp but when I compiled my own 2.4.2 kernel I get the following message. request_module[scsi_host_adapter]: Root FS not mounted request_module[scsi_host_adapter]: Root FS not mounted Then some standard lines Then: NET 4: Unix domain sockets 1.0/SMP for Linux NET 4.0 request_module[block-major-104]: Root FS not mounted VFS: Cannot open root device "6802" or 68:02 Please append a correct "root=" boot option Kernel Panic: VFS: Unable to mount root FS on 68:02 When I boot 2.2.16 the only modules that are loaded are cciss, NCR53C8XX, eepro100 and tlan. I have triple checked and I have built cciss and NCR53C8XX into the kernel, I even tried them as modules. It almost looks like it just isn't loading the NCR53C8XX and then it cant mount the File system. If you need any more info please let me know. Please CC anything to me directly since I am not on the mailing list. Thanks, Jeremy __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
Benjamin Herrenschmidt writes: > There is still the need, in the ioctl we use the "select" what need to be > mapped by the next mmap, to ask for the "legacy IO range of the bus where > the card reside" (if it exist of course). That would be the 0-64k (or less, > actually a couple of pages would probably be enough) that generates IO cycles > in the "low" addresses used for VGA registers on the card. As I've stated in another email, this is perfectly fine and is precisely the kind of thing implied by my original proposal in this thread. You can even have arch-specific "next mmap is" ioctl values to do "special things". The generic part of the ioctl()/mmap() bits the PCI driver will have added won't care about these ioctl's all that much, the include/asm/pcimmap.h header will deal with all such details. This header is also where the physical address and the actual creation of the page table mappings will occur. The generic PCI code will only provide the skeletal parts of the mmap() method and call into the arch-specific hooks coded in asm/pcimmap.h Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
Benjamin Herrenschmidt writes:
> What I call ISA IOs here doesn't necessarily mean there's an ISA bridge
> on the PCI.
Ok.
> On PPC, we don't have an "IO" space neither, all we have is a range of
> memory addresses that will cause IO cycles to happen on the PCI bus.
This is precisely what the "next MMAP is XXX space" ioctl I've
suggested is for. I think I've addressed this concern in my
proposal already. Look:
fd = open("/proc/bus/pci/${BUS}/${DEV}", ...);
if (fd < 0)
return -errno;
err = ioctl(fd, PCI_MMAP_IO, 0);
if (err < 0) {
close(fd);
return -errno;
}
ptr = mmap(NULL, pdev->bar[3].size, PROT_READ | PROT_WRITE,
MAP_PRIVATE, fd, pdev->bar[3].start);
Something like that.
> Without that, we need to create new versions of inb/outb that take a bus
> number.
No, don't do this, it is evil. Use mappings, specify the device
related info somehow when creating the mapping (in the userspace
variant you do this by openning a specific device to mmap, in the
kernel variant you can encode the bus/dev/etc. info in the device's
resource and decode this at ioremap() time, see?).
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IRQ advice (2.4.2-ac7)
Hello, as I boot some times under windows, i have to change my IRQ for my PCI devices to (all) 9... and all the times I tried to boot that way under linux, it doesn't boot... So I haven't tested it that way for ages... and now with 2.4.2-ac7 i booted without any problem that way: cat /proc/interrupts 03.03 1:52 CPU0 0:3051534 XT-PIC timer 1: 37390 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9:6193814 XT-PIC HiSax, aic7xxx, EMU10K1, usb-uhci, saa7146(1), bttv 12: 314048 XT-PIC PS/2 Mouse 14: 11820 XT-PIC ide0 15: 42041 XT-PIC ide1 NMI: 27599 LOC:3051630 ERR: 0 MIS: 0 Is it safe to do it that way? Thanks you very much, Greg http://ulima.unil.ch/greg ICQ:16624071 mailto:[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/
usleep magically reduces cpu load?
Why does this use up about 5% CPU (on my system) (pseude code of course)
while (data,size = get_data) {
write(/dev/dsp,data,size);
}
And this only uses about 0%:
while (data,size = get_data) {
write(/dev/dsp,data,size);
usleep(1);
}
I've also tried replacing the usleep with sched_yield() but that did
nothing.
Thomas
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.3-pre1: PCI documentation
Some of the fixes to the PCI documentation got lost in the 2.4.3-pre1 patch. Here they are again. Tim. */ 2001-03-02 Tim Waugh <[EMAIL PROTECTED]> * drivers/pci/pci.c: Inline documentation, based on a patch by Jani Monoses. --- linux/drivers/pci/pci.c.pcidoc Sat Mar 3 00:37:12 2001 +++ linux/drivers/pci/pci.c Sat Mar 3 00:37:27 2001 @@ -63,9 +63,9 @@ /** * pci_find_subsys - begin or continue searching for a PCI device by vendor/subvendor/device/subdevice id * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids - * @device: PCI device id to match, or %PCI_ANY_ID to match all vendor ids + * @device: PCI device id to match, or %PCI_ANY_ID to match all device ids * @ss_vendor: PCI subsystem vendor id to match, or %PCI_ANY_ID to match all vendor ids - * @ss_device: PCI subsystem device id to match, or %PCI_ANY_ID to match all vendor ids + * @ss_device: PCI subsystem device id to match, or %PCI_ANY_ID to match all device +ids * @from: Previous PCI device found in search, or %NULL for new search. * * Iterates through the list of known PCI devices. If a PCI device is @@ -97,7 +97,7 @@ /** * pci_find_device - begin or continue searching for a PCI device by vendor/device id * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids - * @device: PCI device id to match, or %PCI_ANY_ID to match all vendor ids + * @device: PCI device id to match, or %PCI_ANY_ID to match all device ids * @from: Previous PCI device found in search, or %NULL for new search. * * Iterates through the list of known PCI devices. If a PCI device is @@ -122,7 +122,8 @@ * found with a matching @class, a pointer to its device structure is * returned. Otherwise, %NULL is returned. * A new search is initiated by passing %NULL to the @from argument. - * Otherwise if @from is not %NULL, searches continue from next device on the global list. + * Otherwise if @from is not %NULL, searches continue from next device + * on the global list. */ struct pci_dev * pci_find_class(unsigned int class, const struct pci_dev *from) @@ -144,9 +145,9 @@ * @cap: capability code * * Tell if a device supports a given PCI capability. - * Returns the address of the requested capability structure within the device's PCI - * configuration space or 0 in case the device does not support it. - * Possible values for @flags: + * Returns the address of the requested capability structure within the + * device's PCI configuration space or 0 in case the device does not + * support it. Possible values for @cap: * * %PCI_CAP_ID_PM Power Management * @@ -387,10 +388,10 @@ static LIST_HEAD(pci_drivers); /** - * pci_match_device - Tell if a PCI device structure has a matching PCI device + * pci_match_device - Tell if a PCI device structure has a matching PCI device id +structure * @ids: array of PCI device id structures to search in * @dev: the PCI device structure to match against - * + * * Used by a driver to check whether a PCI device present in the * system is in its list of supported devices.Returns the matching * pci_device_id structure or %NULL if there is no match. @@ -441,7 +442,8 @@ * * Adds the driver structure to the list of registered drivers * Returns the number of pci devices which were claimed by the driver - * during registration. + * during registration. The driver remains registered even if the + * return value is zero. */ int pci_register_driver(struct pci_driver *drv) @@ -462,8 +464,9 @@ * @drv: the driver structure to unregister * * Deletes the driver structure from the list of registered PCI drivers, - * gives it a chance to clean up and marks the devices for which it - * was responsible as driverless. + * gives it a chance to clean up by calling its remove() function for + * each device it was responsible for, and marks those devices as + * driverless. */ void - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.3-pre1: parport fix (nAutoFd)
Linus, Here is a patch that makes 2.4.x's behaviour more closely match that of 2.2.x when a nibble mode read goes wrong. It prevents reading processes from getting stuck in certain circumstances. Tim. */ 2001-03-02 Tim Waugh <[EMAIL PROTECTED]> * drivers/parport/ieee1284_ops.c (parport_ieee1284_read_nibble): Reset nAutoFd on timeout. Matches 2.2.x behaviour. --- linux/drivers/parport/ieee1284_ops.c.autofd Sat Mar 3 00:37:23 2001 +++ linux/drivers/parport/ieee1284_ops.cSat Mar 3 00:37:23 2001 @@ -189,6 +189,7 @@ DPRINTK (KERN_DEBUG "%s: Nibble timeout at event 9 (%d bytes)\n", port->name, i/2); + parport_frob_control (port, PARPORT_CONTROL_AUTOFD, 0); break; } - 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 2.4.0 parisc PCI support
Jeff Garzik wrote:
> The patch worked 100% on my laptop, but failed to allocate a PCI memory
> region on my desktop machine. Two attachments... "diff -u" output for
> dmesg before and after your patch, and "diff -u" output for lspci before
> and after your patch.
Jeff,
Thanks for trying. I'll rework and resubmit later.
Can you send me the complete lspci output of your desktop?
(either with or without the patch)
I'd like to pull whatever docs I can find on the offending bridge.
I'll also look at moving "transparent Bridge" support to x86
pci_fixup_bus() code (and see if I can find a machine locally
which has this same "feature").
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
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/
Memory-related hangup (2.4.2-ac3)
Is there a reason why the kernel appears to hang temporarily for 3-5 minutes under this circumstance: gandalf:~> free total used free sharedbuffers cached Mem:126700 125024 1676 0964 61640 -/+ buffers/cache: 62420 64280 Swap:97648 97648 0 The system seems to favor the cache, but leaves no room for processes to use the remaining 64MB of ram. This happened while running netscape after viewing a couple of pages with a lot of images on them. Older kernels would happily allow processes to eat up cache space when memory was low. In fact, I used to be able to use 32MB of swap without any problems (even when netscape had more memory allocated to it than this now). Lately with 2.4 kernels I had to add another 64MB swap file to the existing 32, and the performance seems no different than without it, when compared to the old way of letting netscape just use all 125MB if it wants to (and sacrifice cached files, which aren't important in this case). Is there a setting I can control to force the kernel to give up cache when memory is low without hanging the machine? I personally don't think 50% process memory + 50% cache is an ideal solution--especially when running stuff that really wants >= 150MB (RAM + swap). Actually I'd prefer having cache use half the remaining RAM not taken up by processes, instead of half the total RAM on the system. Any suggestions? Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [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: Should isa-pnp utilize the PnP BIOS?
Okay, a couple of people have responded positively to this suggestion. The next question is, how should it be implemented? How 'bout: $ cd pcmcia-cs/modules $ cp pnp_bios.c pnp_proc.c pnp_rsrc.c /usr/src/linux/2.4.2a/drivers/pnp $ cd ../include/linux $ cp pnp_bios.h pnp_resource.h /usr/src/linux/2.4.2a/include/linux Edit makefiles Edit isapnp.c to include new global flag "isapnp_usepnpbios", a MODULE_PARM, which each isapnp function checks at entry. If the flag is set then: in the case of "low-level" functions, return immediately; in the case of "high-level" functions, call appropriate pnp_bios functions to perform the task; in the case of isapnp_init(), just check isapnp_disabled and exit. isapnp's /proc interface would not be supported. Presumably inter_module_get_request() would be used to call the isapnp-bios routines. Comments? (Go easy on me; I'm a newbie at kernel hacking.) Thomas > Hello, l-k. > > On my ThinkPad 600, The ThinkPad PnP BIOS configures > all PnP devices at boot time. > > If I load the isa-pnp.o driver it never detects any ISA PnP > devices: it says "isapnp: No Plug & Play device found". This > is unfortunate, because it means that device drivers can't > find out from isa-pnp where the devices are. > > David Hinds's pcmcia-cs package contains driver code that > interfaces with the PnP BIOS. With it, one can list the resource > usage of ISA PnP devices (serial and parallel ports, sound chip, > etc.) and set them, using the "lspnp" and "setpnp" commands. > > Would it not be useful if the isa-pnp driver would fall back > to utilizing the PnP BIOS (if possible) in order to read and > change ISA PnP device configurations when it can't do this > itself? If so, could this perhaps be done by bringing the Hinds > PnP BIOS driver into the kernel and interfacing isa-pnp to it? > > Thomas Hood > jdthood_AT_yahoo.co.uk <- Change '_AT_' to '@' - 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/
Generic x86 boot code [was Linux OS boilerplate]
I learned of this 12-days past discussion on the "kernel traffic" digest. > The motivation behind this is that I would like to use the Linux boot > system as a boilerplate booter for some experimental code. It's > probably much cleaner and more robust than any boot loader I might > come up with. The Linux boot code may meet your needs fine, but especially if you are developing a quite different kernel, you should take a look at the OSKit, that we developed for the exact purpose of supporting experimental operating systems without getting in your way. http://www.cs.utah.edu/flux/oskit/ It's easy to use, and all the booting is taken care of for you, comes up in 32-bit mode, etc. Provides Linux device drivers if you want drivers, and has a large choice of other components, all separated with no or minimal dependencies. There is continuing work on it, both research and development. Let us know if you use it, and/or need some help here and there. Jay Lepreau, University of Utah, http://www.cs.utah.edu/flux/ - 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 2.4.0 parisc PCI support
Just tested your patch on an x86 laptop with two CardBus controllers (kernel's CardBus bridge code == kernel's PCI-PCI bridge code, for the most part) and an SMP x86 desktop machine. The patch worked 100% on my laptop, but failed to allocate a PCI memory region on my desktop machine. Two attachments... "diff -u" output for dmesg before and after your patch, and "diff -u" output for lspci before and after your patch. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie --- rum-dmesg-before.txtFri Mar 2 17:42:33 2001 +++ rum-dmesg-after.txt Fri Mar 2 17:07:17 2001 @@ -1,4 +1,4 @@ -Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Linux-Mandrake 8.0)) #5 SMP Fri Mar 2 17:37:39 EST 2001 +Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.96 2731 +(Linux-Mandrake 8.0)) #2 SMP Fri Mar 2 16:52:53 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) @@ -29,7 +29,7 @@ ide_setup: ide0=autotune ide_setup: ide1=autotune Initializing CPU#0 -Detected 400.918 MHz processor. +Detected 400.915 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 799.53 BogoMIPS Memory: 126276k/131060k available (1209k kernel code, 4396k reserved, 434k data, 192k init, 0k highmem) @@ -138,19 +138,19 @@ IRQ19 -> 19 done. calibrating APIC timer ... -. CPU clock speed is 400.9022 MHz. -. host bus clock speed is 100.2254 MHz. -cpu: 0, clocks: 1002254, slice: 334084 -CPU0 -cpu: 1, clocks: 1002254, slice: 334084 -CPU1 +. CPU clock speed is 400.9365 MHz. +. host bus clock speed is 100.2340 MHz. +cpu: 0, clocks: 1002340, slice: 334113 +CPU0 +cpu: 1, clocks: 1002340, slice: 334113 +CPU1 checking TSC synchronization across CPUs: passed. PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:04.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 -Unknown bridge resource 0: assuming transparent +PCI : ignoring 00:01.0 PCI-PCI bridge (I/O BASE not configured) PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0d20 00:0c slot=01 0:60/1eb8 1:61/1eb8 2:62/1eb8 3:63/1eb8 @@ -179,6 +179,8 @@ PCI: Resource ce80-ce800fff (f=200, d=0, p=0) PCI: Resource b400-b47f (f=101, d=0, p=0) PCI: Resource d000-d7ff (f=200, d=0, p=0) +PCI: Cannot allocate resource region 0 of device 01:00.0 +PCI: Failed to allocate resource 0 for 01:00.0 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 @@ -186,7 +188,7 @@ IA-32 Microcode Update Driver: v1.08 <[EMAIL PROTECTED]> Starting kswapd v1.8 pty: 256 Unix98 ptys configured -block: queued sectors max/low 83802kB/27934kB, 256 slots per queue +block: queued sectors max/low 83794kB/27931kB, 256 slots per queue RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx --- rum-lspci-before.txtFri Mar 2 17:42:23 2001 +++ rum-lspci-after.txt Fri Mar 2 17:07:26 2001 @@ -88,7 +88,7 @@ Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- (32-bit, non-prefetchable) [size=128M] Expansion ROM at e5ff [disabled] [size=64K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Re: Hashing and directories
Pavel Machek wrote:
> Hi!
> > I was hoping to point out that in real life, most systems that
> > need to access large numbers of files are already designed to do
> > some kind of hashing, or at least to divide-and-conquer by using
> > multi-level directory structures.
> Yes -- because their workaround kernel slowness.
Not just kernel ... because we use NFS a lot, directory searching is
a fair bit quicker with smaller directories (especially when looking
manually at things).
> I had to do this kind of hashing because kernel disliked 7 html
> files (copy of train time tables).
> BTW try rm * with 7 files in directory -- command line will overflow.
Sort of my point, again. There are limits to what is sane.
Another example I have cited -- our ticketing system -- is a good one.
If there is subdivision, it can be easier to search subsets of the data.
Can you imagine a source tree with 10k files, all in one directory? I
think *people* need subdivision more than the machines do, a lot of the
time. Another example would be mailboxes ... I have started to build a
hierarchy of mail folders because I have more than a screenful.
> Yes? Easier to type cat timetab1/2345 that can timetab12345? With bigger
> command line size, putting i into *one& directory is definitely easier.
IMO (strictly my own) it is often easier to have things subdivided.
I have had to split up my archive of linux tarballs and patches because
it was getting too big to vgrep.
> > A couple of practical examples from work here at Netcom UK (now
> > Ebone :), would be say DNS zone files or user authentication data.
> > We use Solaris and NFS a lot, too, so large directories are a bad
> > thing in general for us, so we tend to subdivide things using a
> > very simple scheme: taking the first letter and then sometimes
> > the second letter or a pair of letters from the filename. This
> > actually works extremely well in practice, and as mentioned above
> > provides some positive side-effects.
> Positive? Try listing all names that contain "linux" with such case. I'll
> do ls *linux*. You'll need ls */*linux* ?l/inux* li/nux*. Seems ugly to
> me.
It's not that bad, as we tend to be fairly consistent in a scheme. I
only have to remember one of those combinations at a time :)
Anyway, again I apologise for starting or continuing (I forget which)
this thread. I really do understand (and agree with) the arguments for
better directory performance. I have moved to ReiserFS, mainly for the
avoidance of long fsck (power failure, children pushing buttons, alpha
and beta testing of 3D graphics drivers). I *love* being able to type
"rm -rf linux-x.y.z-acNN" and have the command prompt reappear in less
than a second. I intended merely to highlight the danger inherent in
saying to people "oh look you can put a million entries in a directory
now" :)
*whack* bad thread *die* *die*
> Pavel
--
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include
const char *addresses[] = {
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]", // work
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]"// home
};
-
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: VM balancing problems under 2.4.2-ac1
On Fri, 23 Feb 2001, Rik van Riel wrote: > On 23 Feb 2001, Adam Sampson wrote: > > > The VM balancing updates in the recent ac kernels seem to have caused > > some interesting performance problems on my desktop machine. I've got > > 160Mb of RAM, and 2.4.2-ac1 appears to be using excessively large > > amounts of it for buffers and cache while pushing stuff out to > > swap. This means that Mozilla, for instance, runs significantly worse > > than under 2.4.0, since bits of it are being swapped in and out. > > This is a known problem which I'll fix as soon as I have a > solution. > > The problem is that we still have no good way to balance > how much memory we take from the cache and how much memory > we take from processes. I have the same problem Adam has: I'm running 3-5 applications on my computer. I have 64 MB of RAM and I use usually less than 50 MB. I have swap for the rare cases where I need more RAM than I have. But with 2.4.x-acyz kernels I do often have to wait several seconds after I switched to another running application before it's swapped in again because it seems this application was swapped out to cache some MP3 I surely won't listen to before the next reboot... > This means that for some workloads we'll be evicting too > much cache while for other workloads we'll be evicting too > much process pages... > > If anybody as a good idea to make this code auto-balancing, > please let me know. I have no idea for auto-balancing but another idea: It's one possibility to let the user choose when doing "make *config" what he wants: - A VM optimized for servers that swaps out applications in favor of caching. or - A VM optimized for workstations that won't swap out applications in favor of caching. I know that's not a perfect solution but it would make the situation much better. > regards, > > Rik cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig. - 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: I/O problem with sustained writes
Collectively Unconscious wrote: > > We are having a problem with writes. > They start at 14 M/s for the first hour and then drop to 2.5 M/s and stay > that way. Reads do not seem effected and we've noticed this on the 2.2.16, > 2.2.17, 2.2.18 and now the 2.2.19pre11 kernels. > > These are SMP P-IIIs from 450 to 800 MHz. Redhat 6.2 I've seen something similar on Seagate ST313021A IDE drives. After a few minutes their read throughput falls from 20 megs/sec to about 5. Issuing *any* drive-setting command brings the throughput back. Even a command which the disk doesn't support. So I have a cron job which runs `hdparm -A1' once per minute. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
[EMAIL PROTECTED] wrote: > Linus has spoken, and 2.4.x now requires swap = 2x RAM. > But, the 2GB per swap partition limit still exists, best as we can tell. > So, we sell machines with say 8GB RAM. We need 16GB swap, but really we > need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a > 2GB swap partition on each. That's ugly. > > Is the 2GB per swap partition going to go away any time soon? > > Thanks, > Matt > I know Rik have some plans but I don't know the time table. On the other hand do you really need swap partitions how about using swap files? That way you don't need to manage alot of partitons and you can test if you really do need to go all the way to 2xRAM. It dose look a bit silly to have 16GB swap. Are you really going to load the machine with work that needs more than 8GB?? if not you don't really need any swap. I have not created any swap partitons in years and mostly run without any swap whatsoever. It's easy to create one temporary if I know I'am going to use more memory than I have. Obviously on a server it's better to be safe than sorry. - 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/
IMS Twin Turbo 128 framebuffer
Is there any particular reason why imsttfb isn't available in the i386 arch? It doesn't work in X either in spite of being "supported", but that's not for this list. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Le donne hanno 4 labbra: due per dire delle stupidaggini, due per farsi perdonare. -- Da it.hobby.umorismo - 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] alloc_tty_struct() wastage?
Hugh Dickins writes: > I've been puzzling over alloc_tty_struct(), which seems determined > to waste memory on a machine of page size 8KB. Maybe you could change the ">" to ">="? > I've come to the conclusion that it represents great caution on > Russell's part when introducing ARM, not to interfere with > existing code of other architectures - is that so, Russell? My understanding of the usage of get_free_page there is as follows: The problem was that sizeof(struct tty_struct) was very close to the page size of x86 machines (4K), and kmalloc wasted space unnecessarily. Therefore get_free_page was used by x86 to allocate this structure. I think I'm right in saying that allocating anything larger than half your page size is best done with get_free_page. Someone will probably correct me on that comment above though. Can someone confirm please: is it safe and reasonable to use kmalloc on allocating tty_struct on all architectures now? -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: ftruncate not extending files?
On Fri, 2 Mar 2001 10:17:14 GMT, Malcolm Beattie <[EMAIL PROTECTED]> wrote: >bert hubert writes: >> I would've sworn, based on the fact that I saw people do it, that ftruncate >> was a legitimate way to extend a file > >Well it's not SuSv2 standards compliant: > >http://www.opengroup.org/onlinepubs/007908799/xsh/ftruncate.html > >If the file previously was larger than length, the extra data is >discarded. If it was previously shorter than length, it is >unspecified whether the file is changed or its size increased. If >^^^ >the file is extended, the extended area appears as if it were >zero-filled. > >How "legitimate" relates to "SuSv2 standards compliant" is your call. It is interesting to compare the wording of the Solaris man page, it sounds pretty much like the SuSv2 paragraph above, but without the restriction that the result is unspecified, it guarantees the extending is a legitimate operation. Sounds like the SuSv2 authors chickened out on that issue, most of the Unix platforms I know (including SunOS 4&5, HP/UX, IRIX, Tru64, AIX and various *BSD) do happily extend a file on truncate. -- Jens-Uwe Mager mailto:62CFDB25> - 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] 2.4.2-acX does not recognize any bus on Intel Serverworks based motherboard
This has come up before a few times. The concensus seems to be that the PCI
fixup code for Serverworks chipsets is currently broken (and it's less simple to
fix than it should be due to lack of documentation - there have been some
educated guesses but it would be nicer to know for sure). The suggestion was
to simply kill the fixup code and believe the BIOS (i.e. kill the relevant
lines in the pcibios_fixups[] array in arch/i386/kernel/pci-pc.c). That has
worked on the systems I'm using that use the Serverworks chipset.
Tim
On Fri, Mar 02, 2001 at 07:34:44PM +0100, Petr Vandrovec wrote:
> Hi Martin,
> what's idea behind 'pcibios_last_bus >= 0xff' ? On friend's STL2 Intel
> motherboard Serverworks bridge contains 0x01 in reg. 0x44 (first bus behind
> bridge) and 0xFF in reg. 0x45 (last bus behind bridge).
> This sets pcibios_last_bus to 0xFF in serverworks fixup code. After this
> pcibios_fixup_peer_bridges() refuses to do anything, so devices connected
> to secondary bus are not visible to system.
> With patch below system sees all devices again - patch is for 2.4.2-ac9.
> Thanks,
> Petr Vandrovec
> [EMAIL PROTECTED]
>
>
> diff -urdN linux/arch/i386/kernel/pci-pc.c linux/arch/i386/kernel/pci-pc.c
> --- linux/arch/i386/kernel/pci-pc.c Fri Mar 2 17:55:05 2001
> +++ linux/arch/i386/kernel/pci-pc.c Fri Mar 2 17:56:50 2001
> @@ -784,7 +784,7 @@
> struct pci_dev dev;
> u16 l;
>
> - if (pcibios_last_bus <= 0 || pcibios_last_bus >= 0xff)
> + if (pcibios_last_bus <= 0 || pcibios_last_bus > 0xff)
> return;
> DBG("PCI: Peer bridge fixup\n");
> for (n=0; n <= pcibios_last_bus; n++) {
> -
> 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/
[PATCH] alloc_tty_struct() wastage?
I've been puzzling over alloc_tty_struct(), which seems determined
to waste memory on a machine of page size 8KB. I've come to the
conclusion that it represents great caution on Russell's part
when introducing ARM, not to interfere with existing code of
other architectures - is that so, Russell?
But wouldn't we do better to use kmalloc() in all cases? Unless
you know some reason why a tty_struct is better on its own page:
patch below against 2.4.2-ac9, applies with noise to 2.4.[012].
(I'm not about to follow this with a thousand patches,
replacing page allocation by kmalloc() in sundry places:
now's not the time, but this instance struck me as odd.)
Hugh
--- 2.4.2-ac9/drivers/char/tty_io.c Fri Mar 2 18:22:36 2001
+++ linux/drivers/char/tty_io.c Fri Mar 2 18:23:42 2001
@@ -173,22 +173,15 @@
{
struct tty_struct *tty;
- if (PAGE_SIZE > 8192) {
- tty = kmalloc(sizeof(struct tty_struct), GFP_KERNEL);
- if (tty)
- memset(tty, 0, sizeof(struct tty_struct));
- } else
- tty = (struct tty_struct *)get_zeroed_page(GFP_KERNEL);
-
+ tty = kmalloc(sizeof(struct tty_struct), GFP_KERNEL);
+ if (tty)
+ memset(tty, 0, sizeof(struct tty_struct));
return tty;
}
static inline void free_tty_struct(struct tty_struct *tty)
{
- if (PAGE_SIZE > 8192)
- kfree(tty);
- else
- free_page((unsigned long) tty);
+ kfree(tty);
}
/*
@@ -2239,9 +2232,6 @@
*/
void __init tty_init(void)
{
- if (sizeof(struct tty_struct) > PAGE_SIZE)
- panic("size of tty structure > PAGE_SIZE!");
-
/*
* dev_tty_driver and dev_console_driver are actually magic
* devices which get redirected at open time. Nevertheless,
-
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.2ac10
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac10 o Add ZF-Logic watchdog driver(Fernando Fuganti) o Add devfs support to USB printers (Mark McClelland) o Fix baud rate handling on keyspan (Paul Mackerras) o USB documentation update(Dave Brownell) o Fix disconnect leak (Randy Dunlap) o ARM constants/fixes (Russell King) o Includes for integrator ARM architecture(Russell King) o Update NLS descriptions to be clearer (Pablo Saratxaga) o Add iso-8859-13 (latvian/lithuanian)(Pablo Saratxaga) iso-8859-4, cp1251 (windows cyrillic), cp1255 (windows hebrew), and some alises o Merge 1.14 Megaraid driver (Venkatesh Ramamurthy) o Reapply other fixes this version dropped(me) o Reformat and clean up ifdefs in 1.14 Megaraid (me) o I/O apnic locking fixes (Maciej Rozycki) o Print ioapic id to help debugging (Maciej Rozycki) o Make the tpqic driver work (Hugh Dickins) o USB scanner updates (David Nelson) o Fix usbdevfs multimount (Al Viro) o Fix wrong calculation of path buffer size (Hugh Dickins) o cs89x0 allocated far too much memory(Hugh Dickins) 2.4.2-ac9 o misc device fix (ps/2 and drm are now back) (Tachino Nobuhiro) | Believe it or not my main test box used no misc | device files.. o Radeon build without 8bit (Cha Young-Ho) o Fix oops in scc driver (Andrew Morton) o Add __setup for ISAPnP, update docs (Jaroslav Kysela) o Update E820 table sanitizer (Brian Moyle) o i810 audio updates/mmap fixes (Doug Ledford) o Be paranoid about VIA chipset configurations(Arjan van de Ven) | Fixing VIA disk corruption bugs take 2 o Fix PPC request_irq problems, some fpu emu (Cort Dougan) and timers o Allow scsi drivers to limit request sizes (Jens Axboe, (and fixed by Tim) Tim Waugh) o Configure.help cleanups (Steve Cole) o Loop device fix of the day (Jens Axboe) o CDROM fixes (Jens Axboe) o Reiserfs crash on fsync of dir fix (Alexander Zarochentcev) 2.4.2-ac8 o Fix loop over loop crash(Jens Axboe) o Fix radeon build problems (ISHIKAWA Mutsumi) o Stop two people claiming the same misc dev id (Philipp Rumpf) o capable not suser on sx.c (Rob Radez) o Fix an ixj build combination bug(Andrzej Krzysztofowicz) o Add integrator to ARM machines (Russell King) o ARM include/constant cleanups (Russell King) o Update ARM vmlinuz.in (Russell King) o ARM i2c fixes (Russell King) o ARM scsi updates(Russell King) o ARM header updates (Russell King) o Handle E820 bios returns with overlaps (Brian Moyle) o Fix a sparc64 include build bug (Andrzej Krzysztofowicz) o Loop race fix (Jens Axboe) o s_maxbytes wasnt set for old style compat (Chris Dukes) mounts in reiserfs o Fix the fact we dont see all busses on some (Don Dupuis) Compaq machines o Fix missing watchdog configure.help (Jakob Ostergaard) o Fix oom deadlock (hopefully)(Rik van Riel) o Fix binfmt_aout sign handling bug (Andrew Morton) 2.4.2-ac7 o Fusion driver updates (Steve Ralston) o Olympic fix (Andrew Morton) o Work around hardware bug in older Rage128 (Gareth Hughes) o Handle broken PIV MP tables with a NULL ioapic o Use capable in esp serial driver(Rob Radez) o Use capable not suser in console(Rob Radez) o Small networking fixups (Dave Miller) o Fix make menuconfig breakage(Keith Owens) o Enable cmpxchg8 on Rise P6 (Dave Jones) o Fix wakeup losses on cpu_allowed using tasks(Manfred Spraul) o Maestro3 now works with > 256Mb of ram (Zach Brown) o Opl3sa2 isapnp=0 handling was wrong (Jérôme Augé) | I've fixed it a little differently however o
Re: Keyboard simulation
> Transmit keycodes is AFAIK not implemented in official drivers. Maybe I misunderstand what you mean, but the kernel has had a keycode mode since before 1.0. Andries - 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: Network hanging - Tulip driver with Netgear (Lite-On)
On Fri, 2 Mar 2001, Manfred Spraul wrote: > Jeff Garzik wrote: > > Manfred Spraul wrote: > > > Could you double check the code in tulip_core.c, around line 1450? > > > IMHO it's bogus. > > > > > > 1) if the network card contains multiple mii's, then the the advertised > > > value of all mii's is changed to the advertised value of the first mii. ... > > If you have a single controller with multiple MII phys... how does one > > select the phy of choice (for tulip, in the absence of SROM media > > table...)? > > I'd choose the first one with a link partner. Well, yes, but what is "first"? Are there any Tulip cards (besides the Comet-2 w/HPNA) that have multiple MII transceivers? The Comet2 is a special case, since only one transceiver is powered and visible at a time. Polling the other transceiver switches off the first. > > And once phy A has been selected out of N available as the > > active phy, should you care about the others at all? > > Not until the link beat disappears. Uhmm, but you don't always know when you have lost link beat. In some cases the driver does basic polling to check for duplex changes, but the semantics are not as clean as you would expect. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.19pre - Kernel Panic: no init found
Hi, I have a kernel panic with the patch 2.2.19pre16 that I test. I use a 2.2.18 Kernel very well. I used the last patch on this kernel and make my kernel with sames parameters without error message. At the boot, I can see this : ... eth0: RealTek RTL8139 Fast Ethernet at 0xa800, IRQ 10, 00:50:fc:0b:60:70 eth1: RealTek RTL8139 Fast Ethernet at 0xac00, IRQ 11, 00:50:fc:1f:c1:98 Partition check: hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > Trying to vfree() noexistent vm area (c00f) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 68k freed Kernel panic: No init found. Try passing init= option to kernel. I tried to start with init=3 but no change. I send this information on this mailing list because I think that could be a bug. Sorry if it is a wrong action of me... With Regards, Stephane Garin - 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: [ANNOUNCE] New version of the WRR network scheduler
Hi again, > I have just released a new version of the WRR scheduler supporting the > 2.4 kernels besides 2.2 as always . Oops, I forgot to write that it is available from http://wipl-wrr.dkik.dk/wrr/ Christian. - 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: strange nonmonotonic behavior of gettimeoftheday
OK, short status from the same box. It was up for about 2 weeks, but
yesterday due this problem it become unuseable, as X failed at startup with
message about failed select(). Before reboot I made some tests
and found:
- it triggered by starting of X (without X no backjumps)
- it has something with interrupts, at least when I run program above
(it is correct, at least it can determine problem) as
while [ 1 ]; do ./clo; done
and pressed key, it printed much less strings
- jumps are about 300-2000 microseconds
- there are some cases of such behaviour on Usenet (mainly diagnosed as
screen flickering due incorrect screensaver startup)
After reboot problem goes away( nothing changed in config). Maybe it related
to APM (as I did several suspends before this problem appears). Program
testing RDTSC works OK now. If this problem appears again - I will run it.
Thanks for help.
>From: Manfred Spraul <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED]
>Subject: Re: strange nonmonotonic behavior of gettimeoftheday
>Date: Fri, 02 Mar 2001 18:06:05 +0100
>
> >
> > on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
> > [snip]
> > gives following result on box in question
> > root@**:# ./clo
> > Leap found: -1687 msec
> > and prints nothing on all other my boxes.
>
>Perhaps APM or SMI problems?
>Could you run the attached program?
>
>--
> Manfred
>#include
>#include
>#include
>#include
>
>static unsigned long long get_tsc(void)
>{
> unsigned long v1;
> unsigned long v2;
> __asm__ __volatile__(
> "rdtsc\n\t"
> : "=a" (v1), "=d" (v2));
> return (((unsigned long long)v2)<<32)+v1;
>}
>
>int main(int argc, char** argv)
>{
> unsigned long long t1;
> unsigned long long t2;
>
> printf("RDTSC tester\n");
> t1 = get_tsc();
> for(;;) {
> t2 = get_tsc();
> if(t1 > t2) {
> printf("tsc jumped backwards: from %lld to %lld.\n",
> t1, t2);
> }
>#if 0
> printf("diff is %lld-%lld=%d.\n",t2,t1,t2-t1);
>#endif
> t1 = t2;
>
> }
> return 1;
>}
>
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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: Strange 2.4.2 boot error
Hi folks and D. Stimits, Summary of discussion taken place so far (for linux-kernel people): D. Stimits noticed he can not boot his kernel from a 1.44MB floppy created with "make bzdisk". This would lead into a register dump. The dump does show the boot code tries to read track 80 of the disk. However mkbootdisk as delivered with a pre-release of the RedHat 7.1 distribution can be used to create a working boot disk using the bzImage generated by above. My last question to D. Stimits was: > > How large is the file ./arch/i386/boot/bzImage? And he answered > 1040155 Feb 24 23:28 bzImage > > Definitely within 1.44 Mb floppy size. I see following problem with the bootsector code for bzImage: Within bootsector the size of the kernel is stored as number of 16 byte blocks. This gives a number of 0xfdf2 in this case. Now while loading the kernel the bootsector code calls a helper routine (in setup[.S]) which does copy 64kByte if available and does nothing else. This routine does the return the number of 16 byte blocks read. This number then is a multiple of 1000h. So no when a kernel of above size is completely loaded the count of the 16 byte blocks returned by the helper routine wents from f000h into h due to the 16 bit size of the register ax used. The bootsector code does then compare h to fdf2h and it is less, so it does continue loading until it does reach the end of the disk and fails with a read error. Malware - 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: CPRM is dead; Thanks Andre!
On Thu, 22 Feb 2001, Michael Rothwell wrote: > > IBM withdrew the proposal. > > ... from public view I am saddened to say that I agree with you now that all the info is in hand. However, I do not think IBM is the driving force now... It is now just the C4 extortion^H^H^H^H^H^H^H^H^Horganization sponsoring the mess and they are not in the committee by name. The good news is that I know how to kill it and protect Linux The bad news is I will not fight for the taskfile-filter code to protect the OS, I will just publish it. And yes it does look like a possible security risk now because of the rogue-java that does exist but is not released. Please do not start another war, I do not have the time or desire to fight this one again...the policy of noe policies is not true, because we have a policy to disable the PII/PIII serial-number access. Regards, 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: [ANNOUNCE] New version of the WRR network scheduler
Umm.. where is it located? :) - 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: Network hanging - Tulip driver with Netgear (Lite-On)
Jeff Garzik wrote: > > Manfred Spraul wrote: > > Could you double check the code in tulip_core.c, around line 1450? > > IMHO it's bogus. > > > > 1) if the network card contains multiple mii's, then the the advertised > > value of all mii's is changed to the advertised value of the first mii. > > I'm really curious about this one myself. > > Since I haven't digested all of the tulip media stuff in my brain yet, > and since I'm not familiar with all the corner cases, I'm loathe to > change the tulip media stuff without fully understanding what's going > on. > > If you have a single controller with multiple MII phys... how does one > select the phy of choice (for tulip, in the absence of SROM media > table...)? I'd choose the first one with a link partner. > And once phy A has been selected out of N available as the > active phy, should you care about the others at all? > Not until the link beat disappears. Then scan all existing phy's and select the phy with a link beat as the new active phy. At least that's what the sis900.c driver does. Are there other linux drivers that support multiple phy's? -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-ac6 hangs on boot w/AMD Elan SC520 dev board
Hi! > > bios-e820: 0009f400 @ (usable) > > bios-e820: 0c00 @ 0009f400 (reserved) > > bios-e820: 03f0 @ 0010 (usable) > > bios-e820: 03f0 @ 0010 (usable) > > bios-e820: 0010 @ fff0 (reserved) > >(at this point, it appears to be in an infinite printk loop ) > > > > I didn't spend much time looking into the printk loop, but it seems to > > end up there, even if CONFIG_DEBUG_BUGVERBOSE is not defined, as if the > > ".byte 0x0f,0x0b" is causing the loop to begin. > > > > Any ideas/suggestions/comments? > > Having been over the code the problem is indeed the bios reporting overlapping > /duplicated ranges. That will cause a crash in mm/bootmem when we try and free > the range twice. > > I suspect you need to add some code to take the E820 map and remove any > overlaps from it, favouring ROM over RAM if the types disagree (for safety), > and filter them before you register them with the bootmem in > arch/i386/kernel/setup.c ...plus prining
Re: PROBLEM: Kernel bug in inode.c:885 when floppy disk removed
Hi > > 1: > > Kernel bug/Segmentation fault when floppy disk removed 2nd time > > > > > > 2: > > Segmentation fault in a program, > > hanging processes in "D"-state, > > Kernel bug in inode.c:885! > > > > when removing floppy disk before unmounting and then using again > > - Doctor, it hurts when I do it! > - Don't do it, then. That's not right answer. Think floppy error. 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: Keyboard simulation
Hi! > I'm writting a driver so that my soft braille display can work with the > BRLTTY daemon. > My braille computer contains a braille display, and a braille keyboard > which I can use to enter characters that are transmitted to the computer. > When my driver gets "normla" chars, he writes them to /dev/console. So for > applications, it looks as if they came from the normal keyboard. > Now, I'd like to be able to change the current virtual console and to view > previously displayed screens (equivalent to shift+page up) just by pressing > keys on the braille keyboard. > So my question is: What should my driver do when it detects that the > "change tty" key or the "scroll key" was pressed on the braille keyboard? > Should the driver change the current tty itself (scroll the screen), or is > it possible to call the kernel exactly like the normal keyboard driver > would do (transmit keycodes), saying "alt + function key was pressed", or > "shift + page up/down was pressed". Transmit keycodes is AFAIK not implemented in official drivers. Take a look at vojtech's new input suite. 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/
[ANNOUNCE] New version of the WRR network scheduler
Hi, I have just released a new version of the WRR scheduler supporting the 2.4 kernels besides 2.2 as always . The WRR scheduler is an extension to the Traffic Control/network bandwidth management part of the Linux kernels. The scheduler was developed to support distributing bandwidth on a shared Internet connection fairly between local machines. Further comments: * As a default all local machines will get equally much of the bandwidth if they have sufficient demand. This is obtained by doing so-called weighted round robin (wrr) scheduling. * It is possible to give machines transferring much data over a long or short period of time less bandwidth. * It can work on a bridge, a router or on a firewall. * Supports accounting locally generated masqgraded packets to the correct local machine. * On the WRR home page an extension is available which includes patches for Squid and the Nec socks5 proxy servers so that proxied packets can also be accounted to the correct local machine. * Includes a configuration file based set of scripts that will setup everything without changing your basic network setup. The scripts will allow you to shape both incoming and outgoing traffic. Christian - 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: binfmt_script and ^M
Hi! > > > When running a script (perl in this case) that has DOS-style > > > newlines (\r\n), Linux 2.4.2 can't find an interpreter because it > > > doesn't recognize the \r. The following patch should fix this > > > (untested). > > > Fix the script. The kernel expects a specific format > > > How about letting the kernel return ENOEXEC instead of ENOENT? It would > give the luser just the little extra hint about converting their files to > Unix format. > > $ ls > testscript > $ head -1 testscript > #!/bin/sh > $ ./testscript > bash: ./testscript: No such file or directory What kernel wants to say is "/usr/bin/perl\r: no such file". Saying ENOEXEC would be even more confusing. -- 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: 2.4.2 TCP window shrinking
Jim Woodward writes: > This has probably been covered but I saw this message in my logs and > wondered what it meant? > > TCP: peer xxx.xxx.1.11:41154/80 shrinks window 2442047470:1072:2442050944. > Bad, what else can I say? > > Is it potentially bad? - Ive only ever seen it twice with 2.4.x We need desperately to know exactly what OS the xxx.xxx.1.14 machine is running. Because you've commented out the first two octets, I cannot check this myself using nmap. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I/O problem with sustained writes
We are having a problem with writes. They start at 14 M/s for the first hour and then drop to 2.5 M/s and stay that way. Reads do not seem effected and we've noticed this on the 2.2.16, 2.2.17, 2.2.18 and now the 2.2.19pre11 kernels. These are SMP P-IIIs from 450 to 800 MHz. Redhat 6.2 Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: usbdevfs can be mounted multiple times
On Fri, 2 Mar 2001, Alexander Viro wrote:
> I.e. replace the last argument in declaration of usbdevfs with FS_SINGLE -
> without that we get a new instance every time.
Grr... Proper patch follows. Please, apply.
Cheers,
Al
--- drivers/usb/inode.c Fri Feb 16 18:24:31 2001
+++ drivers/usb/inode.c.new Fri Mar 2 16:39:44 2001
@@ -596,7 +596,7 @@
return NULL;
}
-static DECLARE_FSTYPE(usbdevice_fs_type, "usbdevfs", usbdevfs_read_super, 0);
+static DECLARE_FSTYPE(usbdevice_fs_type, "usbdevfs", usbdevfs_read_super, FS_SINGLE);
/* - */
@@ -691,6 +691,7 @@
return ret;
if ((ret = register_filesystem(_fs_type)))
usb_deregister(_driver);
+ kern_mount(_fs_type);
#ifdef CONFIG_PROC_FS
/* create mount point for usbdevfs */
usbdir = proc_mkdir("usb", proc_bus);
@@ -702,6 +703,7 @@
{
usb_deregister(_driver);
unregister_filesystem(_fs_type);
+ kern_umount(usbdevice_fs_type.kern_mnt);
#ifdef CONFIG_PROC_FS
if (usbdir)
remove_proc_entry("usb", proc_bus);
-
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 2.4.0 parisc PCI support
Jeff Garzik wrote:
> IIRC these "assuming transparent" lines were put in to -fix- PCI-PCI
> bridges on at least some x86 boxes... I didn't really understand the
> bridge code well enough at the time to comment one way or the other on
> its correctness, but it definitely fixed some problems.
Jeff,
If someone could clarify, I'd be happy to rework/resubmit the patch.
My gut feeling is it was to support something other than a PCI-PCI bridge.
pci_read_bridge_bases() assumes the device is a PCI-PCI Bridge (layout
and interpretation of the window registers). Either the code needs to
be more explicit about the type of bridge being handled or the caller
(arch specific code) should.
Only x86 and parisc PCI support call this code in my 2.4.0 tree.
Maybe the right answer is the "assuming transperent" support in
pci_read_bridge_bases() move to arch/x86.
I'm pretty sure Alpha and parisc/PAT_PDC systems don't use this
code since the registers programmed in pci_setup_bridge().
This makes me think none of the other arches attempt to
support PCI-PCI bridges. Is that correct?
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] getname() buffer overflow
The pathname slab cache size was "reduced" from PAGE_SIZE to
PATH_MAX + 1 during the 2.4.0-test series, and len similarly
adjusted in do_getname(). But its "are we near top of task space?"
test should have been adjusted too: could overflow if page size >4KB.
Patch below against 2.4.2-ac9, applies equally to 2.4.[012].
Hugh
--- 2.4.2-ac9/fs/namei.cFri Dec 29 22:07:23 2000
+++ linux/fs/namei.cFri Mar 2 18:23:42 2001
@@ -113,7 +113,7 @@
if ((unsigned long) filename >= TASK_SIZE) {
if (!segment_eq(get_fs(), KERNEL_DS))
return -EFAULT;
- } else if (TASK_SIZE - (unsigned long) filename < PAGE_SIZE)
+ } else if (TASK_SIZE - (unsigned long) filename < PATH_MAX + 1)
len = TASK_SIZE - (unsigned long) filename;
retval = strncpy_from_user((char *)page, filename, len);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CS89x0 demands too many pages
The CS89x0 driver wants a 16KB or 64KB dma_buff (if use_dma and
ANY_ISA_DMA), thinks it's asking __get_dma_pages() for 4 or 16
pages, but actually it's demanding order 4 or order 16 buffer.
Patch below against 2.4.2-ac9 or 2.4.2, offset against 2.4.[01].
Hugh
--- 2.4.2-ac9/drivers/net/cs89x0.c Tue Feb 13 21:15:05 2001
+++ linux/drivers/net/cs89x0.c Fri Mar 2 18:23:42 2001
@@ -1075,7 +1075,7 @@
if (lp->isa_config & ANY_ISA_DMA) {
unsigned long flags;
lp->dma_buff = (unsigned char *)__get_dma_pages(GFP_KERNEL,
- (lp->dmasize * 1024) /
PAGE_SIZE);
+ get_order(lp->dmasize * 1024));
if (!lp->dma_buff) {
printk(KERN_ERR "%s: cannot get %dK memory for DMA\n",
dev->name, lp->dmasize);
@@ -1456,7 +1456,7 @@
static void release_dma_buff(struct net_local *lp)
{
if (lp->dma_buff) {
- free_pages((unsigned long)(lp->dma_buff), (lp->dmasize * 1024) /
PAGE_SIZE);
+ free_pages((unsigned long)(lp->dma_buff), get_order(lp->dmasize *
+1024));
lp->dma_buff = 0;
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to set hdparms for ide-scsi devices on devfs?
There are mystert ATAPI harddrives in the world! On Fri, 2 Mar 2001, Wakko Warner wrote: > > PS: Is there still a possibility for setting the IDE-sleep timeout > > for a ide-scsi harddisk? (I know, this doesnt make sense) > > I didn't know you could use ide-scsi emulation for hard drives. > > -- > Lab tests show that use of micro$oft causes cancer in lab animals > - > 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/ > 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/
[PATCH] QIC-02 tape broken buffaddr
I don't have a QIC-02 tape drive to test, but its driver source
looks long broken. Note the comment at line 2836 "TODO:
does _get_dma_pages() really return the physical address?" and
follow uses of buffaddr - sometimes physical, sometimes virtual.
Which worked in 2.2, with ISA DMA ignoring PAGE_OFFSET bits, and
bus_to_virt() or'ing them; but 2.4 bus_to_virt() adds PAGE_OFFSET.
Patch below against 2.4.2-ac9, applies to 2.4.[012] offset -2 lines.
Hugh
--- 2.4.2-ac9/drivers/char/tpqic02.cFri Mar 2 18:22:36 2001
+++ linux/drivers/char/tpqic02.cFri Mar 2 18:23:42 2001
@@ -210,7 +210,7 @@
* must ensure that a large enough buffer is passed to the kernel, in order
* to reduce tape repositioning wear and tear.
*/
-static unsigned long buffaddr; /* physical address of buffer */
+static void *buffaddr; /* virtual address of buffer */
/* This translates minor numbers to the corresponding recording format: */
static const char *format_names[] = {
@@ -1378,7 +1378,7 @@
flags=claim_dma_lock();
clear_dma_ff(QIC02_TAPE_DMA);
set_dma_mode(QIC02_TAPE_DMA, dma_mode);
- set_dma_addr(QIC02_TAPE_DMA, buffaddr+dma_bytes_done); /* full address */
+ set_dma_addr(QIC02_TAPE_DMA, virt_to_bus(buffaddr) + dma_bytes_done);
set_dma_count(QIC02_TAPE_DMA, TAPE_BLKSIZE);
/* start tape DMA controller */
@@ -1923,7 +1923,7 @@
/* copy buffer to user-space in one go */
if (bytes_done>0)
{
- err = copy_to_user( (void *) buf, (void *) bus_to_virt(buffaddr),
bytes_done);
+ err = copy_to_user(buf, buffaddr, bytes_done);
if (err)
{
return -EFAULT;
@@ -2076,7 +2076,7 @@
/* copy from user to DMA buffer and initiate transfer. */
if (bytes_todo>0)
{
- err = copy_from_user( (void *) bus_to_virt(buffaddr), (const void *) buf,
bytes_todo);
+ err = copy_from_user(buffaddr, buf, bytes_todo);
if (err)
{
return -EFAULT;
@@ -2782,7 +2782,7 @@
release_region(QIC02_TAPE_PORT, QIC02_TAPE_PORT_RANGE);
if (buffaddr)
{
- free_pages(buffaddr, get_order(TPQBUF_SIZE));
+ free_pages((unsigned long)buffaddr, get_order(TPQBUF_SIZE));
}
buffaddr = 0; /* Better to cause a panic than overwite someone else */
status_zombie = YES;
@@ -2832,9 +2832,7 @@
request_region(QIC02_TAPE_PORT, QIC02_TAPE_PORT_RANGE, TPQIC02_NAME);
/* Setup the page-address for the dma transfer. */
-
-/*** TODO: does _get_dma_pages() really return the physical address?? /
-buffaddr = __get_dma_pages(GFP_KERNEL,get_order(TPQBUF_SIZE));
+buffaddr = (void *)__get_dma_pages(GFP_KERNEL, get_order(TPQBUF_SIZE));
if (!buffaddr)
{
@@ -2842,7 +2840,7 @@
return -EBUSY; /* Not ideal, EAGAIN perhaps? */
}
-memset( (void*) buffaddr, 0, TPQBUF_SIZE );
+memset(buffaddr, 0, TPQBUF_SIZE);
printk(TPQIC02_NAME ": Settings: IRQ %d, DMA %d, IO 0x%x, IFC %s\n",
QIC02_TAPE_IRQ, QIC02_TAPE_DMA,
-
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: Escape sequences & console
On Thu, 1 Mar 2001, Sébastien HINDERER wrote:
> According to linux/drivers/console.c, function setterm_commands, case 12,
> one can change the virtual console by sending an escape sequence to
> /dev/cnsole (what I want to do), hower, this is not documented in man
> pages.
From the source of the chvt program:
if (ioctl(fd,VT_ACTIVATE,num)) {
perror("chvt: VT_ACTIVATE");
exit(1);
}
if (ioctl(fd,VT_WAITACTIVE,num)) {
perror("VT_WAITACTIVE");
exit(1);
}
Where fd is /dev/tty, /dev/tty0, /dev/console or std{in,out,err} (From the
source, I doubt this ioctl works on all of those).
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
UP: 10:29pm up 7 days, 3:40, 8 users, load average: 3.67, 4.43, 4.69
-
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/
[FIX] Re: usbdevfs can be mounted multiple times
On Fri, 2 Mar 2001, Pavel Roskin wrote: > Hello! > > I understand that root can do many strange and unsafe things, but mounting > the same filesystem many times is not allowed for systems other than > usbdevfs. Mounting the same fs many times _is_ perfectly legitimate. However, I really don't like the fact that you've been able to do it several times on the same mountpoint... Ah. I see - Linus, could you please do the following? vi drivers/usb/inode.c '-c/DECLARE_FSTYPE/s/0/FS_SINGLE/ x' I.e. replace the last argument in declaration of usbdevfs with FS_SINGLE - without that we get a new instance every time. Cheers, 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/
Re: apparent file corruption on 2.4.2
Wade Hampton writes: > I can't move, delete, or do anything with these files. I tried > chattr, touch, etc. and the only thing I can do is change the > access date with touch. > > b--sr-s--t1 1769209956 1852796526 116, 101 May 29 2023 > /binold/hostname > > prwxr-x--T1 2232483836 23128812830 Mar 1 22:41 > /dev/dsp > > Does anyone have any ideas. I can live with one messed up file > in /binold, but I can't live with a messed up /dev/dsp. I > really don't want the Microsoft solution (reload) You could always rename /dev to /devold, copy the rest of your device files back, and run "mknod /dev/dsp c 14 3" to recreate /dev/dsp. You probably need to boot using a rescue floppy (tomsrtbt if needed), and run debugfs to delete them. It is strange that you can't even delete these files. Sometimes there is a problem with files > 2GB in size, but there should be no problems with block special or pipes. What sort of errors do you get, and is there anything in syslog? 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/
2.4 and 2GB swap partition limit
Linus has spoken, and 2.4.x now requires swap = 2x RAM. But, the 2GB per swap partition limit still exists, best as we can tell. So, we sell machines with say 8GB RAM. We need 16GB swap, but really we need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a 2GB swap partition on each. That's ugly. Is the 2GB per swap partition going to go away any time soon? Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - 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: Network hanging - Tulip driver with Netgear (Lite-On)
Manfred Spraul wrote: > Could you double check the code in tulip_core.c, around line 1450? > IMHO it's bogus. > > 1) if the network card contains multiple mii's, then the the advertised > value of all mii's is changed to the advertised value of the first mii. I'm really curious about this one myself. Since I haven't digested all of the tulip media stuff in my brain yet, and since I'm not familiar with all the corner cases, I'm loathe to change the tulip media stuff without fully understanding what's going on. If you have a single controller with multiple MII phys... how does one select the phy of choice (for tulip, in the absence of SROM media table...)? And once phy A has been selected out of N available as the active phy, should you care about the others at all? Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - 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/
usbdevfs can be mounted multiple times
Hello! I understand that root can do many strange and unsafe things, but mounting the same filesystem many times is not allowed for systems other than usbdevfs. [root@fonzie proski]# mount /dev/ide/host0/bus0/target0/lun0/part1 on / type reiserfs (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /proc/bus/usb type usbdevfs (rw) [root@fonzie proski]# mount /proc/bus/usb [root@fonzie proski]# mount /proc/bus/usb [root@fonzie proski]# mount /proc/bus/usb [root@fonzie proski]# mount /proc/bus/usb [root@fonzie proski]# mount /dev/ide/host0/bus0/target0/lun0/part1 on / type reiserfs (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /proc/bus/usb type usbdevfs (rw) none on /proc/bus/usb type usbdevfs (rw) none on /proc/bus/usb type usbdevfs (rw) none on /proc/bus/usb type usbdevfs (rw) none on /proc/bus/usb type usbdevfs (rw) [root@fonzie proski]# mount /dev/pts mount: none already mounted or /dev/pts busy mount: according to mtab, none is already mounted on /dev/pts [root@fonzie proski]# mount --version mount: mount-2.10p [root@fonzie proski]# uname -a Linux fonzie 2.4.2-ac8 #3 Fri Mar 2 12:59:44 EST 2001 i686 unknown [root@fonzie proski]# Regards, Pavel Roskin - 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: scsi vs ide performance on fsync's
In article <[EMAIL PROTECTED]>, Jeremy Hansen <[EMAIL PROTECTED]> wrote: > >The SCSI adapter on the raid array is an Adaptec 39160, the raid >controller is a CMD-7040. Kernel 2.4.0 using XFS for the filesystem on >the raid array, kernel 2.2.18 on ext2 on the IDE drive. The filesystem is >not the problem, as I get almost the exact same results running this on >ext2 on the raid array. Did you try a 2.4.x kernel on both? 2.4.0 has a bad elevator, which may show problems, so please check 2.4.2 if the numbers change. Also, "fsync()" is very different indeed on 2.2.x and 2.4.x, and I would not be 100% surprised if your IDE drive does asynchronous write caching and your RAID does not... That would not show up in bonnie. Also note how your bonnie file remove numbers for IDE seem to be much better than for your RAID array, so it is not impossible that your RAID unit just has a _huge_ setup overhead but good throughput, and that the IDE numbers are better simply because your IDE setup is much lower latency. Never mistake throughput for _speed_. Linus - 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 2.4.0 parisc PCI support
Grant Grundler wrote:
> Index: drivers/pci/pci.c
> ===
> RCS file: /home/cvs/parisc/linux/drivers/pci/pci.c,v
> retrieving revision 1.1.1.6
> diff -u -p -r1.1.1.6 pci.c
> --- pci.c 2001/01/09 16:57:56 1.1.1.6
> +++ pci.c 2001/03/02 18:44:59
> @@ -644,12 +645,16 @@ void __init pci_read_bridge_bases(struct
> } else {
> +
> /*
> -* Ugh. We don't know enough about this bridge. Just assume
> -* that it's entirely transparent.
> +* Either this is not a PCI-PCI bridge or it's not
> +* configured yet. Since this code only supports PCI-PCI
> +* bridge, we better not be called for any other type.
> +* Don't muck the resources since it will confuse the
> +* platform specific code which does that.
> */
> - printk("Unknown bridge resource %d: assuming transparent\n", 0);
> - child->resource[0] = child->parent->resource[0];
> + printk("PCI : ignoring %s PCI-PCI bridge (I/O BASE not
>configured)\n", child->self->slot_name);
> + return;
> }
>
> res = child->resource[1];
> @@ -664,8 +669,8 @@ void __init pci_read_bridge_bases(struct
> res->name = child->name;
> } else {
> /* See comment above. Same thing */
> - printk("Unknown bridge resource %d: assuming transparent\n", 1);
> - child->resource[1] = child->parent->resource[1];
> + printk("PCI : ignoring %s PCI-PCI bridge (MMIO base not
>configured)\n", child->self->slot_name);
> + return;
> }
>
> res = child->resource[2];
> @@ -690,11 +695,10 @@ void __init pci_read_bridge_bases(struct
> res->end = limit + 0xf;
> res->name = child->name;
> } else {
> - /* See comments above */
> - printk("Unknown bridge resource %d: assuming transparent\n", 2);
> - child->resource[2] = child->parent->resource[2];
> + /* Base > limit means the prefetchable mem is disabled.*/
> }
IIRC these "assuming transparent" lines were put in to -fix- PCI-PCI
bridges on at least some x86 boxes... I didn't really understand the
bridge code well enough at the time to comment one way or the other on
its correctness, but it definitely fixed some problems.
Jeff
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
-
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/
General interest: lawyers talking about GPL and Linux
__ "Legal Implications of Open-Source Software" University of Illinois Law Review, Forthcoming BY: DAVID MCGOWAN University of Minnesota Law School Contact: DAVID MCGOWAN Email: Mailto:[EMAIL PROTECTED] Postal: University of Minnesota Law School 229 19th Avenue South Minneapolis, MN 55455 USA ABSTRACT: This article examines some legal and economic aspects of software produced under licenses that provide for distribution of source code and allow downstream users to copy, modify, and redistribute code. The article focuses in particular on the General Public License (GPL), which grants permission to engage in such activities on the condition that downstream users make their own works available on the same terms on which they received the code. Production under this model is informal compared to production in conventional firms. Persons who work on projects utilizing these licenses do not receive wages from those who initiate or maintain the projects. This model therefore poses questions about traditional assumptions of agent behavior that characterize the Theory of the Firm literature. This article first analyzes the agency question and contends that classifying software by license terms provides an incomplete understanding of this form of production. The social structures necessary to sustain production vary depending upon the complexity, and therefore cost, of different projects; the market position of different projects is relevant as well. Production of simple, low-cost projects may require little if any coordination and therefore little if any hierarchy. Production of complex projects, such as the GNU/Linux operating system, require coordination and are in fact characterized by hierarchy. The article discusses the social factors that have thus far supported these hierarchies. The article also analyzes the reciprocal licensing model of the GPL, and discusses various issues relevant to its enforceability under existing copyright and contract law. --- -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - 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/
apparent file corruption on 2.4.2
Greetings, This is a CC of a post I sent last night to the redhat-list. I am forwarding it to the kernel list as I hear others have had file corruption and this might be of interest Also, if anyone has any ideas I got a couple of responses including: 1) Backup/restore the partition (in this case /) 2) Try shutdown -F now then do an FSCK again 3) There is something else you can do, but it's rather radical. Overwrite the entries directly in the directory table. You would have to write a program to do it, but it should solve the problem. Warren Melnick <[EMAIL PROTECTED]> 4) From Kernel Traffic #107 For 16 Feb, item #3 "I resorted to using debugfs to remove these entries, and re-running e2fsck".[I may try this tonight!] System information: Dell PIII 600 with 20G ATAPI, ATAPI DVD, ZIP, CD-R IDE-SCSI loaded for CD-R, DVD 3COM 3C905 100T NIC 3dfx AGP video RedHat 7.0 with updates 2.4.0 or 2.4.2 kernel, stock (no custom patches) Original post follows: I had some problems with shutting down my RH 7.0 box (2.4.0) and had to hit the reset button. I then tried booting to 2.4.2 which I had just installed. However, I got a lot of disk errors and the sizes on quite a few files were changed to 104. A second hard reboot and startup of 2.4.0, a single user fsck of all partitions and reboot seemed to make all well, however a couple of files are messed up, /bin/hostname and /dev/dsp. I can't move, delete, or do anything with these files. I tried chattr, touch, etc. and the only thing I can do is change the access date with touch. b--sr-s--t1 1769209956 1852796526 116, 101 May 29 2023 /binold/hostname prwxr-x--T1 2232483836 23128812830 Mar 1 22:41 /dev/dsp I recovered /bin by copying /bin/* to /binnew, moving /bin to /binold, then moving /binnew to /bin. I then recovered /bin/hostname from the RPM file, but now I can't do anything with /binold/hostname I tried chattr, chmod, chgrp, mv, cat, vi, touch, etc. Does anyone have any ideas. I can live with one messed up file in /binold, but I can't live with a messed up /dev/dsp. I really don't want the Microsoft solution (reload) Any help would be MOST appreciated! -- Wade Hampton - 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: [Re: paging behavior in Linux]
Neelam Saboo wrote: > > hi, > > After I installed a newer version of Kernel (2.4.2) and enable DMA option in > hardware configuration, the behavior changes. > I can see performance improvements when another thread is used. Also, i can > see timing overlaps between two threads. i.e. when one thread is blocked on a > page fault, other thread keeps working. > Now, how can this behavior be explained , given the earlier argument. > Is it that, a newer version of kernel has fixed the problem of the semaphore > ? > No, that change won't happen until 2.5 I can only guess: the other thread keeps working until it causes a page fault - with both 2.4.1 and 2.4.2. I haven't followed the threads about the mm changes closely, but I assume that the swapout behaviour changed, and that your worker thread now runs without causing page faults. -- Manfred - 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: DMA on a AMD7409 controller with kernel 2.4.2
On Fri, 2 Mar 2001, Thomas Dodd wrote: > > > using_dma= 0 (off) DMA is off and I bet you did not enable the new AUTODMA config setting. 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: report bug: System reboots when accessing a loop-device over a second loop-device with 2.4.2-ac7
Hello! Jens Axboe wrote: > > On Fri, Mar 02 2001, Mario Hermann wrote: > > There is another small bug with the loop over loop problem. Now it works > > fine for > > files but not for Devices: > > > > losetup /dev/loop0 /dev/sr1 > > losetup /dev/loop1 /dev/loop0 > > dd if=/dev/loop1 of=test.dat bs=2048 count=1024 > > Pending miscount, this should fix it. Ok, I did some testing again. What I found: Without crypto: Everything works good! With crypto: I used the ciphers: idea,serbent, aes, blowfish(with small patch in cipher-blowfish send somewhere in the past) Only 2.4.2-ac8 Material: Everything is ok. With old 2.2-Material: Encrypted in the way: losetup -e blowfish /dev/loop0 ./test.file losetup -e serpent /dev/loop1 /dev/loop0 It works perfect too! :-) But with old 2.2 - Material stored on DVD-RAM. losetup -e blowfish /dev/loop0 /dev/sr3 lsoetup -e serpent /dev/loop1 /dev/loop0 it doesn't work. Just garbage comes out of the loop-device. Both, the file on the harddisk and the DVD-RAM are made with 2.2.16 an patch-int-2.2.16.9 and are working there perfectly. I guess that the problem has maybe something to do with the logical block number. Well, for me was the HD-File important to work under 2.4 (DB-on it...) So great thx from me! Hope my testing will help in some way. (will do some more monday afternoon) --- Mario Hermann - 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: strange nonmonotonic behavior of gettimeoftheday -- seen similar problem on PPC
"Richard B. Johnson" wrote: > > On Fri, 2 Mar 2001, george anzinger wrote: > > > "Richard B. Johnson" wrote: > ~snip~ > > > Note that two subsequent calls to gettimeofday() must not return the > > > same time even if your CPU runs infinitely fast. I haven't seen any > > > kernel in the past few years that fails this test. > > > > Oh! With only micro second resolution how is this avoided? The only > > "legal" thing to do to avoid this is for the fast boxes to loop until > > the requirement is satisfied. Is this really done? > > > > George > > > > Yes and no. It takes microseconds to call the kernel for anything (time > getpid() ), so it seldom loops. All the kernel has to do is remember > the last value returned. If the time isn't past that time yet, bump > that value and return it instead of waiting. > Well, "has to do" and "does" are two different animals. My reading of the code shows that it does not. I have a bit of code that does gettimeofday() calls as fast as possible and on some boxes (ix86) have seen the difference as low as 1 micro second. It is not beyond imagination that a box might return the same time two times in a row given the processors performance increases we are seeing. I, for one, don't find this objectionable. I WILL take exception to time running backward, however. (I don't see how this is avoided on the leap second delete, but I have just started looking at this issue.) As to returning a time in the future as you suggest, I think this is a bad policy. If the box can actually do two gettimeofdays in one micro second or less, it SHOULD return the same time (given the resolution can not resolve the difference). If this becomes an issue, and it will, those that care should use the clock_gettime() call which should return time in nano seconds. This is part of the POSIX standard code for which we are working on at: http://sourceforge.net/projects/high-res-timers/ 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/
Re: kernel 2.4.2 SMP + ATM hangs (fwd)
On Fri, 2 Mar 2001, Mitchell Blank Jr wrote: > Miguel Armas wrote: > > A couple days ago we installed a Fore 200E ATM card and after getting the > > ATM address using ilmid the machine hangs. The kernel still respond to > > pings, but the userspace is dead. > > > > If we remove SMP support in the kernel everything works fine (but with > > only one CPU)... > > You probably need the patch that Chas Williams came up with in January. > I've been meaning to forward it, but I haven't yet. Please try it and > see if it fixes your problem. I just applied the patch and everything works now. Thanks a lot! Salu2! -- Miguel Armas del Rio <[EMAIL PROTECTED]> Division de Comunicaciones (DC) Universidad de Las Palmas - 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: APIC error on CPU0 (UP APIC kernel)
Excerpts from mail: 1-Mar-101 Re: APIC error on CPU0 (UP .. by Arnaldo C. de Melo@conec > can you try 2.4.2-ac8 and tell us the results? No change (I used 2.4.2-ac9, since that was available...). (The watchdog doesn't trip and display output, but eventually the errors stop and rebooting is possible) > can you run 2.4.2 with noapic? No change, either on 2.4.2 or 2.4.2-ac9 - 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: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)
On Fri, Mar 02, 2001 at 10:12:36AM +, Russell King wrote: > On Thu, Mar 01, 2001 at 04:41:01PM -0800, Scott Laird wrote: > > I have a fairly repeatable rsync over ssh stall that I'm seeing between > > two Linux boxes, both running identical 2.4.1 kernels. The stall is > > fairly easy to repeat in our environment -- it can happen up to several > > times per minute, and usually happens at least once per minute. It > > doesn't really seem to be data-sensitive. The stall will last until the > > session times out *unless* I take one of two steps to "unstall" it. The > > easiest way to do this is to run 'strace -p $PID' against the sending ssh > > process. As soon as the strace is started, rsync starts working again, > > but will stall again (even with strace still running) after a short period > > of time. > >... > > According to 'ps l', the ssh process is waiting in 'sock_wait_for_wmem'. > > I've also reported this recently, and got told that it was because I was > running 2.2.15pre13 on one end. Thanks for confirming that 2.2.15pre13 > is not the cause. > Be very careful here. He did nothing of the sort. He merely indicated that there is at least one problem running rsync over ssh between 2.4.1 systems. There is no guarantee that your problem and his are identical. As Alexey pointed out, there are bad bugs in 2.2.15 which can cause a TCP connection to get stuck. Given that you are running 2.2.15, you'd need a tcpdump to determine whether you hit one of these or not. I've been bitten too many times assuming something was one big problem only to find out later it was actually several smaller ones. Regards, Tim -- 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/
Raw IO fixes for 2.4.2-ac8
Hi, I've just uploaded the current raw IO fixes as kiobuf-2.4.2-ac8-A0.tar.gz on ftp.uk.linux.org:/pub/linux/sct/fs/raw-io/ and ftp.*.kernel.org:/pub/linux/kernel/people/sct/raw-io/ This includes: 00-movecode.diff: move kiobuf code from mm/memory.c to fs/iobuf.c 02-faultfix.diff: fixes for faulting and pinning pages 03-unbind.diff: allow unbinding of raw devices 04-pgdirty.diff:use the new SetPageDirty to dirty pages after reads 05-bh-err.diff: fix cleanup of buffer_heads after ENOMEM 06-eio.diff:fix error returned on EIO in first block of IO The first 3 of these are from the current 2.2 raw patches. The 4th is the fix for dirtying pages after raw reads, using the new functionality of the 2.4 VM. The 5th and 6th fix up problems introduced when brw_kiovec was moved to use submit_bh(). Cheers, Stephen - 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: paging behavior in Linux]
hi, After I installed a newer version of Kernel (2.4.2) and enable DMA option in hardware configuration, the behavior changes. I can see performance improvements when another thread is used. Also, i can see timing overlaps between two threads. i.e. when one thread is blocked on a page fault, other thread keeps working. Now, how can this behavior be explained , given the earlier argument. Is it that, a newer version of kernel has fixed the problem of the semaphore ? thanks neelam > That's a known problem: > > The paging io for a process is controlled with a per-process semaphore. > The semaphore is held while waiting for the actual io. Thus the paging > in multi threaded applications is single threaded. > Probably your prefetch thread is waiting for disk io, and the worker > thread causes a minor pagefault --> worker thread sleeps until the disk > io is completed. > > -- > Manfred Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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: scsi vs ide performance on fsync's
> > > On Friday, March 02, 2001 01:25:25 PM -0600 Steve Lord <[EMAIL PROTECTED]> wrote: > > >> For why ide is beating scsi in this benchmark...make sure tagged queueing > >> is on (or increase the queue length?). For the xlog.c test posted, I > >> would expect scsi to get faster than ide as the size of the write > >> increases. > > > > I think the issue is the call being used now is going to get slower the > > larger the device is, just from the point of view of how many buffers it > > has to scan. > > filemap_fdatawait, filemap_fdatasync, and fsync_inode_buffers all restrict > their scans to a list of dirty buffers for that specific file. Only > file_fsync goes through all the dirty buffers on the device, and the ext2 > fsync path never calls file_fsync. > > Or am I missing something? > > -chris > > No you are not, I will now go put on the brown paper bag. The scsi thing is wierd though, we have seen it here too. Steve - 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: scsi vs ide performance on fsync's
On Friday, March 02, 2001 01:25:25 PM -0600 Steve Lord <[EMAIL PROTECTED]> wrote: >> For why ide is beating scsi in this benchmark...make sure tagged queueing >> is on (or increase the queue length?). For the xlog.c test posted, I >> would expect scsi to get faster than ide as the size of the write >> increases. > > I think the issue is the call being used now is going to get slower the > larger the device is, just from the point of view of how many buffers it > has to scan. filemap_fdatawait, filemap_fdatasync, and fsync_inode_buffers all restrict their scans to a list of dirty buffers for that specific file. Only file_fsync goes through all the dirty buffers on the device, and the ext2 fsync path never calls file_fsync. Or am I missing something? -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote: > > xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find > . -name "12*" | xargs rm, which has terrible issues with files names > > "xyzzy" > "bla" > "xyzzy bla" > "12 xyzzy bla" > Getting a bit OffTopic(TM) here, but that's why the GNU versions of the tools wisely added options to output '\0' rather than '\n' as a separator for the data i.e. find . -name '12*' -print0 | xargs -0 rm does exactly what you want it to - no surprises. The point about arbitrary limits, is, however well taken. The fact that the space for exec args and environment historically was static and of a fixed size is not a good reason to perpetuate the limitation. Tim -- 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/
PATCH 2.4.0 parisc PCI support
Hi all,
This patch contains the support parisc-linux needs in PCI generic.
My patch is not as clean as I'd like - but it should work.
Please send changes/feedback directly to me.
Code in parisc-linux CVS (based on 2.4.0) does boot on my OB800
(133Mhz Pentium), C3000, and A500 with PCI-PCI bridge support
working. I'm quite certain PCI-PCI bridge configuration (ie BIOS
didn't configure the bridge) support was broken. I'm not able to
test on alpha though...alpha may want to see #ifdef __hppa__
around some of the code I've changed.
I think the plan is to update the arch/parisc support in the near
future so parisc builds actually work from linus' tree.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
Index: drivers/pci/Makefile
===
RCS file: /home/cvs/parisc/linux/drivers/pci/Makefile,v
retrieving revision 1.1.1.4
retrieving revision 1.6
diff -u -p -r1.1.1.4 -r1.6
--- Makefile2001/01/09 16:57:56 1.1.1.4
+++ Makefile2001/02/02 15:35:25 1.6
@@ -21,6 +21,7 @@ obj-$(CONFIG_PROC_FS) += proc.o
#
obj-$(CONFIG_ALPHA) += setup-bus.o setup-irq.o
obj-$(CONFIG_ARM) += setup-bus.o setup-irq.o
+obj-$(CONFIG_PARISC64) += setup-bus.o
ifndef CONFIG_X86
obj-y += syscall.o
Index: drivers/pci/pci.c
===
RCS file: /home/cvs/parisc/linux/drivers/pci/pci.c,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 pci.c
--- pci.c 2001/01/09 16:57:56 1.1.1.6
+++ pci.c 2001/03/02 18:44:59
@@ -615,6 +615,7 @@ static void pci_read_bases(struct pci_de
}
}
+
void __init pci_read_bridge_bases(struct pci_bus *child)
{
struct pci_dev *dev = child->self;
@@ -628,7 +629,7 @@ void __init pci_read_bridge_bases(struct
if (!dev) /* It's a host bus, nothing to read */
return;
- for(i=0; i<3; i++)
+ for(i=0; i<4; i++)
child->resource[i] = >resource[PCI_BRIDGE_RESOURCES+i];
res = child->resource[0];
@@ -644,12 +645,16 @@ void __init pci_read_bridge_bases(struct
res->end = limit + 0xfff;
res->name = child->name;
} else {
+
/*
-* Ugh. We don't know enough about this bridge. Just assume
-* that it's entirely transparent.
+* Either this is not a PCI-PCI bridge or it's not
+* configured yet. Since this code only supports PCI-PCI
+* bridge, we better not be called for any other type.
+* Don't muck the resources since it will confuse the
+* platform specific code which does that.
*/
- printk("Unknown bridge resource %d: assuming transparent\n", 0);
- child->resource[0] = child->parent->resource[0];
+ printk("PCI : ignoring %s PCI-PCI bridge (I/O BASE not configured)\n",
+child->self->slot_name);
+ return;
}
res = child->resource[1];
@@ -664,8 +669,8 @@ void __init pci_read_bridge_bases(struct
res->name = child->name;
} else {
/* See comment above. Same thing */
- printk("Unknown bridge resource %d: assuming transparent\n", 1);
- child->resource[1] = child->parent->resource[1];
+ printk("PCI : ignoring %s PCI-PCI bridge (MMIO base not
+configured)\n", child->self->slot_name);
+ return;
}
res = child->resource[2];
@@ -690,11 +695,10 @@ void __init pci_read_bridge_bases(struct
res->end = limit + 0xf;
res->name = child->name;
} else {
- /* See comments above */
- printk("Unknown bridge resource %d: assuming transparent\n", 2);
- child->resource[2] = child->parent->resource[2];
+ /* Base > limit means the prefetchable mem is disabled.*/
}
}
+
static struct pci_bus * __init pci_alloc_bus(void)
{
Index: drivers/pci/setup-bus.c
===
RCS file: /home/cvs/parisc/linux/drivers/pci/setup-bus.c,v
retrieving revision 1.1.1.2
retrieving revision 1.5
diff -u -p -r1.1.1.2 -r1.5
--- setup-bus.c 2001/01/09 16:57:56 1.1.1.2
+++ setup-bus.c 2001/02/22 01:11:47 1.5
@@ -23,7 +23,7 @@
#include
-#define DEBUG_CONFIG 1
+#define DEBUG_CONFIG 0
#if DEBUG_CONFIG
# define DBGC(args) printk args
#else
@@ -32,6 +32,7 @@
#define ROUND_UP(x, a) (((x) + (a) - 1) & ~((a) - 1))
+
static int __init
pbus_assign_resources_sorted(struct pci_bus *bus,
struct pbus_set_ranges_data *ranges)
@@ -46,7 +47,6 @@ pbus_assign_resources_sorted(struct pci_
for (ln=bus->devices.next; ln != >devices; ln=ln->next) {
struct pci_dev *dev = pci_dev_b(ln);
u16 class =
Re: scsi vs ide performance on fsync's
Okay I now have to create TCQ for ATA becasue I am not going to lose again now that I am winning ;-) On Fri, 2 Mar 2001, Chris Mason wrote: > > > On Friday, March 02, 2001 12:39:01 PM -0600 Steve Lord <[EMAIL PROTECTED]> wrote: > > [ file_fsync syncs all dirty buffers on the FS ] > > > > So it looks like fsync is going to cost more for bigger devices. Given the > > O_SYNC changes Stephen Tweedie did, couldnt fsync look more like this: > > > > down(>i_sem); > > filemap_fdatasync(ip->i_mapping); > > fsync_inode_buffers(ip); > > filemap_fdatawait(ip->i_mapping); > > up(>i_sem); > > > > reiserfs might need to trigger a commit on fsync, so the fs specific fsync > op needs to be called. But, you should not need to call file_fsync in the > XFS fsync call (check out ext2's) > > For why ide is beating scsi in this benchmark...make sure tagged queueing > is on (or increase the queue length?). For the xlog.c test posted, I would > expect scsi to get faster than ide as the size of the write increases. > > -chris > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > 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/
Found out why "sg" was loaded automagically. Re: devfs: "cd" device not showing up initially.
Some time ago, I posted a question concerning the device name "cd" (module sr_mod) not appearing automatically under my 2.4.x devfs/devfsd configuration. However, "generic" (module sg) does appear automagically. This confused me a bit. The subject I used back then was like "devfs: "cd" device not showing up initially. Doug Gilbert was kind enough to explain to me that the module loading needed be done explicitly for sr_mod so that "cd" entries were registered by devfs/devfsd. Then I came to wonder why "generic" registeted by the module sg showed up. I thought that I was not calling for automatic loading of "sg" myself. After a bit of exchange, Doug even went so far as to read my config files to check for obvious mistakes, and we could not find one. It took me a while to figure out why "sg" was inserted automatically. The cause had nothing to do with devfs/devfsd interaction. I found the answer today. Short answer: On my Debian GNU/Linux PC, /etc/rcS.d/S20modutils (a symlink to /etc/init.d/modutils ) calls modprobe to install modules listed in a file called /etc/modules at boot time, and "sg" was listed there. (I don't know / have forgotten why "sg" is listed there.) I didn't realize that Debian uses this /etc/modules file as part of its grand module configuration scheme. (Or I have forgotten about this completely.) --- somewhat longer description. I followed the suggestions given by various parties after my post, and when I inserted the printk() inside a few scsi-related modules as suggested by Doug Gilbert, the problem became immediately apparent. The module "sg" was inserted by "modprobe", which in turn was called from "S20modutils". (swapon had nothing to do with the "sg" loading as I recently suspected.) [I was going to insert "echo this is $0 or something to that effect in all of the init script files to see where the sg loading was taking place, but embedding the printk in a few C source files was easiter and so I tried it first.] After seeing the message in dmesg output (now I use 128KB buffer for printk to capture all the devfs/devfsd interaction debug messages), I had to read /etc/init.d/S20modutils to find out why. It turns out the Debian module init script uses /etc/modules to list kernel module names that need to be inserted at boot up time. And, for reasons unknown to me (now), the name "sg" was there (!). I should have realized that something was amiss when lsmod showed unused modules as in tmscsim29920 0 (unused) sg 25728 0 (unused) nls_cp437 4384 0 (unused) hpfs 69216 0 (unused) tmscsim is where the CD changer is located. Until I manually mount a CD in there, the module is unused. But what about other threes? Forgetting about "sg", I had a nagging suspition especially about the last two entries. Why are they loaded at all? I could not figure out why until today. These are also listed in /etc/modules, and "auto" is not given. So kerneld is not started at boot time... FYO, just to show what the lsmod output looks like after mounting a CD in nakamichi changer. >duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2 >mount: special device /dev/scsi/host1/bus0/target6/lun0/cd does not exist (* Oops I have forgotten the manual loading of sr_mod.o *) >duron:/home/ishikawa# mkdir /mnt2 >mkdir: cannot create directory `/mnt2': File exists >duron:/home/ishikawa# modprobe sr_mod >duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2 >mount: block device /dev/scsi/host1/bus0/target6/lun0/cd is write-protected, mounting >read-only >duron:/home/ishikawa# lsmod >Module Size Used by >isofs 19280 1 (autoclean) >sr_mod 13200 1 >cdrom 26912 0 [sr_mod] >tmscsim29920 1 >sg 25728 0 (unused) >nls_cp437 4384 0 (unused) >hpfs 69216 0 (unused) >duron:/home/ishikawa# ls /mnt2 >Copyright Solaris_2.7 >duron:/home/ishikawa# This final answer that I am posting today only shows that I have been using module loading under linux for quite a long time without understanding its implementation ver well. (The first time I used module loading was to re-order the scsi host scanning about three or four years ago. Using module was one of the few wasy aside from physically swaping bus slots to change the scaned order of host adaptors back then. The original kernel/distribution that I used then was the one that came Yggrdrasil 1994, but I had upgraded various pieces to use more modern kernel and tools. I switched to Debian about two or three years ago. Now I figure I must have have bumped into this module configuration issues back when I switched to Debian, but I must have taken care of them quickly and forgotten about them completely if so.) So anyway, this finally has answered my question that originated from my observation about
