2.4.2-ac18 fix for Alpha machines

[Matti Aarnio]

The linkage of vmlinux fails with lacking code for  bust_spinlocks(),
thus I cloned the i386 one as is -- which apparently is not really
processor specific...


--- arch/alpha/mm/fault.c~  Sun Mar 11 11:49:23 2001
+++ arch/alpha/mm/fault.c   Sun Mar 11 14:46:39 2001
@@ -231,3 +231,39 @@
}
 #endif
 }
+
+extern spinlock_t timerlist_lock;
+
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out (timerlist_lock is acquired through the
+ * console unblank code)
+ */
+void bust_spinlocks(int yes)
+{
+   spin_lock_init(&timerlist_lock);
+   if (yes) {
+   oops_in_progress = 1;
+#ifdef CONFIG_SMP
+   global_irq_lock = 0;/* Many serial drivers do __global_cli() */
+#endif
+   } else {
+   int loglevel_save = console_loglevel;
+   unblank_screen();
+   oops_in_progress = 0;
+   /*
+* OK, the message is on the console.  Now we call printk()
+* without oops_in_progress set so that printk will give klogd
+* a poke.  Hold onto your hats...
+*/
+   console_loglevel = 15;  /* NMI oopser may have shut the 
+console up */
+   printk(" ");
+   console_loglevel = loglevel_save;
+   }
+}
+
+void do_BUG(const char *file, int line)
+{
+   bust_spinlocks(1);
+   printk("kernel BUG at %s:%d!\n", file, line);
+}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IDE on 2.4.2

[Martin Diehl]

On Sun, 11 Mar 2001, Steven Walter wrote:

> > on insmod). This is with SiS5513 rev 208 IDE function from SiS5591
> > chipset with CONFIG_BLK_DEV_SIS5513 and autotune enabled (default).
> 
> I have this exact same chip on my board (a PCChips M599-LMR or something
> like that) which works flawlessly on 2.4.2, even with UDMA66.

Do you have CONFIG_BLK_DEV_SIS5513 and autotuning enabled at the
same time? Unless I enable them both it works flawlessly for me too - up
to UDMA33. In fact, I've never seen any docs claiming the 5591/5513 would
even provide UDMA66 support. How do you program the controler to do UDMA66
cycles?
Anyway, might be interesting to have a look at your lspci -d:5513 -vvvxxx
report from working UDMA33/66 setups!

Martin



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

ps2 keyboard not recognized in 2.4.2

[Ralph Gauges]

Hi,

I am not exactly new to linux, but right now I am clueless.
I have been running Kernel 2.4.0ac4 for a while and now I tried to
upgrade to 2.4.2. Everything went well, but after boot, I can not use
the keyboard. I can not type a thing, the only way to reboot is to hit
the reset switch.
The keyboard is connected to the ps2 port and the mouse is connected to
the serial port.
After booting the old kernel, searched through the boot messages, but I
could not find an error message anywhere.
I also tried 2.4.2ac16 with the same result.
Since this a single machine not connected to any other, I can not log in
to check some things, so I would be very happy if someone could tell me
what is going wrong.

Machine Specs are:

Athlon 500 on Ausu K7M
256 MB RAM
Matrox G400DH
3x IDE HDD
1xISA ISDN Card
Pinnacle Bt848 Board
Adaptec 2940U2W
1x DVD-ROM SCSI
1x ZIP SCSI
1x YAMAHA CD-RW SCSI


Thanks a lot

Ralph

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

Re: Rename all derived CONFIG variables

[Jeff Garzik]

Keith Owens wrote:
> 
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them.  It is useful for the
> kernel build process to know which variables are derived and which
> variables the user can control.  There are also 6 CONFIG options that
> are not used anywhere.
> 
> ftp://ftp.ocs.com.au/pub/2.4.2-ac18-config_derived.gz
> 
> is a 583,904 byte (unzipped) 114,291 (gzipped) patch which removes the
> unused variables and renames the 130 derived variables from CONFIG_FOO
> to CONFIG_FOO_DERIVED.  The affected variables are :-

Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name
of derived vars, but your patch does not belong in a stable series. 
Derived CONFIG_xxx vars are likely to be referenced in source.  Changing
those vars in the middle of a stable series pointlessly breaks external
source code.

I hope vendors don't start applying this patch...

Jeff


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

No Subject

[Donald J. Barry]

Odd problem: Guaranteed Oops on my "pathological file system" (a monster ext2)

System: Athlon tbird 1100 MHz 
GA 79X motherboard (with the notorious VIA kt133 chipset) 
this problem with a very minimal 2.4.2 install except with
Pavlich's v4.3 via82cxxx.c driver (same problem with 2.4.2
stock driver), also same problems problems also seen with
RedHat's rawhide 2.4.2-0.1.25 (and 0.1.19)

I had corruption problems before, slowly knocked away by upgrading
mb bios to current and using less aggressive disk parameters.  Now
running: 
/dev/hda: (and hdb and hde, my 3 drives)
 multcount=  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 7473/255/63, sectors = 120064896, start = 0

(and I just reproduced the oops even with DMA entirely off on these three
drives).

My "pathological file system" is a three physical partition lvm volume,
nonstriped, just a simple concretion, containing an e2fs 180G volume.  
But some of the directories have many thousands of files (ugh) of 
considerable length (40-60 characters, in many cases).

Just doing a "du -s *" in the top level will create the oops, quite
reliably.  Sometimes fscking the system after a reboot will oops it also.

It's a new system and has been a royal pain in the three days I've had it.

More problems with the vaunted VIA chips? (the AmiBios isn't terribly
configurable but I've got all the parameters set at their conservative
end -- this is for a spacecraft data server in our lab here, and I'd
sort of like the thing to be stable -- not an auspicious beginning so far.

Cheers,  Don Barry, 
SIRTF/IRS Science Team,
Cornell Astronomy
(please cc to [EMAIL PROTECTED] any messages to the list)

ksymoops follows

ksymoops 2.3.4 on i686 2.4.2.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Warning (compare_maps): ksyms_base symbol __blk_get_queue_R__ver___blk_get_queue not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_cleanup_queue_R__ver_blk_cleanup_queue 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_get_queue_R__ver_blk_get_queue not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_init_queue_R__ver_blk_init_queue not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
blk_queue_headactive_R__ver_blk_queue_headactive not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
blk_queue_make_request_R__ver_blk_queue_make_request not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
blk_queue_pluggable_R__ver_blk_queue_pluggable not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
blkdev_release_request_R__ver_blkdev_release_request not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
end_that_request_first_R__ver_end_that_request_first not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
end_that_request_last_R__ver_end_that_request_last not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
generic_make_request_R__ver_generic_make_request not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
generic_unplug_device_R__ver_generic_unplug_device not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol io_request_lock_R__ver_io_request_lock not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol queued_sectors_R__ver_queued_sectors not 
found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address 003dde2f
c014196b
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: cffd9188   ebx: 003dde0f   ecx: 000e   edx: 006d0225
esi: 003dde0f   edi:    ebp: cffd9188   esp: ce419eb8
ds: 0018   es: 0018   ss: 0018
Process du (pid: 902, stackpage=ce419000)
Stack: 006d0225  006d0225 ce885c00 c0141d87 ce885c00 006d0225 cffd9188 
     006d0225 c

Rename all derived CONFIG variables

[Keith Owens]

In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
other options, the user has no control over them.  It is useful for the
kernel build process to know which variables are derived and which
variables the user can control.  There are also 6 CONFIG options that
are not used anywhere.

ftp://ftp.ocs.com.au/pub/2.4.2-ac18-config_derived.gz

is a 583,904 byte (unzipped) 114,291 (gzipped) patch which removes the
unused variables and renames the 130 derived variables from CONFIG_FOO
to CONFIG_FOO_DERIVED.  The affected variables are :-

Removed.  There were a couple more that could have been removed because
nothing checks them, but they identify architecture types in .config
and are useful for bug reporting.

CONFIG_ABSTRACT_CONSOLE
CONFIG_ACPI_INTERPRETER
CONFIG_CACHE_LINE_SHIFT
CONFIG_FB_CONSOLE
CONFIG_PCMCIA_SCSICARD
CONFIG_PERCPU_IRQ

Renamed to _DERIVED.

CONFIG_ALPHA_APECS
CONFIG_ALPHA_BROKEN_IRQ_MASK
CONFIG_ALPHA_CIA
CONFIG_ALPHA_EISA
CONFIG_ALPHA_EV4
CONFIG_ALPHA_EV5
CONFIG_ALPHA_EV6
CONFIG_ALPHA_EV6
CONFIG_ALPHA_IRONGATE
CONFIG_ALPHA_LCA
CONFIG_ALPHA_MCPCIA
CONFIG_ALPHA_POLARIS
CONFIG_ALPHA_PYXIS
CONFIG_ALPHA_T2
CONFIG_ALPHA_TSUNAMI
CONFIG_ARC32
CONFIG_ARC64
CONFIG_ARCH_ACORN
CONFIG_ARCH_EBSA285
CONFIG_ARCH_S390
CONFIG_ARCH_S390X
CONFIG_ARC_MEMORY
CONFIG_ARM
CONFIG_ATM_FORE200E
CONFIG_BLK_DEV_COMMERIAL
CONFIG_BLK_DEV_HD
CONFIG_BLK_DEV_IDEDISK_VENDOR
CONFIG_BLK_DEV_IDEDMA
CONFIG_BLK_DEV_IDE_MODES
CONFIG_BOARD_SCACHE
CONFIG_BOOT_ELF32
CONFIG_BOOT_ELF64
CONFIG_BUS_I2C
CONFIG_COBALT_27
CONFIG_COBALT_LCD
CONFIG_COHERENT_IO
CONFIG_CPU_26
CONFIG_CPU_32
CONFIG_CPU_32v3
CONFIG_CPU_32v4
CONFIG_CPU_SH3
CONFIG_CPU_SH4
CONFIG_CRIS_LOW_MAP
CONFIG_DMASOUND
CONFIG_DMA_NONPCI
CONFIG_DMA_NONPCI_DERIVED
CONFIG_DUMMY_CONSOLE
CONFIG_FBCON_STI
CONFIG_FB_APOLLO
CONFIG_FB_G364
CONFIG_FB_HP300
CONFIG_FB_MAC
CONFIG_FB_Q40
CONFIG_FOOTBRIDGE
CONFIG_FOOTBRIDGE_ADDIN
CONFIG_FOOTBRIDGE_HOST
CONFIG_FUSION_BOOT
CONFIG_HAVE_DEC_LOCK
CONFIG_IA64
CONFIG_IA64_BRL_EMU
CONFIG_IDEDMA_AUTO
CONFIG_IP_NF_NAT_FTP
CONFIG_IP_NF_NAT_NEEDED
CONFIG_ISA
CONFIG_ISA_DMA
CONFIG_ISDN_CAPI_CAPIFS
CONFIG_ITANIUM
CONFIG_KBDMOUSE
CONFIG_LOCKD
CONFIG_LOCKD_V4
CONFIG_M68K_L2_CACHE
CONFIG_MACH_SPECIFIC
CONFIG_MAC_HID
CONFIG_MIPS_JAZZ
CONFIG_MSNDCLAS_HAVE_BOOT
CONFIG_MSNDPIN_HAVE_BOOT
CONFIG_MTD_AMDSTD
CONFIG_MTD_DOCPROBE
CONFIG_MTD_JEDEC
CONFIG_NET_CLS_ROUTE
CONFIG_NLS
CONFIG_NUBUS
CONFIG_PARIDE_PARPORT
CONFIG_PCI_BIOS
CONFIG_PCI_CONSOLE
CONFIG_PCI_DIRECT
CONFIG_PCMCIA_CHRDEV
CONFIG_PCMCIA_NETCARD
CONFIG_PC_KEYB
CONFIG_PC_KEYMAP
CONFIG_PPC
CONFIG_PPC64BRIDGE
CONFIG_QL_ISP_A64
CONFIG_RPCMOUSE
CONFIG_SA
CONFIG_SBUS
CONFIG_SBUSCHAR
CONFIG_SGI
CONFIG_SH_HP600
CONFIG_SH_RTC
CONFIG_SMB_NLS
CONFIG_SPARC32
CONFIG_SPARC64
CONFIG_SUNRPC
CONFIG_SUN_AUXIO
CONFIG_SUN_CONSOLE
CONFIG_SUN_IO
CONFIG_SUN_SERIAL
CONFIG_SUPERH
CONFIG_TQM8xxL
CONFIG_UID16
CONFIG_X86
CONFIG_X86_ALIGNMENT_16
CONFIG_X86_BSWAP
CONFIG_X86_CMPXCHG
CONFIG_X86_GOOD_APIC
CONFIG_X86_INVLPG
CONFIG_X86_IO_APIC
CONFIG_X86_L1_CACHE_SHIFT
CONFIG_X86_LOCAL_APIC
CONFIG_X86_PAE
CONFIG_X86_PGE
CONFIG_X86_POPAD_OK
CONFIG_X86_TSC
CONFIG_X86_USE_3DNOW
CONFIG_X86_USE_PPRO_CHECKSUM
CONFIG_X86_USE_STRING_486
CONFIG_X86_VISWS_APIC
CONFIG_X86_WP_WORKS_OK
CONFIG_ZFT_COMPRESSOR

The patch hits these files.

Documentation/Configure.help
Documentation/kbuild/config-language.txt
Documentation/kbuild/makefiles.txt
Makefile
arch/alpha/Makefile
arch/alpha/config.in
arch/alpha/defconfig
arch/alpha/kernel/Makefile
arch/alpha/kernel/alpha_ksyms.c
arch/alpha/kernel/irq_alpha.c
arch/alpha/kernel/irq_i8259.c
arch/alpha/kernel/process.c
arch/alpha/kernel/setup.c
arch/alpha/lib/Makefile
arch/arm/Makefile
arch/arm/boot/Makefile
arch/arm/boot/compressed/Makefile
arch/arm/config.in
arch/arm/def-configs/a5k
arch/arm/def-configs/assabet
arch/arm/def-configs/brutus
arch/arm/def-configs/cerf
arch/arm/def-configs/clps7500
arch/arm/def-configs/ebsa110
arch/arm/def-configs/empeg
arch/arm/def-configs/footbridge
arch/arm/def-configs/graphicsclient
arch/arm/def-configs/integrator
arch/arm/def-configs/lart
arch/arm/def-configs/lusl7200
arch/arm/def-configs/neponset
arch/arm/def-configs/pangolin
arch/arm/def-configs/rpc
arch/arm/def-configs/shark
arch/arm/def-configs/sherman
arch/arm/def-configs/victor
arch/arm/defconfig
arch/arm/kernel/Makefile
arch/arm/kernel/arch.c
arch/arm/kernel/armksyms.c
arch/arm/kernel/bios32.c
arch/arm/kernel/debug-armv.S
arch/arm/kernel/dma-footbridge.c
arch/arm/kernel/ecard.c
arch/arm/kernel/entry-armv.S
arch/arm/kernel/fiq.c
arch/arm/kernel/irq.c
arch/arm/kernel/process.c
arch/arm/kernel/semaphore.c
arch/arm/kernel/setup.c
arch/arm/kernel/signal.c
arch/arm/kernel/traps.c
arch/arm/lib/Makefile
arch/arm/lib/backtrace.S
arch/arm/lib/csumpartialcopyuser.S
arch/arm/lib/ecard.S
arch/arm/lib/io-acorn.S
arch/arm/mach-footbridge/Makefile
arch/arm/mach-footbridge/arch.c
arch/arm/mach-sa1100/hw.c
arch/arm/mach-shark/dma.c
arch/arm/mm/Makefile
arch/arm/mm/fault-common.c
arch/arm/mm/init.c
arch/arm/mm/mm-footbridge.c

Re: linux localization

[Martin Dalecki]

Alan Cox wrote:
> 
> > My work will concern with the internationalization of Linux
> > So, could anybody tell me what kinds of features should be in the
> > consideration when linux be localized from english to Japanese or chinese,
> > say using 2 bytes character set.
> 
> Most of the Linux userspace libraries are set up for handling UTF8 and
> other internationalisations. Fonts are more of an issue and lack of application
> translations. Filenames are defined to be UTF8.

Something along the lines of pcvt (*BSD)
for full userspace line discipline handling on
the console would be great. Read: much saner then trying to do this all
in kernel like
linux does currently. Maybe the linux way was justified during the days
of 386sx 16MHz
somehow. Currently it's relly just plain ugly. Try using some other
character set then iso8859-1 on the linux console to see why.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Penguin logos

[Martin Dalecki]

"Albert D. Cahalan" wrote:
> 
> Geert Uytterhoeven writes:
> 
> >   - The colors for the 16 color logo are wrong. We used a hack to
> > give the logo its own color palette, but this no longer works
> > as a side effect of a console color map bug being fixed a while
> > ago. The solution is to replace the logo with a new one that
> > uses the standard VGA console palette.
> 
> Good idea, but the feet don't look too good. Either dither a bit,
> or pick a single color for the feet. Maybe a checkerboard-dither
> would get close to the right color without looking grainy.
> 
> >   - There are still some politically-incorrect (PI) logos of a penguin
> > holding a glass of beer or wine (or perhaps even worse? :-).
> 
> Those also just look bad. The drink sort of floats above the penguin's
> foot. It really looks like it was just pasted onto the image.
> 
> The arch-specific logos look bad in general, and the swirly gray
> background isn't so great either. Why not use the original image?

I agree fully about the swirly gray - it's just looks ugly chlidish,
dilletantic
and very tasteless... plain color or some gui alike border would look
much better.

> 
> > Changes:
> >  1. Update the frame buffer console code to no longer change the
> > palette when displaying the 16 color logo. Remove the tricks
> > to load the logo palette in unused palette entries on displays
> > with >= 32 colors.
> 
> I used to have only 256 colors on my display. I upgraded because
> there still isn't a global system palette. I'd have been happy
> enough with 256 colors allocated in a sane way, for kernel & X:
> 
> 1. the 16 VGA colors and extra 4 Windows colors (so Wine can work)
> 2. the 216 Netscape colors
> 3. gray: 0x00, 0x11, 0x22... 0xff, plus both 0x7f and 0x80
> 4. everything else reserved for future global allocation
> 
> The current situation is way too painful to use.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] serial console vs NMI watchdog

