* Re: Intel P6 vs P7 system call performance
From: Mark Mielke @ 2002-12-18 19:12 UTC (permalink / raw)
To: Horst von Brand; +Cc: linux-kernel
In-Reply-To: <200212181410.gBIEAod6027746@pincoya.inf.utfsm.cl>
On Wed, Dec 18, 2002 at 11:10:50AM -0300, Horst von Brand wrote:
> Sean Neakums <sneakums@zork.net> said:
> > How are system calls a new feature? Or is optimizing an existing
> > feature not allowed by your definition of "feature freeze"?
> This "optimizing" is very much userspace-visible, and a radical change in
> an interface this fundamental counts as a new feature in my book.
Since operating systems like WIN32 are at least published to take
advantage of SYSENTER, it may not be in Linux's interest to
purposefully use a slower interface until 2.8 (how long will that be
until people can use?). The last thing I want to read about in a
technical journal is how WIN32 has lower system call overhead than
Linux on IA-32 architectures. That might just be selfish of me for
the Linux community... :-)
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
^ permalink raw reply
* [BUG] 2.5.47 - Assertion failed in fs/jbd/journal.c:415
From: Robert Macaulay @ 2002-12-18 19:02 UTC (permalink / raw)
To: linux-kernel
We were performing an IO performance test on 2.5.47. The storage we were
writing to was a Fibre Channel array(dell 650f) via qlogic 2200 cards
using the qlogicfc driver in the Linux kernel. There were 8 separate LUNS
on the FC array, each of which has an ext3 filesystem on them. There are
no partition tables on the disks(one of the disks would not accept one,
separate issue). The ext3 filesystem was created directly on the block
devices, /dev/sdf /dev/sdg etc. The server is a Dell Poweredge 6650, 4
procs, 8Gig RAM. More detailed system information is appended at the
bottom.
For now, the test was 100% writing to all 8 filesystems in parallel. The
following BUG was reported halfway through the 4th run of this test. I'm
not sure how reproducible this is.
The machine is still running. IO in progress at the time of the BUG has
stopped in D state, New IO is stil possible though to the disks. I will
leave the system up and running if there is any more info needed for a few
days.
I will be trying a more recent version in a few days. 2.5.47 was the
latest kernel I could compile at the time. I've looked through the
archives, but could not find any mention of this particular bug, so I do
not know if it has been addressed or not. Thanks
Assertion failure in journal_write_metadata_buffer() at fs/jbd/journal.c:415: "buffer_jdirty(jh2bh(jh_in))"
------------[ cut here ]------------
kernel BUG at fs/jbd/journal.c:415!
invalid operand: 0000
qlogicfc autofs
CPU: 2
EIP: 0060:[<c0193b62>] Not tainted
EFLAGS: 00010246
eax: 0000006f ebx: cd31e720 ecx: 00000000 edx: c02f6388
esi: 00000000 edi: ea0caa50 ebp: f29abb00 esp: c6b23e30
ds: 0068 es: 0068 ss: 0068
Process kjournald (pid: 3032, threadinfo=c6b22000 task=ee07d100)
Stack: c02b2240 c02afb0d c02afae0 0000019f c02afaf1 00000000 c6b22000 f6a5de00
00000000 00000000 cd31e720 00000000 ea0caa50 f29abb00 c0191062 f29abb00
cd31e720 c6b23e98 000015bf f6a5de94 00000000 00000f9c cb1a3064 0000000a
Call Trace: [<c0191062>] [<c0193976>] [<c01937e0>] [<c0193800>] [<c0108b75>]
Code: 0f 0b 9f 01 e0 fa 2a c0 83 c4 14 8b 54 24 2c 8b 4a 0c 85 c9
Decoded is below
ksymoops 2.4.8 on i686 2.5.47. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.47/ (default)
-m /gold/linux-2.5.46/System.map (specified)
Warning (compare_maps): ksyms_base symbol page_states__per_cpu_R__ver_page_states__per_cpu not found in System.map. Ignoring ksyms_base entry
kernel BUG at fs/jbd/journal.c:415!
invalid operand: 0000
CPU: 2
EIP: 0060:[<c0193b62>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 0000006f ebx: cd31e720 ecx: 00000000 edx: c02f6388
esi: 00000000 edi: ea0caa50 ebp: f29abb00 esp: c6b23e30
ds: 0068 es: 0068 ss: 0068
Stack: c02b2240 c02afb0d c02afae0 0000019f c02afaf1 00000000 c6b22000 f6a5de00
00000000 00000000 cd31e720 00000000 ea0caa50 f29abb00 c0191062 f29abb00
cd31e720 c6b23e98 000015bf f6a5de94 00000000 00000f9c cb1a3064 0000000a
Call Trace: [<c0191062>] [<c0193976>] [<c01937e0>] [<c0193800>] [<c0108b75>]
Code: 0f 0b 9f 01 e0 fa 2a c0 83 c4 14 8b 54 24 2c 8b 4a 0c 85 c9
>>EIP; c0193b62 <journal_write_metadata_buffer+62/260> <=====
>>ebx; cd31e720 <_end+cef86d4/3852bfb4>
>>edx; c02f6388 <log_wait+4/c>
>>edi; ea0caa50 <_end+29ca4a04/3852bfb4>
>>ebp; f29abb00 <_end+32585ab4/3852bfb4>
>>esp; c6b23e30 <_end+66fdde4/3852bfb4>
Trace; c0191062 <journal_commit_transaction+812/1219>
Trace; c0193976 <kjournald+176/260>
Trace; c01937e0 <commit_timeout+0/10>
Trace; c0193800 <kjournald+0/260>
Trace; c0108b75 <kernel_thread_helper+5/10>
Code; c0193b62 <journal_write_metadata_buffer+62/260>
00000000 <_EIP>:
Code; c0193b62 <journal_write_metadata_buffer+62/260> <=====
0: 0f 0b ud2a <=====
Code; c0193b64 <journal_write_metadata_buffer+64/260>
2: 9f lahf
Code; c0193b65 <journal_write_metadata_buffer+65/260>
3: 01 e0 add %esp,%eax
Code; c0193b67 <journal_write_metadata_buffer+67/260>
5: fa cli
Code; c0193b68 <journal_write_metadata_buffer+68/260>
6: 2a c0 sub %al,%al
Code; c0193b6a <journal_write_metadata_buffer+6a/260>
8: 83 c4 14 add $0x14,%esp
Code; c0193b6d <journal_write_metadata_buffer+6d/260>
b: 8b 54 24 2c mov 0x2c(%esp,1),%edx
Code; c0193b71 <journal_write_metadata_buffer+71/260>
f: 8b 4a 0c mov 0xc(%edx),%ecx
Code; c0193b74 <journal_write_metadata_buffer+74/260>
12: 85 c9 test %ecx,%ecx
1 warning issued. Results may not be reliable.
/proc/meminfo
MemTotal: 7769884 kB
MemFree: 7196 kB
MemShared: 0 kB
Buffers: 94304 kB
Cached: 7384944 kB
SwapCached: 2440 kB
Active: 64680 kB
Inactive: 7420544 kB
HighTotal: 6946752 kB
HighFree: 5248 kB
LowTotal: 823132 kB
LowFree: 1948 kB
SwapTotal: 2096440 kB
SwapFree: 2092160 kB
Dirty: 229620 kB
Writeback: 0 kB
Mapped: 12712 kB
Slab: 252824 kB
Committed_AS: 81216 kB
PageTables: 1360 kB
ReverseMaps: 19053
/proc/version
Linux version 2.5.47 (root@bottom) (gcc version 2.96 20000731 (Red Hat
Linux 7.2 2.96-108.1)) #13 SMP Wed Dec 11 11:49:05 CST 2002
/proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: ServerWorks CMIC-HE (rev 34).
Bus 0, device 0, function 1:
Host bridge: ServerWorks CMIC-HE (#2) (rev 0).
Bus 0, device 0, function 2:
Host bridge: ServerWorks CMIC-HE (#3) (rev 0).
Bus 0, device 0, function 3:
Host bridge: ServerWorks CMIC-HE (#4) (rev 0).
Bus 0, device 4, function 0:
VGA compatible controller: ATI Technologies Inc Rage XL (rev 39).
Master Capable. Latency=32. Min Gnt=8.
Non-prefetchable 32 bit memory at 0xfd000000 [0xfdffffff].
I/O at 0xec00 [0xecff].
Non-prefetchable 32 bit memory at 0xfe101000 [0xfe101fff].
Bus 0, device 5, function 0:
Class ff00: Dell Computer Corporation Remote Assistant Card 3 (rev 0).
IRQ 20.
Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xfeb80000 [0xfeb80fff].
I/O at 0xe8f8 [0xe8ff].
I/O at 0xe8e8 [0xe8ef].
Bus 0, device 5, function 1:
Class ff00: Dell Computer Corporation PowerEdge Expandable RAID
Controller 3/Di (rev 0).
IRQ 31.
Master Capable. Latency=32.
Non-prefetchable 32 bit memory at 0xfe100000 [0xfe100fff].
I/O at 0xe880 [0xe8bf].
Prefetchable 32 bit memory at 0xfeb00000 [0xfeb7ffff].
Bus 0, device 5, function 2:
Class 0c07: PCI device 1028:0009 (Dell Computer Corporation) (rev 0).
IRQ 41.
Master Capable. Latency=32.
I/O at 0xe8f4 [0xe8f7].
Bus 0, device 15, function 0:
Host bridge: ServerWorks CSB5 South Bridge (rev 147).
Master Capable. Latency=64.
Bus 0, device 15, function 1:
IDE interface: ServerWorks CSB5 IDE Controller (rev 147).
Master Capable. Latency=64.
I/O at 0x8c0 [0x8c7].
I/O at 0x8c8 [0x8cb].
I/O at 0x8d0 [0x8d7].
I/O at 0x8d8 [0x8db].
I/O at 0x8b0 [0x8bf].
Bus 0, device 15, function 3:
ISA bridge: PCI device 1166:0225 (ServerWorks) (rev 0).
Bus 0, device 16, function 0:
Host bridge: ServerWorks CIOB30 (rev 3).
Master Capable. Latency=32.
Bus 0, device 16, function 2:
Host bridge: ServerWorks CIOB30 (#2) (rev 3).
Master Capable. Latency=32.
Bus 0, device 17, function 0:
Host bridge: ServerWorks CIOB30 (#3) (rev 3).
Master Capable. Latency=32.
Bus 0, device 17, function 2:
Host bridge: ServerWorks CIOB30 (#4) (rev 3).
Master Capable. Latency=32.
Bus 0, device 18, function 0:
Host bridge: ServerWorks CIOB30 (#5) (rev 3).
Master Capable. Latency=32.
Bus 0, device 18, function 2:
Host bridge: ServerWorks CIOB30 (#6) (rev 3).
Master Capable. Latency=32.
Bus 3, device 1, function 0:
PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge (rev 0).
Master Capable. Latency=32. Min Gnt=6.
Bus 4, device 0, function 0:
PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge (#2) (rev 0).
Master Capable. Latency=32. Min Gnt=6.
Bus 4, device 1, function 0:
SCSI storage controller: QLogic Corp. ISP12160 Dual Channel Ultra3
SCSI Processor (rev 6).
IRQ 32.
Master Capable. Latency=32. Min Gnt=64.
I/O at 0xdc00 [0xdcff].
Non-prefetchable 32 bit memory at 0xfcdff000 [0xfcdfffff].
Bus 5, device 0, function 0:
RAID bus controller: American Megatrends Inc. MegaRAID (rev 32).
IRQ 21.
Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xf0000000 [0xf7ffffff].
Bus 11, device 1, function 0:
Ethernet controller: Intel Corp. 82544EI Gigabit Ethernet Controller
(rev 2).
IRQ 25.
Master Capable. Latency=64. Min Gnt=255.
Non-prefetchable 64 bit memory at 0xefe20000 [0xefe3ffff].
Non-prefetchable 64 bit memory at 0xefe00000 [0xefe1ffff].
I/O at 0xcce0 [0xccff].
Bus 21, device 1, function 0:
Ethernet controller: Intel Corp. 82544EI Gigabit Ethernet Controller
(#2) (rev 2).
IRQ 29.
Master Capable. Latency=64. Min Gnt=255.
Non-prefetchable 64 bit memory at 0xefa20000 [0xefa3ffff].
Non-prefetchable 64 bit memory at 0xefa00000 [0xefa1ffff].
I/O at 0xace0 [0xacff].
Bus 16, device 2, function 0:
SCSI storage controller: QLogic Corp. QLA2200 (rev 5).
IRQ 24.
Master Capable. Latency=32. Min Gnt=64.
I/O at 0xbc00 [0xbcff].
Non-prefetchable 32 bit memory at 0xefc00000 [0xefc00fff].
Bus 26, device 1, function 0:
SCSI storage controller: QLogic Corp. QLA2200 (#2) (rev 5).
IRQ 27.
Master Capable. Latency=32.
I/O at 0x9c00 [0x9cff].
Non-prefetchable 32 bit memory at 0xef800000 [0xef800fff].
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Xeon(TM) CPU 1.50GHz
stepping : 1
cpu MHz : 1490.693
cache size : 256 KB
physical id : 0
siblings : 1
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 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 2932.73
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Xeon(TM) CPU 1.50GHz
stepping : 1
cpu MHz : 1490.693
cache size : 256 KB
physical id : 1
siblings : 1
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 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 2973.69
processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Xeon(TM) CPU 1.50GHz
stepping : 1
cpu MHz : 1490.693
cache size : 256 KB
physical id : 2
siblings : 1
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 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 2973.69
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Xeon(TM) CPU 1.50GHz
stepping : 1
cpu MHz : 1490.693
cache size : 256 KB
physical id : 3
siblings : 1
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 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 2973.69
/proc/modules
qlogicfc 172416 8
autofs 13252 1 (autoclean)
kernel .config file
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_SWAP=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# General setup
#
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_NR_CPUS=32
# CONFIG_X86_NUMA is not set
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_CPU_FREQ is not set
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
#
# Power management options (ACPI, APM)
#
#
# ACPI Support
#
# CONFIG_ACPI is not set
# CONFIG_PM is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_SCx200 is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_EISA=y
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
#
# Executable file formats
#
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_PNP_NAMES is not set
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_XD=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_UMEM=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set
#
# ATA/ATAPI/MFM/RLL device support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_ISAPNP=y
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_GENERIC is not set
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDE_TCQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_AMD74XX_OVERRIDE is not set
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NFORCE is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_SVWKS=y
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_BLK_DEV_IDE_MODES=y
#
# SCSI device support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
CONFIG_SCSI_MEGARAID=y
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# PCMCIA SCSI adapter support
#
# CONFIG_SCSI_PCMCIA is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
# CONFIG_BLK_DEV_DM is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
CONFIG_IEEE1394=m
#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_IPV6=m
#
# IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
# CONFIG_IP6_NF_MATCH_LENGTH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set
#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
CONFIG_IRDA=m
#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set
#
# Infrared-port device drivers
#
#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
#
# Old SIR device drivers
#
# CONFIG_IRTTY_OLD is not set
CONFIG_IRPORT_SIR=m
#
# Old Serial dongle support
#
# CONFIG_DONGLE_OLD is not set
#
# FIR device drivers
#
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
# CONFIG_TOSHIBA_OLD is not set
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set
#
# Telephony Support
#
CONFIG_PHONE=m
CONFIG_PHONE_IXJ=m
CONFIG_PHONE_IXJ_PCMCIA=m
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=m
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=2048
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m
#
# Mice
#
CONFIG_BUSMOUSE=m
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_SOFT_WATCHDOG=m
CONFIG_WDT=m
CONFIG_WDTPCI=m
# CONFIG_WDT_501 is not set
CONFIG_PCWATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_I810_TCO=m
# CONFIG_MIXCOMWD is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_60XX_WDT is not set
CONFIG_W83877F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_INTEL_RNG=m
CONFIG_AMD_RNG=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
CONFIG_AGP_SWORKS=y
# CONFIG_AGP_AMD_8151 is not set
# CONFIG_DRM is not set
#
# PCMCIA character devices
#
CONFIG_SYNCLINK_CS=m
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
CONFIG_HFS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
CONFIG_JFS_DEBUG=y
# CONFIG_JFS_STATISTICS is not set
CONFIG_MINIX_FS=m
CONFIG_VXFS_FS=m
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_SYSV_FS=m
CONFIG_UDF_FS=m
# CONFIG_UDF_RW is not set
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_XFS_FS is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
# CONFIG_CIFS is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_AFS_FS=m
CONFIG_RXRPC=m
CONFIG_ZISOFS_FS=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
# CONFIG_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Bluetooth support
#
# CONFIG_BT is not set
#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_KALLSYMS is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Security options
#
CONFIG_SECURITY_CAPABILITIES=y
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
^ permalink raw reply
* RE: problem using jffs2 on DiskOnChip
From: Carl Wolff @ 2002-12-18 19:26 UTC (permalink / raw)
To: 'Russ Dill'; +Cc: linux-mtd
In-Reply-To: <1040238853.2843.3.camel@timmy>
> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org
> [mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Russ Dill
> Sent: woensdag 18 december 2002 20:14
> To: wolff@turnkiek.nl
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: problem using jffs2 on DiskOnChip
>
>
> On Wed, 2002-12-18 at 12:03, Carl Wolff wrote:
> > Hello,
> >
> > I've got a problem with jffs2. I'm using a DiskOnChip
> module type milennium.
> >
> > Do I need NFTL support?
> > I've managed to copy a jffs2 image onto the diskonchip
> using cp image
> > /dev/mtd/0.
>
> eraseall /dev/mtd/0
I did it. I checked the contents after the eraseall and saw only FF's.
Then I copied the image and verified the contents of the device with the
orginial file: they are the same.
So I think the data is correctly put into the flash....
>
> --
> Russ Dill <Russ.Dill@asu.edu>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Jun Sun @ 2002-12-18 18:51 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips, jsun
In-Reply-To: <Pine.GSO.3.96.1021218185016.5977F-100000@delta.ds2.pg.gda.pl>
On Wed, Dec 18, 2002 at 07:14:20PM +0100, Maciej W. Rozycki wrote:
> On Wed, 18 Dec 2002, Jun Sun wrote:
>
> > > do_IRQ(poll_8259A_irq(), regs);
> >
> > I actually don't like the new semantic. The main drawback is that we can't
> > dispatch a 8259A interrupt from assemably code, which is often needed.
>
> You can't do that with your original code either,
What do you mean? I could do a standard assembly intr dispatching code like
this;
move a0, sp
jal dispatch_i8259_irq
j ret_from_irq
Please cross-check all current assembly-level irq dispatching calls. They
are all like this.
> unless you arrange a
> call to your dispatch_i8259_irq() C function. This can still be done with
> a trivial wrapper like:
>
> asmlinkage void foo_dispatch_i8259_irq(struct pt_regs *regs)
> {
> do_IRQ(poll_8259A_irq(), regs);
> }
>
This is essentially the same as adding dispatch_i8259_irq() to i8259.c file,
which in turn calls an inline function as its function body.
Unless there is obvious another usage of poll_8259A_irq(), the inline function
might as well be not inlined.
> which results in code like you proposed.
>
Yes, that is why I liked my original function call. :-)
> > What is wrong with original way of dispatching? The general interrupt
> > dispatching flow is that you chase the routing path until you find the final
> > source and do a do_IRQ(). That seems fine with i8259A case here.
>
> It does too much and is therefore useful for a single specific case only.
> I focused on handling the chip only and the resulting function may be used
> however desired, including your specific case. Not all platforms need to
> want to call do_IRQ() immediately after getting an IRQ number, including
> code already in existence.
Note those platforms don't read i8259 registers to get irq number either.
There is also a style issue. Dispatching an interrupt is really part of
hw_interrupt_type structure. You should implement it in the same file as the
rest functions. However, if anybody feels it is not optimized enough they are
always free to lump all IRQ dispatching code together in one place, probably even
in assembly code.
I also disagree to have a header file with only one function declaration, but I
agree there is orthognal issue, mostly a maintenance issue. So if Ralf is ok with that,
I won't bitching about it.
Jun
^ permalink raw reply
* Re: [lvm-devel] [PATCH] add kobject to struct mapped_device
From: Greg KH @ 2002-12-18 18:53 UTC (permalink / raw)
To: lvm-devel, linux-kernel
In-Reply-To: <20021218184307.GA32190@kroah.com>
On Wed, Dec 18, 2002 at 10:43:07AM -0800, Greg KH wrote:
>
> Here's a simple patch against 2.5.52 that adds the kobject structure to
> struct mapped_device.
Sorry, that patch didn't apply against the latest 2.5-bk tree. Here's
an updated version.
thanks,
greg k-h
===== drivers/block/genhd.c 1.61 vs edited =====
--- 1.61/drivers/block/genhd.c Wed Dec 4 16:07:17 2002
+++ edited/drivers/block/genhd.c Wed Dec 18 10:53:26 2002
@@ -475,3 +475,4 @@
EXPORT_SYMBOL(bdev_read_only);
EXPORT_SYMBOL(set_device_ro);
EXPORT_SYMBOL(set_disk_ro);
+EXPORT_SYMBOL(block_subsys);
===== drivers/md/dm.c 1.14 vs edited =====
--- 1.14/drivers/md/dm.c Mon Dec 16 01:42:31 2002
+++ edited/drivers/md/dm.c Wed Dec 18 10:54:10 2002
@@ -40,7 +40,7 @@
struct mapped_device {
struct rw_semaphore lock;
- atomic_t holders;
+ struct kobject kobj;
unsigned long flags;
@@ -65,9 +65,13 @@
mempool_t *io_pool;
};
+#define to_md(obj) container_of(obj, struct mapped_device, kobj)
+
#define MIN_IOS 256
static kmem_cache_t *_io_cache;
+struct subsystem dm_subsys;
+
static __init int local_init(void)
{
int r;
@@ -89,6 +93,7 @@
if (!_major)
_major = r;
+ subsystem_register(&dm_subsys);
return 0;
}
@@ -100,7 +105,8 @@
DMERR("devfs_unregister_blkdev failed");
_major = 0;
-
+ subsystem_unregister(&dm_subsys);
+
DMINFO("cleaned up");
}
@@ -603,7 +609,8 @@
DMWARN("allocating minor %d.", minor);
memset(md, 0, sizeof(*md));
init_rwsem(&md->lock);
- atomic_set(&md->holders, 1);
+ md->kobj.subsys = &dm_subsys;
+ kobject_init(&md->kobj);
md->queue.queuedata = md;
blk_queue_make_request(&md->queue, dm_request);
@@ -696,17 +703,30 @@
void dm_get(struct mapped_device *md)
{
- atomic_inc(&md->holders);
+ kobject_get(&md->kobj);
}
void dm_put(struct mapped_device *md)
{
- if (atomic_dec_and_test(&md->holders)) {
- DMWARN("destroying md");
- __unbind(md);
- free_dev(md);
- }
+ kobject_put(&md->kobj);
}
+
+static void dm_release(struct kobject *kobj)
+{
+ struct mapped_device *md = to_md(kobj);
+
+ DMWARN("destroying md");
+ __unbind(md);
+ free_dev(md);
+}
+
+extern struct subsystem block_subsys;
+
+struct subsystem dm_subsys = {
+ .kobj = { .name = "dm", .parent = &block_subsys.kobj },
+ .release = dm_release,
+};
+
/*
* Requeue the deferred bios by calling generic_make_request.
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Maciej W. Rozycki @ 2002-12-18 18:47 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2vg1rnrkg.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> maciej> Is it needed? The part that returns .mx should be optimized away by the
> maciej> compiler automagically if unused.
>
> Idea was to make things compile without warnings, that way when you
> change anything, you search for warnings :(
The idea is fine, sure.
> With the changes that I sent, I have put the warnings levels down to
> (for IP22) to:
> - 7 C warnings
> - 2 Asm warnings
A few warnings are unavoidable -- e.g. there is no way to shut up gas
complaining about macros expanding into multiple instructions in branch
delay slots. Too bad.
How about this patch? -- it seems to work here (gcc 2.95.4).
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
patch-mips-2.4.20-pre6-20021212-setcx-0
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips/math-emu/ieee754int.h linux-mips-2.4.20-pre6-20021212/arch/mips/math-emu/ieee754int.h
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips/math-emu/ieee754int.h 2002-12-16 17:17:55.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips/math-emu/ieee754int.h 2002-12-18 18:31:51.000000000 +0000
@@ -58,10 +58,10 @@
#define CLPAIR(x,y) ((x)*6+(y))
#define CLEARCX \
- (ieee754_csr.cx = 0)
+ (ieee754_csr.cx = 0)
#define SETCX(x) \
- (ieee754_csr.cx |= (x),ieee754_csr.sx |= (x),ieee754_csr.mx & (x))
+ ({ieee754_csr.cx |= (x); ieee754_csr.sx |= (x); ieee754_csr.mx & (x);})
#define TSTX() \
(ieee754_csr.cx & ieee754_csr.mx)
^ permalink raw reply
* Re: problem using jffs2 on DiskOnChip
From: Russ Dill @ 2002-12-18 19:14 UTC (permalink / raw)
To: wolff; +Cc: linux-mtd
In-Reply-To: <001901c2a6c8$1c87ff60$446410ac@lt-gw8l30j.turnkiek.nl>
On Wed, 2002-12-18 at 12:03, Carl Wolff wrote:
> Hello,
>
> I've got a problem with jffs2. I'm using a DiskOnChip module type milennium.
>
> Do I need NFTL support?
> I've managed to copy a jffs2 image onto the diskonchip using cp image
> /dev/mtd/0.
eraseall /dev/mtd/0
--
Russ Dill <Russ.Dill@asu.edu>
^ permalink raw reply
* Re: [Benchmark] AIM9 results
From: Cliff White @ 2002-12-18 18:47 UTC (permalink / raw)
To: Hans Reiser
Cc: Andrew Morton, Paolo Ciarrocchi, linux-kernel, Chris Mason,
cliffw
In-Reply-To: <3DFE690D.7000602@namesys.com>
> Andrew Morton wrote:
>
> >Andrew Morton wrote:
> >
> >
> >>Hans Reiser wrote:
> >>
> >>
> >>>Andrew and Chris, are these changes in performance definitely due to VM
> >>>changes (and not some difference I am not thinking of between 2.5 and
> >>>2.4 reiserfs code)?
> >>>
> >>>
> >>>
> >>aim9 is just doing
> >>
> >> for (lots)
> >> close(creat(filename))
> >>
> >>
> > unlink(filename); /* of course */
> >
> >
> >
> >
> Oh, commercial fs vendors must really love tuning for this benchmark....
> sigh....
>
Ya, we think the AIM stuff is getting a little old. The basic idea is fine, but
many of the tests do _very little work. We (OSDL) would like to re-do
AIM9+7 and make it more useful. We'd love to have some input from everyone....
For example, how big a file should we create for a real creat() test ?
cliffw
> Hans
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Problems with running BP 7.0 and a application made with BP
From: Bart Oldeman @ 2002-12-18 18:39 UTC (permalink / raw)
To: Karlheinz Blau; +Cc: linux-msdos
In-Reply-To: <200212181910.34065.heinz@sybon.de>
On Wed, 18 Dec 2002, Karlheinz Blau wrote:
> DOSEMU built-in command.com version 1.0
> DOSEMU version is 1.0.2.0, 2001/06/10
> FreeDOS kernel version 1.1.24 [Jun 10 2001 22:25:01]
>
> XX-DOS version reported is 5.0
>
> This is my DOSEMU
>
> As we programmed our SYbon with BP 7.0 in 1994 we started it with a former
> DOSEMU. So I know, that is could work - but how.
In general BP 7.0 real-mode applications should work with this DOSEMU.
What is your problem exactly?
* if it's a "run time error 200", google it, that's not a DOSEMU problem
* otherwise get a new ~/dosemu/freedos/kernel.sys from
http://freedos.sourceforge.net (kernel build 2028)
* if you still have problems you could try a development version of
DOSEMU.
Bart
^ permalink raw reply
* RE: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 series cards
From: Neulinger, Nathan @ 2002-12-18 18:45 UTC (permalink / raw)
To: Adam Radford, Dave Jones; +Cc: linux-kernel, Uetrecht, Daniel J.
Your statement makes a hell of a lot more sense to me, but I'm just
going on what I was told, and observed behavior.
As soon as I followed his instructions, the symptom went away. Basically
on this one machine, I'm getting tons of command timed out, resetting
card messages. Along with unknown ioctl messages. Snippet from dmesg
follows:
3w-xxxx: scsi0: Unit #0: Command (0xdfeb4400) timed out, resetting card.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: scsi0: Unit #0: Command (0xdfeb4400) timed out, resetting card.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: scsi0: Unit #0: Command (0xdfeb4800) timed out, resetting card.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: Unknown ioctl 0x46.
3w-xxxx: scsi0: Unit #0: Command (0xdfeb4800) timed out, resetting card.
Have not seen any of those with the .016 driver.
I'm more than happy to test any changes/etc. to make this go away with
current drivers, but it'll need to be code for 2.4.x as I haven't
started doing anything with 2.5/2.6 yet.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Adam Radford [mailto:aradford@3WARE.com]
> Sent: Wednesday, December 18, 2002 12:42 PM
> To: 'Dave Jones'; Neulinger, Nathan
> Cc: linux-kernel@vger.kernel.org; Uetrecht, Daniel J.
> Subject: RE: 3ware driver in 2.4.x and 2.5.x not compatible
> with 6x00 series cards
>
>
> Who from 3ware told you it isn't compatible? That's totally bogus.
> It's completely compatible.
>
> 3ware supports 6, 7, and 8000 series cards with a single driver in
> 2.2, 2.4, and 2.5 trees.
>
> If it isn't working for you, let me know.
>
> -Adam
>
> -----Original Message-----
> From: Dave Jones [mailto:davej@codemonkey.org.uk]
> Sent: Wednesday, December 18, 2002 10:26 AM
> To: Nathan Neulinger
> Cc: linux-kernel@vger.kernel.org; uetrecht@umr.edu
> Subject: Re: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00
> series cards
>
>
> On Wed, Dec 18, 2002 at 12:10:54PM -0600, Nathan Neulinger wrote:
> > According to 3Ware, the driver in the 2.4.x and (I assume)
> 2.5.x is no
> > longer compatible with the 6xxx series cards.
> > I don't know what we'll do with this situation when we
> move to 2.6, cause
> > right now, it looks like we are completely screwed. The old driver
> > obviously will not compile on 2.6 since the API's have changed.
>
> Any idea at which point the 2.5 driver stopped working ?
> It may not be that much work to bring that version up to date as
> a 3ware-old.c driver in a worse-case scenario.
>
> This would be huge code duplication however, and would be much
> better fixed by having the driver detect which card its running
> on, and 'do the right thing' wrt which firmware it needs.
>
> Dave
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH] add kobject to struct mapped_device
From: Greg KH @ 2002-12-18 18:43 UTC (permalink / raw)
To: lvm-devel, linux-kernel
Hi,
Here's a simple patch against 2.5.52 that adds the kobject structure to
struct mapped_device. I did this for two reasons:
- kobject provides proper reference counting for a structure
(not saying that struct mapped_device didn't get this correct,
but it's nice to use the core for these things).
- This lets us tie into the block layer better to describe the
dm devices.
I originally hacked something together that added dm attributes to the
block devices themselves, but that wasn't proper, as it forced the dm
code to dig into the gendisk core too intrusively. With this patch, it
is very easy to make a dm object be a child of the proper struct gendisk
object (which it already is logically, but that representation isn't
exported to userspace yet.) Then, the dm specific attributes of the
gendisk object will show up in sysfs properly, under the associated
block device.
Anyway, Joe, please add this to your set of patches to send on to Linus.
Oh, and why isn't struct mapped_device declared in dm.h? If it was,
dm_get and dm_put could be inlined, along with a few other potential
cleanups.
thanks,
greg k-h
# add kobj support to struct mapped_device
diff -Nru a/drivers/block/genhd.c b/drivers/block/genhd.c
--- a/drivers/block/genhd.c Wed Dec 18 10:39:48 2002
+++ b/drivers/block/genhd.c Wed Dec 18 10:39:48 2002
@@ -475,3 +475,4 @@
EXPORT_SYMBOL(bdev_read_only);
EXPORT_SYMBOL(set_device_ro);
EXPORT_SYMBOL(set_disk_ro);
+EXPORT_SYMBOL(block_subsys);
diff -Nru a/drivers/md/dm.c b/drivers/md/dm.c
--- a/drivers/md/dm.c Wed Dec 18 10:39:48 2002
+++ b/drivers/md/dm.c Wed Dec 18 10:39:48 2002
@@ -41,7 +41,7 @@
struct mapped_device {
struct rw_semaphore lock;
- atomic_t holders;
+ struct kobject kobj;
unsigned long flags;
@@ -60,11 +60,14 @@
*/
struct dm_table *map;
};
+#define to_md(obj) container_of(obj, struct mapped_device, kobj)
#define MIN_IOS 256
static kmem_cache_t *_io_cache;
static mempool_t *_io_pool;
+struct subsystem dm_subsys;
+
static __init int local_init(void)
{
int r;
@@ -94,6 +97,7 @@
if (!_major)
_major = r;
+ subsystem_register(&dm_subsys);
return 0;
}
@@ -106,7 +110,8 @@
DMERR("devfs_unregister_blkdev failed");
_major = 0;
-
+ subsystem_unregister(&dm_subsys);
+
DMINFO("cleaned up");
}
@@ -553,7 +558,8 @@
DMWARN("allocating minor %d.", minor);
memset(md, 0, sizeof(*md));
init_rwsem(&md->lock);
- atomic_set(&md->holders, 1);
+ md->kobj.subsys = &dm_subsys;
+ kobject_init(&md->kobj);
md->queue.queuedata = md;
blk_queue_make_request(&md->queue, dm_request);
@@ -637,17 +643,30 @@
void dm_get(struct mapped_device *md)
{
- atomic_inc(&md->holders);
+ kobject_get(&md->kobj);
}
void dm_put(struct mapped_device *md)
{
- if (atomic_dec_and_test(&md->holders)) {
- DMWARN("destroying md");
- __unbind(md);
- free_dev(md);
- }
+ kobject_put(&md->kobj);
+}
+
+static void dm_release(struct kobject *kobj)
+{
+ struct mapped_device *md = to_md(kobj);
+
+ DMWARN("destroying md");
+ __unbind(md);
+ free_dev(md);
}
+
+extern struct subsystem block_subsys;
+
+struct subsystem dm_subsys = {
+ .kobj = { .name = "dm", .parent = &block_subsys.kobj },
+ .release = dm_release,
+};
+
/*
* Requeue the deferred bios by calling generic_make_request.
^ permalink raw reply
* Invalidate: busy buffer + MD RAID 1
From: Igmar Palsenberg @ 2002-12-18 18:45 UTC (permalink / raw)
To: linux-kernel
Hi,
I get a 'invalidate: busy buffer' about 20 times at reboot. Only at
reboot however.
Setup :
linux-2.4.19 + grsecurity-1.9.7d + acl+xattr 0.8.53 + freeswan (inc. aes
and that kind of stuff)
The machine (Compaq ML350) has 2 scsi devices (sda, sdb) and a RAID 1
setup :
md0 : sda1 + sdb1
md1 : sda3 + sdb3
swap is done on sda2 + sdb2, using default prio's.
Triggering the 'invalidate: busy buffer' is easiest done by letting squid
create it's cache dirs and then rebooting.
No data corruption is occuring (at last not any that a force fsck can
detect), but I removed the RAID1 setup to make sure I sleep well tonight
:)
Looking at the md.c code, line 1708 :
ITERATE_RDEV(mddev,rdev,tmp) {
if (rdev->faulty)
continue;
invalidate_device(rdev->dev, 1);
if (get_hardsect_size(rdev->dev)
> md_hardsect_sizes[mdidx(mddev)])
md_hardsect_sizes[mdidx(mddev)] =
get_hardsect_size(rdev->dev);
}
Looks like it is invalidating the underlying devices (sda[13], sdb[13] in
my case.
Since my RAID array doesn't get screwed I suspect that the md code does
the above again on a do_md_stop(), but I can't find it.
Anyone got any comments on this ??
Regards,
Igmar
Please CC all responses.
--
Igmar Palsenberg
JDI Media Solutions
Helhoek 30
6923PE Groessen
Tel: +31 (0)316 - 596695
Fax: +31 (0)316 - 596699
The Netherlands
mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Horst von Brand @ 2002-12-18 18:41 UTC (permalink / raw)
To: Dave Jones, Horst von Brand, Linus Torvalds, linux-kernel
In-Reply-To: <20021218164119.GC27695@suse.de>
Dave Jones <davej@codemonkey.org.uk> said:
> On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> > [Extremely interesting new syscall mechanism tread elided]
> >
> > What happened to "feature freeze"?
> *bites lip* it's fairly low impact *duck*.
> Given the wins seem to be fairly impressive across the board, spending
> a few days on getting this right isn't going to push 2.6 back any
> noticable amount of time.
Ever hear Larry McVoy's [I think, please correct me if wrong] standard
rant of how $UNIX_FROM_BIG_VENDOR sucks, one "almost unnoticeable
performance impact" feature at a time?
Similarly, Fred Brooks tells in "The Mythical Man Month" how schedules
don't slip by months, they slip a day at a time...
> This stuff is mostly of the case "it either works, or it doesn't".
> And right now, corner cases like apm aside, it seems to be holding up
> so far. This isn't as far reaching as it sounds. There are still
> drivers being turned upside down which are changing things in a
> lot bigger ways than this[1]
>
> Dave
>
> [1] Myself being one of the guilty parties there, wrt agp.
Fixing a broken feature is in for me. Adding new features is supposed to be
out until 2.7 opens.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* RE: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 seri es cards
From: Adam Radford @ 2002-12-18 18:41 UTC (permalink / raw)
To: 'Dave Jones', Nathan Neulinger; +Cc: linux-kernel, uetrecht
Who from 3ware told you it isn't compatible? That's totally bogus.
It's completely compatible.
3ware supports 6, 7, and 8000 series cards with a single driver in
2.2, 2.4, and 2.5 trees.
If it isn't working for you, let me know.
-Adam
-----Original Message-----
From: Dave Jones [mailto:davej@codemonkey.org.uk]
Sent: Wednesday, December 18, 2002 10:26 AM
To: Nathan Neulinger
Cc: linux-kernel@vger.kernel.org; uetrecht@umr.edu
Subject: Re: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00
series cards
On Wed, Dec 18, 2002 at 12:10:54PM -0600, Nathan Neulinger wrote:
> According to 3Ware, the driver in the 2.4.x and (I assume) 2.5.x is no
> longer compatible with the 6xxx series cards.
> I don't know what we'll do with this situation when we move to 2.6, cause
> right now, it looks like we are completely screwed. The old driver
> obviously will not compile on 2.6 since the API's have changed.
Any idea at which point the 2.5 driver stopped working ?
It may not be that much work to bring that version up to date as
a 3ware-old.c driver in a worse-case scenario.
This would be huge code duplication however, and would be much
better fixed by having the driver detect which card its running
on, and 'do the right thing' wrt which firmware it needs.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* problem using jffs2 on DiskOnChip
From: Carl Wolff @ 2002-12-18 19:03 UTC (permalink / raw)
To: linux-mtd
Hello,
I've got a problem with jffs2. I'm using a DiskOnChip module type milennium.
Do I need NFTL support?
I've managed to copy a jffs2 image onto the diskonchip using cp image
/dev/mtd/0.
When I copy the contents of the device to a file using cat /dev/mtd/0 >
testfile and I compare this file with the file just copied to the device,
they are the same, the latter is bigger, because padded with FF's
when I do a mount -t jffs2 /dev/mtd/0 /mnt I get the following output:
# mount -t jffs2 /dev/mtdblock/0 /mnt
mtdblock_open
ok
Short read: 0x10 bytes at 0x000001f0 instead of requested 44
mtdblock_release
ok
mount: Mounting /dev/mtdblock/0 on /mnt failed: Invalid argument
#
What do I wrong?
I use a 2.4.17 kernel with following version details
NFTL driver: nftlcore.c $Revision: 1.85 $, nftlmount.c $Revision: 1.25 $
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00002000 "DiskOnChip Millennium"
#
Thanks for any help
Carl.
^ permalink raw reply
* [PATCH] (2.5;v3) move LOG_BUF_SIZE to header/config
From: Randy.Dunlap @ 2002-12-18 18:31 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Linus,
Patch applies to 2.5.52-bk3.
This makes LOG_BUF_LEN (actually its shift value) a configurable
parameter. It does this by adding a general/common config file
that can use processor-related dependencies. This new Kconfig file
is located in linux/kernel/ and is included at the end of each
arch/*/Kconfig file.
Modified to address comments from Christoph Hellwig, James Cloos,
and Andrew Morton, who likes it.
Please apply.
--
~Randy
On Tue, 17 Dec 2002, Andrew Morton wrote:
| "Randy.Dunlap" wrote:
| >
| > Changes from yesterday:
| >
| > a. use a shift value (suggested by HCH); probably still not as quite
| > as free and open as he suggested, but I had user-friendliness
| > problems with that.
| >
| > b. allow a wider range of values (HCH and James Cloos):
| > smaller added, larger can be added as needed.
| >
| > c. put common config into kernel/Kconfig and include that in each
| > arch/*/Kconfig
| >
| > More comments?
|
| Well I like it. You were missing the arch/ia32/Kconfig include btw...
patch_name: logbuf-configs-2552b.patch
patch_version: 2002.12.17
author: Randy Dunlap <rddunlap@osdl.org>
description: change LOG_BUF_SIZE to a config option (LOG_BUF_SHIFT)
product: linux
product_versions: 2.5.52
changelog: (a) move to a common kernel/Kconfig;
(b) use a SHIFT value (enforces power of 2, gives more choices)
URL:
requires: kconfig in 2.5.52
conflicts:
diffstat:
arch/alpha/Kconfig | 2 +
arch/arm/Kconfig | 2 +
arch/cris/Kconfig | 2 +
arch/i386/Kconfig | 2 +
arch/ia64/Kconfig | 3 ++
arch/m68k/Kconfig | 2 +
arch/m68knommu/Kconfig | 2 +
arch/mips/Kconfig | 2 +
arch/mips64/Kconfig | 2 +
arch/parisc/Kconfig | 2 +
arch/ppc/Kconfig | 2 +
arch/ppc64/Kconfig | 2 +
arch/s390/Kconfig | 2 +
arch/s390x/Kconfig | 2 +
arch/sh/Kconfig | 2 +
arch/sparc/Kconfig | 2 +
arch/sparc64/Kconfig | 2 +
arch/um/Kconfig | 2 +
arch/v850/Kconfig | 2 +
arch/x86_64/Kconfig | 2 +
kernel/Kconfig | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
kernel/printk.c | 11 ---------
22 files changed, 97 insertions(+), 10 deletions(-)
--- ./arch/m68k/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/m68k/Kconfig Tue Dec 17 14:08:33 2002
@@ -2346,3 +2346,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/sparc/Kconfig%LOGBUF Sun Dec 15 18:07:42 2002
+++ ./arch/sparc/Kconfig Tue Dec 17 14:11:06 2002
@@ -1422,3 +1422,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/sparc64/Kconfig%LOGBUF Sun Dec 15 18:08:16 2002
+++ ./arch/sparc64/Kconfig Tue Dec 17 14:11:13 2002
@@ -1710,3 +1710,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/i386/Kconfig%LOGBUF Sun Dec 15 18:07:47 2002
+++ ./arch/i386/Kconfig Tue Dec 17 11:38:46 2002
@@ -1610,3 +1610,5 @@
bool
default y
+source "kernel/Kconfig"
+
--- ./arch/ppc/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/ppc/Kconfig Tue Dec 17 14:10:18 2002
@@ -1872,3 +1872,5 @@
source "crypto/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/m68knommu/Kconfig%LOGBUF Sun Dec 15 18:08:13 2002
+++ ./arch/m68knommu/Kconfig Tue Dec 17 14:08:52 2002
@@ -759,3 +759,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/alpha/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/alpha/Kconfig Tue Dec 17 14:07:34 2002
@@ -1030,3 +1030,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/cris/Kconfig%LOGBUF Sun Dec 15 18:08:19 2002
+++ ./arch/cris/Kconfig Tue Dec 17 14:08:06 2002
@@ -759,3 +759,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/mips/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/mips/Kconfig Tue Dec 17 14:08:59 2002
@@ -1284,3 +1284,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/x86_64/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/x86_64/Kconfig Tue Dec 17 14:11:54 2002
@@ -700,3 +700,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ppc64/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/ppc64/Kconfig Tue Dec 17 14:10:25 2002
@@ -559,3 +559,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/um/Kconfig%LOGBUF Sun Dec 15 18:07:57 2002
+++ ./arch/um/Kconfig Tue Dec 17 14:11:35 2002
@@ -171,3 +171,5 @@
endmenu
+source "kernel/Kconfig"
+
--- ./arch/arm/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/arm/Kconfig Tue Dec 17 14:07:56 2002
@@ -1228,3 +1228,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/parisc/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/parisc/Kconfig Tue Dec 17 14:10:11 2002
@@ -423,3 +423,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ia64/Kconfig%LOGBUF Sun Dec 15 18:08:21 2002
+++ ./arch/ia64/Kconfig Tue Dec 17 14:08:24 2002
@@ -891,3 +891,6 @@
source "security/Kconfig"
source "crypto/Kconfig"
+
+source "kernel/Kconfig"
+
--- ./arch/mips64/Kconfig%LOGBUF Sun Dec 15 18:07:52 2002
+++ ./arch/mips64/Kconfig Tue Dec 17 14:09:07 2002
@@ -727,3 +727,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/s390x/Kconfig%LOGBUF Sun Dec 15 18:07:59 2002
+++ ./arch/s390x/Kconfig Tue Dec 17 14:10:41 2002
@@ -346,3 +346,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/v850/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/v850/Kconfig Tue Dec 17 14:11:46 2002
@@ -452,4 +452,6 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
#############################################################################
--- ./arch/sh/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/sh/Kconfig Tue Dec 17 14:10:52 2002
@@ -1276,3 +1276,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/s390/Kconfig%LOGBUF Sun Dec 15 18:07:54 2002
+++ ./arch/s390/Kconfig Tue Dec 17 14:10:33 2002
@@ -337,3 +337,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./kernel/Kconfig%LOGBUF Tue Dec 17 14:00:31 2002
+++ ./kernel/Kconfig Tue Dec 17 14:28:52 2002
@@ -0,0 +1,55 @@
+# This general setup config file is read _after_ all other config files.
+# It is for generic kernel options that cannot be handled elsewhere,
+# including some generic options that are processor-dependent.
+# This is also _not_ for device driver options.
+# They should be handled in their driver subsystem areas.
+
+menu "Common kernel setup (more)"
+
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_SHIFT_17 if ARCH_S390
+ default LOG_BUF_SHIFT_16 if X86_NUMAQ || IA64
+ default LOG_BUF_SHIFT_15 if SMP
+ default LOG_BUF_SHIFT_14
+ help
+ Select kernel log buffer size from this list (power of 2).
+ Defaults: 17 (=> 128 KB for S/390)
+ 16 (=> 64 KB for x86 NUMAQ or IA-64)
+ 15 (=> 32 KB for SMP)
+ 14 (=> 16 KB for uniprocessor)
+
+config LOG_BUF_SHIFT_17
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_SHIFT_16
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_SHIFT_15
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_SHIFT_14
+ bool "16 KB"
+
+config LOG_BUF_SHIFT_13
+ bool "8 KB"
+
+config LOG_BUF_SHIFT_12
+ bool "4 KB"
+
+endchoice
+
+config LOG_BUF_SHIFT
+ int
+ default 17 if LOG_BUF_SHIFT_17=y
+ default 16 if LOG_BUF_SHIFT_16=y
+ default 15 if LOG_BUF_SHIFT_15=y
+ default 14 if LOG_BUF_SHIFT_14=y
+ default 13 if LOG_BUF_SHIFT_13=y
+ default 12 if LOG_BUF_SHIFT_12=y
+
+endmenu
+
--- ./kernel/printk.c%LOGBUF Sun Dec 15 18:08:24 2002
+++ ./kernel/printk.c Tue Dec 17 14:01:50 2002
@@ -30,16 +30,7 @@
#include <asm/uaccess.h>
-#if defined(CONFIG_X86_NUMAQ) || defined(CONFIG_IA64)
-#define LOG_BUF_LEN (65536)
-#elif defined(CONFIG_ARCH_S390)
-#define LOG_BUF_LEN (131072)
-#elif defined(CONFIG_SMP)
-#define LOG_BUF_LEN (32768)
-#else
-#define LOG_BUF_LEN (16384) /* This must be a power of two */
-#endif
-
+#define LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT) /* This must be a power of two */
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
#ifndef arch_consoles_callable
^ permalink raw reply
* Re: PROBLEM: kernel 2.4.20 option CONFIG_BLK_STATS breaks /proc/partitons so "mount" can't mount devices by UUID.
From: Marcelo Tosatti @ 2002-12-18 15:31 UTC (permalink / raw)
To: Andries Brouwer; +Cc: jiri.wichern, linux-kernel
In-Reply-To: <20021217005539.GA11900@win.tue.nl>
On Tue, 17 Dec 2002, Andries Brouwer wrote:
> On Tue, Dec 17, 2002 at 12:24:50AM +0100, jiri.wichern@hccnet.nl wrote:
>
> > Short description of the problem: You can't mount hard drive
> > volumes by using their UUID number when also using extra
> > statistics for your block devices by the CONFIG_BLK_STATS
> > kernel option.
>
> Yes, we know.
> You use an old version of mount, and the mount will always fail.
>
> Two solutions:
> (i) Do not use CONFIG_BLK_STATS.
> (ii) Upgrade mount to a recent version (mount is part of util-linux,
> recent is for example 2.11y).
>
> Note that solution (ii) gives you a situation where mount and fdisk
> fail sporadically instead of always, maybe not precisely what one
> had hoped. Thus, (i) is the preferred solution.
>
> It was really bad that CONFIG_BLK_STATS went into 2.4.20,
> but you need not use it.
Hi Andries,
Could you please expand on the "sporadically" so we can inform the user in
a better way when he should not use CONFIG_BLK_STATS ?
Mentioning that a newer util-linux is one good thing to be done.
^ permalink raw reply
* RE: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 series cards
From: Neulinger, Nathan @ 2002-12-18 18:29 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel, Uetrecht, Daniel J.
Unfortunately, no... (I don't actually know for certain that 2.5.x is
broke, only that 2.4.x is. The 2.5.x comment is based on the driver
version only.)
They said that that newest version of the driver that should be used
with 6xxx cards is .016. I haven't tried stepping up through the
revisions.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Dave Jones [mailto:davej@codemonkey.org.uk]
> Sent: Wednesday, December 18, 2002 12:26 PM
> To: Neulinger, Nathan
> Cc: linux-kernel@vger.kernel.org; Uetrecht, Daniel J.
> Subject: Re: 3ware driver in 2.4.x and 2.5.x not compatible
> with 6x00 series cards
>
>
> On Wed, Dec 18, 2002 at 12:10:54PM -0600, Nathan Neulinger wrote:
> > According to 3Ware, the driver in the 2.4.x and (I assume)
> 2.5.x is no
> > longer compatible with the 6xxx series cards.
> > I don't know what we'll do with this situation when we
> move to 2.6, cause
> > right now, it looks like we are completely screwed. The old driver
> > obviously will not compile on 2.6 since the API's have changed.
>
> Any idea at which point the 2.5 driver stopped working ?
> It may not be that much work to bring that version up to date as
> a 3ware-old.c driver in a worse-case scenario.
>
> This would be huge code duplication however, and would be much
> better fixed by having the driver detect which card its running
> on, and 'do the right thing' wrt which firmware it needs.
>
> Dave
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
>
^ permalink raw reply
* Re: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 series cards
From: Dave Jones @ 2002-12-18 18:26 UTC (permalink / raw)
To: Nathan Neulinger; +Cc: linux-kernel, uetrecht
In-Reply-To: <20021218181052.GA26465@umr.edu>
On Wed, Dec 18, 2002 at 12:10:54PM -0600, Nathan Neulinger wrote:
> According to 3Ware, the driver in the 2.4.x and (I assume) 2.5.x is no
> longer compatible with the 6xxx series cards.
> I don't know what we'll do with this situation when we move to 2.6, cause
> right now, it looks like we are completely screwed. The old driver
> obviously will not compile on 2.6 since the API's have changed.
Any idea at which point the 2.5 driver stopped working ?
It may not be that much work to bring that version up to date as
a 3ware-old.c driver in a worse-case scenario.
This would be huge code duplication however, and would be much
better fixed by having the driver detect which card its running
on, and 'do the right thing' wrt which firmware it needs.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [Linux-ia64] RTC support on ia64
From: Stephane Eranian @ 2002-12-18 18:18 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805600@msgid-missing>
Joel,
On Wed, Dec 18, 2002 at 04:01:56PM +0100, Joel GUILLET wrote:
>
> On Wed, 18 Dec 2002, Peter Chubb wrote:
>
> > >>>>> "Alex" = Alex Williamson <alex_williamson@hp.com> writes:
> >
> > Alex> Joel, Does this provide more functionality than the EFI RTC?
> > Alex> Concerns I have w/ it on ia64 is that the rtc driver assumes you
> > Alex> have a legacy rtc at the legacy irq and port address. This
> > Alex> won't work on HP zx1 boxes, the legacy hardware doesn't exist.
> > Alex> In the future, there's a possibility that the port address could
> > Alex> be allocated to non-legacy purposes. Maybe ACPI could tell you
> > Alex> if you have a legacy RTC, it could at least tell you if you
> > Alex> support PC/AT compatible interrupts. Thanks,
> >
> Peter> Yes it does. There's no way to get a regular interrupt into user
> Peter> space from the EFI RTC.
>
> The RTC legacy hardware seems to be on the i870 chipset. And if you don't
> have this one, you may not be able to use it.
>
> Peter> I've been using the PMU to generate regular interrupts, and have a
> Peter> locally-modified amlat benchmark that does that.
>
> Did you modify anything inside the kernel to make use of this timer ?
> With PMU, you mean "Performance Monitoring Unit" or "Power Management
> Utility" ? -- this question may look strange but with the acutal high
> resolution timer his ACPI PowerManagement timer, I've finally got some
> doubts.
>
> I had a looked at the PMU code but I couldn't find anything about the way
> of using this timer ? Is it built-in somewhere ?
> Do I need to implement some code in the kernel to use it ? I've
> been trying to find some docs in the Web for quite a long time ... but
> without any results ! Does an user interface already exist ?
>
PMU means Performance Monitoring Unit. What David meant is that you can get
fine grain timer with the PMU by using the CPU_CYCLES event. You can program a
PMU counter to overflow after a certain number of cycles have elapsed. It is
very fine grain because you get down to the cycle. If you setup the counter to
2^64-n, then it will overflow after n cycles. Setting this up is relatively
easy. I encourage you to download the libpfm library. It contains examples
on how to setup counters and get overflow notifications. You can get
the library and also the pfmon monitoring tool from:
ftp://ftp.hpl.hp.com/pub/linux-ia64/libpfm-2.0.tar.gz
ftp://ftp.hpl.hp.com/pub/linux-ia64/pfmon-2.0.tar.gz
These two package are beta versions of the upcoming 2.0 release.
--
-Stephane
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: John Alvord @ 2002-12-18 18:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Jones, Horst von Brand, linux-kernel, Alan Cox,
Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212180844550.29852-100000@home.transmeta.com>
On Wed, 18 Dec 2002 08:49:37 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> wrote:
>
>
>On Wed, 18 Dec 2002, Dave Jones wrote:
>> On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
>> > [Extremely interesting new syscall mechanism tread elided]
>> >
>> > What happened to "feature freeze"?
>>
>> *bites lip* it's fairly low impact *duck*.
>
>However, it's a fair question.
>
>I've been wondering how to formalize patch acceptance at code freeze, but
>it might be a good idea to start talking about some way to maybe put
>brakes on patches earlier, ie some kind of "required approval process".
>
>I think the system call thing is very localized and thus not a big issue,
>but in general we do need to have something in place.
>
>I just don't know what that "something" should be. Any ideas? I thought
>about the code freeze require buy-in from three of four people (me, Alan,
>Dave and Andrew come to mind) for a patch to go in, but that's probably
>too draconian for now. Or is it (maybe start with "needs approval by two"
>and switch it to three when going into code freeze)?
>
> Linus
I think there should be a distinction between changes which make an
API change/new function/user interface change, versus bug fixes,
adapting to new APIs, documentation, etc.
john alvord
^ permalink raw reply
* Re: ALSA update
From: Greg KH @ 2002-12-18 18:21 UTC (permalink / raw)
To: Linux Kernel Mailing List, perex
In-Reply-To: <200212181807.gBII7Wn28845@hera.kernel.org>
> ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, perex@suse.cz
<snip>
> diff -Nru a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
> --- a/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> +++ b/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> @@ -526,7 +526,11 @@
> /*
> * complete callback from data urb
> */
> +#ifndef OLD_USB
> static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
> +#else
> +static void snd_complete_urb(struct urb *urb)
> +#endif
> {
> snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> snd_usb_substream_t *subs = ctx->subs;
> @@ -551,7 +555,11 @@
> /*
> * complete callback from sync urb
> */
> +#ifndef OLD_USB
> static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs)
> +#else
> +static void snd_complete_sync_urb(struct urb *urb)
> +#endif
> {
> snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> snd_usb_substream_t *subs = ctx->subs;
> @@ -583,6 +591,9 @@
Ick, you're kidding me, right? Why do this? Are you trying to keep a
common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend
it, as the code will be sprinkled with these ifdef's...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-18 18:14 UTC (permalink / raw)
To: Jun Sun; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20021218094828.A6061@mvista.com>
On Wed, 18 Dec 2002, Jun Sun wrote:
> > do_IRQ(poll_8259A_irq(), regs);
>
> I actually don't like the new semantic. The main drawback is that we can't
> dispatch a 8259A interrupt from assemably code, which is often needed.
You can't do that with your original code either, unless you arrange a
call to your dispatch_i8259_irq() C function. This can still be done with
a trivial wrapper like:
asmlinkage void foo_dispatch_i8259_irq(struct pt_regs *regs)
{
do_IRQ(poll_8259A_irq(), regs);
}
which results in code like you proposed.
> What is wrong with original way of dispatching? The general interrupt
> dispatching flow is that you chase the routing path until you find the final
> source and do a do_IRQ(). That seems fine with i8259A case here.
It does too much and is therefore useful for a single specific case only.
I focused on handling the chip only and the resulting function may be used
however desired, including your specific case. Not all platforms need to
want to call do_IRQ() immediately after getting an IRQ number, including
code already in existence.
> While there is certain urge to create asm/i8259a.h file, if in the end all there
> is two function declarations (i8259_init() and dispatch_i8259_irq()), it is not
> really worth it.
The header issue is orthogonal -- for lone init_i8259_irqs() it should
exist. Otherwise you'll be doomed upon the next interface change.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Ross Biro @ 2002-12-18 18:19 UTC (permalink / raw)
To: John Bradford; +Cc: D.A.M. Revok, linux-kernel
In-Reply-To: <200212152337.gBFNbZp9002196@darkstar.example.net>
The promise chips often respond to starnge situations by locking up the
PCI bus. In particular they assert the wait signal and do not release
it. This locks the system up had the next time the CPU tries to access
the PCI bus. The machine is dead in your case and needs to be reset.
I've sent a PCI bus trace of this happening to Promise and have not yet
heard anything back yet.
Ross
John Bradford wrote:
>>man, the Magic SysReq key didn't work ( at all ):
>>it were DEAD
>>The drive-light stayed on for 10+ hours, nothing happening ( that I could
>>figure out ) the whole time. It /stayed/ dead.
>>
>>/dev/hde is part of a RAID-5 in my system ( because I no longer trust
>>anything else ), and this only happens on drives connected onto the
>>Promise controller.
>>
>>Oh, yeah, I forgot to include this:
>>trying to touch/activate/read the S.M.A.R.T. in any drive on the Promise
>>kills it, too. Can't activate the reliability-system without killing
>>the kernel? /that's/ ironic, eh?
>>
>>
>>As for having another terminal connected to my home machine...
>>1. if the kernel's dead, then how's that gonna work, and
>>
>>
>
>Maybe just the console was not responding.
>
>If I start X with /dev/null as the core pointer, the console locks
>completely, but I can still log in on a serial terminal.
>
>I have seen machines which will mostly stop responding when you issue
>a sleep command to a disk, E.G.
>
>hdparm -Y /dev/hda
>
>you can't terminate the process with control-C, for example, but if
>you are logged in on another virtual terminal, or have another
>terminal window open in X, you can reset the interface, and the
>machine will respond again.
>
>
>
>>2. why have 2 terminals on one machine when I'm a hermit?
>>
>>
>
>Why not? I read and write a lot of E-Mail on a serial terminal right
>next to my main console, and what about debugging SVGALIB applications?
>
>
>
>>I /do/ thank you for the interface-reset tip, though, I hope I never need
>>that info : )
>>
>>
>
>It can be useful for recovering from a spun-down disk that won't spin
>up again :-)
>
>John
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Problems with running BP 7.0 and a application made with BP
From: Karlheinz Blau @ 2002-12-18 18:10 UTC (permalink / raw)
To: linux-msdos
Hello together,
I tried to start a application on a SuSE 8.1 system.
DOSEMU built-in command.com version 1.0
DOSEMU version is 1.0.2.0, 2001/06/10
FreeDOS kernel version 1.1.24 [Jun 10 2001 22:25:01]
XX-DOS version reported is 5.0
This is my DOSEMU
As we programmed our SYbon with BP 7.0 in 1994 we started it with a former
DOSEMU. So I know, that is could work - but how.
Is there anybody with some help for me?
Thanks al lot
Karlheinz Blau
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.