Re: bug database braindump from the kernel summit

[Richard Russon]

On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote:
> Let's hope it's not a flamewar, but here goes :)
> 
> We -need- .config, but /proc/config seems like pure bloat.

Don't ask me for sample code, but...

The init code for many drivers is freed up after it's used.
Could we apply the same technique and compile in .config,
then printk the entire lot (boot option) and free up the
space afterwards?

FlatCap (Richard Russon)
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: Kernel 2.4.3 oops when hard linking UMSDOS files

[Peter Fales]

1.  Kernel 2.4.3 oops when hard linking UMSDOS files

2.  I can consistently generate a kernel oops by creating a file on 
a UMSDOS file system, and attempting to create a hard link to it.
The same procedure has always worked fine on the 2.2 seriels
kernels.

3. umsdos, link, hard-link

4. Kernel version 2.4.3, umsdos loaded as a module

5. 

Unable to handle kernel NULL pointer dereference at virtual address 0004
c013f1d6
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010283
eax:    ebx: 0fff   ecx: c31f7040   edx: c31f7ce0
esi: c79b65a0   edi: c31f7ce0   ebp: c314effe   esp: c3169c6c
ds: 0018   es: 0018   ss: 0018
Process ln (pid: 1380, stackpage=c3169000)
Stack: c1234320 c31f7ce0 c31f7ce0 c3169f40 c314efff c1227e6c c905aa90 c31f7ce0 
    c79b65a0  c314e000 1000 c31f7be0 c31f7ce0 c31f7ce0 
   c3169f40 c905cb58 c31f7ce0 c314e000 1000 c382c800 c382c080  
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] 
Code: 3b 50 04 74 0b 8b 72 0c 89 74 24 14 39 f2 75 1a 8b 7c 24 20 

>>EIP; c013f1d6 <__d_path+ba/128>   <=
Trace; c905aa90 <[umsdos]umsdos_d_path+58/98>
Trace; c905cb58 <[umsdos]UMSDOS_link+340/418>
Trace; c905a9ca <[umsdos]umsdos_lookup_dentry+52/c0>
Trace; c905f86d <[umsdos]start_ind_dev.493+916/a67>
Trace; c905d5ab <[umsdos]umsdos_get_emd_dentry+13/18>
Trace; c905f86d <[umsdos]start_ind_dev.493+916/a67>
Trace; c905ae32 <[umsdos]umsdos_set_dirinfo_new+2a/30>
Trace; c905ae4c <[umsdos]umsdos_patch_dentry_inode+14/80>
Trace; c013ebc8 
Trace; c905a8ae <[umsdos]UMSDOS_lookup+12/38>
Trace; c905aa0a <[umsdos]umsdos_lookup_dentry+92/c0>
Trace; c013e677 
Trace; c905c1cc <[umsdos]umsdos_endlookup+40/44>
Trace; c905a83e <[umsdos]umsdos_lookup_x+1ca/228>
Trace; c0110444 
Trace; c0128078 
Trace; c0121861 <__find_get_page+2d/68>
Trace; c0137142 
Trace; c0137a5a 
Trace; c0139eab 
Trace; c0137142 
Trace; c01391c6 
Trace; c01392c6 
Trace; c01350a6 
Trace; c0106e73 
Code;  c013f1d6 <__d_path+ba/128>
 <_EIP>:
Code;  c013f1d6 <__d_path+ba/128>   <=
   0:   3b 50 04  cmp0x4(%eax),%edx   <=
Code;  c013f1d9 <__d_path+bd/128>
   3:   74 0b je 10 <_EIP+0x10> c013f1e6 <__d_path+ca/128>
Code;  c013f1db <__d_path+bf/128>
   5:   8b 72 0c  mov0xc(%edx),%esi
Code;  c013f1de <__d_path+c2/128>
   8:   89 74 24 14   mov%esi,0x14(%esp,1)
Code;  c013f1e2 <__d_path+c6/128>
   c:   39 f2 cmp%esi,%edx
Code;  c013f1e4 <__d_path+c8/128>
   e:   75 1a jne2a <_EIP+0x2a> c013f200 <__d_path+e4/128>
Code;  c013f1e6 <__d_path+ca/128>
  10:   8b 7c 24 20   mov0x20(%esp,1),%edi


6. # /usr1 is a UMSDOS file system
   date > /usr1/jnk1
   ln /usr1/jnk1 /usr1/jnk2

7. AFAIK environment configuration is not critical, other than using
   a UMSDOS file system.


-- 
Peter Fales
[EMAIL PROTECTED] or [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: bug database braindump from the kernel summit

[David Lang]

Miles, if the system is just sending the config info it may not be a
problem, but take the microsoft example, how do you know the bug report is
just sending info that is relevent to the system and not trying to
discover everything that you have installed in your system (in our case we
can't be looking for pirated software, but assuming that the bug report is
being sent as root how do you know that it's not sending out your password
file if it just send 'stuff' out)

David Lang

 On Sun, 1 Apr 2001, Miles Lane wrote:

> David Lang wrote:
> >
> > On Sun, 1 Apr 2001, Larry McVoy wrote:
> >
> > when generating the auto bug reports make sure that the system tells the
> > user exactly what data is being sent.
> >
> > sending a large chunk of unknown data off the machine is a big concern to
> > many people.
>
> Yeah.  This is a good point, although I can't think of info
> about a system's hardware and software configuration that would
> be particularly sensitive, other than files that contain network
> topology or encrypted passwords.  I'm sure others can come up
> with such a list.  One candidate might be the smbfs configuration
> file, since network passwords can live there, right?  tcpdump output
> might also be sensitive, but that type of info would need to get
> requested by network driver developers after the initial bug report
> anyhow.
>
>   Miles
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

System clock loses time at approx 17 secs per two hours

[Eric Gillespie]

First off, CC: back to me, as my machine can't handle an estimated 200
messages a day for me to sign up to the list 8-( - Anyway..

I updated my kernel to 2.4.3 when the patch was released. (Tarballs -
wonderful things!)

However, I noticed that the kernel timer loses seconds over time with both the
2.4.2 and 2.4.3 kernels (seems to be at a steady rate...), and the rate of
loss is NOT related to the CMOS clock. I compared against a 2.2.18 kernel,
which lost about 1 second in 14 hours - about what I'd expect with my
machine).

Now, has anybody else noticed their 2.4.x kernel losing time?  If so, and
anyone knows how I can fix it so it behaves like 2.2.18, I'd be grateful.


Can't say I like the April Fools release on "behalf" of Linus.


===
Some relevant data:
 Linux version 2.4.3 ([EMAIL PROTECTED])
 (gcc version 2.95.3 19991030 (prerelease)) #2 Sat Mar 31 09:52:39 NZST 2001

Software present (among others) 
Gnu C  2.95.3  Gnu make   3.77
binutils   2.9.5.0.31  Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2

Processor information (from /proc/cpuinfo) for a Cyrix-M II-300:
processor   : 0
vendor_id   : CyrixInstead
cpu family  : 6
model   : 2
model name  : M II 3.5x Core/Bus Clock
stepping: 8
cpu MHz : 233.030
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de tsc msr cx8 pge cmov mmx cyrix_arr
bogomips: 465.30

Loaded driver and hardware information (/proc/ioports, /proc/iomem)
==Drivers==
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0220-022f : soundblaster
02f8-02ff : serial(auto)
0300-031f : eth0
0376-0376 : ide1
0388-038b : Yamaha OPL3
03c0-03df : vesafb
03f6-03f6 : ide0
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
4000-400f : Silicon Integrated Systems [SiS] 5513 [IDE]
  4000-4007 : ide0
  4008-400f : ide1
e000-e07f : Silicon Integrated Systems [SiS] 5597/5598 VGA
==memory info==
-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-01cf : System RAM
  0010-001e9c4f : Kernel code
  001e9c50-002445d7 : Kernel data
0800-082f : vesafb
e100-e13f : Silicon Integrated Systems [SiS] 5597/5598 VGA
e140-e140 : Silicon Integrated Systems [SiS] 5597/5598 VGA
e141-e141 : Rockwell International HCF 56k V90 FaxModem
[7.5.] PCI information ('lspci -vvv' as root)
==PCI Information==

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 10)
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- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at 4000 [size=16]

00:0b.0 Serial controller: Rockwell International HCF 56k V90 FaxModem (rev 01) 
(prog-if 00 [8250])
Subsystem: Aztech System Ltd MDP3858SP-A SVD Modem
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR-  [disabled] [size=32K]



-- 
 /|   _,.:*^*:.,   |\   Cheers from the Viking family, 
| |_/'  viking@ `\_| |including Pippin, our cat
|flying-brick| $FunnyMail  Bilbo   : Now far ahead the Road has gone,
 \_.caverock.net.nz_/ 5.39in LOTR  : Let others follow it who can!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Asus CUV4X-D, 2.4.3 crashes at boot

[Simon Garner]

Hi all,

>
> However, the machine now crashes at "Configuring Kernel Parameters" during
> rc initialisation:
>
>
> Welcome to Red Hat Linux
> Press 'I' for interactive startup
>
> Mounting /proc filesystem...[   OK   ]
> Configuring Kernel Parameters...
>
>
> This is if I type "linux noapic" at the Lilo boot prompt.
>
> Also, what do I lose by running with noapic?
>
>


Just discovered the above is not quite correct - it actually says [  OK  ]
after Configuring Kernel Parameters, and crashes on the next line.

Reading through /etc/rc.d/rc.sysinit, the next line is where it sets the
system clock. If I comment out the line:

/sbin/hwclock $CLOCKFLAGS

Then the system will boot OK with 'noapic'. So presumably the system RTC is
not accessed in a SMP-compatible way without APIC.

Anyway, I'm not too happy about having to run without APIC - seems more of a
workaround than a fix. I'm happy to test patches etc if anyone has any
ideas - this problem I presume affects all motherboards using the VIA 694XDP
chipset.


Thanks in advance,

Simon Garner

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Miles Lane]

David Lang wrote:
> 
> On Sun, 1 Apr 2001, Larry McVoy wrote:
> 
> when generating the auto bug reports make sure that the system tells the
> user exactly what data is being sent.
> 
> sending a large chunk of unknown data off the machine is a big concern to
> many people.

Yeah.  This is a good point, although I can't think of info
about a system's hardware and software configuration that would
be particularly sensitive, other than files that contain network
topology or encrypted passwords.  I'm sure others can come up
with such a list.  One candidate might be the smbfs configuration
file, since network passwords can live there, right?  tcpdump output
might also be sensitive, but that type of info would need to get 
requested by network driver developers after the initial bug report 
anyhow.  

Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Miles Lane]

Jeff Garzik wrote:



> /proc/pci data alone with every bug report is usually invaluable.  It
> gives you a really good idea of the general layout of the system, and
> you can often catch or become aware of related hardware characteristics
> which

I often see requests for the output of "lspci -vvxxx" when developers
are looking into problems with handling pci bus bridging and quirks
in specific hardware.  For example, this info has been requested of
me for debugging a problem handling my Neomagic 2160, at least one
bug in early Yenta code and so on.  Does /proc/pci get you all the
information that would be obtained with "lspci -vvxxx"?

> linux/REPORTINGS-BUGS was created to give users a hint that we need
> -more- information, and tells exactly what general information is useful
> to provide.  We do not need less information.

Agreed.

Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

IDE DMA Problem? (or at least behavior change) 2.2/2.4

[James Turinsky (LKML)]

Hi esteemed kernel hackers!

For some time now I've been encountering the following problem:

1) background info:

Hard drive is

/dev/hda:

 Model=IBM-DTTA-371010, FwRev=T77OA73A, SerialNo=WL0WLF36394
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=465kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=19746720
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2

IDE controllers are

00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II] (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR-  [disabled] [size=64K]
Capabilities: [58] 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-

This is an IBM Deskstar 10GXP (7200rpm 10GB) UDMA/33? drive which I've
either had on the PIIX3 or Promise Ultra66 controller (unhacked with
latest BIOS).

2) The problem itself:

I manually run hdparm -c1 -d1 -k1 -K1 -m16 on /dev/hda (currently on
Ultra66 but same on PIIX3).
The drive uses DMA fine for a while, and then at some point the
following happens (from dmesg):

hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: DMA disabled
ide0: reset: success

I don't remember if this is exactly how the message was in 2.2.x but
ide0 did reset.

In 2.2.x I could re-issue hdparm -d1 /dev/hda and the drive would go
back to using DMA.  Now, in 2.4.x, it barfs out the same error as above
(and pauses for several seconds) if say "sync" or "updatedb" commands
are issued.  Apparently short of rebooting I can't re-enable DMA.

One of the things I have noticed but I don't know is related is that the
buffers part of "free" seems to be really small around the time this
happens:

 total   used   free sharedbuffers
cached
Mem:126820  79548  47272  0   2680
34220
-/+ buffers/cache:  42648  84172
Swap:   262576 36 262540

Otherwise, the drive seems to do work fine in DMA or non-DMA modes.  I'm
not doing anything particularly disk-intensive...

[root@Sarah hda]# cat /proc/interrupts
   CPU0
  0:   19754320  XT-PIC  timer
  1:  3  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  3:  9  XT-PIC  serial
  4:  9  XT-PIC  serial
  8:  5  XT-PIC  rtc
  9:  0  XT-PIC  usb-uhci
 10: 165521  XT-PIC  eth0
 11:  88076  XT-PIC  ide0, ide1
 12:  0  XT-PIC  PS/2 Mouse
NMI:  0
ERR:  0

System just handles my mail (l-k and a few other messages a day), serves
out a few 404's an hour with Apache, and runs SETI@Home.

Is this a bug, glitch, or normal behavior?

Below please find additional info which hopefully answers some questions
before you ask them.

Thanks.
JT

--begin diagnostic stuff--

(Linux-Mandrake 7.2)