[Keith Owens]

On Sun, 11 Mar 2001 20:43:16 -0800, 
george anzinger <[EMAIL PROTECTED]> wrote:
>Consider this.  Why not use the NMI to sync the cpus.  Kdb would have a
>function that is called each NMI.

kdb uses NMI IPI to get the other cpu's attention.  One cpu is in
control and may or may not be accepting NMI, it depends on the event
that entered kdb.  The other cpus end up in kdb code, spinning waiting
for a cpu switch.  Initially they are not receiving NMI because they
were invoked via NMI which is masked until they exit.  However if the
user does a cpu switch then single steps the interrupted code, the cpu
has to return from the NMI handler to the interrupted code at which
time this cpu starts receiving NMI again.

The kdb context can change from ignoring NMI to accepting NMI.  It is
easier to bring all the cpus into kdb and let the kdb code decide if it
ignores any NMI that is being received.

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

[Rick Hohensee]

>> My work will concern with the internationalization of Linux
>> So, could anybody tell me what kinds of features should be in the
>> consideration when linux be localized from english to Japanese or
chinese,
>> say using 2 bytes character set.
>
>Most of the Linux userspace libraries are set up for handling UTF8 and
>other internationalisations. Fonts are more of an issue and lack of
application>translations. Filenames are defined to be UTF8.

For the features that don't exist in Linux yet, you want to look closely
at Plan 9 From Bell Labs, whence UTF-8 originates. Plan 9 for example has
font cacheing in the kernel for huge glyph sets, if I read it right. The
Plan 9 C compiler, written by Ken Thompson, author of UNIX and ed,
specifically for writing Plan 9, is fully UTF-8 also. Everything else in
Plan 9 is also UTF-8, from ed to libc to the GUI.

Per-process namespaces are a Plan 9 idea also. That is the ultimate in
localization. Plan 9 was released relatively recently under a license
clearly patterned after the GPL. Congratulations once again to Richard
Stallman. Thompson, Ritchie, Pike and so on have embraced his most
important ideas. 

Plan 9 has a narrow platform base compared to Linux or NetBSD. I myself
haven't been able to install it on my oldish hardware. You probably need
to see it running, I suspect. 

My own Dotted Standard File Hierarchy mechanism in cLIeNUX
(Linux/GNU/unix) may also be of interest. See my "/" below. That could
easily be Japanese, Mandarin, Hindi, etc.

ftp://linux01.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html

Rick Hohensee
www.clienux.com

:; cLIeNUX /dev/tty3  00:12:08   /
:;d -d */
Linux//dev//  help// mounts//   suite//
boot// device//   incoming// owner//temp//
command//  floppy//   log//  source//
configure//guest//lost+found//   subroutines//
:; cLIeNUX /dev/tty3  00:42:44   /
:;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How many dquots is enough?

[Norman Gaywood]

I have not been able to run quotas for several versions of 2.2.x now. I
always get stuff like:

Mar 11 18:56:17 turing kernel: Unable to handle kernel paging request at virtual 
address 6c206f8f 
Mar 11 18:56:17 turing kernel: current->tss.cr3 = 2b4e1000, %%cr3 = 2b4e1000 
Mar 11 18:56:17 turing kernel: *pde =  
Mar 11 18:56:17 turing kernel: Oops: 0002 
Mar 11 18:56:17 turing kernel: CPU:0 
Mar 11 18:56:17 turing kernel: EIP:0010:[kmem_cache_alloc+19/348] 
Mar 11 18:56:17 turing kernel: EFLAGS: 00010006 
Mar 11 18:56:17 turing kernel: eax: 6c206f6f   ebx:    ecx:    edx: 
f66cf208 
Mar 11 18:56:17 turing kernel: esi: 6c206f6f   edi: 0080   ebp: 0206   esp: 
b3381f08 
Mar 11 18:56:17 turing kernel: ds: 0018   es: 0018   ss: 0018 
Mar 11 18:56:17 turing kernel: Process in.ftpd (pid: 9193, process nr: 305, 
stackpage=b3381000) 
Mar 11 18:56:17 turing kernel: Stack: 0080 f778ade0 8013b275 6c206f6f 0015 
  0080  
Mar 11 18:56:17 turing kernel: 8013b3fa  8013b571  
0001 08084580 fffd  
Mar 11 18:56:17 turing kernel:027a 0002   0811 
0020 0811 8013c086  
Mar 11 18:56:17 turing kernel: Call Trace: [grow_dquots+21/132] 
[get_empty_dquot+194/284] [dqget+285/660] [get_quota+130/272] [sys_quotactl+526/784] 
[system_call+52/56]  
Mar 11 18:56:17 turing kernel: Code: f0 0f ba 6e 20 00 0f 82 56 e5 0d 00 90 8b 06 89 
c3 81 78 08  

The process in question will then hang in the D state. More and processes
get like this until the system becomes unusable. The Oops is always in
kmem_cache_alloc called from grow_dquots.

I solve it by turning off quotas with "quotaoff -a" after a reboot.

I thought that I probably didn't have enough dquots so I increased
dquot-max to 16384. But I still get these Oops-es.

In Documentation/proc.txt it tells me:

  dquot-nr and dquot-max
 ...
 If the number of free cached disk quotas is very low and you have
 a large number of simultaneous system users, you might want
 to raise the limit.

Problem is I have no handle on what "very low", "large number", and
whether I "might want to" mean. I'm not even sure how you define what a
"simultaneous system user" is.

Our system typically would have 20-100 ssh/rlogin/telnet sessions which
overlaps with 20-60 "Xterminal" sessions. Also < 10 ftp sessions,
< 20 samba connections and 10-50 WWW hits a minute.

The current kernel is a RedHat 6.2 rpm based install of 2.2.16, rebuilt
for PPro/6x86MX, with Bigmem set for 2Gig, CONFIG_UNIX98_PTY_COUNT=2048,
and SCSI_AIC7XXX built into the kernel (not a module).

I'm happy to supply more details if anyone is interested.

Cheers.
-- 
Norman Gaywood -- School of Mathematical and Computer Sciences
University of New England, Armidale, NSW 2351, Australia
[EMAIL PROTECTED] http://turing.une.edu.au/~norm
Phone: +61 2 6773 2412 Fax: +61 2 6773 3312

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

Re: your mail

[Greg KH]

On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
> 
> Bug report from Martin Bruchanov ([EMAIL PROTECTED], [EMAIL PROTECTED])
> 
> 
> [1.] One line summary of the problem:
> USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.

What kind of motherboard is this?

And does USB work in SMP mode with "noapic" given on the kernel command
line?

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] serial console vs NMI watchdog

[george anzinger]

Keith Owens wrote:
> 
> On Sun, 11 Mar 2001 08:44:24 +0100 (CET),
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >Andrew,
> >
> >your patch looks too complex, and doesnt cover the case of the serial
> >driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function
> >that just changes last_irq_sums instead of adding locking? This way
> >deadlocks will be caught in the serial code too. (because touch_nmi() will
> >only "postpone" the NMI watchdog lockup event, not disable it.)
> 
> kdb has to completely disable the nmi counter while it is in control.
> All interrupts are disabled, all but one cpus are spinning, the control
> cpu does busy wait while it polls the input devices.  With that model
> there is no alternative to a complete disable.
> 
Consider this.  Why not use the NMI to sync the cpus.  Kdb would have a
function that is called each NMI.  If it is doing nothing, just return
false, else, if waiting for this cpu, well here it is, put it in spin
AFTER saving where it came from so the operator can figure out what it
is doing.  In kgdb I just put the interrupt registers in the task_struct
where they are put when a context switch is done.  Then the debugger can
do a trace, etc. on that task.  A global var that the debugger can see
is also set to the cpus, "current".  

If the cpu is already spinning, return to the nmi code with a true flag
which will cause it to ignore the nmi.  Same thing if it is the cpu that
is doing debug i/o.

I went to this for kgdb after the system failed to return from the call
to force the other cpus to execute a function (which means they have to
be alive).  For extra safety I also time the sync.  If one or more
expected cpus, don't show while looping reading the cycle counter, the
code just continues with out the sync.

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

params of register_netdev

[Rama Krishna Mandava]

hi all,
 In my module the code as below ...syntax code from alasandro rubini
...I hope all arguments are not necessary to be initialised   

struct device my_dev =
{
  myne_name,
0,0,0,0,
0x000,
0,
0,0,0,
NULL,
myne_init,
};


int   init_module(void)
{
register_netdev(my_dev);
}


the compile error generated is  :incompatible type for argument 1 of 
'register_netdev'..

Please help me out.

Thank u
srinivas


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

Re: hotplug and interrupt context

[Jeff Garzik]

Andreas Bombe wrote:
> 
> I couldn't trace that down to be 100% sure and it's better to conform to
> design than implementation, so I'll ask:
> 
> Do the probe and remove functions of a pci_driver have to be able to
> work in interrupt context?  (i.e. GFP_ATOMIC and stuff)

No, no interrupt context to worry about.  It would really suck if you
couldn't sleep in pci_driver::probe :)

For CardBus, it calls schedule_task ..

-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

make: *** [vmlinux] Error 1

[tmwhitehead]

On a compile of 2.4.2 I get the following (using make bzImage) 


make[2]: Leaving directory `/usr/src/linux-2.4.2/linux/arch/i386/lib'
make[1]: Leaving directory `/usr/src/linux-2.4.2/linux/arch/i386/lib'
ld -m elf_i386 -T /usr/src/linux-2.4.2/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o
\
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o  drivers/parport/driver.o
drivers/char/agp/agp.o drivers/ide/idedriver.o drivers/cdrom/driver.o
drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o \
net/network.o \
/usr/src/linux-2.4.2/linux/arch/i386/lib/lib.a
/usr/src/linux-2.4.2/linux/lib/lib.a
/usr/src/linux-2.4.2/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
init/main.o: In function `check_fpu':
init/main.o(.text.init+0x63): undefined reference to `__buggy_fxsr_alignment'
make: *** [vmlinux] Error 1


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

Re: linux localization

[Alan Cox]

> My work will concern with the internationalization of Linux
> So, could anybody tell me what kinds of features should be in the
> consideration when linux be localized from english to Japanese or chinese,
> say using 2 bytes character set.

Most of the Linux userspace libraries are set up for handling UTF8 and
other internationalisations. Fonts are more of an issue and lack of application
translations. Filenames are defined to be UTF8.

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

linux localization

[XingFei]

Hello
My work will concern with the internationalization of Linux
So, could anybody tell me what kinds of features should be in the
consideration when linux be localized from english to Japanese or chinese,
say using 2 bytes character set.
Thanks a lot

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

[PATCH] 2.4.2-ac18 ipx compile fix

[Anton Altaparmakov]

Attached patch is required to make ipx compile in 2.4.2-ac18.

