Re: [PATCH] Containment measures for slab objects on scatter gather lists
On Thu, 28 Jun 2007, Christoph Lameter wrote: > I had a talk with James Bottomley last night and it seems that there is an > established way of using the page structs of slab objects in the block > layer. Drivers may use the DMA interfaces to issue control commands. In > that case they may allocate a short structure via the slab allocator and > put the control commands into that slab object. > > The driver will then perform a sg_init_one() on the slab object. > sg_init_one() calls sg_set_buf() which determines the page struct of a > page. In this case sg_set_buf() will determine the page struct of a slab > object. The dma layer may then perform operations on the "slab page". The > block layer folks seem to have spend some time to make this work right. Yes, I don't see why this comes as such a surprise and horror to you, so much in need of dire WARNINGs. kmalloc memory is not a different kind of memory from what you get from the page allocators. I stand by my page_mapping patch, and the remark I made before, that page_mapping(page) is the correct place to check this. What is page_mapping(page) for? Precisely to return the struct address_space* from page->mapping when that's what's in there, and not when that field has been reused for something else. So lines like > + mapping = PageSlab(page) ? NULL : page_mapping(page); seem to miss the point. I agree that the only clash found yet has been in flush_dcache_page, so some bytes and branches can indeed be saved by just doing the test in there. Oh, but your VM_BUG_ON cancels out that saving. And if we were to try to save bytes and branches there, it's the synthetic swapper_space business (only required in a couple of places) I'd be wanting to cut out. To me this all seems like a big fuss to excuse your surprise: so please don't expect an Ack from me; but if others prefer this, I won't be Nacking. (Though I'll probably whine about it into eternity ;) Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
On Thu, 2007-06-28 at 15:49 +0200, Jan Engelhardt wrote: > I'll have to chime in here. > Test program: > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include /* get IP_FREEBIND */ > > Creates a lot of error messages. > (Lots of redefinitions.) > > $ rpm -q linux-kernel-headers glibc > linux-kernel-headers-2.6.21-7 > glibc-2.6-5 > (suse 10.3 factory) > > So looks like there's still something to do. Hm, yes. But what? Is it reasonable for people to include and at the same time? It's suboptimal that they have to include for certain definitions, but that file also provides conflicting definitions of stuff which exists elsewhere. Should we split into two parts? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hello. Mariusz Kozlowski wrote: allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 I'm not sure if this will work out but maybe it's worth to disable XMON if KGDB is selected, like this? config XMON bool "Include xmon kernel debugger" depends on DEBUGGER && !KGDB Regards, Mariusz WBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
Hi, > > Just look at the tasklet_disable() logic. > > Do not count this. > > Done this way because nobody needed that thing, except for _one_ place > in keyboard/console driver, which was very difficult to fix that time, > when vt code was utterly messy and not smp safe at all. > > start_bh_atomic() was successfully killed, but we had to preserve analogue > of disable_bh() with the same semantics for some time. > It is deliberately implemented in a way, which does not impact hot paths > and is easy to remove. > > It is sad that some usb drivers started to use this creepy and > useless thing. the usbatm USB driver uses it in the methods for opening and closing a new network connection, and on device disconnect. Yes, tasklet_disable could be eliminated by adding a spinlock. However this would mean taking the lock every time a packet is received or transmitted. As it is, typically open occurs once, when the computer boots, and close and disconnect also occur once each, when the computer shuts down. I felt that three calls to tasklet_disable were better than a gazillion calls to spin_(un)lock. Please feel free to educate me :) Ciao, Duncan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Vim highlighting for trailing spaces
On 6/29/07, Michael Tokarev <[EMAIL PROTECTED]> wrote: Kyle Moffett wrote: > On Jun 28, 2007, at 03:20:24, Dave Young wrote: >> And for vim trailing space, there's a tip in vim.org: >> http://www.vim.org/tips/tip.php?tip_id=878 > > I actually prefer this (in .vimrc): > > " Show trailing whitespace and spaces before tabs > hi link localWhitespaceError Error > au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display > au Syntax * syn match localWhitespaceError / \+\ze\t/ display > > It always displays trailing whitespace and spaces-before tabs... except > if your cursor is at the end of the whitespace. The updating is > occasionally a bit laggy (EG: Put spaces on a line and then move the > cursor off it without pressing ), but when you hit Ctrl-L, enter, > or edit an adjacent line then it updates. Stolen from an old message in LKML - I don't remember who's the author: highlight WhitespaceEOL ctermbg=red guibg=red match WhitespaceEOL /\s\+$/ Works without any glitches here (not "laggy"). But I don't use syntax coloring - never tried if it works with coloring or not. That only highlights whitespace at the end of the lines. You might want to use pattern below to also highlight "tab after space" in the middle of the line: :highlight RedundantSpaces ctermbg=red guibg=red :match RedundantSpaces /\s\+$\| \+\ze\t/ -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Anton Petrusevich wrote: Is there a tool which can be used to configure .asoundrc? There is an QT4 based one [1] and a somewhat old KDE based tool [2]. Regards, Gabriel C [1] http://sourceforge.net/projects/aplugedit/ [2] http://sourceforge.net/projects/kasound/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 boot fail, EIP in __change_page_attr:166
Dave Young wrote: The diffrences is net520c item. sorry it is netsc520, I will post the patch after a while. I read your other mail out of order, and I'd forgotten about this oops. But still, the fix you posted doesn't look quite right. How big is the netsc520 ioremap? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression: 2.6.22-rcX: hda: lost interrupt
Folks,
After updating an x86_64 machine from 2.6.21 to 2.6.22-rc6 and
fighting off the where-the-fuck-did-my-serial-console-go blues
(legacy_serial.force), I finally discovered why the damn thing
wasn't booting - the machine was sitting there in a loop outputting
"hda: lost interrupt" over and over again during hardware
discovery (hda = dvd drive).
It doesn't happen on every boot - more boots hung than failed,
though, while I was trying to work out where my serial port
went and get some work done.
Since I've had the console operative, the boot hangs are
basically like:
ESB2: IDE controller at PCI slot :00:1f.1
ACPI: PCI Interrupt :00:1f.1[A] -> GSI 20 (level, low) -> IRQ20
ESB2: chipset revision 9
ESB2: not 100% native mode: will probe irqs later
ide0: DM-DMA at 0x50a0-0x50a7, BIOS settings: hda:DMA, hdb:pio
ide1: DM-DMA at 0x50a8-0x50af, BIOS settings: hda:pio, hdb:pio
Probing IDE interface ide0...
hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x58)
hda: , ATAPI UNKNOWN (type 31) drive
hdb: probing with STATUS(0xb0) instead of ALTSTATUS(0x00)
hdb: probing with STATUS(0xa1) instead of ALTSTATUS(0x51)
hdb: , ATAPI UNKNOWN (type 31) drive
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { AbortedCommand }
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
..
The success boots I've had (looking at the boot logs) have all
failed to discover the dvd drive correctly except one. The
one that dsicovered it still had errors, though. Errors
look like:
ESB2: IDE controller at PCI slot :00:1f.1
ACPI: PCI Interrupt :00:1f.1[A] -> GSI 20 (level, low) -> IRQ20
ESB2: chipset revision 9
ESB2: not 100% native mode: will probe irqs later
ide0: DM-DMA at 0x50a0-0x50a7, BIOS settings: hda:DMA, hdb:pio
ide1: DM-DMA at 0x50a8-0x50af, BIOS settings: hda:pio, hdb:pio
Probing IDE interface ide0...
hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x58)
hda: , ATAPI UNKNOWN (type 31) drive
hdb: probing with STATUS(0xb0) instead of ALTSTATUS(0x00)
hdb: probing with STATUS(0xa1) instead of ALTSTATUS(0x51)
hdb: , ATAPI UNKNOWN (type 31) drive
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }
hda: selected mode 0x0
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { AbortedCommand }
hda: selected mode 0x0
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Another failure mode:
hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x58)
hda: , ATAPI UNKNOWN (type 31) drive
hdb: probing with STATUS(0xb0) instead of ALTSTATUS(0x00)
hdb: probing with STATUS(0xb0) instead of ALTSTATUS(0x00)
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { AbortedCommand }
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: lost interrupt
hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_in_intr: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xa1
And another:
hda: host side 80-wire cable detection failed, limiting max speed to UDMA33
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { AbortedCommand }
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: lost interrupt
And other boots were a combination of the ones above.
And the boot that really read the drive type properly but had
scary warnings:
ESB2: IDE controller at PCI slot :00:1f.1
ACPI: PCI Interrupt :00:1f.1[A] -> GSI 20 (level, low) -> IRQ20
ESB2: chipset revision 9
ESB2: not 100% native mode: will probe irqs later
ide0: DM-DMA at 0x50a0-0x50a7, BIOS settings: hda:DMA, hdb:pio
ide1: DM-DMA at 0x50a8-0x50af, BIOS settings: hda:pio, hdb:pio
Probing IDE interface ide0...
hda: DV-28E-R, ATAPI CD/DVD-ROM drive
hda: selected mode 0x42
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 24X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hda: status error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
I haven't seen any failures like this on 2.6.21 or earlier, so
this is appears to be new to 2.6.22-rc.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: [OT] Vim highlighting for trailing spaces
Kyle Moffett wrote: > On Jun 28, 2007, at 03:20:24, Dave Young wrote: >> And for vim trailing space, there's a tip in vim.org: >> http://www.vim.org/tips/tip.php?tip_id=878 > > I actually prefer this (in .vimrc): > > " Show trailing whitespace and spaces before tabs > hi link localWhitespaceError Error > au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display > au Syntax * syn match localWhitespaceError / \+\ze\t/ display > > It always displays trailing whitespace and spaces-before tabs... except > if your cursor is at the end of the whitespace. The updating is > occasionally a bit laggy (EG: Put spaces on a line and then move the > cursor off it without pressing ), but when you hit Ctrl-L, enter, > or edit an adjacent line then it updates. Stolen from an old message in LKML - I don't remember who's the author: highlight WhitespaceEOL ctermbg=red guibg=red match WhitespaceEOL /\s\+$/ Works without any glitches here (not "laggy"). But I don't use syntax coloring - never tried if it works with coloring or not. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND
On Thu, Jun 28, 2007 at 09:12:44PM +0200, Rafael J. Wysocki wrote: > On Thursday, 28 June 2007 19:25, Stefan Seyfried wrote: > > > > However, we don't know which consoles are safe to stay alive during suspend. > > Generally, defaulting to suspending them all is not a bad idea IMHO. > > And IIRC it is plain luck if a serial console survives the suspend (or was > > the serial code fixed recently?) > > Well, I don't think so, but I'm not sure. > > The VGA/fb console also should be off during suspend (not necessarily during > hibernation, though). IIRC, that's what caused Linus to introduce the > suspending of consoles after all. > > > So i do not care too much, but my / Frank's patch was shorter :-) and safer. > > I'm not sure which way to go. On the one hand, I agree that we should rather > fix the consoles so that we know which one is suspend-safe and which is not > and disable the unsafe ones, but on the other hand we are not there yet and it > _sometimes_ is useful not to suspend a console even if we know that it will > break things. This is what my / Frank's patch was aimed at: give the user the ability to (painlessly, without rebuilding the kernel) debug suspend problems. Keep the default safe, like Linus likes it (consoles suspended), but give the user a switch to make it unsafe (consoles not suspended) for the sake of debugging. Of course, fixing up all console drivers is an option that i'd very much like to see. It is however debatable if it is really worth the effort. If it works with consoles suspended, the user does not care. If it doesn't, he turns on debugging (knowing, or being told that this will break using netconsole). I strongly oppose Pavel's approach to "declare all console drivers as nonbroken except netconsole". Even if he has not seen any failures apart from netconsole, in general i had the impression that suspending consoles did help. At least suspend works on many more machines than half a year ago, and i'd not be surprised if this was partly due to suspending the consoles. Remember that wrt. suspend "i did not get a bugreport" very often just means "people tried it, it did not work, but they expected that and just turned away". It does not mean "it just works for everyone". -- Stefan Seyfried QA / R Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] generic bug: use show_regs() instead of dump_stack()
On Fri, 29 Jun 2007 14:19:59 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote: > [patch] generic bug: use show_regs() instead of dump_stack() > > From: Heiko Carstens <[EMAIL PROTECTED]> > > The current generic bug implementation has a call to dump_stack() in > case a WARN_ON(whatever) gets hit. Since report_bug(), which calls > dump_stack(), gets called from an exception handler we can do better: > just pass the pt_regs structure to report_bug() and pass it to > show_regs() in case of a warning. This will give more debug informations > like register contents, etc... In addition this avoids some pointless > lines that dump_stack() emits, since it includes a stack backtrace of > the exception handler which is of no interest in case of a warning. > E.g. on s390 the following lines are currently always present in a stack > backtrace if dump_stack() gets called from report_bug(): > > [<0001517a>] show_trace+0x92/0xe8) > [<00015270>] show_stack+0xa0/0xd0 > [<000152ce>] dump_stack+0x2e/0x3c > [<00195450>] report_bug+0x98/0xf8 > [<00016cc8>] illegal_op+0x1fc/0x21c > [<000227d6>] sysc_return+0x0/0x10 I've seen those extra lines on avr32 as well and I agree they are confusing. Register contents is nice to have too. Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Anton Petrusevich wrote: > On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: > > Sadly it seems pretty much everyone, especially closed source apps get > > this wrong (but to be fair: loads of open source software gets it wrong, > > too, ekiga for example). > > Isn't that because there's a perferct documentation for programming ALSA > but authors of those apps can't read? No, like i said, the docs are unclear on these issues :) That's why so many people get it wrong. > But in real life I have to use flashplayer, for example. Yes, in these cases flashplayer should use either the default pcm device [which the user can then tweak to his liking] or provide some means to configure it. for example via a dotfile in the user's homedir. This is not ALSA's fault. > I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but > now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a > user. I agree that it would be nice to have a tool to select the default device in ALSA. > > But skype is a piece of crap anyways. It also doesn't get any sounds out > > of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a > > beep. And yeah, the device is available [and even has hardware > > multiplexing].. > > > > But 99.9% of problems people have with ALSA are due to badly coded apps.. > > "Those apps are crap and ALSA is perfect". I hoped some ALSA-developers > would think of improving usability of ALSA, or I would not talk here. ALSA must be improved, too. But that doesn't change a thing about these apps misusing the ALSA API and people blaming ALSA lateron. Which is wrong. > It's good that people are not thinking that ALSA is already perfect, it > leaves us (me) a hope it will be improved. I don't think any serious person believes that ALSA is perfect :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ioremap: fix iounmap numpages
Dave Young wrote: Hi, The second parameter of change_page_attr in iounmap is wrong, it should be (p->size - 1) >> PAGE_SHIFT Why's that? Isn't p->size always going to be a pagesize multiple; in which case, why would you want to change_page_attr on n-1 pages? Are you seeing a problem that this patch fixes? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hello, allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 anyway after unselecting XMON we can see: CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat': fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat' undeclared (first use in this function) fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is reported only once fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.) make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1 make[1]: *** [fs/xfs] Blad 2 This is just allmodconfig - not a .config that's used daily by users but I'm used to compiling the kernel using it anyway 8) Regards, Mariusz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
* Alexey Kuznetsov <[EMAIL PROTECTED]> wrote: > > also, the "be afraid of the hardirq or the process context" mantra > > is overblown as well. If something is too heavy for a hardirq, _it's > > too heavy for a tasklet too_. Most hardirqs are (or should be) > > running with interrupts enabled, which makes their difference to > > softirqs miniscule. ^^ > > Incorrect. > > The difference between softirqs and hardirqs lays not in their > "heavyness". It is in reentrancy protection, which has to be done with > local_irq_disable(), unless networking is not isolated from hardirqs. i know that pretty well ;) > That's all. Networking is too hairy to allow to be executed with > disabled hardirqs. And moving this hairyiness to process context > requires a little more efforts than conversion > tasklets to work queues. as i said above (see the underlined sentence), hardirq contexts already run just fine with hardirqs enabled. So your dismissal of executing that 'hairy' bit in hardirq context is not that automatically true as you seem to assume i think. also, network softirq locking dependencies arent all that magic or complex either: they do not operate on sockets that are already locked by a user context, they are per CPU and they are not preempted by 'themselves', nor are they preempted by certain other softirqs (such as they are not preempted by the timer softirq). Am i missing some point of yours? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Chinese translation of Documentation/HOWTO
Hi! > And sometimes maybe the issue isn't even just about straight translations, > but also perhaps about explaining cultural differences that aren't > mentioned at all in the documentation, just because people in the west end > up taking certain things for granted and it doesn't "need" documenting.. Actually docs of cultural differences would be useful even for western people. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please release a stable kernel Linux 3.0
Hi! > > >> Even the good ones that get lots of fixes aren't all that good. The > > >> biggest problem ATM is that suspend is badly broken and keeps getting > > >> worse... > > > > > > I wasn't under the impression suspend had really ever worked. Such a > > > messy problem to solve. > > > > > > > It never worked reliably for everyone, but with each new release it > > seems to get worse. > > the thing is just fundamentally not designed right. Declaring it stable > ain't gonna fix that. Having someone do a right design (which will > obviously will go through some breakage period, even if it's an > evolution of the current design) is a required step of getting s/r more > reliable... but the current one doesn't get stable just by declaring it > so. Ok, I guess one more pair of eyes would help. > > >> Even the good ones that get lots of fixes aren't all that good. The > > >> biggest problem ATM is that suspend is badly broken and keeps getting > > >> worse... > > > > > > Can you please provide me with any links to suspend-related bug reports > > > from > > > you? > > > > I get so many suspend/resume bug reports that I've given up trying > > to get them fixed. And there are so many bugs that are even worse, > > like crashes during normal use, data corruption, etc. that suspend > > bugs don't get much attention. But here are the ones for Fedora 6; > > the list would be much longer if I included Fedora 5 and 7: (list of 20 bugs in redhat bugzilla). ...well, it looks a bit better from my side. Number of suspend bugs in suse bugzilla is certainly lower, and I guess it works a bit better, too. (But we do not claim s2ram support for machines outside of s2ram whitelist). Now, perhaps redhat should get someone to work on suspend/hibernation support (kernel level)? IIRC you had Nigel at one point, but he was working on something else? Rafael and me am trying to look after hibernation, but I believe noone is really working on suspend :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > >What you do with AppArmor, instead of addressing the problem, is just > >redefine the environment along the lines of "set your house into a rock > >wall so there is only one path to it". > > Harrumph. Those analogies sound good but aren't a very good guide. > > Let's take a concrete example. Consider the following fragment of a > policy for Mozilla: > allow ~/.mozilla > deny ~ > Ignore the syntax; the goal is to allow Mozilla to access files under > ~/.mozilla but nothing else under my home directory. This is a perfectly > reasonable policy fragment to want to enforce. And enforcing it in > the obvious way using pathname-based access control is not a ridiculous > thing to do. Unfortunately, mozilla needs temporary files IIRC. And when you add allow /tmp to your config files, you get system where your fellow users can ln HOME/.ssh/identity /tmp/to-steal (or ln HOME/.profile /tmp/put-evil-code-here) and AA protection is not effective any more. Would _you_ do this mistake? Would our users do this mistake? Is it right to provide them with auto-learning tools to make this mistake really easy? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! One more... > 2. This is argument #1 in a different guise and I find it about as weak. > Pathname-based access control has strengths and weaknesses. I think > users and Linux distributions are in a better position to evaluate those > tradeoffs than L-K. Competition is good. It took you quite a lot of time to realize AA does not do IPC (and all the implications of that). I do not think Linux _users_ can do informed decision here. Novell marketing did too good job here. Heck, even I am not sure if I understand the implications of not doing IPC confinement. Is shared memory commonly used in a way that allows exploiting? I know it is a problem, and you probably could kill init from hacked apache. but what would you do to break out of jail? Pavel (please cc me) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > I've heard four arguments against merging AA. > > Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA. > Or: SELinux can do everything that AA can.) > > Argument 2. Object labeling (or: information flow control) is more secure > than pathname-based access control. > > Argument 3. AA isn't complete until it mediates network and IPC. > > Argument 4. AA doesn't have buy-in from VFS maintainers. ... > 1. I think this is a bogus argument for rejecting AA. As I remember it, ... > 3. This one I agree with. If you want to sandbox network daemons that > 4. Way over my head. I'm not qualified to comment on this aspect. > I suspect this is the argument that ought to be getting the most serious > and thorough discussion, not the irrelevant SELinux-vs-AA faceoff. I believe situation is 'vfs maintainers seriously dislike AA', but if they were given good enough reasons -- like 'selinux is broken crap that does not really work', we probably could twist their arms or something. So question is not 'is AA better then SELinux' but 'is AA so much better than SELinux that we want to overrule vfs maintainers'. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] generic bug: use show_regs() instead of dump_stack()
Heiko Carstens wrote: [patch] generic bug: use show_regs() instead of dump_stack() From: Heiko Carstens <[EMAIL PROTECTED]> The current generic bug implementation has a call to dump_stack() in case a WARN_ON(whatever) gets hit. Since report_bug(), which calls dump_stack(), gets called from an exception handler we can do better: just pass the pt_regs structure to report_bug() and pass it to show_regs() in case of a warning. This will give more debug informations like register contents, etc... In addition this avoids some pointless lines that dump_stack() emits, since it includes a stack backtrace of the exception handler which is of no interest in case of a warning. E.g. on s390 the following lines are currently always present in a stack backtrace if dump_stack() gets called from report_bug(): Yep, seems reasonable to me. Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: stopped at "Freeing init memory: 100K "
I have used busybox 1.6.0 and 1.5.1 I used the kernel 2.6.18 from Montavista ,used arm_v5t_le-gcc to compile kernel and busybox , but my busybox can't enter shell I have no "etc/inittab " file . Following is my debug info : ---JK2410: Starting kernel , mach_type is 193 ... Uncompressing Linux. done, booting the kernel. Linux version 2.6.18_pro500-versatile926ejs ([EMAIL PROTECTED]) (gcc version 4.2.0 20070126 (prerelease) (MontaVista 4.2.0-3.0.0.0702771 2007-03-10)) #17 PREEMPT Wed Jun 20 11:37:00 EDT 2007 CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=7177 Machine: SMDK2410 Ignoring unrecognised tag 0x54410008 Memory policy: ECC disabled, Data cache writeback CPU S3C2410A (id 0x32410002) S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz S3C24XX Clocks, (c) 2004 Simtec Electronics CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Real-Time Preemption Support (C) 2004-2006 Ingo Molnar Built 1 zonelists. Total pages: 16384 Kernel command line: root=/dev/ram0 rw console=ttySAC0,115200 mem=64M ramdisk=32768 initrd=0x3080,20M init=/linuxrc WARNING: experimental RCU implementation. irq: clearing subpending status 0002 PID hash table entries: 512 (order: 9, 2048 bytes) timer tcon=0050, tcnt a2c1, tcfg 0200,, usec 1eb8 Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 41976KB available (1952K code, 423K data, 100K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd Freeing initrd memory: 20480K NET: Registered protocol family 16 S3C2410: Initialising architecture NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 4, 65536 bytes) TCP bind hash table entries: 1024 (order: 2, 28672 bytes) TCP: Hash tables configured (established 2048 bind 1024) TCP reno registered NetWinder Floating Point Emulator V0.97 (extended precision) NTFS driver 2.1.27 [Flags: R/O]. io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Console: switching to colour frame buffer device 80x25 fb0: Virtual frame buffer device, using 1024K of video memory S3C2410 RTC, (c) 2004 Simtec Electronics Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled s3c2410-uart.0: s3c2410_serial0 at MMIO map 0x5000 mem 0xf080 (irq = 70) is a S3C2410 s3c2410-uart.1: s3c2410_serial1 at MMIO map 0x50004000 mem 0xf0804000 (irq = 73) is a S3C2410 s3c2410-uart.2: s3c2410_serial2 at MMIO map 0x50008000 mem 0xf0808000 (irq = 76) is a S3C2410 RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize dm9000 Ethernet Driver mice: PS/2 mouse device common for all mice IPv4 over IPv4 tunneling driver TCP bic registered NET: Registered protocol family 1 IP-Config: No network devices available. RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 20480KiB [1 disk] into ram disk... done. VFS: Mounted root (ext2 filesystem). * * * * REMINDER, the following debugging option is turned on in your .config: * * * * CONFIG_DEBUG_PREEMPT * * * * it may increase runtime overhead and latencies. * * * * Freeing init memory: 100K --- <<>>> From: Ben Dooks <[EMAIL PROTECTED]> To: Bob Zhang <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Date: 2007年6月22日 下午10:05 On Fri, Jun 22, 2007 at 09:54:29PM +0800, Bob Zhang wrote: I have used busybox 1.6.0 and 1.5.1 I used the kernel 2.6.18 from Montavista ,used arm_v5t_le-gcc to compile kernel and busybox , but my busybox can't enter shell Why are you using an arm v5 compiler for an arm v4 system? Also why do you feel the need to use a montavista kernel and one as old as 2.6.18! [引用文字已隐藏]did you ensure /dev/ttySAC where correctly created in the root fs? -- Ben Q: What's a light-year? A: One-third less calories than a regular year. From: Mike Frysinger <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Bob Zhang <[EMAIL PROTECTED]> Date: 2007年6月23日 上午2:32 Attachments: signature.asc On Friday 22 June 2007, Bob Zhang wrote: I have used busybox 1.6.0 and 1.5.1 I used the kernel 2.6.18 from Montavista ,used arm_v5t_le-gcc to compile kernel and busybox , but my busybox can't enter shell this is rarely a busybox problem see if booting with init=/bin/sh works if it doesnt, create a static
[patch] generic bug: use show_regs() instead of dump_stack()
[patch] generic bug: use show_regs() instead of dump_stack()
From: Heiko Carstens <[EMAIL PROTECTED]>
The current generic bug implementation has a call to dump_stack() in
case a WARN_ON(whatever) gets hit. Since report_bug(), which calls
dump_stack(), gets called from an exception handler we can do better:
just pass the pt_regs structure to report_bug() and pass it to
show_regs() in case of a warning. This will give more debug informations
like register contents, etc... In addition this avoids some pointless
lines that dump_stack() emits, since it includes a stack backtrace of
the exception handler which is of no interest in case of a warning.
E.g. on s390 the following lines are currently always present in a stack
backtrace if dump_stack() gets called from report_bug():
[<0001517a>] show_trace+0x92/0xe8)
[<00015270>] show_stack+0xa0/0xd0
[<000152ce>] dump_stack+0x2e/0x3c
[<00195450>] report_bug+0x98/0xf8
[<00016cc8>] illegal_op+0x1fc/0x21c
[<000227d6>] sysc_return+0x0/0x10
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Haavard Skinnemoen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Kyle McMartin <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Paul Mundt <[EMAIL PROTECTED]>
Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
Patch is against current git tree. But applies against latest -mm as well.
arch/avr32/kernel/traps.c |2 +-
arch/i386/kernel/traps.c|2 +-
arch/parisc/kernel/traps.c |2 +-
arch/powerpc/kernel/traps.c |2 +-
arch/ppc/kernel/traps.c |2 +-
arch/s390/kernel/traps.c|2 +-
arch/sh/kernel/traps.c |2 +-
arch/x86_64/kernel/traps.c |2 +-
include/linux/bug.h |7 +--
lib/bug.c |5 +++--
10 files changed, 16 insertions(+), 12 deletions(-)
Index: linux-2.6/arch/avr32/kernel/traps.c
===
--- linux-2.6.orig/arch/avr32/kernel/traps.c
+++ linux-2.6/arch/avr32/kernel/traps.c
@@ -184,7 +184,7 @@ asmlinkage void do_illegal_opcode(unsign
if (!user_mode(regs) && (ecr == ECR_ILLEGAL_OPCODE)) {
enum bug_trap_type type;
- type = report_bug(regs->pc);
+ type = report_bug(regs->pc, regs);
switch (type) {
case BUG_TRAP_TYPE_NONE:
break;
Index: linux-2.6/arch/i386/kernel/traps.c
===
--- linux-2.6.orig/arch/i386/kernel/traps.c
+++ linux-2.6/arch/i386/kernel/traps.c
@@ -390,7 +390,7 @@ void die(const char * str, struct pt_reg
unsigned long esp;
unsigned short ss;
- report_bug(regs->eip);
+ report_bug(regs->eip, regs);
printk(KERN_EMERG "%s: %04lx [#%d]\n", str, err & 0x,
++die_counter);
#ifdef CONFIG_PREEMPT
Index: linux-2.6/arch/parisc/kernel/traps.c
===
--- linux-2.6.orig/arch/parisc/kernel/traps.c
+++ linux-2.6/arch/parisc/kernel/traps.c
@@ -302,7 +302,7 @@ static void handle_break(struct pt_regs
if (unlikely(iir == PARISC_BUG_BREAK_INSN && !user_mode(regs))) {
/* check if a BUG() or WARN() trapped here. */
enum bug_trap_type tt;
- tt = report_bug(regs->iaoq[0] & ~3);
+ tt = report_bug(regs->iaoq[0] & ~3, regs);
if (tt == BUG_TRAP_TYPE_WARN) {
regs->iaoq[0] += 4;
regs->iaoq[1] += 4;
Index: linux-2.6/arch/powerpc/kernel/traps.c
===
--- linux-2.6.orig/arch/powerpc/kernel/traps.c
+++ linux-2.6/arch/powerpc/kernel/traps.c
@@ -777,7 +777,7 @@ void __kprobes program_check_exception(s
return;
if (!(regs->msr & MSR_PR) && /* not user-mode */
- report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
+ report_bug(regs->nip, regs) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
return;
}
Index: linux-2.6/arch/ppc/kernel/traps.c
===
--- linux-2.6.orig/arch/ppc/kernel/traps.c
+++ linux-2.6/arch/ppc/kernel/traps.c
@@ -619,7 +619,7 @@ void program_check_exception(struct pt_r
return;
if (!(regs->msr & MSR_PR) && /* not user-mode */
- report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
+ report_bug(regs->nip, regs) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
return;
}
Index: linux-2.6/arch/s390/kernel/traps.c
===
---
Re: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Andreas Steinmetz wrote: >> Patrick McHardy wrote: >> >>> - assuming you have ethernet internally, the PMTU from your router >>> to the internal hosts is 1500, so it won't do any clamping. >>> >> >> Yep, internal PMTU is 1500, still the incoming packets are clamped to >> 1452 on the one line and not clamped on the other. >> >> >>> Does that explain it? >>> >>> A useful thing for TCPMSS for routers would be to clamp to the >>> minimum of the PMTU of both directions. But thats not supported >>> so far. >>> >> >> I wonder, as somteimes it gets clamped. If it would never have been >> clamped I wouldn't have asked. > > > Its possible that one of your ISPs is doing clamping. You could This would be fun as it is the same ISP for both lines. I'll check next week as the lines are located 40km away. > check on ppp0 if thats the case. Or maybe for some reason the > PMTU value for the internal host is smaller than 1500. You can > check that by doing "ip route get ". > No. Unmodified internal network in both test cases. > -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mss to pmtu clamping partially broken?
Andreas Steinmetz wrote: > Patrick McHardy wrote: > >>- assuming you have ethernet internally, the PMTU from your router >>to the internal hosts is 1500, so it won't do any clamping. >> > > > Yep, internal PMTU is 1500, still the incoming packets are clamped to > 1452 on the one line and not clamped on the other. > > >>Does that explain it? >> >>A useful thing for TCPMSS for routers would be to clamp to the >>minimum of the PMTU of both directions. But thats not supported >>so far. >> > > > I wonder, as somteimes it gets clamped. If it would never have been > clamped I wouldn't have asked. Its possible that one of your ISPs is doing clamping. You could check on ppp0 if thats the case. Or maybe for some reason the PMTU value for the internal host is smaller than 1500. You can check that by doing "ip route get ". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Containment measures for slab objects on scatter gather lists
> If those operations involve modifying that slab page's pageframe then what > stops concurrent dma'ers from stomping on each other's changes? As in: > why aren't we already buggy? Or DMA operations falling out with CPU operations in the same memory area. Not all platforms have hardware consistency and some will blat the entire page out of cache. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Andreas Steinmetz wrote: >> Patrick McHardy wrote: >> >>> Andreas Steinmetz wrote: >>> [...] The tcpdump on the client shows that the mss of the incoming syn reply packet is *NOT* clamped to the ppp interface mtu. >>> >>> You forgot to mention *how* you're clamping the MSS. Using >>> TCPMSS? Do you have a rule for incoming packets? >>> >> >> The relevant iptables commands I do use for masquerading and clamping are: >> >> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE >> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \ >> --clamp-mss-to-pmtu > > > Two things here: > > - tcpdumps on ppp0 will show unclamped packets since they haven't > been forwarded yet > That is true, I know this. > - assuming you have ethernet internally, the PMTU from your router > to the internal hosts is 1500, so it won't do any clamping. > Yep, internal PMTU is 1500, still the incoming packets are clamped to 1452 on the one line and not clamped on the other. > Does that explain it? > > A useful thing for TCPMSS for routers would be to clamp to the > minimum of the PMTU of both directions. But thats not supported > so far. > I wonder, as somteimes it gets clamped. If it would never have been clamped I wouldn't have asked. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Tasklet usage in the DRM
On Fri, 2007-06-29 at 09:09 +0200, Michel Dänzer wrote: > I just read an article on LWN's kernel page about plans to remove > tasklets, and I thought I'd explain what the DRM is using tasklets for. > Maybe there's other ways to satisfy the requirements equally well or > even better. > > > The i915 driver uses a tasklet to make sure a GL buffer swap blit or > flip takes effect (or at least starts in the case of a blit) during the > vertical blank period, to avoid tearing. I chose a tasklet for this > purpose because: > > * The traditional method of the vertical blank interrupt waking up > the user process, which would then emit the buffer swap > commands, didn't even come close to avoiding tearing. So I > suspect a workqueue wouldn't cut it either. > * The processing of scheduled buffer swaps could potentially take > a long time, so doing it in hardirq context could cause high IRQ > latency. > * It requires holding the DRM lock, so the 'each tasklet can only > run once at a time' restriction is fine. > > > I'm looking forward to any suggestions what to do with this in case > tasklets disappear, and I'll gladly provide further clarification on the > requirements. If it hasn't been done someone with this hardware could test Steven's patches to see if they do satisfy the requirements.. I think the most recent version was posted in this message, http://lkml.org/lkml/2007/6/27/289 Subject was "[RFC PATCH 0/8] Convert all tasklets to workqueues V3" if people are subscribed to LKML .. (Added Steven to the CC list) Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mss to pmtu clamping partially broken?
Andreas Steinmetz wrote: > Patrick McHardy wrote: > >>Andreas Steinmetz wrote: >> >>>[...] >>>The tcpdump on the client shows that the mss of the incoming syn reply >>>packet is *NOT* clamped to the ppp interface mtu. >> >> >>You forgot to mention *how* you're clamping the MSS. Using >>TCPMSS? Do you have a rule for incoming packets? >> > > > The relevant iptables commands I do use for masquerading and clamping are: > > iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE > iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \ > --clamp-mss-to-pmtu Two things here: - tcpdumps on ppp0 will show unclamped packets since they haven't been forwarded yet - assuming you have ethernet internally, the PMTU from your router to the internal hosts is 1500, so it won't do any clamping. Does that explain it? A useful thing for TCPMSS for routers would be to clamp to the minimum of the PMTU of both directions. But thats not supported so far. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Andreas Steinmetz wrote: >> There seems to be a problem with mss to pmtu clamping for incoming syn >> packets on reply to an outgoing connection on a ppp interface. The mss >> of the outgoing syn packets is always always clamped to the pmtu, I did >> check this with a target host I do have access to. The incoming syn >> reply to such a packet, however, is mss clamped only sometimes and this >> seems to depend on the DSL line used. >> >> The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6. >> >> Test setup: Two DSL lines, otherwise identical setup (same masquerading >> linux gateway, same DSL account, same DSL modem, same DSL line provider, >> same target host, request from and tcpdump on the same client). >> >> Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->... >> >> DSL line 1, working: >> >> 22:26:39.319281 IP (tos 0x0, ttl 64, id 22377, offset 0, flags [DF], >> length: 48 >> ) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok] >> 1465827859:1465827859(0) >> win 5840 >> 22:26:39.459314 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], >> length: 48) 64 >> .34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok] >> 3667852791:3667852791(0) ack >> 1465827860 win 5840 >> >> The tcpdump on the client shows that the mss of the incoming syn reply >> packet is clamped to the ppp interface mtu. >> >> DSL line 2, not working: >> >> 22:03:57.725998 IP (tos 0x0, ttl 64, id 55984, offset 0, flags [DF], >> length: 48 >> ) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok] >> 36968258:36968258(0) win >> 5840 >> 22:03:57.866966 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], >> length: 48) 64 >> .34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok] >> 2226854208:2226854208(0) ack >> 36968259 win 5840 >> >> The tcpdump on the client shows that the mss of the incoming syn reply >> packet is *NOT* clamped to the ppp interface mtu. > > > You forgot to mention *how* you're clamping the MSS. Using > TCPMSS? Do you have a rule for incoming packets? > The relevant iptables commands I do use for masquerading and clamping are: iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \ --clamp-mss-to-pmtu -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Adrian Bunk wrote: > There is also a userspace OSS emulation for ALSA not suffering from > these problems. Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to intercept library calls that open the /dev/dsp devices etc.. This doesn't always work. I suppose the best way to provide OSS emu is to use something like FUSD [similar to the OSS2JACK package] [1] to provide the OSS device files and then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD doesn't really get actively developed anymore it seems. And FUSE can't handle ioctls. [1] http://www.circlemud.org/~jelson/software/fusd/ Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rt9 problem : xruns
Hi, I've recently compiled a "vanilla" 2.6.21 kernel, patched with Ingo Molnar's rt-8 patch, as I was unable to compile with rt-7. I needed it because I'm using audio applications (tests were made with FrugalWare, but I don't think it's a distro issue). Everything was allright until I changed my motherboard for an Asrock 4coreDual-Vsta (I formerly used a Nforce4 one), with VIA PT880 Ultra chipset. I've justed switched the hardware, as Linux is neat enough to boot without having to reinstall the whole OS. Since, I get tons of xruns when using RT applications, and the only solution I've found to "fix" it was to disable ACPI at boot time. Moreover, I get this message at boot time : PCI: BIOS bug: MCFG [EMAIL PROTECTED] is not E820 reserved PCI: not using MMCONFIG I've also tested this hardware setup with a UbuntoStudio kernel (2.6.19), and everything works flawlessy (no XRUNS, no kernel messages) ! So here is my question (I'd like to understand what's happening) : - is it a kernel (or patch) issue ? - is it a bad chipset support in the latest kernel versions ? - could this be related to BIOS issues only (I've tried all available versions without any change) ? - should I use special settings in the ".config" in order to avoid these problems ? I wasn't able to detect what causes these XRUNS, so if anyone has clues ... Regards skb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: > Sadly it seems pretty much everyone, especially closed source apps get this > wrong (but to be fair: loads of open source software gets it wrong, too, > ekiga for example). Isn't that because there's a perferct documentation for programming ALSA but authors of those apps can't read? > Well, like i said, the application in question should allow you to enter > any pcm name you want. If it doesn't it's broken. But in real life I have to use flashplayer, for example. > I don't know of any. But any text editor will do. I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a user. > The flashplayer has been another one of these badly coded apps ;) Maybe > that has changed in recent releases. [...] > But skype is a piece of crap anyways. It also doesn't get any sounds out of > my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. > And yeah, the device is available [and even has hardware multiplexing].. > But 99.9% of problems people have with ALSA are due to badly coded apps.. "Those apps are crap and ALSA is perfect". I hoped some ALSA-developers would think of improving usability of ALSA, or I would not talk here. > I agree. ALSA is not very userfriendly. Especially the missing proper > device enumeration support is a problem. It's good that people are not thinking that ALSA is already perfect, it leaves us (me) a hope it will be improved. -- Anton Petrusevich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mss to pmtu clamping partially broken?
Andreas Steinmetz wrote: > There seems to be a problem with mss to pmtu clamping for incoming syn > packets on reply to an outgoing connection on a ppp interface. The mss > of the outgoing syn packets is always always clamped to the pmtu, I did > check this with a target host I do have access to. The incoming syn > reply to such a packet, however, is mss clamped only sometimes and this > seems to depend on the DSL line used. > > The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6. > > Test setup: Two DSL lines, otherwise identical setup (same masquerading > linux gateway, same DSL account, same DSL modem, same DSL line provider, > same target host, request from and tcpdump on the same client). > > Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->... > > DSL line 1, working: > > 22:26:39.319281 IP (tos 0x0, ttl 64, id 22377, offset 0, flags [DF], > length: 48 > ) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok] > 1465827859:1465827859(0) > win 5840 > 22:26:39.459314 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], > length: 48) 64 > .34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok] > 3667852791:3667852791(0) ack > 1465827860 win 5840 > > The tcpdump on the client shows that the mss of the incoming syn reply > packet is clamped to the ppp interface mtu. > > DSL line 2, not working: > > 22:03:57.725998 IP (tos 0x0, ttl 64, id 55984, offset 0, flags [DF], > length: 48 > ) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok] > 36968258:36968258(0) win > 5840 > 22:03:57.866966 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], > length: 48) 64 > .34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok] > 2226854208:2226854208(0) ack > 36968259 win 5840 > > The tcpdump on the client shows that the mss of the incoming syn reply > packet is *NOT* clamped to the ppp interface mtu. You forgot to mention *how* you're clamping the MSS. Using TCPMSS? Do you have a rule for incoming packets? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LinuxPPS (with new syscalls API) - new version
On Thu, 2007-06-28 at 18:14 +0200, Rodolfo Giometti wrote: > here my new LinuxPPS patch. > > What to do now for kernel inclusion? Should I provide several patches? > If so how should I divide them? It doesn't apply to the current git tree, which has already had some new system calls added. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
Hello!
> I find the 4usecs cost on a P4 interesting and a bit too high - how did
> you measure it?
Simple and stupid:
int flag;
static void do_test(unsigned long dummy)
{
flag = 1;
}
static void do_test_wq(void *dummy)
{
flag = 1;
}
static void measure_tasklet0(void)
{
int i;
int cnt = 0;
DECLARE_TASKLET(test, do_test, 0);
unsigned long start = jiffies;
for (i=0; i<100; i++) {
flag = 0;
local_bh_disable();
tasklet_schedule();
local_bh_enable();
while (flag == 0) {
schedule();
cnt++;
} /*while (flag == 0)*/;
}
printk("tasklet0: %lu %d\n", jiffies - start, cnt);
}
static void measure_tasklet1(void)
{
int i;
int cnt = 0;
DECLARE_TASKLET(test, do_test, 0);
unsigned long start = jiffies;
for (i=0; i<100; i++) {
flag = 0;
local_bh_disable();
tasklet_schedule();
local_bh_enable();
do {
schedule();
cnt++;
} while (flag == 0);
}
printk("tasklet1: %lu %d\n", jiffies - start, cnt);
}
static void measure_workqueue(void)
{
int i;
int cnt = 0;
unsigned long start;
DECLARE_WORK(test, do_test_wq, 0);
struct workqueue_struct * wq;
start = jiffies;
wq = create_workqueue("testq");
for (i=0; i<100; i++) {
flag = 0;
queue_work(wq, );
do {
schedule();
cnt++;
} while (flag == 0);
}
printk("wq: %lu %d\n", jiffies - start, cnt);
destroy_workqueue(wq);
}
> tasklet as an intermediary towards a softirq - what's the technological
> point in such a splitup?
"... work_struct as intermediary towards a workqueue - what's the technological
point in such a splitup?" Non-sense? Yes, but it is exactly what you said. :-)
softirq is just a context and engine to run something. Exactly like
workqueue task. struct tasklet is work_struct, it is just a thing to run.
> workqueues can be per-cpu - for tasklets to be per-cpu you have to
> open-code them into per-cpu like rcu-tasklets did
I feel I have to repeat: tasklet==work_struct, workqueue==softirq.
Essentially, you said that workqueues "scale" in direction of increasing
amount of softirqs. This is _correct_, but the word is different: "flexible"
is the word. What's about performance,scalability blah-blah, workqueues
are definitely worse. And this is OK, you do not need to conceal this.
This is the price, which we pay for flexibility and to niceness to realtime.
That's what should be said in adverticement notes instead of propaganda.
> Just look at the tasklet_disable() logic.
Do not count this.
Done this way because nobody needed that thing, except for _one_ place
in keyboard/console driver, which was very difficult to fix that time,
when vt code was utterly messy and not smp safe at all.
start_bh_atomic() was successfully killed, but we had to preserve analogue
of disable_bh() with the same semantics for some time.
It is deliberately implemented in a way, which does not impact hot paths
and is easy to remove.
It is sad that some usb drivers started to use this creepy and
useless thing.
> also, the "be afraid of the hardirq or the process context" mantra is
> overblown as well. If something is too heavy for a hardirq, _it's too
> heavy for a tasklet too_. Most hardirqs are (or should be) running with
> interrupts enabled, which makes their difference to softirqs miniscule.
Incorrect.
The difference between softirqs and hardirqs lays not in their "heavyness".
It is in reentrancy protection, which has to be done with local_irq_disable(),
unless networking is not isolated from hardirqs. That's all.
Networking is too hairy to allow to be executed with disabled hardirqs.
And moving this hairyiness to process context requires
a little more efforts than conversion tasklets to work queues.
> The most scalable workloads dont involve any (or many) softirq middlemen
> at all: you queue work straight from the hardirq context to the target
> process context.
Do you really see something common between this Holy Grail Quest and
tasklets/workqeueus? Come on. :-)
Actually, this is step backwards. Instead of execution in correct
context, you create a new dummy context. This is the place, where goals
of realtime and Holy Grail Quest split.
> true just as much: tasklets from a totally uninteresting network adapter
> can kill your latency-sensitive application too.
If I started nice --22 running process I signed to killing latency
of nice 0 processes. But I did not sign for killing network/scsi adapters.
"latency-sensitive application" use real
Re: 2.6.22-rc6 spurious hangs
Hello, > I'm observing seldom hangs with linux 2.6. I can't tell when exactly it > happened the first time, I think somewhere around 2.6.16 or 2.6.17. I > see it about once or twice a month. With absolutely nothing in the logs. > So far I asked for help: > The box I talk about is an IBM T41p with 1.7GHz Pentium M and 512MB RAM. > The distribution in use is gentoo, quite up to date. Attached to the box > is an USB2.0 DVB-T receiver (Cinergy T², Terratec). > > In rare cases the keyboard stops working when the T² stops streaming DVB > to the box. It happens when I record the stream to disk as well as when > I stream it to mplayer. I just wanted you to know that you are not alone with this problem. I've seen the same symptoms on my parents machine during the last 1-2 months --> ie. keyboard hangs completely, mouse works and the host either hangs completely sooner or later with only the following usb debug messages in the logs (pasted below). I believe that there is certainly some sort of bug in cinergyT2-driver as I've not seen the hang happen whenever the cinergyT2 usb-receiver has been disconnected from the machine. Host configuration is: 2.6.22-rc4-git4 kernel + latest DVB drivers from v4l-dvb tree (previously also tested with FC6 kernels with same symptoms) MythTV-software (from devel SVN) Asus P4P800-E motherboard (ich5 & PDC20378 sata-controllers) 1GB ram Intel P4 2.8MHz Terratec Cinergy T2 dvb-t receiver Regards, Tomi Orava -- ehci_hcd :00:1d.7: devpath 1 ep2in 3strikes hub 1-0:1.0: state 7 ports 8 chg evt 0002 ehci_hcd :00:1d.7: GetStatus port 1 status 001002 POWER sig=se0 CSC hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s usb 1-1: USB disconnect, address 2 usb 1-1: unregistering device usb 1-1: usb_disable_device nuking all URBs ehci_hcd :00:1d.7: shutdown urb f6c9a3c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a340 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a2c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a240 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f71a6c40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f7e7f0c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c37dc0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c37e40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f71a6d40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9af40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f71a61c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9ae40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9adc0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9ad40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9acc0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9ac40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9abc0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9ab40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9aac0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9aa40 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a9c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a940 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a8c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a840 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a7c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a740 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a6c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a640 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a5c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a540 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a4c0 pipe c0010280 ep2in-bulk ehci_hcd :00:1d.7: shutdown urb f6c9a440 pipe c0010280 ep2in-bulk cinergyT2: cinergyt2_submit_stream_urb(): urb submission failed (err = -19)! last message repeated 31 times - -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mss to pmtu clamping partially broken?
There seems to be a problem with mss to pmtu clamping for incoming syn packets on reply to an outgoing connection on a ppp interface. The mss of the outgoing syn packets is always always clamped to the pmtu, I did check this with a target host I do have access to. The incoming syn reply to such a packet, however, is mss clamped only sometimes and this seems to depend on the DSL line used. The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6. Test setup: Two DSL lines, otherwise identical setup (same masquerading linux gateway, same DSL account, same DSL modem, same DSL line provider, same target host, request from and tcpdump on the same client). Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->... DSL line 1, working: 22:26:39.319281 IP (tos 0x0, ttl 64, id 22377, offset 0, flags [DF], length: 48 ) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok] 1465827859:1465827859(0) win 5840 22:26:39.459314 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], length: 48) 64 .34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok] 3667852791:3667852791(0) ack 1465827860 win 5840 The tcpdump on the client shows that the mss of the incoming syn reply packet is clamped to the ppp interface mtu. DSL line 2, not working: 22:03:57.725998 IP (tos 0x0, ttl 64, id 55984, offset 0, flags [DF], length: 48 ) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok] 36968258:36968258(0) win 5840 22:03:57.866966 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], length: 48) 64 .34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok] 2226854208:2226854208(0) ack 36968259 win 5840 The tcpdump on the client shows that the mss of the incoming syn reply packet is *NOT* clamped to the ppp interface mtu. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Then something is seriously broken with your kernel. I can only assume that this is because of some vendor modifications. So I would suggest contacting them or trying to get a vanilla kernel running. Hmm. I will try getting the vanilla kernel and putting the required patches. Or rather see what can be done with this driver. Thanks a lot for all the help. Thanks, Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Midhun Agnihotram wrote: >> >> Not likely. It's probably a no-op when you don't have devfs. >> > > CONFIG_MMC_DEBUG is already enabled. This is not printing any debug > statements as such. > Then something is seriously broken with your kernel. I can only assume that this is because of some vendor modifications. So I would suggest contacting them or trying to get a vanilla kernel running. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Not likely. It's probably a no-op when you don't have devfs. CONFIG_MMC_DEBUG is already enabled. This is not printing any debug statements as such. Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please pull from 'from_linus' branch
Kumar Gala wrote: Please pull from 'for_linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus to receive the following updates: drivers/net/gianfar.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Kumar Gala (1): gianfar: Fix typo bug introduced by move to udp_hdr() Why is net driver stuff no longer going through me? Fixes are regularly going upstream. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode
On Thu, Jun 28, 2007 at 11:15:30AM -0700, Andrew Morton wrote:
> CC fs/xfs/linux-2.6/xfs_ioctl32.o
> fs/xfs/linux-2.6/xfs_ioctl32.c: In function ‘xfs_ioc_bulkstat_compat’:
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: ‘xfs_inumbers_fmt_compat’
> undeclared (first use in this function)
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is
> reported only once
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
Sorry, the #define was wrong. This one should work better (at least
build-tested on ppc64 this time):
* 32bit struct xfs_fsop_bulkreq has different size and layout of
members, no matter the alignment. Move the code out of the #else
branch (why was it there in the first place?). Define _32 variants of
the ioctl constants.
* 32bit struct xfs_bstat is different because of time_t and on
i386 becaus of different padding. Create a new formatter
xfs_bulkstat_one_compat() that takes care of this. To do this, we need
to make xfs_bulkstat_one_iget() and xfs_bulkstat_one_dinode()
non-static.
* i386 struct xfs_inogrp has different padding. Introduce a similar
"formatter" mechanism for xfs_inumbers: the native formatter is just a
copy_to_user, the compat formatter takes care of the different layout
Signed-off-by: Michal Marek <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_ioctl.c |2
fs/xfs/linux-2.6/xfs_ioctl32.c | 259 +
fs/xfs/xfs_itable.c| 30 +++-
fs/xfs/xfs_itable.h| 31
4 files changed, 290 insertions(+), 32 deletions(-)
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl32.c
+++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl32.c
@@ -28,12 +28,27 @@
#include "xfs_vfs.h"
#include "xfs_vnode.h"
#include "xfs_dfrag.h"
+#include "xfs_sb.h"
+#include "xfs_log.h"
+#include "xfs_trans.h"
+#include "xfs_dmapi.h"
+#include "xfs_mount.h"
+#include "xfs_inum.h"
+#include "xfs_bmap_btree.h"
+#include "xfs_dir2.h"
+#include "xfs_dir2_sf.h"
+#include "xfs_attr_sf.h"
+#include "xfs_dinode.h"
+#include "xfs_itable.h"
+#include "xfs_error.h"
+#include "xfs_inode.h"
#define _NATIVE_IOC(cmd, type) \
_IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(type))
#if defined(CONFIG_IA64) || defined(CONFIG_X86_64)
#define BROKEN_X86_ALIGNMENT
+#define _PACKED __attribute__((packed))
/* on ia32 l_start is on a 32-bit boundary */
typedef struct xfs_flock64_32 {
__s16 l_type;
@@ -111,35 +126,234 @@ STATIC unsigned long xfs_ioctl32_geom_v1
return (unsigned long)p;
}
+typedef struct compat_xfs_inogrp {
+ __u64 xi_startino;/* starting inode number*/
+ __s32 xi_alloccount; /* # bits set in allocmask */
+ __u64 xi_allocmask; /* mask of allocated inodes */
+} __attribute__((packed)) compat_xfs_inogrp_t;
+
+STATIC int xfs_inumbers_fmt_compat(
+ void __user *ubuffer,
+ const xfs_inogrp_t *buffer,
+ long count,
+ long *written)
+{
+ compat_xfs_inogrp_t *p32 = ubuffer;
+ long i;
+
+ for (i = 0; i < count; i++) {
+ if (put_user(buffer[i].xi_startino, [i].xi_startino) ||
+ put_user(buffer[i].xi_alloccount, [i].xi_alloccount) ||
+ put_user(buffer[i].xi_allocmask, [i].xi_allocmask))
+ return -EFAULT;
+ }
+ *written = count * sizeof(*p32);
+ return 0;
+}
+
#else
-typedef struct xfs_fsop_bulkreq32 {
+#define xfs_inumbers_fmt_compat xfs_inumbers_fmt
+#define _PACKED
+
+#endif
+
+/* XFS_IOC_FSBULKSTAT and friends */
+
+typedef struct compat_xfs_bstime {
+ __s32 tv_sec; /* seconds */
+ __s32 tv_nsec;/* and nanoseconds */
+} compat_xfs_bstime_t;
+
+static int xfs_bstime_store_compat(
+ compat_xfs_bstime_t __user *p32,
+ xfs_bstime_t *p)
+{
+ __s32 sec32;
+
+ sec32 = p->tv_sec;
+ if (put_user(sec32, >tv_sec) ||
+ put_user(p->tv_nsec, >tv_nsec))
+ return -EFAULT;
+ return 0;
+}
+
+typedef struct compat_xfs_bstat {
+ __u64 bs_ino; /* inode number */
+ __u16 bs_mode;/* type and mode*/
+ __u16 bs_nlink; /* number of links */
+ __u32 bs_uid; /* user id */
+ __u32 bs_gid; /* group id */
+ __u32 bs_rdev;/* device value */
+ __s32 bs_blksize; /* block size */
+ __s64 bs_size;/* file size*/
+ compat_xfs_bstime_t bs_atime; /* access time */
+ compat_xfs_bstime_t bs_mtime; /* modify time */
+ compat_xfs_bstime_t bs_ctime; /* inode change time*/
+
Re: Fwd: Mounting MMC card
Midhun Agnihotram wrote: > linux/fs/devfs/base.c. I don't have devfs enabled in my kernel (kernel > version 2.6.16. In fact I don't even get an option to enable it in > menuconfig.). Can this be the cause of the problem?? I have found the > same code in the original kernel version too (the one from > kernel.org). > Not likely. It's probably a no-op when you don't have devfs. You should enable CONFIG_MMC_DEBUG to see what is going wrong. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Hi,
> Both of them show no sign of MMC.
>
Then you cannot mount them. What output did you see in dmesg when you inserted
the card?
The dmesg contains only the following when I remove and insert the card.
<6>imx-mmc imx-mmc.0: card removed
<6>imx-mmc imx-mmc.0: card inserted
Also I was looking through the code. I found this function for init
of mmc_blk (linux/drivers/mmc/mmc_block.c)
static int __init mmc_blk_init(void)
{
int res = -ENOMEM;
res = register_blkdev(major, "mmc");
if (res < 0) {
printk(KERN_WARNING "Unable to get major %d for MMC media:
%d\n",
major, res);
goto out;
}
if (major == 0)
major = res;
devfs_mk_dir("mmc");
return mmc_register_driver(_driver);
out:
return res;
}
This uses the function devfs_mk_dir() - defined in
linux/fs/devfs/base.c. I don't have devfs enabled in my kernel (kernel
version 2.6.16. In fact I don't even get an option to enable it in
menuconfig.). Can this be the cause of the problem?? I have found the
same code in the original kernel version too (the one from
kernel.org).
Thanks,
Midhun.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Anton Petrusevich wrote:
> > > I have ICE1724, a very good sound card to my taste, works like a charm.
> > > But with ALSA I had a really hard time to configure it properly, wanna
> > > see my .asoundrc?
> >
> > Not particularly. I don't count as a great fan of the config file syntax
> > and don't use any configuration myself.
>
> Do you have an SPDIF out? If you don't then you don't need .asoundrc of
> course.
With a properly coded ALSA app, one doesn't need a .asoundrc. You would
enter "plug:spdif" [or something similar] into the pcm device name entry text
field.
Or if you want to point all apps to that device you actually could add this to
your .asoundrc:
pcm.!default {
type plug
slace.pcm "spdif"
}
[or something similar. Too lazy to look up the exact syntax now]. And then
every app using the ALSA API _correctly_ should use that device [if
configured to use the default device, which should be the _default_ ;)]
Sadly it seems pretty much everyone, especially closed source apps get this
wrong (but to be fair: loads of open source software gets it wrong, too,
ekiga for example).
What they do wrong is that they try to present a list of devices to the user
from which he can choose [which isn't bad in itself] and also do _not_ offer
any way to specify an arbitrary PCM device name.
Sadly, the ALSA api docs do not stress this point often enough, so it gets
missed pretty often.
I once posted an [not original, i suppose people before me got that idea, too]
idea to the alsa-dev list a while back, proposing a way to be able
to "register" pcm devices defined in .asoundrc/asound.conf, so that apps that
want to present a list to the user can simply ask ALSA for a list of devices
nd hav the user defined ones included. Sadly i don't think it ever went
anywhere..
> Because I want to route it differently, sometimes to spdif, sometimes to
> headphones, sometimes to mix sounds from different apps. Well, my config
> may be a bit ancient as it was written when dmix was not default.
Well, like i said, the application in question should allow you to enter any
pcm name you want. If it doesn't it's broken.
> I have read some advices for ice1724 already. The main reason I wrote to
> lkml -- I hate .asounrc and reading docs about it. I hate "flexebility"
> that requires restarting apps after changing sound routes.
I own a ice1712, too, but i only use it for JACK and it works brilliantly
there. But i know it can be a bitch to configure since it sports a 10/12
channel device which can be too complicated for some ALSA apps making
assumptions about the device they get ;)
> I perfectly know this one. I would like to use some really user-friendly
> tool.
I don't know of any. But any text editor will do.
> > > I want to be able to hear sound from flashplayer on my reciever or in
> > > my headphones -- how?
> >
> > Not sure? Is your receiver on an analog output and are your headphones
>
> My receiver is on spdif out.
The flashplayer has been another one of these badly coded apps ;) Maybe that
has changed in recent releases.
> > It's not working without an .asoundrc?
>
> Looks like it's not working with. As skype is not so informative.
But skype is a piece of crap anyways. It also doesn't get any sounds out of my
other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And
yeah, the device is available [and even has hardware multiplexing]..
> I am not about ice1724 or .asounrc here. I am trying to talk about
> user-friendliness of ALSA. It's very unfriendly.
I agree. ALSA is not very userfriendly. Especially the missing proper device
enumeration support is a problem.
But 99.9% of problems people have with ALSA are due to badly coded apps..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Midhun Agnihotram wrote: >> >> This all looks correct. How about /proc/partitions? And what's in >> /sys/block? >> > > Both of them show no sign of MMC. > Then you cannot mount them. What output did you see in dmesg when you inserted the card? -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Uli Luckas wrote: > If I remember correctly, mmc devices did not have fixed majors/minors > allocated until recently. Either get a recent kernel or use some kind of > hotplug (udev) scripts to create your device nodes with dynamically allocated > major/minors. > Correct. But a double check in /proc/devices reveals the current allocation. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Am Freitag 29 Juni 2007 11:45 schrieb Midhun Agnihotram: > > > > This all looks correct. How about /proc/partitions? And what's in > > /sys/block? > > > > Both of them show no sign of MMC. > > / # cat /proc/partitions > major minor #blocks name > > 31 0 8192 mtdblock0 > 31 1384 mtdblock1 > 31 2 1664 mtdblock2 > 31 3 2048 mtdblock3 > 31 4 4096 mtdblock4 > > > > / # cd /sys/block/ > /sys/block # ls -l > drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock0 > drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock1 > drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock2 > drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock3 > drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock4 > drwxr-xr-x2 00 0 Jan 1 00:00 ram0 > drwxr-xr-x2 00 0 Jan 1 00:00 ram1 > drwxr-xr-x2 00 0 Jan 1 00:00 ram10 > drwxr-xr-x2 00 0 Jan 1 00:00 ram11 > drwxr-xr-x2 00 0 Jan 1 00:00 ram12 > drwxr-xr-x2 00 0 Jan 1 00:00 ram13 > drwxr-xr-x2 00 0 Jan 1 00:00 ram14 > drwxr-xr-x2 00 0 Jan 1 00:00 ram15 > drwxr-xr-x2 00 0 Jan 1 00:00 ram2 > drwxr-xr-x2 00 0 Jan 1 00:00 ram3 > drwxr-xr-x2 00 0 Jan 1 00:00 ram4 > drwxr-xr-x2 00 0 Jan 1 00:00 ram5 > drwxr-xr-x2 00 0 Jan 1 00:00 ram6 > drwxr-xr-x2 00 0 Jan 1 00:00 ram7 > drwxr-xr-x2 00 0 Jan 1 00:00 ram8 > drwxr-xr-x2 00 0 Jan 1 00:00 ram9 For comparison, here's what it looks like here (kernel 2.6.21.5, udev): # cat /proc/partitions major minor #blocks name 31 0512 mtdblock0 31 1 4096 mtdblock1 31 2 28160 mtdblock2 254 0 250880 mmcblk0 254 1 250697 mmcblk0p1 # ls -l /sys/block/ drwxr-xr-x6 root root0 Jun 29 08:41 mmcblk0 drwxr-xr-x5 root root0 Jun 29 08:41 mtdblock0 drwxr-xr-x5 root root0 Jun 29 08:41 mtdblock1 drwxr-xr-x5 root root0 Jun 29 08:41 mtdblock2 # ls -l /sys/block/mmcblk0 -r--r--r--1 root root 4096 Jun 29 08:41 dev lrwxrwxrwx1 root root0 Jun 29 10:07 device -> ../../class/mmc_host/mmc0/mmc0:0002 drwxr-xr-x2 root root0 Jan 1 1970 holders drwxr-xr-x3 root root0 Jun 29 08:41 mmcblk0p1 drwxr-xr-x3 root root0 Jan 1 1970 queue -r--r--r--1 root root 4096 Jun 29 08:41 range -r--r--r--1 root root 4096 Jun 29 08:41 removable -r--r--r--1 root root 4096 Jun 29 08:41 size drwxr-xr-x2 root root0 Jan 1 1970 slaves -r--r--r--1 root root 4096 Jun 29 08:41 stat lrwxrwxrwx1 root root0 Jun 29 08:41 subsystem -> ../../block --w---1 root root 4096 Jun 29 08:41 uevent # ls -l mmcblk0p1 ls: mmcblk0p1: No such file or directory # ls -l /sys/block/mmcblk0/mmcblk0p1 -r--r--r--1 root root 4096 Jun 29 10:08 dev drwxr-xr-x2 root root0 Jan 1 1970 holders -r--r--r--1 root root 4096 Jun 29 10:08 size -r--r--r--1 root root 4096 Jun 29 10:08 start -r--r--r--1 root root 4096 Jun 29 10:08 stat lrwxrwxrwx1 root root0 Jun 29 10:08 subsystem -> ../../../block --w---1 root root 4096 Jun 29 08:41 uevent # cat /sys/block/mmcblk0/mmcblk0p1/size 501394 # Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: man-pages-2.59 and man-pages-2.60 are released
Michael Kerrisk wrote: Alex: Okay -- I've set up a script that ensures that the "Archive" directory (was "Old") always includes links to the latest versions of the pages, so you can be guaranteed that links in Archive should always be stable (I don't know that I'll ever actually remove files from that directory). Thank you! -- Alexander E. Patrakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
No. The #address-cells is determined by the bus binding, so that all RapidIO busses on the planet can be represented in a similar way in the OF device tree. Take for example the PCI binding, which gives you three address cells -- one to distinguish between different address spaces (configuration space, legacy I/O space, memory mapped space) and to contain some flags (prefetchable vs. non-prefetchable, etc.); the other two 32-bit cells contain a 64-bit address, although config and legacy I/O never are more than 32 bit, and many PCI devices can't do 64-bit addressing at all. Now, there is no OF binding for RapidIO yet of course, but it would be good to start thinking about one while doing the binding for your specific controller -- it will make life easier down the line for everyone, including yourself. How about I add more words here for more clear expression? Such as "<2> for 34 and 50 bit address, <3> for 66 bit address". You should more explicitly define the address format, i.e. what every bit means -- just saying it is 64 or 96 bits isn't enough. While you're doing that, think of a way that can represent _every possible_ RapidIO address, not just the ones supported by this particular controller. Segher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
This all looks correct. How about /proc/partitions? And what's in /sys/block? Both of them show no sign of MMC. / # cat /proc/partitions major minor #blocks name 31 0 8192 mtdblock0 31 1384 mtdblock1 31 2 1664 mtdblock2 31 3 2048 mtdblock3 31 4 4096 mtdblock4 / # cd /sys/block/ /sys/block # ls -l drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock0 drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock1 drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock2 drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock3 drwxr-xr-x3 00 0 Jan 1 00:00 mtdblock4 drwxr-xr-x2 00 0 Jan 1 00:00 ram0 drwxr-xr-x2 00 0 Jan 1 00:00 ram1 drwxr-xr-x2 00 0 Jan 1 00:00 ram10 drwxr-xr-x2 00 0 Jan 1 00:00 ram11 drwxr-xr-x2 00 0 Jan 1 00:00 ram12 drwxr-xr-x2 00 0 Jan 1 00:00 ram13 drwxr-xr-x2 00 0 Jan 1 00:00 ram14 drwxr-xr-x2 00 0 Jan 1 00:00 ram15 drwxr-xr-x2 00 0 Jan 1 00:00 ram2 drwxr-xr-x2 00 0 Jan 1 00:00 ram3 drwxr-xr-x2 00 0 Jan 1 00:00 ram4 drwxr-xr-x2 00 0 Jan 1 00:00 ram5 drwxr-xr-x2 00 0 Jan 1 00:00 ram6 drwxr-xr-x2 00 0 Jan 1 00:00 ram7 drwxr-xr-x2 00 0 Jan 1 00:00 ram8 drwxr-xr-x2 00 0 Jan 1 00:00 ram9 Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
On Friday, 29. June 2007, Midhun Agnihotram wrote: > Hi All, > > > Let's try something a lot less complex than mounting. Try running: > > dd if=/dev/mmcblk0 of=/dev/null count=100 > > Here goes the output(error). > > / # dd if=/dev/mmcblk0 of=/dev/null count=100 > dd: can't open '/dev/mmcblk0': No such device or address > > The /dev is has the following: > > / # ls -l /dev | grep mmc > brwxrwxrwx1 00254, 0 Jun 26 2007 mmcblk0 > brwxrwxrwx1 00254, 1 Jun 26 2007 mmcblk0p0 > brwxrwxrwx1 00254, 2 Jun 26 2007 mmcblk0p1 > brwxrwxrwx1 00254, 3 Jun 26 2007 mmcblk0p2 > brwxrwxrwx1 00254, 4 Jun 26 2007 mmcblk0p3 > If I remember correctly, mmc devices did not have fixed majors/minors allocated until recently. Either get a recent kernel or use some kind of hotplug (udev) scripts to create your device nodes with dynamically allocated major/minors. Regards Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Midhun Agnihotram wrote: > >So are the device nodes wrong? When i say `cat /proc/devices` it says : > > So is the major number 254 is correct for MMC ?? > This all looks correct. How about /proc/partitions? And what's in /sys/block? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: man-pages-2.59 and man-pages-2.60 are released
> > Well, I think all that LFS seems to want is links that are > > stable "for a while" (since I don't suppose that they want > > to use really old tarballs in any case). So, for > > the benefit of LFS, I'll just be less aggressive about > > moving tarballs into "Old" (I'll leave them sitting in > http://www.kernel.org/pub/linux/docs/manpages/ > > for a few months at least.) > > If this helps, here is the version information. > > Stable LFS (version 6.2, released on August 3, 2006) tells users to > download > man-pages 2.34 (two releases old at that time). LFS-6.3 is expected to be > released in two months or so, thus a one-year period before moving > tarballs > to "Old" should be enough even for stable LFS books (and if we agree on > that, I'll close http://wiki.linuxfromscratch.org/lfs/ticket/2037 as > invalid). > > Thanks for cooperation. Alex: Okay -- I've set up a script that ensures that the "Archive" directory (was "Old") always includes links to the latest versions of the pages, so you can be guaranteed that links in Archive should always be stable (I don't know that I'll ever actually remove files from that directory). Rob: the script also creates a LATEST-IS-m.xy file in /pub/linux/docs/manpages. Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver.
Rodolfo Giometti wrote: > On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote: >> Let's start with *JUST* a driver, not trying to update everything >> else in the USB Gadget stack so that it looks like it's designed >> specifically to handle all of Intel's design botches related to >> endpoint config ... and work worse for essentially everything else. >> >> (Unlike pretty much every other vendor, Intel wanted hardware config >> management. It was unusably buggy in pxa21x/25x/26x, and not much >> better in pxa27x.) >> >> >> So in technical terms, and to repeat what I've said before: just >> configure it to act more like a PXA 25x chip (no altsettings) and >> get it so it passes all the tests [1], modulo errata which have no >> workarounds ... then submit that. No epautoconfig updates, no >> patches to every gadget driver to cope with updated autoconfig. > > This looks interesting... as you alredy told this driver derives from > an older one, I just maintained it till now. > > If I well understand I should remove usb_ep_autoconfig() and program > into the controller only one (the default) configuration. Is that > right? You should leave the usb_ep_autoconfig() as is, i.e. do not introduce any new parameters to it. > > Currently I tested the driver only with ether gadget, Why have you submitted the limited driver then? You should test the driver with all gadgets. Also, please report how it works in DMA and PIO modes. And what transfer rate the driver achives in both modes. > but if I do as > above, should I get the driver working with all gadgets automagically? Probably no, but technically there is no reason to not support all gadgets. BTW, I suggest that you wait until PXA3XX arch support will be merged into mainline kernel, then, pxa27x_udc-compatible driver will probably be submitted too. Taking into account that pxa27_udc have not been merged for years, I think extra 2-3 month is ok. Regards, Dmitry > :) > > Thanks a lot, > > Rodolfo > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Hi All, Let's try something a lot less complex than mounting. Try running: dd if=/dev/mmcblk0 of=/dev/null count=100 Here goes the output(error). / # dd if=/dev/mmcblk0 of=/dev/null count=100 dd: can't open '/dev/mmcblk0': No such device or address The /dev is has the following: / # ls -l /dev | grep mmc brwxrwxrwx1 00254, 0 Jun 26 2007 mmcblk0 brwxrwxrwx1 00254, 1 Jun 26 2007 mmcblk0p0 brwxrwxrwx1 00254, 2 Jun 26 2007 mmcblk0p1 brwxrwxrwx1 00254, 3 Jun 26 2007 mmcblk0p2 brwxrwxrwx1 00254, 4 Jun 26 2007 mmcblk0p3 So are the device nodes wrong? When i say `cat /proc/devices` it says : / # cat /proc/devices Character devices: 1 mem 2 pty 3 ttyp 4 /dev/vc/0 4 tty 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 29 fb 90 mtd 128 ptm 136 pts Block devices: 1 ramdisk 1 ramdisk 31 mtdblock 254 mmc So is the major number 254 is correct for MMC ?? Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Vim highlighting for trailing spaces
On 6/29/07, Björn Steinbrink <[EMAIL PROTECTED]> wrote: On 2007.06.29 01:42:22 -0700, Josh Triplett wrote: > Jan Engelhardt wrote: > > On Jun 29 2007 00:53, Josh Triplett wrote: > >> And if you really want highlighting, you can always use grep --color. :) > > > > Been there, done that, have GREP_COLOR env variable defined! > > Same here. Now I just need to convince git-grep to use it. You need to convince grep. When piping its output to less, it won't colorize unless forced. Always forcing color via GREP_OPTIONS might break certain use-cases, and git-grep doesn't allow to pass options. So for me, a bash alias it is: alias gg='GREP_OPTIONS=--color=always git-grep' You might need to set LESS=-R in addition to that, to stop less from stripping the color codes. Björn I ussualy prefer the simple vim search command: /\ *$ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Hi, Segher, > DTS sector to the document of booting-without-of.txt file. > > >>> +- #address-cells : Address representation for > >> "rapidio" devices. > >>> + This field represents the number of cells needed > to represent > >>> + the RapidIO address of the registers. For > >> supporting more than > >>> + 32-bits RapidIO address, this field should be <2>. > >>> + See 1) above for more details on defining #address-cells. > >> > >> What does the RapidIO standard say about number of address > >> bits? You want to follow that, so all RapidIO devices can > >> use the same #address-cells, not just the FSL ones. Also, > >> are there different kinds of address spaces on the bus, or > >> is it just one big memory-like space? > > > > I've checked the specification of RapidIO. The supporting of RapidIO > > extended address modes are 66, 50 and 34 bit. > > These three are all two bits more than some "regular" size -- > do those two extra bits have some special meaning perhaps, > like an address space identifier or something? > > > The Freescale's silicons is only support 34 bit address now. > > Do you mean I should not use words -- 'should be <2>'? > > The #address-cells should be assigned according the address mode > > supported by silicon. > > No. The #address-cells is determined by the bus binding, > so that all RapidIO busses on the planet can be represented > in a similar way in the OF device tree. Take for example > the PCI binding, which gives you three address cells -- one > to distinguish between different address spaces (configuration > space, legacy I/O space, memory mapped space) and to contain > some flags (prefetchable vs. non-prefetchable, etc.); the > other two 32-bit cells contain a 64-bit address, although > config and legacy I/O never are more than 32 bit, and many > PCI devices can't do 64-bit addressing at all. > > Now, there is no OF binding for RapidIO yet of course, but > it would be good to start thinking about one while doing > the binding for your specific controller -- it will make > life easier down the line for everyone, including yourself. > How about I add more words here for more clear expression? Such as "<2> for 34 and 50 bit address, <3> for 66 bit address". Thanks! Wei. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Vim highlighting for trailing spaces
On 2007.06.29 01:42:22 -0700, Josh Triplett wrote: > Jan Engelhardt wrote: > > On Jun 29 2007 00:53, Josh Triplett wrote: > >> And if you really want highlighting, you can always use grep --color. :) > > > > Been there, done that, have GREP_COLOR env variable defined! > > Same here. Now I just need to convince git-grep to use it. You need to convince grep. When piping its output to less, it won't colorize unless forced. Always forcing color via GREP_OPTIONS might break certain use-cases, and git-grep doesn't allow to pass options. So for me, a bash alias it is: alias gg='GREP_OPTIONS=--color=always git-grep' You might need to set LESS=-R in addition to that, to stop less from stripping the color codes. Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Midhun Agnihotram wrote: > > The kernel version is 2.6.16. So I guess there should not be a > problem. Any more things that I need to check?? > Let's try something a lot less complex than mounting. Try running: dd if=/dev/mmcblk0 of=/dev/null count=100 If that fails, then you should either have some revealing output in dmesg or your device nodes must be wrong somehow. If it succeeds, then there is some problem reading the filesystem off the card. Have you tried mounting the card in some other system? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updated sbpcd.c
On 29/06/07, Eberhard Moenkeberg <[EMAIL PROTECTED]> wrote: Hi, On Fri, 29 Jun 2007, Surya Prabhakar N wrote: > > Hi emoenke, >Can this patch be verified and pulled into your tree. > > thanks. > Surya. Jesper Juhl should ack it (if), and Jens Axboe would be the right person to pull it into the tree. Consider Surya's patch to be Acked-by: Jesper Juhl <[EMAIL PROTECTED]> -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Hi, I was talking about the file system on the card. Usually, you've got vfat on such a card. How about that? BTW, You mounted proc on /proc and sysfs on /sys, I hope? Yes I do have the support for vfat and msdos file system. I have formatted the card on a Windows system with "FAT" file system. # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set Also, I have mounted proc and sysfs. No. You don't have jffs2 on your MMC, do you? I do not have a jffs2 on my MMC. >I have seen the udev page. But I am a bit skeptic about > implementing it with my kernelas this kernel is from Microcross - > customized for CSB535FS board. As long as it's a reasonable recent kernel (>=2.6.15), it shouldn't be a problem. The kernel version is 2.6.16. So I guess there should not be a problem. Any more things that I need to check?? Thanks, Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ioremap: fix iounmap numpages
Hi,
The second parameter of change_page_attr in iounmap is wrong, it should be
(p->size - 1) >> PAGE_SHIFT
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
diff -upr linux/arch/i386/mm/ioremap.c linux.new/arch/i386/mm/ioremap.c
--- linux/arch/i386/mm/ioremap.c2007-06-29 16:48:40.0 +
+++ linux.new/arch/i386/mm/ioremap.c2007-06-29 16:50:09.0 +
@@ -196,7 +196,7 @@ void iounmap(volatile void __iomem *addr
/* Reset the direct mapping. Can block */
if ((p->flags >> 20) && p->phys_addr < virt_to_phys(high_memory) - 1) {
change_page_attr(virt_to_page(__va(p->phys_addr)),
-p->size >> PAGE_SHIFT,
+(p->size - 1) >> PAGE_SHIFT,
PAGE_KERNEL);
global_flush_tlb();
}
Regards
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Containment measures for slab objects on scatter gather lists
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Fri, 29 Jun 2007 00:00:39 -0700 (PDT) > On Thu, 28 Jun 2007, David Miller wrote: > > > Really, it would be great if we could treat kmalloc() objects > > just like real pages. Everything wants to do I/O on pages > > but sometimes (like the networking) you have a kmalloc > > chunk which is technically just a part of a page. > > > > The fact that there is no easy way to make this work is > > frustrating :-) > > There is easy way: Allocate a page and just use the first N bytes. You can > specify the bytes to be used when putting the memory onto the scatter > gather list. This wastes memory but it works. You have real refcounting > since you got a real page. > > How frequent are these objects? Every single network packet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
+- #address-cells : Address representation for "rapidio" devices. + This field represents the number of cells needed to represent + the RapidIO address of the registers. For supporting more than + 32-bits RapidIO address, this field should be <2>. + See 1) above for more details on defining #address-cells. What does the RapidIO standard say about number of address bits? You want to follow that, so all RapidIO devices can use the same #address-cells, not just the FSL ones. Also, are there different kinds of address spaces on the bus, or is it just one big memory-like space? I've checked the specification of RapidIO. The supporting of RapidIO extended address modes are 66, 50 and 34 bit. These three are all two bits more than some "regular" size -- do those two extra bits have some special meaning perhaps, like an address space identifier or something? The Freescale's silicons is only support 34 bit address now. Do you mean I should not use words -- 'should be <2>'? The #address-cells should be assigned according the address mode supported by silicon. No. The #address-cells is determined by the bus binding, so that all RapidIO busses on the planet can be represented in a similar way in the OF device tree. Take for example the PCI binding, which gives you three address cells -- one to distinguish between different address spaces (configuration space, legacy I/O space, memory mapped space) and to contain some flags (prefetchable vs. non-prefetchable, etc.); the other two 32-bit cells contain a 64-bit address, although config and legacy I/O never are more than 32 bit, and many PCI devices can't do 64-bit addressing at all. Now, there is no OF binding for RapidIO yet of course, but it would be good to start thinking about one while doing the binding for your specific controller -- it will make life easier down the line for everyone, including yourself. Segher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 boot fail, EIP in __change_page_attr:166
On 6/29/07, Dave Young <[EMAIL PROTECTED]> wrote: >On 6/27/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > dave young wrote: > > 2007/6/26, Chuck Ebbert <[EMAIL PROTECTED]>: > >> On 06/25/2007 09:11 PM, dave young wrote: > >> > Hi, > >> > > >> > 2007/6/25, Chuck Ebbert <[EMAIL PROTECTED]>: > >> >> On 06/24/2007 11:43 PM, dave young wrote: > >> >> > Hi, > >> >> > I reconfig my kernel, boot and oops, EIP in > >> __change_page_attr:166, I > >> >> > tried 2.6.22-rc4-mm2 and 2.6.22-rc5 , same result. > >> >> > > >> >> > Anyone has some clues? > >> >> > > >> >> > here is my config file: > >> >> > >> >> Where are the oops messages? > >> > Attached please find the screenshots. sorry for my phone camera > >> resolution. > >> > screen1.png : vga=ask select mode 6 > >> > screen2.png : normal 80x25 console > >> > >> That's 2.6.22-rc4-mm2 which I don't have. > >> > >> netsc520 is doing iounmap() of an area it did > >> ioremap_nocache() on earlier, because it has now failed to > >> find a device. Why it went BUG() I have no idea. > >> > > > > Hi, maybe some config option cause this issue, here is my current > > working-ok config file: > > What are the differences from the non-working config? > > J > The diffrences is net520c item. sorry it is netsc520, I will post the patch after a while. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver.
David Brownell wrote: > On Thursday 28 June 2007, Rodolfo Giometti wrote: > >> As suggest by Leo let me propose to you my new patch for PXA27x UDC >> support. >> >> Please, let me know what I have to do for kernel inclusion. :) > > Let's start with *JUST* a driver, not trying to update everything > else in the USB Gadget stack so that it looks like it's designed > specifically to handle all of Intel's design botches related to > endpoint config ... and work worse for essentially everything else. > > (Unlike pretty much every other vendor, Intel wanted hardware config > management. It was unusably buggy in pxa21x/25x/26x, and not much > better in pxa27x.) > > > So in technical terms, and to repeat what I've said before: just > configure it to act more like a PXA 25x chip (no altsettings) and > get it so it passes all the tests [1], modulo errata which have no > workarounds Other options are: 1. pre-program endpoints so the setting covers all gadget configurations, it seems it's feasible. The only appreciable change is, CDC Ethernet config number should be 3 instead of 1. It should not break anything. 2. Implement a FAKE call of GET_CONFIGURATION command so upon gadget binding you can issue the command and program endpoints according to the received gadget configuration. Also, considering that PXA3XX processors include PXA27x-compatible USB device controller it makes sense to develop a driver that will support both processor families. Hopefully PXA3XX arch support will be merged some day (the arch support has been already submitted here, but I don't know about its current status). Regards, Dmitry > ... then submit that. No epautoconfig updates, no > patches to every gadget driver to cope with updated autoconfig. > > Once there's a basic working no-frills version merged, then we can > talk about whether things in the rest of the stack should change > to accomodate the bizarre concepts of this controller. > > - Dave > > > [1] http://www.linux-usb.org/usbtest/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 boot fail, EIP in __change_page_attr:166
On 6/27/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: dave young wrote: > 2007/6/26, Chuck Ebbert <[EMAIL PROTECTED]>: >> On 06/25/2007 09:11 PM, dave young wrote: >> > Hi, >> > >> > 2007/6/25, Chuck Ebbert <[EMAIL PROTECTED]>: >> >> On 06/24/2007 11:43 PM, dave young wrote: >> >> > Hi, >> >> > I reconfig my kernel, boot and oops, EIP in >> __change_page_attr:166, I >> >> > tried 2.6.22-rc4-mm2 and 2.6.22-rc5 , same result. >> >> > >> >> > Anyone has some clues? >> >> > >> >> > here is my config file: >> >> >> >> Where are the oops messages? >> > Attached please find the screenshots. sorry for my phone camera >> resolution. >> > screen1.png : vga=ask select mode 6 >> > screen2.png : normal 80x25 console >> >> That's 2.6.22-rc4-mm2 which I don't have. >> >> netsc520 is doing iounmap() of an area it did >> ioremap_nocache() on earlier, because it has now failed to >> find a device. Why it went BUG() I have no idea. >> > > Hi, maybe some config option cause this issue, here is my current > working-ok config file: What are the differences from the non-working config? J The diffrences is net520c item. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PXA27x UDC driver.
On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote: > > Let's start with *JUST* a driver, not trying to update everything > else in the USB Gadget stack so that it looks like it's designed > specifically to handle all of Intel's design botches related to > endpoint config ... and work worse for essentially everything else. > > (Unlike pretty much every other vendor, Intel wanted hardware config > management. It was unusably buggy in pxa21x/25x/26x, and not much > better in pxa27x.) > > > So in technical terms, and to repeat what I've said before: just > configure it to act more like a PXA 25x chip (no altsettings) and > get it so it passes all the tests [1], modulo errata which have no > workarounds ... then submit that. No epautoconfig updates, no > patches to every gadget driver to cope with updated autoconfig. This looks interesting... as you alredy told this driver derives from an older one, I just maintained it till now. If I well understand I should remove usb_ep_autoconfig() and program into the controller only one (the default) configuration. Is that right? Currently I tested the driver only with ether gadget, but if I do as above, should I get the driver working with all gadgets automagically? :) Thanks a lot, Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: man-pages-2.59 and man-pages-2.60 are released
Michael Kerrisk wrote: Well, I think all that LFS seems to want is links that are stable "for a while" (since I don't suppose that they want to use really old tarballs in any case). So, for the benefit of LFS, I'll just be less aggressive about moving tarballs into "Old" (I'll leave them sitting in http://www.kernel.org/pub/linux/docs/manpages/ for a few months at least.) If this helps, here is the version information. Stable LFS (version 6.2, released on August 3, 2006) tells users to download man-pages 2.34 (two releases old at that time). LFS-6.3 is expected to be released in two months or so, thus a one-year period before moving tarballs to "Old" should be enough even for stable LFS books (and if we agree on that, I'll close http://wiki.linuxfromscratch.org/lfs/ticket/2037 as invalid). Thanks for cooperation. -- Alexander E. Patrakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20->2.6.21 - networking dies after random time
Update... I did 2 tests : 1) booted with option acpi=off It booted correctly, i managed to get some load on one of the card and after a while (10 minutes i guess) the Timeout occurs. Side effect, at the same moment the sata contolers lost control of the disks somehow and the raid 5 array on the system crashed hard. I have no traces as i was unable to rebuild it (and i tried a lot of extreme voodoo methods). 2) changed the 3com cards i replaced by two cards, 01:06.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42) 01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) reinstalled and stressed the network (small download from a laptop) and : Jun 29 09:34:10 loki kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 29 09:34:51 loki last message repeated 14 times Jun 29 09:35:18 loki last message repeated 8 times so it seems to be a more generic problem. (i'v updated the fedora bugzilla aswell) did not test the "[PATCH] 8139cp dev->tx_timeout" yet. JB > On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote: > > Hello, i have a very similar problem with 2.6.21 also; > > > > 2 3com NICs and they are failling randomly. > > > > The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7) > > I found a bug report and added details here : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960 > > > > I'm not subcribed on this list, so please cc me if there is any questions. > > > > JB > > > > > On Tue, Jun 26, 2007 at 08:10:17AM +0200, Marcin Ślusarz wrote: > > > ... > > > > I reproduced it on minimal config: > ... > > > We know your hardware should be OK - since it was fine with 2.6.20. > ... > > It looks like there is something common in the air... > > Marcin: ne2k_pci with 8390, Jean: 3com, and now I see > similar problem with 8139cp too (plus some ideas): > > http://marc.info/?l=linux-netdev=118293314109648=2 > > So, you probably should wait a little & look for new patches here. > > Cheers, > Jarek P. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LVM/RAID/FS integration
"Kent Overstreet" <[EMAIL PROTECTED]> writes: > > Basically, the order we want is fs -> raid -> lvm. Given a set of > identical drives, we want LVM to handle them separately and divide > them up into LVs identically; then corresponding LVs are raided > together. We might have a raid5 volume and a raid1 volume, each of > which can be resized independently. The FS then makes use of both of > them, putting metadata and frequently used data on the raid1 and > everything else on the raid5 (btrfs, as I understand it, will be able > to do this sort of thing eventually). XFS can do it already using its realtime volume feature. It keeps the metadata on the original device and puts the data on another device. The log can be also on another device (but other file systems support that too) People often complain about the code size and complexity of XFS, but it actually implements a lot of functionality other file systems don't have in there. Arguably it's all not too easy to configure and a little awkward to have upto 3 LVs per fs. And there is no concept of "frequently used data" (which would be probably hard anyways; how would you move data if it becomes frequently used) Out of tree XFS actually supports that using DMAPI and an external manager for automatic swapping of files to tape robots, but you probably don't want to go this way. DMAPI is pretty ugly. > The trouble is it's completely impractical with current tools; we need > tighter integration between md and LVM. The current direction seems to be to slowly duplicate all MD functionality in DM, but then there were also some movements to add a little volume manager to MD. We'll see who wins. They both move relatively slowly. > throw out my ideas before I get too far in. Thoughts? Some nicer high level userland utilities who know how to integrate all this would be probably a good idea. That seems to be the main appeal of ZFS anyways -- simpler user interfaces. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Vim highlighting for trailing spaces
Jan Engelhardt wrote: > On Jun 29 2007 00:53, Josh Triplett wrote: I actually prefer this (in .vimrc): " Show trailing whitespace and spaces before tabs hi link localWhitespaceError Error au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display au Syntax * syn match localWhitespaceError / \+\ze\t/ display >>> I prefer this: >>> >>> find . -type f -print0 | xargs -0 grep -Pn '[\t ]+$' >>> >>> It is editor agnostic, and I do not have to look through all source files >>> for >>> highlighted whitespace :-) >> And if you really want highlighting, you can always use grep --color. :) > > Been there, done that, have GREP_COLOR env variable defined! Same here. Now I just need to convince git-grep to use it. - Josh Triplett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
Am Freitag 29 Juni 2007 09:40 schrieb Midhun Agnihotram: > > >* Is support for the file system on the MMC in your kernel? > > Yes. There is support for MMC card in my kernel. I was talking about the file system on the card. Usually, you've got vfat on such a card. How about that? BTW, You mounted proc on /proc and sysfs on /sys, I hope? > >I have checked the log and it is attached to the end of the mail. > The log contains debug messages for removing and inserting the MMC > card. But nothing specific relating to mount. Can you interpret > anything more from it? No. You don't have jffs2 on your MMC, do you? > > >Have you checked that your device nodes are correct? Since you use busybox I > >assume the system is too lightweight to run udev. > > Yes. I have checked the device nodes. They are fine for MMC. (I > have made them form what I got on the internet. BTW can anybody tell > me how can I find the corresponding major and minor number for my > device driver? This MMC driver is from Microcross. I have put the > device nodes as 254,0 - which are generic.). Here's what I have (nodes created by udev): # ls -l /dev/mmc* brw-rw1 root root 254, 0 Jun 29 08:41 /dev/mmcblk0 brw-rw1 root root 254, 1 Jun 29 08:41 /dev/mmcblk0p1 > > >I run udev on an arm system, it costs you about 200kBytes, > >and saves you all the trouble with creating device files. > >Note that you don't need any rules files. If you want to write > >rules, you can even implement a poor-man's hotplug without HAL. > >If you can afford 200k, use udev. > >I have seen the udev page. But I am a bit skeptic about > implementing it with my kernelas this kernel is from Microcross - > customized for CSB535FS board. As long as it's a reasonable recent kernel (>=2.6.15), it shouldn't be a problem. > I want to try udev only as my last > option. Your choice. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.
> After the reset, I got a 0x06 0x00 back, which is fine. > > But when the driver sets the coordinate output rate, the > TSC-103 answered 0x15 0x01 which means that the TSC-10 is used > with an EEPROM but the EEPROM data is empty (which is > correct). > > In that case the driver should at least continue to allow > initialization of the EEPROM later on. No, I don't think so. Not in it's current form. Currently, usbtouchscreen doesn't have any means to initialize an EEPROM. And in the absence of such a possibility, you need other means to accomplish your task. The current behavior provides you with this "plan b": If you set the rate and that doesn't work because no EEPROM is there, the driver fails. While doing it, it will release the device. This brings in the opportunity to access the touchscreen controller from userspace, e.g. with libusb, and write the EEPROM. After this, reboot, and be happy. Because now the device would act correctly on the "set rate" command and would be usable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: man-pages-2.59 and man-pages-2.60 are released
Bill, > >> There is one little problem with this: there is no stable URL for a > >> given version. > > > > Well, there never really was. To date, most old tarballs have > > had only a limited life on kernel.org. > > > Why? I'm not questioning the policy, it's just that if HUGE kernel > versions are kept available forever, a tiny man page tar would not seem > to be a disk space issue. It's not a space issue -- it's just a question of clutter. Even though I've been the maintainer for coming up for 2.5 years now, Andries was still doing the uploads onto kernel.org until about a year or so ago. I think Andries used to clear down old versions periodically just so it was easier to see which version was the latest. Since I started doing the uploads, I hadn't cleared away any old versions, but yesterday I noticed that the list of files in the directory is getting long, so that it's hard to see what version is latest. So I created the directory "old" and moved all the old stuff in there. Alexander notes that this causes some problem for the LFS folk, since their scripts expect the tarballs to be in stable locations for longer periods. (I was of course unaware of this.) > >> This hurts, e.g., automated Linux From Scratch rebuilds (the > >> official script grabs the URL from the book, but it becomes > >> invalid too soon). [...] > > How about a link in /pub/linux/docs/manpages/ of the form > > "LATEST-IS-m.xy"? Rob Landley was wanting something like this, > > and I guess it would be easy for LFS to build a simple > > script that looks for that link and deduces "man-pages-m.xy" > > from it. (I've just now created such a link in the directory, > > as an example.) > > > Why not just a link with a fixed name (LATEST?) which could be updated? > I assume installing a new version is automated There is no automation on my part. Each time I do a release, I use scp to upload the .tar.gz and .lsm files, and some kernel.org scripts automagically create the .bz2 and .sign files. To maintain any sort of link will either require me to write some script, or manually create the links. > to create and install the > tar, any needed links, the push to mirrors, etc. So it would just be a > single step added to an automated procedure. Yes, I'll write a script to create suitable links. > You could have a link in > "Old" as requested, and any other links as well. Well, I think all that LFS seems to want is links that are stable "for a while" (since I don't suppose that they want to use really old tarballs in any case). So, for the benefit of LFS, I'll just be less aggressive about moving tarballs into "Old" (I'll leave them sitting in http://www.kernel.org/pub/linux/docs/manpages/ for a few months at least.) Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.
> The same is true if there is no EEPROM present but the EEPROM > is enabled. Anyway, I disabled my EEPROM by pulling the SEL4 > pin high because I don't need/want it (yet). The same is done by my hardware guy. In my case, there is no EEPROM attached ... but he didn't pull up this pin up, until I found out what happend. For the EEPROM: I actually don't care if the calibration data is written somewhere in my filesystem or in some proprietary EEPROM. If you create gadgets with unwritable filesystems, e.g. cramfs, then you might care. But I didn't, and therefore didn't bother implementing any support for calibration on the driver-level. I'm doing that completely from userspace. > I started to do some more error handling, but it's propably > not worth doing so if the driver(s) has only limited > functionality (and no userspace app using it). Who says that the driver has no user space app? All touchscreen events that you get are exported via /dev/input/eventX to user space and there are plenty of apps that utilize this info. I wrote a (company inside) tool that reads /dev/input/eventXX, calibrates them and injects those events into X11 via the XTest extension. But for newer X.Org release you can also use xserver-input-event driver. My approach has just the benefit that I can "SIGHUP" my driver any time to re-calibrate, I don't need to restart X for this, which is cumbersome. So, please add error handling and post your patch :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume
David Greaves wrote: been away, back now... again... David Greaves wrote: When I move the swap/resume partition to a different controller (ie when I broke the / mirror and used the freed space) the problem seems to go away. No, it's not gone away - but it's taking longer to show up. I can try and put together a test loop that does work, hibernates, resumes and repeats but since I know it crashes at some point there doesn't seem much point unless I'm looking for something. There's not much in the logs - is there any other instrumentation that people could suggest? DaveC, given this is happening without (obvious) libata errors do you think it may be something in the XFS/md/hibernate area? If there's anything to be tried then I'll also move to 2.6.22-rc6. > Tejun Heo wrote: >> It's really weird tho. The PHY RDY status changed events are coming >> from the device which is NOT used while resuming There is an obvious problem there though Tejun (the errors even when sda isn't involved in the OS boot) - can I start another thread about that issue/bug later? I need to reshuffle partitions so I'd rather get the hibernate working first and then go back to it if that's OK? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Vim highlighting for trailing spaces
On Jun 29 2007 00:53, Josh Triplett wrote: >>> I actually prefer this (in .vimrc): >>> >>> " Show trailing whitespace and spaces before tabs >>> hi link localWhitespaceError Error >>> au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display >>> au Syntax * syn match localWhitespaceError / \+\ze\t/ display >> >> I prefer this: >> >> find . -type f -print0 | xargs -0 grep -Pn '[\t ]+$' >> >> It is editor agnostic, and I do not have to look through all source files for >> highlighted whitespace :-) > >And if you really want highlighting, you can always use grep --color. :) Been there, done that, have GREP_COLOR env variable defined! Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
filemap.c: interesting check around zero_length_segment:
Adding -W -Wno-stupid-warnings results in the following warning:
mm/filemap.c: In function 'generic_file_buffered_write':
mm/filemap.c:2179: warning: comparison of unsigned expression >= 0 is always
true
if (likely(copied >= 0)) {
if (!status)
status = copied;
Branch is always taken since "copied" is size_t.
Such code doesn't exist in -mm, but is this something to worry about for
current and older kernels?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Vim highlighting for trailing spaces
Jan Engelhardt wrote: > On Jun 28 2007 23:11, Kyle Moffett wrote: >> I actually prefer this (in .vimrc): >> >> " Show trailing whitespace and spaces before tabs >> hi link localWhitespaceError Error >> au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display >> au Syntax * syn match localWhitespaceError / \+\ze\t/ display > > I prefer this: > > find . -type f -print0 | xargs -0 grep -Pn '[\t ]+$' > > It is editor agnostic, and I do not have to look through all source files for > highlighted whitespace :-) And if you really want highlighting, you can always use grep --color. :) - Josh Triplett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [linux-lvm] 2.6.22-rc4 XFS fails after hibernate/resume
David Chinner wrote: On Fri, Jun 29, 2007 at 08:40:00AM +0100, David Greaves wrote: What happens if a filesystem is frozen and I hibernate? Will it be thawed when I resume? If you froze it yourself, then you'll have to thaw it yourself. So hibernate will not attempt to re-freeze a frozen fs and, during resume, it will only thaw filesystems that were frozen by the suspend? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [linux-lvm] 2.6.22-rc4 XFS fails after hibernate/resume
On Fri, Jun 29, 2007 at 08:40:00AM +0100, David Greaves wrote: > What happens if a filesystem is frozen and I hibernate? > Will it be thawed when I resume? If you froze it yourself, then you'll have to thaw it yourself. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [linux-lvm] 2.6.22-rc4 XFS fails after hibernate/resume
David Chinner wrote: On Fri, Jun 29, 2007 at 12:16:44AM +0200, Rafael J. Wysocki wrote: There are two solutions possible, IMO. One would be to make these workqueues freezable, which is possible, but hacky and Oleg didn't like that very much. The second would be to freeze XFS from within the hibernation code path, using freeze_bdev(). The second is much more likely to work reliably. If freezing the filesystem leaves something in an inconsistent state, then it's something I can reproduce and debug without needing to suspend/resume. FWIW, don't forget you need to thaw the filesystem on resume. I've been a little distracted recently - sorry. I'll re-read the thread and see if there are any test actions I need to complete. I do know that the corruption problems I've been having: a) only happen after hibernate/resume b) only ever happen on one of 2 XFS filesystems c) happen even when the script does xfs_freeze;sync;hibernate;xfs_thaw What happens if a filesystem is frozen and I hibernate? Will it be thawed when I resume? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Mounting MMC card
Hi All, # mount /dev/mmcblk0p0 /mnt/mmc mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How Try to mount mmcblk0 and/or try fdisk and look at the partition table. dmesg output would also be helpful (after the failed mount). Jan I have tried mounting mmcblk0. But I get the same error from mount. I have pasted the dmesg log at the end of the mail. You should check: * Is the driver for your MMC actually loaded? * Did it initialize correctly? Does it find your MMC card? As far as I have seen the log, the device gets probed properly. Also the kernel detects the MMC card when inserted. So there must be no problem with the driver loading. * Is support for the file system on the MMC in your kernel? Yes. There is support for MMC card in my kernel. The following is from the .config file. # # MMC/SD Card support # CONFIG_MMC=y CONFIG_MMC_DEBUG=y CONFIG_MMC_BLOCK=y CONFIG_MMC_IMX=y * /dev/mmcblk0p0 and /mnt/mmc really exist? (sorry, but...) Yes they do. I have created the /dev/mmcblk0, /dev/mmcblk0p0, /dev/mmcblk0p1, /dev/mmcblk0p2, /dev/mmcblk0p3, /dev/mmcblk0p4 entries using mknod. Also I have created the /mnt and /mnt/mmc directories. Check the output of dmesg for messages from the mmc driver. Hans I have checked the log and it is attached to the end of the mail. The log contains debug messages for removing and inserting the MMC card. But nothing specific relating to mount. Can you interpret anything more from it? Have you checked that your device nodes are correct? Since you use busybox I assume the system is too lightweight to run udev. Yes. I have checked the device nodes. They are fine for MMC. (I have made them form what I got on the internet. BTW can anybody tell me how can I find the corresponding major and minor number for my device driver? This MMC driver is from Microcross. I have put the device nodes as 254,0 - which are generic.). I run udev on an arm system, it costs you about 200kBytes, and saves you all the trouble with creating device files. Note that you don't need any rules files. If you want to write rules, you can even implement a poor-man's hotplug without HAL. If you can afford 200k, use udev. I have seen the udev page. But I am a bit skeptic about implementing it with my kernelas this kernel is from Microcross - customized for CSB535FS board. I want to try udev only as my last option. Please help me resolve this issue. I have been on it for a week now. Thanks a lot, Midhun. The dmesg log: <7>jffs2_add_physical_node_ref(): Node at 0x160300(2), size 0x124 <7>jffs2_write_dnode wrote node at 0x00160300(2) with dsize 0x269, csize 0xde, node_crc 0x7b52763e, data_crc 0x5a16f8e5, totlen 0x0122 <7>[JFFS2 DBG] (673) jffs2_add_full_dnode_to_inode: adding node 0x00-0x269 @0x00160300 on flash, newfrag *c2d05fe0 <7>Obsoleting node at 0x001602bc of len 0x44: <7>Wasting <7>obliterating obsoleted node at 0x001602bc <7>jffs2_complete_reservation() <7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0, dirty_size 0x2f1e4: no <7>increasing writtenlen by 617 <7>jffs2_commit_write() returning 0 <7>jffs2_lookup() <7>jffs2_lookup() <7>jffs2_read_inode(): inode->i_ino == 27 <7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #27 <7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #27 nlink is 1 <7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #27 <7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x087618(3). <7>[JFFS2 DBG] (673) read_more: read more 28 bytes <7>[JFFS2 DBG] (673) read_dnode: dnode @00087618: ver 1, offset 0x00, dsize 0x07, csize 0x07 <7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #27 were read, the highest version is 1, latest_mctime 3269877536, mctime_ver 0. <7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver 1, phys offset 0x087618(3), range 0-7. <7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment 0x00-0x07, ver 1 <7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: symlink's target 'busybox' cached <7>jffs2_read_inode() returning <7>jffs2_follow_link(): target path is 'busybox' <7>jffs2_follow_link(): target path is 'busybox' <6>imx-mmc imx-mmc.0: card removed <6>imx-mmc imx-mmc.0: card inserted <7>jffs2_setattr(): ino #353 <7>jffs2_reserve_space(): Requested 0x44 bytes <7>jffs2_reserve_space(): alloc sem got <7>jffs2_do_reserve_space(): Giving 0x1fbdc bytes at 0x160424 <7>jffs2_add_physical_node_ref(): Node at 0x160424(2), size 0x44 <7>jffs2_write_dnode wrote node at 0x00160424(2) with dsize 0x0, csize 0x0, node_crc 0x93cbd6de, data_crc 0x, totlen 0x0044 <7>[JFFS2 DBG] (673) jffs2_truncate_fragtree: truncating fragtree to 0x bytes <7>Obsoleting node at 0x00160300 of len 0x124: <7>Wasting <7>obliterating obsoleted node at 0x00160300 <7>jffs2_complete_reservation() <7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0, dirty_size 0x2f1e4: no
Re: [OT] Vim highlighting for trailing spaces
On Jun 28 2007 23:11, Kyle Moffett wrote: > I actually prefer this (in .vimrc): > > " Show trailing whitespace and spaces before tabs > hi link localWhitespaceError Error > au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display > au Syntax * syn match localWhitespaceError / \+\ze\t/ display I prefer this: find . -type f -print0 | xargs -0 grep -Pn '[\t ]+$' It is editor agnostic, and I do not have to look through all source files for highlighted whitespace :-) > The script mentioned there *is* good for removing said whitespace, though > > Cheers, > Kyle Moffett > Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
subscribe linux-kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] Unionfs: Remove unnecessary BUG_ON in unionfs_follow_link
From: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/inode.c | 30 --
1 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index a86da5b..b5f9022 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -832,35 +832,21 @@ out:
}
/*
- * Check if dentry is valid or not, as per our generation numbers.
- * @dentry: dentry to check.
- * Returns 1 (valid) or 0 (invalid/stale).
+ * unionfs_follow_link takes a dentry, but it is simple. It only needs to
+ * allocate some memory and then call our ->readlink method. Our
+ * unionfs_readlink *does* lock our dentry and revalidate the dentry.
+ * Therefore, we do not have to lock our dentry here, to prevent a deadlock;
+ * nor do we need to revalidate it either. It is safe to not lock our
+ * dentry here, nor revalidate it, because unionfs_follow_link does not do
+ * anything (prior to calling ->readlink) which could become inconsistent
+ * due to branch management.
*/
-static inline int is_valid_dentry(struct dentry *dentry)
-{
- BUG_ON(!UNIONFS_D(dentry));
- BUG_ON(!UNIONFS_SB(dentry->d_sb));
- return (atomic_read(_D(dentry)->generation) ==
- atomic_read(_SB(dentry->d_sb)->generation));
-}
-
-/* We don't lock the dentry here, because readlink does the heavy lifting. */
static void *unionfs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
char *buf;
int len = PAGE_SIZE, err;
mm_segment_t old_fs;
- /*
-* FIXME: Really nasty...we can get called from two distinct places:
-* 1) read_link - locks the dentry
-* 2) VFS lookup code - does NOT lock the dentry
-*
-* The proper thing would be to call dentry revalidate. It however
-* expects a locked dentry, and we can't cleanly guarantee that.
-*/
- BUG_ON(!is_valid_dentry(dentry));
-
unionfs_read_lock(dentry->d_sb);
/* This is freed by the put_link method assuming a successful call. */
--
1.5.2.2.238.g7cbf2f2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Unionfs: Add missing unlock call in unionfs_file_release
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> --- fs/unionfs/commonfops.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c index 6d87426..8527ac6 100644 --- a/fs/unionfs/commonfops.c +++ b/fs/unionfs/commonfops.c @@ -559,7 +559,7 @@ int unionfs_file_release(struct inode *inode, struct file *file) * support. */ if ((err = unionfs_file_revalidate(file, 1))) - return err; + goto out; fileinfo = UNIONFS_F(file); BUG_ON(file->f_dentry->d_inode != inode); inodeinfo = UNIONFS_I(inode); @@ -596,7 +596,9 @@ int unionfs_file_release(struct inode *inode, struct file *file) fileinfo->rdstate = NULL; } kfree(fileinfo); - return 0; +out: + unionfs_read_unlock(sb); + return err; } /* pass the ioctl to the lower fs */ -- 1.5.2.2.238.g7cbf2f2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Unionfs: Use file->f_path instead of file->f_dentry
From: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 8527ac6..28cb4e9 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -708,10 +708,10 @@ int unionfs_flush(struct file *file, fl_owner_t id)
{
int err = 0;
struct file *lower_file = NULL;
- struct dentry *dentry = file->f_dentry;
+ struct dentry *dentry = file->f_path.dentry;
int bindex, bstart, bend;
- unionfs_read_lock(file->f_path.dentry->d_sb);
+ unionfs_read_lock(dentry->d_sb);
if ((err = unionfs_file_revalidate(file, 1)))
goto out;
@@ -745,6 +745,6 @@ int unionfs_flush(struct file *file, fl_owner_t id)
out_lock:
unionfs_unlock_dentry(dentry);
out:
- unionfs_read_unlock(file->f_path.dentry->d_sb);
+ unionfs_read_unlock(dentry->d_sb);
return err;
}
--
1.5.2.2.238.g7cbf2f2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Unionfs: Clarification comment for unionfs_lookup
From: Erez Zadok <[EMAIL PROTECTED]> Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> --- fs/unionfs/inode.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c index f946b33..a86da5b 100644 --- a/fs/unionfs/inode.c +++ b/fs/unionfs/inode.c @@ -217,6 +217,11 @@ out: return err; } +/* + * unionfs_lookup is the only special function which takes a dentry, yet we + * do NOT want to call __unionfs_d_revalidate_chain because by definition, + * we don't have a valid dentry here yet. + */ static struct dentry *unionfs_lookup(struct inode *parent, struct dentry *dentry, struct nameidata *nd) -- 1.5.2.2.238.g7cbf2f2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL -mm] Unionfs cleanups and fixes
The following patches consist of mostly cleanups and bug fixes of the Unionfs code. As before, there is a git repo at: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git (master.kernel.org:/pub/scm/linux/kernel/git/jsipek/unionfs.git) There are 5 new commits: Erez Zadok (4): Unionfs: Convert all instances of "hidden" to "lower" Unionfs: Use file->f_path instead of file->f_dentry Unionfs: Clarification comment for unionfs_lookup Unionfs: Remove unnecessary BUG_ON in unionfs_follow_link Josef 'Jeff' Sipek (1): Unionfs: Add missing unlock call in unionfs_file_release Thanks, Josef 'Jeff' Sipek <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6][TAKE5] fallocate system call
On Thu, Jun 28, 2007 at 11:33:42AM -0700, Andrew Morton wrote: > I think Mingming was asking that Ted move the current quilt tree into git, > presumably because she's working off git. > > I'm not sure what to do, really. The core kernel patches need to be in > Ted's tree for testing but that'll create a mess for me. Could we please stop this stupid ext4-centrism? XFS is ready so we can put in the syscalls backed by XFS. We have already done this with the xattr syscalls in 2.4, btw. Then again I don't think we should put it in quite yet, because this thread has degraded into creeping featurism, please give me some more time to preparate a semi-coheret rants about this.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB card reader and HAL
Hi Kay :) * Kay Sievers <[EMAIL PROTECTED]> dixit: > On 6/28/07, DervishD <[EMAIL PROTECTED]> wrote: > >When I insert a card in the reader, it is not detected, no udev > >event is generated and I have to do things like "hdparm -z /dev/sda" to > >"probe" the card. Moreover, I have to do the same when removing the card > >or the /dev/sdaX nodes are not deleted. > > > >Is HAL the only way of making it work? Is there any CONFIG_ thing > >I've forgotten in my kernel? > > You have to open() the device node to trigger events from the kernel, > the kernel itself will not do that for you. HAL polls the device every > few seconds. So, opening the node and checking for ENOMEDIUM is the only solution... Polling looks like a waste of time, and given that I use the reader once a month or so, HAL will be a waste of resources. I'll resort to manually do "hdparm -z" (or something similar) when I need to insert or remove a card. Thanks for confirming, Kay :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6 spurious hangs
>> Jun 28 19:23:03 pearl cinergyt2_query_rc+0x0/0x2e9 [cinergyT2]
>
> cinergyt2_query_rc() hangs. I'll try to look tomorrov, but I know nothing
> about drivers/media/dvb/.
Does this mean the problem is in the cinergyt2 driver? I'm having similar
problems with another box but with different hardware. While my laptop is
used as a test system the other one is used as a 'productive' TV-recorder.
I hoped we could trace the bug on the test system and fix the productive
one at the same time. :-/
The other box ("silver") is a desktop, which has two Hauppauge Nova-T DVB-T
PCI cards and one (analog) Hauppauge WinTV PVR-350. Silver only hangs if
the (digital) recording process has to much priority: (silver is running
2.6.21.5-cfs-v17 +squashfs +ivtv)
As I wanted to give as much priority to the recording process as possible
I firstly run dvbd as SCHED_RR. This hung the box quite often, sometimes
after an uptime of several minutes, sometimes after two weeks.
I switched to -ck and run dvbd as SCHED_ISO which worked without *any*
problem for about 18 months. As -ck is discontinued I switched to CFS and
the box hung again (twice until I understood why) when dvbd was running as
nice -15.
ATM dvbd runs with nice -12 but yesterday, during a rsync-transfer of
several >4G files, a recording was broken. 29 seconds of the recorded
stream are lost because the system load was at 5 for about three hours.
Perhaps the 29 missing seconds are caused not by to less CPU time but by
the havy IO of rsync. But on the other hand dvbd is also running at IO
realtime prio 4 (ionice) while rsync run as IO normal.
Any hints?
Thomas
--
keep mailinglists in english, feel free to send PM in german
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tasklet usage in the DRM
I just read an article on LWN's kernel page about plans to remove tasklets, and I thought I'd explain what the DRM is using tasklets for. Maybe there's other ways to satisfy the requirements equally well or even better. The i915 driver uses a tasklet to make sure a GL buffer swap blit or flip takes effect (or at least starts in the case of a blit) during the vertical blank period, to avoid tearing. I chose a tasklet for this purpose because: * The traditional method of the vertical blank interrupt waking up the user process, which would then emit the buffer swap commands, didn't even come close to avoiding tearing. So I suspect a workqueue wouldn't cut it either. * The processing of scheduled buffer swaps could potentially take a long time, so doing it in hardirq context could cause high IRQ latency. * It requires holding the DRM lock, so the 'each tasklet can only run once at a time' restriction is fine. I'm looking forward to any suggestions what to do with this in case tasklets disappear, and I'll gladly provide further clarification on the requirements. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Containment measures for slab objects on scatter gather lists
On Thu, 28 Jun 2007, David Miller wrote: > Really, it would be great if we could treat kmalloc() objects > just like real pages. Everything wants to do I/O on pages > but sometimes (like the networking) you have a kmalloc > chunk which is technically just a part of a page. > > The fact that there is no easy way to make this work is > frustrating :-) There is easy way: Allocate a page and just use the first N bytes. You can specify the bytes to be used when putting the memory onto the scatter gather list. This wastes memory but it works. You have real refcounting since you got a real page. How frequent are these objects? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Containment measures for slab objects on scatter gather lists
On Thu, 28 Jun 2007, Andrew Morton wrote: > If those operations _don't_ involve modifying the pageframe (hopes this is > true) then we're read-only and things become much easier? This is true right now. We are way off topic ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Containment measures for slab objects on scatter gather lists
On Thu, 28 Jun 2007, David Miller wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Thu, 28 Jun 2007 22:24:24 -0700 > > > So what happens when two quite different threads of control are doing > > IO against two hunks of kmalloced memory which happen to come from the same > > page? Either some (kernel-wide) locking is needed, or that pageframe needs > > to be treated as readonly? > > Or you put an atomic_t at the beginning or tail of every SLAB > object. It's a space cost not a runtime cost for the common > case which is: Hmmm... We could do something like kmem_cache_get(slab, object) and kmem_cache_put(slab, object) kmem_cache_get would disable allocations from the slab and increment a refcount. kmem_cache_put would enable allocations again if the refcount reaches one. The problem is that freeing an object may cause writes to the object. F.e. poisoning will overwrite the object on free. SLUB will put its free pointer in the first words etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