uptime:
  1:20am  up 2 days,  6:57,  1 user,  load average: 1.00, 1.00, 0.93

dmesg:
Linux version 2.4.3 () (gcc version 2.95.3 19991030 (prerelease)) #1 Fri
Mar 30 17:21:54 GMT 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009e800 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f820a - 0010 (reserved)
 BIOS-e820: 0010 - 0800 (usable)
 BIOS-e820: 820a - 0001 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
mapped APIC to e000 (01223000)
Kernel command line: auto BOOT_IMAGE=linux ro root=302 ide=reverse
ide_setup: ide=reverse : Enabled support for IDE inverse scan order.
Initializing CPU#0
Detected 398.625 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 796.26 BogoMIPS
Memory: 126612k/131072k available (1054k kernel code, 4068k reserved,
379k data, 208k init, 0k highmem)
Dentry-cache hash table entries: 16384 

Re: Serial, 115Kbps, 2.2, 2.4

[Manfred H. Winter]

Hi Trever!

On Sun, 01 Apr 2001, Trever L. Adams wrote:

> I am trying to find out if I am the only one who has pppd drop packets 
> as bogus when the port is set at 115Kbps.  I only get it at that speed. 
>   It causes stall outs etc.
>

I also have some problems with pppd. At my machine it says sometimes:

Couldn't set tty to PPP discipline: Invalid argument

I'm also using the serial port at 115Kps with a USR Sportster Voice
33.6.

Manfred
-- 
 /"\| PGP-Key available at Public Key Servers
 \ /  ASCII ribbon campaign | or at "http://www.mahowi.de/"
  X   against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA
 / \  and postings  | GPG: 0x88BC3576 * ICQ: 61597169
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

MTRR

[mythos]

Using Matrox G400 dualhead and a K7V I get the following message:

mtrr: base(0xe200) is not aligned on a size(0x180) boundary
mtrr: base(0xe200) is not aligned on a size(0x180) boundary
mtrr: no MTRR for e380,80 found

Can anybody tell why is this happening?

Mythos

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Asus CUV4X-D, 2.4.3 crashes at boot

[Simon Garner]

From: "Jeff Garzik" <[EMAIL PROTECTED]>

> (private reply, because I have lost discussion context)
>
> Have you tried booting with 'noapic'?
>
>


Thanks Jeff, this seems to fix the problem, and also fixes my problem with
the aic7xxx scsi driver ABORTing multiple times at startup (which I presumed
was unrelated).

However, the machine now crashes at "Configuring Kernel Parameters" during
rc initialisation:


Welcome to Red Hat Linux
Press 'I' for interactive startup

Mounting /proc filesystem...[   OK   ]
Configuring Kernel Parameters...


This is if I type "linux noapic" at the Lilo boot prompt.

Also, what do I lose by running with noapic?


Thanks

Simon Garner

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial, 115Kbps, 2.2, 2.4

[Tom Sightler]

Actually, I do have a similar problem that I've been unable to track down
100%.  Under 2.4.x when I run the modem on my Xircom Cardbus 10/100
Ethernet/56K Modem combo card (installed in a Dell 5000e with 650Mhz Pentium
III) I get a fair number of dropped packets at 115Kbps, enough to cause
problems and a significant speed decrease.  Simply dropping the serial port
rate to 56K seems to solve the problem.  I'm actually suspicious that the
hardware handshaking isn't working quite right, but I haven't take the time
to look at it.

I never noticed the problem under 2.2.x, but the last kernel I ran from that
era was the 2.2.16 kernel included with Redhat 7.  I've really not looked at
it very hard, backing the speed down to 56K was a good enough solution for
me for now, the Xircom has such a troublesome history that I just blamed it
on that but your report makes me more curious.

Later,
Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 bus numbering

[Justin T. Gibbs]

>On Sun, 1 Apr 2001, Douglas Gilbert wrote:
>
>[...]
>
>> >  scsihosts  <
>>
>> As a boot time option try:
>>   scsihosts=aic7xxx:ncr53c8xxx
>> or if you are using lilo, in /etc/lilo.conf add:
>>   append="scsihosts=aic7xxx:ncr53c8xxx"
>
>that does indeed change the bus numbering. Unfortunately, even
>with this option, the first disk on the ncr controller becomes
>"/dev/sda" ...
>
>regards,
>   Peter Daum

This is probably because the aic7xxx driver is not linked into
the scsi "library" for statically compiled HBA drivers.  It is
linked directly into the kernel and I believe is after the scsi.a
entry on the link line.  I'll look into this on monday.

--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bug database braindump from the kernel summit

[Ben Ford]

Why not have the /proc/config option but instead of being plain text, 
make it binary with a userspace app that can interpret it?

It could have a signature as to kernel version + patches and the rest 
would be just bits.

Instead of:

CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

You'd have
2.4.3-pre3:110101 . . . . .

-b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 mmap() works?

[Andreas Bombe]

On Sun, Apr 01, 2001 at 03:28:05PM -0500, Tim Hockin wrote:
> > Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
> > when pages have to be freed (I think also when the bdflush writes back
> > data, i.e. every 30 seconds by default).
> 
> what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ?

They map physically present memory directly and do not have to be
synced, since all writes go directly to their destination (which is of
course not possible with disk files).  I'm not that sure if PCI is a bit
special case though, since not all architectures can access it like
memory.

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial, 115Kbps, 2.2, 2.4

[Trever L. Adams]

Mark Hahn wrote:

>> There may be a possibility this is machine specific, because if it is 
>> meant to forward the packet to the internal net and I slow the machine 
>> down (external cache off) it works fine, turn the cache back on and it 
>> is a problem.
> 
> 
> where's the serial port?  (isa, pci?)  could there be a problem
> with something being overclocked (like >8 MHz ISA, etc)?
> also, is the port's fifo detected and used?


As far as I know the system is not overclocked (standard Digital 
Venturis 6200 GL PPro 200 Mhz machine).  It is an ISA modem.  All info I 
have on the port is as follows:

Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ 
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A

cat /proc/ioports
03f8-03ff : serial(auto)

It is a USR 56K Voice/Fax/Modem.  I am unable to find the exact model. 
It was definitely pre v.90 though I believe it has been updated 
(Firmware) to that.  I have another, though I don't remember similar 
problems even though it was at the same baudrate (different machine though).

Trever Adams

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

NFS Bug in 2.4.3?

[J.]

There is an NFS bug described here 

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=30944

that seems to have been known about for a while that is not fixed in
2.4.3.  Is there something wrong with the patch that is discussed?

Thanks,

tjb





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Possible Bug: Kernel Parameter 'scsihosts' Doesn't Work In 2.4.3?

[J.]

Is the 'scsihosts' kernel parameter broken in 2.4.3?  It has worked in
2.4.0 - 2.4.2 but doesn't seem to now.  Using 

append="apm=power-off scsihosts=aic7xxx,BusLogic"

in my lilo.conf, the BusLogic is found first.

Thanks,

tjb



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, David Lang wrote:
> On Sun, 1 Apr 2001, Jeff Garzik wrote:
> > /sbin/installkernel copies stuff into /boot, appending a version number.
> > One way might be to have this script also copy the kernel config.

> could be, /sbin/installkernel doesn't exist on my systems

arch/i386/boot/install.sh has been calling /sbin/installkernel, if it
exists, for a good while now.

It sounds like your kernel or initscripts package is incomplete.
You can grab installkernel off a Mandrake- or RedHat-based system.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial, 115Kbps, 2.2, 2.4

[Jeff Chua]

On Sun, 1 Apr 2001, Trever L. Adams wrote:

> I am trying to find out if I am the only one who has pppd drop packets
> as bogus when the port is set at 115Kbps.  I only get it at that speed.
>   It causes stall outs etc.
>
works fine for me.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Asus CUV4X-D, 2.4.3 crashes at boot

[Simon Garner]

From: "Keith Owens" <[EMAIL PROTECTED]>

> >Doesn't matter. The NMI-watchdog tries to detect SMP-lockups, and is
> >always present. Unless you specifically disable it on boot.
>
> Not any more.  In 2.4.3-ac* the default is no watchdog and it must be
> specifically enabled at boot.
>


nmi_watchdog 0 didn't help - the above would explain why.

Any more ideas? My expensive server is basically useless because of this. :(

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[David Lang]

Jeff, my point was that not all systems will have this script. also it
won't do you any good if the system you are compiling on is not the same
system the kernel will be running on

but we are starting the wrong discussion here :-)

David Lang

On Sun, 1 Apr 2001, Jeff Garzik
wrote:

> On Sun, 1 Apr 2001, David Lang wrote:
> > On Sun, 1 Apr 2001, Jeff Garzik wrote:
> > > /sbin/installkernel copies stuff into /boot, appending a version number.
> > > One way might be to have this script also copy the kernel config.
>
> > could be, /sbin/installkernel doesn't exist on my systems
>
> arch/i386/boot/install.sh has been calling /sbin/installkernel, if it
> exists, for a good while now.
>
> It sounds like your kernel or initscripts package is incomplete.
> You can grab installkernel off a Mandrake- or RedHat-based system.
>
>   Jeff
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[David Lang]

could be, /sbin/installkernel doesn't exist on my systems

David Lang

On Sun, 1 Apr 2001, Jeff Garzik wrote:

> Date: Sun, 1 Apr 2001 18:34:07 -0500 (CDT)
> From: Jeff Garzik <[EMAIL PROTECTED]>
> To: David Lang <[EMAIL PROTECTED]>
> Cc: Manfred Spraul <[EMAIL PROTECTED]>,
>  Albert D. Cahalan <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
>  [EMAIL PROTECTED]
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, David Lang wrote:
> > /proc/config may be bloat, but we do need a way for the kernel config to
> > be tied to the kernel image that is running, however it is made available.
>
> /sbin/installkernel copies stuff into /boot, appending a version number.
> One way might be to have this script also copy the kernel config.
>
>   Jeff
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[David Lang]

Jeff, if the sysadmin had anything to do with setting up the box I would
agree with you, but there are cases where one person will boot a machine
and another will then need to find out what is going on.

I have seen systems with multiple kernels available on boot get booted
from the wrong kernel

I've also seen a machine running for years without being touched and then
a sysadmin is hired and has to work on it, how should they know what the
config was?

/proc/config may be bloat, but we do need a way for the kernel config to
be tied to the kernel image that is running, however it is made available.

David Lang

 On Sun, 1 Apr
2001, Jeff Garzik wrote:

>
> If a sysadmin (note I don't say "user") has no clue what his kernel
> config is, or has no clue what kernel is running on his box, then
> they should be fired before the day is out.
>
>   Jeff
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Larry McVoy wrote:
> Problem details
> Bug report quality
[...]
>   But the main thing was to extract all the info we could
>   automatically.  One thing was the machine config (hardware and
>   at least kernel version).  The other thing was extract any oops
>   messages and get a stack traceback.

Basically look through REPORTING-BUGS for a laundry list of helpful info.

>   The other main thing was to define some sort of structure to the
>   bug report and try and get the use to categorize if they could.
>   In an ideal world, we would use the maintainers file and the
>   stack traceback to cc the bug to the maintainer.  I think we want
>   to explore this a bit.  I'm not sure that the maintainer file is
>   the way to go, what if we divided it up into much broader chunks
>   like "fs", "vm", "network drivers", and had a mail forwarder
>   for each area.  That could fan out to the maintainers.

(slight tangent)
One thing people have talked about in the past is updating MAINTAINERS
to actually reflect real life...  some of the active maintainers
don't have maintainer entries.  That may be intentional, maybe not...

For drivers at least, bugs -should- be mailed to the driver
maintainer where possible, which is not always the same as the
subsystem maintainer.


> Signal/noise
[...]
>   Jens wants there to be a queue of 

Jes?

>   new bugs and a mechanism where people can come in the morning, pull
>   a pile of bugs off of the queue, sort them, sending some to the real
>   database.  This idea has a lot of merit, it needs some pondering as
>   DaveM would say, to get to the point that we have a workable mechanism
>   which works in a distributed fashion.

Back when I was hacking GNOME, various janitors (to use the now-popular
term) would go through and clean the bug database, sorting through a lot
of the noise.

Newbies are finding the Kernel Janitors project as an excellent way to
begin to contribute to the kernel.  There are definitely interested,
smart people willing to help, that at present don't know a lot about the
kernel.  Such volunteers, like the GNOMEs mentioned above, could be a
vast benefit to this particular step of the bug tracking process.  You
http://sourceforge.net/projects/kernel-janitor/

> Past experiences
> This is a catch all for sound bytes that we don't want to forget...
> 
> - one key observation: let bugs "expire" much like news expires.  If
>   nobody has been whining enough that it gets into the high signal 
>   bug db then it probably isn't real.  We really want a way where no
>   activity means let it expire.

Agreed, with a caveat:  some bugs should stay around but not expire.
There is a class of bugs that shouldn't go away from the "less noise"
bug database when there is no activity.  ie. hard problems we want to
remember, but solve in a later version.


> Requirements

1) An e-mail interface.

For sorting through massive amounts of bugs, NNTP is far more useful.
Maybe as a query interface as well, NNTP is useful.  But for getting
into the nitty-gritty details of handling a bug, e-mail is generally the
primary medium of communication between developer and user.

debian-bugs assigns each bug a unique e-mail address, and all e-mail
that arrives in that mailbox is appended to the bug's comments.

2) Support for binary attachments from users


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, David Lang wrote:
> /proc/config may be bloat, but we do need a way for the kernel config to
> be tied to the kernel image that is running, however it is made available.

/sbin/installkernel copies stuff into /boot, appending a version number.
One way might be to have this script also copy the kernel config.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, David Lang wrote:
> if we want to get the .config as part of the report then we need to make
> it part of the kernel in some standard way (the old /proc/config flamewar)
> it's difficult enough sometimes for the sysadmin of a box to know what
> kernel is running on it, let alone a bug reporting script.

