There's absolutely nothing interesting here, unless you want to play with
KVM, or happened to be bitten by the bug with really old versions of the
linker that made parts of entry.S just go away.
But check it out anyway, and the shortlog gives more details on the
various minor fixes that have accumulated this week. Mostly in random
device drivers.
Linus
---
Adam Megacz (1):
Add AFS_SUPER_MAGIC to magic.h
Adrian Bunk (2):
[NET] drivers/net/loopback.c: convert to module_init()
[X25]: proper prototype for x25_init_timers()
Alan (3):
libata: fix combined mode
atiixp: Old drivers/ide layer driver for the ATIIXP hang fix
hpt37x: Two important bug fixes
Alan Stern (2):
UHCI: make test for ASUS motherboard more specific
UHCI: support device_may_wakeup
Alexey Dobriyan (2):
[NETFILTER] xt_hashlimit.c: fix typo
pata_optidma: typo in Kconfig
Andrew Morton (5):
USB: funsoft is borken on sparc
sisusb_con warning fixes
PCI: disable PCI_MULTITHREAD_PROBE
ip2 warning fix
shrink_all_memory(): fix lru_pages handling
Ard van Breemen (3):
start_kernel: test if irq's got enabled early, barf, and disable them again
kernelparams: detect if and which parameter parsing enabled irq's
PCI: prevent down_read when pci_devices is empty
Arnaud Patard (2):
[ARM] 4065/1: S3C24XX: dma printk fixes
[ARM] 4073/1: Prevent s3c24xx drivers from including asm/arch/hardware.h and asm/arch/irqs.h
Avi Kivity (39):
KVM: Prevent stale bits in cr0 and cr4
KVM: MMU: Implement simple reverse mapping
KVM: MMU: Teach the page table walker to track guest page table gfns
KVM: MMU: Load the pae pdptrs on cr3 change like the processor does
KVM: MMU: Fold fetch_guest() into init_walker()
KVM: MU: Special treatment for shadow pae root pages
KVM: MMU: Use the guest pdptrs instead of mapping cr3 in pae mode
KVM: MMU: Make the shadow page tables also special-case pae
KVM: MMU: Make kvm_mmu_alloc_page() return a kvm_mmu_page pointer
KVM: MMU: Shadow page table caching
KVM: MMU: Write protect guest pages when a shadow is created for them
KVM: MMU: Let the walker extract the target page gfn from the pte
KVM: MMU: Support emulated writes into RAM
KVM: MMU: Zap shadow page table entries on writes to guest page tables
KVM: MMU: If emulating an instruction fails, try unprotecting the page
KVM: MMU: Implement child shadow unlinking
KVM: MMU: kvm_mmu_put_page() only removes one link to the page
KVM: MMU: oom handling
KVM: MMU: Remove invlpg interception
KVM: MMU: Remove release_pt_page_64()
KVM: MMU: Handle misaligned accesses to write protected guest page tables
KVM: MMU: <ove is_empty_shadow_page() above kvm_mmu_free_page()
KVM: MMU: Ensure freed shadow pages are clean
KVM: MMU: If an empty shadow page is not empty, report more info
KVM: MMU: Page table write flood protection
KVM: MMU: Never free a shadow page actively serving as a root
KVM: MMU: Fix cmpxchg8b emulation
KVM: MMU: Treat user-mode faults as a hint that a page is no longer a page table
KVM: MMU: Free pages on kvm destruction
KVM: MMU: Replace atomic allocations by preallocated objects
KVM: MMU: Detect oom conditions and propagate error to userspace
KVM: MMU: Flush guest tlb when reducing permissions on a pte
KVM: MMU: Destroy mmu while we still have a vcpu left
KVM: MMU: add audit code to check mappings, etc are correct
KVM: Improve reporting of vmwrite errors
KVM: Initialize vcpu->kvm a little earlier
KVM: Add missing 'break'
KVM: Don't set guest cr3 from vmx_vcpu_setup()
KVM: MMU: Add missing dirty bit
Bartlomiej Zolnierkiewicz (1):
via82cxxx: fix cable detection
Ben Dooks (1):
[ARM] 4071/1: S3C24XX: Documentation update
Benjamin Herrenschmidt (1):
[SUNGEM]: PHY updates & pause fixes (#2)
Brice Goglin (1):
[CPUFREQ] speedstep-centrino: missing space and bracket
Christoph Hellwig (2):
[XFRM_USER]: avoid pointless void ** casts
Fix BUG at drivers/scsi/scsi_lib.c:1118 caused by "pktsetup dvd /dev/sr0"
Christoph Lameter (1):
Check for populated zone in __drain_pages
Chuck Ebbert (1):
[NETFILTER]: ebtables: don't compute gap before checking struct type
Cyrill V. Gorcunov (1):
qconf: fix SIGSEGV on empty menu items
Dan Williams (1):
[ARM] 4077/1: iop13xx: fix __io() macro
Dave Jones (3):
[CPUFREQ] longhaul: Fix up unreachable code.
[CPUFREQ] longhaul: Kill off warnings introduced by recent changes.
Fix implicit declarations in via-pmu
David Brownell (4):
i2c: Migration aids for i2c_adapter.dev removal
USB: omap_udc build fixes (sync with linux-omap)
rtc-at91rm9200 build fix
Update the rtc-rs5c372 driver
David Hollis (1):
USB: asix: Fix AX88772 device PHY selection
David L Stevens (1):
[IPV4/IPV6]: Fix inet{,6} device initialization order.
David S. Miller (2):
[PKTGEN]: Convert to kthread API.
[SOUND] Sparc CS4231: Use 64 for period_bytes_min
Dmitry Mishin (1):
[NETFILTER]: compat offsets size change
Dor Laor (2):
KVM: Improve interrupt response
KVM: Simplify test for interrupt window
Doug Chapman (1):
ACPI: increase ACPI_MAX_REFERENCE_COUNT for larger systems
Eric Anholt (1):
[AGPGART] fix detection of aperture size versus GTT size on G965
Eric Sandeen (1):
fix memory corruption from misinterpreted bad_inode_ops return values
Erik Jacobson (1):
connector: some fixes for ia64 unaligned access errors
Evgeniy Dushistov (1):
fix garbage instead of zeroes in UFS
Gabriel Mansi (1):
[AGPGART] K8M890 support for amd-k8.
Georg Chini (1):
[SOUND] Sparc CS4231: Fix IRQ return value and initialization.
Gerrit Renker (1):
[TCP]: Use old definition of before
Guillaume Chazarain (2):
ACPI: EC: move verbose printk to debug build only
[CPUFREQ] Uninitialized use of cmd.val in arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:acpi_cpufreq_target()
Hugh Dickins (2):
fix BUG_ON(!PageSlab) from fallback_alloc
fix OOM killing of swapoff
Ingo Molnar (6):
KVM: Fix GFP_KERNEL alloc in atomic section bug
KVM: Use raw_smp_processor_id() instead of smp_processor_id() where applicable
profiling: fix sched profiling typo
KVM: Avoid oom on cr3 switch
KVM: Make loading cr3 more robust
KVM: Simplify mmu_alloc_roots()
James Bursa (1):
adfs: fix filename handling
Jens Axboe (3):
cfq-iosched: merging problem
cdrom: set default timeout to 7 seconds
ide-cd maintainer
Jiri Kosina (1):
HID: fix help texts in Kconfig
Kay Sievers (1):
Driver core: Fix prefix driver links in /sys/module by bus-name
Len Brown (2):
ACPI: fix section mis-match build warning
ACPI: asus_acpi: new MAINTAINER
Lennert Buytenhek (1):
[ARM] 4063/1: ep93xx: fix IRQ_EP93XX_GPIO?MUX numbering
Leonard Norrgård (1):
sound: hda: detect ALC883 on MSI K9A Platinum motherboards (MS-7280)
Linus Torvalds (3):
Revert "[PATCH] x86_64: fix boot hang caused by CALGARY_IOMMU_ENABLED_BY_DEFAULT"
Revert "[PATCH] binfmt_elf: randomize PIE binaries (2nd try)"
Linux 2.6.20-rc4
Mariusz Kozlowski (1):
[AF_NETLINK]: module_put cleanup
Martin Josefsson (1):
[NETFILTER]: nf_nat: fix MASQUERADE crash on device down
Martin Williges (1):
USB: usblp.c - add Kyocera Mita FS 820 to list of "quirky" printers
Matthijs van Otterdijk (1):
fix the toshiba_acpi write_lcd return value
Maxime Bizon (1):
i2c-mv64xxx: Fix random oops at boot
Miguel Angel Alvarez (1):
USB: fix interaction between different interfaces in an "Option" usb device
Nicolas Pitre (2):
[ARM] 4064/1: make pxa_get_cycles() static
[ARM] 4066/1: correct a comment about PXA's sched_clock range
OGAWA Hirofumi (1):
x86_64: Fix dump_trace()
Oliver Neukum (1):
USB: small update to Documentation/usb/acm.txt
Parag Warudkar (1):
selinux: fix selinux_netlbl_inode_permission() locking
Patrick McHardy (2):
[NETFILTER]: Fix routing of REJECT target generated packets in output chain
[NETFILTER]: New connection tracking is not EXPERIMENTAL anymore
Paul Brook (1):
[ARM] 4074/1: Flat loader stack alignment
Paul Mundt (1):
Sanely size hash tables when using large base pages
Pete Zaitcev (1):
USB storage: fix ipod ejecting issue
Phil Dibowitz (1):
USB Storage: unusual_devs: add supertop drives
Philipp Zabel (2):
[ARM] 4080/1: Fix for the SSCR0_SlotsPerFrm macro
[ARM] 4081/1: Add definition for TI Sync Serial Protocol
Philippe De Muyter (1):
i2c/m41t00: Do not forget to write year
Rafael J. Wysocki (1):
swsusp: Do not fail if resume device is not set
Rafa? Bilski (2):
[CPUFREQ] Longhaul - Fix up powersaver assumptions.
[CPUFREQ] Longhaul - Always guess FSB
Randy Dunlap (1):
[CPUFREQ] select consistently
Richard Purdie (3):
[ARM] 4078/1: Fix ARM copypage cache coherency problems
backlight: fix backlight_device_register compile failures
Fix leds-s3c24xx hardware.h reference
Russell King (2):
[ARM] Fix VFP initialisation issue for SMP systems
Fix some ARM builds due to HID brokenness
Sarah Bailey (1):
USB: Fixed bug in endpoint release function.
Segher Boessenkool (1):
Fix insta-reboot with "i386: Relocatable kernel support"
Thomas Hellstrom (2):
[AGPGART] Remove unnecessary flushes when inserting and removing pages.
[AGPGART] Fix PCI-posting flush typo.
Venkatesh Pallipadi (1):
[CPUFREQ] Bug fix for acpi-cpufreq and cpufreq_stats oops on frequency change notification
Vitaly Wool (2):
i2c-pnx: Fix interrupt handler, get rid of EARLY config option
i2c-pnx: Add entry to MAINTAINERS
Vivek Goyal (4):
i386: Restore CONFIG_PHYSICAL_START option
i386: fix modpost warning in SMP trampoline code
i386: fix another modpost warning
i386: modpost smpboot code warning fix
Yoshimi Ichiyanagi (1):
KVM: Recover after an arch module load failure
[email protected] (1):
[AGPGART] drivers/char/agp/sgi-agp.c: check kmalloc() return value
dean gaudet (1):
[NET]: ifb double-counts packets
On Jan 6 2007 22:19, Linus Torvalds wrote:
>Leonard Norrgård (1):
> sound: hda: detect ALC883 on MSI K9A Platinum motherboards (MS-7280)
Something seems to have mangled the name, that should have
been an å not A¥. (Something reencoded it). A gitlog problem?
-`J'
--
On Sun, Jan 07, 2007 at 11:56:01AM +0100, Jan Engelhardt wrote:
> On Jan 6 2007 22:19, Linus Torvalds wrote:
>
> >Leonard Norrgård (1):
> > sound: hda: detect ALC883 on MSI K9A Platinum motherboards (MS-7280)
>
> Something seems to have mangled the name, that should have
> been an ? not A?. (Something reencoded it). A gitlog problem?
That is an ? if you look at the raw message in UTF-8. However, Linus
sends mail in with a charset of ISO-8859-1, and if you place UTF-8
encoded text in such a message body, you will see A?.
Welcome to the mess which the UTF-8 charset creates.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 1/7/07, Linus Torvalds <[email protected]> wrote:
>
> There's absolutely nothing interesting here, unless you want to play with
> KVM, or happened to be bitten by the bug with really old versions of the
> linker that made parts of entry.S just go away.
>
> But check it out anyway, and the shortlog gives more details on the
> various minor fixes that have accumulated this week. Mostly in random
> device drivers.
Linus,
I can't find 2.6.20-rc4 on the kernel.org home page. Latest shows as:-
The latest prepatch for the stable Linux kernel tree is: 2.6.20-rc3
2007-01-01 01:15 UTC
Is there any problem here?
> Linus
~Akula2
On Sun, Jan 07, 2007 at 05:45:28PM +0530, Akula2 wrote:
> I can't find 2.6.20-rc4 on the kernel.org home page. Latest shows as:-
>
> The latest prepatch for the stable Linux kernel tree is: 2.6.20-rc3
> 2007-01-01 01:15 UTC
>
> Is there any problem here?
See the thread "kernel.org lies about latest -mm kernel" on this mailing
list.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Russell King schrieb:
[Leonard Norrgård (1):]
> That is an å if you look at the raw message in UTF-8. However, Linus
> sends mail in with a charset of ISO-8859-1, and if you place UTF-8
> encoded text in such a message body, you will see A¥.
Only if the mechanism used for placing it there ignores the different
encodings.
> Welcome to the mess which the UTF-8 charset creates.
The problem of different character encodings coexisting on the same
platform, and the resulting occasional messing-up, far predates Unicode.
I distinctly remember one case of being bitten by this myself in 1977
when Unicode wasn't even on the horizon yet, and I don't think that was
the first time.
Tilman
On Sun, 7 Jan 2007 11:56:01 +0100 (MET)
Jan Engelhardt <[email protected]> wrote:
>
>
> On Jan 6 2007 22:19, Linus Torvalds wrote:
>
> >Leonard Norrgård (1):
> > sound: hda: detect ALC883 on MSI K9A Platinum motherboards (MS-7280)
>
> Something seems to have mangled the name, that should have
> been an å not A¥. (Something reencoded it). A gitlog problem?
Git tree is fine, Linus has a wonky mailer (that or a problem between
keyboard and chair 8)) that sends UTF-8 data in ISO 8859-1 marked email.
On 1/7/07, Russell King <[email protected]> wrote:
>
> See the thread "kernel.org lies about latest -mm kernel" on this mailing
> list.
Russell,
I have read the thread, big thanks to you for the inputs.
Honestly I didn't understand much about the git internal working
except getdents () @ HPA & Linus replies. This is incredible indeed.
I didn't understand these lines posted by John 'Warthog9' Hawley:-
"On average we are moving anywhere from 400-600mbps between the two
machines, on release days we max both of the connections at 1gpbs each
and have seen that draw last for 48hours. For instance when FC6 was
released in the first 12 hours or so we moved 13 TBytes of data"
What FC6 release has to do with moving of 13 TB of data? :O
Apologies if I've embarassed you guys with my question.
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
~Akula2
On Sun, Jan 07, 2007 at 07:08:47PM +0530, Akula2 wrote:
> On 1/7/07, Russell King <[email protected]> wrote:
> >
> >See the thread "kernel.org lies about latest -mm kernel" on this mailing
> >list.
>
> Russell,
>
> I have read the thread, big thanks to you for the inputs.
> Honestly I didn't understand much about the git internal working
> except getdents () @ HPA & Linus replies. This is incredible indeed.
>
> I didn't understand these lines posted by John 'Warthog9' Hawley:-
>
> "On average we are moving anywhere from 400-600mbps between the two
> machines, on release days we max both of the connections at 1gpbs each
> and have seen that draw last for 48hours. For instance when FC6 was
> released in the first 12 hours or so we moved 13 TBytes of data"
>
> What FC6 release has to do with moving of 13 TB of data? :O
There are distro mirrors on kernel.org, and the most famous ones
are downloaded by huge number of people on their release day. What
John explained is that the cumulated downloads during the 12 first
hours after FC6 releases totalized 13 TB of data sent to the net,
which is indeed 2 gig links at full load. Impressive !
Willy
On 1/7/07, Willy Tarreau <[email protected]> wrote:
>
> There are distro mirrors on kernel.org, and the most famous ones
> are downloaded by huge number of people on their release day. What
> John explained is that the cumulated downloads during the 12 first
> hours after FC6 releases totalized 13 TB of data sent to the net,
> which is indeed 2 gig links at full load. Impressive !
Hmm got you. If that's the case can't we do away with the distro
mirrors since we have many mirrors & torrents? In this fashion we can
reduce huge loads I guess.
Or, is it sentimental to have a distro mirror on kernel.org because
this is the core kernel developer site?
>
> Willy
~Akula2
On Sun, 2007-01-07 at 14:06 +0100, Tilman Schmidt wrote:
> Russell King schrieb:
> > Welcome to the mess which the UTF-8 charset creates.
Utter bollocks.
> The problem of different character encodings coexisting on the same
> platform, and the resulting occasional messing-up, far predates Unicode.
> I distinctly remember one case of being bitten by this myself in 1977
> when Unicode wasn't even on the horizon yet, and I don't think that was
> the first time.
Indeed. If you take arbitrary content and send it out to the world
labelled as ISO8859-1, of _course_ you're likely to be corrupting it.
Far from being the cause of the problem, UTF-8 actually offers the
chance of a _solution_. Because once the Luddites catch up, it'll
largely eliminate the need for using the multitude of legacy character
sets and converting between them -- and the problem of mislabelling will
fairly much go away.
--
dwmw2
On Sun, Jan 07, 2007 at 11:13:57PM +0800, David Woodhouse wrote:
> On Sun, 2007-01-07 at 14:06 +0100, Tilman Schmidt wrote:
> > Russell King schrieb:
> > > Welcome to the mess which the UTF-8 charset creates.
>
> Utter bollocks.
Wrong. The problem is partly caused by not everything understanding
multi-byte character encodings, and text files containing absolutely
_no_ information about their character encodings.
When a text file is stored on disk, there's no way to tell what
character set the characters in that file belong to. As a result,
ISO-8859-1 folk assume that all text files are ISO-8859-1 encoded.
UTF-8 folk assume all text files are UTF-8 encoded. This leads to
utter confusion.
To see what I mean, try the following:
$ git log | head -n 1000 > o
$ file -i o
o: text/x-c; charset=iso-8859-1
According to that, the charset of the 'git log' output (which on that
test included Leonard's entry) is iso-8859-1, and by that Linus' mailer
was right to include it as ISO-8859-1.
In reality, the output from git log contains an ad-hoc collection of
character sets making its interpretation under any one character set
incorrect.
> > The problem of different character encodings coexisting on the same
> > platform, and the resulting occasional messing-up, far predates Unicode.
> > I distinctly remember one case of being bitten by this myself in 1977
> > when Unicode wasn't even on the horizon yet, and I don't think that was
> > the first time.
>
> Indeed. If you take arbitrary content and send it out to the world
> labelled as ISO8859-1, of _course_ you're likely to be corrupting it.
>
> Far from being the cause of the problem, UTF-8 actually offers the
> chance of a _solution_. Because once the Luddites catch up, it'll
> largely eliminate the need for using the multitude of legacy character
> sets and converting between them -- and the problem of mislabelling will
> fairly much go away.
In other words, the UTF-8 luddites require the entire Internet to
upgrade to UTF-8 for UTF-8 to work properly.
I _regularly_ struggle with idiotic programs that assume that the world
is UTF-8 and nothing else. UTF-8 does _not_ solve these inter-operability
problems - it only makes the entire situation worse by introducing yet
another different charset. (Yes, it's also true that there are programs
which assume the world is only another, different, character set.)
Rather than having these problems fixed properly (by looking at the LANG
environment variable) many of these programs now assume that the world
is UTF-8. It isn't.
elinks is one such program. It now assumes UTF-8 _only_ displays.
That's no better than programs which assume ISO-8859-1 only or US-ASCII
only.
So, in short, UTF-8 is all fine and dandy if your _entire_ universe
is UTF-8 enabled. If you're operating in a mixed charset environment
it's one bloody big pain in the butt.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Sun, 2007-01-07 at 15:38 +0000, Russell King wrote:
> On Sun, Jan 07, 2007 at 11:13:57PM +0800, David Woodhouse wrote:
> > On Sun, 2007-01-07 at 14:06 +0100, Tilman Schmidt wrote:
> > > Russell King schrieb:
> > > > Welcome to the mess which the UTF-8 charset creates.
> >
> > Utter bollocks.
>
> Wrong. The problem is partly caused by not everything understanding
> multi-byte character encodings,
No, that's a different problem; not the one you were referring to above.
And it's a problem which is rapidly diminishing, too.
> and text files containing absolutely
> _no_ information about their character encodings.
That's a real problem, yes -- but it was a problem long before UTF-8 was
added to the collection of character sets in use. Even within the UK, we
had to choose between ISO8859-1 and ISO8859-15.
> When a text file is stored on disk, there's no way to tell what
> character set the characters in that file belong to. As a result,
> ISO-8859-1 folk assume that all text files are ISO-8859-1 encoded.
> UTF-8 folk assume all text files are UTF-8 encoded. This leads to
> utter confusion.
Only if you are making different assumptions about the _same_ set of
files, on the _same_ system. But that would be silly.
If I suddenly "assume" that my laptop has a Dvorak keyboard layout
despite that blatantly not being true, I'll get the same kind of
confusion. That isn't Dvorak's fault, either.
If, on the other hand, I have one system which is entirely ISO8859-1 and
a separate system which is entirely UTF-8, each of those are _fine_ and
unconfusing. Obviously I have to make sure files are properly labelled
and converted in transport between different systems -- but that's
nothing new.
> To see what I mean, try the following:
>
> $ git log | head -n 1000 > o
> $ file -i o
> o: text/x-c; charset=iso-8859-1
>
> According to that, the charset of the 'git log' output (which on that
> test included Leonard's entry) is iso-8859-1, and by that Linus' mailer
> was right to include it as ISO-8859-1.
Yes. When you stored it on disk, the character set information was lost.
If you were running a mixed-charset system then attempting to recreating
the lost information with heuristics and assumptions is obviously going
to be problematic.
Actually, because UTF-8 allows me to run a system which is purely based
on a single character set, I get better results when I try the same
trick:
shinybook /shiny/git/mtd-2.6 $ git log | head -n 1000 > o
shinybook /shiny/git/mtd-2.6 $ file -i o
o: text/plain; charset=utf-8
Again, the problem of labelling isn't at all new to UTF-8. The only
thing that's new with UTF-8 is that it's now actually _practical_ to
have a system which only uses one character set throughout, and which
thus _can_ get its 'guess' right when you don't bother to label
everything.
> In reality, the output from git log contains an ad-hoc collection of
> character sets making its interpretation under any one character set
> incorrect.
No, the contents of the git log ought to be UTF-8, unless people have
been misusing it. Git stores its text in UTF-8 (by default), and is
capable of converting to and from legacy character sets on input
(git-commit) and output (git-log).
(Obviously, that's likely to be lossy if you convert it to any given
legacy character set, because ∀ legacy character set, ∃ characters
within UTF-8 that aren't in that legacy character set.)
> > Far from being the cause of the problem, UTF-8 actually offers the
> > chance of a _solution_. Because once the Luddites catch up, it'll
> > largely eliminate the need for using the multitude of legacy character
> > sets and converting between them -- and the problem of mislabelling will
> > fairly much go away.
>
> In other words, the UTF-8 luddites require the entire Internet to
> upgrade to UTF-8 for UTF-8 to work properly.
Not at all. The problems arise when character set information is lost,
which can happen at any point during the flow of information.
Anything we can do to reduce the likelihood of charset information being
lost is an overall improvement. We already demonstrated an example
(git-log > o; file -i o) of a case where a _consistent_ system gets it
right, while an inconsistent system introduces an error.
If any individual system processes all text in a single character set,
then that system is no longer a likely source of corruption due to
labelling errors. And because UTF-8 fully covers the set of characters
which can be represented in the legacy character sets, it allows us to
deploy systems which do just that.
> I _regularly_ struggle with idiotic programs that assume that the world
> is UTF-8 and nothing else.
I don't think I've encountered such a program in my distribution of
choice. If I had, I would have filed a bug. Making assumptions about
character sets, outside of the locally-controlled environment, is
invalid. That's been true since the first 8-bit character sets, if not
longer.
> So, in short, UTF-8 is all fine and dandy if your _entire_ universe
> is UTF-8 enabled. If you're operating in a mixed charset environment
> it's one bloody big pain in the butt.
A mixed charset environment was _already_ a pain in the butt, because
almost nobody got labelling right. It's wrong to blame that on UTF-8.
--
dwmw2
On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> On Sun, 2007-01-07 at 15:38 +0000, Russell King wrote:
> > When a text file is stored on disk, there's no way to tell what
> > character set the characters in that file belong to. As a result,
> > ISO-8859-1 folk assume that all text files are ISO-8859-1 encoded.
> > UTF-8 folk assume all text files are UTF-8 encoded. This leads to
> > utter confusion.
>
> Only if you are making different assumptions about the _same_ set of
> files, on the _same_ system. But that would be silly.
$ git log | head -n 1000 | tail -n 200 > o
$ file -i o
o: text/plain; charset=us-ascii
$ git log | head -n 1000 | tail -n 300 > o
$ file -i o
o: text/plain; charset=us-ascii
$ git log | head -n 1000 | tail -n 400 > o
$ file -i o
o: text/plain; charset=utf-8
(and you know what charset the file is thought to have with all 1000
lines in it.)
All on a system with LANG set to en_GB (iow ISO-8859-1).
> > To see what I mean, try the following:
> >
> > $ git log | head -n 1000 > o
> > $ file -i o
> > o: text/x-c; charset=iso-8859-1
> >
> > According to that, the charset of the 'git log' output (which on that
> > test included Leonard's entry) is iso-8859-1, and by that Linus' mailer
> > was right to include it as ISO-8859-1.
>
> Yes. When you stored it on disk, the character set information was lost.
The same thing actually happens when I look at it via:
$ git log | head -n 1000 | less
but in this case the output is always interpreted by the terminal to be
in its character set.
> If you were running a mixed-charset system then attempting to recreating
> the lost information with heuristics and assumptions is obviously going
> to be problematic.
I'm not - I'm running a pure ISO-8859-1 system:
$ echo $LANG
en_GB
$ locale -k LC_CTYPE | grep charmap
charmap="ISO-8859-1"
> Actually, because UTF-8 allows me to run a system which is purely based
> on a single character set, I get better results when I try the same
> trick:
> shinybook /shiny/git/mtd-2.6 $ git log | head -n 1000 > o
> shinybook /shiny/git/mtd-2.6 $ file -i o
> o: text/plain; charset=utf-8
$ LANG=en_GB.UTF-8 locale -k LC_CTYPE | grep charmap
charmap="UTF-8"
$ LANG=en_GB.UTF-8 git log | head -n 1000 > o
$ LANG=en_GB.UTF-8 file -i o
o: text/x-c; charset=iso-8859-1
$ git version
git version 1.4.4.2
Looks like the output is iso-8859-1 even with UTF-8!
> > In reality, the output from git log contains an ad-hoc collection of
> > character sets making its interpretation under any one character set
> > incorrect.
>
> No, the contents of the git log ought to be UTF-8, unless people have
> been misusing it. Git stores its text in UTF-8 (by default), and is
> capable of converting to and from legacy character sets on input
> (git-commit) and output (git-log).
Git may store its text internally in UTF-8 (I don't know but I have no
evidence to suggest it does - in fact I have some evidence in this test
that it doesn't care about charsets.) git log output on a non-UTF-8
system certainly is not in the hosts character set. For example:
$ LANG=en_GB.UTF-8 git log | head -n 1000 > o
$ LANG=en_GB git log | head -n 1000 > o2
$ diff -u o o2
That includes the UTF-8 encoded part of Leonard name. It also includes
Rafa? Bilski's name which is non-UTF-8 encoded.
So, in both cases, exactly the same output bytestream was created
independent of the character set _actually_ being used, which both
includes untranslated UTF-8 and non-UTF-8 sequences.
There is obviously no character set translation going on with the output.
So we can add 'git' to my list of charset-broken programs.
Also, since we have recent data in the git repository which is non-UTF-8
as well, it is clear that there is no character set translation going on
at input time either.
Looking at the git-commit script, there appears to be no character set
conversion going on in there either.
So, I think you'll find that the contents of git _is_ an ad-hoc collection
of character sets which people happen to have in use on their machines.
> > So, in short, UTF-8 is all fine and dandy if your _entire_ universe
> > is UTF-8 enabled. If you're operating in a mixed charset environment
> > it's one bloody big pain in the butt.
>
> A mixed charset environment was _already_ a pain in the butt, because
> almost nobody got labelling right. It's wrong to blame that on UTF-8.
I'm not talking about a mixed charset environment. I'm talking about
non-UTF-8 single charset environments being broken by programs which
universally think the universe is UTF-8 only.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
> So, in short, UTF-8 is all fine and dandy if your _entire_ universe
> is UTF-8 enabled. If you're operating in a mixed charset environment
> it's one bloody big pain in the butt.
Net ASCII is 7bit and is 1:1 mapped with UTF-8 unicode. It's just old
broken 8bit encodings that are problematic.
The kernel maintainers/help/config pretty consistently use UTF8
On Jan 7 2007 17:06, Russell King wrote:
>On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
>
>$ git log | head -n 1000 | tail -n 200 > o
>$ file -i o
>o: text/plain; charset=us-ascii
>$ git log | head -n 1000 | tail -n 300 > o
>$ file -i o
>o: text/plain; charset=us-ascii
>$ git log | head -n 1000 | tail -n 400 > o
>$ file -i o
>o: text/plain; charset=utf-8
I am inclined to say that "file" does not count, because it tries to guess an
ambiguous mapping from bytes to character set. Even more, file should be
_unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
file. This program is soo... forget it, it's not an argument. It works well for
headerful files, but text files don't really contain one. The next best thing
would be html, with a proper <meta http-equiv=Content> tag.
-`J'
--
On Jan 7 2007 18:21, Alan wrote:
>
>> So, in short, UTF-8 is all fine and dandy if your _entire_ universe
>> is UTF-8 enabled. If you're operating in a mixed charset environment
>> it's one bloody big pain in the butt.
>
>Net ASCII is 7bit and is 1:1 mapped with UTF-8 unicode. It's just old
>broken 8bit encodings that are problematic.
>
>The kernel maintainers/help/config pretty consistently use UTF8
I've seen a lot of places that don't do so. Want a patch?
-`J'
--
On Sun, Jan 07, 2007 at 06:21:51PM +0000, Alan wrote:
> > So, in short, UTF-8 is all fine and dandy if your _entire_ universe
> > is UTF-8 enabled. If you're operating in a mixed charset environment
> > it's one bloody big pain in the butt.
>
> Net ASCII is 7bit and is 1:1 mapped with UTF-8 unicode.
The same is true of ISO-8859-1.
> It's just old broken 8bit encodings that are problematic.
>
> The kernel maintainers/help/config pretty consistently use UTF8
As I've tried to point out, that's not universally true. For instance:
commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32
tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6
parent 264166e604a7e14c278e31cadd1afb06a7d51a11
author Rafa? Bilski <[email protected]> 1167691774 +0100
committer Dave Jones <[email protected]> 1167799119 -0500
and looking at that "author" closer with od:
0000140 74 68 6f 72 20 52 61 66 61 b3 20 42 69 6c 73 6b
t h o r R a f a ? B i l s k
clearly not UTF-8. I doubt whether any of the commits I do on my
en_GB ISO-8859-1 systems end up being UTF-8 encoded.
And _this_ is the problem when it comes to generating the logs,
irrespective of whether or not Linus loads UTF-8 data into an
ISO-8859-1 message. For all we know, Linus' system could be using
an ISO-8859 charset rather than UTF-8.
But the point is there is charset damage which has happened _long_ before
Linus' action. There is no character set defined for the contents of git
repositories, and as such the output of the git tools can not be
interpreted as any one single character set.
All that UTF-8 has done is added to the "which charset is this data"
problem rather than actually solving any proper real life problem.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
>
> On Jan 7 2007 17:06, Russell King wrote:
> >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> >
> >$ git log | head -n 1000 | tail -n 200 > o
> >$ file -i o
> >o: text/plain; charset=us-ascii
> >$ git log | head -n 1000 | tail -n 300 > o
> >$ file -i o
> >o: text/plain; charset=us-ascii
> >$ git log | head -n 1000 | tail -n 400 > o
> >$ file -i o
> >o: text/plain; charset=utf-8
>
> I am inclined to say that "file" does not count, because it tries to guess an
> ambiguous mapping from bytes to character set. Even more, file should be
> _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> file. This program is soo... forget it, it's not an argument. It works well for
> headerful files, but text files don't really contain one. The next best thing
> would be html, with a proper <meta http-equiv=Content> tag.
You're discarding a perfectly reasonable argument - file itself obviously
is not good at guessing the charset, but inspecting the resulting file
manually and identifying *both* ISO-8859 and UTF-8 character sequences
in there is pretty conclusive. As I did indeed do prior to sending
that message.
In this case, 'file' was doing a remarkably accurate job.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Am 07.01.2007 18:06 schrieb Russell King:
>
> $ git log | head -n 1000 | tail -n 200 > o
> $ file -i o
> o: text/plain; charset=us-ascii
> $ git log | head -n 1000 | tail -n 300 > o
> $ file -i o
> o: text/plain; charset=us-ascii
> $ git log | head -n 1000 | tail -n 400 > o
> $ file -i o
> o: text/plain; charset=utf-8
>
> (and you know what charset the file is thought to have with all 1000
> lines in it.)
What the "file" command thinks is hardly relevant here. "file" just
attempts to guess what the contents of a file might be, by applying
a simple set of heuristics. Your results only highlight the actual
problem: "git" is apparently unable to handle character sets properly
and instead produces a mix of encodings as output.
> All on a system with LANG set to en_GB (iow ISO-8859-1).
For software with proper multilingual support, that should have been
enough to make sure that all its output would be in iso-8859-1, too.
Obviously "git" doesn't fall into that category.
>> Yes. When you stored it on disk, the character set information was lost.
>
> The same thing actually happens when I look at it via:
>
> $ git log | head -n 1000 | less
The loss has happened long before you run that command, when the
data was committed into "git".
> So, I think you'll find that the contents of git _is_ an ad-hoc collection
> of character sets which people happen to have in use on their machines.
Exactly.
>> A mixed charset environment was _already_ a pain in the butt, because
>> almost nobody got labelling right. It's wrong to blame that on UTF-8.
>
> I'm not talking about a mixed charset environment. I'm talking about
> non-UTF-8 single charset environments being broken by programs which
> universally think the universe is UTF-8 only.
The problem is not programs thinking the universe is UTF-8 only; it's
people mixing different charsets, in conjunction with programs not
caring about charsets at all.
Specifically, your non-UTF-8 single charset environment was not broken
by git thinking everything was UTF-8, but to the contrary by some data
in the git repository actually being UTF-8 and git *not* thinking that.
And that problem is, I repeat, much older than UTF-8.
HTH
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On Sun, Jan 07, 2007 at 07:17:30PM +0000, Russell King wrote:
> commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32
> tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6
> parent 264166e604a7e14c278e31cadd1afb06a7d51a11
> author Rafa³ Bilski <[email protected]> 1167691774 +0100
> committer Dave Jones <[email protected]> 1167799119 -0500
>
> and looking at that "author" closer with od:
>
> 0000140 74 68 6f 72 20 52 61 66 61 b3 20 42 69 6c 73 6b
> t h o r R a f a ³ B i l s k
>
> clearly not UTF-8. I doubt whether any of the commits I do on my
> en_GB ISO-8859-1 systems end up being UTF-8 encoded.
This has been bugging me for a while.
Viewing the mail I applied in mutt shows his name correctly as Rafał
Applying it with git-applymbox and viewing the log on master.kernel.org
with git log shows Rafa<B3> And then later when put into email
it turns into Rafa³
> But the point is there is charset damage which has happened _long_ before
> Linus' action. There is no character set defined for the contents of git
> repositories, and as such the output of the git tools can not be
> interpreted as any one single character set.
If there's something I should be doing when I commit that I'm not,
I'll be happy to change my scripts. My $LANG is set to en_US.UTF-8
which should DTRT to the best of my knowledge, but clearly, that isn't
the case.
Dave
--
http://www.codemonkey.org.uk
On Sun, 7 Jan 2007 15:05:53 -0500
Dave Jones <[email protected]> wrote:
Including the Git list...
> On Sun, Jan 07, 2007 at 07:17:30PM +0000, Russell King wrote:
>
> > commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32
> > tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6
> > parent 264166e604a7e14c278e31cadd1afb06a7d51a11
> > author Rafa³ Bilski <[email protected]> 1167691774 +0100
> > committer Dave Jones <[email protected]> 1167799119 -0500
> >
> > and looking at that "author" closer with od:
> >
> > 0000140 74 68 6f 72 20 52 61 66 61 b3 20 42 69 6c 73 6b
> > t h o r R a f a ³ B i l s k
> >
> > clearly not UTF-8. I doubt whether any of the commits I do on my
> > en_GB ISO-8859-1 systems end up being UTF-8 encoded.
>
> This has been bugging me for a while.
> Viewing the mail I applied in mutt shows his name correctly as Rafał
> Applying it with git-applymbox and viewing the log on master.kernel.org
> with git log shows Rafa<B3> And then later when put into email
> it turns into Rafa³
>
> > But the point is there is charset damage which has happened _long_ before
> > Linus' action. There is no character set defined for the contents of git
> > repositories, and as such the output of the git tools can not be
> > interpreted as any one single character set.
>
> If there's something I should be doing when I commit that I'm not,
> I'll be happy to change my scripts. My $LANG is set to en_US.UTF-8
> which should DTRT to the best of my knowledge, but clearly, that isn't
> the case.
s?ndag 07 januari 2007 20:17 skrev Russell King:
[...]
> clearly not UTF-8. I doubt whether any of the commits I do on my
> en_GB ISO-8859-1 systems end up being UTF-8 encoded.
They don't. Git doesn't convert, with the exception of two mail-related tools,
which is the reason the commit being discussed ended up as UTF-8
in GIT. The mail containing the patch was in ISO-8859-1. All other git tools
just store whatever byte sequence they are fed, be ut ISO-latin, utf-8 or
something (to westeners) more exotic.
-- robin
>On Sun, 7 Jan 2007 15:05:53 -0500
>Dave Jones <[email protected]> wrote:
>
>> If there's something I should be doing when I commit that I'm not,
>> I'll be happy to change my scripts. My $LANG is set to en_US.UTF-8
>> which should DTRT to the best of my knowledge, but clearly, that isn't
>> the case.
No, LC_CTYPE defines what charset you use. (I may be wrong, though.)
-`J'
--
On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
>
> On Jan 7 2007 17:06, Russell King wrote:
> >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> >
> >$ git log | head -n 1000 | tail -n 200 > o
> >$ file -i o
> >o: text/plain; charset=us-ascii
> >$ git log | head -n 1000 | tail -n 300 > o
> >$ file -i o
> >o: text/plain; charset=us-ascii
> >$ git log | head -n 1000 | tail -n 400 > o
> >$ file -i o
> >o: text/plain; charset=utf-8
>
> I am inclined to say that "file" does not count, because it tries to guess an
> ambiguous mapping from bytes to character set. Even more, file should be
> _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> file. This program is soo... forget it, it's not an argument. It works well for
> headerful files, but text files don't really contain one. The next best thing
> would be html, with a proper <meta http-equiv=Content> tag.
The stupidity from the start up with those character sets is that they
consider that a whole file is written with a given set. In fact, the
charset should apply to characters themselves. At least, the
quoted-printable, non-human friendly, encoding was the least stupid.
Now that UTF8 comes everywhere, everyone receives tons of mangled mails,
and even mailers which correctly support UTF8 and use it by default manage
to shoot themselves in the foot when they reply to, or forward a mail. The
system is completely broken because limited by design, and we have to learn
to live with this brokenness.
Willy
Peter Osterlund <[email protected]> writes:
> Linus Torvalds <[email protected]> writes:
>
> > Patrick McHardy (2):
> > [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore
>
> I get kernel panics when doing large ethernet transfers. A loop doing
I also see an annoying side effect of this bug. When the panic
happens, the caps lock LED starts to blink, and the kernel prints this
on the console once every second (or more often, don't know exactly):
printk(KERN_WARNING "atkbd.c: Spurious %s on %s. "
"Some program might be trying access hardware directly.\n",
data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys);
This makes the actual crash information disappear before you have a
chance to read it.
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
Le dimanche 07 janvier 2007 ? 21:40 +0100, Jan Engelhardt a ?crit :
> >On Sun, 7 Jan 2007 15:05:53 -0500
> >Dave Jones <[email protected]> wrote:
> >
> >> If there's something I should be doing when I commit that I'm not,
> >> I'll be happy to change my scripts. My $LANG is set to en_US.UTF-8
> >> which should DTRT to the best of my knowledge, but clearly, that isn't
> >> the case.
>
> No, LC_CTYPE defines what charset you use. (I may be wrong, though.)
IIRC LANG is a superset for all LC_* - i.e. if only LANG is defined, it
sets all your locales, but you can individually set the charset, numeric
format, date format, etc.
Xav
On Sunday 07 January 2007 01:19, Linus Torvalds wrote:
>There's absolutely nothing interesting here, unless you want to play
Running on FC6, all uptodate as of yesterday, using LVM on an XP-2800
Athlon & a gig of ram.
First boot of 2.6.20-rc4 here, in the messages scrolling by, the nptd
startup failed. But after fully booting and x was started, a restart
worked, albeit it took several seconds for the startup phase. NDI if it
means anything or not.
And maybe I'm seeing the effects of this ext3 bug that's hurting
kernel.org here, it seems the x startup has everything 100% serialized
now and that's slow as snails. A good 15-17 seconds from the background
image being loaded to all the shells reopened I left open when I logged
out of x, and gkrellm is all restarted. With a cpu running at 2.1 ghz,
and a 333mhz FSB, I'd think that should be 2, maybe 3 seconds. And I
think I can recall times like that when I was running ext2 in a past
life. I'm hoping whatever fixes kernel.org will filter back to us peons
in due time.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
Linus Torvalds <[email protected]> writes:
> Patrick McHardy (2):
> [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore
I get kernel panics when doing large ethernet transfers. A loop doing
continuous scp transfers of some large (>100MB) files makes the kernel
crash after a few minutes. scp runs on a different machine and copies
data from the machine that crashes. (The first crash did not happen
when scp was used, but scp is an easy way to reproduce the problem.)
I've seen this crash also with 2.6.20-rc2-git-something. Previously I
ran these kernels quite a lot and used a ppp link without problems.
Today I started using eth0 and the crashes started to occur. I have
netfilter rules for ppp0, but no rules for eth0. Earlier kernels have
been working perfectly for large eth0 transfers on this machine.
Hand copied data from the console:
BUG: unable to handle kernel paging request at virtual address 9f5cea9f
printing eip:
c034c729
*pde = 00000000
Ooops: 0000 [#1]
PREEMPT
Modules linked in: ... 8139too ...
CPU: 0
EIP: 0060:[<c034c729>] Not tainted VLI
EFALLGS: 00010206 (2.6.20-rc4 #13)
EIP is at ipv4_conntrack_help+0x6b/0x83
eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 00000014
esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, ti=c0474000 task=c0437500 task.ti=c0474000)
Stack: 00000001 9f5cea37 c0463a6c c0475e1c c0471a48 c0475dfc c0308269 00000000
c0318767 00000001 c0475e44 00000001 c0475e44 c0471a48 c0475e2c c03083a8
df391800 00000000 c0475e1c c0318767 80000000 00000002 c0463a6c df391800
Call Trace:
show_trace_log_lvl+0x1a/0x30
show_stack_log_lvl+0xa5/0xca
show_registers+0x1e2/0x343
die+0x10b/0x228
do_page_fault+0x2b9/0x5f6
error_code+0x74/0x7c
nf_iterate+0x59/0x7d
nf_hook_slow+0x57/0xe1
ip_local_deliver+0x1a8/0x1ef
ip_rcv+0x25b/0x4eb
netif_receive_skb+0x196/0x2cc
rtl8139_poll+0x309/0x4d7
net_rx_action+0xac/0x25f
__do_softirq+0x5c/0xb7
do_softirq+0x4d/0x50
irq_exit+0x49/0x4b
do_IRQ+0x5f/0xb3
common_interrupt+0x2e/0x34
cpu_idle+0x41/0x6a
rest_init+0x37/0x3a
start_kernel+0x2ba/0x385
0x0
=================
Code: 89 45 f0 85 c0 74 2f 8b 42 20 89 c1 2b 8a 98 00 00 00 0f b6 10
80 e2 0f 0f b6 d2 8d 14 91 0f b6 c3 89 04 24 89 f1 89 f8 8b 5d f0 <ff>
53 68 83 c4 08 5b 5e 5f 5d c3 b8 01 00- 00 00 83 c4 08 5b 5e
EIP: [<c034c729>] ipv4_conntrack_help+0x6b/0x83 SS:ESP 0068:c0475dc4
<0>Kernel panic - not syncing: Fatal exception in interrupt
Network related config options (There is also some wireless stuff
compiled in, but it isn't used):
CONFIG_INET=y
CONFIG_IP_FIB_HASH=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK_ENABLED=y
CONFIG_NF_CONNTRACK_SUPPORT=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
CONFIG_NF_NAT_H323=y
CONFIG_NF_NAT_SIP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_NET_CLS_ROUTE=y
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
> >The kernel maintainers/help/config pretty consistently use UTF8
>
> I've seen a lot of places that don't do so. Want a patch?
I think that would be a good idea - and add it to the coding/docs specs
that documentation is UTF-8. Code should IMHO say 7bit though.
Alan
On Sun, 7 Jan 2007, Peter Osterlund wrote:
> Linus Torvalds <[email protected]> writes:
>
> > Patrick McHardy (2):
> > [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore
>
> I get kernel panics when doing large ethernet transfers. A loop doing
> continuous scp transfers of some large (>100MB) files makes the kernel
> crash after a few minutes. scp runs on a different machine and copies
> data from the machine that crashes. (The first crash did not happen
> when scp was used, but scp is an easy way to reproduce the problem.)
>
> I've seen this crash also with 2.6.20-rc2-git-something. Previously I
> ran these kernels quite a lot and used a ppp link without problems.
> Today I started using eth0 and the crashes started to occur. I have
> netfilter rules for ppp0, but no rules for eth0. Earlier kernels have
> been working perfectly for large eth0 transfers on this machine.
>
> Hand copied data from the console:
>
> BUG: unable to handle kernel paging request at virtual address 9f5cea9f
> printing eip:
> c034c729
> *pde = 00000000
> Ooops: 0000 [#1]
> PREEMPT
> Modules linked in: ... 8139too ...
> CPU: 0
> EIP: 0060:[<c034c729>] Not tainted VLI
> EFALLGS: 00010206 (2.6.20-rc4 #13)
> EIP is at ipv4_conntrack_help+0x6b/0x83
> eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 00000014
> esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4
That's
and $0xf,%dl
movzbl %dl,%edx
lea (%ecx,%edx,4),%edx
movzbl %bl,%eax
mov %eax,(%esp)
mov %esi,%ecx
mov %edi,%eax
mov 0xfffffff0(%ebp),%ebx
** call *0x68(%ebx) **
add $0x8,%esp
pop %ebx
pop %esi
pop %edi
pop %ebp
ret
which is ipv4_conntrack_help():
return help->helper->help(pskb,
(*pskb)->nh.raw - (*pskb)->data
+ (*pskb)->nh.iph->ihl*4,
ct, ctinfo);
and that call instruction is the one that oopses because "help->helper" is
corrupt (it's 0x9f5cea37 - not a valid kernel pointer).
David, there really *is* something screwy in netfilter.
Linus
On Sun, Jan 07, 2007 at 09:48:34PM +0100, Willy Tarreau wrote:
> On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
> >
> > On Jan 7 2007 17:06, Russell King wrote:
> > >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> > >
> > >$ git log | head -n 1000 | tail -n 200 > o
> > >$ file -i o
> > >o: text/plain; charset=us-ascii
> > >$ git log | head -n 1000 | tail -n 300 > o
> > >$ file -i o
> > >o: text/plain; charset=us-ascii
> > >$ git log | head -n 1000 | tail -n 400 > o
> > >$ file -i o
> > >o: text/plain; charset=utf-8
> >
> > I am inclined to say that "file" does not count, because it tries to guess an
> > ambiguous mapping from bytes to character set. Even more, file should be
> > _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> > file. This program is soo... forget it, it's not an argument. It works well for
> > headerful files, but text files don't really contain one. The next best thing
> > would be html, with a proper <meta http-equiv=Content> tag.
>
> The stupidity from the start up with those character sets is that they
> consider that a whole file is written with a given set. In fact, the
> charset should apply to characters themselves. At least, the
> quoted-printable, non-human friendly, encoding was the least stupid.
I doubt doing this would really be worth the effort.
In the 21st century, people should simply use UTF-8.
> Now that UTF8 comes everywhere, everyone receives tons of mangled mails,
> and even mailers which correctly support UTF8 and use it by default manage
> to shoot themselves in the foot when they reply to, or forward a mail. The
> system is completely broken because limited by design, and we have to learn
> to live with this brokenness.
Only if MUAs have broken charset support or don't set a correct
"charset" header in the mails they are sending.
If some software still can't handle UTF-8 correctly more than 10 years
after it was introduced, that's not a brokenness you can blame on UTF-8.
> Willy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : BUG: at mm/truncate.c:60 cancel_dirty_page()
References : http://lkml.org/lkml/2007/1/7/117
Submitter : Malte Schr?der <[email protected]>
Status : unknown
Subject : netfilter conntrack Oopses
References : http://lkml.org/lkml/2007/1/4/156
http://lkml.org/lkml/2007/1/7/188
Submitter : Bernhard Schmidt <[email protected]>
Peter Osterlund <[email protected]>
Status : unknown
Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>
Caused-By : YOSHIFUJI Hideaki <[email protected]>
commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki <[email protected]>
Status : problem is being debugged
Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
Status : unknown
Subject : BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl <[email protected]>
Damien Wyart <[email protected]>
Aaron Sethman <[email protected]>
Status : unknown
Subject : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[email protected]>
Status : unknown
Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
http://lkml.org/lkml/2007/1/3/9
Submitter : Tobias Diedrich <[email protected]>
Caused-By : Andi Kleen <[email protected]>
commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu <[email protected]>
Eric W. Biederman <[email protected]>
Status : patches are being discussed
Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <[email protected]>
Status : unknown
Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Handled-By : Alexey Starikovskiy <[email protected]>
Status : problem is being debugged
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : bluetooth oopses because of multiple kobject_add()
References : http://lkml.org/lkml/2007/1/2/101
Submitter : Pavel Machek <[email protected]>
Handled-By : Marcel Holtmann <[email protected]>
Patch : http://lkml.org/lkml/2007/1/2/147
Status : patch available
Subject : forcedeth.c 0.59: problem with sideband managment
References : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Submitter : Michael Reske <[email protected]>
Handled-By : Ayaz Abdulla <[email protected]>
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Status : patch available
Subject : nVidia CK804 chipset: not detecting HT MSI capabilities
References : http://lkml.org/lkml/2007/1/5/215
Submitter : Brice Goglin <[email protected]>
Robert Hancock <[email protected]>
Handled-By : Brice Goglin <[email protected]>
Patch : http://lkml.org/lkml/2007/1/5/215
Status : patch available
Hi Adrian,
> This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
> with patches available.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>
>
> Subject : bluetooth oopses because of multiple kobject_add()
> References : http://lkml.org/lkml/2007/1/2/101
> Submitter : Pavel Machek <[email protected]>
> Handled-By : Marcel Holtmann <[email protected]>
> Patch : http://lkml.org/lkml/2007/1/2/147
> Status : patch available
the patch has been forwarded to Dave Miller.
Regards
Marcel
On Mon, Jan 08, 2007 at 12:37:50AM +0100, Adrian Bunk wrote:
> On Sun, Jan 07, 2007 at 09:48:34PM +0100, Willy Tarreau wrote:
> > On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
> > >
> > > On Jan 7 2007 17:06, Russell King wrote:
> > > >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> > > >
> > > >$ git log | head -n 1000 | tail -n 200 > o
> > > >$ file -i o
> > > >o: text/plain; charset=us-ascii
> > > >$ git log | head -n 1000 | tail -n 300 > o
> > > >$ file -i o
> > > >o: text/plain; charset=us-ascii
> > > >$ git log | head -n 1000 | tail -n 400 > o
> > > >$ file -i o
> > > >o: text/plain; charset=utf-8
> > >
> > > I am inclined to say that "file" does not count, because it tries to guess an
> > > ambiguous mapping from bytes to character set. Even more, file should be
> > > _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> > > file. This program is soo... forget it, it's not an argument. It works well for
> > > headerful files, but text files don't really contain one. The next best thing
> > > would be html, with a proper <meta http-equiv=Content> tag.
> >
> > The stupidity from the start up with those character sets is that they
> > consider that a whole file is written with a given set. In fact, the
> > charset should apply to characters themselves. At least, the
> > quoted-printable, non-human friendly, encoding was the least stupid.
>
> I doubt doing this would really be worth the effort.
>
> In the 21st century, people should simply use UTF-8.
>
> > Now that UTF8 comes everywhere, everyone receives tons of mangled mails,
> > and even mailers which correctly support UTF8 and use it by default manage
> > to shoot themselves in the foot when they reply to, or forward a mail. The
> > system is completely broken because limited by design, and we have to learn
> > to live with this brokenness.
>
> Only if MUAs have broken charset support or don't set a correct
> "charset" header in the mails they are sending.
>
> If some software still can't handle UTF-8 correctly more than 10 years
> after it was introduced, that's not a brokenness you can blame on UTF-8.
I'm not blaming UTF-8 per se, but people who still believe in encoding
*whole documents*. Copy-paste, text insertion, git output, etc... everything
has a good reason not to be in the same encoding as what your MUA believes.
If major MUAs still have problems with UTF-8 10 years after it was introduced,
it's clearly the proof of a flaw in the initial design. And I'm not even
discussing the stupidity which requires that you read a whole text to get
its number of characters !
Willy
From: Linus Torvalds <[email protected]>
Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST)
> David, there really *is* something screwy in netfilter.
Sure, but from what I can see this bug appears unrelated to the one in
kernel bugzilla #7781 that we've been discussing the past few days.
First of all, the nf conntrack paths won't be used by normal
users until 2.6.20-rc1 or so. The bz #7781 report is against
2.6.19 and all those backtraces have IP conntrack in them, not
nf conntrack.
So what are we compiling with here btw, gcc-4.1?
I want to rule the compiler out in this and the bz #7781 case
so that we can look at the code seriously.
On Mon, Jan 08, 2007 at 01:38:57AM +0100, Willy Tarreau wrote:
> On Mon, Jan 08, 2007 at 12:37:50AM +0100, Adrian Bunk wrote:
> > On Sun, Jan 07, 2007 at 09:48:34PM +0100, Willy Tarreau wrote:
> > > On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
> > > >
> > > > On Jan 7 2007 17:06, Russell King wrote:
> > > > >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> > > > >
> > > > >$ git log | head -n 1000 | tail -n 200 > o
> > > > >$ file -i o
> > > > >o: text/plain; charset=us-ascii
> > > > >$ git log | head -n 1000 | tail -n 300 > o
> > > > >$ file -i o
> > > > >o: text/plain; charset=us-ascii
> > > > >$ git log | head -n 1000 | tail -n 400 > o
> > > > >$ file -i o
> > > > >o: text/plain; charset=utf-8
> > > >
> > > > I am inclined to say that "file" does not count, because it tries to guess an
> > > > ambiguous mapping from bytes to character set. Even more, file should be
> > > > _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> > > > file. This program is soo... forget it, it's not an argument. It works well for
> > > > headerful files, but text files don't really contain one. The next best thing
> > > > would be html, with a proper <meta http-equiv=Content> tag.
> > >
> > > The stupidity from the start up with those character sets is that they
> > > consider that a whole file is written with a given set. In fact, the
> > > charset should apply to characters themselves. At least, the
> > > quoted-printable, non-human friendly, encoding was the least stupid.
> >
> > I doubt doing this would really be worth the effort.
> >
> > In the 21st century, people should simply use UTF-8.
> >
> > > Now that UTF8 comes everywhere, everyone receives tons of mangled mails,
> > > and even mailers which correctly support UTF8 and use it by default manage
> > > to shoot themselves in the foot when they reply to, or forward a mail. The
> > > system is completely broken because limited by design, and we have to learn
> > > to live with this brokenness.
> >
> > Only if MUAs have broken charset support or don't set a correct
> > "charset" header in the mails they are sending.
> >
> > If some software still can't handle UTF-8 correctly more than 10 years
> > after it was introduced, that's not a brokenness you can blame on UTF-8.
>
> I'm not blaming UTF-8 per se, but people who still believe in encoding
> *whole documents*. Copy-paste, text insertion, git output, etc... everything
> has a good reason not to be in the same encoding as what your MUA believes.
How would you do this technically in a way that it's significantely
easier than simply finishing the UTF=8 transition?
> If major MUAs still have problems with UTF-8 10 years after it was introduced,
> it's clearly the proof of a flaw in the initial design. And I'm not even
> discussing the stupidity which requires that you read a whole text to get
> its number of characters !
The only major MUA not supporting UTF-8 is Eudora.
And if you are talking about buggy old pine, in the latest development
version [1] it does not only become open source, it also got some
working Unicode support.
> Willy
cu
Adrian
[1] Alpine
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 08, 2007 at 02:03:37AM +0100, Adrian Bunk wrote:
> On Mon, Jan 08, 2007 at 01:38:57AM +0100, Willy Tarreau wrote:
> > On Mon, Jan 08, 2007 at 12:37:50AM +0100, Adrian Bunk wrote:
> > > On Sun, Jan 07, 2007 at 09:48:34PM +0100, Willy Tarreau wrote:
> > > > On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
> > > > >
> > > > > On Jan 7 2007 17:06, Russell King wrote:
> > > > > >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> > > > > >
> > > > > >$ git log | head -n 1000 | tail -n 200 > o
> > > > > >$ file -i o
> > > > > >o: text/plain; charset=us-ascii
> > > > > >$ git log | head -n 1000 | tail -n 300 > o
> > > > > >$ file -i o
> > > > > >o: text/plain; charset=us-ascii
> > > > > >$ git log | head -n 1000 | tail -n 400 > o
> > > > > >$ file -i o
> > > > > >o: text/plain; charset=utf-8
> > > > >
> > > > > I am inclined to say that "file" does not count, because it tries to guess an
> > > > > ambiguous mapping from bytes to character set. Even more, file should be
> > > > > _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> > > > > file. This program is soo... forget it, it's not an argument. It works well for
> > > > > headerful files, but text files don't really contain one. The next best thing
> > > > > would be html, with a proper <meta http-equiv=Content> tag.
> > > >
> > > > The stupidity from the start up with those character sets is that they
> > > > consider that a whole file is written with a given set. In fact, the
> > > > charset should apply to characters themselves. At least, the
> > > > quoted-printable, non-human friendly, encoding was the least stupid.
> > >
> > > I doubt doing this would really be worth the effort.
> > >
> > > In the 21st century, people should simply use UTF-8.
> > >
> > > > Now that UTF8 comes everywhere, everyone receives tons of mangled mails,
> > > > and even mailers which correctly support UTF8 and use it by default manage
> > > > to shoot themselves in the foot when they reply to, or forward a mail. The
> > > > system is completely broken because limited by design, and we have to learn
> > > > to live with this brokenness.
> > >
> > > Only if MUAs have broken charset support or don't set a correct
> > > "charset" header in the mails they are sending.
> > >
> > > If some software still can't handle UTF-8 correctly more than 10 years
> > > after it was introduced, that's not a brokenness you can blame on UTF-8.
> >
> > I'm not blaming UTF-8 per se, but people who still believe in encoding
> > *whole documents*. Copy-paste, text insertion, git output, etc... everything
> > has a good reason not to be in the same encoding as what your MUA believes.
>
> How would you do this technically in a way that it's significantely
> easier than simply finishing the UTF=8 transition?
In how many decades do you think the transition will be finished ?
> > If major MUAs still have problems with UTF-8 10 years after it was introduced,
> > it's clearly the proof of a flaw in the initial design. And I'm not even
> > discussing the stupidity which requires that you read a whole text to get
> > its number of characters !
>
> The only major MUA not supporting UTF-8 is Eudora.
>
> And if you are talking about buggy old pine, in the latest development
> version [1] it does not only become open source, it also got some
> working Unicode support.
No, I'm not speaking about "not supporting", but "having problems". Every
one of us has already received mails from Thunderbird, Outlook, Notes, etc...
with erroneously encoded characters because of this :
- an UTF8 MUA sends a mail to a non-UTF8 aware one.
- this last one only sees double chars. When it wants to forward the mail
to someone else, it keeps the chars verbatim, and sets the encoding type
to its own, something like iso8859-1 for instance.
- the final MUA, which is UTF8-aware, is very happy to detect lots of UTF8
combinations in the forwarded mail and decides that everything in it is
UTF8, then you get lots of chars mangled in the mail, in the middle of
UTF8 combinations. Then, this crappy mail can be forwarded as long as
you want between UTF8 MUAs, they will all apply heuristics and to the
wrong thing : consider the *whole* document with *one* type.
What I find even funnier is when, for no apparent reason, the same MUA is used
on both ends and the contents get mangled because the sender copies a portion
of text from somewhere else.
Anyway, I don't want to follow up on this thread, it's *highly* off-topic here.
Cheers,
Willy
Adrian Bunk wrote:
> This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19.
> Subject : netfilter conntrack Oopses
> References : http://lkml.org/lkml/2007/1/4/156
Netfilter bugzilla #528
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=528
fixed, I think the patch is in -rc4 already (it is listed in the "Merge
/pub/scm/linux/kernel/git/davem/net-2.6" on Jan. 4th in the git browser)
> http://lkml.org/lkml/2007/1/7/188
Netfilter bugzilla #529
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=529
no patch available yet, remote DoS attack for 2.6.20-rc3, not excluded
this has been the case since nf_conntrack_ipv6 was available (2.6.16 or
so), UDPv6 fragments are rare in the wild and a large number of users
could not use nf_conntrack_ipv6 up to now due to incompatibility with
IPv4 NAT code.
Regards,
Bernhard
On Jan 7 2007 22:30, Alan wrote:
>
>> >The kernel maintainers/help/config pretty consistently use UTF8
>>
>> I've seen a lot of places that don't do so. Want a patch?
>
>I think that would be a good idea - and add it to the coding/docs specs
>that documentation is UTF-8. Code should IMHO say 7bit though.
Hm, what do the list of authors in .c/.h files and kerneldoc
in .c/h belong to? doc or code?
-`J'
--
Am 08.01.2007 01:38 schrieb Willy Tarreau:
> I'm not blaming UTF-8 per se, but people who still believe in encoding
> *whole documents*. Copy-paste, text insertion, git output, etc... everything
> has a good reason not to be in the same encoding as what your MUA believes.
> If major MUAs still have problems with UTF-8 10 years after it was introduced,
> it's clearly the proof of a flaw in the initial design.
Actually it's working amazingly well. In the past 15 years the frequency of
character encoding problems has gone from "frequent, that's just the way it
is, if you want your text to go through unharmed then stick to 7 bit ASCII"
to "rare, it normally works, if it doesn't then we've got a problem to solve".
Copy/paste? Works for me! Mail forwarding? Works for me!
The only thing that doesn't and cannot work is automatic conversion of data
with unknown encoding or with incorrect encoding information, and that has
to be solved at the source. If you store differently encoded text in git
without labelling it accordingly then there is just no way to retrieve it
consistently. There are two ways out of that - a complicated one: storing
encoding information with every piece of text, and a simple one - declaring
a single internal encoding to which everything must be converted upon entry
into the database. Guess which one has more chances of working well.
> And I'm not even
> discussing the stupidity which requires that you read a whole text to get
> its number of characters !
Personally I find the requirement to know the number of characters in a text
rather unusual, so I wouldn't base a decision for an encoding on that. In
fact, I cannot remember ever really wanting to know the actual number of
characters in a text. The number of bytes occupied on storage, ok. The
number of letters, of words, of lines, perhaps even the number of printable
characters, all potentially interesting, depending on the application.
But the raw number of characters? I don't know what that might serve for.
HTH
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Russell King <[email protected]> wrote:
[...]
> All that UTF-8 has done is added to the "which charset is this data"
> problem rather than actually solving any proper real life problem.
It solves real-world problems, the pain is that it is not (yet) universally
used. The charset problems today are much more visible today than, say, 15
years back, that is all.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Mon, Jan 08, 2007 at 02:14:41AM +0100, Willy Tarreau wrote:
> On Mon, Jan 08, 2007 at 02:03:37AM +0100, Adrian Bunk wrote:
> > On Mon, Jan 08, 2007 at 01:38:57AM +0100, Willy Tarreau wrote:
> > > On Mon, Jan 08, 2007 at 12:37:50AM +0100, Adrian Bunk wrote:
> > > > On Sun, Jan 07, 2007 at 09:48:34PM +0100, Willy Tarreau wrote:
> > > > > On Sun, Jan 07, 2007 at 08:11:38PM +0100, Jan Engelhardt wrote:
> > > > > >
> > > > > > On Jan 7 2007 17:06, Russell King wrote:
> > > > > > >On Mon, Jan 08, 2007 at 12:29:05AM +0800, David Woodhouse wrote:
> > > > > > >
> > > > > > >$ git log | head -n 1000 | tail -n 200 > o
> > > > > > >$ file -i o
> > > > > > >o: text/plain; charset=us-ascii
> > > > > > >$ git log | head -n 1000 | tail -n 300 > o
> > > > > > >$ file -i o
> > > > > > >o: text/plain; charset=us-ascii
> > > > > > >$ git log | head -n 1000 | tail -n 400 > o
> > > > > > >$ file -i o
> > > > > > >o: text/plain; charset=utf-8
> > > > > >
> > > > > > I am inclined to say that "file" does not count, because it tries to guess an
> > > > > > ambiguous mapping from bytes to character set. Even more, file should be
> > > > > > _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15)
> > > > > > file. This program is soo... forget it, it's not an argument. It works well for
> > > > > > headerful files, but text files don't really contain one. The next best thing
> > > > > > would be html, with a proper <meta http-equiv=Content> tag.
> > > > >
> > > > > The stupidity from the start up with those character sets is that they
> > > > > consider that a whole file is written with a given set. In fact, the
> > > > > charset should apply to characters themselves. At least, the
> > > > > quoted-printable, non-human friendly, encoding was the least stupid.
> > > >
> > > > I doubt doing this would really be worth the effort.
> > > >
> > > > In the 21st century, people should simply use UTF-8.
> > > >
> > > > > Now that UTF8 comes everywhere, everyone receives tons of mangled mails,
> > > > > and even mailers which correctly support UTF8 and use it by default manage
> > > > > to shoot themselves in the foot when they reply to, or forward a mail. The
> > > > > system is completely broken because limited by design, and we have to learn
> > > > > to live with this brokenness.
> > > >
> > > > Only if MUAs have broken charset support or don't set a correct
> > > > "charset" header in the mails they are sending.
> > > >
> > > > If some software still can't handle UTF-8 correctly more than 10 years
> > > > after it was introduced, that's not a brokenness you can blame on UTF-8.
> > >
> > > I'm not blaming UTF-8 per se, but people who still believe in encoding
> > > *whole documents*. Copy-paste, text insertion, git output, etc... everything
> > > has a good reason not to be in the same encoding as what your MUA believes.
> >
> > How would you do this technically in a way that it's significantely
> > easier than simply finishing the UTF=8 transition?
>
> In how many decades do you think the transition will be finished ?
>
> > > If major MUAs still have problems with UTF-8 10 years after it was introduced,
> > > it's clearly the proof of a flaw in the initial design. And I'm not even
> > > discussing the stupidity which requires that you read a whole text to get
> > > its number of characters !
> >
> > The only major MUA not supporting UTF-8 is Eudora.
> >
> > And if you are talking about buggy old pine, in the latest development
> > version [1] it does not only become open source, it also got some
> > working Unicode support.
>
> No, I'm not speaking about "not supporting", but "having problems". Every
> one of us has already received mails from Thunderbird, Outlook, Notes, etc...
> with erroneously encoded characters because of this :
>
> - an UTF8 MUA sends a mail to a non-UTF8 aware one.
"non-UTF8 aware one" = Eudora (BTW: there's no Linux version)
> - this last one only sees double chars. When it wants to forward the mail
> to someone else, it keeps the chars verbatim, and sets the encoding type
> to its own, something like iso8859-1 for instance.
Let's not base everything on the one broken non-Linux MUA,
> - the final MUA, which is UTF8-aware, is very happy to detect lots of UTF8
> combinations in the forwarded mail and decides that everything in it is
> UTF8, then you get lots of chars mangled in the mail, in the middle of
> UTF8 combinations. Then, this crappy mail can be forwarded as long as
> you want between UTF8 MUAs, they will all apply heuristics and to the
> wrong thing : consider the *whole* document with *one* type.
Which MUAs exactly do ignore the "charset" of an email and try their own
guessing instead?
Or which MUAs exactly do not set a "charset" so that the receiving MUA
might have a reason for guessing?
> What I find even funnier is when, for no apparent reason, the same MUA is used
> on both ends and the contents get mangled because the sender copies a portion
> of text from somewhere else.
With which MUA and which charset settings of the users?
> Anyway, I don't want to follow up on this thread, it's *highly* off-topic here.
People want their names written correctly in changelogs.
It is therefore on-topic if the result is something like "kernel
maintainers shouldn't be using Eudora" or "kernel maintainers using pine
should upgrade to Alpine" or something similar.
> Cheers,
> Willy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 08, 2007 at 02:32:42AM +0100, Tilman Schmidt wrote:
> Am 08.01.2007 01:38 schrieb Willy Tarreau:
>...
> > And I'm not even
> > discussing the stupidity which requires that you read a whole text to get
> > its number of characters !
>
> Personally I find the requirement to know the number of characters in a text
> rather unusual, so I wouldn't base a decision for an encoding on that. In
> fact, I cannot remember ever really wanting to know the actual number of
> characters in a text. The number of bytes occupied on storage, ok. The
> number of letters, of words, of lines, perhaps even the number of printable
> characters, all potentially interesting, depending on the application.
> But the raw number of characters? I don't know what that might serve for.
Also note that the UTF-32 Unicode encoding would offer this property,
but with the following disadvantages compared to the UTF-8 Unicode
encoding:
- 7bit ASCII is not a subset of UTF-32 losing a lot of compatibility
(code 7bit ASCII with some UTF-8 in the comments is no problem
for not-Unicode aware systems except for slight misdisplayments
of the comments)
- UTF-32 has up to 4 times the size of UTF-8
There's also the point that you can use e.g. "wc" or your editor for
counting the characters.
> HTH
> Tilman
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, 2007-01-07 at 15:05 -0500, Dave Jones wrote:
> This has been bugging me for a while.
> Viewing the mail I applied in mutt shows his name correctly as Rafał
> Applying it with git-applymbox and viewing the log on master.kernel.org
> with git log shows Rafa<B3> And then later when put into email
> it turns into Rafa³
I believe you need to use the misnamed '-u' option to git-applymbox,
which _really_ ought to be the default behaviour. Otherwise, it fails to
pay any attention to the character set tags in the mail it's decoding --
it commits the sin which rmk was whining about; assuming the input data
is of a given type and ignoring the explicit tags which indicate the
contrary.
The '-u' option is misdocumented as 'causes the resulting commit to be
encoded in utf-8', but in fact I believe it doesn't necessarily do that
-- it actually causes the resulting commit to be encoded in the
configured storage charset for the repository, which just _happens_ to
default to UTF-8 unless otherwise specified. That is something which
should definitely be the _default_ behaviour.
We should make the '-u' behaviour the default, and if anyone really
wants the old behaviour of importing arbitrary data in untagged
binary form overriding its labelling then they can have a separate
option which does that.
--
dwmw2
David Miller <[email protected]> writes:
> From: Linus Torvalds <[email protected]>
> Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST)
>
> > David, there really *is* something screwy in netfilter.
>
> Sure, but from what I can see this bug appears unrelated to the one in
> kernel bugzilla #7781 that we've been discussing the past few days.
>
> First of all, the nf conntrack paths won't be used by normal
> users until 2.6.20-rc1 or so. The bz #7781 report is against
> 2.6.19 and all those backtraces have IP conntrack in them, not
> nf conntrack.
>
> So what are we compiling with here btw, gcc-4.1?
"gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)" from Fedora Core 5.
That distribution has gcc32 installed too, so I'll try that compiler
too and report back.
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
On Jan 8 2007 02:03, Adrian Bunk wrote:
>
>The only major MUA not supporting UTF-8 is Eudora.
>
>And if you are talking about buggy old pine, in the latest development
>version [1] it does not only become open source, it also got some
>working Unicode support.
Uhm, just for the record, I run pine 4.61 where my mail delivers to,
and Unicode works, yes, including the spam.
-`J'
--
On Mon, Jan 08, 2007 at 07:52:48AM +0100, Jan Engelhardt wrote:
>
> On Jan 8 2007 02:03, Adrian Bunk wrote:
> >
> >The only major MUA not supporting UTF-8 is Eudora.
> >
> >And if you are talking about buggy old pine, in the latest development
> >version [1] it does not only become open source, it also got some
> >working Unicode support.
>
> Uhm, just for the record, I run pine 4.61 where my mail delivers to,
> and Unicode works, yes, including the spam.
For some years I'm using pine only as a newsreader, and I remember some
display problems of Unicode characters that are fixed in Alpine.
It might be that the support in pine was already better than I thought
(but my switch to MUA was so many years ago...).
> -`J'
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> elinks is one such program. It now assumes UTF-8 _only_ displays.
> That's no better than programs which assume ISO-8859-1 only or US-ASCII
> only.
That's way better than programs:
- which assume an encoding you can't write most world languages in (BTW
ISO-8859-1 & US-ASCII are broken by design for Western Europe since at
least the Euro creation)
- which perpetuate the myth local 8-bit encodings are manageable (they
aren't, people spent decades trying to limp along with them, unicode &
UTF-8 where not created just to make your life miserable)
Show me one program that spurns Unicode I'll show you one that "passed on"
iso-8859-15 (typically, though it's the easiest non-iso-8859-1 to do)
The only reason you have the UTF-8 big stick approach nowadays is people
have tried for years to get app writers manage 8-bit locales properly to
dismal results. The old system was only working for en_US users (and
perhaps to .uk people)
--
Nicolas Mailhot
>> How would you do this technically in a way that it's significantely
>> easier than simply finishing the UTF=8 transition?
> In how many decades do you think the transition will be finished ?
Right now it looks like it will be finished way earlier than app bother
supporting the later 8-bit encodings such as iso-8859-15
(case in point: Russel's system. I was ROTFL when he proudly announced he
was running a full iso-8859-1 system after dissing UTF-8. Last I've seen
the official 8bit EU encoding was iso-8859-15, and UK is part of the EU)
--
Nicolas Mailhot
> (case in point: Russel's system. I was ROTFL when he proudly announced he
> was running a full iso-8859-1 system after dissing UTF-8. Last I've seen
> the official 8bit EU encoding was iso-8859-15, and UK is part of the EU)
There is no correct UK encoding. You need -14 or -15 depending upon
language and can come horribly unstuck the moment a name is involved.
Alan
Le Lun 8 janvier 2007 11:44, Alan a écrit :
>> (case in point: Russel's system. I was ROTFL when he proudly announced
>> he
>> was running a full iso-8859-1 system after dissing UTF-8. Last I've seen
>> the official 8bit EU encoding was iso-8859-15, and UK is part of the EU)
>
> There is no correct UK encoding. You need -14 or -15 depending upon
> language and can come horribly unstuck the moment a name is involved.
Either way it's not iso-8859-1 :)
--
Nicolas Mailhot
Hello,
Doesn't build on iMac G3 machine. Relevant info attached.
In file included from drivers/usb/host/ohci-hcd.c:893:
drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest'
drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here
drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module'
drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here
drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest'
drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here
drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module'
drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here
make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1
make[2]: *** [drivers/usb/host] Blad 2
make[1]: *** [drivers/usb] Blad 2
make: *** [drivers] Blad 2
processor : 0
cpu : 740/750
temperature : 51-53 C (uncalibrated)
clock : 400MHz
revision : 2.2 (pvr 0008 0202)
bogomips : 796.67
machine : PowerMac2,1
motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
detected as : 66 (iMac FireWire)
pmac flags : 00000005
L2 cache : 512K unified
memory : 256MB
pmac-generation : NewWorld
Gnu C 4.1.2
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.3-pre2
e2fsprogs 1.40-WIP
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom joydev evdev ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix
Config comes from debian 2.6.8-powerpc + make oldconfig. Please find it attached.
--
Regards,
Mariusz Kozlowski
Don't build ohci as module for now.
A fix for that is already in gregkh usb tree for 2.6.21
Sylvain
Mariusz Kozlowski wrote:
> Hello,
>
> Doesn't build on iMac G3 machine. Relevant info attached.
>
> In file included from drivers/usb/host/ohci-hcd.c:893:
> drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest'
> drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here
> drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module'
> drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here
> drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest'
> drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here
> drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module'
> drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here
> make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1
> make[2]: *** [drivers/usb/host] Blad 2
> make[1]: *** [drivers/usb] Blad 2
> make: *** [drivers] Blad 2
>
> processor : 0
> cpu : 740/750
> temperature : 51-53 C (uncalibrated)
> clock : 400MHz
> revision : 2.2 (pvr 0008 0202)
> bogomips : 796.67
> machine : PowerMac2,1
> motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
> detected as : 66 (iMac FireWire)
> pmac flags : 00000005
> L2 cache : 512K unified
> memory : 256MB
> pmac-generation : NewWorld
>
> Gnu C 4.1.2
> Gnu make 3.81
> binutils 2.17
> util-linux 2.12r
> mount 2.12r
> module-init-tools 3.3-pre2
> e2fsprogs 1.40-WIP
> Linux C Library 2.3.6
> Dynamic linker (ldd) 2.3.6
> Procps 3.2.7
> Net-tools 1.60
> Console-tools 0.2.3
> Sh-utils 5.97
> Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom joydev evdev ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix
>
> Config comes from debian 2.6.8-powerpc + make oldconfig. Please find it attached.
>
>
> ------------------------------------------------------------------------
>
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.20-rc4
> # Mon Jan 8 14:00:20 2007
> #
> # CONFIG_PPC64 is not set
> CONFIG_PPC32=y
> CONFIG_PPC_MERGE=y
> CONFIG_MMU=y
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_IRQ_PER_CPU=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_ARCH_HAS_ILOG2_U32=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_GENERIC_FIND_NEXT_BIT=y
> CONFIG_PPC=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_GENERIC_NVRAM=y
> CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_PPC_OF=y
> CONFIG_PPC_UDBG_16550=y
> # CONFIG_GENERIC_TBSYNC is not set
> CONFIG_AUDIT_ARCH=y
> CONFIG_GENERIC_BUG=y
> # CONFIG_DEFAULT_UIMAGE is not set
>
> #
> # Processor support
> #
> CONFIG_CLASSIC32=y
> # CONFIG_PPC_82xx is not set
> # CONFIG_PPC_83xx is not set
> # CONFIG_PPC_85xx is not set
> # CONFIG_PPC_86xx is not set
> # CONFIG_40x is not set
> # CONFIG_44x is not set
> # CONFIG_8xx is not set
> # CONFIG_E200 is not set
> CONFIG_6xx=y
> CONFIG_PPC_FPU=y
> # CONFIG_PPC_DCR_NATIVE is not set
> # CONFIG_PPC_DCR_MMIO is not set
> # CONFIG_ALTIVEC is not set
> CONFIG_PPC_STD_MMU=y
> CONFIG_PPC_STD_MMU_32=y
> # CONFIG_SMP is not set
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>
> #
> # Code maturity level options
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
>
> #
> # General setup
> #
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> # CONFIG_IPC_NS is not set
> CONFIG_POSIX_MQUEUE=y
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> # CONFIG_TASKSTATS is not set
> # CONFIG_UTS_NS is not set
> CONFIG_AUDIT=y
> # CONFIG_AUDITSYSCALL is not set
> # CONFIG_IKCONFIG is not set
> CONFIG_SYSFS_DEPRECATED=y
> # CONFIG_RELAY is not set
> CONFIG_INITRAMFS_SOURCE=""
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_SYSCTL=y
> # CONFIG_EMBEDDED is not set
> CONFIG_SYSCTL_SYSCALL=y
> CONFIG_KALLSYMS=y
> # CONFIG_KALLSYMS_ALL is not set
> # CONFIG_KALLSYMS_EXTRA_PASS is not set
> CONFIG_HOTPLUG=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> CONFIG_SHMEM=y
> CONFIG_SLAB=y
> CONFIG_VM_EVENT_COUNTERS=y
> CONFIG_RT_MUTEXES=y
> # CONFIG_TINY_SHMEM is not set
> CONFIG_BASE_SMALL=0
> # CONFIG_SLOB is not set
>
> #
> # Loadable module support
> #
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> CONFIG_MODULE_FORCE_UNLOAD=y
> CONFIG_MODVERSIONS=y
> # CONFIG_MODULE_SRCVERSION_ALL is not set
> CONFIG_KMOD=y
>
> #
> # Block layer
> #
> CONFIG_BLOCK=y
> CONFIG_LBD=y
> # CONFIG_BLK_DEV_IO_TRACE is not set
> # CONFIG_LSF is not set
>
> #
> # IO Schedulers
> #
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_AS=y
> CONFIG_IOSCHED_DEADLINE=y
> CONFIG_IOSCHED_CFQ=y
> # CONFIG_DEFAULT_AS is not set
> # CONFIG_DEFAULT_DEADLINE is not set
> CONFIG_DEFAULT_CFQ=y
> # CONFIG_DEFAULT_NOOP is not set
> CONFIG_DEFAULT_IOSCHED="cfq"
>
> #
> # Platform support
> #
> CONFIG_PPC_MULTIPLATFORM=y
> # CONFIG_EMBEDDED6xx is not set
> # CONFIG_APUS is not set
> CONFIG_PPC_CHRP=y
> CONFIG_PPC_MPC52xx=y
> CONFIG_PPC_EFIKA=y
> # CONFIG_PPC_LITE5200 is not set
> CONFIG_PPC_PMAC=y
> # CONFIG_PPC_CELL is not set
> # CONFIG_PPC_CELL_NATIVE is not set
> CONFIG_PPC_NATIVE=y
> # CONFIG_UDBG_RTAS_CONSOLE is not set
> CONFIG_PPC_RTAS=y
> # CONFIG_RTAS_ERROR_LOGGING is not set
> CONFIG_RTAS_PROC=y
> # CONFIG_MMIO_NVRAM is not set
> CONFIG_PPC_MPC106=y
> # CONFIG_PPC_970_NAP is not set
> # CONFIG_PPC_INDIRECT_IO is not set
> # CONFIG_GENERIC_IOMAP is not set
> # CONFIG_CPU_FREQ is not set
> # CONFIG_PPC601_SYNC_FIX is not set
> # CONFIG_TAU is not set
> # CONFIG_WANT_EARLY_SERIAL is not set
> CONFIG_MPIC=y
>
> #
> # Kernel options
> #
> CONFIG_HIGHMEM=y
> # CONFIG_HZ_100 is not set
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> # CONFIG_KEXEC is not set
> CONFIG_ARCH_FLATMEM_ENABLE=y
> CONFIG_ARCH_POPULATES_NODE_MAP=y
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_FLATMEM_MANUAL=y
> # CONFIG_DISCONTIGMEM_MANUAL is not set
> # CONFIG_SPARSEMEM_MANUAL is not set
> CONFIG_FLATMEM=y
> CONFIG_FLAT_NODE_MEM_MAP=y
> # CONFIG_SPARSEMEM_STATIC is not set
> CONFIG_SPLIT_PTLOCK_CPUS=4
> # CONFIG_RESOURCES_64BIT is not set
> CONFIG_PROC_DEVICETREE=y
> CONFIG_CMDLINE_BOOL=y
> CONFIG_CMDLINE="console=ttyS0,9600 console=tty0"
> CONFIG_PM=y
> # CONFIG_PM_LEGACY is not set
> # CONFIG_PM_DEBUG is not set
> # CONFIG_PM_SYSFS_DEPRECATED is not set
> # CONFIG_SOFTWARE_SUSPEND is not set
> CONFIG_SECCOMP=y
> CONFIG_ISA_DMA_API=y
>
> #
> # Bus options
> #
> # CONFIG_ISA is not set
> CONFIG_GENERIC_ISA_DMA=y
> # CONFIG_MPIC_WEIRD is not set
> CONFIG_PPC_I8259=y
> CONFIG_PPC_INDIRECT_PCI=y
> CONFIG_PCI=y
> CONFIG_PCI_DOMAINS=y
> # CONFIG_PCIEPORTBUS is not set
> # CONFIG_PCI_DEBUG is not set
>
> #
> # PCCARD (PCMCIA/CardBus) support
> #
> # CONFIG_PCCARD is not set
>
> #
> # PCI Hotplug Support
> #
> # CONFIG_HOTPLUG_PCI is not set
>
> #
> # Advanced setup
> #
> # CONFIG_ADVANCED_OPTIONS is not set
>
> #
> # Default settings for advanced configuration options are used
> #
> CONFIG_HIGHMEM_START=0xfe000000
> CONFIG_LOWMEM_SIZE=0x30000000
> CONFIG_KERNEL_START=0xc0000000
> CONFIG_TASK_SIZE=0x80000000
> CONFIG_BOOT_LOAD=0x00800000
>
> #
> # Networking
> #
> CONFIG_NET=y
>
> #
> # Networking options
> #
> # CONFIG_NETDEBUG is not set
> CONFIG_PACKET=m
> # CONFIG_PACKET_MMAP is not set
> CONFIG_UNIX=m
> CONFIG_XFRM=y
> CONFIG_XFRM_USER=m
> # CONFIG_XFRM_SUB_POLICY is not set
> CONFIG_NET_KEY=m
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> CONFIG_IP_ADVANCED_ROUTER=y
> CONFIG_ASK_IP_FIB_HASH=y
> # CONFIG_IP_FIB_TRIE is not set
> CONFIG_IP_FIB_HASH=y
> CONFIG_IP_MULTIPLE_TABLES=y
> CONFIG_IP_ROUTE_MULTIPATH=y
> # CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
> CONFIG_IP_ROUTE_VERBOSE=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=y
> # CONFIG_SYN_COOKIES is not set
> CONFIG_INET_AH=m
> CONFIG_INET_ESP=m
> CONFIG_INET_IPCOMP=m
> CONFIG_INET_XFRM_TUNNEL=m
> CONFIG_INET_TUNNEL=m
> CONFIG_INET_XFRM_MODE_TRANSPORT=y
> CONFIG_INET_XFRM_MODE_TUNNEL=y
> CONFIG_INET_XFRM_MODE_BEET=y
> CONFIG_INET_DIAG=y
> CONFIG_INET_TCP_DIAG=y
> # CONFIG_TCP_CONG_ADVANCED is not set
> CONFIG_TCP_CONG_CUBIC=y
> CONFIG_DEFAULT_TCP_CONG="cubic"
> # CONFIG_TCP_MD5SIG is not set
>
> #
> # IP: Virtual Server Configuration
> #
> CONFIG_IP_VS=m
> # CONFIG_IP_VS_DEBUG is not set
> CONFIG_IP_VS_TAB_BITS=12
>
> #
> # IPVS transport protocol load balancing support
> #
> CONFIG_IP_VS_PROTO_TCP=y
> CONFIG_IP_VS_PROTO_UDP=y
> CONFIG_IP_VS_PROTO_ESP=y
> CONFIG_IP_VS_PROTO_AH=y
>
> #
> # IPVS scheduler
> #
> CONFIG_IP_VS_RR=m
> CONFIG_IP_VS_WRR=m
> CONFIG_IP_VS_LC=m
> CONFIG_IP_VS_WLC=m
> CONFIG_IP_VS_LBLC=m
> CONFIG_IP_VS_LBLCR=m
> CONFIG_IP_VS_DH=m
> CONFIG_IP_VS_SH=m
> CONFIG_IP_VS_SED=m
> CONFIG_IP_VS_NQ=m
>
> #
> # IPVS application helper
> #
> CONFIG_IP_VS_FTP=m
> CONFIG_IPV6=m
> CONFIG_IPV6_PRIVACY=y
> # CONFIG_IPV6_ROUTER_PREF is not set
> CONFIG_INET6_AH=m
> CONFIG_INET6_ESP=m
> CONFIG_INET6_IPCOMP=m
> # CONFIG_IPV6_MIP6 is not set
> CONFIG_INET6_XFRM_TUNNEL=m
> CONFIG_INET6_TUNNEL=m
> CONFIG_INET6_XFRM_MODE_TRANSPORT=m
> CONFIG_INET6_XFRM_MODE_TUNNEL=m
> CONFIG_INET6_XFRM_MODE_BEET=m
> # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
> CONFIG_IPV6_SIT=m
> CONFIG_IPV6_TUNNEL=m
> # CONFIG_IPV6_MULTIPLE_TABLES is not set
> # CONFIG_NETWORK_SECMARK is not set
> CONFIG_NETFILTER=y
> # CONFIG_NETFILTER_DEBUG is not set
> CONFIG_BRIDGE_NETFILTER=y
>
> #
> # Core Netfilter Configuration
> #
> # CONFIG_NETFILTER_NETLINK is not set
> # CONFIG_NF_CONNTRACK_ENABLED is not set
> # CONFIG_NETFILTER_XTABLES is not set
>
> #
> # IP: Netfilter Configuration
> #
> CONFIG_IP_NF_QUEUE=m
>
> #
> # IPv6: Netfilter Configuration (EXPERIMENTAL)
> #
> # CONFIG_IP6_NF_QUEUE is not set
>
> #
> # DECnet: Netfilter Configuration
> #
> # CONFIG_DECNET_NF_GRABULATOR is not set
>
> #
> # Bridge: Netfilter Configuration
> #
> # CONFIG_BRIDGE_NF_EBTABLES is not set
>
> #
> # DCCP Configuration (EXPERIMENTAL)
> #
> # CONFIG_IP_DCCP is not set
>
> #
> # SCTP Configuration (EXPERIMENTAL)
> #
> CONFIG_IP_SCTP=m
> # CONFIG_SCTP_DBG_MSG is not set
> # CONFIG_SCTP_DBG_OBJCNT is not set
> # CONFIG_SCTP_HMAC_NONE is not set
> # CONFIG_SCTP_HMAC_SHA1 is not set
> CONFIG_SCTP_HMAC_MD5=y
>
> #
> # TIPC Configuration (EXPERIMENTAL)
> #
> # CONFIG_TIPC is not set
> CONFIG_ATM=m
> CONFIG_ATM_CLIP=m
> CONFIG_ATM_CLIP_NO_ICMP=y
> CONFIG_ATM_LANE=m
> CONFIG_ATM_MPOA=m
> CONFIG_ATM_BR2684=m
> # CONFIG_ATM_BR2684_IPFILTER is not set
> CONFIG_BRIDGE=m
> CONFIG_VLAN_8021Q=m
> CONFIG_DECNET=m
> CONFIG_DECNET_ROUTER=y
> CONFIG_LLC=y
> CONFIG_LLC2=m
> CONFIG_IPX=m
> CONFIG_IPX_INTERN=y
> CONFIG_ATALK=m
> CONFIG_DEV_APPLETALK=m
> CONFIG_IPDDP=m
> CONFIG_IPDDP_ENCAP=y
> CONFIG_IPDDP_DECAP=y
> CONFIG_X25=m
> CONFIG_LAPB=m
> CONFIG_ECONET=m
> CONFIG_ECONET_AUNUDP=y
> CONFIG_ECONET_NATIVE=y
> CONFIG_WAN_ROUTER=m
>
> #
> # QoS and/or fair queueing
> #
> CONFIG_NET_SCHED=y
> CONFIG_NET_SCH_FIFO=y
> CONFIG_NET_SCH_CLK_JIFFIES=y
> # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
> # CONFIG_NET_SCH_CLK_CPU is not set
>
> #
> # Queueing/Scheduling
> #
> CONFIG_NET_SCH_CBQ=m
> CONFIG_NET_SCH_HTB=m
> CONFIG_NET_SCH_HFSC=m
> CONFIG_NET_SCH_ATM=m
> CONFIG_NET_SCH_PRIO=m
> CONFIG_NET_SCH_RED=m
> CONFIG_NET_SCH_SFQ=m
> CONFIG_NET_SCH_TEQL=m
> CONFIG_NET_SCH_TBF=m
> CONFIG_NET_SCH_GRED=m
> CONFIG_NET_SCH_DSMARK=m
> CONFIG_NET_SCH_NETEM=m
> CONFIG_NET_SCH_INGRESS=m
>
> #
> # Classification
> #
> CONFIG_NET_CLS=y
> # CONFIG_NET_CLS_BASIC is not set
> CONFIG_NET_CLS_TCINDEX=m
> CONFIG_NET_CLS_ROUTE4=m
> CONFIG_NET_CLS_ROUTE=y
> CONFIG_NET_CLS_FW=m
> CONFIG_NET_CLS_U32=m
> # CONFIG_CLS_U32_PERF is not set
> # CONFIG_CLS_U32_MARK is not set
> CONFIG_NET_CLS_RSVP=m
> CONFIG_NET_CLS_RSVP6=m
> # CONFIG_NET_EMATCH is not set
> # CONFIG_NET_CLS_ACT is not set
> CONFIG_NET_CLS_POLICE=y
> # CONFIG_NET_CLS_IND is not set
> CONFIG_NET_ESTIMATOR=y
>
> #
> # Network testing
> #
> CONFIG_NET_PKTGEN=m
> CONFIG_HAMRADIO=y
>
> #
> # Packet Radio protocols
> #
> CONFIG_AX25=m
> CONFIG_AX25_DAMA_SLAVE=y
> CONFIG_NETROM=m
> CONFIG_ROSE=m
>
> #
> # AX.25 network device drivers
> #
> CONFIG_MKISS=m
> CONFIG_6PACK=m
> CONFIG_BPQETHER=m
> CONFIG_BAYCOM_SER_FDX=m
> CONFIG_BAYCOM_SER_HDX=m
> CONFIG_YAM=m
> CONFIG_IRDA=m
>
> #
> # IrDA protocols
> #
> CONFIG_IRLAN=m
> CONFIG_IRNET=m
> CONFIG_IRCOMM=m
> CONFIG_IRDA_ULTRA=y
>
> #
> # IrDA options
> #
> CONFIG_IRDA_CACHE_LAST_LSAP=y
> CONFIG_IRDA_FAST_RR=y
> CONFIG_IRDA_DEBUG=y
>
> #
> # Infrared-port device drivers
> #
>
> #
> # SIR device drivers
> #
> CONFIG_IRTTY_SIR=m
>
> #
> # Dongle support
> #
> # CONFIG_DONGLE is not set
>
> #
> # Old SIR device drivers
> #
> # CONFIG_IRPORT_SIR is not set
>
> #
> # Old Serial dongle support
> #
>
> #
> # FIR device drivers
> #
> CONFIG_USB_IRDA=m
> # CONFIG_SIGMATEL_FIR is not set
> # CONFIG_NSC_FIR is not set
> # CONFIG_WINBOND_FIR is not set
> # CONFIG_TOSHIBA_FIR is not set
> # CONFIG_SMC_IRCC_FIR is not set
> # CONFIG_ALI_FIR is not set
> # CONFIG_VLSI_FIR is not set
> # CONFIG_VIA_FIR is not set
> # CONFIG_MCS_FIR is not set
> CONFIG_BT=m
> CONFIG_BT_L2CAP=m
> CONFIG_BT_SCO=m
> CONFIG_BT_RFCOMM=m
> CONFIG_BT_RFCOMM_TTY=y
> CONFIG_BT_BNEP=m
> CONFIG_BT_BNEP_MC_FILTER=y
> CONFIG_BT_BNEP_PROTO_FILTER=y
> CONFIG_BT_CMTP=m
> CONFIG_BT_HIDP=m
>
> #
> # Bluetooth device drivers
> #
> CONFIG_BT_HCIUSB=m
> CONFIG_BT_HCIUSB_SCO=y
> CONFIG_BT_HCIUART=m
> CONFIG_BT_HCIUART_H4=y
> CONFIG_BT_HCIUART_BCSP=y
> CONFIG_BT_HCIBCM203X=m
> # CONFIG_BT_HCIBPA10X is not set
> CONFIG_BT_HCIBFUSB=m
> CONFIG_BT_HCIVHCI=m
> # CONFIG_IEEE80211 is not set
> CONFIG_WIRELESS_EXT=y
> CONFIG_FIB_RULES=y
>
> #
> # Device Drivers
> #
>
> #
> # Generic Driver Options
> #
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=m
> # CONFIG_DEBUG_DRIVER is not set
> # CONFIG_SYS_HYPERVISOR is not set
>
> #
> # Connector - unified userspace <-> kernelspace linker
> #
> # CONFIG_CONNECTOR is not set
>
> #
> # Memory Technology Devices (MTD)
> #
> # CONFIG_MTD is not set
>
> #
> # Parallel port support
> #
> # CONFIG_PARPORT is not set
>
> #
> # Plug and Play support
> #
>
> #
> # Block devices
> #
> CONFIG_BLK_DEV_FD=m
> # CONFIG_MAC_FLOPPY is not set
> CONFIG_BLK_CPQ_DA=m
> CONFIG_BLK_CPQ_CISS_DA=m
> CONFIG_CISS_SCSI_TAPE=y
> CONFIG_BLK_DEV_DAC960=m
> CONFIG_BLK_DEV_UMEM=m
> # CONFIG_BLK_DEV_COW_COMMON is not set
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_CRYPTOLOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_SX8=m
> # CONFIG_BLK_DEV_UB is not set
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=8192
> CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
> CONFIG_BLK_DEV_INITRD=y
> # CONFIG_CDROM_PKTCDVD is not set
> # CONFIG_ATA_OVER_ETH is not set
>
> #
> # Misc devices
> #
> # CONFIG_SGI_IOC4 is not set
> # CONFIG_TIFM_CORE is not set
>
> #
> # ATA/ATAPI/MFM/RLL support
> #
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
>
> #
> # Please see Documentation/ide.txt for help/info on IDE drives
> #
> # CONFIG_BLK_DEV_IDE_SATA is not set
> CONFIG_BLK_DEV_IDEDISK=m
> # CONFIG_IDEDISK_MULTI_MODE is not set
> CONFIG_BLK_DEV_IDECD=m
> CONFIG_BLK_DEV_IDETAPE=m
> CONFIG_BLK_DEV_IDEFLOPPY=m
> CONFIG_BLK_DEV_IDESCSI=m
> # CONFIG_IDE_TASK_IOCTL is not set
>
> #
> # IDE chipset support/bugfixes
> #
> # CONFIG_IDE_GENERIC is not set
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> # CONFIG_BLK_DEV_OFFBOARD is not set
> CONFIG_BLK_DEV_GENERIC=m
> # CONFIG_BLK_DEV_OPTI621 is not set
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> # CONFIG_IDEDMA_ONLYDISK is not set
> CONFIG_BLK_DEV_AEC62XX=m
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> CONFIG_BLK_DEV_CMD64X=m
> # CONFIG_BLK_DEV_TRIFLEX is not set
> # CONFIG_BLK_DEV_CY82C693 is not set
> # CONFIG_BLK_DEV_CS5520 is not set
> # CONFIG_BLK_DEV_CS5530 is not set
> CONFIG_BLK_DEV_HPT34X=m
> # CONFIG_HPT34X_AUTODMA is not set
> CONFIG_BLK_DEV_HPT366=m
> # CONFIG_BLK_DEV_JMICRON is not set
> CONFIG_BLK_DEV_SC1200=m
> # CONFIG_BLK_DEV_PIIX is not set
> # CONFIG_BLK_DEV_IT821X is not set
> CONFIG_BLK_DEV_NS87415=m
> CONFIG_BLK_DEV_PDC202XX_OLD=m
> # CONFIG_PDC202XX_BURST is not set
> CONFIG_BLK_DEV_PDC202XX_NEW=m
> # CONFIG_BLK_DEV_SVWKS is not set
> CONFIG_BLK_DEV_SIIMAGE=m
> CONFIG_BLK_DEV_SL82C105=m
> # CONFIG_BLK_DEV_SLC90E66 is not set
> CONFIG_BLK_DEV_TRM290=m
> CONFIG_BLK_DEV_VIA82CXXX=m
> # CONFIG_BLK_DEV_IDE_PMAC is not set
> # CONFIG_IDE_ARM is not set
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_IDEDMA_IVB is not set
> CONFIG_IDEDMA_AUTO=y
> # CONFIG_BLK_DEV_HD is not set
>
> #
> # SCSI device support
> #
> # CONFIG_RAID_ATTRS is not set
> CONFIG_SCSI=m
> # CONFIG_SCSI_TGT is not set
> CONFIG_SCSI_NETLINK=y
> CONFIG_SCSI_PROC_FS=y
>
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> CONFIG_BLK_DEV_SD=m
> 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
> CONFIG_CHR_DEV_SCH=m
>
> #
> # Some SCSI devices (e.g. CD jukebox) support multiple LUNs
> #
> CONFIG_SCSI_MULTI_LUN=y
> # CONFIG_SCSI_CONSTANTS is not set
> CONFIG_SCSI_LOGGING=y
> # CONFIG_SCSI_SCAN_ASYNC is not set
>
> #
> # SCSI Transports
> #
> CONFIG_SCSI_SPI_ATTRS=m
> CONFIG_SCSI_FC_ATTRS=m
> # CONFIG_SCSI_ISCSI_ATTRS is not set
> # CONFIG_SCSI_SAS_ATTRS is not set
> # CONFIG_SCSI_SAS_LIBSAS is not set
>
> #
> # SCSI low-level drivers
> #
> # CONFIG_ISCSI_TCP is not set
> CONFIG_BLK_DEV_3W_XXXX_RAID=m
> CONFIG_SCSI_3W_9XXX=m
> CONFIG_SCSI_ACARD=m
> CONFIG_SCSI_AACRAID=m
> CONFIG_SCSI_AIC7XXX=m
> CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
> CONFIG_AIC7XXX_RESET_DELAY_MS=15000
> CONFIG_AIC7XXX_DEBUG_ENABLE=y
> CONFIG_AIC7XXX_DEBUG_MASK=0
> CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
> CONFIG_SCSI_AIC7XXX_OLD=m
> CONFIG_SCSI_AIC79XX=m
> CONFIG_AIC79XX_CMDS_PER_DEVICE=32
> CONFIG_AIC79XX_RESET_DELAY_MS=15000
> # CONFIG_AIC79XX_ENABLE_RD_STRM is not set
> CONFIG_AIC79XX_DEBUG_ENABLE=y
> CONFIG_AIC79XX_DEBUG_MASK=0
> CONFIG_AIC79XX_REG_PRETTY_PRINT=y
> # CONFIG_SCSI_AIC94XX is not set
> CONFIG_SCSI_DPT_I2O=m
> # CONFIG_SCSI_ARCMSR is not set
> # CONFIG_MEGARAID_NEWGEN is not set
> # CONFIG_MEGARAID_LEGACY is not set
> # CONFIG_MEGARAID_SAS is not set
> # CONFIG_SCSI_HPTIOP is not set
> CONFIG_SCSI_BUSLOGIC=m
> # CONFIG_SCSI_OMIT_FLASHPOINT is not set
> CONFIG_SCSI_DMX3191D=m
> CONFIG_SCSI_EATA=m
> # CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
> # CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
> CONFIG_SCSI_EATA_MAX_TAGS=16
> CONFIG_SCSI_FUTURE_DOMAIN=m
> # CONFIG_SCSI_GDTH is not set
> CONFIG_SCSI_IPS=m
> # CONFIG_SCSI_INITIO is not set
> CONFIG_SCSI_INIA100=m
> # CONFIG_SCSI_STEX is not set
> CONFIG_SCSI_SYM53C8XX_2=m
> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
> CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
> CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
> CONFIG_SCSI_SYM53C8XX_MMIO=y
> CONFIG_SCSI_QLOGIC_1280=m
> # CONFIG_SCSI_QLA_FC is not set
> # CONFIG_SCSI_QLA_ISCSI is not set
> # CONFIG_SCSI_LPFC is not set
> CONFIG_SCSI_DC395x=m
> CONFIG_SCSI_DC390T=m
> CONFIG_SCSI_NSP32=m
> # CONFIG_SCSI_DEBUG is not set
> # CONFIG_SCSI_MESH is not set
> # CONFIG_SCSI_MAC53C94 is not set
> # CONFIG_SCSI_SRP is not set
>
> #
> # Serial ATA (prod) and Parallel ATA (experimental) drivers
> #
> # CONFIG_ATA is not set
>
> #
> # Multi-device support (RAID and LVM)
> #
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=m
> CONFIG_MD_LINEAR=m
> CONFIG_MD_RAID0=m
> CONFIG_MD_RAID1=m
> # CONFIG_MD_RAID10 is not set
> # CONFIG_MD_RAID456 is not set
> CONFIG_MD_MULTIPATH=m
> # CONFIG_MD_FAULTY is not set
> CONFIG_BLK_DEV_DM=m
> # CONFIG_DM_DEBUG is not set
> CONFIG_DM_CRYPT=m
> CONFIG_DM_SNAPSHOT=m
> CONFIG_DM_MIRROR=m
> CONFIG_DM_ZERO=m
> # CONFIG_DM_MULTIPATH is not set
>
> #
> # Fusion MPT device support
> #
> # CONFIG_FUSION is not set
> # CONFIG_FUSION_SPI is not set
> # CONFIG_FUSION_FC is not set
> # CONFIG_FUSION_SAS is not set
>
> #
> # IEEE 1394 (FireWire) support
> #
> CONFIG_IEEE1394=m
>
> #
> # Subsystem Options
> #
> # CONFIG_IEEE1394_VERBOSEDEBUG is not set
> CONFIG_IEEE1394_OUI_DB=y
> CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
> CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
> # CONFIG_IEEE1394_EXPORT_FULL_API is not set
>
> #
> # Device Drivers
> #
> CONFIG_IEEE1394_PCILYNX=m
> CONFIG_IEEE1394_OHCI1394=m
>
> #
> # Protocol Drivers
> #
> CONFIG_IEEE1394_VIDEO1394=m
> CONFIG_IEEE1394_SBP2=m
> CONFIG_IEEE1394_ETH1394=m
> CONFIG_IEEE1394_DV1394=m
> CONFIG_IEEE1394_RAWIO=m
>
> #
> # I2O device support
> #
> CONFIG_I2O=m
> CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
> CONFIG_I2O_EXT_ADAPTEC=y
> CONFIG_I2O_CONFIG=m
> CONFIG_I2O_CONFIG_OLD_IOCTL=y
> # CONFIG_I2O_BUS is not set
> CONFIG_I2O_BLOCK=m
> CONFIG_I2O_SCSI=m
> CONFIG_I2O_PROC=m
>
> #
> # Macintosh device drivers
> #
> # CONFIG_ADB is not set
> # CONFIG_ADB_CUDA is not set
> # CONFIG_ADB_PMU is not set
> # CONFIG_PMAC_MEDIABAY is not set
> CONFIG_MAC_EMUMOUSEBTN=y
> # CONFIG_THERM_WINDTUNNEL is not set
> # CONFIG_THERM_ADT746X is not set
> # CONFIG_WINDFARM is not set
> # CONFIG_PMAC_RACKMETER is not set
>
> #
> # Network device support
> #
> CONFIG_NETDEVICES=y
> CONFIG_DUMMY=m
> CONFIG_BONDING=m
> CONFIG_EQUALIZER=m
> CONFIG_TUN=m
>
> #
> # ARCnet devices
> #
> CONFIG_ARCNET=m
> CONFIG_ARCNET_1201=m
> CONFIG_ARCNET_1051=m
> CONFIG_ARCNET_RAW=m
> # CONFIG_ARCNET_CAP is not set
> CONFIG_ARCNET_COM90xx=m
> CONFIG_ARCNET_COM90xxIO=m
> CONFIG_ARCNET_RIM_I=m
> CONFIG_ARCNET_COM20020=m
> CONFIG_ARCNET_COM20020_PCI=m
>
> #
> # PHY device support
> #
> # CONFIG_PHYLIB is not set
>
> #
> # Ethernet (10 or 100Mbit)
> #
> CONFIG_NET_ETHERNET=y
> CONFIG_MII=y
> # CONFIG_MACE is not set
> # CONFIG_BMAC is not set
> CONFIG_HAPPYMEAL=m
> CONFIG_SUNGEM=m
> # CONFIG_CASSINI is not set
> CONFIG_NET_VENDOR_3COM=y
> CONFIG_VORTEX=m
> CONFIG_TYPHOON=m
>
> #
> # Tulip family network device support
> #
> CONFIG_NET_TULIP=y
> CONFIG_DE2104X=m
> CONFIG_TULIP=m
> # CONFIG_TULIP_MWI is not set
> # CONFIG_TULIP_MMIO is not set
> # CONFIG_TULIP_NAPI is not set
> CONFIG_DE4X5=m
> CONFIG_WINBOND_840=m
> CONFIG_DM9102=m
> # CONFIG_ULI526X is not set
> CONFIG_HP100=m
> CONFIG_NET_PCI=y
> CONFIG_PCNET32=m
> # CONFIG_PCNET32_NAPI is not set
> # CONFIG_AMD8111_ETH is not set
> CONFIG_ADAPTEC_STARFIRE=m
> # CONFIG_ADAPTEC_STARFIRE_NAPI is not set
> CONFIG_B44=m
> # CONFIG_FORCEDETH is not set
> # CONFIG_DGRS is not set
> CONFIG_EEPRO100=m
> CONFIG_E100=m
> CONFIG_FEALNX=m
> CONFIG_NATSEMI=m
> CONFIG_NE2K_PCI=m
> CONFIG_8139CP=m
> CONFIG_8139TOO=m
> CONFIG_8139TOO_PIO=y
> # CONFIG_8139TOO_TUNE_TWISTER is not set
> CONFIG_8139TOO_8129=y
> # CONFIG_8139_OLD_RX_RESET is not set
> CONFIG_SIS900=m
> CONFIG_EPIC100=m
> CONFIG_SUNDANCE=m
> CONFIG_SUNDANCE_MMIO=y
> CONFIG_TLAN=m
> CONFIG_VIA_RHINE=m
> CONFIG_VIA_RHINE_MMIO=y
> # CONFIG_VIA_RHINE_NAPI is not set
>
> #
> # Ethernet (1000 Mbit)
> #
> # CONFIG_ACENIC is not set
> CONFIG_DL2K=m
> CONFIG_E1000=m
> # CONFIG_E1000_NAPI is not set
> # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
> CONFIG_NS83820=m
> CONFIG_HAMACHI=m
> CONFIG_YELLOWFIN=m
> CONFIG_R8169=m
> # CONFIG_R8169_NAPI is not set
> # CONFIG_R8169_VLAN is not set
> # CONFIG_SIS190 is not set
> # CONFIG_SKGE is not set
> # CONFIG_SKY2 is not set
> CONFIG_SK98LIN=m
> CONFIG_VIA_VELOCITY=m
> CONFIG_TIGON3=m
> # CONFIG_BNX2 is not set
> # CONFIG_MV643XX_ETH is not set
> # CONFIG_QLA3XXX is not set
>
> #
> # Ethernet (10000 Mbit)
> #
> # CONFIG_CHELSIO_T1 is not set
> CONFIG_IXGB=m
> # CONFIG_IXGB_NAPI is not set
> CONFIG_S2IO=m
> # CONFIG_S2IO_NAPI is not set
> # CONFIG_MYRI10GE is not set
> # CONFIG_NETXEN_NIC is not set
>
> #
> # Token Ring devices
> #
> CONFIG_TR=y
> CONFIG_IBMOL=m
> CONFIG_IBMLS=m
> CONFIG_3C359=m
> CONFIG_TMS380TR=m
> CONFIG_TMSPCI=m
> CONFIG_ABYSS=m
>
> #
> # Wireless LAN (non-hamradio)
> #
> CONFIG_NET_RADIO=y
> # CONFIG_NET_WIRELESS_RTNETLINK is not set
>
> #
> # Obsolete Wireless cards support (pre-802.11)
> #
> CONFIG_STRIP=m
>
> #
> # Wireless 802.11b ISA/PCI cards support
> #
> # CONFIG_IPW2100 is not set
> # CONFIG_IPW2200 is not set
> # CONFIG_AIRO is not set
> CONFIG_HERMES=m
> # CONFIG_APPLE_AIRPORT is not set
> CONFIG_PLX_HERMES=m
> CONFIG_TMD_HERMES=m
> # CONFIG_NORTEL_HERMES is not set
> CONFIG_PCI_HERMES=m
> CONFIG_ATMEL=m
> # CONFIG_PCI_ATMEL is not set
>
> #
> # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
> #
> CONFIG_PRISM54=m
> # CONFIG_USB_ZD1201 is not set
> # CONFIG_HOSTAP is not set
> CONFIG_NET_WIRELESS=y
>
> #
> # Wan interfaces
> #
> CONFIG_WAN=y
> CONFIG_LANMEDIA=m
> CONFIG_HDLC=m
> CONFIG_HDLC_RAW=m
> CONFIG_HDLC_RAW_ETH=m
> CONFIG_HDLC_CISCO=m
> CONFIG_HDLC_FR=m
> CONFIG_HDLC_PPP=m
> CONFIG_HDLC_X25=m
> CONFIG_PCI200SYN=m
> CONFIG_WANXL=m
> CONFIG_PC300=m
> CONFIG_PC300_MLPPP=y
>
> #
> # Cyclades-PC300 MLPPP support is disabled.
> #
>
> #
> # Refer to the file README.mlppp, provided by PC300 package.
> #
> CONFIG_FARSYNC=m
> CONFIG_DSCC4=m
> # CONFIG_DSCC4_PCISYNC is not set
> # CONFIG_DSCC4_PCI_RST is not set
> CONFIG_DLCI=m
> CONFIG_DLCI_COUNT=24
> CONFIG_DLCI_MAX=8
> CONFIG_WAN_ROUTER_DRIVERS=m
> CONFIG_CYCLADES_SYNC=m
> CONFIG_CYCLOMX_X25=y
> CONFIG_LAPBETHER=m
> CONFIG_X25_ASY=m
>
> #
> # ATM drivers
> #
> # CONFIG_ATM_DUMMY is not set
> CONFIG_ATM_TCP=m
> CONFIG_ATM_LANAI=m
> CONFIG_ATM_ENI=m
> # CONFIG_ATM_ENI_DEBUG is not set
> # CONFIG_ATM_ENI_TUNE_BURST is not set
> CONFIG_ATM_FIRESTREAM=m
> CONFIG_ATM_ZATM=m
> CONFIG_ATM_ZATM_DEBUG=y
> CONFIG_ATM_NICSTAR=m
> CONFIG_ATM_NICSTAR_USE_SUNI=y
> CONFIG_ATM_NICSTAR_USE_IDT77105=y
> CONFIG_ATM_IDT77252=m
> # CONFIG_ATM_IDT77252_DEBUG is not set
> # CONFIG_ATM_IDT77252_RCV_ALL is not set
> CONFIG_ATM_IDT77252_USE_SUNI=y
> CONFIG_ATM_AMBASSADOR=m
> # CONFIG_ATM_AMBASSADOR_DEBUG is not set
> CONFIG_ATM_HORIZON=m
> # CONFIG_ATM_HORIZON_DEBUG is not set
> CONFIG_ATM_IA=m
> # CONFIG_ATM_IA_DEBUG is not set
> CONFIG_ATM_FORE200E_MAYBE=m
> CONFIG_ATM_FORE200E_PCA=y
> CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y
> CONFIG_ATM_FORE200E_USE_TASKLET=y
> CONFIG_ATM_FORE200E_TX_RETRY=16
> CONFIG_ATM_FORE200E_DEBUG=0
> CONFIG_ATM_FORE200E=m
> CONFIG_ATM_HE=m
> # CONFIG_ATM_HE_USE_SUNI is not set
> CONFIG_FDDI=y
> CONFIG_DEFXX=m
> CONFIG_SKFP=m
> CONFIG_HIPPI=y
> # CONFIG_ROADRUNNER is not set
> CONFIG_PPP=m
> CONFIG_PPP_MULTILINK=y
> CONFIG_PPP_FILTER=y
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_SYNC_TTY=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_BSDCOMP=m
> # CONFIG_PPP_MPPE is not set
> CONFIG_PPPOE=m
> CONFIG_PPPOATM=m
> CONFIG_SLIP=m
> # CONFIG_SLIP_COMPRESSED is not set
> CONFIG_SLHC=m
> # CONFIG_SLIP_SMART is not set
> # CONFIG_SLIP_MODE_SLIP6 is not set
> CONFIG_NET_FC=y
> CONFIG_SHAPER=m
> CONFIG_NETCONSOLE=m
> CONFIG_NETPOLL=y
> CONFIG_NETPOLL_RX=y
> CONFIG_NETPOLL_TRAP=y
> CONFIG_NET_POLL_CONTROLLER=y
>
> #
> # ISDN subsystem
> #
> CONFIG_ISDN=m
>
> #
> # Old ISDN4Linux
> #
> # CONFIG_ISDN_I4L is not set
>
> #
> # CAPI subsystem
> #
> CONFIG_ISDN_CAPI=m
> # CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
> CONFIG_ISDN_CAPI_MIDDLEWARE=y
> CONFIG_ISDN_CAPI_CAPI20=m
> # CONFIG_ISDN_CAPI_CAPIFS_BOOL is not set
>
> #
> # CAPI hardware drivers
> #
>
> #
> # Active AVM cards
> #
> CONFIG_CAPI_AVM=y
> CONFIG_ISDN_DRV_AVMB1_B1PCI=m
> CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
> CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
> CONFIG_ISDN_DRV_AVMB1_T1PCI=m
> CONFIG_ISDN_DRV_AVMB1_C4=m
>
> #
> # Active Eicon DIVA Server cards
> #
> CONFIG_CAPI_EICON=y
> CONFIG_ISDN_DIVAS=m
> CONFIG_ISDN_DIVAS_BRIPCI=y
> CONFIG_ISDN_DIVAS_PRIPCI=y
> CONFIG_ISDN_DIVAS_DIVACAPI=m
> CONFIG_ISDN_DIVAS_USERIDI=m
> CONFIG_ISDN_DIVAS_MAINT=m
>
> #
> # Telephony Support
> #
> CONFIG_PHONE=m
> CONFIG_PHONE_IXJ=m
>
> #
> # Input device support
> #
> CONFIG_INPUT=y
> CONFIG_INPUT_FF_MEMLESS=m
>
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> CONFIG_INPUT_JOYDEV=m
> CONFIG_INPUT_TSDEV=m
> CONFIG_INPUT_TSDEV_SCREEN_X=240
> CONFIG_INPUT_TSDEV_SCREEN_Y=320
> CONFIG_INPUT_EVDEV=m
> CONFIG_INPUT_EVBUG=m
>
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=m
> # CONFIG_KEYBOARD_SUNKBD is not set
> # CONFIG_KEYBOARD_LKKBD is not set
> # CONFIG_KEYBOARD_XTKBD is not set
> # CONFIG_KEYBOARD_NEWTON is not set
> # CONFIG_KEYBOARD_STOWAWAY is not set
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=m
> # CONFIG_MOUSE_SERIAL is not set
> # CONFIG_MOUSE_VSXXXAA is not set
> CONFIG_INPUT_JOYSTICK=y
> CONFIG_JOYSTICK_ANALOG=m
> CONFIG_JOYSTICK_A3D=m
> CONFIG_JOYSTICK_ADI=m
> CONFIG_JOYSTICK_COBRA=m
> CONFIG_JOYSTICK_GF2K=m
> CONFIG_JOYSTICK_GRIP=m
> CONFIG_JOYSTICK_GRIP_MP=m
> CONFIG_JOYSTICK_GUILLEMOT=m
> CONFIG_JOYSTICK_INTERACT=m
> CONFIG_JOYSTICK_SIDEWINDER=m
> CONFIG_JOYSTICK_TMDC=m
> CONFIG_JOYSTICK_IFORCE=m
> CONFIG_JOYSTICK_IFORCE_USB=y
> CONFIG_JOYSTICK_IFORCE_232=y
> CONFIG_JOYSTICK_WARRIOR=m
> CONFIG_JOYSTICK_MAGELLAN=m
> CONFIG_JOYSTICK_SPACEORB=m
> CONFIG_JOYSTICK_SPACEBALL=m
> CONFIG_JOYSTICK_STINGER=m
> # CONFIG_JOYSTICK_TWIDJOY is not set
> # CONFIG_JOYSTICK_JOYDUMP is not set
> CONFIG_INPUT_TOUCHSCREEN=y
> CONFIG_TOUCHSCREEN_GUNZE=m
> # CONFIG_TOUCHSCREEN_ELO is not set
> # CONFIG_TOUCHSCREEN_MTOUCH is not set
> # CONFIG_TOUCHSCREEN_MK712 is not set
> # CONFIG_TOUCHSCREEN_PENMOUNT is not set
> # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
> # CONFIG_TOUCHSCREEN_TOUCHWIN is not set
> # CONFIG_TOUCHSCREEN_UCB1400 is not set
> CONFIG_INPUT_MISC=y
> # CONFIG_INPUT_PCSPKR is not set
> CONFIG_INPUT_UINPUT=m
>
> #
> # Hardware I/O ports
> #
> CONFIG_SERIO=m
> CONFIG_SERIO_I8042=m
> CONFIG_SERIO_SERPORT=m
> # CONFIG_SERIO_PCIPS2 is not set
> CONFIG_SERIO_LIBPS2=m
> # CONFIG_SERIO_RAW is not set
> CONFIG_GAMEPORT=m
> CONFIG_GAMEPORT_NS558=m
> CONFIG_GAMEPORT_L4=m
> CONFIG_GAMEPORT_EMU10K1=m
> CONFIG_GAMEPORT_FM801=m
>
> #
> # Character devices
> #
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> # CONFIG_VT_HW_CONSOLE_BINDING is not set
> # CONFIG_SERIAL_NONSTANDARD is not set
>
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_NR_UARTS=4
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4
> # CONFIG_SERIAL_8250_EXTENDED is not set
>
> #
> # Non-8250 serial port support
> #
> # CONFIG_SERIAL_UARTLITE is not set
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> # CONFIG_SERIAL_PMACZILOG is not set
> # CONFIG_SERIAL_MPC52xx is not set
> # CONFIG_SERIAL_JSM is not set
> CONFIG_UNIX98_PTYS=y
> # CONFIG_LEGACY_PTYS is not set
> # CONFIG_BRIQ_PANEL is not set
> # CONFIG_HVC_RTAS is not set
>
> #
> # IPMI
> #
> CONFIG_IPMI_HANDLER=m
> # CONFIG_IPMI_PANIC_EVENT is not set
> CONFIG_IPMI_DEVICE_INTERFACE=m
> CONFIG_IPMI_SI=m
> CONFIG_IPMI_WATCHDOG=m
> # CONFIG_IPMI_POWEROFF is not set
>
> #
> # Watchdog Cards
> #
> CONFIG_WATCHDOG=y
> # CONFIG_WATCHDOG_NOWAYOUT is not set
>
> #
> # Watchdog Device Drivers
> #
> CONFIG_SOFT_WATCHDOG=m
> # CONFIG_WATCHDOG_RTAS is not set
>
> #
> # PCI-based Watchdog Cards
> #
> CONFIG_PCIPCWATCHDOG=m
> CONFIG_WDTPCI=m
> CONFIG_WDT_501_PCI=y
>
> #
> # USB-based Watchdog Cards
> #
> CONFIG_USBPCWATCHDOG=m
> CONFIG_HW_RANDOM=m
> CONFIG_NVRAM=y
> CONFIG_GEN_RTC=y
> CONFIG_GEN_RTC_X=y
> CONFIG_DTLK=m
> CONFIG_R3964=m
> CONFIG_APPLICOM=m
> CONFIG_AGP=m
> # CONFIG_AGP_UNINORTH is not set
> CONFIG_DRM=m
> CONFIG_DRM_TDFX=m
> CONFIG_DRM_R128=m
> CONFIG_DRM_RADEON=m
> CONFIG_DRM_MGA=m
> CONFIG_DRM_SIS=m
> # CONFIG_DRM_VIA is not set
> # CONFIG_DRM_SAVAGE is not set
> # CONFIG_RAW_DRIVER is not set
>
> #
> # TPM devices
> #
> # CONFIG_TCG_TPM is not set
>
> #
> # I2C support
> #
> CONFIG_I2C=y
> CONFIG_I2C_CHARDEV=m
>
> #
> # I2C Algorithms
> #
> CONFIG_I2C_ALGOBIT=y
> CONFIG_I2C_ALGOPCF=m
> # CONFIG_I2C_ALGOPCA is not set
>
> #
> # I2C Hardware Bus support
> #
> # CONFIG_I2C_ALI1535 is not set
> # CONFIG_I2C_ALI1563 is not set
> # CONFIG_I2C_ALI15X3 is not set
> # CONFIG_I2C_AMD756 is not set
> # CONFIG_I2C_AMD8111 is not set
> # CONFIG_I2C_HYDRA is not set
> # CONFIG_I2C_I801 is not set
> # CONFIG_I2C_I810 is not set
> # CONFIG_I2C_PIIX4 is not set
> CONFIG_I2C_ISA=m
> CONFIG_I2C_POWERMAC=y
> # CONFIG_I2C_MPC is not set
> # CONFIG_I2C_NFORCE2 is not set
> # CONFIG_I2C_OCORES is not set
> CONFIG_I2C_PARPORT_LIGHT=m
> CONFIG_I2C_PROSAVAGE=m
> CONFIG_I2C_SAVAGE4=m
> CONFIG_I2C_SIS5595=m
> CONFIG_I2C_SIS630=m
> CONFIG_I2C_SIS96X=m
> # CONFIG_I2C_STUB is not set
> CONFIG_I2C_VIA=m
> CONFIG_I2C_VIAPRO=m
> CONFIG_I2C_VOODOO3=m
> # CONFIG_I2C_PCA_ISA is not set
>
> #
> # Miscellaneous I2C Chip support
> #
> # CONFIG_SENSORS_DS1337 is not set
> # CONFIG_SENSORS_DS1374 is not set
> CONFIG_SENSORS_EEPROM=m
> CONFIG_SENSORS_PCF8574=m
> # CONFIG_SENSORS_PCA9539 is not set
> CONFIG_SENSORS_PCF8591=m
> # CONFIG_SENSORS_M41T00 is not set
> # CONFIG_SENSORS_MAX6875 is not set
> # CONFIG_I2C_DEBUG_CORE is not set
> # CONFIG_I2C_DEBUG_ALGO is not set
> # CONFIG_I2C_DEBUG_BUS is not set
> # CONFIG_I2C_DEBUG_CHIP is not set
>
> #
> # SPI support
> #
> # CONFIG_SPI is not set
> # CONFIG_SPI_MASTER is not set
>
> #
> # Dallas's 1-wire bus
> #
> CONFIG_W1=m
>
> #
> # 1-wire Bus Masters
> #
> # CONFIG_W1_MASTER_MATROX is not set
> # CONFIG_W1_MASTER_DS2490 is not set
> # CONFIG_W1_MASTER_DS2482 is not set
>
> #
> # 1-wire Slaves
> #
> # CONFIG_W1_SLAVE_THERM is not set
> # CONFIG_W1_SLAVE_SMEM is not set
> # CONFIG_W1_SLAVE_DS2433 is not set
>
> #
> # Hardware Monitoring support
> #
> CONFIG_HWMON=y
> CONFIG_HWMON_VID=m
> # CONFIG_SENSORS_ABITUGURU is not set
> CONFIG_SENSORS_ADM1021=m
> CONFIG_SENSORS_ADM1025=m
> # CONFIG_SENSORS_ADM1026 is not set
> CONFIG_SENSORS_ADM1031=m
> # CONFIG_SENSORS_ADM9240 is not set
> # CONFIG_SENSORS_AMS is not set
> CONFIG_SENSORS_ASB100=m
> # CONFIG_SENSORS_ATXP1 is not set
> CONFIG_SENSORS_DS1621=m
> # CONFIG_SENSORS_F71805F is not set
> CONFIG_SENSORS_FSCHER=m
> # CONFIG_SENSORS_FSCPOS is not set
> CONFIG_SENSORS_GL518SM=m
> # CONFIG_SENSORS_GL520SM is not set
> CONFIG_SENSORS_IT87=m
> # CONFIG_SENSORS_LM63 is not set
> CONFIG_SENSORS_LM75=m
> CONFIG_SENSORS_LM77=m
> CONFIG_SENSORS_LM78=m
> CONFIG_SENSORS_LM80=m
> CONFIG_SENSORS_LM83=m
> CONFIG_SENSORS_LM85=m
> # CONFIG_SENSORS_LM87 is not set
> CONFIG_SENSORS_LM90=m
> # CONFIG_SENSORS_LM92 is not set
> CONFIG_SENSORS_MAX1619=m
> # CONFIG_SENSORS_PC87360 is not set
> # CONFIG_SENSORS_PC87427 is not set
> # CONFIG_SENSORS_SIS5595 is not set
> # CONFIG_SENSORS_SMSC47M1 is not set
> # CONFIG_SENSORS_SMSC47M192 is not set
> # CONFIG_SENSORS_SMSC47B397 is not set
> CONFIG_SENSORS_VIA686A=m
> # CONFIG_SENSORS_VT1211 is not set
> # CONFIG_SENSORS_VT8231 is not set
> CONFIG_SENSORS_W83781D=m
> # CONFIG_SENSORS_W83791D is not set
> # CONFIG_SENSORS_W83792D is not set
> # CONFIG_SENSORS_W83793 is not set
> CONFIG_SENSORS_W83L785TS=m
> CONFIG_SENSORS_W83627HF=m
> # CONFIG_SENSORS_W83627EHF is not set
> # CONFIG_HWMON_DEBUG_CHIP is not set
>
> #
> # Multimedia devices
> #
> CONFIG_VIDEO_DEV=m
> CONFIG_VIDEO_V4L1=y
> CONFIG_VIDEO_V4L1_COMPAT=y
> CONFIG_VIDEO_V4L2=y
>
> #
> # Video Capture Adapters
> #
>
> #
> # Video Capture Adapters
> #
> # CONFIG_VIDEO_ADV_DEBUG is not set
> CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
> CONFIG_VIDEO_TVAUDIO=m
> CONFIG_VIDEO_TDA7432=m
> CONFIG_VIDEO_TDA9840=m
> CONFIG_VIDEO_TDA9875=m
> CONFIG_VIDEO_TEA6415C=m
> CONFIG_VIDEO_TEA6420=m
> CONFIG_VIDEO_MSP3400=m
> CONFIG_VIDEO_BT819=m
> CONFIG_VIDEO_BT856=m
> CONFIG_VIDEO_SAA7110=m
> CONFIG_VIDEO_SAA7111=m
> CONFIG_VIDEO_SAA7114=m
> CONFIG_VIDEO_VPX3220=m
> CONFIG_VIDEO_SAA7185=m
> CONFIG_VIDEO_ADV7170=m
> CONFIG_VIDEO_ADV7175=m
> # CONFIG_VIDEO_VIVI is not set
> CONFIG_VIDEO_BT848=m
> # CONFIG_VIDEO_BT848_DVB is not set
> # CONFIG_VIDEO_SAA6588 is not set
> CONFIG_VIDEO_CPIA=m
> CONFIG_VIDEO_CPIA_USB=m
> # CONFIG_VIDEO_CPIA2 is not set
> CONFIG_VIDEO_SAA5246A=m
> CONFIG_VIDEO_SAA5249=m
> CONFIG_TUNER_3036=m
> CONFIG_VIDEO_STRADIS=m
> CONFIG_VIDEO_ZORAN_ZR36060=m
> CONFIG_VIDEO_ZORAN=m
> CONFIG_VIDEO_ZORAN_BUZ=m
> CONFIG_VIDEO_ZORAN_DC10=m
> CONFIG_VIDEO_ZORAN_DC30=m
> CONFIG_VIDEO_ZORAN_LML33=m
> CONFIG_VIDEO_ZORAN_LML33R10=m
> # CONFIG_VIDEO_ZORAN_AVS6EYES is not set
> CONFIG_VIDEO_SAA7134=m
> # CONFIG_VIDEO_SAA7134_ALSA is not set
> # CONFIG_VIDEO_SAA7134_DVB is not set
> CONFIG_VIDEO_MXB=m
> CONFIG_VIDEO_DPC=m
> CONFIG_VIDEO_HEXIUM_ORION=m
> CONFIG_VIDEO_HEXIUM_GEMINI=m
> CONFIG_VIDEO_CX88=m
> # CONFIG_VIDEO_CX88_ALSA is not set
> # CONFIG_VIDEO_CX88_BLACKBIRD is not set
> # CONFIG_VIDEO_CX88_DVB is not set
> # CONFIG_VIDEO_CAFE_CCIC is not set
>
> #
> # V4L USB devices
> #
> # CONFIG_VIDEO_PVRUSB2 is not set
> # CONFIG_VIDEO_EM28XX is not set
> # CONFIG_VIDEO_USBVISION is not set
> CONFIG_VIDEO_USBVIDEO=m
> CONFIG_USB_VICAM=m
> CONFIG_USB_IBMCAM=m
> CONFIG_USB_KONICAWC=m
> # CONFIG_USB_QUICKCAM_MESSENGER is not set
> # CONFIG_USB_ET61X251 is not set
> CONFIG_VIDEO_OVCAMCHIP=m
> CONFIG_USB_W9968CF=m
> CONFIG_USB_OV511=m
> CONFIG_USB_SE401=m
> CONFIG_USB_SN9C102=m
> CONFIG_USB_STV680=m
> # CONFIG_USB_ZC0301 is not set
> CONFIG_USB_PWC=m
> # CONFIG_USB_PWC_DEBUG is not set
>
> #
> # Radio Adapters
> #
> CONFIG_RADIO_GEMTEK_PCI=m
> CONFIG_RADIO_MAXIRADIO=m
> CONFIG_RADIO_MAESTRO=m
> CONFIG_USB_DSBR=m
>
> #
> # Digital Video Broadcasting Devices
> #
> CONFIG_DVB=y
> CONFIG_DVB_CORE=m
> # CONFIG_DVB_CORE_ATTACH is not set
>
> #
> # Supported SAA7146 based PCI Adapters
> #
> CONFIG_DVB_AV7110=m
> CONFIG_DVB_AV7110_OSD=y
> CONFIG_DVB_BUDGET=m
> CONFIG_DVB_BUDGET_CI=m
> CONFIG_DVB_BUDGET_AV=m
> CONFIG_DVB_BUDGET_PATCH=m
>
> #
> # Supported USB Adapters
> #
> # CONFIG_DVB_USB is not set
> CONFIG_DVB_TTUSB_BUDGET=m
> CONFIG_DVB_TTUSB_DEC=m
> # CONFIG_DVB_CINERGYT2 is not set
>
> #
> # Supported FlexCopII (B2C2) Adapters
> #
> # CONFIG_DVB_B2C2_FLEXCOP is not set
>
> #
> # Supported BT878 Adapters
> #
> CONFIG_DVB_BT8XX=m
>
> #
> # Supported Pluto2 Adapters
> #
> # CONFIG_DVB_PLUTO2 is not set
>
> #
> # Supported DVB Frontends
> #
>
> #
> # Customise DVB Frontends
> #
> # CONFIG_DVB_FE_CUSTOMISE is not set
>
> #
> # DVB-S (satellite) frontends
> #
> CONFIG_DVB_STV0299=m
> CONFIG_DVB_CX24110=m
> # CONFIG_DVB_CX24123 is not set
> CONFIG_DVB_TDA8083=m
> CONFIG_DVB_MT312=m
> CONFIG_DVB_VES1X93=m
> CONFIG_DVB_S5H1420=m
> CONFIG_DVB_TDA10086=m
>
> #
> # DVB-T (terrestrial) frontends
> #
> CONFIG_DVB_SP8870=m
> CONFIG_DVB_SP887X=m
> CONFIG_DVB_CX22700=m
> # CONFIG_DVB_CX22702 is not set
> CONFIG_DVB_L64781=m
> CONFIG_DVB_TDA1004X=m
> CONFIG_DVB_NXT6000=m
> CONFIG_DVB_MT352=m
> CONFIG_DVB_ZL10353=m
> # CONFIG_DVB_DIB3000MB is not set
> # CONFIG_DVB_DIB3000MC is not set
> # CONFIG_DVB_DIB7000M is not set
> # CONFIG_DVB_DIB7000P is not set
>
> #
> # DVB-C (cable) frontends
> #
> CONFIG_DVB_VES1820=m
> CONFIG_DVB_TDA10021=m
> CONFIG_DVB_STV0297=m
>
> #
> # ATSC (North American/Korean Terrestrial/Cable DTV) frontends
> #
> # CONFIG_DVB_NXT200X is not set
> CONFIG_DVB_OR51211=m
> # CONFIG_DVB_OR51132 is not set
> # CONFIG_DVB_BCM3510 is not set
> CONFIG_DVB_LGDT330X=m
>
> #
> # Tuners/PLL support
> #
> CONFIG_DVB_PLL=m
> CONFIG_DVB_TDA826X=m
> # CONFIG_DVB_TUNER_MT2060 is not set
> CONFIG_DVB_TUNER_LGH06XF=m
>
> #
> # Miscellaneous devices
> #
> CONFIG_DVB_LNBP21=m
> # CONFIG_DVB_ISL6421 is not set
> CONFIG_DVB_TUA6100=m
> CONFIG_VIDEO_SAA7146=m
> CONFIG_VIDEO_SAA7146_VV=m
> CONFIG_VIDEO_VIDEOBUF=m
> CONFIG_VIDEO_TUNER=m
> CONFIG_VIDEO_BUF=m
> CONFIG_VIDEO_BTCX=m
> CONFIG_VIDEO_IR=m
> CONFIG_VIDEO_TVEEPROM=m
> # CONFIG_USB_DABUSB is not set
>
> #
> # Graphics support
> #
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB=y
> CONFIG_FB_DDC=y
> CONFIG_FB_CFB_FILLRECT=y
> CONFIG_FB_CFB_COPYAREA=y
> CONFIG_FB_CFB_IMAGEBLIT=y
> CONFIG_FB_MACMODES=y
> # CONFIG_FB_BACKLIGHT is not set
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_CIRRUS=m
> # CONFIG_FB_PM2 is not set
> # CONFIG_FB_CYBER2000 is not set
> CONFIG_FB_OF=y
> # CONFIG_FB_CONTROL is not set
> # CONFIG_FB_PLATINUM is not set
> # CONFIG_FB_VALKYRIE is not set
> CONFIG_FB_CT65550=y
> # CONFIG_FB_ASILIANT is not set
> CONFIG_FB_IMSTT=y
> CONFIG_FB_VGA16=m
> # CONFIG_FB_S1D13XXX is not set
> # CONFIG_FB_NVIDIA is not set
> CONFIG_FB_RIVA=m
> CONFIG_FB_RIVA_I2C=y
> # CONFIG_FB_RIVA_DEBUG is not set
> CONFIG_FB_MATROX=y
> CONFIG_FB_MATROX_MILLENIUM=y
> CONFIG_FB_MATROX_MYSTIQUE=y
> # CONFIG_FB_MATROX_G is not set
> CONFIG_FB_MATROX_I2C=m
> CONFIG_FB_MATROX_MULTIHEAD=y
> CONFIG_FB_RADEON=y
> CONFIG_FB_RADEON_I2C=y
> # CONFIG_FB_RADEON_DEBUG is not set
> CONFIG_FB_ATY128=y
> CONFIG_FB_ATY=y
> CONFIG_FB_ATY_CT=y
> # CONFIG_FB_ATY_GENERIC_LCD is not set
> CONFIG_FB_ATY_GX=y
> # CONFIG_FB_SAVAGE is not set
> CONFIG_FB_SIS=m
> CONFIG_FB_SIS_300=y
> CONFIG_FB_SIS_315=y
> CONFIG_FB_NEOMAGIC=m
> CONFIG_FB_KYRO=m
> CONFIG_FB_3DFX=y
> # CONFIG_FB_3DFX_ACCEL is not set
> CONFIG_FB_VOODOO1=y
> CONFIG_FB_TRIDENT=m
> CONFIG_FB_TRIDENT_ACCEL=y
> # CONFIG_FB_IBM_GXT4500 is not set
> # CONFIG_FB_VIRTUAL is not set
>
> #
> # Console display driver support
> #
> CONFIG_VGA_CONSOLE=y
> # CONFIG_VGACON_SOFT_SCROLLBACK is not set
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
> # CONFIG_FONTS is not set
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
>
> #
> # Logo configuration
> #
> CONFIG_LOGO=y
> # CONFIG_LOGO_LINUX_MONO is not set
> CONFIG_LOGO_LINUX_VGA16=y
> # CONFIG_LOGO_LINUX_CLUT224 is not set
> # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
>
> #
> # Sound
> #
> CONFIG_SOUND=m
> # CONFIG_DMASOUND_PMAC is not set
>
> #
> # Advanced Linux Sound Architecture
> #
> CONFIG_SND=m
> CONFIG_SND_TIMER=m
> CONFIG_SND_PCM=m
> CONFIG_SND_HWDEP=m
> CONFIG_SND_RAWMIDI=m
> CONFIG_SND_SEQUENCER=m
> # CONFIG_SND_SEQ_DUMMY is not set
> CONFIG_SND_OSSEMUL=y
> CONFIG_SND_MIXER_OSS=m
> CONFIG_SND_PCM_OSS=m
> CONFIG_SND_PCM_OSS_PLUGINS=y
> CONFIG_SND_SEQUENCER_OSS=y
> # CONFIG_SND_DYNAMIC_MINORS is not set
> CONFIG_SND_SUPPORT_OLD_API=y
> CONFIG_SND_VERBOSE_PROCFS=y
> # CONFIG_SND_VERBOSE_PRINTK is not set
> # CONFIG_SND_DEBUG is not set
>
> #
> # Generic devices
> #
> CONFIG_SND_MPU401_UART=m
> CONFIG_SND_OPL3_LIB=m
> CONFIG_SND_VX_LIB=m
> CONFIG_SND_AC97_CODEC=m
> # CONFIG_SND_DUMMY is not set
> # CONFIG_SND_VIRMIDI is not set
> # CONFIG_SND_MTPAV is not set
> # CONFIG_SND_SERIAL_U16550 is not set
> # CONFIG_SND_MPU401 is not set
>
> #
> # PCI devices
> #
> # CONFIG_SND_AD1889 is not set
> # CONFIG_SND_ALS300 is not set
> CONFIG_SND_ALS4000=m
> # CONFIG_SND_ALI5451 is not set
> CONFIG_SND_ATIIXP=m
> # CONFIG_SND_ATIIXP_MODEM is not set
> CONFIG_SND_AU8810=m
> CONFIG_SND_AU8820=m
> CONFIG_SND_AU8830=m
> CONFIG_SND_AZT3328=m
> CONFIG_SND_BT87X=m
> # CONFIG_SND_BT87X_OVERCLOCK is not set
> # CONFIG_SND_CA0106 is not set
> CONFIG_SND_CMIPCI=m
> CONFIG_SND_CS4281=m
> CONFIG_SND_CS46XX=m
> CONFIG_SND_CS46XX_NEW_DSP=y
> # CONFIG_SND_DARLA20 is not set
> # CONFIG_SND_GINA20 is not set
> # CONFIG_SND_LAYLA20 is not set
> # CONFIG_SND_DARLA24 is not set
> # CONFIG_SND_GINA24 is not set
> # CONFIG_SND_LAYLA24 is not set
> # CONFIG_SND_MONA is not set
> # CONFIG_SND_MIA is not set
> # CONFIG_SND_ECHO3G is not set
> # CONFIG_SND_INDIGO is not set
> # CONFIG_SND_INDIGOIO is not set
> # CONFIG_SND_INDIGODJ is not set
> CONFIG_SND_EMU10K1=m
> # CONFIG_SND_EMU10K1X is not set
> CONFIG_SND_ENS1370=m
> CONFIG_SND_ENS1371=m
> CONFIG_SND_ES1938=m
> CONFIG_SND_ES1968=m
> CONFIG_SND_FM801=m
> # CONFIG_SND_FM801_TEA575X_BOOL is not set
> # CONFIG_SND_HDA_INTEL is not set
> CONFIG_SND_HDSP=m
> # CONFIG_SND_HDSPM is not set
> CONFIG_SND_ICE1712=m
> CONFIG_SND_ICE1724=m
> # CONFIG_SND_INTEL8X0 is not set
> # CONFIG_SND_INTEL8X0M is not set
> CONFIG_SND_KORG1212=m
> CONFIG_SND_MAESTRO3=m
> CONFIG_SND_MIXART=m
> CONFIG_SND_NM256=m
> # CONFIG_SND_PCXHR is not set
> # CONFIG_SND_RIPTIDE is not set
> CONFIG_SND_RME32=m
> CONFIG_SND_RME96=m
> CONFIG_SND_RME9652=m
> CONFIG_SND_SONICVIBES=m
> CONFIG_SND_TRIDENT=m
> CONFIG_SND_VIA82XX=m
> # CONFIG_SND_VIA82XX_MODEM is not set
> CONFIG_SND_VX222=m
> CONFIG_SND_YMFPCI=m
> # CONFIG_SND_AC97_POWER_SAVE is not set
>
> #
> # ALSA PowerMac devices
> #
> # CONFIG_SND_POWERMAC is not set
>
> #
> # Apple Onboard Audio driver
> #
> # CONFIG_SND_AOA is not set
> # CONFIG_SND_AOA_SOUNDBUS is not set
>
> #
> # USB devices
> #
> CONFIG_SND_USB_AUDIO=m
> # CONFIG_SND_USB_USX2Y is not set
>
> #
> # Open Sound System
> #
> # CONFIG_SOUND_PRIME is not set
> CONFIG_AC97_BUS=m
>
> #
> # HID Devices
> #
> CONFIG_HID=y
>
> #
> # USB support
> #
> CONFIG_USB_ARCH_HAS_HCD=y
> CONFIG_USB_ARCH_HAS_OHCI=y
> CONFIG_USB_ARCH_HAS_EHCI=y
> CONFIG_USB=m
> # CONFIG_USB_DEBUG is not set
>
> #
> # Miscellaneous USB options
> #
> CONFIG_USB_DEVICEFS=y
> CONFIG_USB_BANDWIDTH=y
> CONFIG_USB_DYNAMIC_MINORS=y
> # CONFIG_USB_SUSPEND is not set
> # CONFIG_USB_MULTITHREAD_PROBE is not set
> # CONFIG_USB_OTG is not set
>
> #
> # USB Host Controller Drivers
> #
> CONFIG_USB_EHCI_HCD=m
> CONFIG_USB_EHCI_SPLIT_ISO=y
> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> # CONFIG_USB_EHCI_TT_NEWSCHED is not set
> # CONFIG_USB_ISP116X_HCD is not set
> CONFIG_USB_OHCI_HCD=m
> CONFIG_USB_OHCI_HCD_PPC_SOC=y
> CONFIG_USB_OHCI_HCD_PCI=y
> CONFIG_USB_OHCI_BIG_ENDIAN=y
> CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> CONFIG_USB_UHCI_HCD=m
> # CONFIG_USB_SL811_HCD is not set
>
> #
> # USB Device Class drivers
> #
> CONFIG_USB_ACM=m
> CONFIG_USB_PRINTER=m
>
> #
> # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
> #
>
> #
> # may also be needed; see USB_STORAGE Help for more information
> #
> CONFIG_USB_STORAGE=m
> # CONFIG_USB_STORAGE_DEBUG is not set
> CONFIG_USB_STORAGE_DATAFAB=y
> CONFIG_USB_STORAGE_FREECOM=y
> CONFIG_USB_STORAGE_ISD200=y
> CONFIG_USB_STORAGE_DPCM=y
> # CONFIG_USB_STORAGE_USBAT is not set
> CONFIG_USB_STORAGE_SDDR09=y
> CONFIG_USB_STORAGE_SDDR55=y
> CONFIG_USB_STORAGE_JUMPSHOT=y
> # CONFIG_USB_STORAGE_ALAUDA is not set
> # CONFIG_USB_STORAGE_KARMA is not set
> # CONFIG_USB_LIBUSUAL is not set
>
> #
> # USB Input Devices
> #
> CONFIG_USB_HID=m
> # CONFIG_USB_HIDINPUT_POWERBOOK is not set
> CONFIG_HID_FF=y
> CONFIG_HID_PID=y
> CONFIG_LOGITECH_FF=y
> CONFIG_THRUSTMASTER_FF=y
> # CONFIG_ZEROPLUS_FF is not set
> CONFIG_USB_HIDDEV=y
>
> #
> # USB HID Boot Protocol drivers
> #
> # CONFIG_USB_KBD is not set
> # CONFIG_USB_MOUSE is not set
> CONFIG_USB_AIPTEK=m
> CONFIG_USB_WACOM=m
> # CONFIG_USB_ACECAD is not set
> CONFIG_USB_KBTAB=m
> CONFIG_USB_POWERMATE=m
> # CONFIG_USB_TOUCHSCREEN is not set
> # CONFIG_USB_YEALINK is not set
> CONFIG_USB_XPAD=m
> CONFIG_USB_ATI_REMOTE=m
> # CONFIG_USB_ATI_REMOTE2 is not set
> # CONFIG_USB_KEYSPAN_REMOTE is not set
> # CONFIG_USB_APPLETOUCH is not set
>
> #
> # USB Imaging devices
> #
> CONFIG_USB_MDC800=m
> CONFIG_USB_MICROTEK=m
>
> #
> # USB Network Adapters
> #
> CONFIG_USB_CATC=m
> CONFIG_USB_KAWETH=m
> CONFIG_USB_PEGASUS=m
> CONFIG_USB_RTL8150=m
> CONFIG_USB_USBNET_MII=m
> CONFIG_USB_USBNET=m
> CONFIG_USB_NET_AX8817X=m
> CONFIG_USB_NET_CDCETHER=m
> # CONFIG_USB_NET_GL620A is not set
> CONFIG_USB_NET_NET1080=m
> # CONFIG_USB_NET_PLUSB is not set
> # CONFIG_USB_NET_MCS7830 is not set
> # CONFIG_USB_NET_RNDIS_HOST is not set
> # CONFIG_USB_NET_CDC_SUBSET is not set
> CONFIG_USB_NET_ZAURUS=m
> CONFIG_USB_MON=y
>
> #
> # USB port drivers
> #
>
> #
> # USB Serial Converter support
> #
> CONFIG_USB_SERIAL=m
> CONFIG_USB_SERIAL_GENERIC=y
> # CONFIG_USB_SERIAL_AIRCABLE is not set
> # CONFIG_USB_SERIAL_AIRPRIME is not set
> # CONFIG_USB_SERIAL_ARK3116 is not set
> CONFIG_USB_SERIAL_BELKIN=m
> # CONFIG_USB_SERIAL_WHITEHEAT is not set
> CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
> # CONFIG_USB_SERIAL_CP2101 is not set
> # CONFIG_USB_SERIAL_CYPRESS_M8 is not set
> CONFIG_USB_SERIAL_EMPEG=m
> CONFIG_USB_SERIAL_FTDI_SIO=m
> # CONFIG_USB_SERIAL_FUNSOFT is not set
> CONFIG_USB_SERIAL_VISOR=m
> CONFIG_USB_SERIAL_IPAQ=m
> CONFIG_USB_SERIAL_IR=m
> CONFIG_USB_SERIAL_EDGEPORT=m
> CONFIG_USB_SERIAL_EDGEPORT_TI=m
> # CONFIG_USB_SERIAL_GARMIN is not set
> # CONFIG_USB_SERIAL_IPW is not set
> CONFIG_USB_SERIAL_KEYSPAN_PDA=m
> CONFIG_USB_SERIAL_KEYSPAN=m
> # CONFIG_USB_SERIAL_KEYSPAN_MPR is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set
> CONFIG_USB_SERIAL_KLSI=m
> CONFIG_USB_SERIAL_KOBIL_SCT=m
> CONFIG_USB_SERIAL_MCT_U232=m
> # CONFIG_USB_SERIAL_MOS7720 is not set
> # CONFIG_USB_SERIAL_MOS7840 is not set
> # CONFIG_USB_SERIAL_NAVMAN is not set
> CONFIG_USB_SERIAL_PL2303=m
> # CONFIG_USB_SERIAL_HP4X is not set
> CONFIG_USB_SERIAL_SAFE=m
> CONFIG_USB_SERIAL_SAFE_PADDED=y
> # CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
> # CONFIG_USB_SERIAL_TI is not set
> CONFIG_USB_SERIAL_CYBERJACK=m
> CONFIG_USB_SERIAL_XIRCOM=m
> # CONFIG_USB_SERIAL_OPTION is not set
> CONFIG_USB_SERIAL_OMNINET=m
> # CONFIG_USB_SERIAL_DEBUG is not set
> CONFIG_USB_EZUSB=y
>
> #
> # USB Miscellaneous drivers
> #
> # CONFIG_USB_EMI62 is not set
> # CONFIG_USB_EMI26 is not set
> # CONFIG_USB_ADUTUX is not set
> CONFIG_USB_AUERSWALD=m
> CONFIG_USB_RIO500=m
> CONFIG_USB_LEGOTOWER=m
> CONFIG_USB_LCD=m
> CONFIG_USB_LED=m
> # CONFIG_USB_CYPRESS_CY7C63 is not set
> CONFIG_USB_CYTHERM=m
> # CONFIG_USB_PHIDGET is not set
> # CONFIG_USB_IDMOUSE is not set
> # CONFIG_USB_FTDI_ELAN is not set
> # CONFIG_USB_APPLEDISPLAY is not set
> # CONFIG_USB_SISUSBVGA is not set
> # CONFIG_USB_LD is not set
> # CONFIG_USB_TRANCEVIBRATOR is not set
> CONFIG_USB_TEST=m
>
> #
> # USB DSL modem support
> #
> # CONFIG_USB_ATM is not set
>
> #
> # USB Gadget Support
> #
> CONFIG_USB_GADGET=m
> # CONFIG_USB_GADGET_DEBUG_FILES is not set
> CONFIG_USB_GADGET_SELECTED=y
> CONFIG_USB_GADGET_NET2280=y
> CONFIG_USB_NET2280=m
> # CONFIG_USB_GADGET_PXA2XX is not set
> # CONFIG_USB_GADGET_GOKU is not set
> # CONFIG_USB_GADGET_LH7A40X is not set
> # CONFIG_USB_GADGET_OMAP is not set
> # CONFIG_USB_GADGET_AT91 is not set
> # CONFIG_USB_GADGET_DUMMY_HCD is not set
> CONFIG_USB_GADGET_DUALSPEED=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_GADGETFS=m
> CONFIG_USB_FILE_STORAGE=m
> CONFIG_USB_FILE_STORAGE_TEST=y
> CONFIG_USB_G_SERIAL=m
> # CONFIG_USB_MIDI_GADGET is not set
>
> #
> # MMC/SD Card support
> #
> # CONFIG_MMC is not set
>
> #
> # LED devices
> #
> # CONFIG_NEW_LEDS is not set
>
> #
> # LED drivers
> #
>
> #
> # LED Triggers
> #
>
> #
> # InfiniBand support
> #
> # CONFIG_INFINIBAND is not set
>
> #
> # EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
> #
>
> #
> # Real Time Clock
> #
> # CONFIG_RTC_CLASS is not set
>
> #
> # DMA Engine support
> #
> # CONFIG_DMA_ENGINE is not set
>
> #
> # DMA Clients
> #
>
> #
> # DMA Devices
> #
>
> #
> # Virtualization
> #
>
> #
> # File systems
> #
> CONFIG_EXT2_FS=m
> # CONFIG_EXT2_FS_XATTR is not set
> # CONFIG_EXT2_FS_XIP is not set
> CONFIG_EXT3_FS=m
> CONFIG_EXT3_FS_XATTR=y
> # CONFIG_EXT3_FS_POSIX_ACL is not set
> # CONFIG_EXT3_FS_SECURITY is not set
> # CONFIG_EXT4DEV_FS is not set
> CONFIG_JBD=m
> # CONFIG_JBD_DEBUG is not set
> CONFIG_FS_MBCACHE=m
> CONFIG_REISERFS_FS=m
> # CONFIG_REISERFS_CHECK is not set
> # CONFIG_REISERFS_PROC_INFO is not set
> CONFIG_REISERFS_FS_XATTR=y
> # CONFIG_REISERFS_FS_POSIX_ACL is not set
> # CONFIG_REISERFS_FS_SECURITY is not set
> CONFIG_JFS_FS=m
> # CONFIG_JFS_POSIX_ACL is not set
> # CONFIG_JFS_SECURITY is not set
> # CONFIG_JFS_DEBUG is not set
> CONFIG_JFS_STATISTICS=y
> CONFIG_FS_POSIX_ACL=y
> CONFIG_XFS_FS=m
> CONFIG_XFS_QUOTA=y
> # CONFIG_XFS_SECURITY is not set
> CONFIG_XFS_POSIX_ACL=y
> # CONFIG_XFS_RT is not set
> # CONFIG_GFS2_FS is not set
> # CONFIG_OCFS2_FS is not set
> CONFIG_MINIX_FS=m
> # CONFIG_ROMFS_FS is not set
> CONFIG_INOTIFY=y
> CONFIG_INOTIFY_USER=y
> # CONFIG_QUOTA is not set
> CONFIG_QUOTACTL=y
> CONFIG_DNOTIFY=y
> # CONFIG_AUTOFS_FS is not set
> CONFIG_AUTOFS4_FS=m
> # CONFIG_FUSE_FS is not set
>
> #
> # CD-ROM/DVD Filesystems
> #
> CONFIG_ISO9660_FS=m
> CONFIG_JOLIET=y
> CONFIG_ZISOFS=y
> CONFIG_ZISOFS_FS=m
> CONFIG_UDF_FS=m
> CONFIG_UDF_NLS=y
>
> #
> # DOS/FAT/NT Filesystems
> #
> CONFIG_FAT_FS=m
> CONFIG_MSDOS_FS=m
> CONFIG_VFAT_FS=m
> CONFIG_FAT_DEFAULT_CODEPAGE=437
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> CONFIG_NTFS_FS=m
> # CONFIG_NTFS_DEBUG is not set
> # CONFIG_NTFS_RW is not set
>
> #
> # Pseudo filesystems
> #
> CONFIG_PROC_FS=y
> CONFIG_PROC_KCORE=y
> CONFIG_PROC_SYSCTL=y
> CONFIG_SYSFS=y
> CONFIG_TMPFS=y
> # CONFIG_TMPFS_POSIX_ACL is not set
> # CONFIG_HUGETLB_PAGE is not set
> CONFIG_RAMFS=y
> # CONFIG_CONFIGFS_FS is not set
>
> #
> # Miscellaneous filesystems
> #
> CONFIG_ADFS_FS=m
> # CONFIG_ADFS_FS_RW is not set
> CONFIG_AFFS_FS=m
> CONFIG_HFS_FS=m
> CONFIG_HFSPLUS_FS=m
> CONFIG_BEFS_FS=m
> # CONFIG_BEFS_DEBUG is not set
> CONFIG_BFS_FS=m
> CONFIG_EFS_FS=m
> CONFIG_CRAMFS=y
> CONFIG_VXFS_FS=m
> CONFIG_HPFS_FS=m
> CONFIG_QNX4FS_FS=m
> CONFIG_SYSV_FS=m
> CONFIG_UFS_FS=m
> # CONFIG_UFS_FS_WRITE is not set
> # CONFIG_UFS_DEBUG is not set
>
> #
> # Network File Systems
> #
> CONFIG_NFS_FS=m
> CONFIG_NFS_V3=y
> # CONFIG_NFS_V3_ACL is not set
> CONFIG_NFS_V4=y
> # CONFIG_NFS_DIRECTIO is not set
> CONFIG_NFSD=m
> CONFIG_NFSD_V3=y
> # CONFIG_NFSD_V3_ACL is not set
> CONFIG_NFSD_V4=y
> CONFIG_NFSD_TCP=y
> CONFIG_LOCKD=m
> CONFIG_LOCKD_V4=y
> CONFIG_EXPORTFS=m
> CONFIG_NFS_COMMON=y
> CONFIG_SUNRPC=m
> CONFIG_SUNRPC_GSS=m
> CONFIG_RPCSEC_GSS_KRB5=m
> # CONFIG_RPCSEC_GSS_SPKM3 is not set
> CONFIG_SMB_FS=m
> CONFIG_SMB_NLS_DEFAULT=y
> CONFIG_SMB_NLS_REMOTE="iso8859-1"
> CONFIG_CIFS=m
> # CONFIG_CIFS_STATS is not set
> # CONFIG_CIFS_WEAK_PW_HASH is not set
> # CONFIG_CIFS_XATTR is not set
> # CONFIG_CIFS_DEBUG2 is not set
> # CONFIG_CIFS_EXPERIMENTAL is not set
> CONFIG_NCP_FS=m
> # CONFIG_NCPFS_PACKET_SIGNING is not set
> # CONFIG_NCPFS_IOCTL_LOCKING is not set
> # CONFIG_NCPFS_STRONG is not set
> CONFIG_NCPFS_NFS_NS=y
> CONFIG_NCPFS_OS2_NS=y
> # CONFIG_NCPFS_SMALLDOS is not set
> CONFIG_NCPFS_NLS=y
> CONFIG_NCPFS_EXTRAS=y
> CONFIG_CODA_FS=m
> # CONFIG_CODA_FS_OLD_API is not set
> CONFIG_AFS_FS=m
> CONFIG_RXRPC=m
> # CONFIG_9P_FS is not set
>
> #
> # Partition Types
> #
> CONFIG_PARTITION_ADVANCED=y
> # CONFIG_ACORN_PARTITION is not set
> # CONFIG_OSF_PARTITION is not set
> CONFIG_AMIGA_PARTITION=y
> # CONFIG_ATARI_PARTITION is not set
> CONFIG_MAC_PARTITION=y
> CONFIG_MSDOS_PARTITION=y
> # CONFIG_BSD_DISKLABEL is not set
> # CONFIG_MINIX_SUBPARTITION is not set
> # CONFIG_SOLARIS_X86_PARTITION is not set
> # CONFIG_UNIXWARE_DISKLABEL is not set
> # CONFIG_LDM_PARTITION is not set
> # CONFIG_SGI_PARTITION is not set
> # CONFIG_ULTRIX_PARTITION is not set
> # CONFIG_SUN_PARTITION is not set
> # CONFIG_KARMA_PARTITION is not set
> # CONFIG_EFI_PARTITION is not set
>
> #
> # Native Language Support
> #
> CONFIG_NLS=m
> 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_ASCII=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
>
> #
> # Distributed Lock Manager
> #
> # CONFIG_DLM is not set
>
> #
> # Library routines
> #
> CONFIG_BITREVERSE=y
> CONFIG_CRC_CCITT=m
> CONFIG_CRC16=m
> CONFIG_CRC32=y
> CONFIG_LIBCRC32C=m
> CONFIG_ZLIB_INFLATE=y
> CONFIG_ZLIB_DEFLATE=m
> CONFIG_PLIST=y
> CONFIG_IOMAP_COPY=y
>
> #
> # Instrumentation Support
> #
> CONFIG_PROFILING=y
> CONFIG_OPROFILE=m
>
> #
> # Kernel hacking
> #
> # CONFIG_PRINTK_TIME is not set
> CONFIG_ENABLE_MUST_CHECK=y
> CONFIG_MAGIC_SYSRQ=y
> # CONFIG_UNUSED_SYMBOLS is not set
> # CONFIG_DEBUG_FS is not set
> # CONFIG_HEADERS_CHECK is not set
> CONFIG_DEBUG_KERNEL=y
> CONFIG_LOG_BUF_SHIFT=14
> CONFIG_DETECT_SOFTLOCKUP=y
> # CONFIG_SCHEDSTATS is not set
> # CONFIG_DEBUG_SLAB is not set
> # CONFIG_DEBUG_RT_MUTEXES is not set
> # CONFIG_RT_MUTEX_TESTER is not set
> # CONFIG_DEBUG_SPINLOCK is not set
> # CONFIG_DEBUG_MUTEXES is not set
> # CONFIG_DEBUG_RWSEMS is not set
> # CONFIG_DEBUG_SPINLOCK_SLEEP is not set
> # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
> # CONFIG_DEBUG_KOBJECT is not set
> # CONFIG_DEBUG_HIGHMEM is not set
> CONFIG_DEBUG_BUGVERBOSE=y
> # CONFIG_DEBUG_INFO is not set
> # CONFIG_DEBUG_VM is not set
> # CONFIG_DEBUG_LIST is not set
> CONFIG_FORCED_INLINING=y
> # CONFIG_RCU_TORTURE_TEST is not set
> # CONFIG_DEBUGGER is not set
> # CONFIG_BDI_SWITCH is not set
> CONFIG_BOOTX_TEXT=y
> # CONFIG_SERIAL_TEXT_DEBUG is not set
> # CONFIG_PPC_EARLY_DEBUG is not set
>
> #
> # Security options
> #
> # CONFIG_KEYS is not set
> # CONFIG_SECURITY is not set
>
> #
> # Cryptographic options
> #
> CONFIG_CRYPTO=y
> CONFIG_CRYPTO_ALGAPI=y
> CONFIG_CRYPTO_BLKCIPHER=m
> CONFIG_CRYPTO_HASH=y
> CONFIG_CRYPTO_MANAGER=y
> CONFIG_CRYPTO_HMAC=y
> # CONFIG_CRYPTO_XCBC is not set
> CONFIG_CRYPTO_NULL=m
> CONFIG_CRYPTO_MD4=m
> CONFIG_CRYPTO_MD5=y
> CONFIG_CRYPTO_SHA1=m
> CONFIG_CRYPTO_SHA256=m
> CONFIG_CRYPTO_SHA512=m
> # CONFIG_CRYPTO_WP512 is not set
> # CONFIG_CRYPTO_TGR192 is not set
> # CONFIG_CRYPTO_GF128MUL is not set
> CONFIG_CRYPTO_ECB=m
> CONFIG_CRYPTO_CBC=m
> # CONFIG_CRYPTO_LRW is not set
> CONFIG_CRYPTO_DES=m
> CONFIG_CRYPTO_BLOWFISH=m
> CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRYPTO_TWOFISH_COMMON=m
> CONFIG_CRYPTO_SERPENT=m
> CONFIG_CRYPTO_AES=m
> CONFIG_CRYPTO_CAST5=m
> CONFIG_CRYPTO_CAST6=m
> CONFIG_CRYPTO_TEA=m
> CONFIG_CRYPTO_ARC4=m
> CONFIG_CRYPTO_KHAZAD=m
> # CONFIG_CRYPTO_ANUBIS is not set
> CONFIG_CRYPTO_DEFLATE=m
> CONFIG_CRYPTO_MICHAEL_MIC=m
> CONFIG_CRYPTO_CRC32C=m
> CONFIG_CRYPTO_TEST=m
>
> #
> # Hardware crypto devices
> #
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> [email protected]
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hello,
> Don't build ohci as module for now.
> A fix for that is already in gregkh usb tree for 2.6.21
Ok. Thanks.
--
Regards,
Mariusz Kozlowski
On 07 Jan 2007 22:04:02 +0100, Peter Osterlund <[email protected]> wrote:
> Peter Osterlund <[email protected]> writes:
>
> > Linus Torvalds <[email protected]> writes:
> >
> > > Patrick McHardy (2):
> > > [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore
> >
> > I get kernel panics when doing large ethernet transfers. A loop doing
>
> I also see an annoying side effect of this bug. When the panic
> happens, the caps lock LED starts to blink, and the kernel prints this
> on the console once every second (or more often, don't know exactly):
>
> printk(KERN_WARNING "atkbd.c: Spurious %s on %s. "
> "Some program might be trying access hardware directly.\n",
> data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys);
>
> This makes the actual crash information disappear before you have a
> chance to read it.
>
I believe I have a fix for this in my tree. I even asked Linus to pull
from it but it is a good thing he did not as I need to revert one
patch to lifebook driver...
Linus, did you not pull because you considered changes to ads7848 and
a new driver gpio-keys unappropriate for this stage or you just missed
my request?
--
Dmitry
Hi Sylvain,
On Mon, 08 Jan 2007 15:58:31 +0100, Sylvain Munaut wrote:
> Mariusz Kozlowski wrote:
> > Hello,
> >
> > Doesn't build on iMac G3 machine. Relevant info attached.
> >
> > In file included from drivers/usb/host/ohci-hcd.c:893:
> > drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest'
> > drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here
> > drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module'
> > drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here
> > drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest'
> > drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here
> > drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module'
> > drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here
> > make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1
> > make[2]: *** [drivers/usb/host] Blad 2
> > make[1]: *** [drivers/usb] Blad 2
> > make: *** [drivers] Blad 2
>
> Don't build ohci as module for now.
> A fix for that is already in gregkh usb tree for 2.6.21
We shouldn't have to wait for 2.6.21 to fix a known compilation
breakage. Greg, can you please push the fix to Linus quickly?
Thanks,
--
Jean Delvare
On Mon, 08 Jan 2007 01:38:57 +0100, Willy Tarreau said:
> it's clearly the proof of a flaw in the initial design. And I'm not even
> discussing the stupidity which requires that you read a whole text to get
> its number of characters !
It's no more stupid than the *current* situation with Linux kernel code, where
the stupidity actually requires that even if you know that there are only 60
characters on a given line, you actually have to look at each one in order to
figure out if the line goes past column 80....
On Jan 8 2007 02:22, Jan Engelhardt wrote:
>On Jan 7 2007 22:30, Alan wrote:
>>
>>> >The kernel maintainers/help/config pretty consistently use UTF8
>>>
>>> I've seen a lot of places that don't do so. Want a patch?
>>
>>I think that would be a good idea - and add it to the coding/docs specs
>>that documentation is UTF-8. Code should IMHO say 7bit though.
Most memorable issues:
* "don<decimal-180>t" (standalone accent aigu) rather than "don't" (apostrophe)
* "<decimal-160>", non breaking spaces
* cp437 encoding in some files (heh, heh, DOS!)
* iso8859-1/utf-8 mixed in some files
My compose key is hot now...
None of you people screw that patch with your buggy MUAs! I'll pack
it up into a .bz2 to get it marked as application/octet-stream to
not even give your MUA the chance to. ;-) [and because it's 221 K
uncompressed and I am not sure if splitting it up makes much sense for
such 'trivial' changes, or not?]
Signed-off-by: Jan Engelhardt <[email protected]>
-`J'
--
David Miller <[email protected]> writes:
> From: Linus Torvalds <[email protected]>
> Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST)
>
> > David, there really *is* something screwy in netfilter.
>
> Sure, but from what I can see this bug appears unrelated to the one in
> kernel bugzilla #7781 that we've been discussing the past few days.
>
> First of all, the nf conntrack paths won't be used by normal
> users until 2.6.20-rc1 or so. The bz #7781 report is against
> 2.6.19 and all those backtraces have IP conntrack in them, not
> nf conntrack.
>
> So what are we compiling with here btw, gcc-4.1?
>
> I want to rule the compiler out in this and the bz #7781 case
> so that we can look at the code seriously.
The first crash was with gcc 4.1.1, but now I recompiled the kernel
with "gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5)" and I
can still reproduce the same crash. The backtrace looks the same,
although the addresses are obviously different. Some hand copied data
from the oops:
BUG: unable to handle kernel paging request at virtual address 1d075089
eax: cc671e5c ebx: d58569a0 ecx: d58569a0 edx: 00000014
esi: 1d075021 edi: 00000001 ebp: cc671df0 esp: cc671ddc
ds: 007b es: 007b ss: 0068
EIP: ipv4_conntrack_help+0x8e/0x93
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
On Sun 2007-01-07 22:30:55, Alan wrote:
> > >The kernel maintainers/help/config pretty consistently use UTF8
> >
> > I've seen a lot of places that don't do so. Want a patch?
>
> I think that would be a good idea - and add it to the coding/docs specs
> that documentation is UTF-8. Code should IMHO say 7bit though.
Yes, yes, please.
I have been flamed when someone tried to do 8bit patch, and I was
trying to NAK it...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Peter Osterlund <[email protected]>
Date: 08 Jan 2007 21:49:23 +0100
> The first crash was with gcc 4.1.1, but now I recompiled the kernel
> with "gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5)" and I
> can still reproduce the same crash. The backtrace looks the same,
Thanks for performing this test.
On Mon, Jan 08, 2007 at 09:17:06PM +0100, Jan Engelhardt wrote:
>
> On Jan 8 2007 02:22, Jan Engelhardt wrote:
> >On Jan 7 2007 22:30, Alan wrote:
> >>
> >>> >The kernel maintainers/help/config pretty consistently use UTF8
> >>>
> >>> I've seen a lot of places that don't do so. Want a patch?
> >>
> >>I think that would be a good idea - and add it to the coding/docs specs
> >>that documentation is UTF-8. Code should IMHO say 7bit though.
>
> Most memorable issues:
>
> * "don<decimal-180>t" (standalone accent aigu) rather than "don't" (apostrophe)
> * "<decimal-160>", non breaking spaces
> * cp437 encoding in some files (heh, heh, DOS!)
> * iso8859-1/utf-8 mixed in some files
Looks nicely done, but I query the postal address changes in
Documentation/cdrom/sbpcd - that seems to be a change of address
(without anything to explain it). Everything else seems to be just
character-set conversion or the occasional translation of comments
into English. (And no, I didn't attempt to review the character-set
changes, even it there is an occasional error it will be better than
where we are now, and easy to patch.)
>
> My compose key is hot now...
I prefer the AltGr dead keys in X (they seem to work more reliably
for me), but I guess I'm straying OT.
>
> None of you people screw that patch with your buggy MUAs! I'll pack
> it up into a .bz2 to get it marked as application/octet-stream to
> not even give your MUA the chance to. ;-) [and because it's 221 K
> uncompressed and I am not sure if splitting it up makes much sense for
> such 'trivial' changes, or not?]
>
> Signed-off-by: Jan Engelhardt <[email protected]>
>
>
> -`J'
> --
Thanks for doing this, I hope it wasn't in vain.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
On 1/8/07, Pavel Machek <[email protected]> wrote:
> On Sun 2007-01-07 22:30:55, Alan wrote:
> > I think that would be a good idea - and add it to the coding/docs specs
> > that documentation is UTF-8. Code should IMHO say 7bit though.
>
> Yes, yes, please.
>
> I have been flamed when someone tried to do 8bit patch, and I was
> trying to NAK it...
Could this get put in Documentation/CodingStyle? And an item added to
the kernel janitors' list to fix up 8bit files? Last I looked trying
to decided if there was a standard here I found a mish-mash of
encodings based output of file vs Linus' git tree.
[NETFILTER]: nf_conntrack_netbios_ns: fix uninitialized member in expectation
->helper is uninitialized in the expectation registered by the netbios_ns
helper and it later copied to the expected connection, which causes invalid
memory dereferences when trying to call the helper.
Signed-off-by: Patrick McHardy <[email protected]>
---
commit fe6df90eb909a84593b6902e6e4f802687bc4564
tree 113ffbc5cd73dd3a5fe66bc24ba4747b2b5a4c6c
parent fa0035e191e85a2ab31861df9e0a0273e60dc745
author Patrick McHardy <[email protected]> Mon, 08 Jan 2007 23:30:35 +0100
committer Patrick McHardy <[email protected]> Mon, 08 Jan 2007 23:30:35 +0100
net/netfilter/nf_conntrack_netbios_ns.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netbios_ns.c b/net/netfilter/nf_conntrack_netbios_ns.c
index a5b234e..2a48efd 100644
--- a/net/netfilter/nf_conntrack_netbios_ns.c
+++ b/net/netfilter/nf_conntrack_netbios_ns.c
@@ -89,6 +89,7 @@ static int help(struct sk_buff **pskb, u
exp->expectfn = NULL;
exp->flags = NF_CT_EXPECT_PERMANENT;
+ exp->helper = NULL;
nf_conntrack_expect_related(exp);
nf_conntrack_expect_put(exp);
Patrick McHardy <[email protected]> writes:
> Linus Torvalds wrote:
> > On Sun, 7 Jan 2007, Peter Osterlund wrote:
> >
> >>I get kernel panics when doing large ethernet transfers. A loop doing
> >> EFALLGS: 00010206 (2.6.20-rc4 #13)
> >> EIP is at ipv4_conntrack_help+0x6b/0x83
> >> eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 00000014
> >> esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4
> >
> > which is ipv4_conntrack_help():
> >
> > return help->helper->help(pskb,
> > (*pskb)->nh.raw - (*pskb)->data
> > + (*pskb)->nh.iph->ihl*4,
> > ct, ctinfo);
> >
> > and that call instruction is the one that oopses because "help->helper" is
> > corrupt (it's 0x9f5cea37 - not a valid kernel pointer).
>
> I guess its because of an uninitialized helper field in struct
> nf_conntrack_expect, which is then copied from the expectation to
> the conntrack entry.
>
> Peter, do you have locally generated netbios ns queries on the machine
> running nf_conntrack?
I have samba running on both machines. I guess that generates some
netbios traffic even though it isn't currently in active use.
> If so, please try this patch.
Thanks, the patch appears to help. The kernel has now survived much
longer with this patch than it used to do without it.
I will recompile with gcc 4.1.1 too just to make sure, but if you
don't hear anything more from me, consider the case closed. :)
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
On Mon, 9 Jan 2007, Peter Osterlund wrote:
>
> Thanks, the patch appears to help. The kernel has now survived much
> longer with this patch than it used to do without it.
>
> I will recompile with gcc 4.1.1 too just to make sure, but if you
> don't hear anything more from me, consider the case closed. :)
David - I assume I'll get this patch through you, and I can just forget
about this issue and go about my normal mindless ways?
Linus
On Jan 8 2007 22:00, Ken Moffat wrote:
> Looks nicely done, but I query the postal address changes in
>Documentation/cdrom/sbpcd - that seems to be a change of address
>(without anything to explain it).
Eberhard [cc], please attach an Acked-by: YourName <emailaddress>
keep Ccs, thanks ;-)
[thread/patch: http://lkml.org/lkml/2007/1/8/222 ]
-`J'
--
Hi,
On Tue, 9 Jan 2007, Jan Engelhardt wrote:
> On Jan 8 2007 22:00, Ken Moffat wrote:
> > Looks nicely done, but I query the postal address changes in
> >Documentation/cdrom/sbpcd - that seems to be a change of address
> >(without anything to explain it).
>
> Eberhard [cc], please attach an Acked-by: YourName <emailaddress>
> keep Ccs, thanks ;-)
>
> [thread/patch: http://lkml.org/lkml/2007/1/8/222 ]
Acked-by: Eberhard Moenkeberg <[email protected]>
Jan had contacted me before, and I had sent him my new address data.
This very young guy is doing a really good job. ;-))
Cheers -e
--
Eberhard Moenkeberg ([email protected], [email protected])
On Jan 8 2007 14:17, Tim Pepper wrote:
> On 1/8/07, Pavel Machek <[email protected]> wrote:
>> On Sun 2007-01-07 22:30:55, Alan wrote:
>> > I think that would be a good idea - and add it to the coding/docs
>> > specs
>> > that documentation is UTF-8. Code should IMHO say 7bit though.
>>
>> Yes, yes, please.
>>
>> I have been flamed when someone tried to do 8bit patch, and I was
>> trying to NAK it...
>
> Could this get put in Documentation/CodingStyle?
Someone do that.
> And an item added to
> the kernel janitors' list to fix up 8bit files? Last I looked trying
That's already been just done by me. http://lkml.org/lkml/2007/1/8/222
> to decided if there was a standard here I found a mish-mash of
> encodings based output of file vs Linus' git tree.
-`J'
--
On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote:
> Don't build ohci as module for now.
> A fix for that is already in gregkh usb tree for 2.6.21
Do you mean that as-is, powerpc defconfigs cannot build USB as a module
in 2.6.20 ? That is unacceptable as a regression. We need a fix in
2.6.20.
Greg, what is the status there ?
Ben.
On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote:
> > Don't build ohci as module for now.
> > A fix for that is already in gregkh usb tree for 2.6.21
>
> Do you mean that as-is, powerpc defconfigs cannot build USB as a module
> in 2.6.20 ? That is unacceptable as a regression. We need a fix in
> 2.6.20.
>
> Greg, what is the status there ?
Hm, for some reason I thought your patches were not needed until 2.6.21.
Should I forward them on to Linus now for 2.6.20? Are they required for
ppc to build?
thanks,
greg k-h
On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote:
> On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote:
> > > Don't build ohci as module for now.
> > > A fix for that is already in gregkh usb tree for 2.6.21
> >
> > Do you mean that as-is, powerpc defconfigs cannot build USB as a module
> > in 2.6.20 ? That is unacceptable as a regression. We need a fix in
> > 2.6.20.
> >
> > Greg, what is the status there ?
>
> Hm, for some reason I thought your patches were not needed until 2.6.21.
My endian patches aren't, but Sylvain' are based on mines so ... Maybe
if Sylvain rebases his ?
> Should I forward them on to Linus now for 2.6.20? Are they required for
> ppc to build?
Sylvain fixes are. My endian patches are for ps3 and toshiba celleb,
none of which is fully merged in 2.6.20 so they are fine to wait. It's
mostly a matter of being a PITA to rebase Sylvain stuff to apply before
mine and rebase mine on top of his I suppose :-)
Ben.
On Mon, Jan 08, 2007 at 03:12:08PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 9 Jan 2007, Peter Osterlund wrote:
> >
> > Thanks, the patch appears to help. The kernel has now survived much
> > longer with this patch than it used to do without it.
> >
> > I will recompile with gcc 4.1.1 too just to make sure, but if you
> > don't hear anything more from me, consider the case closed. :)
>
> David - I assume I'll get this patch through you, and I can just forget
> about this issue and go about my normal mindless ways?
I'll keep reminding him until it's in your tree. ;-)
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs)
References : http://lkml.org/lkml/2007/1/7/117
Submitter : Malte Schr?der <[email protected]>
Status : unknown
Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
Status : unknown
Subject : BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl <[email protected]>
Damien Wyart <[email protected]>
Aaron Sethman <[email protected]>
Status : unknown
Subject : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[email protected]>
Status : unknown
Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <[email protected]>
Handled-By : Jiri Kosina <[email protected]>
Status : problem is being debugged
Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Handled-By : Alexey Starikovskiy <[email protected]>
Status : problem is being debugged
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
References : http://lkml.org/lkml/2007/1/5/308
Submitter : Sami Farin <[email protected]>
Handled-By : David Chinner <[email protected]>
Patch : http://lkml.org/lkml/2007/1/7/201
Status : patch available
Subject : bluetooth oopses because of multiple kobject_add()
References : http://lkml.org/lkml/2007/1/2/101
Submitter : Pavel Machek <[email protected]>
Handled-By : Marcel Holtmann <[email protected]>
Patch : http://lkml.org/lkml/2007/1/2/147
Status : patch available
Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>
Caused-By : YOSHIFUJI Hideaki <[email protected]>
commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : Craig Schlenter <[email protected]>
YOSHIFUJI Hideaki <[email protected]>
Patch : http://lkml.org/lkml/2007/1/9/5
Status : patch available
Subject : nf_conntrack_netbios_ns.c causes Oops
References : http://lkml.org/lkml/2007/1/7/188
Submitter : Peter Osterlund <[email protected]>
Caused-By : Patrick McHardy <[email protected]>
commit 92703eee4ccde3c55ee067a89c373e8a51a8adf9
Handled-By : Patrick McHardy <[email protected]>
Patch : http://lkml.org/lkml/2007/1/8/290
Status : patch available
Subject : forcedeth.c 0.59: problem with sideband managment
References : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Submitter : Michael Reske <[email protected]>
Handled-By : Ayaz Abdulla <[email protected]>
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Status : patch available
Subject : nVidia CK804 chipset: not detecting HT MSI capabilities
References : http://lkml.org/lkml/2007/1/5/215
Submitter : Brice Goglin <[email protected]>
Robert Hancock <[email protected]>
Handled-By : Brice Goglin <[email protected]>
Patch : http://lkml.org/lkml/2007/1/5/215
Status : patch available
On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote:
> Sylvain fixes are. My endian patches are for ps3 and toshiba celleb,
> none of which is fully merged in 2.6.20 so they are fine to wait. It's
> mostly a matter of being a PITA to rebase Sylvain stuff to apply before
> mine and rebase mine on top of his I suppose :-)
Er, doesn't Efika need the same endian patches?
--
dwmw2
David Woodhouse wrote:
> On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote:
>
>> Sylvain fixes are. My endian patches are for ps3 and toshiba celleb,
>> none of which is fully merged in 2.6.20 so they are fine to wait. It's
>> mostly a matter of being a PITA to rebase Sylvain stuff to apply before
>> mine and rebase mine on top of his I suppose :-)
>>
>
> Er, doesn't Efika need the same endian patches?
>
No, Ben's patches are for controller that have registers in big-endian and
memory structures in little-endian.
52xx is full big-endian and that's already supported since quite some time
now.
Sylvain
Benjamin Herrenschmidt wrote:
> On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote:
>> On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote:
>>> On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote:
>>>> Don't build ohci as module for now.
>>>> A fix for that is already in gregkh usb tree for 2.6.21
>>> Do you mean that as-is, powerpc defconfigs cannot build USB as a module
>>> in 2.6.20 ? That is unacceptable as a regression. We need a fix in
>>> 2.6.20.
>>>
>>> Greg, what is the status there ?
>> Hm, for some reason I thought your patches were not needed until 2.6.21.
>
> My endian patches aren't, but Sylvain' are based on mines so ... Maybe
> if Sylvain rebases his ?
FWIW, the patch does apply fine (at least the first one, which is needed) :
tnt@hitomi linux-2.6-mpc52xx-new $ patch -p1 --dry-run <
ohci-rework-bus-glue-integration-to-allow-several-at-once.patch
patching file drivers/usb/host/ohci-at91.c
patching file drivers/usb/host/ohci-au1xxx.c
patching file drivers/usb/host/ohci-ep93xx.c
patching file drivers/usb/host/ohci-hcd.c
patching file drivers/usb/host/ohci-lh7a404.c
patching file drivers/usb/host/ohci-omap.c
patching file drivers/usb/host/ohci-pci.c
Hunk #1 succeeded at 238 (offset -73 lines).
patching file drivers/usb/host/ohci-pnx4008.c
patching file drivers/usb/host/ohci-pnx8550.c
patching file drivers/usb/host/ohci-ppc-soc.c
patching file drivers/usb/host/ohci-pxa27x.c
patching file drivers/usb/host/ohci-s3c2410.c
patching file drivers/usb/host/ohci-sa1111.c
The offset in ohci-pci.c is harmless.
But maybe the question we should ask is why would it build
drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem
(ohci multiple glue in module) is there since a long time, just never
spotted before.
arch/powerpc/KConfig :
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MULTIPLATFORM && PPC32
select PPC_RTAS
select RTAS_PROC
select PPC_MPC52xx
select PPC_NATIVE
default y
^^^
This was added by commit
c37858d333a50815c74349396e31a535f4128e0b on Nov5.
and a patch to correct that has been submitted recently :
http://patchwork.ozlabs.org/linuxppc/patch?id=8848
Sylvain
On Tue, Jan 09, 2007 at 01:05:23PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote:
> > On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote:
> > > On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote:
> > > > Don't build ohci as module for now.
> > > > A fix for that is already in gregkh usb tree for 2.6.21
> > >
> > > Do you mean that as-is, powerpc defconfigs cannot build USB as a module
> > > in 2.6.20 ? That is unacceptable as a regression. We need a fix in
> > > 2.6.20.
> > >
> > > Greg, what is the status there ?
> >
> > Hm, for some reason I thought your patches were not needed until 2.6.21.
>
> My endian patches aren't, but Sylvain' are based on mines so ... Maybe
> if Sylvain rebases his ?
Yes, if something needs to get in now, please let me know, I don't have
any USB patches pending in the "2.6.20" queue at this moment.
thanks,
greg k-h
On Tue, 2007-01-09 at 08:14 +0100, Sylvain Munaut wrote:
> But maybe the question we should ask is why would it build
> drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem
> (ohci multiple glue in module) is there since a long time, just never
> spotted before.
Are you suggesting that distributions must choose to support OHCI from
_either_ PCI or OF but not both?
--
dwmw2
From: Linus Torvalds <[email protected]>
Date: Mon, 8 Jan 2007 15:12:08 -0800 (PST)
>
>
> On Mon, 9 Jan 2007, Peter Osterlund wrote:
> >
> > Thanks, the patch appears to help. The kernel has now survived much
> > longer with this patch than it used to do without it.
> >
> > I will recompile with gcc 4.1.1 too just to make sure, but if you
> > don't hear anything more from me, consider the case closed. :)
>
> David - I assume I'll get this patch through you, and I can just forget
> about this issue and go about my normal mindless ways?
Yep, I'll push it to you very soon.
Thanks Patrick for figuring this bug out, nice work.
On Tue, 2007-01-09 at 15:04 +0800, David Woodhouse wrote:
> On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote:
> > Sylvain fixes are. My endian patches are for ps3 and toshiba celleb,
> > none of which is fully merged in 2.6.20 so they are fine to wait. It's
> > mostly a matter of being a PITA to rebase Sylvain stuff to apply before
> > mine and rebase mine on top of his I suppose :-)
>
> Er, doesn't Efika need the same endian patches?
No, Efika is fully big endian OHCI which is already supported. The
patches are for "split" endian OHCI and EHCI (the toshiba chip).
Ben.
> But maybe the question we should ask is why would it build
> drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem
> (ohci multiple glue in module) is there since a long time, just never
> spotted before.
>
> arch/powerpc/KConfig :
>
> config PPC_EFIKA
> bool "bPlan Efika 5k2. MPC5200B based computer"
> depends on PPC_MULTIPLATFORM && PPC32
> select PPC_RTAS
> select RTAS_PROC
> select PPC_MPC52xx
> select PPC_NATIVE
> default y
> ^^^
>
> This was added by commit
> c37858d333a50815c74349396e31a535f4128e0b on Nov5.
>
> and a patch to correct that has been submitted recently :
> http://patchwork.ozlabs.org/linuxppc/patch?id=8848
Yes, I think both issue should be fixed for 2.6.20 : the compile problem
with the OF glue -and- removing the default y.
The later should get picked up by Paulus, I'll make sure it is
tomorrow.
The former, well, since it seems it doesn't mixup too much with my
patches, greg, you can probably send it to linus now if you think it
looks good (I haven't looked too closely at Sylvain patches myself).
Ben.
On Tue, 2007-01-09 at 15:28 +0800, David Woodhouse wrote:
> On Tue, 2007-01-09 at 08:14 +0100, Sylvain Munaut wrote:
> > But maybe the question we should ask is why would it build
> > drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem
> > (ohci multiple glue in module) is there since a long time, just never
> > spotted before.
>
> Are you suggesting that distributions must choose to support OHCI from
> _either_ PCI or OF but not both?
I think not. What he meant I suppose is that in -addition- to the
problem that needs to be fixed, there is another one where efika support
defaults to y in Kconfig, thus gets enabled for pmac32_defconfig etc...
Ben.
On Tue, 9 Jan 2007, Adrian Bunk wrote:
>
> Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs)
> References : http://lkml.org/lkml/2007/1/7/117
> Submitter : Malte Schr?der <[email protected]>
> Status : unknown
Adrian, this is also available as
http://lkml.org/lkml/2007/1/5/308
But, at worst, I don't think this is a show-stopper (oh, well: I actually
liked it better when "WARN_ON()" said _warning_, not BUG, since it
separates out the two cases visually much better, but others disagreed.
Crud).
It does show that something is wrong in reiserfs-land, although probably
not any worse than it ever was before, so in that sense this is not a
"regression", it's actually an _improvement_. Now it warns about reiserfs
trying to clear the dirty bit on a page cache that is still mapped (and
that _may_ be dirty in the page tables, although it almost certainly isn't
in practice).
That warning just didn't exist before.
Now, that said, the call stack is interestign:
BUG: at mm/truncate.c:60 cancel_dirty_page()
[<c0137371>] cancel_dirty_page+0x45/0x7b
[<df944b18>] reiserfs_cut_from_item+0x7cc/0x7fd [reiserfs]
[<c01e5eba>] __kfree_skb+0x9b/0xf7
[<df9316a0>] make_cpu_key+0x3f/0x46 [reiserfs]
[<df944efa>] reiserfs_do_truncate+0x3b1/0x515 [reiserfs]
[<df949901>] journal_begin+0x3f/0xd0 [reiserfs]
[<df9322fc>] reiserfs_truncate_file+0x1c1/0x2ad [reiserfs]
[<df938172>] reiserfs_file_release+0x35f/0x379 [reiserfs]
[<c013be42>] free_pgtables+0x70/0x7c
[<c01491f1>] __fput+0xa5/0x14d
[<c0146e7a>] filp_close+0x51/0x58
[<c0147de8>] sys_close+0x55/0x8a
[<c0102ab2>] sysenter_past_esp+0x5f/0x85
in that a final "sys_close()" that releases the file and causes it to be
truncated (which is apparently what is going on) should NOT have any
mappings of that file active any more!
If there are mappings active, the reiserfs_truncate_file() thing should
have been delayed until the mappins are gone!
So something interesting is definitely going on, but I don't know exactly
what it is. Why does reiserfs do the truncate as part of a close, if the
same inode is actually mapped somewhere else? And if it's a race with two
different CPU's (one doing a "munmap()" and the other doing a "close()",
then the unmap should _still_ have actually unmapped the pages before it
actually did _its_ "release()" call.
In general, a filesystem should never do a truncate at "release()" time
_anyway_. It should do it at "drop_inode" time.
So I think this does show some confusion in reiserfs, but it's not
anything new. The only new thing is that the _message_ happens.
So I don't personally consider this a regression. Just a sign of old and
preexisting confusion that is now uncovered by new code (and it will print
out the scary message at most four times, and then stop complaining about
it. So apart from the scary message, nothing new and bad has really
happened).
Linus
On Tuesday 09 January 2007 18:58, Linus Torvalds wrote:
> On Tue, 9 Jan 2007, Adrian Bunk wrote:
> > Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs)
> > References : http://lkml.org/lkml/2007/1/7/117
> > Submitter : Malte Schr?der <[email protected]>
> > Status : unknown
>
> Adrian, this is also available as
>
> http://lkml.org/lkml/2007/1/5/308
>
> But, at worst, I don't think this is a show-stopper (oh, well: I actually
> liked it better when "WARN_ON()" said _warning_, not BUG, since it
> separates out the two cases visually much better, but others disagreed.
> Crud).
--8<--
> So something interesting is definitely going on, but I don't know exactly
> what it is. Why does reiserfs do the truncate as part of a close, if the
> same inode is actually mapped somewhere else? And if it's a race with two
> different CPU's (one doing a "munmap()" and the other doing a "close()",
> then the unmap should _still_ have actually unmapped the pages before it
> actually did _its_ "release()" call.
This was on a single core. But with CONFIG_PREEMPT_VOLUNTARY=y.
It didn't happen again since then.
>
> In general, a filesystem should never do a truncate at "release()" time
> _anyway_. It should do it at "drop_inode" time.
>
> So I think this does show some confusion in reiserfs, but it's not
> anything new. The only new thing is that the _message_ happens.
>
> So I don't personally consider this a regression. Just a sign of old and
> preexisting confusion that is now uncovered by new code (and it will print
> out the scary message at most four times, and then stop complaining about
> it. So apart from the scary message, nothing new and bad has really
> happened).
I also didn't reboot the machine afterwards and did not notice any problems
beside that one message.
--
---------------------------------------
Malte Schr?der
[email protected]
ICQ# 68121508
---------------------------------------
On Tue, 9 Jan 2007, Malte Schr?der wrote:
>
> > So something interesting is definitely going on, but I don't know exactly
> > what it is. Why does reiserfs do the truncate as part of a close, if the
> > same inode is actually mapped somewhere else? And if it's a race with two
> > different CPU's (one doing a "munmap()" and the other doing a "close()",
> > then the unmap should _still_ have actually unmapped the pages before it
> > actually did _its_ "release()" call.
>
> This was on a single core. But with CONFIG_PREEMPT_VOLUNTARY=y.
> It didn't happen again since then.
Yeah, PREEMPT would be able to show most races like this too. In fact,
some races show up much better with preemption than they do with real SMP.
But I haven't looked at what exactly reiserfs does. I did check that the
VM layer definitely does the remove_vma() stuff (that actually closes the
files) _after_ it has unmapped everything. It would have surprised me if
we had had that kind of bug, but still..
Linus
On Tue, Jan 09, 2007 at 09:58:19AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 9 Jan 2007, Adrian Bunk wrote:
> >
> > Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs)
> > References : http://lkml.org/lkml/2007/1/7/117
> > Submitter : Malte Schr?der <[email protected]>
> > Status : unknown
>
> Adrian, this is also available as
>
> http://lkml.org/lkml/2007/1/5/308
The latter was in my list as:
Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
References : http://lkml.org/lkml/2007/1/5/308
Submitter : Sami Farin <[email protected]>
Handled-By : David Chinner <[email protected]>
Patch : http://lkml.org/lkml/2007/1/7/201
Status : patch available
>...
> So I think this does show some confusion in reiserfs, but it's not
> anything new. The only new thing is that the _message_ happens.
>
> So I don't personally consider this a regression. Just a sign of old and
> preexisting confusion that is now uncovered by new code (and it will print
> out the scary message at most four times, and then stop complaining about
> it. So apart from the scary message, nothing new and bad has really
> happened).
At least the printing of scary messages is a regression.
Unless we want to be buried in bug reports after 2.6.20 got released,
the minimum fix is to temporarily remove the WARN_ON().
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hello
On Tuesday 09 January 2007 21:30, Linus Torvalds wrote:
>
> On Tue, 9 Jan 2007, Malte Schr?der wrote:
> >
> > > So something interesting is definitely going on, but I don't know exactly
> > > what it is. Why does reiserfs do the truncate as part of a close, if the
> > > same inode is actually mapped somewhere else?
on file close reiserfs tries to "pack" content of last incomplete page of file into metadata blocks.
It should not if that page is still mapped somewhere.
It does not actually truncate, it calls the same function which does truncate, but file size does not change.
Please consider the below patch.
From: Vladimir Saveliev <[email protected]>
This patch fixes a confusion reiserfs has for a long time.
On release file operation reiserfs used to try to pack file data stored in last incomplete page of some files
into metadata blocks. After packing the page got cleared with clear_page_dirty.
It did not take into account that the page may be mmaped into
other process's address space. Recent replacement for clear_page_dirty cancel_dirty_page found the confusion
with sanity check that page has to be not mapped.
The patch fixes the confusion by making reiserfs to avoid tail packing if an inode was ever mmapped.
reiserfs_mmap and reiserfs_file_release are serialized with mutex in reiserfs specific inode.
reiserfs_mmap locks the mutex and sets a bit in reiserfs specific inode flags.
reiserfs_file_release checks the bit having the mutex locked. If bit is set - tail packing is avoided.
This eliminates a possibility that mmapped page gets cancel_page_dirty-ed.
Signed-off-by: Vladimir Saveliev <[email protected]>
diff -puN fs/reiserfs/file.c~reiserfs-dont-convert-if-tail-page-mapped fs/reiserfs/file.c
--- linux-2.6.20-rc4/fs/reiserfs/file.c~reiserfs-dont-convert-if-tail-page-mapped 2007-01-11 02:09:19.000000000 +0300
+++ linux-2.6.20-rc4-vs/fs/reiserfs/file.c 2007-01-11 02:09:19.000000000 +0300
@@ -48,6 +48,11 @@ static int reiserfs_file_release(struct
}
mutex_lock(&inode->i_mutex);
+
+ mutex_lock(&(REISERFS_I(inode)->i_mmap));
+ if (REISERFS_I(inode)->i_flags & i_ever_mapped)
+ REISERFS_I(inode)->i_flags &= ~i_pack_on_close_mask;
+
reiserfs_write_lock(inode->i_sb);
/* freeing preallocation only involves relogging blocks that
* are already in the current transaction. preallocation gets
@@ -100,11 +105,24 @@ static int reiserfs_file_release(struct
err = reiserfs_truncate_file(inode, 0);
}
out:
+ mutex_unlock(&(REISERFS_I(inode)->i_mmap));
mutex_unlock(&inode->i_mutex);
reiserfs_write_unlock(inode->i_sb);
return err;
}
+static int reiserfs_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct inode *inode;
+
+ inode = file->f_path.dentry->d_inode;
+ mutex_lock(&(REISERFS_I(inode)->i_mmap));
+ REISERFS_I(inode)->i_flags |= i_ever_mapped;
+ mutex_unlock(&(REISERFS_I(inode)->i_mmap));
+
+ return generic_file_mmap(file, vma);
+}
+
static void reiserfs_vfs_truncate_file(struct inode *inode)
{
reiserfs_truncate_file(inode, 1);
@@ -1527,7 +1545,7 @@ const struct file_operations reiserfs_fi
#ifdef CONFIG_COMPAT
.compat_ioctl = reiserfs_compat_ioctl,
#endif
- .mmap = generic_file_mmap,
+ .mmap = reiserfs_file_mmap,
.open = generic_file_open,
.release = reiserfs_file_release,
.fsync = reiserfs_sync_file,
diff -puN fs/reiserfs/inode.c~reiserfs-dont-convert-if-tail-page-mapped fs/reiserfs/inode.c
--- linux-2.6.20-rc4/fs/reiserfs/inode.c~reiserfs-dont-convert-if-tail-page-mapped 2007-01-11 02:09:19.000000000 +0300
+++ linux-2.6.20-rc4-vs/fs/reiserfs/inode.c 2007-01-11 02:14:57.000000000 +0300
@@ -1125,6 +1125,7 @@ static void init_inode(struct inode *ino
REISERFS_I(inode)->i_prealloc_count = 0;
REISERFS_I(inode)->i_trans_id = 0;
REISERFS_I(inode)->i_jl = NULL;
+ mutex_init(&(REISERFS_I(inode)->i_mmap));
reiserfs_init_acl_access(inode);
reiserfs_init_acl_default(inode);
reiserfs_init_xattr_rwsem(inode);
@@ -1832,6 +1833,7 @@ int reiserfs_new_inode(struct reiserfs_t
REISERFS_I(inode)->i_attrs =
REISERFS_I(dir)->i_attrs & REISERFS_INHERIT_MASK;
sd_attrs_to_i_attrs(REISERFS_I(inode)->i_attrs, inode);
+ mutex_init(&(REISERFS_I(inode)->i_mmap));
reiserfs_init_acl_access(inode);
reiserfs_init_acl_default(inode);
reiserfs_init_xattr_rwsem(inode);
diff -puN include/linux/reiserfs_fs_i.h~reiserfs-dont-convert-if-tail-page-mapped include/linux/reiserfs_fs_i.h
--- linux-2.6.20-rc4/include/linux/reiserfs_fs_i.h~reiserfs-dont-convert-if-tail-page-mapped 2007-01-11 02:09:19.000000000 +0300
+++ linux-2.6.20-rc4-vs/include/linux/reiserfs_fs_i.h 2007-01-11 02:09:19.000000000 +0300
@@ -25,6 +25,7 @@ typedef enum {
i_link_saved_truncate_mask = 0x0020,
i_has_xattr_dir = 0x0040,
i_data_log = 0x0080,
+ i_ever_mapped = 0x0100
} reiserfs_inode_flags;
struct reiserfs_inode_info {
@@ -52,6 +53,7 @@ struct reiserfs_inode_info {
** flushed */
unsigned long i_trans_id;
struct reiserfs_journal_list *i_jl;
+ struct mutex i_mmap;
#ifdef CONFIG_REISERFS_FS_POSIX_ACL
struct posix_acl *i_acl_access;
struct posix_acl *i_acl_default;
_
> > > And if it's a race with two
> > > different CPU's (one doing a "munmap()" and the other doing a "close()",
> > > then the unmap should _still_ have actually unmapped the pages before it
> > > actually did _its_ "release()" call.
> >
> > This was on a single core. But with CONFIG_PREEMPT_VOLUNTARY=y.
> > It didn't happen again since then.
>
> Yeah, PREEMPT would be able to show most races like this too. In fact,
> some races show up much better with preemption than they do with real SMP.
>
> But I haven't looked at what exactly reiserfs does. I did check that the
> VM layer definitely does the remove_vma() stuff (that actually closes the
> files) _after_ it has unmapped everything. It would have surprised me if
> we had had that kind of bug, but still..
>
> Linus
Vladimir V. Saveliev wrote:
> Hello
>
> On Tuesday 09 January 2007 21:30, Linus Torvalds wrote:
>
>>On Tue, 9 Jan 2007, Malte Schr?der wrote:
>>
>>>>So something interesting is definitely going on, but I don't know exactly
>>>>what it is. Why does reiserfs do the truncate as part of a close, if the
>>>>same inode is actually mapped somewhere else?
>
>
> on file close reiserfs tries to "pack" content of last incomplete page of file into metadata blocks.
> It should not if that page is still mapped somewhere.
> It does not actually truncate, it calls the same function which does truncate, but file size does not change.
That's racy, unfortunately :P
>
> Please consider the below patch.
That seems like it would work. Probably papers over your truncate-inside-i_size as well.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl <[email protected]>
Damien Wyart <[email protected]>
Aaron Sethman <[email protected]>
Status : unknown
Subject : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[email protected]>
Status : unknown
Subject : 'shutdown -h now' reboots the system (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Handled-By : Alexey Starikovskiy <[email protected]>
Status : problem is being debugged
Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <[email protected]>
Handled-By : Jiri Kosina <[email protected]>
Alan Stern <[email protected]>
Status : problem is being debugged
Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
Handled-By : John McCutchan <[email protected]>
Status : problem is being debugged
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : ibm-acpi: bay support disabled
References : http://lkml.org/lkml/2007/1/9/242
Submitter : Henrique de Moraes Holschuh <[email protected]>
Caused-By : Henrique de Moraes Holschuh <[email protected]>
commit 2df910b4c3edcce9a0c12394db6f5f4a6e69c712
Handled-By : Henrique de Moraes Holschuh <[email protected]>
Patch : http://lkml.org/lkml/2007/1/9/242
Status : patch to revert the commit available
Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs)
References : http://lkml.org/lkml/2007/1/7/117
Submitter : Malte Schr?der <[email protected]>
Handled-By : Vladimir V. Saveliev <[email protected]>
Patch : http://lkml.org/lkml/2007/1/10/202
Status : patch available
Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
References : http://lkml.org/lkml/2007/1/5/308
Submitter : Sami Farin <[email protected]>
Handled-By : David Chinner <[email protected]>
Patch : http://lkml.org/lkml/2007/1/7/201
Status : patch available
Subject : nVidia CK804 chipset: not detecting HT MSI capabilities
References : http://lkml.org/lkml/2007/1/5/215
Submitter : Brice Goglin <[email protected]>
Robert Hancock <[email protected]>
Handled-By : Brice Goglin <[email protected]>
Patch : http://lkml.org/lkml/2007/1/5/215
Status : patch available
Subject : KVM: guest crash
References : http://lkml.org/lkml/2007/1/8/163
Submitter : Roland Dreier <[email protected]>
Handled-By : Avi Kivity <[email protected]>
Patch : http://lkml.org/lkml/2007/1/9/280
Status : patch available
Adrian Bunk wrote:
> Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
> References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
> Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
> Handled-By : John McCutchan <[email protected]>
> Status : problem is being debugged
I'm not sure that this is actually a regression for 2.6.20-rc.
I'll see if I can cook up something that dumps a bit more info
for us. There must be some peculiar usage pattern and/or filesystem
involved.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
On Thu, Jan 11, 2007 at 05:43:55PM +1100, Nick Piggin wrote:
> Adrian Bunk wrote:
>
> >Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
> >References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
> >Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
> >Handled-By : John McCutchan <[email protected]>
> >Status : problem is being debugged
>
> I'm not sure that this is actually a regression for 2.6.20-rc.
The submitter says it doesn't occur in 2.6.19.
> I'll see if I can cook up something that dumps a bit more info
> for us. There must be some peculiar usage pattern and/or filesystem
> involved.
Thanks. :-)
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 11 Jan 2007, Adrian Bunk wrote:
> > >Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
> > >References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
> > >Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
> > >Handled-By : John McCutchan <[email protected]>
> > >Status : problem is being debugged
> > I'm not sure that this is actually a regression for 2.6.20-rc.
> The submitter says it doesn't occur in 2.6.19.
Any chance that the submitter could do git bisect? (added to CC). From the
bugzilla entry it seems to be well reproducible for him.
--
Jiri Kosina
On Thu, Jan 11, 2007 at 11:21:23AM +0100, Jiri Kosina wrote:
> On Thu, 11 Jan 2007, Adrian Bunk wrote:
>
> > > >Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
> > > >References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
> > > >Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
> > > >Handled-By : John McCutchan <[email protected]>
> > > >Status : problem is being debugged
> > > I'm not sure that this is actually a regression for 2.6.20-rc.
> > The submitter says it doesn't occur in 2.6.19.
>
> Any chance that the submitter could do git bisect? (added to CC). From the
> bugzilla entry it seems to be well reproducible for him.
That's a possible but time intensive approach for this kind of bug.
I'd expect bisecting such an "at least 1 times a day" bug to take at
about one month.
And that's not a high number, that's a realistic estimate considering
that you have to test a dozen kernels and verifying that a kernel is
good takes 2-3 days.
> Jiri Kosina
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
I all,
I can't work on this until 23.2.2007 because of my diploma thesis.
But my opinion is - if you make a release with this bug, you'll see more
reporters soon. It can be than fixed in 2.6.20.1 - I haven't find any data
corruptions yet.
Michal
Dne ?tvrtek 11 leden 2007 11:54 Adrian Bunk napsal(a):
> On Thu, Jan 11, 2007 at 11:21:23AM +0100, Jiri Kosina wrote:
> > On Thu, 11 Jan 2007, Adrian Bunk wrote:
> > > > >Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
> > > > >References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
> > > > >Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>
> > > > >Handled-By : John McCutchan <[email protected]>
> > > > >Status : problem is being debugged
> > > >
> > > > I'm not sure that this is actually a regression for 2.6.20-rc.
> > >
> > > The submitter says it doesn't occur in 2.6.19.
> >
> > Any chance that the submitter could do git bisect? (added to CC). From
> > the bugzilla entry it seems to be well reproducible for him.
>
> That's a possible but time intensive approach for this kind of bug.
>
> I'd expect bisecting such an "at least 1 times a day" bug to take at
> about one month.
>
> And that's not a high number, that's a realistic estimate considering
> that you have to test a dozen kernels and verifying that a kernel is
> good takes 2-3 days.
>
> > Jiri Kosina
>
> cu
> Adrian
Hello
On Thursday 11 January 2007 04:00, Nick Piggin wrote:
> Vladimir V. Saveliev wrote:
> > Hello
> >
> > On Tuesday 09 January 2007 21:30, Linus Torvalds wrote:
> >
> >>On Tue, 9 Jan 2007, Malte Schr?der wrote:
> >>
> >>>>So something interesting is definitely going on, but I don't know exactly
> >>>>what it is. Why does reiserfs do the truncate as part of a close, if the
> >>>>same inode is actually mapped somewhere else?
> >
> >
> > on file close reiserfs tries to "pack" content of last incomplete page of file into metadata blocks.
> > It should not if that page is still mapped somewhere.
> > It does not actually truncate, it calls the same function which does truncate, but file size does not change.
>
> That's racy, unfortunately :P
>
Sorry, please, explain what is racy.
reiserfs_truncate and reiserfs_release call that function after they have inode's mutex locked.
> >
> > Please consider the below patch.
>
> That seems like it would work. Probably papers over your truncate-inside-i_size as well.
>
On Thu, Jan 11, 2007 at 06:13:29AM +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
> with patches available.
>
> Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
> References : http://lkml.org/lkml/2007/1/5/308
> Submitter : Sami Farin <[email protected]>
> Handled-By : David Chinner <[email protected]>
> Patch : http://lkml.org/lkml/2007/1/7/201
> Status : patch available
Patch is broken, do not merge. The original had an off-by-one bug in
it, and the fixed one I have has just shown a worse problem than
before - partial page truncation (i.e. filesystem block size less
than page size) is busted because invalidate_complete_page2_range() can
only handle complete pages.
Andrew - looking at unmap_mapping_pages, it says it cannot handle
partial pages and must get rid of them whereas vmtrucate() handles
partial pages but changes file size so can't be used. I see that
vmtruncate handles this by not unmapping the first partial page.
I can use the vmtruncate mechanism (unmap_mapping_pages, then
truncate_inode_pages) but that seems racy to me because we are not
actually truncating the file so a mmap could remap a page between
the unmap and the truncate and hence we still get the warning.
So the question is - is there any generic function that handles
this case (i.e. don't unmap first partial page, unmap the rest,
partial truncate of first page, complete truncate of the rest)
without racing? Or do I need to write a variation of
invalidate_inode_pages2_range() to do this?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
On Fri, 12 Jan 2007 08:39:16 +1100
David Chinner <[email protected]> wrote:
> On Thu, Jan 11, 2007 at 06:13:29AM +0100, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
> > with patches available.
> >
> > Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
> > References : http://lkml.org/lkml/2007/1/5/308
> > Submitter : Sami Farin <[email protected]>
> > Handled-By : David Chinner <[email protected]>
> > Patch : http://lkml.org/lkml/2007/1/7/201
> > Status : patch available
>
> Patch is broken, do not merge. The original had an off-by-one bug in
> it, and the fixed one I have has just shown a worse problem than
> before - partial page truncation (i.e. filesystem block size less
> than page size) is busted because invalidate_complete_page2_range() can
> only handle complete pages.
>
> Andrew - looking at unmap_mapping_pages, it says it cannot handle
> partial pages and must get rid of them whereas vmtrucate() handles
> partial pages but changes file size so can't be used. I see that
> vmtruncate handles this by not unmapping the first partial page.
>
> I can use the vmtruncate mechanism (unmap_mapping_pages, then
> truncate_inode_pages) but that seems racy to me because we are not
> actually truncating the file so a mmap could remap a page between
> the unmap and the truncate and hence we still get the warning.
Yes, truncate relies upon there being nothing outside i_size, and that
i_mutex is held.
> So the question is - is there any generic function that handles
> this case (i.e. don't unmap first partial page, unmap the rest,
> partial truncate of first page, complete truncate of the rest)
> without racing? Or do I need to write a variation of
> invalidate_inode_pages2_range() to do this?
umm, nothing I can immediately think of. Perhaps you can generalise
vmtruncate_range() a bit?
On Thu, Jan 11, 2007 at 02:02:41PM -0800, Andrew Morton wrote:
> On Fri, 12 Jan 2007 08:39:16 +1100
> David Chinner <[email protected]> wrote:
>
> > On Thu, Jan 11, 2007 at 06:13:29AM +0100, Adrian Bunk wrote:
> > > This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
> > > with patches available.
> > >
> > > Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
> > > References : http://lkml.org/lkml/2007/1/5/308
> > > Submitter : Sami Farin <[email protected]>
> > > Handled-By : David Chinner <[email protected]>
> > > Patch : http://lkml.org/lkml/2007/1/7/201
> > > Status : patch available
> >
> > Patch is broken, do not merge. The original had an off-by-one bug in
> > it, and the fixed one I have has just shown a worse problem than
> > before - partial page truncation (i.e. filesystem block size less
> > than page size) is busted because invalidate_complete_page2_range() can
> > only handle complete pages.
> >
> > Andrew - looking at unmap_mapping_pages, it says it cannot handle
> > partial pages and must get rid of them whereas vmtrucate() handles
> > partial pages but changes file size so can't be used. I see that
> > vmtruncate handles this by not unmapping the first partial page.
> >
> > I can use the vmtruncate mechanism (unmap_mapping_pages, then
> > truncate_inode_pages) but that seems racy to me because we are not
> > actually truncating the file so a mmap could remap a page between
> > the unmap and the truncate and hence we still get the warning.
>
> Yes, truncate relies upon there being nothing outside i_size, and that
> i_mutex is held.
>
> > So the question is - is there any generic function that handles
> > this case (i.e. don't unmap first partial page, unmap the rest,
> > partial truncate of first page, complete truncate of the rest)
> > without racing? Or do I need to write a variation of
> > invalidate_inode_pages2_range() to do this?
>
> umm, nothing I can immediately think of. Perhaps you can generalise
> vmtruncate_range() a bit?
I had a look at that - apart from being used for actually freeing disk
blocks as well (punching a hole in the file) - it requires locks that
we may or may not be able to grab and still has the problem of
separate calls to unmap_mapping_pages and truncate_inode_pages_range.
Unless I'm misunderstanding the purpose of vmtruncate_range() I
don't think it's the right API to be using because XFS only needs
to invalidate the page cache (hence my thoughts on a variant of
invalidate_inode_pages2_range being required).
Am I making sense, or do I need more coffe this morning?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
Vladimir V. Saveliev wrote:
> Hello
>
> On Thursday 11 January 2007 04:00, Nick Piggin wrote:
>>That's racy, unfortunately :P
>>
>
>
> Sorry, please, explain what is racy.
> reiserfs_truncate and reiserfs_release call that function after they have inode's mutex locked.
Calling truncate inside i_size (ie. vmtruncate_range is also racy), because
of the way that the pagefault side of the equation works (eg. truncate_count).
But if you're only calling truncate on files that are never mmapped, then I
think that race should disappear.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com