Appologies if this has been fixed already.

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/


--- linux-2.4.2-ac18-vanilla/net/ipx/af_ipx.c   Sun Mar 11 23:26:27 2001
+++ linux-2.4.2-ac18/net/ipx/af_ipx.c   Mon Mar 12 01:15:36 2001
@@ -123,7 +123,7 @@
 static unsigned char ipxcfg_max_hops = 16;
 static char ipxcfg_auto_select_primary;
 static char ipxcfg_auto_create_interfaces;
-static int sysctl_ipx_pprop_broadcasting = 1;
+int sysctl_ipx_pprop_broadcasting = 1;
 
 /* Global Variables */
 static struct datalink_proto *p8022_datalink;

Re: sys_sched_yield fast path

[Anton Blanchard]

 
Hi,

> 2.4.x has changed the scheduler behaviour so that the task that call
> sched_yield() is not rescheduled by the incoming schedule().  A flag is
> set ( under certain conditions in SMP ) and the goodness() calculation
> assign the lower value to the exiting task ( this flag is cleared in
> schedule_tail() ).

The behaviour I am talking about is when there is a heavily contended
spinlock, and more than one task is trying to obtain it. Since SCHED_YIELD
only changes the goodness when we are trying to reschedule the task we
can bounce between two or more tasks doing sched_yield() for a while before
finally running the task that has the spinlock.

Of course with short lived spinlocks you should rarely get the case where
a task grabs a spinlock just before its timeslice is up, so maybe the answer
is just to spin a few times on sched_yield() then back off to nanosleep()
like pthreads does.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Penguin logos

[Albert D. Cahalan]

Geert Uytterhoeven writes:

>   - The colors for the 16 color logo are wrong. We used a hack to
> give the logo its own color palette, but this no longer works
> as a side effect of a console color map bug being fixed a while
> ago. The solution is to replace the logo with a new one that
> uses the standard VGA console palette.

Good idea, but the feet don't look too good. Either dither a bit,
or pick a single color for the feet. Maybe a checkerboard-dither
would get close to the right color without looking grainy.

>   - There are still some politically-incorrect (PI) logos of a penguin
> holding a glass of beer or wine (or perhaps even worse? :-).

Those also just look bad. The drink sort of floats above the penguin's
foot. It really looks like it was just pasted onto the image.

The arch-specific logos look bad in general, and the swirly gray
background isn't so great either. Why not use the original image?

> Changes:
>  1. Update the frame buffer console code to no longer change the
> palette when displaying the 16 color logo. Remove the tricks
> to load the logo palette in unused palette entries on displays
> with >= 32 colors.

I used to have only 256 colors on my display. I upgraded because
there still isn't a global system palette. I'd have been happy
enough with 256 colors allocated in a sane way, for kernel & X:

1. the 16 VGA colors and extra 4 Windows colors (so Wine can work)
2. the 216 Netscape colors
3. gray: 0x00, 0x11, 0x22... 0xff, plus both 0x7f and 0x80
4. everything else reserved for future global allocation

The current situation is way too painful to use.

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

hotplug and interrupt context

[Andreas Bombe]

I couldn't trace that down to be 100% sure and it's better to conform to
design than implementation, so I'll ask:

Do the probe and remove functions of a pci_driver have to be able to
work in interrupt context?  (i.e. GFP_ATOMIC and stuff)


I expect so, since CardBus handling doesn't start a thread and would
call these functions from the context it got the insertion message
(interrupt context).

-- 
 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: Status of posix-ACL's

[Bernd Eckenfels]

In article  you wrote:
> What are the biggest problems? (i know that many userland-tools must be
> changed for this).

AFAIK there is no Support in User Land Programs required. You just have
additional tools for managing the ACLs . The main problem with ACLs are the
storage of the additional info in the file system. This is a hard job if you
want to have it for all/most file systems. Remy had a working Version for
ext2, but it never got very public.. dunno why.

NTs ACLs are somewhat messy cause they require too much scanning.

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

Re: VMware 2.0.3 & Kernel 2.4.2-ac17

[Petr Vandrovec]