Let's hope it's not a flamewar, but here goes :)

We -need- .config, but /proc/config seems like pure bloat.

If a sysadmin (note I don't say "user") has no clue what his kernel
config is, or has no clue what kernel is running on his box, then
they should be fired before the day is out.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[David Lang]

if we want to get the .config as part of the report then we need to make
it part of the kernel in some standard way (the old /proc/config flamewar)
it's difficult enough sometimes for the sysadmin of a box to know what
kernel is running on it, let alone a bug reporting script.

David Lang

 On Sun, 1 Apr
2001, Jeff Garzik wrote:

> Date: Sun, 1 Apr 2001 17:48:34 -0500 (CDT)
> From: Jeff Garzik <[EMAIL PROTECTED]>
> To: Manfred Spraul <[EMAIL PROTECTED]>
> Cc: Albert D. Cahalan <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
>  [EMAIL PROTECTED]
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, Manfred Spraul wrote:
> > From: "Jeff Garzik" <[EMAIL PROTECTED]>
> > >
> > > /proc/pci data alone with every bug report is usually invaluable.
> >
> > Even if the bug is a compile error?
>
> In fact, yes.  Having the tuple of: .config, /proc/pci, and compile
> error output, you can see additionally if the user is doing something
> wrong.
>
> It allows you to fix the user as well as the compile error ;-)
>
>
> > E.g.
> > BUG REPORT (a real one, I didn't have the time yet to post a patch):
> > kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
> > Description:
> > Several config options are missing in the 'if' at the end of
> > linux/drivers/net/pcmcia/Config.in.
> > This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
> > kernel won't link.
> >
> > CONFIG_ARCNET_COM20020_CS
> > CONFIG_PCMCIA_HERMES
> > CONFIG_AIRONET4500_CS
> > CONFIG_PCMCIA_IBMTR
> > are missing.
>
> noted.
>
> > Obviously too much data doesn't hurt, as long as
> > * it's hidden somewhere deep in a database, clearly separated from the
> > important parts (if there is an oops: decoded oops, description, how
> > easy is it to trigger the bug, steps to reproduce)
> > * very easy for the bug reporter to collect.
> > * not mandatory.
>
> agreed.
>
> Regards,
>
>   Jeff
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Manfred Spraul wrote:
> From: "Jeff Garzik" <[EMAIL PROTECTED]>
> >
> > /proc/pci data alone with every bug report is usually invaluable.
> 
> Even if the bug is a compile error?

In fact, yes.  Having the tuple of: .config, /proc/pci, and compile
error output, you can see additionally if the user is doing something
wrong.

It allows you to fix the user as well as the compile error ;-)


> E.g.
> BUG REPORT (a real one, I didn't have the time yet to post a patch):
> kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
> Description:
> Several config options are missing in the 'if' at the end of
> linux/drivers/net/pcmcia/Config.in.
> This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
> kernel won't link.
> 
> CONFIG_ARCNET_COM20020_CS
> CONFIG_PCMCIA_HERMES
> CONFIG_AIRONET4500_CS
> CONFIG_PCMCIA_IBMTR
> are missing.

noted.

> Obviously too much data doesn't hurt, as long as
> * it's hidden somewhere deep in a database, clearly separated from the
> important parts (if there is an oops: decoded oops, description, how
> easy is it to trigger the bug, steps to reproduce)
> * very easy for the bug reporter to collect.
> * not mandatory.

agreed.

Regards,

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: unistd.h and 'extern's and 'syscall' "standard(?)"

[Tim Wright]

And furthermore, it's been around in Unix and unix-like systems for a very long
time. Sounds like the lack of man page is an oversight. Anybody want to write
one ?

Tim

On Sun, Apr 01, 2001 at 09:38:24PM +0100, Philip Blundell wrote:
> >of action to take.  Seeing as you work for suse, would you know
> >where this 'syscall(3)' interface should be documented?  Is it
> >supposed to be present in all distro's?  
> 
> It's documented in the glibc manual.  Yes, it should be present in all glibc 
> based distributions.
> 
> p.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent problems with APM and XFree86-4.0.1

[Rafael E. Herrera]

Jamie Lokier wrote:
> 
> I've noticed other changes in suspend/resume.  I'm running Gnome now,
> and it insists on running xscreensaver whenever I close the lid.
> Somehow it is noticing the APM event, because this is very consistent.
> Does anyone know how to disable this?  The setting "No screensaver"
> under the list of screensavers didn't help -- it just runs a blank
> screensaver which is even more confusing, because the computer appears
> not to have resumed (when it's just a black screensaver).

Look at the s option in the man pages for xset, that may help.

-- 
 Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Stephen Satchell]

At 10:54 AM 4/1/01 -0700, Larry McVoy wrote:
> - one key observation: let bugs "expire" much like news expires.  If
>   nobody has been whining enough that it gets into the high signal
>   bug db then it probably isn't real.  We really want a way where no
>   activity means let it expire.

I have a couple of suggestions that may improve the bug tracking process 
without needing a bug czar or driving everyone crazy.

1)  The idea of letting a bug "expire" is a good one.  One way to do this 
is to incorporate some form of user-base moderation into the bug 
database.  Unlike some of the forum systems, there's no reason why we can't 
have tiers of moderators:  "maintainers" are the clearinghouse people for 
certain portions of the Linux kernel source tree and should have a larger 
voice as to whether a bug is important, redundant, or completely off 
base.  "contributors" are people recognized as having contributed in one 
way or another to the source tree (or, as the bug systems grows to 
encompass documentation, the documentation tree) and could serve as a 
"citizens advisory group" to speed the process of sorting the wheat from 
the chaff.  Also, a "contributor" would be able to "take ownership" of the bug.

2)  One of the big problems is recognizing that a particular bug has 
already been reported, and more importantly getting some sort of link 
between the new bug and the old bug.  When I ran a DVT operation, the 
developers found this linkage to be extremely useful in order to trace the 
source of bugs, especially really obscure ones that cut across a number of 
modules.

3)  In the commercial software world, there is a requirement that a bug be 
verified by someone "in house" -- in other words, a bug isn't a bug until 
someone can reproduce it.  This is a key item in separating the noise from 
the signal.  Again, the group-moderation system would permit quick 
identification of repeatable bugs.

4)  Using an NNTP interface would be interesting.  "Follow-ups" could 
consist of observations, commands, and requests for additional information 
from the bug report that isn't visible from the basic NNTP tree.  If you 
want to see more about a bug, the tree representation could let you pick 
and choose what you want to look at.  For someone who prefers to have 
everything to hand, a command would say "email sections a, b, ... to me 
(with "me" defined in the NNTP headers) and those sections would be mailed 
to the individual.

5)  Most important, the person originally submitting the bug should have an 
easy way of saying "never mind."  Existing search commands in the NNTP 
interface could make this a very easy chore for the infrequent contributor.

EXPIRING:  It's one thing to do an expire a la standard NNTP conventions, 
but it's quite another to do something "smarter".  I see a couple of things 
that would have to enter into a decision whether to expire a bug from the 
pending-status list:

a)  The bug needs to be present for more than a set amount of time without 
overt activity.
b)  A person trying to replicate the bug should be able to extend the 
time-out -- some bugs take longer to replicate than others.  If you don't 
allow for this, the bug could be expired before it can be verified, and the 
verifier has to work harder (assuming they even bother) to extract the bug 
from the data mine and get it to where a code guy can get to it.
c)  A maintainer should be able to sink a bogus bug early, especially if no 
one has owned up to trying to replicate it or fix it.  Contributors can 
heartily declare a bug "bogus", and if enough do so the bug could be sunk 
early.  Also, if enough people say "I can't replicate this bug" that's a 
good sign you have a piece of noise.

 From my own experience in commercial shops, I'd say that we could start 
with an expire time of two weeks, and if necessary adjust it.  Weighting 
for each of the metrics for expiring bugs could be set experimentally.  The 
goal is that a maintainer can squash bugs NOW, and the community could 
actively squash bugs in 24 hours.

IS THE BUG FIXED:  When a bug is declared "fixed" the bug tracking system 
needs to alert everyone who has submitted the bug and replicated it.  This 
notification would then let those people (those who are still interested) 
see if the patch really fixes the bug.  If it does, confirmation of a bug 
fix would be included, and that would help Alan & Co. to determine what 
patches should go in.

Just a few random thoughts on the whole process -- but I suspect others 
have already thought of these things.  I'd be interested in working on 
this, day job willing.

Stephen Satchell
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: configuring net interfaces

[Jeff Garzik]

On 1 Apr 2001, Krzysztof Halasa wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
> > I'm not suggesting you modify ethtool for your needs :)   But ethtool
> > perfectly illustrates the technique of using a single socket ioctl
> > (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls
> > (ETHTOOL_xxx) to Linux networking drivers.
> 
> I know. The problem is I don't see here any advantages over many SIOCxxx
> command codes, while there are disadvantages.
> Simple things are IMHO better, and ioctl was designed to handle many
> simple commands (instead of one complex).
> 
> Am I missing something?

IMHO we should get away from adding hardware-type-specific ioctls
from the generic SIOCxxx list.

Sure it is easy to dump a bunch of new ioctls into sockios.h.
But having "one big header that covers all hardware types and ioctl
situations" does not seem like the right solution to me.

First of all, you as the HDLC subsystem maintainer have a lot more
control over what goes into include/linux/hdlc.h than
include/linux/sockios.h.  New SIOC ioctls should not be added on a
whim, but after examination of the issues involved.  Making a mistake
and adding a bad/pointless SIOC ioctl means you are stuck with it
for a long time.  The same applies to ioctls in hdlc.h of course -- but
the key distinction is that you are 100% sure of the issues involved
because changes are localized to your own domain.

Further, each change to sockios.h affects a LOT of code, both in
and outside the kernel.  Localizing your changes also localizes the
effects of bad namespace and ioctl choices (and bugs, though in this
case that would be rare).

Finally, I have this (perhaps crazy) idea that we should move in the
direction of removing ALL hardware-related ioctls from sockios.h, making
SIOC the domain of generic network device ioctls.

Comments welcome.  IMHO domain-specific ioctls are a better direction
than the current make-sockios.h-huge-with-new-ioctls approach.

Regards,

Jeff


P.S.  It would be awesome if you would consider CC'ing
[EMAIL PROTECTED]  Some developers who might have valuable input
do not subscribe to linux-kernel, or are not able to read all of the
net-related linux-kernel messages.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Manfred Spraul]

From: "Jeff Garzik" <[EMAIL PROTECTED]>
>
> /proc/pci data alone with every bug report is usually invaluable.

Even if the bug is a compile error?

