On Mon, Oct 22, 2007 at 11:40:01AM -0700, Andrew Morton wrote:
- Here:
+ if (0 == memcmp(heci_wd_guid,
we boringly prefer if (foo == 0) rather than if (0 == foo). (lots
of places).
But 0 == blah is safer. If you accidentally do 0 = blah the compiler
will tell you. Just
On Tue, Oct 23, 2007 at 09:23:33AM -0700, Arjan van de Ven wrote:
gcc will tell you in the other direction just as well.
and people read from left to right (at least in english) so coding in
that direction is generally preferred in the Linux kernel as well.
What does gcc have to say about if
On Tue, Oct 23, 2007 at 11:22:50AM -0700, Roland Dreier wrote:
It's not a hard experiment to do.
The answer is:
warning: suggest parentheses around assignment used as truth value
A warning is not an error. It won't abort the compile.
The warning (which I don't remember gcc doing in
On Mon, Oct 22, 2007 at 07:33:23PM +0400, Andrey Panin wrote:
> So the card probably generates screaming interrupt... that's bad.
> I found some docs for IT887x chips, according to these docs IT887x
> have simple interrupt controller inside. Further investigation is needed.
>
> Can you post
On Mon, Oct 22, 2007 at 07:33:23PM +0400, Andrey Panin wrote:
So the card probably generates screaming interrupt... that's bad.
I found some docs for IT887x chips, according to these docs IT887x
have simple interrupt controller inside. Further investigation is needed.
Can you post output of
On Fri, Oct 19, 2007 at 11:04:23PM +0100, Nick Warne wrote:
> Yes, Len's advice has me wondering now. Do I have a dodgy cable? I will have
> to change that tomorrow.
>
> But more info. The old drive played DVD movies etc. OK, but slowly it became
> worse until I couldn't read any one of them
On Fri, Oct 19, 2007 at 10:03:09PM +0100, Nick Warne wrote:
> No change:
>
> ide_setup: hdd=ide-cd
> ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
> hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
> hdd: drive side 80-wire cable detection failed, limiting max speed to
On Fri, Oct 19, 2007 at 11:04:23PM +0100, Nick Warne wrote:
Yes, Len's advice has me wondering now. Do I have a dodgy cable? I will have
to change that tomorrow.
But more info. The old drive played DVD movies etc. OK, but slowly it became
worse until I couldn't read any one of them 9
On Fri, Oct 19, 2007 at 10:03:09PM +0100, Nick Warne wrote:
No change:
ide_setup: hdd=ide-cd
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33
On Fri, Oct 12, 2007 at 01:46:33PM -0700, Kok, Auke wrote:
> I would assume that that is true for all PHY's - if there is no link to keep
> the
> carrier active on I would think that the power consumption is nominal across
> the
> board. Once the PHY detects link pulses it should obviously use
On Fri, Oct 12, 2007 at 01:46:33PM -0700, Kok, Auke wrote:
I would assume that that is true for all PHY's - if there is no link to keep
the
carrier active on I would think that the power consumption is nominal across
the
board. Once the PHY detects link pulses it should obviously use
On Thu, Oct 11, 2007 at 01:02:12PM -0400, Chris Bergeron wrote:
> I'm sure that's what it says on the largest chip on the PCI card. It
> could be that the other two chips are more relevant... the numbers from
> them are included below.
>
> I've posted up a quick text only page with the
On Thu, Oct 11, 2007 at 01:02:12PM -0400, Chris Bergeron wrote:
I'm sure that's what it says on the largest chip on the PCI card. It
could be that the other two chips are more relevant... the numbers from
them are included below.
I've posted up a quick text only page with the diagnostic
On Tue, Oct 09, 2007 at 12:56:37PM -0500, Timur Tabi wrote:
> I'm sure they're correct, my problem is that how can my driver know what
> they are?
If they are correct, then you should only need to know about byte order
in my experience.
> I was hoping that there would be some compile-time
On Mon, Oct 08, 2007 at 03:31:51PM -0700, Kok, Auke wrote:
> you most certainly want to do this in userspace I think.
>
> One of the biggest problems is that link negotiation can take a significant
> amount
> of time, well over several seconds (1 to 3 seconds typical) with gigabit, and
> having
On Sat, Oct 06, 2007 at 03:33:59PM -0400, Bill Davidsen wrote:
> I'm not sure that configurations requiring more than 15 partitions are
> properly described as "trivial." Which is not to disagree with your
> point about required user tools, but most systems needing such tools
> will be large
On Fri, Oct 05, 2007 at 05:31:05PM -0400, Chris Bergeron wrote:
> I've just installed a multiport serial card released by an outfit called
> Syba. This is an 8 port serial-only card with an Octopus style breakout
> cable. The main chipset on it is an ITE IT8871F.
Well 8250_pci.c mentions
On Fri, Oct 05, 2007 at 04:10:26PM -0500, Timur Tabi wrote:
> Why not? I honestly don't know what x86 does, but I would think that if I
> write a 32-bit value to a memory location, that when I examine that memory
> location, all 32 bits will be in order.
>
> You're talking about byte endian.
On Fri, Oct 05, 2007 at 04:10:26PM -0500, Timur Tabi wrote:
Why not? I honestly don't know what x86 does, but I would think that if I
write a 32-bit value to a memory location, that when I examine that memory
location, all 32 bits will be in order.
You're talking about byte endian. I'm
On Fri, Oct 05, 2007 at 05:31:05PM -0400, Chris Bergeron wrote:
I've just installed a multiport serial card released by an outfit called
Syba. This is an 8 port serial-only card with an Octopus style breakout
cable. The main chipset on it is an ITE IT8871F.
Well 8250_pci.c mentions IT8871,
On Sat, Oct 06, 2007 at 03:33:59PM -0400, Bill Davidsen wrote:
I'm not sure that configurations requiring more than 15 partitions are
properly described as trivial. Which is not to disagree with your
point about required user tools, but most systems needing such tools
will be large and
On Mon, Oct 08, 2007 at 03:31:51PM -0700, Kok, Auke wrote:
you most certainly want to do this in userspace I think.
One of the biggest problems is that link negotiation can take a significant
amount
of time, well over several seconds (1 to 3 seconds typical) with gigabit, and
having your
On Tue, Oct 09, 2007 at 12:56:37PM -0500, Timur Tabi wrote:
I'm sure they're correct, my problem is that how can my driver know what
they are?
If they are correct, then you should only need to know about byte order
in my experience.
I was hoping that there would be some compile-time constant
On Fri, Oct 05, 2007 at 09:32:11PM +0200, Jan Engelhardt wrote:
> Ah you seem to be a proponent of http://www.blackgoogle.com/
> then :-) Unfortunately, it seems like Xft uses Grayscale AA
> (http://antigrain.com/research/font_rasterization/index.html)
> so black background make the font look
On Fri, Oct 05, 2007 at 09:21:57PM +0200, Jan Engelhardt wrote:
> Indeed it should be 0x07, should it go in.
> Otherwise the openbsd camp might start another flamewar.
>
> (On a personal note, would 0x1F work better for you?)
No, I actually find most things hard to read on a blue background.
On Fri, Oct 05, 2007 at 09:13:40PM +0200, Jan Engelhardt wrote:
> +config VT_PRINTK_COLOR
> + hex "Colored kernel message output"
> + range 0x00 0xFF
> + depends on VT_CONSOLE
> + default 0x17
Shouldn't the default at least be what we already had? Somehow grey on
blue sounds
On Fri, Oct 05, 2007 at 09:13:40PM +0200, Jan Engelhardt wrote:
+config VT_PRINTK_COLOR
+ hex Colored kernel message output
+ range 0x00 0xFF
+ depends on VT_CONSOLE
+ default 0x17
Shouldn't the default at least be what we already had? Somehow grey on
blue sounds pretty hard
On Fri, Oct 05, 2007 at 09:21:57PM +0200, Jan Engelhardt wrote:
Indeed it should be 0x07, should it go in.
Otherwise the openbsd camp might start another flamewar.
(On a personal note, would 0x1F work better for you?)
No, I actually find most things hard to read on a blue background.
Besides
On Fri, Oct 05, 2007 at 09:32:11PM +0200, Jan Engelhardt wrote:
Ah you seem to be a proponent of http://www.blackgoogle.com/
then :-) Unfortunately, it seems like Xft uses Grayscale AA
(http://antigrain.com/research/font_rasterization/index.html)
so black background make the font look
On Fri, Sep 28, 2007 at 05:24:20PM -0400, Bill Davidsen wrote:
> I'll offer this suggestion, knowing it may piss you off, given the
> difficulty of preserving whitespace on *many* mailers without using
> attachments, and given that attachments can be saved easily without
> prying them out of
On Fri, Sep 28, 2007 at 05:24:20PM -0400, Bill Davidsen wrote:
I'll offer this suggestion, knowing it may piss you off, given the
difficulty of preserving whitespace on *many* mailers without using
attachments, and given that attachments can be saved easily without
prying them out of the
On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote:
> But I compile net/* into bzImage. I like netbooting :)
Isn't it possible to netboot with an initramfs image? I am pretty sure
I have seen some systems do exactly that.
--
Len Sorensen
-
To unsubscribe from this list: send the
On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote:
But I compile net/* into bzImage. I like netbooting :)
Isn't it possible to netboot with an initramfs image? I am pretty sure
I have seen some systems do exactly that.
--
Len Sorensen
-
To unsubscribe from this list: send the line
On Thu, Sep 20, 2007 at 09:43:42AM +0200, Wojciech Kromer wrote:
> Uff. Now full memtest takes less than 2 hours.
Being able to cache memory helps a lot.
--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Wed, Sep 19, 2007 at 11:28:16AM +0200, Wojciech Kromer wrote:
> a)With mem=8GB parameter I had:
>
> #free -m
> total used free shared buffers cached
> Mem: 6473 474 5999 0 29 278
>
>
> b) Without mem=8GM system slows down while booting and sometimes restart...
>
>
> So the story
On Wed, Sep 19, 2007 at 11:28:16AM +0200, Wojciech Kromer wrote:
a)With mem=8GB parameter I had:
#free -m
total used free shared buffers cached
Mem: 6473 474 5999 0 29 278
b) Without mem=8GM system slows down while booting and sometimes restart...
So the story begins
On Thu, Sep 20, 2007 at 09:43:42AM +0200, Wojciech Kromer wrote:
Uff. Now full memtest takes less than 2 hours.
Being able to cache memory helps a lot.
--
Len Sorensen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Tue, Sep 18, 2007 at 11:55:29AM -0700, Can E. Acar wrote:
> Well, they can add their names *anywhere* in the whole file, *except*
> these two lines. See, these lines have a whole different meaning
> when it comes to laws. When they make sufficient contribution, they
> sure can add their names.
On Tue, Sep 18, 2007 at 04:35:43PM +0200, Wojciech Kromer wrote:
> Yes, it's a bit strange, but there should be a way to configure it in linux.
> I found only memmap option which does selection of regions, but not
> remapping.
No it is entirely the BIOS's job to do that. It would be very hard
On Tue, Sep 18, 2007 at 03:08:46PM +0100, [EMAIL PROTECTED] wrote:
> The driver already does that ...
>
> result =
> request_irq(irq, can_pci_interrupt, SA_INTERRUPT | SA_SHIRQ,
> pDevice->au8IrqName, pDevice);
>
>
> Any other ideas?
Maybe the system thinks a ps2
On Tue, Sep 18, 2007 at 09:01:44AM +0200, Wojciech Kromer wrote:
> I have 2.6.22.6 kernel
>
> First MTRR looks good for me.
> Why it was rejected?
> And how to force using it?
>
> here are more details
>
> [EMAIL PROTECTED] ~]# cat /proc/mtrr
> reg00: base=0x1 (4096MB), size=8192MB:
On Tue, Sep 18, 2007 at 03:08:46PM +0100, [EMAIL PROTECTED] wrote:
The driver already does that ...
result =
request_irq(irq, can_pci_interrupt, SA_INTERRUPT | SA_SHIRQ,
pDevice-au8IrqName, pDevice);
Any other ideas?
Maybe the system thinks a ps2 mouse port
On Tue, Sep 18, 2007 at 09:01:44AM +0200, Wojciech Kromer wrote:
I have 2.6.22.6 kernel
First MTRR looks good for me.
Why it was rejected?
And how to force using it?
here are more details
[EMAIL PROTECTED] ~]# cat /proc/mtrr
reg00: base=0x1 (4096MB), size=8192MB: write-back,
On Tue, Sep 18, 2007 at 04:35:43PM +0200, Wojciech Kromer wrote:
Yes, it's a bit strange, but there should be a way to configure it in linux.
I found only memmap option which does selection of regions, but not
remapping.
No it is entirely the BIOS's job to do that. It would be very hard for
On Tue, Sep 18, 2007 at 11:55:29AM -0700, Can E. Acar wrote:
Well, they can add their names *anywhere* in the whole file, *except*
these two lines. See, these lines have a whole different meaning
when it comes to laws. When they make sufficient contribution, they
sure can add their names.
On Fri, Sep 14, 2007 at 11:06:44PM +0200, Stefan Richter wrote:
> On 14 Sep, Lennart Sorensen wrote:
> > On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
> >> -If you want to use a SCSI or FireWire CD-ROM under Linux,
> >> +If you want to use a SCS
On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
> - If you want to use a SCSI or FireWire CD-ROM under Linux,
> + If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
> say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
>
On Fri, Sep 14, 2007 at 06:01:53PM +0200, Stefan Richter wrote:
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
>
> Applicable to 2.6.23-rc6 and to scsi-misc.
>
> drivers/scsi/Kconfig | 32
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
>
On Fri, Sep 14, 2007 at 10:50:24AM +0200, Wojciech Kromer wrote:
> I can't see whole 8GB of ram.
>
> With F2 BIOS release i can only work with kernel param mem=4G.
> After updating to F4 BIOS release I can work with mem=8G, but I see this:
>
> # free -m
> total used free
On Fri, Sep 14, 2007 at 10:50:24AM +0200, Wojciech Kromer wrote:
I can't see whole 8GB of ram.
With F2 BIOS release i can only work with kernel param mem=4G.
After updating to F4 BIOS release I can work with mem=8G, but I see this:
# free -m
total used free
On Fri, Sep 14, 2007 at 06:01:53PM +0200, Stefan Richter wrote:
Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
Applicable to 2.6.23-rc6 and to scsi-misc.
drivers/scsi/Kconfig | 32
1 file changed, 20 insertions(+), 12 deletions(-)
Index:
On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
- If you want to use a SCSI or FireWire CD-ROM under Linux,
+ If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
On Fri, Sep 14, 2007 at 11:06:44PM +0200, Stefan Richter wrote:
On 14 Sep, Lennart Sorensen wrote:
On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
-If you want to use a SCSI or FireWire CD-ROM under Linux,
+If you want to use a SCSI, SATA, USB or FireWire CD-ROM
On Thu, Sep 13, 2007 at 01:31:39PM -0700, Venkat Subbiah wrote:
> Doing it in a round-robin fashion will be disastrous for performance.
> Your cache miss rate will go through the roof and you'll hit the slow
> paths in the network stack most of the time.
> > Most of the work in my system is spent
On Thu, Sep 13, 2007 at 01:31:39PM -0700, Venkat Subbiah wrote:
Doing it in a round-robin fashion will be disastrous for performance.
Your cache miss rate will go through the roof and you'll hit the slow
paths in the network stack most of the time.
Most of the work in my system is spent in
On Wed, Sep 12, 2007 at 10:27:16AM +0100, Christoph Hellwig wrote:
> On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
> > As an example, visws.c is as much non-64bit as it is pre-i686.
>
> Bullshit. visws were shipped with P3s.
Certainly true, but still not 64bit and never will be.
On Wed, Sep 12, 2007 at 10:27:16AM +0100, Christoph Hellwig wrote:
On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
As an example, visws.c is as much non-64bit as it is pre-i686.
Bullshit. visws were shipped with P3s.
Certainly true, but still not 64bit and never will be.
--
On Thu, Aug 30, 2007 at 05:16:46PM -0400, Greg Freemyer wrote:
> USB / Firewire / FC / iSCSI are all SCSI transports and fit within the
> SCSI subsystem by design.
>
> ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no
> conceptual conflict, many media by design carry SCSI
On Thu, Aug 30, 2007 at 09:38:23PM +0200, Jan Engelhardt wrote:
> Hard to tell, since some (most?) laptops have sort of a backplane and there
> might be no real cable you could see because it's all mainboard wire paths
> already.
Makes you wonder why the mainboard doesn't just pretend to be an 80
On Thu, Aug 30, 2007 at 09:31:14PM +0200, Jan Engelhardt wrote:
> Welcome to the wonderful world of SCSIfying ATA. (Don't talk about
> ATAPI, USB/Firewire, it's a different matter.)
I guess eventually all disks will appear the same, just like on BSD and
many other systems (probably most other
On Thu, Aug 30, 2007 at 09:31:14PM +0200, Jan Engelhardt wrote:
Welcome to the wonderful world of SCSIfying ATA. (Don't talk about
ATAPI, USB/Firewire, it's a different matter.)
I guess eventually all disks will appear the same, just like on BSD and
many other systems (probably most other
On Thu, Aug 30, 2007 at 09:38:23PM +0200, Jan Engelhardt wrote:
Hard to tell, since some (most?) laptops have sort of a backplane and there
might be no real cable you could see because it's all mainboard wire paths
already.
Makes you wonder why the mainboard doesn't just pretend to be an 80
On Thu, Aug 30, 2007 at 05:16:46PM -0400, Greg Freemyer wrote:
USB / Firewire / FC / iSCSI are all SCSI transports and fit within the
SCSI subsystem by design.
ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no
conceptual conflict, many media by design carry SCSI traffic.
On Thu, Aug 23, 2007 at 01:56:35PM +0200, Espen M. Rutger wrote:
> I got problems with the IDE code which causes the kernel to freez after
> printing out:
>
> hda: status timeout: status=0xd0 { Busy }
>
> kernel used: 2.4.18 crosscompiled with Montavista tools (ppc_82xx-gcc
> (GCC) 3.2.1
On Thu, Aug 23, 2007 at 01:56:35PM +0200, Espen M. Rutger wrote:
I got problems with the IDE code which causes the kernel to freez after
printing out:
hda: status timeout: status=0xd0 { Busy }
kernel used: 2.4.18 crosscompiled with Montavista tools (ppc_82xx-gcc
(GCC) 3.2.1 20020930
On Thu, Aug 23, 2007 at 10:44:55PM -0400, TheOneKEA wrote:
> While doing a long mega-copy from one side of a DVD-RAM disc formatted
> with the vfat filesystem to an smbfs network share, I got lots and
> lots of these in the dmesg:
No idea about the error, but isn't vfat torture of a dvd-ram?
On Thu, Aug 23, 2007 at 10:44:55PM -0400, TheOneKEA wrote:
While doing a long mega-copy from one side of a DVD-RAM disc formatted
with the vfat filesystem to an smbfs network share, I got lots and
lots of these in the dmesg:
No idea about the error, but isn't vfat torture of a dvd-ram? Don't
On Wed, Aug 22, 2007 at 05:48:52PM +0200, Rene Herman wrote:
> He has a SATA harddrive and an IDE DVD drive. When he compiles with
> CONFIG_ATA_PIIX (a driver which advertises both SATA and PATA in its
> description) his drive works, his DVD does not. Is that not the correct
> driver? Does he
On Wed, Aug 22, 2007 at 05:48:52PM +0200, Rene Herman wrote:
He has a SATA harddrive and an IDE DVD drive. When he compiles with
CONFIG_ATA_PIIX (a driver which advertises both SATA and PATA in its
description) his drive works, his DVD does not. Is that not the correct
driver? Does he need
On Tue, Aug 21, 2007 at 07:12:53PM +0200, Marco Aicardi wrote:
> [1.] One line summary of the problem:
>
> Unable to burn DVD with the Asus M2NPV mainboard
>
> [2.] Full description of the problem/report:
>
> I have recently changed my mainboard to a Asus M2NPV-VM one;
On Tue, Aug 21, 2007 at 07:12:53PM +0200, Marco Aicardi wrote:
[1.] One line summary of the problem:
Unable to burn DVD with the Asus M2NPV mainboard
[2.] Full description of the problem/report:
I have recently changed my mainboard to a Asus M2NPV-VM one; nothing
On Mon, Aug 20, 2007 at 04:18:21AM -0700, Marc Perkel wrote:
> Look at the reality of the situation. Linux is free
> and yey it can't compete with operating systems that
> are paid for. Maybe the reason is that when someone
> point out the something is broken all yopu get is
> justification and
On Sat, Aug 18, 2007 at 09:07:05PM -0700, Marc Perkel wrote:
> No Al, there isn't any shortage of arrogance here.
Yes you provide plenty yourself.
> Let me try to repeat what I'm talking about as simply
> as I can.
>
> First - I'm describing a kind of functionality and
> suggesting Linux should
On Sat, Aug 18, 2007 at 09:07:05PM -0700, Marc Perkel wrote:
No Al, there isn't any shortage of arrogance here.
Yes you provide plenty yourself.
Let me try to repeat what I'm talking about as simply
as I can.
First - I'm describing a kind of functionality and
suggesting Linux should have
On Mon, Aug 20, 2007 at 04:18:21AM -0700, Marc Perkel wrote:
Look at the reality of the situation. Linux is free
and yey it can't compete with operating systems that
are paid for. Maybe the reason is that when someone
point out the something is broken all yopu get is
justification and excuses
On Wed, Aug 15, 2007 at 01:44:50PM -0700, Marc Perkel wrote:
> Yes - that's a good example. Git is far more powerful
> and a different paradigm for CVS. Someone had to think
> outside the box and come up with a new way of looking
> at things. I'm trying to do something like that with
> this idea.
On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote:
> When one thinks outside the box one has to think about
> evolving beyond what you are used to. When I moved
> beyond DOS I have to give up the idea of 8.3 file
> names. The idea here is to come up with a model that
> can emulate the
On Wed, Aug 15, 2007 at 10:09:31AM -0700, Marc Perkel wrote:
> Yep - way outside the box - and thus the title of the
> thread.
>
> The idea is that people have permissions - not files.
> By people I mean users, groups, managers, applications
> etc. One might even specify that there are no
>
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
> This jumped out at me right away. In such a system, an attacker with
> write permissions on a "sticky" directory like /tmp could probe for
> others' files by attempting to create them and recording all cases where
> permission was
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
This jumped out at me right away. In such a system, an attacker with
write permissions on a sticky directory like /tmp could probe for
others' files by attempting to create them and recording all cases where
permission was denied
On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote:
When one thinks outside the box one has to think about
evolving beyond what you are used to. When I moved
beyond DOS I have to give up the idea of 8.3 file
names. The idea here is to come up with a model that
can emulate the
On Wed, Aug 15, 2007 at 10:09:31AM -0700, Marc Perkel wrote:
Yep - way outside the box - and thus the title of the
thread.
The idea is that people have permissions - not files.
By people I mean users, groups, managers, applications
etc. One might even specify that there are no
permission
On Wed, Aug 15, 2007 at 01:44:50PM -0700, Marc Perkel wrote:
Yes - that's a good example. Git is far more powerful
and a different paradigm for CVS. Someone had to think
outside the box and come up with a new way of looking
at things. I'm trying to do something like that with
this idea.
To
On Fri, Aug 10, 2007 at 04:28:19PM +0400, Brad Campbell wrote:
> I'm building a bit of hardware. It's basically a serial multiplexer that
> communicates to the PC using a single usb-serial port. It has the ability
> to run between 2 and 8 standard async ports over this single interface.
>
> I'd
On Fri, Aug 10, 2007 at 04:28:19PM +0400, Brad Campbell wrote:
I'm building a bit of hardware. It's basically a serial multiplexer that
communicates to the PC using a single usb-serial port. It has the ability
to run between 2 and 8 standard async ports over this single interface.
I'd
On Thu, Aug 02, 2007 at 07:46:49AM -0700, Marc Perkel wrote:
> OK - so the driver I downloaded from nVidia to fix
> their problem I was having with the video installed
> drivers for everything? I'm really getting to dislike
> nVidia.
It installs a kernel module just for the video card. Nothing
On Thu, Aug 02, 2007 at 07:46:49AM -0700, Marc Perkel wrote:
OK - so the driver I downloaded from nVidia to fix
their problem I was having with the video installed
drivers for everything? I'm really getting to dislike
nVidia.
It installs a kernel module just for the video card. Nothing else.
On Tue, Jul 31, 2007 at 05:08:19PM -0400, Cal Peake wrote:
> On Mon, 30 Jul 2007, Brian D. McGrew wrote:
>
> > Using FC5 with a 2.6.15 kernel my system (Dell Optiplex) see both
> > drives.
> >
> > Using the 2.6.16.16 kernel that I've built I see no CD-ROM drives.
> >
> > What could I have
On Mon, Jul 30, 2007 at 08:17:18PM -0400, Joe Korty wrote:
> Add missing IRQs and IRQ descriptions to /proc/interrupts.
>
> /proc/interrupts is most useful when it displays every
> IRQ vector in use by the system, not just those somebody
> thought would be interesting.
>
> This patch inserts the
On Tue, Jul 31, 2007 at 05:08:19PM -0400, Cal Peake wrote:
On Mon, 30 Jul 2007, Brian D. McGrew wrote:
Using FC5 with a 2.6.15 kernel my system (Dell Optiplex) see both
drives.
Using the 2.6.16.16 kernel that I've built I see no CD-ROM drives.
What could I have missed in the
On Mon, Jul 30, 2007 at 08:17:18PM -0400, Joe Korty wrote:
Add missing IRQs and IRQ descriptions to /proc/interrupts.
/proc/interrupts is most useful when it displays every
IRQ vector in use by the system, not just those somebody
thought would be interesting.
This patch inserts the
On Fri, Jul 20, 2007 at 09:58:50AM -0400, Justin Piszcz wrote:
> I have a multi-core Q6600 CPU on a 10-disk Raptor RAID 5 running XFS.
>
> I just pulled down the Debian Etch 4.0 DVD ISO's, one for x86 and one for
> x86_64, when I ran md5sum -c MD5SUMS, I see ~280-320MB/s. When I ran the
>
On Fri, Jul 20, 2007 at 09:58:50AM -0400, Justin Piszcz wrote:
I have a multi-core Q6600 CPU on a 10-disk Raptor RAID 5 running XFS.
I just pulled down the Debian Etch 4.0 DVD ISO's, one for x86 and one for
x86_64, when I ran md5sum -c MD5SUMS, I see ~280-320MB/s. When I ran the
second
On Thu, Jul 19, 2007 at 04:38:09PM +0300, Avi Kivity wrote:
> Looking at two random servers here and a desktop, interrupts are
> unshared except for usb. A laptop was not so lucky. So "no chance" is
> a bit extreme.
>
> I agree it's far from optimal, but it is less limited than you imply.
On Thu, Jul 19, 2007 at 12:23:24PM +0300, Avi Kivity wrote:
> No, it means disallowing pci devices that use shared irqs, and allowing
> pci devices that use non-shared irqs.
Most machiens I see today have almost no chance of having PCI devices
without shared IRQs. This probably means any
On Thu, Jul 19, 2007 at 12:23:24PM +0300, Avi Kivity wrote:
No, it means disallowing pci devices that use shared irqs, and allowing
pci devices that use non-shared irqs.
Most machiens I see today have almost no chance of having PCI devices
without shared IRQs. This probably means any
On Thu, Jul 19, 2007 at 04:38:09PM +0300, Avi Kivity wrote:
Looking at two random servers here and a desktop, interrupts are
unshared except for usb. A laptop was not so lucky. So no chance is
a bit extreme.
I agree it's far from optimal, but it is less limited than you imply.
Well with
On Wed, Jul 18, 2007 at 07:46:13PM +0300, Avi Kivity wrote:
> IMO the only reasonable solution is to disallow interrupt forwarding
> with shared irqs. If someone later comes up with a bright idea, we can
> implement it. Otherwise the problem will solve itself with hardware
> moving to msi.
On Wed, Jul 18, 2007 at 12:53:19PM +0300, Or Sagi wrote:
> Gentlepeople,
>
> We're currently working on PCI device pass-through support for KVM. In this
> model all physical hardware access to specific devices will be performed by
> the VM, and not by the host.
>
> In particular, this requires
On Wed, Jul 18, 2007 at 12:53:19PM +0300, Or Sagi wrote:
Gentlepeople,
We're currently working on PCI device pass-through support for KVM. In this
model all physical hardware access to specific devices will be performed by
the VM, and not by the host.
In particular, this requires
401 - 500 of 986 matches
Mail list logo