> While compiling the vmnet module, there is a warning
> 
> make: Entering directory `/tmp/vmware-config2/vmnet-only'
> bridge.c: In function `VNetBridgeReceiveFromDev':
> bridge.c:788: warning: implicit declaration of function `skb_datarefp'
> 
> and while inserting the module
> 
> /tmp/vmware-config2/vmnet.o: unresolved symbol skb_datarefp
> 
> I have traced this back to 2.4.2-ac4 by looking for where this function 
> was removed.

Try this patch. I believe that there are no other needed changes
in vmnet code, but as I do not have any scatter-gather checksumming
hardware around, I'm not 100% sure. But up to now nobody complained 
about getting 'xxx invoked with paged skb', so I believe that rest
of code is correct.
 
diff -u vmnet-only.dist/vnetInt.h vmnet-only/vnetInt.h
--- vmnet-only.dist/vnetInt.h   Thu Nov  2 02:40:20 2000
+++ vmnet-only/vnetInt.hMon Mar 12 01:12:00 2001
@@ -16,9 +16,15 @@
 #  define KFREE_SKB(skb, type) kfree_skb(skb)
 #  define DEV_KFREE_SKB(skb, type) dev_kfree_skb(skb)
 #  define SKB_INCREF(skb)  atomic_inc(&(skb)->users)
-#  define SKB_IS_CLONE_OF(clone, skb)  ( \
-  skb_datarefp(clone) == skb_datarefp(skb) \
-   )
+#  ifdef skb_shinfo
+#define SKB_IS_CLONE_OF(clone, skb)( \
+skb_shinfo(clone) == skb_shinfo(skb) \
+ )
+#  else
+#define SKB_IS_CLONE_OF(clone, skb)( \
+skb_datarefp(clone) == skb_datarefp(skb) \
+ )
+#  endif
 #  define SK_ALLOC(pri)sk_alloc(0, pri, 1)
 #  define DEV_QUEUE_XMIT(skb, dev, pri)( \
   (skb)->dev = (dev), \

> yes, technically this probably is OT, and properly belong on the VMware 
> list, but I can't access their nntp server.

Is problem on your side or on VMware side? If on VMware one, I'd like to
know (private pls.).
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

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

Re: About DC-315U scsi driver

[Alan Cox]

> > when I burn CDRs. Some files burned is different from the origin at HD.
> > I use 2.2.17 with Tekram's driver,and nothing is wrong.
> 
> Indeed; people report more problems on 2.4 kernels than on 2.2 kernels. I
> currently have no clue why.

2.4 causes longer continuous I/O requests to be sent to the drive for one


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

Re: About DC-315U scsi driver

[Kurt Garloff]

Hi,

On Sun, Mar 11, 2001 at 04:37:10PM +0800, ³¯¤ý®i wrote:
> The driver has not to be included in officeal kernel.

Yes, that's what I tell people that ask me to submit the driver from
inclusion. The reason are strange problems, which unfortunately I have not
been able to track down, yet. Fortunately, they don't happen for everyone.
Unfortunately, that means I can't reproduce most of them.

I added quite some debugging feature to the driver, like a complete history
of every SCSI command being kept and output if something goes wrong
(_abort()). I guess, a good chipset docu would give more insight.

> And the maintainer has not updated the driver from 2.4.0-test9-pre7.
> Maybe he is very busy.The last update is 2000-12-03.

I'm quite busy, that's true.
The driver 1.32 (Dec 3 2000) can be used with 2.4.2. Just ignore the
patch rejection in the file MAINTAINERS.

> I used some kernels from 2.4.0 to 2.4.2-ac17,and the driver always go wrong
> when I burn CDRs. Some files burned is different from the origin at HD.
> I use 2.2.17 with Tekram's driver,and nothing is wrong.

Indeed; people report more problems on 2.4 kernels than on 2.2 kernels. I
currently have no clue why.
Anyway, you can use the patch from 1.32 to have the driver integrated in the
2.4 kernel and the use the version from Tekram. (I believe they distribute
my version 1.27, but I didn't check fro quite some time.)
I would like to hear your results.

> I think the scsi layer maybe changed from 2.2.x,so the driver cannot run well.

It did change. For example the way SCSI devices are scanned fro changed from
T_U_R to INQUIRY. However, the driver has been changed to accept that.

> I am sure the hardware&software is ok,and no error messages about scsi
> found by me.
> 
> Can anyone do me a favor to modify the driver in order to suite the
> new kernel?

Compiling it should be no problem.
Making it work flawlessly is. I'd like to know as well.

Regards,
-- 
Kurt Garloff   <[EMAIL PROTECTED]> [Eindhoven, NL]
Physics: Plasma simulations  <[EMAIL PROTECTED]>  [TU Eindhoven, NL]
Linux: SCSI, Security  <[EMAIL PROTECTED]>   [SuSE Nuernberg, FRG]
 (See mail header or public key servers for PGP2 and GPG public keys.)

 PGP signature

Re: Status of posix-ACL's

[Albert D. Cahalan]

Jochen Dolze writes:

> i found at http://acl.bestbits.at the ACL-linux-project. Now i want to know,
> if there is a plan to integrate posix-ACLs into the fs-part of the kernel,
> e.g. into the VFS-Layer? Is there a general discussion about this anywhere?
> What are the biggest problems? (i know that many userland-tools must be
> changed for this).

I hope not. POSIX ACLs are crap. NFSv4 mostly follows NT.
Compatibility with NFSv4 and SMB (Samba's protocol) is important.

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

Re: sys_sched_yield fast path

[Davide Libenzi]

On 11-Mar-2001 Dave Zarzycki wrote:
> On Mon, 12 Mar 2001, Anton Blanchard wrote:
> 
>> Perhaps we need something like sched_yield that takes off some of
>> tsk->counter so the task with the spinlock will run earlier.
> 
> Personally speaking, I wish sched_yield() API was like so:
> 
> int sched_yield(pid_t pid);

Yes, You could do an API like this but it's not the mean of sched_yield().


> This would allow the thread wanting to acquire the spinlock to yield
> specifically to the thread holding the lock (assuming the pid of the lock
> holder was stored in the spinlock...) In fact, the the original lock owner
> could in theory yield back to the threading wanting to acquire the lock.

Everything happens inside a spinlock should be very fast otherwise the use of a
spinlock should be avoided.




- Davide

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

Re: sys_sched_yield fast path

[Davide Libenzi]

On 11-Mar-2001 Anton Blanchard wrote:
>  
>> This is the linux thread spinlock acquire :
>> 
>> 
>> static void __pthread_acquire(int * spinlock)
>> {
>>   int cnt = 0;
>>   struct timespec tm;
>> 
>>   while (testandset(spinlock)) {
>> if (cnt < MAX_SPIN_COUNT) {
>>   sched_yield();
>>   cnt++;
>> } else {
>>   tm.tv_sec = 0;
>>   tm.tv_nsec = SPIN_SLEEP_DURATION;
>>   nanosleep(&tm, NULL);
>>   cnt = 0;
>> }
>>   }
>> }
>> 
>> 
>> Yes, it calls sched_yield() but this is not a std wait for mutex but for
>> spinlocks that are hold a very short time.  Real wait are implemented using
>> signals.  More, with the new implementation of sys_sched_yield() the task
>> release all its time quantum so, even in a case where a task repeatedly
>> calls
>> sched_yield() the call rate is not so high if there is at least one process
>> to spin.  And if there isn't one task with goodness() > 0, nobody cares
>> about
>> sched_yield() performance.
> 
> The problem I found with sched_yield is that things break down with high
> levels of contention. If you have 3 processes and one has a lock then
> the other two can ping pong doing sched_yield() until their priority drops
> below the process with the lock. eg in a run I just did then where 2
> has the lock:
> 
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 2
> 
> Perhaps we need something like sched_yield that takes off some of 
> tsk->counter so the task with the spinlock will run earlier.

2.4.x has changed the scheduler behaviour so that the task that call
sched_yield() is not rescheduled by the incoming schedule().
A flag is set ( under certain conditions in SMP ) and the goodness()
calculation assign the lower value to the exiting task ( this flag is cleared
in schedule_tail() ).
This could give the task owning the lock the opportunity to complete the locked
code.
But yes, if the locked code is rescheduled for some reason ( timeslice or I/O )
the yielding task will run again.
But this is a software design problem, not a sched_yield() one coz, if the time
path between lock ans unlock can be high the use of sched_yield() is not the
best way to wait.
Wait queue or user space equivalences are a better choice to do this.




- Davide

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

Re: sys_sched_yield fast path

[Davide Libenzi]

On 11-Mar-2001 Anton Blanchard wrote:
>  
>> This is the linux thread spinlock acquire :
>> 
>> 
>> static void __pthread_acquire(int * spinlock)
>> {
>>   int cnt = 0;
>>   struct timespec tm;
>> 
>>   while (testandset(spinlock)) {
>> if (cnt < MAX_SPIN_COUNT) {
>>   sched_yield();
>>   cnt++;
>> } else {
>>   tm.tv_sec = 0;
>>   tm.tv_nsec = SPIN_SLEEP_DURATION;
>>   nanosleep(&tm, NULL);
>>   cnt = 0;
>> }
>>   }
>> }
>> 
>> 
>> Yes, it calls sched_yield() but this is not a std wait for mutex but for
>> spinlocks that are hold a very short time.  Real wait are implemented using
>> signals.  More, with the new implementation of sys_sched_yield() the task
>> release all its time quantum so, even in a case where a task repeatedly
>> calls
>> sched_yield() the call rate is not so high if there is at least one process
>> to spin.  And if there isn't one task with goodness() > 0, nobody cares
>> about
>> sched_yield() performance.
> 
> The problem I found with sched_yield is that things break down with high
> levels of contention. If you have 3 processes and one has a lock then
> the other two can ping pong doing sched_yield() until their priority drops
> below the process with the lock. eg in a run I just did then where 2
> has the lock:
> 
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 1
> 0
> 2
> 
> Perhaps we need something like sched_yield that takes off some of 
> tsk->counter so the task with the spinlock will run earlier.

Which kernel are You running ?



- Davide

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

Re: IDE on 2.4.2

[Steven Walter]

On Sun, Mar 11, 2001 at 10:03:48PM +0100, Martin Diehl wrote:
> On Fri, 9 Mar 2001, Lawrence MacIntyre wrote:
> 
> > Uniform MultiPlatform E-IDE driver Revision 6.31
> > ide: assuminmg 33 MHz system bus speed for PIO modes: override with
> > idebus=xx
> > SIS5513: IDE controller on PCI bus 00 dev 09
> > PCI: Assigned IRQ 14 for device 00:01.1
> > SIS5513: chipset revision 208
> > SIS5513: not 100% native mode: will probe irqs later
> > SIS5597
> > ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
> > ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
> > hda: Maxtor 90640D4, ATA DISK drive
> > hdc: CD-ROM CDU55E, ATAPI CD/DVD-ROM drive
> > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > ide1 at 0x170-0x177,0x376 on irq 15
> > 
> > At this point, the machine hangs...
> 
> interesting, I see the same thing except it hangs not before the disk
> drives are initialized but afterwards, when initializing the CD-ROM
> drives. (Compiling ide-cd as module permits successful boot but hangs
> on insmod). This is with SiS5513 rev 208 IDE function from SiS5591
> chipset with CONFIG_BLK_DEV_SIS5513 and autotune enabled (default).

I have this exact same chip on my board (a PCChips M599-LMR or something
like that) which works flawlessly on 2.4.2, even with UDMA66.
-- 
-Steven
Never ask a geek why, just nod your head and slowly back away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in __mark_inode_dirty (2.4.2-pre3)

[Michael Mueller]

Hi,

i wrote:
> EIP:0010:[__mark_inode_dirty+92/112]
> EFLAGS: 00010202
> eax:    ebx: cc85b240   ecx: cc85b428   edx: cc85b248
> esi: c15dc200   edi: 0001   ebp: c361dfa4   esp: c361df24
   

This is a bit-flipper. There is a valid super-block entry at c14dc200.


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

Re: broken(?) Lucent Venus chipset and Linux 2.4

[Martin Diehl]

On Fri, 9 Mar 2001, W. Michael Petullo wrote:

> If you have or have access to a Linux box with a Venus-based modem,
> answering any of these questions would be very helpful:
> 

Well, I'm not absolutely sure if we are talking about the same thing: what 
I have is a re-labeled PC-Card modem which identifies according to

cardctl ident:
  product info: "LUCENT-VENUS", "PCMCIA 56K DataFax"
  manfid: 0x0200, 0x0001
  function: 2 (serial)

ATI:
Venus K56FLEX V.90 kfav163 PCMCIA p52198

> o Does your modem work flawlessly with Linux 2.4?

Yes, for me it does - with the standard serial.c driver (and
PCMCIA's serial_cs of course) under Linux 2.0/2.2/2.4.

HTH.
Martin

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

Digiboard EPCA driver for 2.4

[Jim Paris]

The Digiboard EPCA driver supplied with Linux 2.4.x didn't work for
me, so I took the latest Digi driver and patched it to make it 
work with 2.4 and devfs.  I'm sure that I managed to horribly 
break some stuff, but hey, it works for me.  The patch to their 
latest (4001450M) driver is included below, or, get the updated
driver from:

http://neurosis.mit.edu/~jim/epca/

-jim



diff -Naur epca-1.4.5-1/dl/Makefile epca-1.4.5.1-jim/dl/Makefile
--- epca-1.4.5-1/dl/MakefileFri Mar 24 15:33:25 2000
+++ epca-1.4.5.1-jim/dl/MakefileSun Mar 11 14:16:33 2001
@@ -1,14 +1,15 @@
 
+all: digiDload cxconf epcxconf
+
 digiDload: digiDload.c
-   cc -g -O2 -Wall digiDload.c -o digiDload
+   cc $(CFLAGS) -Wall digiDload.c -o digiDload
 
 cxconf:epcxconf.c
-   cc -g -O2 epcxconf.c -o cxconf
+   cc $(CFLAGS) epcxconf.c -o cxconf
 
 epcxconf: epcxconf.c
-   cc -g -O2 epcxconf.c -o epcxconf -DEPCXCONF
+   cc $(CFLAGS) epcxconf.c -o epcxconf -DEPCXCONF
 clean:
rm -f *~ *.o epcxconf cxconf digiDload
 
-all: digiDload cxconf epcxconf
 
diff -Naur epca-1.4.5-1/dl/digiDload.c epca-1.4.5.1-jim/dl/digiDload.c
--- epca-1.4.5-1/dl/digiDload.c Mon Apr 24 11:16:57 2000
+++ epca-1.4.5.1-jim/dl/digiDload.c Sun Mar 11 14:40:22 2001
@@ -196,7 +196,16 @@
 typedef unsigned char unchar;
 extern int iopl( int level );
 
+#ifndef __KERNEL__
+/* 2.4 needs __KERNEL__ defined for tqueue.h */
+#define __KERNEL__
+#include 
+#undef __KERNEL__
+#else
+#include 
+#endif
 
+#include 
 #include 
 #include 
 #include 
@@ -220,7 +229,7 @@
 
 #include 
 #include 
-#include 
+
 #include 
 
 #include "../drv/digi1.h"
@@ -240,15 +249,15 @@
 
 /* This is used to calculate the path to digiDload, for temp_name */
 
-#define DIRPATH "/etc/digiepca/"
+#define DIRPATH "/etc/digi/"
 
 /* C/X concentrator download image */
-char *cxcon_fname = "/etc/digiepca/cxcon.bin";
-char *epcxcon_fname = "/etc/digiepca/fxcon.bin";
+char *cxcon_fname = "/etc/digi/cxcon.bin";
+char *epcxcon_fname = "/etc/digi/fxcon.bin";
 
 /* C/X concentrator configuration */
-#define CXCONFIG "/etc/digiepca/cxconf.dat"
-#define EPCXCONFIG "/etc/digiepca/epcxconf.dat"
+#define CXCONFIG "/etc/digi/cxconf.dat"
+#define EPCXCONFIG "/etc/digi/epcxconf.dat"
 
 /* CX Concentrator configuration strings can be a maximum of 21 bytes long */
 #define CXCFGLEN 21
@@ -1119,7 +1128,7 @@
target_addr = fm->addr ;
temp_name = (char *)malloc((size_t)((strlen(fm->fname)) + strlen(DIRPATH))); 
*temp_name = 0; /* Make first character null; so strcat can work */
-   strcat(temp_name,"/etc/digiepca/");
+   strcat(temp_name,"/etc/digi/");
strcat(temp_name,fm->fname);
if (verbose) {
mess(0, 1, "Downloading %s to %lx on %s\n", temp_name, (long) 
fm->addr, btypes[di->info_bdtype].desc );
@@ -1953,6 +1962,10 @@
  * Given an channel number, return the corresponding device's pathname
  */
 char *chan_to_path( int channo ) {
+
+#ifdef CONFIG_DEVFS_FS
+   sprintf(dev_path,"/dev/digi/%d",channo);
+#else
char bankname;
int offset;
 
@@ -1960,7 +1973,7 @@
bankname = epca_banknames[ channo/NDEV_MAJOR ];
offset = channo % NDEV_MAJOR;
sprintf( dev_path, "%s%s%c%d", BASENAME, TTY_BASENAME, bankname, offset );
-
+#endif
return( dev_path );
 
 }
@@ -1972,6 +1985,10 @@
  * numbers.
  */
 void make_nodes( int first, int num, int make ) {
+
+#ifndef CONFIG_DEVFS_FS
+   /* Only do this if we're not using DEVFS. */
+
int major = 0, minor = 0;
int mode = 0666 | S_IFCHR;
int channo, ret;
@@ -2014,12 +2031,18 @@
}

}
+#endif
+
 }
 
 /* update_devs
  * unlink old and mkdev current device links
  */
 void update_devs() {
+
+#ifndef CONFIG_DEVFS_FS
+   /* Only do this if we're not using DEVFS. */
+
int crd, make;
// digiConfig creates nodes for the first 256 ports, others created here
//if( port_count > NDEV_MAJOR )
@@ -2040,6 +2063,7 @@
make_nodes( board[crd].digi_info.firstchan,
board[crd].digi_info.info_nports, make );
}
+#endif
 }
 
 void doargs( int ac, char *av[] ) {
@@ -2075,9 +2099,16 @@
 
doargs( argc, argv );
 
+
+#ifdef CONFIG_DEVFS_FS
+   if ((digiFD = open("/dev/digi/ctl", O_RDWR)) < 0 ) {
+   perror(" cannot open digi download device ");
+   }
+#else
if ((digiFD = open("/dev/digiCtl", O_RDWR)) < 0 ) {
perror(" cannot open digi download device ");
}
+#endif
 
if( init(digiFD) )
return( 1 );
diff -Naur epca-1.4.5-1/drv/Makefile epca-1.4.5.1-jim/drv/Makefile
--- epca-1.4.5-1/drv/Makefile   Wed Jun 28 15:10:15 2000
+++ epca-1.4.5.1-jim/drv/Makefile   Sun Mar 11 14:17:09 2001
@@ -1,5 +1,5 @@
 
-CFLAGS = -O2 -D__KERNEL__ -DMODULE -DLINUX -DKERNEL2_0 -Wall -I/usr/src/linux/include
+CFLAGS += -D__KERNEL__ -DMODULE -DLINUX -Wall -I/usr/src/linux/inc

Re: IDE on 2.4.2

[Martin Diehl]

On Fri, 9 Mar 2001, Lawrence MacIntyre wrote:

> Uniform MultiPlatform E-IDE driver Revision 6.31
> ide: assuminmg 33 MHz system bus speed for PIO modes: override with
> idebus=xx
> SIS5513: IDE controller on PCI bus 00 dev 09
> PCI: Assigned IRQ 14 for device 00:01.1
> SIS5513: chipset revision 208
> SIS5513: not 100% native mode: will probe irqs later
> SIS5597
> ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
> hda: Maxtor 90640D4, ATA DISK drive
> hdc: CD-ROM CDU55E, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> 
> At this point, the machine hangs...

interesting, I see the same thing except it hangs not before the disk
drives are initialized but afterwards, when initializing the CD-ROM
drives. (Compiling ide-cd as module permits successful boot but hangs
on insmod). This is with SiS5513 rev 208 IDE function from SiS5591
chipset with CONFIG_BLK_DEV_SIS5513 and autotune enabled (default).

For me, the workaround is disabling either one of the above (i.e. not
including SiS5513 support in the kernel or append'ing "hdx=noautotune"
for the cdrom-drives) and everything is fine again. You may want to use
hdparm to get udma2 working. Doing so provides relyable >14MB/s for a
5.4kRPM drive in UDMA(33), so my impression is this is only a tuning 
issue.

> PCI devices found:
>   Bus  0, device   0, function  0:
> Host bridge: Silicon Integrated Systems 5597/5598 Host (rev 2).
>   Medium devsel.  Master Capable.  Latency=32.  
>   Bus  0, device   1, function  0:
> ISA bridge: Silicon Integrated Systems 85C503 (rev 1).
>   Medium devsel.  Master Capable.  No bursts.  
>   Bus  0, device   1, function  1:
> IDE interface: Silicon Integrated Systems 85C5513 (rev 208).
>   Fast devsel.  IRQ 14.  Master Capable.  Latency=32.  
>   I/O at 0xe400 [0xe401].
>   I/O at 0xe000 [0xe001].
>   I/O at 0xd800 [0xd801].
>   I/O at 0xd400 [0xd401].
>   I/O at 0xd000 [0xd001].

I'm not absolutely sure, but I'm wondering why the driver enabled all
BAR's including the relocateable port areas which are useful in native
mode only. IMHO the driver should force compatibility mode. For me, only 
the last BAR containing the BM registers at 0xd000 is enabled.

Martin

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

NBD Fix (attempt #2)

[Steve Whitehouse]

Hi,

Below is a patch which I think fixes the NBD hangs properly. It works for
me and doesn't need any changes to ll_rw_blk.c like my last patch did. I've
shown it to Pavel Machek who has approved it. The patch is against 2.4.2-ac18.

Pavel: I've made the change you requested and also added a flag I forgot before.
Alan: Please apply this patch to your kernel tree.

If memory serves correctly the MSG_MORE flag only appeared in 2.4.2-ac and
isn't in the standard 2.4.2 kernel so I'll prepare a separate patch for
2.4.2 if there are no plans to merge the ZC patches for a while. Is there
a timescale for this or some criteria by which the ZC changes will be judged 
ready for merging ?

The one other change which might be required is a userland change. The
buffer size used for I/O by the nbd-server program is not large enough
in the case that a lot of buffers get merged into a single request, this
is easy to change though. If you get a message in your syslog on your
server machine complaining of a request thats too large, then this is 
what has happened,

Steve.

--

diff -r -u linux-2.4.2-ac18/drivers/block/nbd.c linux/drivers/block/nbd.c
--- linux-2.4.2-ac18/drivers/block/nbd.cSun Mar 11 21:35:14 2001
+++ linux/drivers/block/nbd.c   Sun Mar 11 20:18:36 2001
@@ -26,7 +26,6 @@
  *  structure with userland
  */
 
-#undef NBD_PLUGGABLE
 #define PARANOIA
 #include 
 
@@ -68,8 +67,6 @@
 static int requests_out;
 #endif
 
-static void nbd_plug_device(request_queue_t *q, kdev_t dev) { }
-
 static int nbd_open(struct inode *inode, struct file *file)
 {
int dev;
@@ -88,7 +85,7 @@
 /*
  *  Send or receive packet.
  */
-static int nbd_xmit(int send, struct socket *sock, char *buf, int size)
+static int nbd_xmit(int send, struct socket *sock, char *buf, int size, int msg_flags)
 {
mm_segment_t oldfs;
int result;
@@ -118,7 +115,7 @@
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_namelen = 0;
-   msg.msg_flags = 0;
+   msg.msg_flags = msg_flags | MSG_NOSIGNAL;
 
if (send)
result = sock_sendmsg(sock, &msg, size);
@@ -151,7 +148,7 @@
 {
int result;
struct nbd_request request;
-   unsigned long size = req->current_nr_sectors << 9;
+   unsigned long size = req->nr_sectors << 9;
 
DEBUG("NBD: sending control, ");
request.magic = htonl(NBD_REQUEST_MAGIC);
@@ -160,15 +157,19 @@
request.len = htonl(size);
memcpy(request.handle, &req, sizeof(req));
 
-   result = nbd_xmit(1, sock, (char *) &request, sizeof(request));
+   result = nbd_xmit(1, sock, (char *) &request, sizeof(request), req->cmd == 
+WRITE ? MSG_MORE : 0);
if (result <= 0)
FAIL("Sendmsg failed for control.");
 
if (req->cmd == WRITE) {
+   struct buffer_head *bh = req->bh;
DEBUG("data, ");
-   result = nbd_xmit(1, sock, req->buffer, size);
-   if (result <= 0)
-   FAIL("Send data failed.");
+   do {
+   result = nbd_xmit(1, sock, bh->b_data, bh->b_size, 
+bh->b_reqnext == NULL ? 0 : MSG_MORE);
+   if (result <= 0)
+   FAIL("Send data failed.");
+   bh = bh->b_reqnext;
+   } while(bh);
}
return;
 
@@ -186,7 +187,7 @@
 
DEBUG("reading control, ");
reply.magic = 0;
-   result = nbd_xmit(0, lo->sock, (char *) &reply, sizeof(reply));
+   result = nbd_xmit(0, lo->sock, (char *) &reply, sizeof(reply), MSG_WAITALL);
if (result <= 0)
HARDFAIL("Recv control failed.");
memcpy(&xreq, reply.handle, sizeof(xreq));
@@ -201,10 +202,14 @@
if (ntohl(reply.error))
FAIL("Other side returned error.");
if (req->cmd == READ) {
+   struct buffer_head *bh = req->bh;
DEBUG("data, ");
-   result = nbd_xmit(0, lo->sock, req->buffer, req->current_nr_sectors << 
9);
-   if (result <= 0)
-   HARDFAIL("Recv data failed.");
+   do {
+   result = nbd_xmit(0, lo->sock, bh->b_data, bh->b_size, 
+MSG_WAITALL);
+   if (result <= 0)
+   HARDFAIL("Recv data failed.");
+   bh = bh->b_reqnext;
+   } while(bh);
}
DEBUG("done.\n");
return req;
@@ -218,7 +223,6 @@
 void nbd_do_it(struct nbd_device *lo)
 {
struct request *req;
-   int dequeued;
 
down (&lo->queue_lock);
while (1) {
@@ -246,11 +250,9 @@
list_del(&req->queue);
up (&lo->queue_lock);

-   dequeued = nbd_end_request(req);
+   nbd_end_request(re

porting to linux kernel 2.4

[Lee Ho]

Hi,

I wrote brief document describing porting 2.2 device driver to 2.4
It contains changes from 2.2 to 2.4 including devfs, /proc, block device
driver, etc.
I'm not a kernel hacker, so there may be errors due to my
misunderstanding.
I'd be grateful if anyone points out and corrects the errors, and my
poor english if possible :-).
And I'd be very grateful if anyone appends more explanation,
and complements it by supplementing what I omitted.
I will greately appreciate any message about this.

http://linuxkernel.to/module/port-2.4/eng/

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Lee, Ho. Software Engineer, Embedded Linux Dep, LinuxOne
Mail : [EMAIL PROTECTED] (work), [EMAIL PROTECTED] (personal)
Homepage : http://flyduck.com, http://linuxkernel.to


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

Re: HP Vectra XU 5/90 interrupt problems

[Gérard Roudier]

On Sun, 11 Mar 2001, John William wrote:

> If shared, edge triggered interrupts are ok then I will talk to the driver 
> maintainers about the problem. If this isn't ok, then maybe the sanity check 
> in pci-irq.c would be to force level triggering only on shared PCI 
> interrupts?

DEFINITELY NO!

Given a PCI device + driver pair, level triggerred interrupt may be 
required for them to work properly, even when the line is not shared.
Anyway, it is a requirement. OTOH, the PCI device must know how to 
trigger the interrupt.

Edge triggerred interrupts cannot be shared. Level triggerred (level
sensitive is a better wording, in my opinion) can be shared.

Even when it is not shared (as it is required), an edge triggerred
interrupt can be lost by the driver. Using level sensitive interrupt let
the interrupt condition active as long as the condition is present at, at
least, one device that wants to interrupt the CPU.

Apart sharing of interrupt lines, level sensitive interrupt allows the
device firmware to run concurrently to the CPU (software driver) without
losing interrupt condition, providing that both driver and firmware use
appropriate barriers against buffering in the bridge.
In the same situation, using edge triggerred interrupt (not shared) can
lead to interrupt condition being lost by the software driver.

  Gérard.

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

[PATCH] Correct module count in do_mount()

[JörgenCederlöf]

If do_mount() fails in the wrong place, the filesystem module count
is incremented twice, but decremented only once.

This patch agains 2.4.2 fixes the problem.

   Jörgen


--- fs/super.c.orig Sun Mar 11 20:25:26 2001
+++ fs/super.c  Sun Mar 11 20:05:27 2001
@@ -1414,6 +1414,8 @@
 fail:
if (list_empty(&sb->s_mounts))
kill_super(sb, 0);
+   else
+   put_filesystem(fstype);
goto unlock_out;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sys_sched_yield fast path

[Dave Zarzycki]

On Mon, 12 Mar 2001, Anton Blanchard wrote:

> Perhaps we need something like sched_yield that takes off some of
> tsk->counter so the task with the spinlock will run earlier.

Personally speaking, I wish sched_yield() API was like so:

int sched_yield(pid_t pid);

The pid argument would be advisory, of course, the kernel doesn't have to
honor it.

This would allow the thread wanting to acquire the spinlock to yield
specifically to the thread holding the lock (assuming the pid of the lock
holder was stored in the spinlock...) In fact, the the original lock owner
could in theory yield back to the threading wanting to acquire the lock.

Feedback from the scheduling gurus would be appreciated.

Thanks,

davez

-- 
Dave Zarzycki
http://thor.sbay.org/~dave/


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

Re: HP Vectra XU 5/90 interrupt problems

[Alan Cox]

> maintainers about the problem. If this isn't ok, then maybe the sanity check 
> in pci-irq.c would be to force level triggering only on shared PCI 
> interrupts?

This seems a sensible path to take for such machines

> I'm going down this path because I can't see a good way to check for the 
> presence of a valid ELCR, so I'm hoping a PCI IRQ sanity check would fix my 
> problem (but someone please correct me if I'm wrong). Are SMP standard type 
> #5 machines (ISA/PCI) or just the Vectra's so rare that I'm the only one 
> having this problem? Or am I the only one to try putting a PCI card in one 
> of it's two slots... :-)

HP/XU boxes have a history of weird (and sometimes invalid) MP tables. In this
case its not clear to me whether HP or the kernel is right (or indeed if both
are right and the standard doesnt help)

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

Re: HP Vectra XU 5/90 interrupt problems

[John William]

>From: Alan Cox <[EMAIL PROTECTED]>
>
> > So PCI interrupts must always be level triggered? If so, then the kernel
> > should never program the IO APIC to use an edge triggered interrupt on a 
>PCI
> > device. If that's true, then why not force the interrupt type to level
> > triggered for all PCI devices (to work around a potentially broken MP
> > table)?
>
>Its not that simple. Its common to edge trigger some of the built in 
>devices
>like IDE controllers.

Ok, I guess I'm a little confused again. My SCSI controller hangs when the 
interrupt it shares with the network card is configured as edge triggered. 
When I force the interrupt to be level triggered, everything works fine. 
Does this sound like a problem in one of the two drivers (unable to share an 
edge triggered interrupt) or is it a no-no to set up a shared PCI interrupt 
as edge triggered?

If shared, edge triggered interrupts are ok then I will talk to the driver 
maintainers about the problem. If this isn't ok, then maybe the sanity check 
in pci-irq.c would be to force level triggering only on shared PCI 
interrupts?

I'm going down this path because I can't see a good way to check for the 
presence of a valid ELCR, so I'm hoping a PCI IRQ sanity check would fix my 
problem (but someone please correct me if I'm wrong). Are SMP standard type 
#5 machines (ISA/PCI) or just the Vectra's so rare that I'm the only one 
having this problem? Or am I the only one to try putting a PCI card in one 
of it's two slots... :-)

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

[patch] Simple serial fix for idiots at the lilo prompt.

[Roger Gammans]

Hi

If you don't pay attention (yeah, I know) Its easy to write
kernel commond lines like 'console=ttyS0, console=.., etc'

The lack of a baud rate after the comma causes the kernel
to panic. The patch below will cause the kernel in treat the
non-existant baud rate specifier as the default without panicing.


--- ../linux-2.2+lvm/drivers/char/serial.c  Sat Jun 10 16:04:13 2000
+++ drivers/char/serial.c   Sun Mar 11 17:51:02 2001
@@ -3490,6 +3490,10 @@
case 9600:
default:
cflag |= B9600;
+   /*
+* Set this to a sane value to prevent a divide error
+*/
+   baud  = 9600;
break;
}
switch(bits) {

TTFN
-- 
Roger
 Think of the mess on the carpet. Sensible people do all their
 demon-summoning in the garage, which you can just hose down afterwards.
-- [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/

Bug in 2.4.2

[Gregory McLean]

I'm not sure exactly what happened to the machine as I was at work at the
time when it died I had just sshed in to read my daily spam box ;)

Here is the decoded captured oops (klogd provided):

Mar 11 09:36:33 tweetie kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0004
Mar 11 09:36:33 tweetie kernel:  printing eip:
Mar 11 09:36:33 tweetie kernel: c0132551
Mar 11 09:36:33 tweetie kernel: *pde = 
Mar 11 09:36:33 tweetie kernel: Oops: 0002
Mar 11 09:36:33 tweetie kernel: CPU:0
Mar 11 09:36:33 tweetie kernel: EIP:0010:[__remove_inode_queue+17/32]
Mar 11 09:36:33 tweetie kernel: EFLAGS: 00010286
Mar 11 09:36:33 tweetie kernel: eax:    ebx: c1656c20   ecx:
   edx: 
Mar 11 09:36:33 tweetie kernel: esi: c1656c20   edi: c1656c20   ebp:
   esp: c147bf64
Mar 11 09:36:33 tweetie kernel: ds: 0018   es: 0018   ss: 0018
Mar 11 09:36:33 tweetie kernel: Process bdflush (pid: 5,
stackpage=c147b000)
Mar 11 09:36:33 tweetie kernel: Stack: c0134a39 c1656c20 0003 0207
c10c6180 019b c012b5d3 
Mar 11 09:36:33 tweetie kernel:c130c074  0007 c012af77
c130c074   0004
Mar 11 09:36:33 tweetie kernel: 00f1 6492 
c147a000  0007 
Mar 11 09:36:33 tweetie kernel: Call Trace: [try_to_free_buffers+105/368]
[free_shortage+35/208] [page_launder+871/2208] [bdflush+155/224]
[empty_bad_page+0/4096] [empty_bad_page+0/4096] [kernel_thread+38/48]
Mar 11 09:36:33 tweetie kernel:[bdflush+0/224]
Mar 11 09:36:33 tweetie kernel:
Mar 11 09:36:33 tweetie kernel: Code: 89 50 04 89 02 c3 89 f6 8d bc 27 00
00 00 00 8b 54 24 04 31
Mar 11 09:36:34 tweetie kernel: kernel BUG at exit.c:458!
Mar 11 09:36:34 tweetie kernel: invalid operand: 
Mar 11 09:36:34 tweetie kernel: CPU:0
Mar 11 09:36:34 tweetie kernel: EIP:0010:[do_exit+518/528]
Mar 11 09:36:34 tweetie kernel: EFLAGS: 00010286
Mar 11 09:36:34 tweetie kernel: eax: 001a   ebx:    ecx:
   edx: 
Mar 11 09:36:34 tweetie kernel: esi: c147a000   edi: 000b   ebp:
c0132551   esp: c147be50
Mar 11 09:36:34 tweetie kernel: ds: 0018   es: 0018   ss: 0018
Mar 11 09:36:34 tweetie kernel: Process bdflush (pid: 5,
stackpage=c147b000)
Mar 11 09:36:34 tweetie kernel: Stack: c025c385 c025c49c 01ca c0132551
c010942a c02544c1 c025460d c147bf30
Mar 11 09:36:34 tweetie kernel:0002 0004 c0112c47 000b
c147bf30 0002 0001 c147a000


>From here the machine was unresponsive, powercycle fixed it up.

modules in use:
lsmod
Module  Size  Used by
tuner   4192   1  (autoclean)
tvaudio 8208   0  (autoclean) (unused)
bttv   58512   0  (autoclean)
i2c-algo-bit7232   1  (autoclean) [bttv]
i2c-core   13232   0  (autoclean) [tuner tvaudio bttv
i2c-algo-bit]
tun 3152   2  (autoclean)
3c509   6992   1  (autoclean)
reiserfs  156464   5  (autoclean)
opl3   11728   0  (unused)
sb  7456   0
sb_lib 34128   0  [sb]
uart401 6384   0  [sb_lib]
sound  57728   0  [opl3 sb_lib uart401]
lvm-mod39392   5  (autoclean)
mousedev4096   1
hid11664   0  (unused)
input   3392   0  [mousedev hid]
usb-uhci   21856   0  (unused)

Hardware installed:
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
(rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:10.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 11)
00:10.1 Multimedia controller: Brooktree Corporation Bt878 (rev 11)
00:11.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04)
00:12.0 SCSI storage controller: Adaptec AIC-7860 (rev 01)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 11)

And two ISA cards:

Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: Creative ViBRA16X PnP detected
sb: ISAPnP reports 'Creative ViBRA16X PnP' at i/o 0x220, irq 7, dma 1, 3
SB 4.16 detected OK (220)

eth0: 3c509 at 0x330, 10baseT port, address  00 20 af 6d e6 2f, IRQ 3.
3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED]
eth0: Setting Rx mode to 1 addresses.

Installed drives (since it appears bdflush triggered this)
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will p

Re: Microsoft begining to open source Windows 2000?

[Mark H. Wood]

On 9 Mar 2001, Kai Henningsen wrote:
[snip]
> And remember that other companies have been doing similar things since  
> just about forever. It's not as if MS invented this thing.
> 
> Or maybe I have to take that back. The "must not modify" clause certainly  
> seems non-standard.
> 
> AT&T Unix source didn't carry a "must not modify" rider.
> 
> IBM's big iron OS source certainly didn't carry a "must not modify" rider.
> 
> In fact, making modifications was very much the *point* of this excercise.

Indeed, Digital LCG used to publish our bug reports verbatim, including
patches if we supplied 'em, and thank us for the help.  (In fact, VMS
Engineering took heat for publishing "sanitized" reports instead of
photocopying the SPR forms as LCG had.)

MS' approach reminds me of what the fellow said about Lotho
Sackville-Baggins:

Seems he wanted to own everything himself, and then order folk
about.

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
Make a good day.

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

No Subject

[Martin Bruchanov]

Bug report from Martin Bruchanov ([EMAIL PROTECTED], [EMAIL PROTECTED])


[1.] One line summary of the problem:
USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.


[2.] Full description of the problem/report:
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=18 (error=-110)
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=20 (error=-110)
This message was echoed, when i plug-in SMP device Wacom Graphire or
keyboard to USB plug. I test it with three identicals kernel, only
difference was in "Processor type and features".
There was USB non-functional  with Symmetric multi-processing support
was US on fistr kernel.
Second kernel without SMP correctly detect the USB device and without
APIC.
Third kernel with APIC and IO-APIC support on uniprocessors was not
detect USB device.


[3.] Keywords (i.e., modules, networking, kernel):
modules, USB


[4.] Kernel version (from /proc/version):
2.4.2


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)


[6.] A small shell script or example program which triggers the
 problem (if possible)

[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 859.113
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse
bogomips: 1710.48

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 859.113
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 3
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse
bogomips: 1717.04


[7.3.] Module information (from /proc/modules):
evdev   3712   0 (unused)
mousedev4288   0 (unused)
wacom   3344   0 (unused)
input   3680   0 [evdev mousedev wacom]
usb-uhci   23248   0 (unused)
usbcore53776   2 [wacom usb-uhci]



[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
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]
9000-900f : VIA Technologies, Inc. Bus Master IDE
9400-941f : VIA Technologies, Inc. UHCI USB
  9400-941f : usb-uhci
9800-981f : VIA Technologies, Inc. UHCI USB (#2)
  9800-981f : usb-uhci
9c00-9cff : VIA Technologies, Inc. AC97 Audio Controller
a000-a003 : VIA Technologies, Inc. AC97 Audio Controller
a400-a403 : VIA Technologies, Inc. AC97 Audio Controller
ac00-ac07 : Promise Technology, Inc. 20265
b000-b003 : Promise Technology, Inc. 20265
b400-b407 : Promise Technology, Inc. 20265
b800-b803 : Promise Technology, Inc. 20265
bc00-bc3f : Promise Technology, Inc. 20265
c000-c0ff : Realtek Semiconductor Co., Ltd. RTL-8139
  c000-c0ff : eth0


[7.5.] PCI information ('lspci -vvv' as root)

00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
Control: I/O-

Re: Kernel 2.4.1 on RHL 6.2

[Chris Andrews]

> >Make sure you have the following symlinks in your /usr/include 
> >directory, assuming you're on an x86 machine: 
> > 
> >asm -> /usr/src/linux/include/asm-i386/ 
> >linux -> /usr/src/linux/include/linux/ 
>
> Note! You only have to have those symlinks on broken systems such 
> as Redhat. 
>
> Sane systems such as Debian have a copy of the kernel header files 
> that the C library was compiled against in /usr/include/{linux,asm} 
> instead of symlinks to the kernel source. Do not play the symlink 
> trick on those systems. 
>
> Before this turns into a flamewar: this has been discussed 20 or 
> so times before, and both Linus and the glibc developers agree 
> that you a distribution should do the latter. The headers you use 
> to compile userland binaries should be the same as the C library 
> was compiled against. 

I've been following this advice for some time, but doing so tripped me up.
My system is RH 6.2, but with kernel 2.4 (and latest modutils etc). I
kept my kernel headers at 2.2.14, i.e. those supplied with the 6.2
kernel-headers RPM.

This breaks XFree 86 4, however, which checks the kernel version you are
*running* and then expects the headers for that kernel to be available. To
build X I had to move the symlink to point at some 2.4 headers so X could
find (IIRC) input.h, and others. 

So what's at fault here? X for looking at the current kernel, me for not
telling X not to do that, or me again for not recompiling glibc and using
the new headers 'legally'?

Chris.

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

[patch] nmi-watchdog-2.4.2-A2

[Ingo Molnar]

On Sun, 11 Mar 2001, Andrew Morton wrote:

> Sorry, this doesn't look right. Are you sure you booted with
> `nmi_watchdog=1'? It was turned off by default in -ac18.