E.g.
BUG REPORT (a real one, I didn't have the time yet to post a patch):
kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
Description:
Several config options are missing in the 'if' at the end of
linux/drivers/net/pcmcia/Config.in.
This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
kernel won't link.

CONFIG_ARCNET_COM20020_CS
CONFIG_PCMCIA_HERMES
CONFIG_AIRONET4500_CS
CONFIG_PCMCIA_IBMTR
are missing.

Obviously too much data doesn't hurt, as long as
* it's hidden somewhere deep in a database, clearly separated from the
important parts (if there is an oops: decoded oops, description, how
easy is it to trigger the bug, steps to reproduce)
* very easy for the bug reporter to collect.
* not mandatory.

--
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/

EXT2-fs error on 2.4.2 & 2.4.3

[Lukasz Trabinski]

Hello

I'm using 2.4.2 and 2.4.3, sometimes after cron jobs like slocate process
or checking md5sum on my file system(heavy load disk), i gets errors from
the kernel:

EXT2-fs error (device sd(8,3)): ext2_free_blocks: bit already cleared for
block
80275
EXT2-fs error (device sd(8,3)): ext2_free_blocks: bit already cleared for
block
80275
EXT2-fs error (device sd(8,3)): ext2_free_blocks: bit already cleared for
block
80275
[...]

This problems occurs on THREE machines (with heavy load disks) with
kernel 2.4.2[3] and I dont't  think that is a problems with disks or RAM.
Any idea?


-- 
*[ ukasz Trbiski ]*
SysAdmin @wsisiz.edu.pl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Recent problems with APM and XFree86-4.0.1

[Jamie Lokier]

Jamie Lokier wrote:
> > > On that theme of power management with X problems, I have been having
> > > trouble with my laptop crashing when the lid is closed, instead of
> > > suspending as it used to.  The laptop is a Toshiba Satellite 4070CDT.
> > 
> > Can you please try adding
> > Option  "NoPM"
> > to the device section of XF86Config or (XF86Config) and then try suspending
> > and resuming.
> > 
> > This made suspend/resume much more reliable on the Thinkpad 600E with
> > XFree86 4.  Also you could try XFree86 4.0.2, as I know that it actually
> > does interact with APM (4.0.1 may have as well - I am not sure).
> 
> I'll try Option "NoPM", and XFree86 4.0.2 if I can find a conveniently
> RH7 compatible RPM.

I tried Option "NoRPM" with XFree86 4.0.1 and it seems to have fixed the
problem!  Yay!  Closing lid: suspend happens after a few beeps.  Open
lid, computer resumes and is working normally.  I guess the new code in
XFree86 was problematic.  Perhaps it's fixed in 4.0.2, but I haven't
tried that.

I've noticed other changes in suspend/resume.  I'm running Gnome now,
and it insists on running xscreensaver whenever I close the lid.
Somehow it is noticing the APM event, because this is very consistent.
Does anyone know how to disable this?  The setting "No screensaver"
under the list of screensavers didn't help -- it just runs a blank
screensaver which is even more confusing, because the computer appears
not to have resumed (when it's just a black screensaver).

cheers,
-- Jamie



> 
> I should point out that I've been using _some_ version of XFree86 4
> since before version 4.0 was released.  (XFree86 3 doesn't support this
> laptop's video adapter).  Suspend/resume worked fine and reliably until
> recently.
> 
> Another problem is that occasionally when X starts now, it will freeze
> the system.  So I suspect a bug was introduced in XFree86 4.0.1.
> 
> -- Jamie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Jamie Lokier]

James Simmons wrote:
> >No, it's the Trident Cyber9525
> 
> Sorry. I only have a early driver for trident 9750 and 9850. Their is a
> gropup working on trident framebuffers.

Is it possible that "jump scroll" would provide more performance benefit
than an accelerated driver anyway?

Seeing as you bring up this topic of writing a 9525 driver.  It seems to
me rather wasteful that you (collectively linux framebuffer authors),
XFree86 and Berlin are all writing drivers for the same, hugely diverse
class of hardware, to support more or less the same ops on the hardware.

Isn't possible to pool the development effort of video drivers?  Doesn't
X require basically the same set of operations as the kernel?  I.e.,
initialise the card and video mode (usually the very complex part); do
some rendering ops (usually fairly simple).  Sure, X provides a few more
kinds of rendering op, but that part of the code is usually much simpler
and smaller than the initialisation code.

Sorry if this sounds insulting -- it isn't intended that way.  I don't
really know what is involved in writing video drivers.  All I am seeing
is an _apparent_ reinventing of a rather complex wheel, when it's hard
enough as it is to keep up with all the different cards.

thanks,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Sat, 31 Mar 2001, Rusty Russell wrote:
> > if (p->state == TASK_RUNNING ||
> > (p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
> > p->flags |= PF_SYNCING;
> 
> Setting a running task's flags brings races, AFAICT, and checking
> p->state is NOT sufficient, consider wait_event(): you need p->has_cpu
> here I think.

My thought here was that if p->state is anything other than TASK_RUNNING
or TASK_RUNNING|TASK_PREEMPTED, then that task is already at a
synchonize point, so we don't need to wait for it to arrive at another
one - it will get a consistent view of the data we are protecting.
wait_event() qualifies as a synchronize point, doesn't it?  Or am I
missing something?

> The only way I can see is to have a new element in "struct
> task_struct" saying "syncing now", which is protected by the runqueue
> lock.  This looks like (and I prefer wait queues, they have such nice
> helpers):
> 
>   static DECLARE_WAIT_QUEUE_HEAD(syncing_task);
>   static DECLARE_MUTEX(synchronize_kernel_mtx);
>   static int sync_count = 0;
> 
> schedule():
>   if (!(prev->state & TASK_PREEMPTED) && prev->syncing)
>   if (--sync_count == 0) wake_up(_task);

Don't forget to reset prev->syncing.  I agree with you about wait
queues, but didn't use them here because of the problem of avoiding
deadlock on the runqueue lock, which the wait queues also use.  The
above code in schedule needs the runqueue lock to protect sync_count.


Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [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: bug database braindump from the kernel summit

[David Lang]

On Sun, 1 Apr 2001, Larry McVoy wrote:

when generating the auto bug reports make sure that the system tells the
user exactly what data is being sent.

sending a large chunk of unknown data off the machine is a big concern to
many people.

David Lang


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Sat, 31 Mar 2001, george anzinger wrote:
> I think this should be:
> if (p->has_cpu || p->state & TASK_PREEMPTED)) {
> to catch tasks that were preempted with other states.

But the other states are all part of the state change that happens at a
non-preemtive schedule() point, aren't they, so those tasks are already
safe to access the data we are protecting.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [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: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Albert D. Cahalan wrote:
> Manfred Spraul writes:
> > [Larry McVoy]
> 
> >> There was a lot of discussion about possible tools
> >> that would dig out the /proc/pci info

> > I think the tools should not dig too much information out of the system.
> > I remember some Microsoft (win98 beta?) bugtracking software that
> > insisted on sending a several hundert kB long compressed blob with every
> > bug report.
> > IMHO it must be possible to file bugreports without the complete hw info
> > if I know that the bug isn't hw related.
> 
> Yep. The two hardware-related items that usually matter:
> 
> Little-endian or broken-endian?
> 32-bit or 64-bit?

Matters to whom?  You, or the people actually fixing bugs?

"Broken-endian"?  whatever.

/proc/pci data alone with every bug report is usually invaluable.  It
gives you a really good idea of the general layout of the system, and
you can often catch or become aware of related hardware characteristics
which 

linux/REPORTINGS-BUGS was created to give users a hint that we need
-more- information, and tells exactly what general information is useful
to provide.  We do not need less information.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 in drivers/block/Config.in (PATCH)

[Tim Waugh]

On Sat, Mar 31, 2001 at 04:00:27PM +0200, Pozsar Balazs wrote:

> On Fri, Mar 30, 2001 at 10:17:08PM +0200, Herbert Rosmanith wrote:
> In fact, if we want to get what is said in the comment, we should write:
> 
> if [ "$CONFIG_PARPORT" = "m" -a "$CONFIG_PARIDE_PARPORT" = "y" ] ; then
>define_bool CONFIG_PARIDE_PARPORT m
> fi

But the condition is never satisfied.

Tim.
*/

 PGP signature

Re: bug database braindump from the kernel summit

[David Lang]

oops, I was going to quote a section from Larry's mail then decided not to
and forgot to delete the header.

David Lang

On Sun, 1 Apr 2001, David Lang wrote:

> Date: Sun, 1 Apr 2001 14:16:57 -0700 (PDT)
> From: David Lang <[EMAIL PROTECTED]>
> To: Larry McVoy <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, Larry McVoy wrote:
>
> when generating the auto bug reports make sure that the system tells the
> user exactly what data is being sent.
>
> sending a large chunk of unknown data off the machine is a big concern to
> many people.
>
> David Lang
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 bus numbering

[Douglas Gilbert]

Peter Daum wrote:
> 
> On Sun, 1 Apr 2001, Douglas Gilbert wrote:
> 
> [...]
> 
> > >  scsihosts  <
> >
> > As a boot time option try:
> >   scsihosts=aic7xxx:ncr53c8xxx
> > or if you are using lilo, in /etc/lilo.conf add:
> >   append="scsihosts=aic7xxx:ncr53c8xxx"
> 
> that does indeed change the bus numbering. Unfortunately, even
> with this option, the first disk on the ncr controller becomes
> "/dev/sda" ...

Peter,
This indicates that the method being used by the 
new aic7xxx driver for initialization is broken 
with respect to other scsi adapters.

The intent is that all built in HBA drivers are
initialized _before_ the built in upper level 
drivers (e.g. sd). To get the effect you describe
the driver init order seems to have been:
  register ncr53c8xxx
  register sd
  register aic7xxx  # too late ...


Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Manfred Spraul wrote:
> > There was a lot of discussion about possible tools
> > that would dig out the /proc/pci info
> 
> I think the tools should not dig too much information out of the system.
> I remember some Microsoft (win98 beta?) bugtracking software that
> insisted on sending a several hundert kB long compressed blob with every
> bug report.
> IMHO it must be possible to file bugreports without the complete hw info
> if I know that the bug isn't hw related.

Two comments --
* It's only disk space.  It's better to have and not need, than need and
  not have.  Please do give me 200kb bug reports!  :)
* There should be a way to allow the user to omit hw info, because the
  user may not want to disclose some parts of their system.

Regards,

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Matrox G400 Dualhead

[mythos]

I solved the problem with dualhead!!!
Second head from 2.4.3 is /dev/fb2 rather than /dev/fb1.
Just had to look to the messages.
About matroxfb + X11 what I have seen is that if you use the same
resolution with the same number of colors as in X11 ,most of the times it will
work(except if I am in the login manager kdm!Then if I change to console
it will have the same screen).

P.S. Petr on the second head if I put mouse in the right-corner at the
bottom of the screen I will have a nice white border around the screen.
Also cursor blinks very strange if there is a lot of move on another
framebuffer on the first head and leaves some white blocks around.
I have used software and hardware cursor.

Mythos


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Albert D. Cahalan]

Gregory Maxwell writes:
> On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:

>> I'm really sick of being buried in useless information. The signal
>> gets lost in the noise. It is easy to discard automatically generated
>> bug reports, and way too annoying to wade through the crud.
>>
>> When network connections hang, the console-tools package version
>> isn't likely to be of any use. When ramfs leaks memory, nobody needs
>> the content of /proc/pci.
>>
>> Sometimes the bit of crud are HUGE. Imagine the hardware info
>> for a 64-way SGI or Sun box with plenty of devices attached.
>
> Disk space is 'free'.

Disk space isn't the issue. Just a few days ago I tried to help
somebody who posted one of the bloated fill-in-the-form bug reports.
I gave him a useless answer, because I didn't see amid all the junk
that he had no problems with a 2.2.xx kernel. The good information
had been buried in fluff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: unistd.h and 'extern's and 'syscall' "standard(?)"

[Philip Blundell]

>of action to take.  Seeing as you work for suse, would you know
>where this 'syscall(3)' interface should be documented?  Is it
>supposed to be present in all distro's?  

It's documented in the glibc manual.  Yes, it should be present in all glibc 
based distributions.

p.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[Gregory Maxwell]

On Sun, Apr 01, 2001 at 03:05:47PM -0500, Adam wrote:
> BZZT, wrong. Headers were forged intentionally to show pine since it is
> what Linus uses.
> 
> I had a joke for this year as well, but I didn't hear back from Linus if
> that's cool with him to send it to LKML (I suppose I should have asked him
> earlier than 24hrs) so I did not send it.
> 
> For those interested, a rought draft is at
> 
>   http://www.eax.com/linux2001/linux2001.txt

You forgot the obligatory Linus Thorvalds reference.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Gregory Maxwell]

On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:
> I'm really sick of being buried in useless information. The signal
> gets lost in the noise. It is easy to discard automatically generated
> bug reports, and way too annoying to wade through the crud.
> 
> When network connections hang, the console-tools package version
> isn't likely to be of any use. When ramfs leaks memory, nobody needs
> the content of /proc/pci.
> 
> Sometimes the bit of crud are HUGE. Imagine the hardware info
> for a 64-way SGI or Sun box with plenty of devices attached.

Disk space is 'free'. The information should be stored in a database where
you can retrieve the information you need at will, while the back-end can
statistically analyze the whole of the information looking for anomalies you
would never have expected (like that network hang actually being caused by
console-tools :) ).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Albert D. Cahalan]

Manfred Spraul writes:
> [Larry McVoy]

>> There was a lot of discussion about possible tools
>> that would dig out the /proc/pci info
>
> I think the tools should not dig too much information out of the system.
> I remember some Microsoft (win98 beta?) bugtracking software that
> insisted on sending a several hundert kB long compressed blob with every
> bug report.
> IMHO it must be possible to file bugreports without the complete hw info
> if I know that the bug isn't hw related.

Yep. The two hardware-related items that usually matter:

Little-endian or broken-endian?
32-bit or 64-bit?

The CPU type is not necessary or sufficient, since one can often
run a 32-bit kernel on 64-bit hardware and at least MIPS has both
little-endian and broken-endian supported.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 mmap() works?

[Tim Hockin]

> Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
> when pages have to be freed (I think also when the bdflush writes back
> data, i.e. every 30 seconds by default).

what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: unistd.h and 'extern's and 'syscall' "standard(?)"

[LA Walsh]

Andreas Schwab wrote:
> Don't use kernel headers in user programs.  Just use syscall(3).
> 
> Andreas.
---
I'm on a SuSE71 system and have all the manpages installed:
law> man syscall
No manual entry for syscall

The problem is not so much for user programs as library
writers that write support libraries for kernel calls.  For 
example there is libcap to implement posix capabilities on top
of the kernel call.  We have a libaudit to implement posix-auditing
on top a a few kernel calls.  It's the "system" library to system-call
interface that's the problem, mainly.  On ia64, it doesn't seem
like there is a reliable, cross-distro, cross architecture way of
interfacing to the kernel.

In saying "use syscall(3)" (which is undocumented on
my SuSE system, and on a RH61 sytem), implies it is in some
library.  I've heard rumors that the call isn't present in RH
distros and they claim its because it's not exported from glibc.
Then I heard glibc said it wasn't their intention to export it.
(This is all 2nd hand, so forgive me if I have parties or details
confused or mis-stated). It seems like kernel source points to an 
external source, Vender points at glibc, glibc says not their intention.
Meanwhile, an important bit of kernel functionality --
being able to use syscall0, syscall1, syscall2...etc, ends up
missing for those wanting to construct libraries on top of the
kernel.

I end up being rather perplexed about the correct course
of action to take.  Seeing as you work for suse, would you know
where this 'syscall(3)' interface should be documented?  Is it
supposed to be present in all distro's?  


Thanks,
-linda
-- 
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Temporary disk space leak

[Jag]

On Sat, 31 Mar 2001, Giuliano Pochini wrote:

> 
> [root@Jay Giu]# du -c /home
> [...]
> 320120/home
> 320120total
> [root@Jay Giu]# df
> Filesystem   1k-blocks  Used Available Use% Mounted on
> /dev/sda8   253823 65909174807  27% /
> /dev/sda7  2158320750672   1296240  37% /usr
> /dev/sda5  2193082   1898198183474  91% /home
> /dev/sda9  1013887899924 61586  94% /opt
> 
> 
> It happened after I wrote and deleted very large files (~750MB) a
> few times in my home dir.
> Then I logged out and I relogged in as root to check what happened
> and "df" shown everything was right again:
> 
> /dev/sda5  2193082320122   1761550  15% /home
> 
> 
> ...strange...

Was the 750M file opened by a program when it was deleted?  When a file
is deleted, if it is opened, it will still be there and taking up file
space (as shown in df) until it is completely closed.  However, even if
the file is opened by a process and not really deleted, the file's space
will no longer show up in du because the file can no longer be accessed
through the filesystem.

It sounds like this is what happened, and whatever program had the file
open was closed when you logged out.


Jag

 PGP signature

Re: how mmap() works?

[Andreas Bombe]

