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
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.
>
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.
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.
>
>
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
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
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
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
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
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
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.
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
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
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]: ***
* 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)
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"
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.
> > >
> >
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
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
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.
>
>
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
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
[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
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
>>
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
> 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
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
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
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
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
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.
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
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
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.
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.
--
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)
{
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
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
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
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
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
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
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)
>
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
>>
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
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
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
> >>
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
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
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
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
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
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
+- #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
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]>:
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
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,
>>
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
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
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
"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
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
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
> 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
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
>
> 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
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
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
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)
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
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
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
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
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
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 /
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/
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
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
+++
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
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
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):
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
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
>> 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
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
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
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
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
201 - 300 of 614 matches
Mail list logo
