On 16 May 2001 01:56:23 +0200, Tim Jansen wrote:
> On Wednesday 16 May 2001 01:16, David Brownell wrote:
> >Only if it's augmented by additional device IDs, such as the
> >"what 's the physical connection for this interface" sort of
> >primitive that's been mentioned.
> >[...]
> > I suppose that
Jeff Garzik writes:
> "Khachaturov, Vassilii" wrote:
>> Can someone please confirm if my assumptions below are correct:
>> 1) Unless someone specifically tampered with my driver's device
>> since the OS bootup, the mapping of the PCI base address registers
>> to virtual memory will remain the
Please CC replies as I'm not subscribed.
I seem to be having some problems with sound ioctl's.
I've attached a short c file that opens /dev/dsp, prints the fd, tries
to issue SNDCTL_DSP_NONBLOCK ioctl, then does the same with /dev/audio.
Both calls to ioctl for NONBLOCK yield Invalid Invalid
I just patched my 2.2.18 kernel. After I did a make dep I got the
following message. Any ideas what does this mean?
md5sum: WARNING: 11 of 12 computed checksums did NOT match
Joe Acosta
home: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, May 16, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote:
> > Could you try this patch? It applies on top of 2.2.20pre1
> >
> > It also cleans up a couple of comments
>
> That fixes it alright.
Excellent. Alan, could you
Hello
I have been trying to get 2.4.x to boot on my machine for sometime. I
finally got ac9 to boot today but I had to change the Processor Opts
from Athlon/K7/etc to PII/Celeron. I am running on an Iwill KK266 board
with a duron 800, 384 megs of RAM, SB Live X-Gamer, Adaptec 2910 and
2940UW,
First this my configuration:
Kernel 2.4.4 / Athlon 650
May 17 05:38:45 m kernel: hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
May 17 05:38:45 m kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
May 17 05:38:45 m kernel: ide1 at 0x170-0x177,0x376 on irq 15
May 17 05:38:45 m kernel: hda: 60036480
OK, I know this is bizarre and probably some goof on my part, but it
is just too weird for me to guess at further:
My program write()s 2- and 4- byte chunks or data to a file (for a WAV
header). When the data being written contains an 0xff byte, it is
apparently written to disk as 2 bytes:
[EMAIL PROTECTED] wrote:
[lots of sensible comments to get this discussion "on track"]
> So we have: user space has file names and uses open() or mount().
> Kernel space has device paths.
>
> In principle the kernel could just number the devices it sees 1,2,...
> and export information about
Linus, I've done a bit more cleaning the device initialization
up (beginning of chr_dev_init()) and results were, well, interesting.
a) I2C stuff got converted to module_init() nicely. That took
a lot of cruft away.
b) init order is preserved. However, that worked only
Julian Anastasov wrote:
>
> eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
This is a failure of the APIC interrupt controller in
the 2.4 kernel. You'll need to boot your kernel with
the `noapic' LILO option. Or run -ac kernels, which
have a software workaround
On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote:
>
> Could you try this patch? It applies on top of 2.2.20pre1
>
> It also cleans up a couple of comments
That fixes it alright.
Shane
--
Shane Wegner: [EMAIL PROTECTED]
http://www.cm.nu/~shane/
PGP:
Followup to: <[EMAIL PROTECTED]>
By author:Felix von Leitner <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I can't copy a file larger than 2 gigs to my vfat partition.
> What gives? 2.4.4-ac5 kernel. My cp copies 2 gigs and then aborts.
>
> $ echo foo >> file_on_vfat_partition
I have been happily accumulating some files on an 80GB Maxtor HD sitting on
/dev/hdg mounted as /arc. There are 2 other drives on the HPT370 (KA7-100
MB with TY Bios) and 2 on the main mother board IDE controller. The system
is currently running 2.4.3-ac14. It has been solid as a rock and I
Hello,
This is known issue. cmpci driver included in the kernel is way too old.
I'm using newer driver (revision 4.14) and it works just fine. It was
announced on lkml long time ago. Last time I checked there was even newer
driver - 5.64. The one in the kernel has version 2.41. Is it possible
I can't copy a file larger than 2 gigs to my vfat partition.
What gives? 2.4.4-ac5 kernel. My cp copies 2 gigs and then aborts.
$ echo foo >> file_on_vfat_partition
causes the shell to become unresponsive and consume lots of CPU time.
Felix
-
To unsubscribe from this list: send the line
Just a "me, too" here. I see this when using the in-kernel driver. I'm
now using... 4.12, I think. At any rate, the error doesn't occur, or at
least occurs to rarely as to escape notice, with this driver. Might I
suggest the kernel's version be upgraded? The updated driver was posted
here on
Gerard, LKML
The attached patch tweaks the sym53c8xx timeout timer handling a bit.
Is it correct?
It works with interrupts off (we need a reboot notifier to iterate the
hosts list, with IRQs off) and doesn't delay() 5 seconds in worst case.
Is there any reason this patch won't work? It seems
To inject a bit of concrete into this discussion, I note that block
devices with dynamically assigned don't work with CONFIG_DEVFS and
devfs=only. Block devices -require- majors currently, due to those
!@#!@# arrays. However, devfs_register_blkdev always returns zero when
devfs=only, even if
On Thu, May 17, 2001 at 12:26:12AM +0100, Alan Cox wrote:
> > Are FireWire (and USB) disks always detected in the same order? Or does it
> > behave like ADB, where you never know which mouse/keyboard is which
> > mouse/keyboard?
>
> USB disks are required (haha etc) to have serial numbers.
[EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote:
> In principle the kernel could just number the devices it sees 1,2,...
> and export information about them, so that user space can choose
> the right number.
> The part about exporting information is good. User space needs to
> be able to ask if a
> Yes, it's broken if someone writes a cabbage dicer driver and uses
> "cd" as the leaf node name for devfs.
>
> Yes, it's broken if someone writes a cabbage dicer driver and uses
> the same major as the IDE CD-ROM or SCSI CD-ROM drivers.
The difference is one is a kernel interface magic cookie
> > USB disks are required (haha etc) to have serial numbers. Firewire similarly
> > has unique disk identifiers.
>
> How about for other device classes?
Keyboards and mice dont which is a real pig because it prevents you using
dual head, two usb keyboards and 2 usb mice for a dual user box
On Wed, May 16, 2001 at 08:25:56PM +0300, Jussi Laako wrote:
> I tested 2.4.4-ac9 today on A7V133 machine. It booted up, but can't stand
> any load. It will deadlock (without oops) when the network/disk system faces
> any load.
>
reset/clear CMOS with jumper. I get this kind of instability each
> when this happened, and I was not able to log in onto any console or
> terminal afterwards (probably because tty_open failed very miserably
> on the way?)
Its a deliberate debugging trap.
> #if DEBUG
> if (cachep->flags & SLAB_POISON)
> if
> How well has the problem been nailed down? Could it be that it just
> showed up first on VIA and the real cause (and fix) remains to be
> discovered? Or does Serverworks somehow have an identical bug in
> their chipset?
There is a notional off by one in the check at least by the rules of the
On Wed, May 16, 2001 at 08:05:38AM -0700, siva prasad wrote:
> Is it true that the ipc calls like
> msgget(),shmget()...
> are not really system calls?
No, they all use a system call, but the system call is the same for all
functions.
> Cos in the file "asm/unistd.h" where the
> system calls
The LANANA discussion has forked into a forest of vaguely related
discussions. If I am not mistaken the only real question is
how user space and kernel space communicate device identities.
Here "user space" is very different from "users".
Devices have a device path and device contents.
For the
> Please throw any comments, questions, suggestions, hard objects this way...
First obvious comments
+ while (uCount-- != 0) {
+ unsigned short val_lo, val_hi;
+ cli();
+ val_lo = InWordDsp(DSP_MsaDataISLow);
+ val_hi =
Richard Gooch wrote:
>
> Alan Cox writes:
> > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > match. No wonder people seemed to be missing the point. So the line of
> > > code I actually meant was:
> > > if (strcmp (buffer + len - 3, "/cd") != 0) {
> >
> >
On Thu, 17 May 2001, Alan Cox wrote:
> > Linus, patch is the first chunk of rootfs stuff. I've tried to
> > get it as small as possible - all it does is addition of absolute root
> > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
> > and follow_dotdot. Real root is
hpa wrote:
>
> Alan Cox wrote:
> >
> > > Are FireWire (and USB) disks always detected in the same
> > > order? Or does it
> > > behave like ADB, where you never know which
> > > mouse/keyboard is which mouse/keyboard?
> >
> > USB disks are required (haha etc) to have serial numbers.
> >
Richard Gooch wrote:
>
> OK. How do you figure on dealing with the problem of multiple
> high-level drivers talking to the same device? How does sr.o "know"
> that this is also a CD-RW? How does sg.o "know" that this is also a
> tape?
>
At some point something talks to the device -- in this
Alan Cox writes:
> > Argh! What I wrote in text is what I meant to say. The code didn't
> > match. No wonder people seemed to be missing the point. So the line of
> > code I actually meant was:
> > if (strcmp (buffer + len - 3, "/cd") != 0) {
>
> drivers/kitchen/bluetooth/vegerack/cd
>
>
> Argh! What I wrote in text is what I meant to say. The code didn't
> match. No wonder people seemed to be missing the point. So the line of
> code I actually meant was:
> if (strcmp (buffer + len - 3, "/cd") != 0) {
drivers/kitchen/bluetooth/vegerack/cd
its the cabbage dicer still ..
-
On Wed, 16 May 2001, H. Peter Anvin wrote:
> Alan Cox wrote:
> >
> > > Are FireWire (and USB) disks always detected in the same order? Or does it
> > > behave like ADB, where you never know which mouse/keyboard is which
> > > mouse/keyboard?
> >
> > USB disks are required (haha etc) to have
> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
> -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs
> -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs
> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
> -rw-r--r--1 cr users 141452 Mai 16
> I tested 2.4.4-ac9 today on A7V133 machine. It booted up, but can't stand
> any load. It will deadlock (without oops) when the network/disk system faces
> any load.
Let me guess 'ide=nodma' fixes that ?
> There is also some new bug in VIA IDE driver. It misdetects cable as 80-w
> when it's
> i'm guessing from your description that the missed event will be noticed
> when the next socket arrives. i.e. if the server is pretty busy then the
> missed events are not important. but if it's not a busy server, like a
> hit every hour, then the missed event may be noticeable to browsers
[Cc: list trimmed because I figure people are getting tired of us:-]
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > H. Peter Anvin writes:
> > > Richard Gooch wrote:
> > > >
> > > > Erm, let's start again. My central point is that you can use devfs
> > > > names to reliably figure out
On Thu, 17 May 2001, Alan Cox wrote:
>
> > Are FireWire (and USB) disks always detected in the same order? Or does it
> > behave like ADB, where you never know which mouse/keyboard is which
> > mouse/keyboard?
>
> USB disks are required (haha etc) to have serial numbers. Firewire similarly
>
Richard Gooch wrote:
>
> H. Peter Anvin writes:
> > Richard Gooch wrote:
> > >
> > > Erm, let's start again. My central point is that you can use devfs
> > > names to reliably figure out what kind of device a FD is, as a cleaner
> > > alternative to comparing major numbers. Therefore, I'm
> Whenever I boot (2.4.4-ac6) I get this error message if there is a zip
> disk in the drive.
Does it work with ide-scsi ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> > code and your new release _before_ you do that.
>
> The new code *can* automagically read and deal with 0.8 created VGDAs.
> What are you refering too in detail here?
Yes. This is good
The important thing is that the external interface and on disk format dont
break - the code can be
> Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a
> minimal _example_ fs. There was some agreement that this should stay
> so.
I think ramfs is an incredibly flawed example right now - precisely because
it has no error cases. ramfs with the size limiting is a brilliant fs
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > Erm, let's start again. My central point is that you can use devfs
> > names to reliably figure out what kind of device a FD is, as a cleaner
> > alternative to comparing major numbers. Therefore, I'm challenging the
> > notion that you need
H. Peter Anvin writes:
> Richard Gooch wrote:
> > We have this aliasing anyway. sg and sr are just one example. If you
> > care about conflicts, then make sure the drivers lock each other out.
> > It's got nothing to do with the mechanism to find out whether
> > something can behave like a CD-ROM
Richard Gooch wrote:
>
> Erm, let's start again. My central point is that you can use devfs
> names to reliably figure out what kind of device a FD is, as a cleaner
> alternative to comparing major numbers. Therefore, I'm challenging the
> notion that you need to reserve magic major numbers in
> Linus, patch is the first chunk of rootfs stuff. I've tried to
> get it as small as possible - all it does is addition of absolute root
> on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
> and follow_dotdot. Real root is mounted atop of the "absolute" one.
Surely
> One else case in wd7000.c did not have a release_region().
Most of these are fixed in -ac and have been for a while. Im not sure if this
one is but do double check the -ac patches for these. I've yet to have
Linus bandwidth to feed them all on
-
To unsubscribe from this list: send the line
> hm, page 0009f000 reserved twice.
> hm, page 000a reserved twice.
> WARNING: MP table in the EBDA can be UNSAFE
These are ok...
> ENABLING IO-APIC IRQs
> ...changing IO-APIC physical APIC ID to 14 ... ok.
> BIOS bug, IO-APIC#1 ID is 15 in the MPC table!...
> ... fixing up to 15. (tell
Alan Cox wrote:
>
> > Are FireWire (and USB) disks always detected in the same order? Or does it
> > behave like ADB, where you never know which mouse/keyboard is which
> > mouse/keyboard?
>
> USB disks are required (haha etc) to have serial numbers. Firewire similarly
> has unique disk
I have tcl/tk8.3.2 installed and make xconfig (for both 2.2.18 and 2.4.2)
just hang. I've been told by the listed maintainer that a new GUI is on its
way and the existing make xconfig is orphaned, but this does not solve the
immediate problem.
I have therefore fixed this problem myself and
On Wed, 16 May 2001, H. Peter Anvin wrote:
> Alexander Viro wrote:
> >
> > In full variant of patch I don't _have_ mount_root(9). It's done by
> > mount(2). Period. Initrd or not. Notice that rootfs stays absolute root
> > forever - it's much more convenient for fs/super.c, since you can get
Richard Gooch wrote:
>
> H. Peter Anvin writes:
> > Ingo Oeser wrote:
> > >
> > > We do this already with ide-scsi. A device is visible as /dev/hda
> > > and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda,
> > > /dev/sr0 and /dev/sg0.
> > >
> > > All at the same time.
> > >
> >
> > ...
> May 13 14:24:41 sunny kernel: PCI: Found IRQ 10 for device 00:0e.0
> May 13 14:24:41 sunny kernel: PCI: The same IRQ used for device 00:0a.0
> "0e" is my PCI sound card, and "0a" is my PCI ethernet card. The messages apppear in
> the following environment: I send from another
> Are FireWire (and USB) disks always detected in the same order? Or does it
> behave like ADB, where you never know which mouse/keyboard is which
> mouse/keyboard?
USB disks are required (haha etc) to have serial numbers. Firewire similarly
has unique disk identifiers.
-
To unsubscribe from
Alexander Viro wrote:
>
> In full variant of patch I don't _have_ mount_root(9). It's done by
> mount(2). Period. Initrd or not. Notice that rootfs stays absolute root
> forever - it's much more convenient for fs/super.c, since you can get rid
> of many kludges that way. So I'm not too happy
> Woopsthis is for 2.4.5-pre2
I guessed - its ok by default in -ac because I do a test build with everything
I can build built as modules
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jonathan Lundell wrote:
>
> At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote:
> >This is not a safe assumption, because the OS may reprogram the PCI BARs
> >at certain times. The rule is: ALWAYS read from dev->resource[] unless
> >you are a bus driver (PCI bridges, for example, need to assign
>
At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote:
>This is not a safe assumption, because the OS may reprogram the PCI BARs
>at certain times. The rule is: ALWAYS read from dev->resource[] unless
>you are a bus driver (PCI bridges, for example, need to assign
>resources).
Would you please
H. Peter Anvin writes:
> Ingo Oeser wrote:
> >
> > We do this already with ide-scsi. A device is visible as /dev/hda
> > and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda,
> > /dev/sr0 and /dev/sg0.
> >
> > All at the same time.
> >
>
> ... and if you don't know about this funny
On 16 May 2001, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Alexander Viro <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Well, since all I actually use in the full variant of patch is sys_mknod(),
> > sys_chdir() and sys_mkdir()... IMO tmpfs is an
Hello people,
I triggered an "invalid operand" oops in linux-2.4.4-ac9 today, and could
trace it back to the line mm/slab.c:1244. I did nothing really special
when this happened, and I was not able to log in onto any console or
terminal afterwards (probably because tty_open failed very miserably
On Wed, 16 May 2001, virii wrote:
> The attatched file is the format for reporting bugs.
Too bad my mailreader doesn't quote that thing .. oh well, lets
just replace your bugreport with mine ;)
I'm seeing a similar thing on 2.4.4-pre[23], but in a far less
serious way. Using xmms the music
Four adapters need to produce data to a
descriptor queue which is consumed by a
user process. A lock mechanism was implemented
to sync the adapters. However, this causes
a performance hit. Is it possible to use
CMPXCHG on Intel's i-386 to avoid the locking?
Where can I find some doc and some
The attatched file is the format for reporting bugs.
1) While playing mp3's on mpg123 it'll lock up for 3/4 seconds, and XMMS just stops
all together
2) May 16 05:46:10 virii kernel: cmpci: dma timed out??
May 16 06:05:43 virii kernel: cmpci: write: chip lockup? dmasz 65536 fragsz 1024
On Wed, May 16 2001, H. Peter Anvin wrote:
> Ingo Oeser wrote:
> >
> > We do this already with ide-scsi. A device is visible as /dev/hda
> > and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda,
> > /dev/sr0 and /dev/sg0.
> >
> > All at the same time.
> >
>
> ... and if you don't know
Followup to: <[EMAIL PROTECTED]>
By author:Alexander Viro <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Well, since all I actually use in the full variant of patch is sys_mknod(),
> sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we
> really need minimal rootfs
Jeff,
Many thanks for the clarifications.
> From: Jeff Garzik
> "Khachaturov, Vassilii" wrote:
[snip]
> > bootup, the mapping of the PCI base address registers to
> virtual memory will
> > remain the same (just as seen in /proc/pci, and as
> reflected in )? If
> > not, is there a way to freeze
Ingo Oeser wrote:
>
> We do this already with ide-scsi. A device is visible as /dev/hda
> and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda,
> /dev/sr0 and /dev/sg0.
>
> All at the same time.
>
... and if you don't know about this funny aliasing, you get screwed.
This is BAD DESIGN,
Anyone know where Ted Tso is? He hasn't posted in several weeks.
Alan, will you put this in -ac? This patch fixes a bug in serial.c
that causes a crash on machines with a ST16C654.
On Tue, May 15, 2001 at 09:52:01AM -0400, Stuart MacDonald wrote:
> Kernel version? Distribution? Are you using
On Wed, May 16, 2001 at 02:36:44PM -0700, H. Peter Anvin wrote:
> > But all devices which export a CD-ROM interface will do so. So the
> > device node that is associated with the CD-ROM driver will export
> > CD-ROM semantics, and the trailing name will be "/cd".
> >
> > Other interfaces a
I'm getting messages saying "clock timer configuration lost - probably
a VIA686a" from 2.2.19 running on a board using the Serverworks HE
chipset. Reading the list archives it sounds like this problem has
previously been attributed to a possible bug in the VIA chipset.
According to RedHat's
Michael Meissner writes:
> On Tue, May 15, 2001 at 01:18:09PM -0700, Linus Torvalds wrote:
> > This is what we have now. Network devices are called "eth0..N", and nobody
> > is complaining about the fact that the numbering is basically random. It
> > is _repeatable_ as long as you don't change
"Khachaturov, Vassilii" wrote:
> Can someone please confirm if my assumptions below are correct:
> 1) Unless someone specifically tampered with my driver's device since the OS
> bootup, the mapping of the PCI base address registers to virtual memory will
> remain the same (just as seen in
Richard Gooch wrote:
> >
> > Because you are now, once again, tying two things that are
> > completely and utterly unrelated: device classification and device
> > name. It breaks every time someone comes out with a new device
> > which is "kind of like an old device, but not really," like
> >
Please CC replies as I'm not subscribed.
I seem to be having some problems with sound ioctl's.
I've attached a short c file that opens /dev/dsp, prints the fd, tries
to issue SNDCTL_DSP_NONBLOCK ioctl, then does the same with /dev/audio.
Both calls to ioctl for NONBLOCK yield Invalid Invalid
Can someone please confirm if my assumptions below are correct:
1) Unless someone specifically tampered with my driver's device since the OS
bootup, the mapping of the PCI base address registers to virtual memory will
remain the same (just as seen in /proc/pci, and as reflected in )? If
not, is
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > H. Peter Anvin writes:
> > > Richard Gooch wrote:
> > > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > > match. No wonder people seemed to be missing the point. So the line of
> > > > code I actually meant was:
> >
Linus, please apply the patch below (device_init as initcall).
BTW, if -pre3 didn't break the init sequence I would be very surprised -
chr_dev_init() is moved _way_ past the other device initialization stuff.
Al
diff -urN
Fixed in the current sources, this was already fixed in 2.4.x
Later,
David S. Miller
[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
> I tried porting a network driver from kernel2.2.x to
> 2.4. When i tried loading the driver, it shows the
> unresolved symbols for
> copy_to_user_ret
if(copy_to_user(...))
return -EFAULT
> outs
Has not gone away, your includes are wrong
> __bad_udelay
> I don't mean to suggest that ioctls be used to deduce device types
> (except in the case of overlapping ioctl numbers, which shouldn't be
> all *that* common (I hope)). I mean to suggest that the question
> "What device type are you?" usually shouldn't even be asked!
But people need to ask
Subject says it all...
The patch is the driver portion for the Mwave applied against the 2.4.4
kernel proper..
It was a little big to send directly to the list.. So... You'll be able
to pick it up at http://www.ibm.com/linux/ltc/ shortly.. Until it goes up
there, it will be available at
Linus Torvalds writes:
>
> On Wed, 16 May 2001, Richard Gooch wrote:
> > >
> > > This is still a really bad idea. You don't want to tie this kind of
> > > things to the name.
> >
> > Why do you think it's a bad idea?
>
> Well, one reason names are bad is that they don't always exist.
>
> If
> I wonder if DFI has a bios or chipset patch available and whether that would
> help ?
> Maybe disabling the VIA chipset support in the kernel and running generic
> drivers would help ?
Play with ideas see what you find out. You might strike lucky. So far nobody
else has
-
To unsubscribe from
Last time I checked (that was 5 minutes ago :-) )only the last two ones
were supported...
On Wed, May 16, 2001 at 01:16:50PM -0700, James Simmons wrote:
>
> > On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote:
> > > > Did you ever try grub?? This a gnu project, a boot-loader, with
On Wed, 16 May 2001, Richard Gooch wrote:
> >
> > This is still a really bad idea. You don't want to tie this kind of
> > things to the name.
>
> Why do you think it's a bad idea?
Well, one reason names are bad is that they don't always exist.
If you only have the fd (remember that unix
As announced 3 weeks ago, we have set up external CVS write access now.
We hereby kindly invite major contributors like Andreas Dilger to join in :-)
In order to set an account up, please send your address information
(including postal, e-mail, phone and fax contacts) to me.
We reserve the
> On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote:
> > > Did you ever try grub?? This a gnu project, a boot-loader, with an embedded
> > > shell... You can read ext2fs and select, your kernel, your root disk, your
> > > params, etc...
> >
> > Yes I have tried it. Pretty cool. The
Hello,
we are experiencing deadlocks when running the RedHat stress test
suite. The test case is basically compiling a kernel on a file
system mounted via NFS from localhost (while this is obviously not
particularly sensible, it should nevertheless work ...), while
putting memory pressure on
On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote:
> > Did you ever try grub?? This a gnu project, a boot-loader, with an embedded
> > shell... You can read ext2fs and select, your kernel, your root disk, your
> > params, etc...
>
> Yes I have tried it. Pretty cool. The only thing
Richard Gooch wrote:
>
> H. Peter Anvin writes:
> > Richard Gooch wrote:
> > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > match. No wonder people seemed to be missing the point. So the line of
> > > code I actually meant was:
> > > if (strcmp (buffer + len -
> > I very often had to move disks from one platform to another, and changing ID's
> > on the was hard or impossible in some cases, and required in others. Being
> > able to find the disk by a label is a thousand times better.
>
> Did you ever try grub?? This a gnu project, a boot-loader,
On Wed, May 16, 2001 at 08:25:56PM +0300, Jussi Laako wrote:
> I tested 2.4.4-ac9 today on A7V133 machine. It booted up, but can't stand
> any load. It will deadlock (without oops) when the network/disk system faces
> any load.
>
> There is also some new bug in VIA IDE driver. It misdetects
H. Peter Anvin writes:
> Richard Gooch wrote:
> > Argh! What I wrote in text is what I meant to say. The code didn't
> > match. No wonder people seemed to be missing the point. So the line of
> > code I actually meant was:
> > if (strcmp (buffer + len - 3, "/cd") != 0) {
>
> This is
Hi
I'm experiencing reproductible oopses on my stock 2.2.19 (with BadRAM
patches, though I seriously doubt thet can affect described behaviour). The
system is Slackware-current, kernel compiled from sources, on Pentium 120
with 32Mb RAM. The oops report is from mc but any process trying to read
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
> > On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> > >
> > > That does indeed correct the problem. 2.2.20pre1 now works
> > > as expected.
> >
> >
Hi Alexander,
On Wed, 16 May 2001, Alexander Viro wrote:
> Because what I need is an absolute minimum. Heck, I don't even use
> regular files (in the full variant of patch, that is). They might
> become useful, but I can live with mkdir() and mknod().
So what about adding shmem_mknod and
1 - 100 of 448 matches
Mail list logo