of course i did ...

> Two things:
>
> - CPU A could be doing the SYSRQ printing, while
>   CPU B is spinning on a lock which CPU A holds. The
>   NMI watchdog will then whack CPU B.  So touch_nmi_watchdog()
>   needs to touch *all* CPUs.  (kbd_controller_lock, for example).

yep, agreed.

> - We need to touch the NMI more than once during the
>   SYSRQ-T output - five seconds isn't enough.
>
>   The correctest way is, I think, to touch_nmi() in
>   rs285_console_write(), lp_console_write() and
>   serial_console_write().

nope:

>   We _could_ just touch it in show_state(), but that means
>   we still get whacked if we do a lot of printk()s with interrupts
>   disabled from some random place in the kernel.

exactly, and that is a feature. We want to find all those places, because
disabling IRQs for too long can cause problems in unrelated kernel code.
SysRq-T is a special case so touch_nmi() is justified in that and only
that case. The NMI watchdog is something that gives security, and we want
to be very conservative disabling its effect.

[i've attached nmi-watchdog-2.4.2-A2 (against -ac18) which adds your fix
to clear all alert counters in touch_nmi_watchdog().]

Ingo


--- linux/kernel/sched.c.orig   Sun Mar 11 11:49:00 2001
+++ linux/kernel/sched.cSun Mar 11 11:51:37 2001
@@ -1183,8 +1183,14 @@
printk("  task PCstack   pid father child younger 
older\n");
 #endif
read_lock(&tasklist_lock);
-   for_each_task(p)
+   for_each_task(p) {
+   /*
+* reset the NMI-timeout, listing all files on a slow
+* console might take alot of time:
+*/
+   touch_nmi_watchdog();
show_task(p);
+   }
read_unlock(&tasklist_lock);
 }
 