On Thu, Mar 29, 2001 at 02:14:51PM -0800, Jerry Hong wrote:
> Hi, 
>   mmap() creates a mmaped memory associated with a
> physical file. If a process updates the mmaped memory,
> Linux will updates the file "automatically". If this
> is the case, why do we need msync()?

For the same reason you might need fsync() or fdatasync().  To force
changes to be written now, without having to munmap() the area, so that
you have a gurantee that current data is on disk and will not be lost.

> If this is not
> the case, what is the interval between 2 "WRITE" (IO
> request operation) request to the physical file
> because it really updates the physical file somehow
> even without msync().

Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
when pages have to be freed (I think also when the bdflush writes back
data, i.e. every 30 seconds by default).

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bug database braindump from the kernel summit

[Albert D. Cahalan]

> Problem details
> Bug report quality
>   There was lots of discussion on this.  The main agreement was that we
>   wanted the bug reporting system to dig out as much info as possible
>   and prefill that.  There was a lot of discussion about possible tools
>   that would dig out the /proc/pci info; there was discussion about
>   Andre's tools which can tell you if you can write your disk; someone
>   else had something similar.
> 
>   But the main thing was to extract all the info we could
>   automatically.  One thing was the machine config (hardware and
>   at least kernel version).  The other thing was extract any oops
>   messages and get a stack traceback.

I'm really sick of being buried in useless information. The signal
gets lost in the noise. It is easy to discard automatically generated
bug reports, and way too annoying to wade through the crud.

When network connections hang, the console-tools package version
isn't likely to be of any use. When ramfs leaks memory, nobody needs
the content of /proc/pci.

Sometimes the bit of crud are HUGE. Imagine the hardware info
for a 64-way SGI or Sun box with plenty of devices attached.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Temporary disk space leak

[Giuliano Pochini]

[root@Jay Giu]# du -c /home
[...]
320120  /home
320120  total
[root@Jay Giu]# df
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/sda8   253823 65909174807  27% /
/dev/sda7  2158320750672   1296240  37% /usr
/dev/sda5  2193082   1898198183474  91% /home
/dev/sda9  1013887899924 61586  94% /opt


It happened after I wrote and deleted very large files (~750MB) a
few times in my home dir.
Then I logged out and I relogged in as root to check what happened
and "df" shown everything was right again:

/dev/sda5  2193082320122   1761550  15% /home


...strange...


Linux Jay 2.4.2 #6 gio mar 22 00:02:30 CET 2001 ppc unknown


Bye.

P.S. Yes, I was the only one using the computer.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bug database braindump from the kernel summit

[Manfred Spraul]

> There was a lot of discussion about possible tools
> that would dig out the /proc/pci info

I think the tools should not dig too much information out of the system.
I remember some Microsoft (win98 beta?) bugtracking software that
insisted on sending a several hundert kB long compressed blob with every
bug report.
IMHO it must be possible to file bugreports without the complete hw info
if I know that the bug isn't hw related.

--
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: scsi bus numbering

[Peter Daum]

On Sun, 1 Apr 2001, Douglas Gilbert wrote:

[...]

> >  scsihosts  <
>
> As a boot time option try:
>   scsihosts=aic7xxx:ncr53c8xxx
> or if you are using lilo, in /etc/lilo.conf add:
>   append="scsihosts=aic7xxx:ncr53c8xxx"

that does indeed change the bus numbering. Unfortunately, even
with this option, the first disk on the ncr controller becomes
"/dev/sda" ...

regards,
   Peter Daum

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: unistd.h and 'extern's and 'syscall' "standard(?)"

[Andreas Schwab]

LA Walsh <[EMAIL PROTECTED]> writes:

|> I have a question.  Some architectures have "system calls"
|> implemented as library calls (calls that are "system calls" on ia32)
|> For example, the expectation on 'arm', seems to be that sys_sync
|> is in a library.  On alpha, sys_open appears to be in a library.
|> Is this correct?
|> 
|> Is it the expectation that the library that handles this
|> is the 'glibc' for that platform or is there a special "kernel.lib"
|> that goes with each platform?
|> 
|>  Is there 1 library that I need to link my apps with to
|> get the 'externs' referenced in "unistd.h"?
|> 
|>  The reason I ask is that in ia64 the 'syscall' call
|> isn't done with inline assembler but is itself an 'extern' call.
|> This implies that you can't do system calls directly w/o some 
|> support library.

Don't use kernel headers in user programs.  Just use syscall(3).

Andreas.

-- 
Andreas Schwab  "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM:Bug when installing NVidia Driver Module

[Greg von Beck]

[1.] Bug when installing NVidia Driver Module on "athlon" architecture
[2.] the following error comes up when i attempt to install NVdriver
module from NVidia.

I build the Nvidia driver from the NVIDIA_kernel-0.9-769.tar.gz found at
www.nvidia.com

command insmod /lib/modules/2.4.3/video/NVDriver

reports this error
/lib/modules/2.4.3/video/NVDriver: unresolved symbol _mmx_memcpy

however if i rebuild my kernel using an "i686" architecture this problem
no longer comes up.

It is quite possible that this is NVidia's problem, however it seemed
reasonable that the "athlon" architecture should support MMX.

[3.] modules, video, nvidia
[4.] Linux version 2.4.3 ([EMAIL PROTECTED]) (gcc version 2.96
2731 (Red Hat Linux 7.0)) #4 Sun Apr 1 11:20:57 MST 2001
[5.] /lib/modules/2.4.3/video/NVDriver: unresolved symbol _mmx_memcpy
[6.] NA
[7.]
[7.1.]If some fields are empty or look unusual you may have an old
version.
Compare to the current minimal requirements in Documentation/Changes.

Linux greg.theblackfire.net 2.4.3 #4 Sun Apr 1 11:20:57 MST 2001 i686
unknown

Gnu C  2.96
Gnu make   3.79.1
binutils   2.10.0.18
util-linux 2.10m
modutils   2.3.14
e2fsprogs  1.18
pcmcia-cs  3.1.19
PPP2.3.11
isdn4k-utils   3.1pre1
Linux C Library2.1.92
Dynamic linker (ldd)   2.1.92
Procps 2.0.7
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded NVdriver nls_cp437 emu10k1

[7.2.]processor : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 900.068
cache size  : 256 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: 1795.68

[7.3.] NVdriver  630008   0 (unused)
nls_cp437   4408   1 (autoclean)
emu10k145400   0

[7.4.] -001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0778-077a : parport0
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
d000-d00f : VIA Technologies, Inc. Bus Master IDE
d400-d41f : VIA Technologies, Inc. UHCI USB
  d400-d41f : usb-uhci
d800-d81f : VIA Technologies, Inc. UHCI USB (#2)
  d800-d81f : usb-uhci
dc00-dc7f : Digital Equipment Corporation DECchip 21140 [FasterNet]
  dc00-dc7f : eth0
e000-e01f : Creative Labs SB Live! EMU1
  e000-e01f : EMU10K1
e400-e407 : Creative Labs SB Live!


-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07fe : System RAM
  0010-0022162b : Kernel code
  0022162c-002918b7 : Kernel data
07ff-07ff2fff : ACPI Non-volatile Storage
07ff3000-07ff : ACPI Tables
d000-d7ff : PCI Bus #01
  d000-d7ff : nVidia Corporation NV11
d800-dbff : VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
dc00-ddff : PCI Bus #01
  dc00-dcff : nVidia Corporation NV11
df00-df7f : Digital Equipment Corporation DECchip 21140
[FasterNet]
  df00-df7f : eth0
- : reserved

[7.5.] 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305
(rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 
Capabilities: [c0] 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:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (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-

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- TAbort-
SERR-  [disabled] [size=256K]

Re: New directions for kernel development

[Adam]

> > Uhm, yeah... I don't know who wrote this, but it came from Washington
> > state and was written with MS Outlook... Something tells me that this
> > April Fool's joke wasn't Linus'. :-)
>
> Yeah, the quality of these jokes has really gone down hill.  Last year we
> had forged headers and composed with Pine.  This year we have someone with
> a dialup account using Outlook, with all it's ^Os and long lines of text.

BZZT, wrong. Headers were forged intentionally to show pine since it is
what Linus uses.

I had a joke for this year as well, but I didn't hear back from Linus if
that's cool with him to send it to LKML (I suppose I should have asked him
earlier than 24hrs) so I did not send it.

For those interested, a rought draft is at

http://www.eax.com/linux2001/linux2001.txt


-- 
Adam
http://www.eax.com  The Supreme Headquarters of the 32 bit registers


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[Kai Henningsen]

[EMAIL PROTECTED] (john slee)  wrote on 01.04.01 in 
<[EMAIL PROTECTED]>:

> On Sun, Apr 01, 2001 at 01:22:48AM -0800, Richard Gooch wrote:
> > Linus Torvalds writes:
> >
> > Ho, hum. No, he didn't. It's April Wankers^WFools again.
>
> we aussies are supposed to have a good sense of humour :P

Yeah, but this one was fairly lame.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PCMCIA problems on IBM ThinkPad 600X

[Constantine Gavrilov]

Jeff Garzik wrote:

> On Sun, 1 Apr 2001, Constantine Gavrilov wrote:
> 
>> There are problems with some PCMCIA drivers included in the kernel. For 
>> example, support for cardbus 3com cards was moved to 3c59x.o driver. It 
>> works (on 600X at least) only of you compile it in. It will not work as 
>> a module.
> 
> 
> It works just fine as a module.  What problems are you seeing?
> 
Exactly as reported by Anton.  "cs: socket X timed out during reset" 
messages on the console when loading the module. This is at least on IBM 
Thinkpad 600X. 16-bit cards work fine.

> 
>> I think a much better solution right now is to use drivers from 
>> pcmcia-cs package. It always works. If you do not configure any support 
>> for pcmcia in your kernel, when you build pcmcia-cs it will build kernel 
>> drivers from its own source tree. Just make sure you use the latest 
>> version. This also allows configuration files interoperbility with 2.2.x 
>> kernel, if you wish to use that as well.
> 
> 
> pcmcia-cs does not always work, and it puts your nice 32-bit hardware
> into 16-bit compatibility mode AFAIK.
> 
> If you have 2.4 bugs, please report them instead of spewing B.S.
> 
>   Jeff
> 
> 
Several points:
* this bug and the workaround have been reported several times on 
several mailing lists, probably on linux-kernel as well. Explanations 
also stated that it has been broken and reported since 2.4.0-preX (I do 
not remember which pre-release). So it is not a hidden knowledge and I 
do not have to report a known bug.

* I do not think pcmcia-cs puts cardbus cards into 16-bit compatibility 
mode. According to David Hinds, pcmcia code has been integrated into 
2.4, so 2.4 uses a similar code base. My tests of bonding code showed 2 
Mbit/sec with PCMCIA (100% CPU utilization) and 12 Mbit/sec with CardBus 
(<5% CPU utilization).

* The letter has not been addressed to you, but to the list. Why are you 
taking this personal? What I said is no BS. The bug has been known and 
reported. I personally use multiple versions of 2.2.x and 2.4.x kernels 
installed on my machine for research and development. These include 
various experimental patches and pre-releases. For people in my 
situation, it is more convenient to use drivers from pcmcia-cs mainly 
for two reasons: 1) I can use the same PCMCIA configuration for all 
kernels; 2) I do not have to recompile kernel to upgrade PCMCIA drivers. 
Why should it bother you?

David's stuff happens to work better right now. So what? There are 
several quite logical reasons for it:
* PCMCIA code has been integrated relatively recently and not all 
integration problems have been solved yet. "Official" and "unofficial" 
Linux documentation state this and recommend pcmcia-cs in the case of 
problems.
* Since 2.4 has come out, a lot of efforts are made to fix bugs. Some 
changes in the code incidentally break "other" stuff. Since David has to 
concentrate on PCMCIA only, he can respond quickly to fix integration 
problems. He is not bound to kernel release schedules and can release 
more frequently. In the current situation, it helps.
* When you (or somebody else) update network drivers, you cannot 
possibly make sure that changes work across all card models. For David, 
on the other hand, it is by far much easier to insure compatibility, 
since he has to deal with CardBus and PCMCIA only. He also has had a lot 
of experince doing this and his releases have always being of high quality.

So, you do not have to get angry. I did not reflect on the quality of 
your code and  the thought has not even occurred to me. After all, if 
you update epro100 code, for instance, these changes appear in pcmcia-cs 
package rather quickly. Part of David's job has been to make sure that 
network drivers written in whole or in large part by other people work 
WELL with PCMCIA and CardBus cards. He has been doing an excellent job 
-- why should it bother you?

-- 

Constantine Gavrilov
Linux Leader
Optibase Ltd
7 Shenkar St, Herzliya 46120, Israel
Phone: (972-9)-970-9140
Fax:   (972-9)-958-6099


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentatio

[Kai Henningsen]

[EMAIL PROTECTED] (Chip Salzenberg)  wrote on 01.04.01 in :

> Why not have a kernel thread and use standard RPC techniques like
> sockets?  Then you'd not have to invent anything unimportant like
> Yet Another IPC Technique.

You can, of course, transfer the exact same RPC messages over a file  
descriptor on your metadata fs. It doesn't *have* to be ASCII, especially  
not for purely internal-use interfaces.

And for ioctl() fans, you could transfer the exact same data via read()/ 
write() again. That's not significantly harder. Especially if you write a  
wrapper around the calls. If you want to be perverse, you can probably  
even transmit user space pointers.

But I suspect there are really only two generally useful interfaces:

1. A text based interface for generally-useful stuff you might want to  
manipulate from the shell, or random user programs. (From the shell _is_  
random user programs.)

2. A RPC based interface for tightly-coupled fs utilities. (I don't know  
off the top of my head what the kernel already has - ISTR networking has  
_something_.)

Don't forget a version marker of some kind. Sooner or later, you'll be  
glad you have it.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[Ben Ford]