--- linux/include/linux/irq.h.orig  Sun Mar 11 11:20:21 2001
+++ linux/include/linux/irq.h   Sun Mar 11 12:02:23 2001
@@ -57,18 +57,16 @@
 #include  /* the arch dependent stuff */
 
 /**
- * nmi_watchdog_disable - disable NMI watchdog checking.
+ * touch_nmi_watchdog - restart NMI watchdog timeout.
  * 
- * If the architecture supports the NMI watchdog, nmi_watchdog_disable() may be used
- * to temporarily disable it.  Use nmi_watchdog_enable() later on.  It is implemented
- * via an up/down counter, so you must keep the calls balanced.
+ * If the architecture supports the NMI watchdog, touch_nmi_watchdog()
+ * may be used to reset the timeout - for code which intentionally
+ * disables interrupts for a long time. This call is stateless.
  */
 #ifdef ARCH_HAS_NMI_WATCHDOG
-extern void nmi_watchdog_disable(void);
-extern void nmi_watchdog_enable(void);
+extern void touch_nmi_watchdog(void);
 #else
-#define nmi_watchdog_disable() do{} while(0)
-#define nmi_watchdog_enable() do{} while(0)
+# define touch_nmi_watchdog() do { } while(0)
 #endif
 
 extern int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *);
--- linux/drivers/char/sysrq.c.orig Sun Mar 11 11:30:46 2001
+++ linux/drivers/char/sysrq.c  Sun Mar 11 11:49:19 2001
@@ -70,11 +70,6 @@
if (!key)
return;
 
-   /*
-* Interrupts are disabled, and serial consoles are slow. So
-* Let's suspend the NMI watchdog.
-*/
-   nmi_watchdog_disable();
console_loglevel = 7;
printk(KERN_INFO "SysRq: ");
switch (key) {
@@ -158,7 +153,6 @@
/* Don't use 'A' as it's handled specially on the Sparc */
}
 
-   nmi_watchdog_enable();
console_loglevel = orig_log_level;
 }
 
--- linux/arch/i386/kernel/nmi.c.orig   Sun Mar 11 11:24:34 2001
+++ linux/arch/i386/kernel/nmi.cSun Mar 11 17:57:41 2001
@@ -226,37 +226,40 @@
 }
 
 static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-static atomic_t nmi_watchdog_disabled = ATOMIC_INIT(0);
 
-void nmi_watchdog_disable(void)
-{
-   atomic_inc(&nmi_watchdog_disabled);
-}
+/*
+ * the best way to detect wether a CPU has a 'hard lockup' problem
+ * is to check it's local APIC timer IRQ counts. If they are not
+ * changing then that CPU has some problem.
+ *
+ * as these watchdog NMI IRQs are generated on every CPU, we only
+ * have to check the current processor.
+ *
+ * since NMIs dont listen to _any_ locks, we have to be extremely
+ * careful not to rely on unsafe variables. The printk might lock
+ * up though, so we have to break up any console locks first ...
+ * [when there will be more tty-related locks, break them up
+ *  here too!]
+ */
+
+static unsigned int
+   last_irq_sums [NR_CPUS],
+   alert_counter [NR_CPUS];
 
-void nmi_watchdog_enable(void)
+void touch_nmi_watchdog (void)
 {
-   atomic_dec(&nmi_watchdog_disabled);
-}
+  

Re: List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.

[Keith Owens]

On Sun, 11 Mar 2001 06:37:10 -0700, 
Steven Cole <[EMAIL PROTECTED]> wrote:
>On Sunday 11 March 2001 00:08, Jeff Garzik wrote:
>> Keith Owens wrote:
>> > If any of these CONFIG_ options are always derived (i.e. the user never
>> > sees them on a config menu) then please add the suffix _DERIVED to such
>> > options.
>
>BTW, the script I used (originally written by Paul Gortmaker), does pass the
>lines in [C,c]onfig.in through grep -v define_ to catch items which are defined
>with define_bool or define_int.

Several options are define_bool in one config.in but are options in
another.  I am working on a global patch to rename all derived options.
It will be big.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]: allow notsc option for buggy cpus

[Alan Cox]

> But is there a reason we don't allow the notsc option at all on
> certain chipsets? Who would complain if I removed the CONFIG_X86_TSC
> option from the CONFIG_M686 definition or even got rid of it completely?

I believe someone had performance reasons. I'm sceptical and I'd tend to agree
with your view. Bug Ingo see what he says

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]: allow notsc option for buggy cpus

[Anton Blanchard]

 
> Intel are being remarkably reluctant on the documentation front.  We have
> the AMD speed change docs, but the intel ones (chipset not cpu based
> primarily) don't seem to be publically available. In fact the 815M manual
> looks like someone quite pointedly went through and removed the relevant
> material before publication

But is there a reason we don't allow the notsc option at all on
certain chipsets? Who would complain if I removed the CONFIG_X86_TSC
option from the CONFIG_M686 definition or even got rid of it completely?

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

Re: HP Vectra XU 5/90 interrupt problems

[Alan Cox]

> So PCI interrupts must always be level triggered? If so, then the kernel 
> should never program the IO APIC to use an edge triggered interrupt on a PCI 
> device. If that's true, then why not force the interrupt type to level 
> triggered for all PCI devices (to work around a potentially broken MP 
> table)?

Its not that simple. Its common to edge trigger some of the built in devices
like IDE controllers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: RTL8029 stops working after being flood pinged

[Alan Cox]

> [1.] One line summary of the problem:
>  RTL8029 based card stops receiving data after being flood pinged

This is probably the apparent hardware problem in the Intel APIC. There is
a workaround for it in 2.4.2-ac

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

Re: 2.4.3pre1: kernel BUG at page_alloc.c:73!

[Alan Cox]

> Well, the kernel module is open source..

No the Nvidia kernel module is not. Try reading it, its obfuscated to point
of being binary, it contains no permission to modify or redistribute either.

In fact if you are using patched versions of it to make it work with later
kernels you may well be breaking their licensing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sys_sched_yield fast path

[Anton Blanchard]

 
> This is the linux thread spinlock acquire :
> 
> 
> static void __pthread_acquire(int * spinlock)
> {
>   int cnt = 0;
>   struct timespec tm;
> 
>   while (testandset(spinlock)) {
> if (cnt < MAX_SPIN_COUNT) {
>   sched_yield();
>   cnt++;
> } else {
>   tm.tv_sec = 0;
>   tm.tv_nsec = SPIN_SLEEP_DURATION;
>   nanosleep(&tm, NULL);
>   cnt = 0;
> }
>   }
> }
> 
> 
> Yes, it calls sched_yield() but this is not a std wait for mutex but for
> spinlocks that are hold a very short time.  Real wait are implemented using
> signals.  More, with the new implementation of sys_sched_yield() the task
> release all its time quantum so, even in a case where a task repeatedly calls
> sched_yield() the call rate is not so high if there is at least one process
> to spin.  And if there isn't one task with goodness() > 0, nobody cares about
> sched_yield() performance.

The problem I found with sched_yield is that things break down with high
levels of contention. If you have 3 processes and one has a lock then
the other two can ping pong doing sched_yield() until their priority drops
below the process with the lock. eg in a run I just did then where 2
has the lock:

1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
2

Perhaps we need something like sched_yield that takes off some of 
tsk->counter so the task with the spinlock will run earlier.

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

[PATCH] /drivers/char/cyclades.c: panic() call removal

[Andrey Panin]

Hi all,

this patch removes panic() calls and adds MODULE_DEVICE_TABLE to cyclades driver.

Best regards.

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc

--- /linux/drivers/char/cyclades.c.orig Sun Mar 11 19:50:00 2001
+++ /linux/drivers/char/cyclades.c  Sun Mar 11 20:09:08 2001
@@ -866,17 +866,21 @@
 static unsigned short  cy_isa_nboard;
 static unsigned short  cy_nboard;
 #ifdef CONFIG_PCI
-static unsigned short  cy_pci_dev_id[] = {
-   PCI_DEVICE_ID_CYCLOM_Y_Lo,  /* PCI < 1Mb */
-   PCI_DEVICE_ID_CYCLOM_Y_Hi,  /* PCI > 1Mb */
-   PCI_DEVICE_ID_CYCLOM_4Y_Lo, /* 4Y PCI < 1Mb */
-   PCI_DEVICE_ID_CYCLOM_4Y_Hi, /* 4Y PCI > 1Mb */
-   PCI_DEVICE_ID_CYCLOM_8Y_Lo, /* 8Y PCI < 1Mb */
-   PCI_DEVICE_ID_CYCLOM_8Y_Hi, /* 8Y PCI > 1Mb */
-   PCI_DEVICE_ID_CYCLOM_Z_Lo,  /* Z PCI < 1Mb */
-   PCI_DEVICE_ID_CYCLOM_Z_Hi,  /* Z PCI > 1Mb */
-   0   /* end of table */
-   };
+#define CYCLADES_DEVICE(x) { PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_##x##, 
+PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }
+
+static struct pci_device_id cy_pci_dev_id[] = {
+   CYCLADES_DEVICE(Y_Lo),  /* PCI < 1Mb */
+   CYCLADES_DEVICE(Y_Hi),  /* PCI > 1Mb */
+   CYCLADES_DEVICE(4Y_Lo), /* 4Y PCI < 1Mb */
+   CYCLADES_DEVICE(4Y_Hi), /* 4Y PCI > 1Mb */
+   CYCLADES_DEVICE(8Y_Lo), /* 8Y PCI < 1Mb */
+   CYCLADES_DEVICE(8Y_Hi), /* 8Y PCI > 1Mb */
+   CYCLADES_DEVICE(Z_Lo),  /* Z PCI < 1Mb */
+   CYCLADES_DEVICE(Z_Hi),  /* Z PCI > 1Mb */
+   { 0, }  /* end of table */
+};
+
+MODULE_DEVICE_TABLE(pci, cy_pci_dev_id);
 #endif
 
 static void cy_start(struct tty_struct *);