Chris Meadors wrote:

> On Sun, 1 Apr 2001, David Riley wrote:
> 
>> Linus Torvalds wrote:
>> 
>>  Uhm, yeah... I don't know who wrote this, but it came from Washington
>> state and was written with MS Outlook... Something tells me that this
>> April Fool's joke wasn't Linus'. :-)
> 
> 
> Yeah, the quality of these jokes has really gone down hill.  Last year we
> had forged headers and composed with Pine.  This year we have someone with
> a dialup account using Outlook, with all it's ^Os and long lines of text.
> Bah.

Perhaps that was intended as part of the joke . . . .

-b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.3, new AIC7XX fails to compile, old works.

[Steven Lembark]

the ../config*works gets a successful build (yet to test kernel).  using
the new AIC driver blows up w/ undefined reference.  full config file
incl.
as an attachment.

pgcc-2.95.2
/lib/libc-2.1.3.so

1097 : dizzy : linux # diff .config ../config-2.4.3-works
228,230c228,231
< CONFIG_SCSI_AIC7XXX=y
< CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
< CONFIG_AIC7XXX_RESET_DELAY=5000
---
> CONFIG_SCSI_AIC7XXX_OLD=y
> # CONFIG_AIC7XXX_OLD_TCQ_ON_BY_DEFAULT is not set
> CONFIG_AIC7XXX_OLD_CMDS_PER_DEVICE=8
> # CONFIG_AIC7XXX_OLD_PROC_STATS is not set

make -w clean depend bzImage;

ends with:

make[5]: Entering directory
`/usr/src/linux-2.4.3/drivers/scsi/aic7xxx/aicasm'
gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm
/var/tmp/cc8rPyGS.o: In function `symtable_open':
/var/tmp/cc8rPyGS.o(.text+0x1d7): undefined reference to `dbopen'
collect2: ld returned 1 exit status
make[5]: *** [aicasm] Error 1
make[5]: Leaving directory
`/usr/src/linux-2.4.3/drivers/scsi/aic7xxx/aicasm'
make[4]: *** [aicasm/aicasm] Error 2
make[4]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx'
make[2]: *** [_subdir_aic7xxx] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi'
make[1]: *** [_subdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.3/drivers'
make: *** [_dir_drivers] Error 2


-- 
 Steven Lembark   2930 W. Palmer St.
 Chicago, IL  60647
 [EMAIL PROTECTED]   800-762-1582

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
# CONFIG_PM is not set
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=16386

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# 

bug database braindump from the kernel summit

[Larry McVoy]

Folks, since bug tracking is the next thing we are attacking here at
BitMover, I have a great deal of interest in the bug tracking discussion
which happened last night at the summit.  We already have a prototyped bug
tracking system which we are integrating into BitKeeper, but as usual,
it isn't good enough for the kernel team who have an interesting set
of requirements.

We want to make sure that the BK bug tracking system _could_ be used for
the kernel effort.  Whether it is or not will be decided after years of
licensing flamewars, etc., etc.  We're not going to go there so please
don't try.

Where I want to go is a discussion of requirements, then we converge on
a strawman proposal, and then all of the people who care enough about
this can go implement an answer and Linus and/or Alan and/or whoever can
choose one.

Let's stay focussed on arriving at a good set of agreed on requirements.

I've done a brain dump below.  I'll track this mail thread and update this
doc as the discussion unfolds.  I'll post updates as it is needed.  If this
discussion takes on a life of its own, I may try and grab all the mail and
archive it so that people can browse; we'll see, it may be that everyone
is so busy that this will be the first and last message on the topic.

--lm

Brain dump on the bug tracking problem from the Kernel Summit discussions

[SCCS/s.BUGS vers 1.2 2001/04/01 10:46:55]

Outline
Problems
Problem details
Past experiences
Requirements

Problems
- getting quality bug reports
- not losing any bugs
- sorting low signal vs high signal into a smaller high signal pile
- simplified, preferably NNTP, access to the bug database (Linus
  would use this; he's unlikely to use anything else)

Problem details
Bug report quality
There was lots of discussion on this.  The main agreement was that we
wanted the bug reporting system to dig out as much info as possible
and prefill that.  There was a lot of discussion about possible tools
that would dig out the /proc/pci info; there was discussion about
Andre's tools which can tell you if you can write your disk; someone
else had something similar.

But the main thing was to extract all the info we could
automatically.  One thing was the machine config (hardware and
at least kernel version).  The other thing was extract any oops
messages and get a stack traceback.

The other main thing was to define some sort of structure to the
bug report and try and get the use to categorize if they could.
In an ideal world, we would use the maintainers file and the
stack traceback to cc the bug to the maintainer.  I think we want
to explore this a bit.  I'm not sure that the maintainer file is
the way to go, what if we divided it up into much broader chunks
like "fs", "vm", "network drivers", and had a mail forwarder
for each area.  That could fan out to the maintainers.

Not losing bugs
While there was much discussion about how to get rid of bad,
incorrect, and/or duplicate bug reports, several people - Alan
in particular - made the point that having a complete collection
of all bug reports was important.  You can do data mining across
all/part of them and look for patterns.  The point was that there
is some useful signal amongst all the noise so we do not want to
lose that signal.

Signal/noise
We had a lot of discussion about how to deal with signal/noise.
The bugzilla proponents thought we could do this with some additional
hacking to bugzilla.  I, given the BitKeeper background, thought 
that we could do this by having two databases, one with all the 
crud in it and another with just the screened bugs in it.  No matter
how it is done, there needs to be some way to both keep a full list,
which will likely be used only for data mining, and another, much
smaller list of screened bugs.  Jens wants there to be a queue of 
new bugs and a mechanism where people can come in the morning, pull
a pile of bugs off of the queue, sort them, sending some to the real
database.  This idea has a lot of merit, it needs some pondering as
DaveM would say, to get to the point that we have a workable mechanism
which works in a distributed fashion.

The other key point seemed to be that if nobody picked up a bug and
nobody said that this bug should be picked up, then the bug expires
out of the pending queue.  It gets stashed in the bug archive for
mining purposes and it can be resurrected if it later becomes a real
bug, but the key point seems to be that it _automatically_ disappears
out of the pending queue.  I personally am very supportive of this
model.  We need 

Serial, 115Kbps, 2.2, 2.4

[Trever L. Adams]

I am trying to find out if I am the only one who has pppd drop packets 
as bogus when the port is set at 115Kbps.  I only get it at that speed. 
  It causes stall outs etc.

There may be a possibility this is machine specific, because if it is 
meant to forward the packet to the internal net and I slow the machine 
down (external cache off) it works fine, turn the cache back on and it 
is a problem.

So, anyway, this is an information seeking trip.

Trever

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[Chris Meadors]

On Sun, 1 Apr 2001, David Riley wrote:

> Linus Torvalds wrote:
>
>   Uhm, yeah... I don't know who wrote this, but it came from Washington
> state and was written with MS Outlook... Something tells me that this
> April Fool's joke wasn't Linus'. :-)

Yeah, the quality of these jokes has really gone down hill.  Last year we
had forged headers and composed with Pine.  This year we have someone with
a dialup account using Outlook, with all it's ^Os and long lines of text.
Bah.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..." --David Lynch, Twin Peaks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PCMCIA problems on IBM ThinkPad 600X

[Jeff Garzik]

On Sun, 1 Apr 2001, Constantine Gavrilov wrote:
> There are problems with some PCMCIA drivers included in the kernel. For 
> example, support for cardbus 3com cards was moved to 3c59x.o driver. It 
> works (on 600X at least) only of you compile it in. It will not work as 
> a module.

It works just fine as a module.  What problems are you seeing?


> I think a much better solution right now is to use drivers from 
> pcmcia-cs package. It always works. If you do not configure any support 
> for pcmcia in your kernel, when you build pcmcia-cs it will build kernel 
> drivers from its own source tree. Just make sure you use the latest 
> version. This also allows configuration files interoperbility with 2.2.x 
> kernel, if you wish to use that as well.

pcmcia-cs does not always work, and it puts your nice 32-bit hardware
into 16-bit compatibility mode AFAIK.

If you have 2.4 bugs, please report them instead of spewing B.S.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Version 6.1.6 of the aic7xxx driver availalbe

[Justin T. Gibbs]

>> >> >A typical revery in my logs.
>>
>> This really looks like you bus is not up to snuff.  We timeout during
>> a write to the drive.  Although the chip has data to write, the target
>> has stopped asking for data.  This is a classic symptom of a lost signal
>> transition on the bus.  The old driver may have worked in the past
>> because it was not quite as fast at driving the bus.  2.2.19 uses the
>> "old" aic7xxx driver but includes some performance improvements over 2.2.18.
>> The new driver has similar improvements.  Check your cables.  Check
>> your terminators.  Etc.
>>
>
>I dont think so. The system is very simple. On the 50 pin Fast scsi there is
>the CD.  And on the Ultra2 device the IBM harddrive.  On the cable there is
>a terminator.  (This is the cable from ASUS delivered with the motherboard.
>Is a balanced pair cable.) On the harddrive there is a strap for termination
>and in the BIOS there is a swich for ternination. The strip is off. (I have
>tryed on also) And the BIOS control led termination is ON. I have tryed all
>permutations! But I have found a workaround.  The wide scsi was not in use
>and have the same connector so  I moved the harddriv to that bus and now
>everything works with 2.4.3. Or at least for a half an hour...  But the drive
>is a LVD and should be on the Ultra2 connector.

I've seen so many bug reports lately, that I can't recall your exact
configuration.  You make it sound as if you have an aic7890 with a
50 pin bus and a 68 pin bus.  If this is the case, it does not sound
like your termination is properly setup for having devices on "either
side" of the controller.  The controller termination should probably
be off.

--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pthreads & fork & execve

[Dennis Noordsij]

Hi,

I have question regarding use of pthreads, forks and execve's which appears 
to not work very well :-) First let me explain the reasoning though

We have an app that launches a few other apps and keeps track of their 
status, resource consumption etc. If one of the apps crashes, it is restarted 
according to certain parameters.

The app uses pthreads, and it's method of (re)starting an application is 
forking and calling execve. 

It works fine for all-but-one other app, which core dumps when started this 
way (from the commandline it works fine) and the core only traces back to  
int main(int argc, char **argv). It uses both pthreads and -ldl for plugin 
handling. 

We have tried changing the linking order (i.e. -ldl -lpthread, -lpthread, 
-ldl, etc), and even execv'ing a shell script that starts a shell script that 
starts the app - result is the same, instant core without even running.

I can see who forks together with threads and execve's are a messy 
combination, and a better solution altogether to our approach is appreciated 
just as much as a way to make the current solution work :-)

We have tested both kernels 2.4.2 and 2.2.18. 

We have tried on different systems, different hardware and slightly different 
distributions (debian potato, unstable, etc).

To sum up: using a pthreaded app to launch another pthreaded app by means of 
forking and exec(ve)'ng makes the second app core immediately, (at entering 
main). What to do?

Kind regards, and thanks for any help
Dennis Noordsij
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

unistd.h and 'extern's and 'syscall' "standard(?)"

[LA Walsh]

I have a question.  Some architectures have "system calls"
implemented as library calls (calls that are "system calls" on ia32)
For example, the expectation on 'arm', seems to be that sys_sync
is in a library.  On alpha, sys_open appears to be in a library.
Is this correct?

Is it the expectation that the library that handles this
is the 'glibc' for that platform or is there a special "kernel.lib"
that goes with each platform?

Is there 1 library that I need to link my apps with to
get the 'externs' referenced in "unistd.h"?

The reason I ask is that in ia64 the 'syscall' call
isn't done with inline assembler but is itself an 'extern' call.
This implies that you can't do system calls directly w/o some 
support library.

The implication of this is that developers working on
platform independent system calls and library functions, for
example, extended attributes, audit or MAC, can't provide
platform independent patches w/o also providing their own
syscall implementation for ia64.

This came up as a problem when we wanted to provide a
a new piece of code but found it wouldn't link on some distributions.
In inquiry there seems to be some confusion regarding who is responsible
for providing this the code/library to satisfy this 'unistd.h' extern.

Should something so basic as the 'syscall' interface be provided
in the kernel sources, perhaps as a kernel-provided 'lib', or is
it expected it will be provided by someone else or is it expected
that each developer should provide their own syscall implementation for
ia64?

Thanks,
-linda
-- 
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 bus numbering

[Douglas Gilbert]

Peter Daum <[EMAIL PROTECTED]> wrote:
> For some reason, the order of initializing the scsi drivers
> changed between 2.4.2 and 2.4.3: If both, ncr53c8xx and aic7xxx
> drivers are included in the kernel, up to version 2.4.2, the
> adaptec driver always came first (so the first disk on an adaptec
> controller ended up as /dev/sda) while in 2.4.3, the ncr driver
> initializes first and all the device names change - with
> potentially disastrous effects for unsuspecting users.
> 
> AFAIK, the numbering of scsi busses depends only on the order the
> low-level drivers are loaded. Not that I can think of any better
> way to do this, but it would be good if things were a little bit
> more predictable - in absence of any better idea, maybe by
> loading the drivers in alphabetical order or something like that ...

Looking at the drivers/scsi/Makefile file in lk 2.4.3
you can see that aic7xxx_old.o is about half way down
the list with ncr53c8xx.o towards the end. So this
dictates the old behaviour (in the lk 2.4 series).
However the new aic7xxx driver isn't in that list,
it has its own entry:
subdir-$(CONFIG_SCSI_AIC7XXX)   += aic7xxx
which seems to invoke drivers/scsi/aic7xxx/Makefile
_after_ all other built in adapters drivers are built.
Maybe another "make" mechanism needs to be found to
restore the previous ordering information. In any case
building the aic7xxx driver last has already surprised
a lot of people.
 
> How is it possible, to influence that order at the moment (for
> example, to revert to the old order)? I personally couldn't
> figure out, where to change this.

>  scsihosts  <

As a boot time option try:
  scsihosts=aic7xxx:ncr53c8xxx
or if you are using lilo, in /etc/lilo.conf add:
  append="scsihosts=aic7xxx:ncr53c8xxx"

Actually just doing:
  scsihosts=aic7xxx
should do the trick for most people.

In the unlikely case that the SCSI mid level is a module,
then you can pass the scsihosts argument to the
module load (or add an option line to /etc/modules.conf):
  modprobe scsi_mod scsihosts=aic7xxx:ncr53c8xxx

You could also read the SCSI-2.4-HOWTO at:
http://www.linuxdoc.org/HOWTO/SCSI-2.4-HOWTO/

BTW You can thank Richard Gooch and devfs for scsihosts.
Lucky he spotted the requirement some time back.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[John Jasen]

On Sun, 1 Apr 2001, Linus Torvalds wrote:

> Hi all,
>
>   Recently, I've been thinking a lot about where Linux development should
> head now that 2.4 is out.  Specifically, I've been thinking about how we
> ought to make some cultural changes as well as technical changes.  Now I'm
> not *entirely* sure what directions we should head in as we move towards
> 3.0, but I'd like to point out a few areas that need to be addressed as well
> as propose some possible solutions.  Nothing is set in stone yet, but these
> are definitely issues we need to work on.

I see you've made no mention of the $17,000,000,000.00 check that you've
gotten from MicroSoft, in order to 'further develop' the Linux kernel?



--
-- John E. Jasen ([EMAIL PROTECTED])
-- In theory, theory and practise are the same. In practise, they aren't.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: tmpfs in 2.4.3 and AC

[Daniel Podlejski]

In linux-kernel, [EMAIL PROTECTED] wrote:
: Hi,
: 
: tmpfs (or shmfs or whatever name you like) is still different in official
: series (2.4.3) and in ac series. Its a kick in the ass for multiboot,
: as offcial 2.4.3 does not recognise 'tmpfs' in fstab:
: 
: shmfs  /dev/shmtmpfs   ...
: 
: Any reason, or is because it has been forgotten ?

There is no tmpfs in vanilla 2.4.3 kernel.

I use this start script to mount tmp/shmfs:

#!/bin/sh

[ -d /dev/shm ] || mkdir -p /dev/shm

shmfs_avail=$(grep -qci 'shmfs' /proc/filesystems || true)
tmpfs_avail=$(grep -qci 'tmpfs' /proc/filesystems || true)
devshm_mounted=$(grep -qci '/dev/shm' /proc/mounts || true)

[ $devshm_mounted = 0 ] || exit 0

if [ $shmfs_avail = 1 ]
then
echo -ne "Mounting shmfs: "
mount none /dev/shm -t shmfs && echo "ok."
exit 0
fi

if [ $tmpfs_avail = 1 ]
then
echo -ne "Mounting tmpfs: "
mount tmpfs /dev/shm -t tmpfs && echo "ok."
fi


-- 
Daniel Podlejski <[EMAIL PROTECTED]>
   ... On a dark desert highway Cool wind in my hair
   Warm smell of colitas Rising up through the air ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: configuring net interfaces

[Krzysztof Halasa]

Jeff Garzik <[EMAIL PROTECTED]> writes:

> I'm not suggesting you modify ethtool for your needs :)   But ethtool
> perfectly illustrates the technique of using a single socket ioctl
> (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls
> (ETHTOOL_xxx) to Linux networking drivers.

I know. The problem is I don't see here any advantages over many SIOCxxx
command codes, while there are disadvantages.
Simple things are IMHO better, and ioctl was designed to handle many
simple commands (instead of one complex).

Am I missing something?
-- 
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[David Riley]

Linus Torvalds wrote:

Uhm, yeah... I don't know who wrote this, but it came from Washington
state and was written with MS Outlook... Something tells me that this
April Fool's joke wasn't 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: New directions for kernel development

[Miles Lane]

Linus Torvalds wrote:

It's definitely time for you to show up on Saturday Night Live!
You are one funny guy.  :-)

Happy April Fools Day.

Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

scsi bus numbering

[Peter Daum]

For some reason, the order of initializing the scsi drivers
changed between 2.4.2 and 2.4.3: If both, ncr53c8xx and aic7xxx
drivers are included in the kernel, up to version 2.4.2, the
adaptec driver always came first (so the first disk on an adaptec
controller ended up as /dev/sda) while in 2.4.3, the ncr driver
initializes first and all the device names change - with
potentially disastrous effects for unsuspecting users.

AFAIK, the numbering of scsi busses depends only on the order the
low-level drivers are loaded. Not that I can think of any better
way to do this, but it would be good if things were a little bit
more predictable - in absence of any better idea, maybe by
loading the drivers in alphabetical order or something like that ...

How is it possible, to influence that order at the moment (for
example, to revert to the old order)? I personally couldn't
figure out, where to change this.

Regards,
  Peter Daum

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: aic7xxx 6.1.8 for 2.2.19

[David Relson]

At 10:54 AM 4/1/01, Mike Bennett wrote:
>Was getting ready to compile 2.2.19 this AM and went to
>Justin's site to grab the latest aic7xxx driver.
>
>Unfortunately, he doesn't have a patch for 2.2.19 and the
>2.2.18 patch doesn't apply cleanly because the stock driver
>changed.
>
>It's a long story, but the short version is that the stock
>driver has always given me timeouts with heavy disk activity.
>Right now I'm using 6.0.8beta in 2.2.18 since Jan 12 and have
>not had a single timeout problem. Needless to say, I won't be
>upgrading kernels today.  Damn, now I've got no excuse for
>not mowing the lawn... :)

No excuse needed here in Ann Arbor, Michigan.  This morning lawn mowing is 
a non-issue.  It's snowing merrily - just like it was winter.


>Has anyone made a patch against 2.2.19 ?
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   Ann Arbor, MI 48103
www.osagesoftware.com  tel:  734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: add-single-device won't work in 2.4.3

[Armin Obersteiner]

hi!

problem resolved: the first scsi adaptor is scsi1 NOT scsi0
as in <=2.4.2. so i did add/remove devices from a non existend
controller ...

thanks for posting your /proc/scsi/scsi, i compared it with
mine from 2.4.2 and voila!

i hope this is a "wanted" behavior ...

thanks for all your fast replies!

> $ uname -a
> Linux frig 2.4.3 #1 Fri Mar 30 16:33:45 EST 2001 i586 unknown
> 
> $ cat /proc/scsi/scsi
> Attached devices: 
> Host: scsi1 Channel: 00 Id: 01 Lun: 00
>   Vendor: IBM  Model: DNES-309170W Rev: SA30
>   Type:   Direct-AccessANSI SCSI revision: 03
> Host: scsi2 Channel: 00 Id: 05 Lun: 00
>   Vendor: UMAX Model: Astra 1220S  Rev: V1.2
>   Type:   Scanner  ANSI SCSI revision: 02

CU,
Armin Obersteiner
--
[EMAIL PROTECTED]pgp public key on requestCU
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[James Simmons]

>No, it's the Trident Cyber9525

Sorry. I only have a early driver for trident 9750 and 9850. Their is a
gropup working on trident framebuffers.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkml]Re: Matrox G400 Dualhead

[James Simmons]