@@ -4970,7 +4974,7 @@
 
 for (i = 0; i < NR_CARDS; i++) {
 /* look for a Cyclades card by vendor and device id */
-while((device_id = cy_pci_dev_id[dev_index]) != 0) {
+while((device_id = cy_pci_dev_id[dev_index].device) != 0) {
 if((pdev = pci_find_device(PCI_VENDOR_ID_CYCLADES,
 device_id, pdev)) == NULL) {
 dev_index++;/* try next device id */
@@ -5478,6 +5482,15 @@
 extra ports are ignored.
  */
 
+static void __init cy_cleanup_after_failure(struct tty_driver *tty)
+{
+   unsigned long flags;
+   save_flags(flags); cli();
+   remove_bh(CYCLADES_BH);
+   if (tty) tty_unregister_driver(tty);
+   restore_flags(flags);
+}
+
 int __init
 cy_init(void)
 {
@@ -5544,10 +5557,16 @@
 cy_callout_driver.proc_entry = 0;
 
 
-if (tty_register_driver(&cy_serial_driver))
-panic("Couldn't register Cyclades serial driver\n");
-if (tty_register_driver(&cy_callout_driver))
-panic("Couldn't register Cyclades callout driver\n");
+if ((i = tty_register_driver(&cy_serial_driver))) {
+   printk(KERN_ERR "cyclades: Couldn't register Cyclades serial driver\n");
+   cy_cleanup_after_failure(NULL);
+   return i;
+}
+if ((i = tty_register_driver(&cy_callout_driver))) {
+   printk(KERN_ERR "cyclades: Couldn't register Cyclades callout driver\n");
+   cy_cleanup_after_failure(&cy_serial_driver);
+   return i;
+}
 
 for (i = 0; i < NR_CARDS; i++) {
 /* base_addr=0 indicates board not found */

 PGP signature

Re: List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.

[Steven Cole]

On Sunday 11 March 2001 00:08, Jeff Garzik wrote:
> Keith Owens wrote:
> > On Sat, 10 Mar 2001 23:03:19 -0700,
> >
> > Steven Cole <[EMAIL PROTECTED]> wrote:
> > >With the 2.4.0 kernel, there were 476 CONFIG options which had
> > >no help entry in Configure.help.  With 2.4.2-ac18, this number is now
> > > 547, which has been kept this low with 54 options getting
> > > Configure.help text.
> >
> > If any of these CONFIG_ options are always derived (i.e. the user never
> > sees them on a config menu) then please add the suffix _DERIVED to such
> > options.  They still need to start with CONFIG_ to suit the kernel
> > build dependency generator so we cannot change the start of the name.
> > Appending _DERIVED will make it obvious that the options require no
> > help text.
>
> Yow.  That is very cumbersome.  Can't you just keep a list somewhere,
> instead of making such options longer?

BTW, the script I used (originally written by Paul Gortmaker), does pass the
lines in [C,c]onfig.in through grep -v define_ to catch items which are defined
with define_bool or define_int.  Here is a short list of new CONFIG_ items which
got filtered out:

CONFIG_ARCH_S390X
CONFIG_CRIS_LOW_MAP
CONFIG_FBCON_STI
CONFIG_FUSION_BOOT
CONFIG_IP_NF_NAT_FTP
CONFIG_MTD_AMDSTD
CONFIG_PARISC32
CONFIG_SPARC32
CONFIG_SPARC64
CONFIG_TQM8xxL

As far as appending _DERIVED is concerned, I like the idea, but there might be
quite a time where it was only partially implemented, just confusing things.  Unless
those CONFIG_XXX_DERIVED items all got renamed at once like the great redo
300+ Makefiles adventure last fall.

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

Re: sys_sched_yield fast path

[Davide Libenzi]

On 10-Mar-2001 Andi Kleen wrote:
> Davide Libenzi <[EMAIL PROTECTED]> writes:
> 
> 
>> Probably the rate at which is called sys_sched_yield() is not so high to let
>> the performance improvement to be measurable.
> 
> LinuxThreads mutexes call sched_yield() when a lock is locked, so when you 
> have a  multithreaded program with some lock contention it'll be called a
> lot.

This is the linux thread spinlock acquire :


static void __pthread_acquire(int * spinlock)
{
  int cnt = 0;
  struct timespec tm;

  while (testandset(spinlock)) {
if (cnt < MAX_SPIN_COUNT) {
  sched_yield();
  cnt++;
} else {
  tm.tv_sec = 0;
  tm.tv_nsec = SPIN_SLEEP_DURATION;
  nanosleep(&tm, NULL);
  cnt = 0;
}
  }
}


Yes, it calls sched_yield() but this is not a std wait for mutex but for
spinlocks that are hold a very short time.
Real wait are implemented using signals.
More, with the new implementation of sys_sched_yield() the task release all its
time quantum so, even in a case where a task repeatedly calls sched_yield() the
call rate is not so high if there is at least one process to spin.
And if there isn't one task with goodness() > 0, nobody cares about
sched_yield() performance.




- Davide

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

Re: pci_id's

[Andrey Panin]

On Sun, Mar 11, 2001 at 01:26:23PM +0200, ivor wrote:
> Hi
> 
> Please could someone help me id the following host and pci bridges, they
> don't appear in kernel 2.4.0.
> 

Where these strange numbers come from ?
Only guesses after this line:

> Host Bridge
> PCI_0600_1106__3050__30-0-0

1106 - VIA Technologies, Inc.
3050 - VIA ACPI controller.

> PCI_0600_8086_1043_1130_8028_02-0-0

?

> PCI_0600_8086_1028_2500_0095_03-0-0

8086 - Intel Corporation.
2500 - 82820 820 (Camino) Chipset Host Bridge (MCH).

> PCI Bridge
> PCI_0604_1106_1106_8391__00-0-0

8391 - VT8371 [KX133 AGP]

> PCI_0604_8086__1131__02-0-0

?

> PCI_0604_8086__244e__01-0-0

244e - 82820 820 (Camino 2) Chipset PCI.

Best regards.

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
 PGP signature

Kernel panic in 2.2.18 and SMP

[Ricardo Galli]

I just upgraded from 2.2.16 to 2.2.18 in a production machine. The machine
dies after few minutes with the following error message (it's not complete,
the machine was rebooted by a colleague of mine):


Kernel panic
Exception.
Context corruption at bank 0

The motherboard is a RD440LX DP, with adapted 2940, 3com905, mtrr enabled,
ioapic enabled.
We've tried several times with the same kernel and we've got the same
problem after a couple of minutes. Sometimes the machine was completely
blocked, even ping didn't work, others ping was ok but everythng else was
down. Sysrq couldn't sync nor unmount disks.

We went down to 2.2.16 and everything it's ok.

Hope this helps.

Regards,

--ricardo
http://m3d.uib.es/~gallir/

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

Oops in __mark_inode_dirty (2.4.2-pre3)

[Michael Mueller]

Hi,

had an Oops in __mark_inode_dirty running kernel 2.4.2-pre3 on i386 UP
(actually a PII-300). It did happen during the daily cron job. Currently
on proc, devpts and ext2 filesystems are used no nfs and the like. The
system is still running. So if you need further information mail me or
come on #kernelnewbies (my nick is malware). 


Michael

So Here is the Oops:

printing eip:
c0140770
*pde = 
Oops: 0002
CPU:0
EIP:0010:[__mark_inode_dirty+92/112]
EFLAGS: 00010202
eax:    ebx: cc85b240   ecx: cc85b428   edx: cc85b248
esi: c15dc200   edi: 0001   ebp: c361dfa4   esp: c361df24
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 2962, stackpage=c361d000)
Stack: c361c000  cc86bce0 c0141660 cc85b240 0001 c0138d09
cc85b240
   c2bbf000  c361dfa4 bc24 0001 bc24 c013823a
0009
   cc86bce0 c2bbf01b 000b ef164d83 c01391dc c2bbf026 c361dfa4
c361dfa4
Call Trace: [update_atime+68/84] [path_walk+1701/1980] [getname+90/152]
[] [__user_walk+60/88] [sys_stat64+22/120] [system_call+51/56]

Code: 89 50 04 89 43 08 8d 46 40 89 42 04 89 56 40 90 5b 5e 5f c3

And this is the code of __mark_inode_dirty:

0xc0140714 <__mark_inode_dirty>:push   %edi
0xc0140715 <__mark_inode_dirty+1>:  push   %esi
0xc0140716 <__mark_inode_dirty+2>:  push   %ebx
0xc0140717 <__mark_inode_dirty+3>:  mov0x10(%esp,1),%ebx
0xc014071b <__mark_inode_dirty+7>:  mov0x14(%esp,1),%edi
0xc014071f <__mark_inode_dirty+11>: mov0x8c(%ebx),%esi
0xc0140725 <__mark_inode_dirty+17>: test   %esi,%esi
0xc0140727 <__mark_inode_dirty+19>:
je 0xc0140780 <__mark_inode_dirty+108>
0xc0140729 <__mark_inode_dirty+21>: test   $0x7,%edi
0xc014072f <__mark_inode_dirty+27>:
je 0xc0140745 <__mark_inode_dirty+49>
0xc0140731 <__mark_inode_dirty+29>: mov0x20(%esi),%eax
0xc0140734 <__mark_inode_dirty+32>: test   %eax,%eax
0xc0140736 <__mark_inode_dirty+34>:
je 0xc0140745 <__mark_inode_dirty+49>
0xc0140738 <__mark_inode_dirty+36>: mov0x8(%eax),%eax
0xc014073b <__mark_inode_dirty+39>: test   %eax,%eax
0xc014073d <__mark_inode_dirty+41>:
je 0xc0140745 <__mark_inode_dirty+49>
0xc014073f <__mark_inode_dirty+43>: push   %ebx
0xc0140740 <__mark_inode_dirty+44>: call   *%eax
0xc0140742 <__mark_inode_dirty+46>: add$0x4,%esp
0xc0140745 <__mark_inode_dirty+49>: mov0xf0(%ebx),%edx
0xc014074b <__mark_inode_dirty+55>: mov%edx,%eax
0xc014074d <__mark_inode_dirty+57>: and%edi,%eax
0xc014074f <__mark_inode_dirty+59>: cmp%edi,%eax
0xc0140751 <__mark_inode_dirty+61>:
je 0xc0140780 <__mark_inode_dirty+108>
0xc0140753 <__mark_inode_dirty+63>: or %edi,%edx
0xc0140755 <__mark_inode_dirty+65>: mov%edx,0xf0(%ebx)
0xc014075b <__mark_inode_dirty+71>: cmp%ebx,(%ebx)
0xc014075d <__mark_inode_dirty+73>:
je 0xc0140780 <__mark_inode_dirty+108>
*** list_del start ***
0xc014075f <__mark_inode_dirty+75>: lea0x8(%ebx),%edx
0xc0140762 <__mark_inode_dirty+78>: mov0x4(%edx),%ecx
0xc0140765 <__mark_inode_dirty+81>: mov0x8(%ebx),%eax
0xc0140768 <__mark_inode_dirty+84>: mov%ecx,0x4(%eax)
0xc014076b <__mark_inode_dirty+87>: mov%eax,(%ecx)
*** list_del end, list_add start ***
0xc014076d <__mark_inode_dirty+89>: mov0x40(%esi),%eax
0xc0140770 <__mark_inode_dirty+92>: mov%edx,0x4(%eax)
 ^ CRASHed at above ^
0xc0140773 <__mark_inode_dirty+95>: mov%eax,0x8(%ebx)
0xc0140776 <__mark_inode_dirty+98>: lea0x40(%esi),%eax
0xc0140779 <__mark_inode_dirty+101>:mov%eax,0x4(%edx)
0xc014077c <__mark_inode_dirty+104>:mov%edx,0x40(%esi)
0xc014077f <__mark_inode_dirty+107>:nop
0xc0140780 <__mark_inode_dirty+108>:pop%ebx
0xc0140781 <__mark_inode_dirty+109>:pop%esi
0xc0140782 <__mark_inode_dirty+110>:pop%edi
0xc0140783 <__mark_inode_dirty+111>:ret

Versions installed:

Gnu C  2.95.2
Gnu make   3.79.1
binutils   2.9.5.0.24
util-linux 2.10r
modutils   2.4.2
e2fsprogs  1.19
pcmcia-cs  3.1.17   (not used)
PPP2.3.11   (not used)
isdn4k-utils   3.1pre1a (not used)
Linux C Library2.1.3
Dynamic linker (ldd)   2.1.3
Procps 2.0.6
Net-tools  1.56
Kbd0.99
Sh-utils   2.0
Modules Loaded ipv6 3c509 serial

Kernel configuration:

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_M686=y
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_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONF

pci_id's

[ivor]

Hi

Please could someone help me id the following host and pci bridges, they
don't appear in kernel 2.4.0.

Host Bridge
PCI_0600_1106__3050__30-0-0
PCI_0600_8086_1043_1130_8028_02-0-0
PCI_0600_8086_1028_2500_0095_03-0-0

PCI Bridge
PCI_0604_1106_1106_8391__00-0-0
PCI_0604_8086__1131__02-0-0
PCI_0604_8086__244e__01-0-0

Thanks
Ivor

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

Re: nanosleep question

[Michael Reinelt]

george anzinger wrote:
> > > > At the moment I implemented by own delay loop using a small assembler
> > > > loop similar to the one used in the kernel. This has two disadvantages:
> > > > assembler isn't that portable, and the loop has to be calibrated.
> > >
> > > Why not use C?  As long as you calibrate it, it should do just fine.
> > Because the compiler might optimize it away.
> 
> Not if you use volatile on the data type.
I did a lost of testing and experimenting, and found the assembler loop
the best solution (it has the finest granualrity even on slower
systems).

> > > the other hand, since you are looping anyway, why not loop on a system
> > > time of day call and have the loop exit when you have the required time
> > > in hand.  These calls have microsecond resolution.
> > I'm afraid they don't (at least with kernel 2.0, I didn't try this with
> > 2.4).
> 
> Gosh, I started with 2.2.14 and it does full microsecond resolution.

Oh! Shame on me! I must have missed something here!

I could swear that this didn't work for me. I tried it yesterday, you
are right, there is microsecond resolution. Even on an old 2.0.38
kernel...

This solves all my problems. I'll loop on gettimeofday().

Thanks a lot!

 Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [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/

fbdev cursor management

[Andrew Morton]

Guys,

I've been taking a look at the cursor flashing code,
from the point of view of how it's affected by the
recent enabling of interrupts across the console code.

Pretty much all of the cursor-blink stuff is racy,
and has always been racy on SMP.  Enabling the
interrupts has made it racy on UP as well.

It all happens in timer handlers and interrupt handlers,
with no protection against mainline code accessing the
hardware simultaneously.  As far as I can see, the
races will be harmless - the worst they can do is to
leave some snailtrails on the screen, which will soon
scroll away. So unless someone feels strongly about it,
or can pick a problem which I've missed I'd propose that
we leave it as it is for now.

vgacon looks OK.


Some things which I'd propose for future work:

- Collapse all the various per-driver cursor flashing
  routines into a single place - manage the timer from
  drivers/video/fbcon.c and from there, call into the
  driver layer if requested.

- The cursor flash code should do the actual flash stuff
  from within process context, not interrupt context.  This
  way, it can do acquire_console_sem() to serialise
  everything properly.

  The only way we have of doing this at present is to call
  schedule_task() from within the timer handler.  This works
  fine, but it complicates the device close and module unload
  problem somewhat.  del_timer_sync + flush_scheduled_tasks
  will be needed in the right places.

  There are lots of places in the kernel which would benefit
  from a process-context timer callback mechanism - ethernet
  drivers in particular.  So this is a piece of infrastructure
  which we should develop for 2.5.  It'll be just fine for
  use in das blinkencursor code.

- With rivafb, I note that fbcon_vbl_handler() is being
  called at 50 Hz, and it doesn't actually *do* anything.
  All the work is being done by riva_cursor_timer_handler().
  Seems a little inefficient?

- riva_cursor_timer_handler() is being called at 100Hz,
  which is also more costly than it needs to be.  Also,
  it does this:

rinfo->cursor->timer->expires = jiffies + (HZ / 100);

  so if the system has HZ < 100, the machine locks
  up - run_timer_list() never returns.  Minor point, but
  it's another argument in favour of using, say, HZ/10.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] nmi-watchdog-2.4.2-A1

[Andrew Morton]

Ingo Molnar wrote:
> 
> On Sun, 11 Mar 2001, Keith Owens wrote:
> 
> > Works for me.  It even makes kdb simpler.
> 
> agreed. Also, touch_nmi_watchdog() is stateless and is thus much less
> prone to locking bugs.
> 
> i've attached nmi-watchdog-2.4.2-A1 that implements touch_nmi_watchdog(),
> ontop of 2.4.2-ac18, and changes show_state() to use this interface. (the
> patch also takes the NMI counters out of the obscure in-function place
> they used to be.)
> 
> the patch compiles & boots just fine on 2.4.2-ac18 in both SMP and
> APIC-less-UP mode. The NMI watchdog is functional, and SysRq-T does not
> cause a lockup if used with a slow serial console that takes more than 5
> seconds to output the tasklist.
> 

Sorry, this doesn't look right. Are you sure you booted
with `nmi_watchdog=1'?  It was turned off by default in -ac18.

Two things:

- CPU A could be doing the SYSRQ printing, while
  CPU B is spinning on a lock which CPU A holds. The
  NMI watchdog will then whack CPU B.  So touch_nmi_watchdog()
  needs to touch *all* CPUs.  (kbd_controller_lock, for example).

- We need to touch the NMI more than once during the 
  SYSRQ-T output - five seconds isn't enough.

  The correctest way is, I think, to touch_nmi() in
  rs285_console_write(), lp_console_write() and serial_console_write().
  We _could_ just touch it in show_state(), but that means
  we still get whacked if we do a lot of printk()s with interrupts
  disabled from some random place in the kernel.


--- linux-2.4.2-ac18/arch/i386/kernel/nmi.c Sun Mar 11 15:12:31 2001
+++ linux-ac/arch/i386/kernel/nmi.c Sun Mar 11 21:03:18 2001
@@ -226,37 +226,39 @@
 }
 
 static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-static atomic_t nmi_watchdog_disabled = ATOMIC_INIT(0);
 
-void nmi_watchdog_disable(void)
-{
-   atomic_inc(&nmi_watchdog_disabled);
-}
+/*
+ * The best way to detect whether a CPU has a 'hard lockup' problem
+ * is to check its local APIC timer IRQ counts. If they are not
+ * changing then that CPU has some problem.
+ *
+ * as these watchdog NMI IRQs are generated on every CPU, we only
+ * have to check the current processor.
+ *
+ * since NMIs dont listen to _any_ locks, we have to be extremely
+ * careful not to rely on unsafe variables. The printk might lock
+ * up though, so we have to break up any console locks first ...
+ * [when there will be more tty-related locks, break them up
+ *  here too!]
+ */
+
+static unsigned int
+   last_irq_sums [NR_CPUS],
+   alert_counter [NR_CPUS];
 
-void nmi_watchdog_enable(void)
+void touch_nmi_watchdog (void)
 {
-   atomic_dec(&nmi_watchdog_disabled);
+   /*
+* Just reset the alert counters.
+*/
+   int cpu;
+
+   for (cpu = 0; cpu < smp_num_cpus; cpu++)
+   alert_counter[cpu] = 0;
 }
 
 void nmi_watchdog_tick (struct pt_regs * regs)
 {
-   /*
-* the best way to detect wether a CPU has a 'hard lockup' problem
-* is to check it's local APIC timer IRQ counts. If they are not
-* changing then that CPU has some problem.
-*
-* as these watchdog NMI IRQs are broadcasted to every CPU, here
-* we only have to check the current processor.
-*
-* since NMIs dont listen to _any_ locks, we have to be extremely
-* careful not to rely on unsafe variables. The printk might lock
-* up though, so we have to break up any console locks first ...
-* [when there will be more tty-related locks, break them up
-*  here too!]
-*/
-
-   static unsigned int last_irq_sums [NR_CPUS],
-   alert_counter [NR_CPUS];
 
/*
 * Since current-> is always on the stack, and we always switch
@@ -266,7 +268,7 @@
 
sum = apic_timer_irqs[cpu];
 
-   if (last_irq_sums[cpu] == sum && atomic_read(&nmi_watchdog_disabled) == 0) {
+   if (last_irq_sums[cpu] == sum) {
/*
 * Ayiee, looks like this CPU is stuck ...
 * wait a few IRQs (5 seconds) before doing the oops ...
--- linux-2.4.2-ac18/drivers/char/sysrq.c   Sun Mar 11 15:12:34 2001
+++ linux-ac/drivers/char/sysrq.c   Sun Mar 11 20:57:30 2001
@@ -70,11 +70,6 @@
if (!key)
return;
 
-   /*
-* Interrupts are disabled, and serial consoles are slow. So
-* Let's suspend the NMI watchdog.
-*/
-   nmi_watchdog_disable();
console_loglevel = 7;
printk(KERN_INFO "SysRq: ");
switch (key) {
@@ -158,7 +153,6 @@
/* Don't use 'A' as it's handled specially on the Sparc */
}
 
-   nmi_watchdog_enable();
console_loglevel = orig_log_level;
 }
 
--- linux-2.4.2-ac18/drivers/char/serial.c  Sun Mar 11 15:12:34 2001
+++ linux-ac/drivers/char/serial.c  Sun Mar 11 20:58:58 2001
@@ -5478,10 +5478,11 @@
 /*
  * Wait for transmitter & holding register to empty
  */
-static inline void wait_for_xmitr(struct 

[patch] nmi-watchdog-2.4.2-A1

[Ingo Molnar]

On Sun, 11 Mar 2001, Keith Owens wrote:

> Works for me.  It even makes kdb simpler.

agreed. Also, touch_nmi_watchdog() is stateless and is thus much less
prone to locking bugs.

i've attached nmi-watchdog-2.4.2-A1 that implements touch_nmi_watchdog(),
ontop of 2.4.2-ac18, and changes show_state() to use this interface. (the
patch also takes the NMI counters out of the obscure in-function place
they used to be.)

the patch compiles & boots just fine on 2.4.2-ac18 in both SMP and
APIC-less-UP mode. The NMI watchdog is functional, and SysRq-T does not
cause a lockup if used with a slow serial console that takes more than 5
seconds to output the tasklist.

Ingo


--- linux/include/linux/irq.h.orig  Sun Mar 11 11:20:21 2001
+++ linux/include/linux/irq.h   Sun Mar 11 11:22:27 2001
@@ -57,18 +57,16 @@
 #include  /* the arch dependent stuff */
 
 /**
- * nmi_watchdog_disable - disable NMI watchdog checking.
+ * touch_nmi_watchdog - restart NMI watchdog timeout.
  * 
- * If the architecture supports the NMI watchdog, nmi_watchdog_disable() may be used
- * to temporarily disable it.  Use nmi_watchdog_enable() later on.  It is implemented
- * via an up/down counter, so you must keep the calls balanced.
+ * If the architecture supports the NMI watchdog, touch_nmi_watchdog()
+ * may be used to reset the timeout - for code which intentionally
+ * disables interrupts for a long time. This call is stateless.
  */
 #ifdef ARCH_HAS_NMI_WATCHDOG
-extern void nmi_watchdog_disable(void);
-extern void nmi_watchdog_enable(void);
+extern void touch_nmi_watchdog(void);
 #else
-#define nmi_watchdog_disable() do{} while(0)
-#define nmi_watchdog_enable() do{} while(0)
+# define touch_nmi_watchdog() do { } while(0)
 #endif
 
 extern int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *);
--- linux/drivers/char/sysrq.c.orig Sun Mar 11 11:30:46 2001
+++ linux/drivers/char/sysrq.c  Sun Mar 11 11:31:12 2001
@@ -72,9 +72,9 @@
 
/*
 * Interrupts are disabled, and serial consoles are slow. So
-* Let's suspend the NMI watchdog.
+* let's re-start the NMI watchdog timeout.
 */
-   nmi_watchdog_disable();
+   touch_nmi_watchdog();
console_loglevel = 7;
printk(KERN_INFO "SysRq: ");
switch (key) {
@@ -158,7 +158,6 @@
/* Don't use 'A' as it's handled specially on the Sparc */
}
 
-   nmi_watchdog_enable();
console_loglevel = orig_log_level;
 }
 
--- linux/arch/i386/kernel/nmi.c.orig   Sun Mar 11 11:24:34 2001
+++ linux/arch/i386/kernel/nmi.cSun Mar 11 11:30:06 2001
@@ -226,37 +226,36 @@
 }
 
 static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-static atomic_t nmi_watchdog_disabled = ATOMIC_INIT(0);
 
-void nmi_watchdog_disable(void)
-{
-   atomic_inc(&nmi_watchdog_disabled);
-}
+/*
+ * the best way to detect wether a CPU has a 'hard lockup' problem
+ * is to check it's local APIC timer IRQ counts. If they are not
+ * changing then that CPU has some problem.
+ *
+ * as these watchdog NMI IRQs are generated on every CPU, we only
+ * have to check the current processor.
+ *
+ * since NMIs dont listen to _any_ locks, we have to be extremely
+ * careful not to rely on unsafe variables. The printk might lock
+ * up though, so we have to break up any console locks first ...
+ * [when there will be more tty-related locks, break them up
+ *  here too!]
+ */
+
+static unsigned int
+   last_irq_sums [NR_CPUS],
+   alert_counter [NR_CPUS];
 
-void nmi_watchdog_enable(void)
+void touch_nmi_watchdog (void)
 {
-   atomic_dec(&nmi_watchdog_disabled);
+   /*
+* Just reset the alert counter:
+*/
+   alert_counter[smp_processor_id()] = 0;
 }
 
 void nmi_watchdog_tick (struct pt_regs * regs)
 {
-   /*
-* the best way to detect wether a CPU has a 'hard lockup' problem
-* is to check it's local APIC timer IRQ counts. If they are not
-* changing then that CPU has some problem.
-*
-* as these watchdog NMI IRQs are broadcasted to every CPU, here
-* we only have to check the current processor.
-*
-* since NMIs dont listen to _any_ locks, we have to be extremely
-* careful not to rely on unsafe variables. The printk might lock
-* up though, so we have to break up any console locks first ...
-* [when there will be more tty-related locks, break them up
-*  here too!]
-*/
-
-   static unsigned int last_irq_sums [NR_CPUS],
-   alert_counter [NR_CPUS];
 
/*
 * Since current-> is always on the stack, and we always switch
@@ -266,7 +265,7 @@
 
sum = apic_timer_irqs[cpu];
 
-   if (last_irq_sums[cpu] == sum && atomic_read(&nmi_watchdog_disabled) == 0) {
+   if (last_irq_sums[cpu] == sum) {
  

About DC-315U scsi driver

[³¯¤ý®i]

Hello All.

Maybe I post at wrong place.sorry

The driver has not to be included in officeal kernel.
And the maintainer has not updated the driver from 2.4.0-test9-pre7.
Maybe he is very busy.The last update is 2000-12-03.

I used some kernels from 2.4.0 to 2.4.2-ac17,and the driver always go wrong
when I burn CDRs. Some files burned is different from the origin at HD.
I use 2.2.17 with Tekram's driver,and nothing is wrong.
I think the scsi layer maybe changed from 2.2.x,so the driver cannot run well.
I am sure the hardware&software is ok,and no error messages about scsi  found by me. 

Can anyone do me a favor to modify the driver in order to suite the
new kernel?

Thanks

And some resources can be found at http://www.garloff.de/kurt/linux/dc395/.

Best Regards,cwz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] serial console vs NMI watchdog

[Andrew Morton]

Keith Owens wrote:
> 
> On Sun, 11 Mar 2001 08:53:40 +0100 (CET),
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >it sure has an alternative. The 'cpus spinning' code calls touch_nmi()
> >within the busy loop, the polling code on the control CPU too. This is
> >sure more robust and catches lockup bugs in kdb too ...
> 
> Works for me.  It even makes kdb simpler.

humm...

OK, this seems doable in the case of serial console.
For CONFIG_LP_CONSOLE (which has the same problem) it
looks like we can just call touch_nmi() in lp_console_write().

I'll see what Tim has to say.

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