>If I use X on an accelerated, normal Matrox screen, my monitor complains
>on exit:
>
>fH 49.4 KHz, fV 39.8 Hz
>
>(and it doesn't sync at 40 Hz vertical refresh :-( ).
>
>This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80" before
>X, of after X, doesn't do anything. Does anybody know what to hack out
>in X to get it to _not_ reset my G400 to some unusable state? 3.3.6 was
>didn't do this. I can use the framebuffer-screen just fine, but I miss
>the DGA extension.

Try adding this to your XF86Config file:

Section "Device"
...
Option UseFBDev
...
EndSection


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

VIA 82c686b and IOMega ATAPI ZIP 100 problem

[Stepan Roh]

I'm experiencing serious problems with Linux, VIA vt82c686b IDE interface
(as included on VIA KT133 (latest revisions), KT133A and newer chipsets)
and IOMega ATAPI ZIP 100 drive. Error description and system information
are included below. That is a known problem with this chip. Something bad
happens with ATAPI there (but only for IOMega ATAPI ZIP 100 and some old
CD-ROMs - I have both). Under Windows (which I don't have) you can install
beta version of VIA IDE Busmaster drivers to solve this problem. I wrote
to MSI (manufacturer of motherboard) and to VIA. Guys from VIA did not
replied to me and from MSI they sent me Windows drivers with suggestion to
try it under Linux. Is there any real solution for this problem under
Linux?

I'm not subscribed to this list, so please CC to me.

Thanks,

Stepan Roh
[EMAIL PROTECTED]

Error description:

When writing data to IOMega ATAPI ZIP 100 drive, whole IDE interface is
frozen including all programs accessing it. Unmount is impossible (even
when I try to force unmount with SysRq). Following messages are written to
syslog (these messages slightly differ from kernel version to kernel
version (I tried 2.2.18, 2.4.2, 2.4.3) - following is from 2.4.3 when
overwriting large file):

Mar 31 20:26:24 penguin kernel: Filesystem panic (dev 16:44).
Mar 31 20:26:24 penguin kernel:   fat_free: deleting beyond EOF
Mar 31 20:26:24 penguin kernel:   File system has been set read-only
Mar 31 20:27:47 penguin kernel: hdd: lost interrupt
Mar 31 20:27:47 penguin kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr
Mar 31 20:27:47 penguin kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr
Mar 31 20:27:47 penguin kernel: hdd: ATAPI reset complete

Last 4 lines are repeated as long as file is not written (this depends on
file size). On 2.2.18 kernel additional set of messages similar to the one
below is written:

Mar  4 19:50:55 penguin kernel: file_cluster badly computed!!! 0 <> 3315

Writing speed is aprox. 1000 times slower than it was on my old computer.

System information:

dmesg:

Linux version 2.4.3 (root@penguin) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #3 Sat Mar 31 20:12:33 CEST 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820:  - 0001 (reserved)
 BIOS-e820: 0010 - 0fff (usable)
 BIOS-e820: 0fff3000 - 1000 (ACPI data)
 BIOS-e820: 0fff - 0fff3000 (ACPI NVS)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux-2.4.3 ro root=301
Initializing CPU#0
Detected 849.609 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 1690.82 BogoMIPS
Memory: 255572k/262080k available (984k kernel code, 6120k reserved, 359k data, 180k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff  
CPU: After generic, caps: 0183f9ff c1c7f9ff  
CPU: Common caps: 0183f9ff c1c7f9ff  
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb260, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Bus master Pipeline request disabled
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169826kB/56608kB, 512 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K 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
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DTLA-307030, ATA DISK drive
hdc: BCD-8X 1996-09-04, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 

aic7xxx 6.1.8 for 2.2.19

[Mike Bennett]

Was getting ready to compile 2.2.19 this AM and went to
Justin's site to grab the latest aic7xxx driver.

Unfortunately, he doesn't have a patch for 2.2.19 and the
2.2.18 patch doesn't apply cleanly because the stock driver
changed.

It's a long story, but the short version is that the stock
driver has always given me timeouts with heavy disk activity.
Right now I'm using 6.0.8beta in 2.2.18 since Jan 12 and have
not had a single timeout problem. Needless to say, I won't be
upgrading kernels today.  Damn, now I've got no excuse for
not mowing the lawn... :)

Has anyone made a patch against 2.2.19 ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sysctl

[Subba Rao]

Hi,

I am working on rebuilding a modified kernel. This is for version 2.2.18 and
on Slackware distro.

I have been looking for the command "sysctl" in my */sbin directories and I
can't seem to find it. Is this something that is an independent program that is
compiled during the kernel build? I do see a few SYSCTL options in the the
xconfig session. Is this command distro specific?

Thanks for any info or pointers.

-- 

Subba Rao
[EMAIL PROTECTED]
http://members.home.net/subba9/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PCMCIA problems on IBM ThinkPad 600X

[Constantine Gavrilov]

There are problems with some PCMCIA drivers included in the kernel. For 
example, support for cardbus 3com cards was moved to 3c59x.o driver. It 
works (on 600X at least) only of you compile it in. It will not work as 
a module.

I think a much better solution right now is to use drivers from 
pcmcia-cs package. It always works. If you do not configure any support 
for pcmcia in your kernel, when you build pcmcia-cs it will build kernel 
drivers from its own source tree. Just make sure you use the latest 
version. This also allows configuration files interoperbility with 2.2.x 
kernel, if you wish to use that as well.

You just need to make sure you are using "ordinary" configuration files 
if you use pcmcia-cs, since 2.4 uses different names for some of pcmcia 
drivers.  Stock pcmcia-cs package will do nicely.

-- 

Constantine Gavrilov
Linux Leader
Optibase Ltd
7 Shenkar St, Herzliya 46120, Israel
Phone: (972-9)-970-9140
Fax:   (972-9)-958-6099


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Original destination of transparent proxied connections?

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:

[ cut 50 lines ]

> If I were to perhaps send linuxdoc.org a check or
> something, might a day come to pass when learning to
> do seemingly obvious things under linux does NOT
> require fairly good forensic investigation skills?  I
> ask merely for information.

And you wonder why my EMail address is not on the HOWTO?  Perhaps
because there's a netfilter-devel list which can respond far more
quickly than I can...

Summary: you had to use a *search engine* to find an obscure piece of
coding information.

Shocked!
Rusty.
--
Premature optmztion is rt of all evl. --DK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.3 SMP aic7895 oops on boot

[Vivek Dasmohapatra]

Hi: I just tried upgrading to the 2.4.3 kernel [ currently running
2.2.18/Debian/woody ] and I got [or rather I should say get - it happens
every time] a kernel panic on boot, just after the lines: 

[ Apologies if two message like this turn up - I sent the last one some
  time ago, and it hasn't surfaced on the list yet. ]

[drm] AGP 0.99 on Intel 440 LX @ 0xe 256MB
[drm] Initialised mga 2.0.1 2928 on minor 63
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
ahc_pci:0:15:1 Using left over BIOS settings

Here is the output of lspci [the scsi related bits]:

00:0f.0 SCSI storage controller: Adaptec AHA-2940U/UW / AHA-39xx / AIC-7895 (rev 03)
00:0f.1 SCSI storage controller: Adaptec AHA-2940U/UW / AHA-39xx / AIC-7895 (rev 03)

The kernel was compiled with gcc 2.95.3 and gas 2.9.5, and unless I took
my brain out of gear at the time [not unknown], all the dependencies in
Documentation/Changes were met.

I have attached the various files that the FAQ indicated might be useful,
although not the sytem map, as this was large [~400k] and I was not sure 
this was an acceptable size for the list

[Note: The system froze pretty early on - no hard disk or anything, so
this ksymoops is based on hand copied oops output: I'm pretty sure it's
accurate, but if any of this is impossible or inconsistent with itself, I 
can just try to boot the new kernel again, it's oopsed every time so far]

Here is the output of ksymoops: 

ksymoops 2.3.7 on i686 2.2.18-01.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.3 (specified)
 -m /usr/src/linux/System.map (specified)

No modules in ksyms, skipping objects
Unable to handle kernel NULL pointer dereference at virtual address 
c0a15cf3
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 0001   ebx: c12a8c00   ecx:    edx: 
esi:    edi:    ebp: 000b   esp: c0281f48
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c0281000)
Stack: c122b9c0 2401  0086 c01086b1 000b c12a8c00 c0281fa8
   c02d7820 c02bb960 000b c0281fa0 c0108896 000b c0281fa8 c122b9c0
   c0105170 c028 c0105170   c122b9c0 0008e000 c010700c
Call Trace: []  []  []  []  []  
[]  []  []  []  []  []  
[] 
Code: 80 3c 11 ff 0f 44 c6 ba 02 00 00 00 85 c0 0f 45 f2 85 f6 74

>>EIP; c0a15cf3<=
Trace; c01086b1 
Trace; c0108896 
Trace; c0105170 
Trace; c0105170 
Trace; 0c01700c Before first symbol
Trace; c0105170 
Trace; c0105170 
Trace; c0100018 
Trace; c010519c 
Trace; c0105202 
Trace; c0105000 
Trace; c01001cf 
Code;  c0a15cf3 
 <_EIP>:
Code;  c0a15cf3<=
   0:   80 3c 11 ff   cmpb   $0xff,(%ecx,%edx,1)   <=
Code;  c0a15cf7 
   4:   0f 44 c6  cmove  %esi,%eax
Code;  c0a15cfa 
   7:   ba 02 00 00 00mov$0x2,%edx
Code;  c0a15cff 
   c:   85 c0 test   %eax,%eax
Code;  c0a15d01 
   e:   0f 45 f2  cmovne %edx,%esi
Code;  c0a15d04 
  11:   85 f6 test   %esi,%esi
Code;  c0a15d06 
  13:   74 00 je 15 <_EIP+0x15> c0a15d08 


Kernel Panic: Aiee, killing interupt handler
Unable to handle kernel NULL pointer dereference at virtual address 
c0a15cf3
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010046
eax: 0001   ebx: c12a8a00   ecx:    edx: 
esi:    edi:    ebp: 000a   esp: c0281d7c
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c0281000)
Stack: c122b740 2401 0082 0086 c01086b1 000a c12a8a00 c0281ddc
   c02d7820 c02bb940 000a c0281dd4 c0108896 000a c0281ddc c122b740
    c028 000b   c122b740 c028 c010700c
Call Trace: [] [] [] [] [] 
[] [] [] [] [] [] 
[] [] [] [] [] [] 
[] [] [] [] [] [] 
[] [] [] [] [] [] 
[] [] [] []
Code: 80 3c 11 ff 0f 44 c6 ba 02 00 00 00 85 c0 0f 45 f2 85 f6 74

>>EIP; c0a15cf3<=
Trace; c01086b1 
Trace; c0108896 
Trace; c010700c 
Trace; c0210018 
Trace; c010fc6d 
Trace; c010fc9c 
Trace; c010fce4 
Trace; c010fc9c 
Trace; c0114494 
Trace; c0117452 
Trace; c01110f4 
Trace; c0107482 
Trace; c0111437 
Trace; c01110f4 
Trace; c0105986 <__up+16/18>
Trace; c0105bb4 <__up_wakeup+8/c>
Trace; c020da8c 
Trace; c018d7b5 
Trace; c019501e 
Trace; c010707c 
Trace; c01a5cf3 
Trace; c01086b1 
Trace; c0108896 
Trace; c0105170 
Trace; c0105170 
Trace; c010700c 
Trace; c0105170 
Trace; c0105170 
Trace; c0100018 
Trace; c010519c 
Trace; c0105202 
Trace; c0105000 
Trace; c01001cf 
Code;  c0a15cf3 
 <_EIP>:
Code;  c0a15cf3<=
   0:   80 3c 11 ff   cmpb   $0xff,(%ecx,%edx,1)   <=
Code;  c0a15cf7 
   4:   0f 44 c6  cmove  %esi,%eax
Code;  c0a15cfa 
   7:   ba 02 00 00 00   

Re: epic100 aka smc etherpower II

[Francois Romieu]

Daniel Nofftz <[EMAIL PROTECTED]> écrit :
[...]
> i can`t get my smc etherpower ii working with the 2.4.3 kernel.
> now i have downgraded to 2.4.2 and it works again ...
> does anyone have a suggestion, what the problem is ?
[...]
> Mar 31 19:23:29 hyperion kernel: eth0: Setting half-duplex based on MII
> xcvr 3 register read of 0001.
> Mar 31 19:23:29 hyperion kernel: Real Time Clock Driver v1.10d
> Mar 31 19:23:29 hyperion kernel: eth0: Setting full-duplex based on MII #3
> link partner capability of 45e1.
> Mar 31 19:24:31 hyperion kernel: NETDEV WATCHDOG: eth0: transmit timed out

How does it behave if you give it the following args:
options=4
full_duplex=4

> lspci output:
[...]

No USB controller ?

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Asus CUV4X-D, 2.4.3 crashes at boot

[Keith Owens]

On Sun, 1 Apr 2001 12:09:18 +0200, 
David Weinehall <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 01, 2001 at 10:04:17PM +1200, Simon Garner wrote:
>> Thanks, but I do not have watchdog support compiled into the kernel.
>
>Doesn't matter. The NMI-watchdog tries to detect SMP-lockups, and is
>always present. Unless you specifically disable it on boot.

Not any more.  In 2.4.3-ac* the default is no watchdog and it must be
specifically enabled at boot.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Keith Owens]

On Sun, 01 Apr 2001 01:01:59 -0800, 
[EMAIL PROTECTED] (Chip Salzenberg) wrote:
>In article  you write:
>Why not have a kernel thread and use standard RPC techniques like
>sockets?  Then you'd not have to invent anything unimportant like
>Yet Another IPC Technique.

kerneld (kmod's late unlamented predecessor) used to use Unix sockets
to communicate from the kernel to the daemon.  It forced everybody to
link Unix sockets into the kernel but there are some people out there
who want to use it as a module.  Also the kernel code for communicating
with kerneld was "unpleasant", see ipc/msg.c in a 2.0 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: Minor 2.4.3 Adaptec Driver Problems

[Marko Kreen]

On Sun, Apr 01, 2001 at 01:09:30PM -0700, Earle Nietzel wrote:
> > Umm.  This isn't an aic7xxx driver problem at all.  The SCSI layer
> > determines the order of bus attachment *amongst* the various
> > SCSI HBA (or SCSI HBA like) drivers in the system.  In this case,
> > it has decided to probe your IDE devices as SCSI devices first.
> > Why it does this I don't really know (link order perhaps???).  One
> > way around this would be to put your IDE driver into an initial
> > ram disk and compile the aic7xxx driver directly into the kernel.


> It really wouldn't make a big deal but I consider my cdroms and zip drives
> to be removable devices and if I ever decided to remove my zip my scsi ids
> will change. Removing a harddrive is not the same as removing a zip!
> 
> Are there other people with the same problem?

Yes, I have ide-scsi compiled in for cd-writer, so 2.4.3 did not
boot on my machine (that is, could  not mount anything).

Not nice.

-- 
marko

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Vegas implementation for Linux

[David S. Miller]

Dan Hollis writes:
 > tcp vegas performs very badly for me on asymmetric links (e.g. adsl),
 > about 50% performance loss vs non-vegas.

This among other reasons is why I ripped out vegas from the
kernel a couple years ago.  I'm actually disappointed vendors
have added this patch because it is still a reasearch problem
as to whether vegas's behavior negatively impacts the overall
internet when clients use it or not.

Sure it's sysctl controlled and disabled by default, but it really
should not be there at all as it's all too tempting to enable
this greedy behavior since it can in many cases improve performance
for the person using vegas (but not necessarily for other machines
not doing vegas but sharing the pipe with the vegas guys flows, they
can be negatively impacted).

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/

Promise 20267 "working" but no UDMA

[Andrew Chan]

Anybody manage to get UDMA 66/100 working with an on-board Promise 20267
chip?

Hardware: Tyan Tiger LE (with ServerWorks OSB4 _and_ Promise 20267 on-board)

Kernel: 2.4.3 with ide.2.4.3-p8.all.03242001.patch by Andre Hedrick (or
stock 2.4.3 with more or less same results)

FastTrack config: only 1 drive, configured as a SPAN volume consisting of 1
drive

I don't quite care about the Promise RAID features. I will use Linux
software RAID. The problem is that I cannot seem to be able to get the
controller into UDMA 4 (66 Mhz) mode!

I have enabled all the relevant DMA related kernel options. I have also
checked using the Seagate disk utility to make sure that the drive is
recognized (and configured) as UDMA 66 capable.

The following is from dmesg:

PCI: Found IRQ 10 for device 00:03.0
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: ROM enabled at 0xfeae
PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER
Mode.
PDC20267: neither IDE port enabled (BIOS)

I wonder what the last line meant by saying neither port is enabled?

# /sbin/hdparm -Tt /dev/hde

/dev/hde:
 Timing buffer-cache reads:   128 MB in  0.74 seconds =172.97 MB/sec
 Timing buffered disk reads:  64 MB in 12.82 seconds =  4.99 MB/sec [should
be much much faster here]

# cat /proc/ide/pdc202xx

PDC20267 Chipset.
--- General
Status -
Burst Mode   : enabled
Host Mode: Normal
Bus Clocking : 33 PCI Internal
IO pad select: 10 mA
Status Polling Period: 0
Interrupt Check Status Polling Delay : 0
--- Primary Channel  Secondary
Channel -
enabled  enabled
66 Clocking enabled  disabled
   Mode MASTER  Mode MASTER
FIFO Empty   FIFO Empty
--- drive0 - drive1  drive0 --
drive1 --
DMA enabled:no   no  yes   no
DMA Mode:   UDMA 4   NOTSET  NOTSETNOTSET
PIO Mode:   PIO 4NOTSET   NOTSETNOTSET

# hdparm -d1 /dev/hde

/dev/hde:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 using_dma=  0 (off)

# hdparm -X68 /dev/hde

[resulted in the following message in /var/log/messages]

Apr  1 19:03:21 promise kernel: ide2: Speed warnings UDMA 3/4/5 is not
functional.

# hdparm -i /dev/hde

/dev/hde:

 Model=ST36421A, FwRev=6.01, SerialNo=5BE064AN
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=13330/15/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=256kB, MaxMultSect=16, MultSect=off
 CurCHS=13330/15/63, CurSects=913440960, LBA=yes, LBAsects=12596850
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 *mdma2 udma0 udma1 udma2 udma3 *udma4

Many thanks for pointers!

Andrew Chan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Minor 2.4.3 Adaptec Driver Problems

[Earle Nietzel]

> Umm.  This isn't an aic7xxx driver problem at all.  The SCSI layer
> determines the order of bus attachment *amongst* the various
> SCSI HBA (or SCSI HBA like) drivers in the system.  In this case,
> it has decided to probe your IDE devices as SCSI devices first.
> Why it does this I don't really know (link order perhaps???).  One
> way around this would be to put your IDE driver into an initial
> ram disk and compile the aic7xxx driver directly into the kernel.

My IDE and AIC7xxx drivers are compiled in to the kernel. I normally conpile
system dependent drivers into the kernel and leave the rest modules when
possible.

> This should force the system to assign the devices the other way
> around.

In all prior versions of the kernel 2.4.3 I have never had this problem. I
have both 2.4.2 & 2.4.3 and when booting from one to the other 2.4.2 orders
my SCSI id's correctly and 2.4.3 doesn't.

It really wouldn't make a big deal but I consider my cdroms and zip drives
to be removable devices and if I ever decided to remove my zip my scsi ids
will change. Removing a harddrive is not the same as removing a zip!

Are there other people with the same problem?

Earle

If you need any more info don't hesitate to ask.


_
Do You Yahoo!?
Get your free @yahoo.com address at http://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: TCP Vegas implementation for Linux

[David S. Miller]

Chip Salzenberg writes:
 > Our (VA's) kernel includes a Vegas patch:
 > 
 >ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2

Slight typo in the URL, it's:

ftp://ftp.valinux.com/pub/people/chip/kernel/linux-vegas-v2-patch-2.2

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: TCP Vegas implementation for Linux

[Dan Hollis]

On Sun, 1 Apr 2001, Chip Salzenberg wrote:
> Our (VA's) kernel includes a Vegas patch:
>ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2

tcp vegas performs very badly for me on asymmetric links (e.g. adsl),
about 50% performance loss vs non-vegas.

-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/