Lockups w/ VIA KT133A board
Hello, (Please CC [EMAIL PROTECTED] as I'm not on the list) I'm getting lockups when I try to use my cd burner (SCSI burner). Using an Asus A7V133 motherboard that uses the VIA KT133A chipset (using an Athlon 1.2ghz). I've scanned the archives and see issues with people using the udma/100 ide controller and what not but I'm not using IDE here (tested with 2.4.1, 2.4.3, 2.4.4, 2.4.5).It locks up solid everytime as writing begins (using cdrecord) and I'm unable do SysRq. I've also had some random lock-ups while xscreensaver is running that also lock the machine solid (scsi harddisks.. again, not IDE). Is the VIA chipset to blame for all this even though they're not IDE problems? If so anyone recommend a chipset that will 'work'... or even a motherboard. thanks kindly, Gerard - 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: double entries in /proc/dri?
On Tue, 12 Jun 2001, Larry McVoy wrote: > This is cute: > > $ ls -li /proc > ... >4106 -r--r--r--1 root root0 Jun 12 18:53 dma >4347 dr-xr-xr-x3 root root0 Jun 12 18:53 dri >4347 dr-xr-xr-x3 root root0 Jun 12 18:53 dri >4121 dr-xr-xr-x2 root root0 Jun 12 18:53 driver > ... > > $ uname -a > Linux work.bitmover.com 2.4.5 #1 Mon May 28 10:54:32 PDT 2001 i686 unknown > > Repeatable. If other users of 2.4.5 do NOT see this, please let me know. Linux pawalski.blipp.com 2.4.5-0.2.9 #1 Wed May 30 06:50:52 EDT 2001 i686 unknown This is the Red Hat kernel from rawhide. -r--r--r--1 root root0 Jun 13 06:59 dma dr-xr-xr-x2 root root0 Jun 13 06:59 driver -r--r--r--1 root root0 Jun 13 06:59 execdomains However, I saw this on a self compiled 2.4.4 with Cisco 350 PC-Card installed using pcmcia-cs and the Cisco airo_cs.o module up and running. -- patrik wallstrom | f o o d f i g h t tel: +46-8-6188428 | s t o c k h o l m gsm: +46-708405080 | - - - - - - - - - - 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] 2.4.6-pre2 page_launder() improvements
Are these page_launder improvements included in 2.4.6-pre3? Linus
mentions "VM tuning has also happened" in the announcement - but there
doesn't seem to be mention of it in his list of changes from -pre2...
Thanks
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Rik van Riel
> Sent: Sunday, June 10, 2001 12:41 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [PATCH] 2.4.6-pre2 page_launder() improvements
>
>
> [Request For Testers ... patch below]
>
> Hi,
>
> during my holidays I've written the following patch
> (forward-ported to 2.4.6-pre2 and improved a tad today),
> which implements these improvements to page_launder():
>
> 1) don't "roll over" inactive_dirty pages to the back of the
>list, but reclaim them in something more resembling LRU
>order; this is especially good when the system has tons
>of inactive_dirty pages due to eg. background scanning
>
> 2) eliminate the infinite penalty clean pages had over dirty
>pages by not scanning the complete inactive_dirty list and
>letting real dirty pages build up near the front of the
>list ... we flush them asynchronously when we have enough
>of them
>
> 3) when going into the launder_loop, we scan a larger fraction
>of the inactive_dirty list; under most workloads this means
>we can always flush the dirty pages asynchronously because
>we'll have clean, freeable pages in the part of the list we
>only scan in the launder_loop
>
> 4) when we have only dirty pages and cannot free pages, we
>remember this for the next run of page_launder() and won't
>waste CPU by scanning pages without flushing them in the
>launder loop (after maxlaunder goes negative)
>
> 5) this same logic is used to control when we use synchronous
>IO; only when we cannot free any pages now do we wait on
>IO, this stops kswapd CPU wastage under heavy write loads
>
> 6) the "sync" argument to page_launder() now means whether
>we're _allowed_ to do synchronous IO or not ... page_launder()
>is now smart enough to determine if we should use asynchronous
>IO only or if we should wait on IO
>
> This patch has given excellent results on my laptop and my
> workstation here and seems to improve kernel behaviour in
> tests quite a bit. I can play mp3's unbuffered during
> moderate write loads or moderately heavy IO ;)
>
> YMMV, please test it. If it works great for everybody I'd
> like to get this improvement merged into the next -pre kernel.
>
> regards,
>
> Rik
> --
> Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
>
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
>
> http://www.surriel.com/
> http://www.conectiva.com/ http://distro.conectiva.com/
>
>
> diff -ur linux-2.4.6-pre2-virgin/include/linux/mm.h
> linux-2.4.6-pre2/include/linux/mm.h
> --- linux-2.4.6-pre2-virgin/include/linux/mm.hSun Jun
> 10 00:44:01 2001
> +++ linux-2.4.6-pre2/include/linux/mm.h Sat Jun 9 23:19:54 2001
> @@ -169,6 +169,7 @@
> #define PG_inactive_clean11
> #define PG_highmem 12
> #define PG_checked 13 /* kill me in 2.5.. */
> +#define PG_marker14
> /* bits 21-29 unused */
> #define PG_arch_130
> #define PG_reserved 31
> @@ -242,6 +243,9 @@
> #define PageInactiveClean(page)
> test_bit(PG_inactive_clean, &(page)->flags)
> #define SetPageInactiveClean(page)
> set_bit(PG_inactive_clean, &(page)->flags)
> #define ClearPageInactiveClean(page)
> clear_bit(PG_inactive_clean, &(page)->flags)
> +
> +#define PageMarker(page) test_bit(PG_marker, &(page)->flags)
> +#define SetPageMarker(page) set_bit(PG_marker, &(page)->flags)
>
> #ifdef CONFIG_HIGHMEM
> #define PageHighMem(page)test_bit(PG_highmem,
> &(page)->flags)
> diff -ur linux-2.4.6-pre2-virgin/include/linux/swap.h
> linux-2.4.6-pre2/include/linux/swap.h
> --- linux-2.4.6-pre2-virgin/include/linux/swap.h Sun Jun
> 10 00:44:01 2001
> +++ linux-2.4.6-pre2/include/linux/swap.h Sat Jun 9 23:19:54 2001
> @@ -205,6 +205,16 @@
> page->zone->inactive_dirty_pages++; \
> }
>
> +/* Like the above, but add us after the bookmark. */
> +#define add_page_to_inactive_dirty_list_marker(page) { \
> + DEBUG_ADD_PAGE \
> + ZERO_PAGE_BUG \
> + SetPageInactiveDirty(page); \
> + list_add(&(page)->lru, marker_lru); \
> + nr_inactive_dirty_pages++; \
> + page->zone->inactive_dirty_pages++; \
> +}
> +
> #define add_page_to_inactive_clean_list(page) { \
> DEBUG_ADD_PAGE \
> ZERO_PAGE_BUG \
> diff -ur linux-2.4.6-pre2-virgin/mm/vmscan.c
> linux-2.4.6-pre2/mm/vmscan.c
> --- linux-2.4.6-pre2-virgin/mm/vmscan.c Sun Jun 10 00:44:02 2001
> +++ linux-2.4.6-pre2/mm/vmscan.c Sun Jun 10 00:57:25 2001
> @@ -407,7 +407,7 @@
> /**
> * page_launder - clean
Re: New PCI PM
On Tue, 12 Jun 2001, Jeff Garzik wrote: > > What is are the guarantees about the order of calls to > pci_driver::suspend and pci_driver::resume? > > Will a driver get calls like > suspend(D3) > suspend(D2) > suspend(D1) Not possible, according to the PCI PM Spec. These are the possible state transitions: +---+ | Current State | New State | +---+ | D0| D1, D2, D3| +---+ | D1| D2, D3| +---+ | D2| D3| +---+ | D1, D2, D3| D0| +---+ (note the last would be ::resume() from any state) > or just one suspend call? Calls to lower power states are possible, but never to higher, except D0. > What effect does the return value have on the rest of the system? On > the order of succeeding calls to pci_driver::suspend functions? On system suspend, it should be ignored. It sounds bad, but there is justification. With a two-stage suspension, drivers will get a call to ::save_state before suspend. It is then that they should fail, if they're going to. That way, nothing will be powered off yet, and a graceful recovery is much more likely. However, if you're gradually bringing the device down to lower and lower power states, you may want to know if it fails (e.g. if it can't enter D1 or D2). > And where is that patch to Documentation/pci.txt young man? :) It should be in -pre4. Quick Draw Torvalds couldn't wait an extra 15 minutes to release -pre3. -pat - 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 there a way to export a fat32 file system using nfs?
On Tuesday June 12, [EMAIL PROTECTED] wrote: > > > On Wed, 13 Jun 2001, Neil Brown wrote: > > >Call fat_iget(i_location). > > If this finds something, check i_logstart. > > If it matches, assume SUCCESS. > > > >Then comes the tricky bit: read the directory entry > > indicated by i_location, check the i_logstart is right, > > if it is, try to get it into the inode cache properly. > > Uh-huh. Suppose that directory had been removed and space had been > reused by a regular file. Which had been filled with the right > contents. It's really not hard to do. Now, remove that file and > you've got a nice data corruption waiting to happen. Told you it was tricky!! Let's see now... We could also store the disc address of the start of the directory in the filehandle. Then we examine the FAT to see if the file starting at that block looks like a directory, and contains the target directory entry. If it does, we extract the ".." entry (do FAT directories have and analogue of ".." entries?) and keep going up the tree until we find the root, or we have tried too hard. Once we hit the root we will have collected a full path name for the file, so we just do lots of lookups to get it into the caches. Ugh. I might just do that first step (find_ino) and offer it as as an experimental patch to the growing number of people who have asked for nfs exporting of FAT filesystems, and see how reliable it is in practice. NeilBrown - 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 there a way to export a fat32 file system using nfs?
On Wed, 13 Jun 2001, Neil Brown wrote: >Call fat_iget(i_location). > If this finds something, check i_logstart. > If it matches, assume SUCCESS. > >Then comes the tricky bit: read the directory entry > indicated by i_location, check the i_logstart is right, > if it is, try to get it into the inode cache properly. Uh-huh. Suppose that directory had been removed and space had been reused by a regular file. Which had been filled with the right contents. It's really not hard to do. Now, remove that file and you've got a nice data corruption waiting to happen. - 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 there a way to export a fat32 file system using nfs?
On Tuesday June 12, [EMAIL PROTECTED] wrote: > Hi. I seem to remember that at one time in the 2.2 series I was able > to to export fat32 file systems using nfs, but now it doesn't work > anymore. No, it doesn't. It did in early 2.2 due to some fairly ugly hacks which just had to go. They worked in a lot of simple cases, but it wouldn't be too difficult to confuse such a server so that it would start losing files. It would be possible to add to 2.4.5, but not easy. The basic problem is that you cannot create a reliable NFS filehandle for a file in a FAT filesystem as there are no inode numbers or anything similar. What might work would be: In fat_fill_inode, set i_generation to the current time. When creating a filehandle, store: i_ino i_generation i_location i_logstart When when asked to lookup a filehandle: Call find_inode(i_ino). If this finds something check i_generation. If it matches, SUCCESS. Call fat_iget(i_location). If this finds something, check i_logstart. If it matches, assume SUCCESS. Then comes the tricky bit: read the directory entry indicated by i_location, check the i_logstart is right, if it is, try to get it into the inode cache properly. It is something that I would like to do, but I have lots of other things that I want to do at the moment. NeilBrown > > If I remember correctly, I get "get: operation not permitted" when > trying to export the directory in question. > > I am using 2.4.5. > > Any assistance would be appreciated. > > -- > John Covici > [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/ - 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/
New PCI PM
What is are the guarantees about the order of calls to pci_driver::suspend and pci_driver::resume? Will a driver get calls like suspend(D3) suspend(D2) suspend(D1) or just one suspend call? What effect does the return value have on the rest of the system? On the order of succeeding calls to pci_driver::suspend functions? And where is that patch to Documentation/pci.txt young man? :) -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - 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: Hour long timeout to ssh/telnet/ftp to down host?
>You can tune things by setting the tcp-timeout probably..I don't
>know exactly where to set this..
Aha, found it. /proc/sys/net/ipv4/tcp_syn_retries
I am a victim of the exponential retry falloff, it would seem. syn_retries
of 1 takes a few seconds, 3 takes less than half a minute, and 5 takes
several minutes. The default value of 10 is what's giving me the problem
(something like 20 minutes to time out, according to my earlier tests.)
Then the fact that ssh then re-attempts the connection four times before
actually failing is where I got my hour and change timeout. ("ssh -v -v -v"
comes in handy...)
Fun.
Can we change the default value for this to something more sane, like 5?
Exponential falloff is not good when your order of magnitude hits double
digits.
> You probably don't want all tcp to time out at 15 seconds anyway, so
Just connection initiation. (If their ip stack hasn't replied to me by then,
I doubt it's going to.)
> I'd suggest either using non-blocking connect (if you have the code
> that does the connect), or just set a timer (or use sigalarm) when you
> start the attempt, and fail the attempt if the timer or alarm signal
> goes off.
Except I'm using off-the-shelf ssh. (I asked them about this problem a month
ago, and there was some discussion of a workaround on their mailing list, but
2.9 came out and still had the same behavior. Apparently, if it's not a
problem in OpenBSD, it's not a problem in OpenSSH...)
> > If it's glibc I'm probably better off writing a wrapper to ping the
> > destination before trying to connect, or killing the connection after a
> > timeout with no traffic. But both of those are really ugly solutions.
>
> Ugly is relative, and don't use ping because there is still a race
> condition (ping worked, but by the time you try tcp, the box is down.)
Yeah, but it would eventually time out and recover, I've got ten threads out
querying boxes, that's a really rare race condition. And I already
acknowledged it was ugly. :)
So the problem is just that tcp_syn_retries' default value of 10 is way too
high due to the exponentially increasing gap between each retry.
Rob
-
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: Hour long timeout to ssh/telnet/ftp to down host?
Rob Landley wrote: > > I have scripts that ssh into large numbers of boxes, which are sometimes > down. The timeout for figuring out the box is down is over an hour. This is > just insane. > > Telnet and ftp behave similarly, or at least tthey lasted the 5 minutes I was > willing to wait, anyway. Basically anything that calls connect(). If the > box doesn't respond in 15 seconds, I want to give up. > > Is this a problem with the kernel or with glibc? If it's the kernel, I'd > expect a /proc entry where I can set this, but I can't seem to find one. Is > there one? What would be involved in writing one? > You can tune things by setting the tcp-timeout probably..I don't know exactly where to set this.. You probably don't want all tcp to time out at 15 seconds anyway, so I'd suggest either using non-blocking connect (if you have the code that does the connect), or just set a timer (or use sigalarm) when you start the attempt, and fail the attempt if the timer or alarm signal goes off. > If it's glibc I'm probably better off writing a wrapper to ping the > destination before trying to connect, or killing the connection after a > timeout with no traffic. But both of those are really ugly solutions. Ugly is relative, and don't use ping because there is still a race condition (ping worked, but by the time you try tcp, the box is down.) > > Anybody have any light to shed on the situation? > > Rob > - > 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/ -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - 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: double entries in /proc/dri?
On 12 Jun 2001 18:56:03 -0700, Larry McVoy wrote: > >4106 -r--r--r--1 root root0 Jun 12 18:53 dma >4347 dr-xr-xr-x3 root root0 Jun 12 18:53 dri >4347 dr-xr-xr-x3 root root0 Jun 12 18:53 dri >4121 dr-xr-xr-x2 root root0 Jun 12 18:53 driver > not here, but this is 2.4.5-ac13. [22:07:35]rml@phantasy:/proc# ls -li ... 4106 -r--r--r--1 root root0 Jun 12 22:07 dma 4300 dr-xr-xr-x3 root root0 Jun 12 22:07 dri 4121 dr-xr-xr-x2 root root0 Jun 12 22:07 driver ... [22:09:13]rml@phantasy:/proc# cat /proc/version Linux version 2.4.5-ac13 (rml@phantasy) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85)) #1 Sun Jun 10 17:34:02 EDT 2001 either fixed in an -ac release, or not a universal bug? -- Robert M. Love [EMAIL PROTECTED] [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: CLOSE_WAIT bug?
> One server socket created and listening, blocking on select(), > once a client connect to that port, there is another thread in server > side issues a close() to the new connection. > After the client close the connection. The connection in server side will > stuck on CLOSE_WAIT forever until the program being killed. This isn't something you should ever do. There is no way the kernel can guarantee a sane reaction to this since the 'close' could occur _before_ you even enter 'select'. There is no atomic 'release mutex and select' function so you can never know for sure whether the 'close' will occur before or after the other thread enters 'select'. There's also the possibility that another thread will open a new connection onto the same descriptor before the thread blocked in 'select' gets a chance to notice that the descriptor is being closed. It's also not clear what the 'close' does in this case. An attempt to close a descriptor is not supposed to close the underlying connection unless it closes the last reference. It's not clear whether 'select' represents a reference or not, and it's not clear what should happen if the descriptor table changes before the 'select' thread gets woken up even if the 'close' call schedules it. One can argue that 'select' should return because a 'read' or 'write' to the connection wouldn't block. But that's only true after 'select' returns. While the endpoint is in use (and 'select' is using it), 'close' shouldn't necessarily close the underlying connection. So this argument require bootstrapping. For TCP, use 'shutdown'. Don't 'close' the descriptor until you are sure no thread is using it. This is as serious an error as 'free'ing memory that another thread is using. So your code is buggy. So long as the kernel doesn't lose track of the resources entirely, it's behavior is (at least to me) acceptable. In fact, I wish it would punish errors like this more severely, as this would reduce the amount of code out there that has them. DS - 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/
Hour long timeout to ssh/telnet/ftp to down host?
I have scripts that ssh into large numbers of boxes, which are sometimes down. The timeout for figuring out the box is down is over an hour. This is just insane. Telnet and ftp behave similarly, or at least tthey lasted the 5 minutes I was willing to wait, anyway. Basically anything that calls connect(). If the box doesn't respond in 15 seconds, I want to give up. Is this a problem with the kernel or with glibc? If it's the kernel, I'd expect a /proc entry where I can set this, but I can't seem to find one. Is there one? What would be involved in writing one? If it's glibc I'm probably better off writing a wrapper to ping the destination before trying to connect, or killing the connection after a timeout with no traffic. But both of those are really ugly solutions. Anybody have any light to shed on the situation? Rob - 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/
double entries in /proc/dri?
This is cute: $ ls -li /proc ... 4106 -r--r--r--1 root root0 Jun 12 18:53 dma 4347 dr-xr-xr-x3 root root0 Jun 12 18:53 dri 4347 dr-xr-xr-x3 root root0 Jun 12 18:53 dri 4121 dr-xr-xr-x2 root root0 Jun 12 18:53 driver ... $ uname -a Linux work.bitmover.com 2.4.5 #1 Mon May 28 10:54:32 PDT 2001 i686 unknown Repeatable. If other users of 2.4.5 do NOT see this, please let me know. --lm - 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.2.19: eepro100 and cmd_wait issues
David Lang wrote: > > I am useing the D-link 4 port card without running into problems > (admittidly I have not been stressing it much yet) I was able to get the D-Link to work in half-duplex (100bt), but not in auto-negotiate or full-duplex mode. (Packets would pass, but there would be huge number of carrier and other bad packets.) I get a similar problem with the ZNYX 4-port, but I can't even force it to half-duplex, or any other fixed speed (it just won't go). It kinda autonegotiates something, claiming to be full-duplex, but it still shows collisions and I can't get through-put above about 10Mbps bi-directional, and its dropping many packets. -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - 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
From: Colonel <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: ISA Soundblaster problem Reply-to: [EMAIL PROTECTED] The Maintainers list does not contain anyone for 2.4 Soundblaster modules, so perhaps some one on the mailing list is aware of a solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2 with XMMS. But I have never been successful in a varity of 2.4 kernels, the latest being 2.4.5-ac12. This is what I know: [DMESG] isapnp: Scanning for PnP cards... isapnp: Calling quirk for 01:00 isapnp: SB audio device quirk - increasing port range isapnp: Card 'Creative SB16 PnP' isapnp: 1 Plug & Play card detected total }modprobe sb /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed [/etc/modules.conf] options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 [DMESG} Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 sb: No ISAPnP cards found, trying standard ones... sb: dsp reset failed. So it seems that PnP finds the card, but the connections (or even the forced values) to the sb module fail. Back when this was a single processor machine, but still running 2.4 kernel, a windoze installation found the SB at the listed interface parameters. Anyone have a solution? Same problem without modules.conf settings, valid version of mod utilities, a web search did not help,... TIA please CC: [EMAIL PROTECTED], not currently on the mailing list. - 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/
is there a way to export a fat32 file system using nfs?
Hi. I seem to remember that at one time in the 2.2 series I was able to to export fat32 file systems using nfs, but now it doesn't work anymore. If I remember correctly, I get "get: operation not permitted" when trying to export the directory in question. I am using 2.4.5. Any assistance would be appreciated. -- John Covici [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/
Linux-2.4.6-pre3
User-noticeable things: if you are tired of not being able to NFS-export your reiserfs tree, this should make you happy. VM tuning has also happened, with Rik van Riel, Mike Galbraith, Marcelo Tosatti and Andrew Morton all doing various tweaks. Give it a whirl. Linus - -pre3: - remember to increment the version number - Chris Mason: reiserfs mark_journal_new and bh leak fix - Richard Gooch: devfs update - Alexander Viro: further FS cleanup (superblock list) - David Woodhouse: MTD update - Kai Germaschewski: ISDN update (stanford checker fixes etc) - Rich Baum: gcc-3.0 warning fixes - Jeff Garzik: network driver updates - Geert Uytterhoeven: m68k fbdev logo merge glitch fix - Andrea Arcangeli: fix signal return path - David Miller: Sparc updates - Johannes Erdfelt: USB update - Carsten Otte, Andries Brouwer: don't clear blk_size unconditionally on partition check - Martin Frey: alpha Sable irq fix - Paul Mackerras: PPC softirq update - Patrick Mochel: PCI power management infrastructure - Robert Siemer: miroSOUND driver update - Neil Brown: knfsd updates, including ability to export ReiserFS filesystems - Trond Myklebust: NFS readdir fixup, don't update atime on client - Andrew Morton: truncate_inode_pages speedup - Paul Menage: make inode quota count all inodes.. -pre2: - Takanori Kawano: brlock indexing bugfix - Ingo Molnar, Jeff Garzik: softirq updates and fixes - Al Viro: rampage of superblock cleanups. - Jean Tourrilhes: Orinoco driver update v6, IrNET update - Trond Myklebust: NFS brown-paper-bag thing - Tim Waugh: parport update - David Miller: networking and sparc updates - Jes Sorensen: m68k update. - Ben Fennema: UDF update - Geert Uytterhoeven: fbdev logo updates - Willem Riede: osst driver updates - Paul Mackerras: PPC update - Marcelo Tosatti: unlazy swap cache - Mikulas Patocka: hpfs update -pre1: - Andreas Dilger: make ext2fs react more gracefully to inode disk errors - Andrea Arkangeli: fix up alpha compile issues - Ingo Molnar: io-apic MP table parsing update and softirq latency update - Johannes Erdfelt: USB updates - Richard Henderson: alpha rawhide irq handling fixes - Marcelo, Andrea, Rik: more VM issues - Al Viro: fix various ext2 directory handling checks by biting the bullet and using the page 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: 2.2.19: eepro100 and cmd_wait issues
I am useing the D-link 4 port card without running into problems (admittidly I have not been stressing it much yet) David Lang On Tue, 12 Jun 2001, Ben Greear wrote: > Date: Tue, 12 Jun 2001 17:51:08 -0700 > From: Ben Greear <[EMAIL PROTECTED]> > To: Ken Brownfield <[EMAIL PROTECTED]> > Cc: Florin Andrei <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: 2.2.19: eepro100 and cmd_wait issues > > Ken Brownfield wrote: > > > OT: does anyone know what the current state of the Tulip driver is and > > if there is good hardware out there? SMC left Tulip and went through at > > least two other chipsets, so the only Tulip card I could find as of a > > couple of years ago was Digital's. But it was astonishingly expensive > > and not clearly supported by the Linux driver. > > The current state seems to be 'BUSTED', at least for the cards > that I am trying (ZNYX 4-port, D-LINK 4-port). (I'm using the 2.4 > drivers, btw.) > > However, I'm hoping that it will be fixed soon, because the D-LINK > 4-port is very cheap compared to other 4-ports out there, and in fact > I haven't found a 4-port card that is NOT tulip based (please let > me know if you have 4-port suggestions!) > > Other than one really old EEPRO card I have, the EEPRO cards seem to be > very stable, fast, and feature-complete. > > Ben > > -- > Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > President of Candela Technologies Inc http://www.candelatech.com > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > - > 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/ > - 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] General race condition with init thread may prematurely free start_kernel
(Please CC replies to me, I'm not subscribed to lkml.)
I think I've found a bug, local to linux/init/main.c, related to
freeing init pages, which seems to be present in 2.4.5.
Executive summary: After start_kernel has created the init
thread, it needs to proceed to cpu_idle before init pages are
free:d, since it's __init-marked. But if the init thread is
scheduled to run before the parent thread, and in turn its call
to do_basic_setup returns quickly, start_kernel will be
free_initmem:d before that thread has proceeded to cpu_idle.
Boom. Patch at end.
Somewhat lengthier description and analysis: I found this out
the hard way when fixing free_initmem (and the linker script) in
Linux/CRIS. In linux/init/main.c it looks as follows at a
conceptual level:
void __init start_kernel()
{
foo_init();
blah_init();
...
kernel_thread (init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
current->need_resched = 1;
cpu_idle();
}
Correspondingly, the function init looks as follows:
static int init(void * unused)
{
do_basic_setup();
free_initmem();
... start up /bin/init or whatever ...
}
And do_basic_setup looks like this:
static void __init do_basic_setup(void)
{
baz_init ();
... more *_init() calls ...
... mount root fs ...
}
If nothing in do_basic_setup causes rescheduling, it might
(depending on e.g. timing) return before the parent has
proceeded to call cpu_idle, from which it never returns. If so,
free_initmem will be called, freeing among others start_kernel.
Later, when the parent thread is scheduled to run and returns
from the kernel_thread call, it will execute in unmapped memory.
Bad: will crash, perhaps depending on that memory being recycled
and modified.
Normally, mounting the root fs involves mechanical disks or
network activity or other stuff that causes I/O or takes time.
Then rescheduling will cause the parent thread to resume to
safety before do_basic_setup returns. You're most likely to see
the race problem on platforms with a solid-state root fs.
Analysis sanity-checked with [EMAIL PROTECTED] Repeatable on an
"Axis Developer Board LX" (with patches to fix the linker script
and remove the #if 0:s from linux/arch/cris/mm/init.c; contact
me if you actually need to do this).
One solution is to break out the last piece of start_kernel to a
non-__init function as follows. The patch is against 2.4.5.
2001-06-12 Hans-Peter Nilsson <[EMAIL PROTECTED]>
* linux/init/main.c (rest_init): New, broken out from start_kernel.
--- linux/init/main.c.original Tue May 22 18:35:42 2001
+++ linux/init/main.c Wed Jun 13 01:20:54 2001
@@ -502,6 +502,21 @@ static void __init smp_init(void)
#endif
/*
+ * We need to finalize in a non-__init function or else race conditions
+ * between the root thread and the init thread may cause start_kernel to
+ * be reaped by free_initmem before the root thread has proceeded to
+ * cpu_idle.
+ */
+
+static void rest_init(void)
+{
+ kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
+ unlock_kernel();
+ current->need_resched = 1;
+ cpu_idle();
+}
+
+/*
* Activate the first processor.
*/
@@ -583,10 +598,7 @@ asmlinkage void __init start_kernel(void
* make syscalls (and thus be locked).
*/
smp_init();
- kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
- unlock_kernel();
- current->need_resched = 1;
- cpu_idle();
+ rest_init();
}
#ifdef CONFIG_BLK_DEV_INITRD
brgds, H-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: Minor "cleanup" patches for 2.4.5-ac kernels
Michal Jaegermann wrote:
> --- linux-2.4.5ac/drivers/pci/quirks.c~ Tue Jun 12 16:31:12 2001
> +++ linux-2.4.5ac/drivers/pci/quirks.c Tue Jun 12 17:13:18 2001
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #undef DEBUG
>
> There is no problem if SMP is not configured.
no the better place for this is include/asm-i386/delay.h. Otherwise you
wind up solving the same problem over and over again in each similar
driver.
I --just-- went through on Alpha, and included linux/sched.h in
include/asm-alpha/delay.h. Not an hour ago :) Then Andrea suggested to
simply un-inline udelay, which solved the compile problem in an even
better way. (we cannot un-inline udelay on x86 I think)
> --- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
> +++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
> @@ -32,6 +32,9 @@ struct linux_binprm{
> unsigned long loader, exec;
> };
>
> +/* Forward declaration */
> +struct mm_struct;
> +
I added this one to the MDK kernel compile. I think it is an 'ac'
thing, I don't get these warnings on vanilla 2.4.[56]-pre.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
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.2.19: eepro100 and cmd_wait issues
Ken Brownfield wrote: > OT: does anyone know what the current state of the Tulip driver is and > if there is good hardware out there? SMC left Tulip and went through at > least two other chipsets, so the only Tulip card I could find as of a > couple of years ago was Digital's. But it was astonishingly expensive > and not clearly supported by the Linux driver. The current state seems to be 'BUSTED', at least for the cards that I am trying (ZNYX 4-port, D-LINK 4-port). (I'm using the 2.4 drivers, btw.) However, I'm hoping that it will be fixed soon, because the D-LINK 4-port is very cheap compared to other 4-ports out there, and in fact I haven't found a 4-port card that is NOT tulip based (please let me know if you have 4-port suggestions!) Other than one really old EEPRO card I have, the EEPRO cards seem to be very stable, fast, and feature-complete. Ben -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - 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/
IRQ problems w/VIA Apollo VP2/97 & NCR 53c875
Summary: IRQ conflict on VIA Apollo VP2/97-based motherboard between dual controllers on NCR 53c875 (Diamond Fireport 40). Kernel version is 2.4.5-ac9. --- cut here --- 00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97] (rev 04) Flags: bus master, 66Mhz, medium devsel, latency 64 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 25) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 64 I/O ports at 6000 [size=16] --- cut here --- When I attempt to mobprobe the ncr53c8xx module, I get the following output: SCSI subsystem driver Revision: 1.00 PCI: Found IRQ 11 for device 00:0b.0 IRQ routing conflict in pirq table for device 00:0b.0 IRQ routing conflict in pirq table for device 00:0b.1 It appears that something is getting confused and doesn't want to allow the two controllers of this card to share the same IRQ. Here is the relevent output from 'lspci -v': --- cut here --- 00:0b.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Diamond Multimedia Systems FirePort 40 Dual SCSI Controller Flags: bus master, medium devsel, latency 144, IRQ 10 I/O ports at 6c00 [size=256] Memory at e2001000 (32-bit, non-prefetchable) [size=256] Memory at e2002000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=64K] 00:0b.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Diamond Multimedia Systems FirePort 40 Dual SCSI Controller Flags: bus master, medium devsel, latency 144, IRQ 10 I/O ports at 7000 [size=256] Memory at e2003000 (32-bit, non-prefetchable) [size=256] Memory at e2004000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=64K] --- cut here -- There are no other devices using IRQ10. Is this a lost cause? This controller and drives in their current configuration can be moved to an Intel based machine and works flawlessly. I have yet to see this controller work on this VIA motherboard. Any assistance is appreciated. Thanks, Mike. - 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/
Minor "cleanup" patches for 2.4.5-ac kernels
Here are some small, but in times important, "gotchas" in current
2.4.5-ac kernels.
When compiling SMP 'udelay' in current drivers/pci/quirks.c expands to:
__udelay((15), cpu_data[(current->processor)]...
and a type for 'current' is not known, at least on alpha, so
the following seems to be in order:
--- linux-2.4.5ac/drivers/pci/quirks.c~ Tue Jun 12 16:31:12 2001
+++ linux-2.4.5ac/drivers/pci/quirks.c Tue Jun 12 17:13:18 2001
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#undef DEBUG
There is no problem if SMP is not configured.
This one is replacing a symbol in sg.c to one which is exported
so 'sg.o' can be compiled as a valid module.
--- linux-2.4.5ac/drivers/scsi/sg.c~Tue May 29 17:52:09 2001
+++ linux-2.4.5ac/drivers/scsi/sg.c Tue May 29 18:40:17 2001
@@ -2603,7 +2603,7 @@
num = (count < 10) ? count : 10;
copy_from_user(buff, buffer, num);
buff[num] = '\0';
-sg_allow_dio = simple_strtol(buff, 0, 10) ? 1 : 0;
+sg_allow_dio = simple_strtoul(buff, 0, 10) ? 1 : 0;
return count;
}
And this one, proposed already some few times by Ivan Kokshaysky,
--- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
+++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
@@ -32,6 +32,9 @@ struct linux_binprm{
unsigned long loader, exec;
};
+/* Forward declaration */
+struct mm_struct;
+
/*
* This structure defines the functions that are used to load the binary formats that
* linux accepts.
kills a flood of warnings (at least on Alpha) about 'mm_struct'
defined on a parameter list.
Are there any reasons which would make any of those "bad"?
Michal
-
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: Getting A Patch Into The Kernel
On Tue, 12 Jun 2001, Craig Lyons wrote: > My name is Craig Lyons and I am the marketing manager at Promise > Technology. We have a question and are hoping you can point us in the > right direction. I think most, if not all, of the things you want to know are described in the following two documents in the Documentation/ directory of the Linux kernel source ;) linux/Documentation/SubmittingDrivers linux/Documentation/SubmittingPatches regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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] symlink.c
Quoting John Martin <[EMAIL PROTECTED]>: > this patch adds a check to make sure memory was allocated, returns an > error code otherwise. autofs4_dentry_ino doesn't allocate memory; it just extracts the fsdata pointer from the dentry structure. If it's returning NULL, then there's something else wrong and you're papering over the symptoms. Are you seeing this happen? Linus, please don't apply this. 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/
Client receives TCP packets but does not ACK
I have a client server program that opens a tcp connection between two machines. Everything is fine until a certain type of data is sent across the socket at which point the client refuses to ACK and the server continues to resend the packets to no avail. I've verified that the client is blocking on a socket read (and not coming out) I've also run "tcpdump -lxa -s 5000" on each machine and verified that each packet sent by each machine is received by the other. I diffed the data and there appears to be no corruption. I first saw this with the server running 2.4.2 and the client running 2.2.16 but I have since upgraded the server first to 2.4.5 and then also added a patch from 1.4.6-pre2 that had to do with tcp acks. The bug still repros. I have also upgraded the client to 2.4.2, 2.4.5, and 2.4.5 + ack patch with no luck. There have been quite a few other people who have experienced these symptoms and posted to the list over the past 5 months or so. I haven't seen a resolution for any of them except for requests to try the latest kernel since there have been a lot of networking fixes in the latest kernels. I have appened links to these other postings at the end of this email in case their data might help. I can consistently reproduce this problem on my machines (10mbs ethernet lan) and would really like to narrow this bug down to the source instead of trying the latest kernels and hoping that they solve the problem. The networking code (net/ipv4/tcp*.c) is daunting to me but if someone has any suggestions on good places to add debug code, building a debug version, or whatever, I can try it on my local system and investigate further. This bug is driving me crazy and I want to find it and fix it! Are there any other details that would help? My hardware configuration? Network settings? etc? Here is the analysis of one of the tcpdump logs for glottis. glottis is the client and manny is the server. Note that the large packet 11006:1254(1448) is received by glottis and an ack is never sent to manny. 20:07:45.043640 glottis->manny ack 11006 20:07:45.047120 manny->glottis 11006:12454(1448) ack 408 probably contains the remainder of ClientMap 20:07:45.047571 manny->glottis 12454:12936(482) ack 408 20:07:45.047673 glottis->manny ack 11006 20:07:45.272042 manny->glottis 11006:12454(1448) ack 408 resend 20:07:45.732049 manny->glottis 11006:12454(1448) ack 408 resend 20:07:46.652015 manny->glottis 11006:12454(1448) ack 408 resend 20:07:48.491986 manny->glottis 11006:12454(1448) ack 408 resend 20:07:52.171937 manny->glottis 11006:12454(1448) ack 408 resend 20:07:59.531850 manny->glottis 11006:12454(1448) ack 408 resend web packets as manny is probably pinging session server 20:08:14.251656 manny->glottis 11006:12454(1448) ack 408 resend 20:08:24.078088 glottis->manny 408:437(29) ack 11006 text request in same packet 20:08:24.110417 manny->glottis ack 437 20:08:27.539778 glottis->manny 437:470(33) ack 11006 quit message 20:08:27.540158 manny->glottis 12936:12936(0) ack 470 20:08:27.541574 glottis->manny 470:472(2) ack 11006 20:08:27.542069 manny->glottis 12936:12936(0) ack 472 20:08:27.637385 manny->glottis 12936:12936(0) ack 473 web packets ntp packets 20:08:43.691285 manny->glottis 11006:12454(1448) ack 473 resend arp packets Here are some other threads on the list that may be related to this problem: http://groups.google.com/groups?hl=en==off=1=ca50bd5b6fab99dd,2=linux.kernel.3A806260.BB77D017%40denise.shiny.it#p http://groups.google.com/groups?hl=en==off=1=c2b75d883be146f6,2=linux.kernel.5.0.2.1.2.20010115152847.00a8a380%40pop.we.mediaone.net#p http://groups.google.com/groups?hl=en==off=1=5a94424eaed764df,21=linux.kernel.3A6F3C4A.27E148E9%40colorfullife.com#p http://groups.google.com/groups?hl=en==off=1=d74b104bfe2da967,14=200104101738.VAA21467%40ms2.inr.ac.ru#p http://groups.google.com/groups?hl=en==off=1=c15161c8342be0a0,7=linux.kernel.Pine.LNX.4.30.0012311601410.9994-10%40shodan.irccrew.org#p http://groups.google.com/groups?hl=en==off=1=7268b77eb1e07a38,3=20010419200905.A2970%40ping.be#p http://groups.google.com/groups?hl=en==off=1=160b098279e28ca9,8=linux.kernel.F57chplw8IfbyyOxmQp000170f7%40hotmail.com#p Please cc me on any replies. thanx! Robert - 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] symlink.c
this patch adds a check to make sure memory was allocated, returns an
error code otherwise.
-john
--- fs/autofs4/symlink.c.orig Fri Apr 21 14:41:36 2000
+++ fs/autofs4/symlink.cSun Jun 3 00:43:18 2001
@@ -15,13 +15,15 @@
static int autofs4_readlink(struct dentry *dentry, char *buffer, int
buflen)
{
struct autofs_info *ino = autofs4_dentry_ino(dentry);
-
return vfs_readlink(dentry, buffer, buflen, ino->u.symlink);
}
static int autofs4_follow_link(struct dentry *dentry, struct nameidata
*nd)
{
struct autofs_info *ino = autofs4_dentry_ino(dentry);
+
+ if(!ino)
+ return -ENOMEM;
return vfs_follow_link(nd, ino->u.symlink);
}
-
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.4.5 gcc3 build patch
On Tue, Jun 12, 2001 at 04:27:33PM -0700, Richard Henderson wrote: > We fixed a bug in cv-qualification checking. > > timer.c:35: conflicting types for `xtime' > include/linux/sched.h:540: previous declaration of `xtime' > > There's no need for the volatile qualification here. One, being a > struct it doesn't do any good, and two it's protected by xtime_lock. wrong, the sec field of xtime is read all the time without any lock. so xtime can change under you it has to be declared volatile or C language will screwup. gcc 3.0 effectively spotted a bug in the kernel that wasn't exporting xtime as volatile. Right fix is this that I did just about 10 minutes ago after the 3.0 checkout ;) ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre2aa2/00_gcc-30-volatile-xtime-1 Andrea - 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] nfsfh.c
this seems to be an appropriate place to check this pointer and return an
error code if necessary.
-john
--- linux/fs/nfsd/nfsfh.c.orig Fri Feb 9 11:29:44 2001
+++ linux/fs/nfsd/nfsfh.c Sun Jun 3 01:23:13 2001
@@ -135,6 +135,9 @@
struct list_head *lp;
struct dentry *result;
inode = iget(sb, ino);
+ if(!inode)
+ return ERR_PTR(-ENOMEM);
+
if (is_bad_inode(inode)
|| (generation && inode->i_generation != generation)
) {
-
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: Getting A Patch Into The Kernel
On Tuesday 12 June 2001 18:34, Craig Lyons wrote: > We have a patch that fixes this and are wondering if it > is possible to get this patch into the kernel, and if so, how this would be > done? Well, you start by reading this: http://www.linuxhq.com/kernel/v2.4/doc/SubmittingPatches.html Which basically says that you post it here, with a title along the lines of: "[PATCH] promise IDE raid support". Start the body of your email with a brief description of the patch (the above is fine, mentioning that this is an official patch from promise is nice), and then include the patch itself at the end of the email in plain text. (Linus won't read Mime attachments, although others sometimes do and forward them to him. Sometimes.) You do know how to make a unified diff using "diff -u", right? (I'm assuming you have an includeable patch already prepared?) Also, try to use an email program that doesn't mangle whitespace. (It's a nit-pick, but it's good hygiene.) The difference between spaces and tabs is generally considered to be a good thing to maintain. Rob - 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.4.6pre2aa2 [was Re: 2.4.5aa1]
Diff between 2.4.6pre2aa1 and 2.4.6pre2aa2: - Only in 2.4.6pre2aa2/: 00_gcc-30-volatile-xtime-1 Fixes a kernel bug noticed by gcc-3_0-branch from cvs of today. Only in 2.4.6pre2aa2/: 00_sched-rt-fix-1 Re-merged fix lost in pre6aa1. -- Andrea - Diff between 2.4.5aa3 and 2.4.6pre2aa1 (besides moving on top of 2.4.6pre2): - Only in 2.4.5aa3: 00_alpha-compile-1 Only in 2.4.5aa3: 00_alpha-dp264-compile-1 Only in 2.4.5aa3: 00_alpha-rawhide-irq-1 Only in 2.4.5aa3: 00_bdev-inode-1 Only in 2.4.5aa3: 00_clear_inode-if-ext2-error-1 Only in 2.4.5aa3: 00_create_buffers-deadlock-1 Only in 2.4.5aa3: 00_eepro100-64bit-1 Only in 2.4.5aa3: 00_ioapic-2.4.5-1 Only in 2.4.5aa3: 00_fix-unusable-vm-on-alpha-1 Only in 2.4.5aa3: 00_gfp_buffer-alloc-pages-deadlock-1 Only in 2.4.5aa3: 00_local-apic-do_softirq-1 Merged in 2.4.6pre2 mainline. Only in 2.4.6pre2aa1: 00_alpha-compile-swapon-1 Fixes a compile problem for the alpha. Jeff noticed it as well. (recommended) Only in 2.4.6pre2aa1: 00_ide-oops-1 Fixes an oops in the ide stats from Kurt. (recommended) Only in 2.4.6pre2aa1: 00_irda-2.4.5ac13-1.bz2 Irda updates in sync with 2.4.5ac13. (nice to have) Only in 2.4.5aa3: 00_ksoftirqd-4 Only in 2.4.6pre2aa1: 00_ksoftirqd-5 ksoftirqd updates to work with the softirq updates in 2.4.6pre2. This fixes severe bugs like the fact do_softirq must not unconditionally re-enable interrupts before returning possibly generating an irq recursion that would overflow the stack. It also avoids to starve userspace and it lets the scheduler to balance the softirq flood. (recommended) Only in 2.4.6pre2aa1: 00_numa-compile-1 Fixes a numa compilation trouble introduced with the mm updates in 2.4.6pre2. (recommended) Only in 2.4.5aa3: 00_o_direct-7 Only in 2.4.6pre2aa1: 00_o_direct-8 Updates the O_DIRECT defines for sparc and sparc64 (approved by DaveM). (recommended) Only in 2.4.5aa3: 00_raisesoftirq-setbit-1 Dropped the set_bit in raisesoftirq, set_bit can only be run on an int. Noticed by DaveM. (ok on x86 it's harmless) (recommended) Only in 2.4.5aa3: 00_sched-rt-fix-1 Dropped by mistake sorry (I didn't catched the reject), will be reintroduced in a later version. Even if the bugfix was recommended this bug matters only in the rt corner case so it's not a showstopper. Only in 2.4.5aa3: 00_softirq-SMP-fixes-3 Only in 2.4.6pre2aa1: 00_softirq-fixes-4 Updated the memory barriers for clear_bit and friends to make the softirq code smp safe in architectures where the non conditional bitops and atomic operations are not also implicit memory barriers. (recommended) Only in 2.4.6pre2aa1: 00_x86-entry.S-fix-1 Showstopper x86 fix to avoid rescheduling and running signals when returning to kernel. (recommended) Only in 2.4.6pre2aa1: 00_xircom-tulip-cb-2.4.5ac13-1 Only in 2.4.5aa3: 00_xircom-tulip-cb-arjanv-2.bz2 Looks like mainline driver is been fixed, not merged the new driver anymore because the new driver hangs every few seconds, while the old one with this fix delivers the expected throughput. (nice to have) Only in 2.4.6pre2aa1: 10_expand-stack-smp-1 Only in 2.4.5aa3: expand-stack-smp-1 Renamed. Only in 2.4.5aa3/30_tux: 30_atomic-lookup-1 Only in 2.4.6pre2aa1/30_tux: 30_atomic-lookup-2 Only in 2.4.5aa3/30_tux: 30_tux-vfs-1 Only in 2.4.6pre2aa1/30_tux: 30_tux-vfs-2 Tux reject fixups. -- Andrea - Diff between 2.4.5aa1 and 2.4.5aa3: - Only in 2.4.5aa3: 00_alpha-compile-1 Only in 2.4.5aa3: 00_alpha-dp264-compile-1 Fixes CONFIG_ALPHA_GENERIC compile troubles and fix the right way the CONFIG_ALPHA_DP264 compile (included bootmem.h _after_ the __EXTERN_INLINE tricks. (recommended) Only in 2.4.5aa3: 00_alpha-rawhide-irq-1 Fix from Richard to cure bad networking performance on rawhide (disable irq right to avoid flood of reentrant nested irqs). (recommended) Only in 2.4.5aa3: 00_bdev-inode-1 Fix initrd issues (from 2.4.5ac). (recommended) Only in 2.4.5aa3: 00_bootmem-header-1 Comment change (from 2.4.5ac). (nice to have) Only in 2.4.5aa3: 00_clear_inode-if-ext2-error-1 Remember to clear_inode if the release of the inode in the superblock fails. (from 2.4.5ac) (nice to have) Only in 2.4.5aa3:
Re: threading question
On Tue, Jun 12, 2001 at 03:25:54PM -0400, Russell Leighton wrote:
> Any recommendations for alternate threading packages?
Does NSPR use native methods (ie, clone), or just ride on top of pthreads?
What about the gnu threading package?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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.4.5 gcc3 build patch
We fixed a bug in cv-qualification checking. timer.c:35: conflicting types for `xtime' include/linux/sched.h:540: previous declaration of `xtime' There's no need for the volatile qualification here. One, being a struct it doesn't do any good, and two it's protected by xtime_lock. r~ --- kernel/timer.c.orig Tue Jun 12 16:22:27 2001 +++ kernel/timer.c Tue Jun 12 16:24:06 2001 @@ -32,7 +32,7 @@ long tick = (100 + HZ/2) / HZ; /* timer interrupt period */ /* The current time */ -volatile struct timeval xtime __attribute__ ((aligned (16))); +struct timeval xtime __attribute__ ((aligned (16))); /* Don't completely fail for HZ > 500. */ int tickadj = 500/HZ ? : 1;/* microsecs */ - 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/
sound driver locking patches
Hello all,
I have attached sound driver locking patches for:
drivers/sound/cs4281/cs4281m.c
drivers/sound/i810_audio.c
The patches are against 2.4.5-ac13, and address the sound driver locking
issue mentioned in the -ac series.
Please review. Thanks.
Regards,
Frank
--- drivers/sound/cs4281/cs4281m.c.old Mon Jun 11 00:23:02 2001
+++ drivers/sound/cs4281/cs4281m.c Tue Jun 12 01:17:14 2001
@@ -293,6 +293,7 @@
struct cs4281_pm pm;
struct cs4281_pipeline pl[CS4281_NUMBER_OF_PIPELINES];
+ struct semaphore sem;
};
#include "cs4281pm-24.c"
@@ -2876,7 +2877,7 @@
{
struct cs4281_state *s =
(struct cs4281_state *) file->private_data;
- ssize_t ret;
+ ssize_t ret = 0;
unsigned long flags;
unsigned swptr;
int cnt;
@@ -2890,11 +2891,12 @@
return -ESPIPE;
if (s->dma_adc.mapped)
return -ENXIO;
- if (!s->dma_adc.ready && (ret = prog_dmabuf_adc(s)))
- return ret;
if (!access_ok(VERIFY_WRITE, buffer, count))
return -EFAULT;
- ret = 0;
+
+ down(>sem);
+ if (!s->dma_adc.ready && (ret = prog_dmabuf_adc(s)))
+ goto out;
//
// "count" is the amount of bytes to read (from app), is decremented each loop
// by the amount of bytes that have been returned to the user buffer.
@@ -2950,10 +2952,23 @@
// the loop when wake up occurs.
start_adc(s);
if (file->f_flags & O_NONBLOCK)
- return ret ? ret : -EAGAIN;
+ {
+ if(!ret) ret = -EAGAIN;
+ goto out;
+ }
+ up(>sem);
interruptible_sleep_on(>dma_adc.wait);
if (signal_pending(current))
- return ret ? ret : -ERESTARTSYS;
+ {
+ if(!ret) ret = -ERESTARTSYS;
+ goto out;
+ }
+ down(>sem);
+ if (s->dma_adc.mapped)
+ {
+ ret = -ENXIO;
+ goto out;
+ }
continue;
}
// there are bytes in the buffer to read.
@@ -2971,7 +2986,10 @@
if (cs_copy_to_user
(s, buffer, s->dma_adc.rawbuf + swptr, cnt, ))
- return ret ? ret : -EFAULT;
+ {
+ if(!ret) ret = -EFAULT;
+ goto out;
+ }
swptr = (swptr + cnt) % s->dma_adc.dmasize;
spin_lock_irqsave(>lock, flags);
s->dma_adc.swptr = swptr;
@@ -2984,6 +3002,8 @@
}
CS_DBGOUT(CS_FUNCTION | CS_WAVE_READ, 2,
printk(KERN_INFO "cs4281: cs4281_read()- %d\n", ret));
+out:
+ up(>sem);
return ret;
}
@@ -3007,10 +3027,12 @@
return -ESPIPE;
if (s->dma_dac.mapped)
return -ENXIO;
- if (!s->dma_dac.ready && (ret = prog_dmabuf_dac(s)))
- return ret;
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;
+ down(>sem);
+ if (!s->dma_dac.ready && (ret = prog_dmabuf_dac(s)))
+ goto out;
+
ret = 0;
while (count > 0) {
spin_lock_irqsave(>lock, flags);
@@ -3035,14 +3057,30 @@
if (cnt <= 0) {
start_dac(s);
if (file->f_flags & O_NONBLOCK)
- return ret ? ret : -EAGAIN;
+ {
+ if(!ret) ret = -EAGAIN;
+ goto out;
+ }
+ up(>sem);
interruptible_sleep_on(>dma_dac.wait);
if (signal_pending(current))
- return ret ? ret : -ERESTARTSYS;
+ {
+ if(!ret) ret = -ERESTARTSYS;
+ goto out;
+ }
+ down(>sem);
+ if (s->dma_dac.mapped)
+ {
+ ret = -ENXIO;
+ goto out;
+ }
continue;
}
if (copy_from_user(s->dma_dac.rawbuf + swptr, buffer, cnt))
- return ret
Re: Getting A Patch Into The Kernel
Hi, this is the correct forum. You can submit the patch here. Merely paste the patch output inline into your email, and make your subject "[PATCH] 2.4.5 FastTrak RAID Whatever Fix" and explain in the email. Note your code must become GPL licensed. I would suggest making the patch against the latest kernel, 2.4.5 -- or even better, 2.4.5-ac13 or 2.4.6-pre2. I suggest reading linux/Documentation/SubmittingPatches for coding standards, etc. It is good to see manufactures supporting their products in Linux, thank you! -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] On 12 Jun 2001 15:34:43 -0700, Craig Lyons wrote: > Hello, > > My name is Craig Lyons and I am the marketing manager at Promise Technology. > We have a question and are hoping you can point us in the right direction. > In the 2.4 kernel there is support for some of our products (Ultra 66, Ultra > 100, etc.). As you may or may not know, our Ultra family of controllers > (which are just standard IDE controllers and do not have RAID) use the same > ASIC on them as our FastTrak RAID controllers do. The 2.4 kernel will > recognize our Ultra family of controllers, but there is a problem in that a > FastTrak will not be recognized as a FastTrak, but as an Ultra. > Consequently, the array on the FastTrak is not recognized as an array, but > instead each disk is seen individually, and the users data cannot be > properly accessed. We have a patch that fixes this and are wondering if it > is possible to get this patch into the kernel, and if so, how this would be > done? > > I apologize if this is the incorrect e-mail to be making this request to. If > this is not the correct address to be posting this message, any assistance > as to where it should be directed would be greatly appreciated. > > Regards, > > Craig - 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] Re: Via-rhine in 2.4.5 still requires cold-boot
Bjorn Wesen wrote:
> Just for the record, the via-rhine.c in 2.4.5 still does not work if you
> soft-boot the computer (at least one a machine here), MAC address shows up
> as 00:00:00:00:00:00 and it fails - but a cold boot (power cable off, no
> standby power) makes it work.
This patch in gkernel cvs, against 2.4.5, should fix things. It is
going to Linus as soon as pre3 appears and I can start syncing up with
him again.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
Index: linux_2_4/drivers/net/via-rhine.c
diff -u linux_2_4/drivers/net/via-rhine.c:1.1.1.27
linux_2_4/drivers/net/via-rhine.c:1.1.1.27.74.2
--- linux_2_4/drivers/net/via-rhine.c:1.1.1.27 Sun Apr 22 18:24:17 2001
+++ linux_2_4/drivers/net/via-rhine.c Sun Jun 10 12:07:42 2001
@@ -1,6 +1,6 @@
/* via-rhine.c: A Linux Ethernet device driver for VIA Rhine family chips. */
/*
- Written 1998-2000 by Donald Becker.
+ Written 1998-2001 by Donald Becker.
This software may be used and distributed according to the terms of
the GNU General Public License (GPL), incorporated herein by reference.
@@ -58,6 +58,12 @@
LK1.1.7:
- Manfred Spraul: added reset into tx_timeout
+
+ LK1.1.9:
+ - Urban Widmark: merges from Beckers 1.10 version
+(media selection + eeprom reload)
+ - David Vrabel: merges from D-Link "1.11" version
+(disable WOL and PME on startup)
*/
@@ -75,6 +81,11 @@
Both 'options[]' and 'full_duplex[]' should exist for driver
interoperability.
The media type is usually passed in 'options[]'.
+ The default is autonegotation for speed and duplex.
+ This should rarely be overridden.
+ Use option values 0x10/0x20 for 10Mbps, 0x100,0x200 for 100Mbps.
+ Use option values 0x10 and 0x100 for forcing half duplex fixed speed.
+ Use option values 0x20 and 0x200 for forcing full duplex operation.
*/
#define MAX_UNITS 8/* More are supported, limit only on options */
static int options[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
@@ -104,6 +115,9 @@
#define PKT_BUF_SZ 1536/* Size of each temporary Rx
buffer.*/
+/* max time out delay time */
+#define W_MAX_TIMEOUT 0x0FFFU
+
#if !defined(__OPTIMIZE__) || !defined(__KERNEL__)
#warning You must compile this file with the correct options!
@@ -132,9 +146,10 @@
/* These identify the driver base version and may not be removed. */
static char version[] __devinitdata =
-KERN_INFO "via-rhine.c:v1.08b-LK1.1.8 4/17/2000 Written by Donald Becker\n"
+KERN_INFO "via-rhine.c:v1.10-LK1.1.9 05/31/2001 Written by Donald Becker\n"
KERN_INFO " http://www.scyld.com/network/via-rhine.html\n;;
+static char shortname[] __devinitdata = "via-rhine";
/* This driver was written to use PCI memory space, however most versions
@@ -165,8 +180,12 @@
MODULE_PARM(rx_copybreak, "i");
MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i");
MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i");
+MODULE_PARM_DESC(max_interrupt_work, "VIA Rhine maximum events handled per
+interrupt");
+MODULE_PARM_DESC(debug, "VIA Rhine debug level (0-7)");
+MODULE_PARM_DESC(rx_copybreak, "VIA Rhine copy breakpoint for copy-only-tiny-frames");
+MODULE_PARM_DESC(options, "VIA Rhine: Bits 0-3: media type, bit 17: full duplex");
+MODULE_PARM_DESC(full_duplex, "VIA Rhine full duplex setting(s) (1)");
-
/*
Theory of Operation
@@ -244,6 +263,9 @@
Preliminary VT86C100A manual from http://www.via.com.tw/
http://www.scyld.com/expert/100mbps.html
http://www.scyld.com/expert/NWay.html
+ftp://ftp.via.com.tw/public/lan/Products/NIC/VT86C100A/Datasheet/VT86C100A03.pdf
+ftp://ftp.via.com.tw/public/lan/Products/NIC/VT6102/Datasheet/VT6102_021.PDF
+
IVc. Errata
@@ -256,7 +278,6 @@
*/
-
/* This table drives the PCI probe routines. It's mostly boilerplate in all
of the drivers, and will likely be provided by some future kernel.
Note the matching code -- the first table entry matchs all 56** cards but
@@ -320,9 +341,9 @@
StationAddr=0x00, RxConfig=0x06, TxConfig=0x07, ChipCmd=0x08,
IntrStatus=0x0C, IntrEnable=0x0E,
MulticastFilter0=0x10, MulticastFilter1=0x14,
- RxRingPtr=0x18, TxRingPtr=0x1C,
+ RxRingPtr=0x18, TxRingPtr=0x1C, GFIFOTest=0x54,
MIIPhyAddr=0x6C, MIIStatus=0x6D, PCIBusConfig=0x6E,
- MIICmd=0x70, MIIRegAddr=0x71, MIIData=0x72,
+ MIICmd=0x70, MIIRegAddr=0x71, MIIData=0x72, MACRegEEcsr=0x74,
Config=0x78, ConfigA=0x7A, RxMissed=0x7C, RxCRCErrs=0x7E,
StickyHW=0x83, WOLcrClr=0xA4, WOLcgClr=0xA7, PwrcsrClr=0xAC,
};
@@ -448,24 +469,29 @@
static int via_rhine_close(struct net_device *dev);
static inline void clear_tally_counters(long ioaddr);
-static void wait_for_reset(struct net_device *dev)
+static void wait_for_reset(struct net_device *dev, char *name)
Getting A Patch Into The Kernel
Hello, My name is Craig Lyons and I am the marketing manager at Promise Technology. We have a question and are hoping you can point us in the right direction. In the 2.4 kernel there is support for some of our products (Ultra 66, Ultra 100, etc.). As you may or may not know, our Ultra family of controllers (which are just standard IDE controllers and do not have RAID) use the same ASIC on them as our FastTrak RAID controllers do. The 2.4 kernel will recognize our Ultra family of controllers, but there is a problem in that a FastTrak will not be recognized as a FastTrak, but as an Ultra. Consequently, the array on the FastTrak is not recognized as an array, but instead each disk is seen individually, and the users data cannot be properly accessed. We have a patch that fixes this and are wondering if it is possible to get this patch into the kernel, and if so, how this would be done? I apologize if this is the incorrect e-mail to be making this request to. If this is not the correct address to be posting this message, any assistance as to where it should be directed would be greatly appreciated. Regards, Craig Craig Lyons Marketing Manager Promise Technology 1460 Koll Circle San Jose, CA 95112 USA Voice - 408-452-0948 ext. 241 Fax - 408-452-1534 [EMAIL PROTECTED] http:\\www.promise.com - 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/
Via-rhine in 2.4.5 still requires cold-boot
Just for the record, the via-rhine.c in 2.4.5 still does not work if you soft-boot the computer (at least one a machine here), MAC address shows up as 00:00:00:00:00:00 and it fails - but a cold boot (power cable off, no standby power) makes it work. I read something that we'd need to reload the EEPROM on the boards or something if a cold-boot solves a problem. Well it does. :) /BW - 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] Inode quota allocation loophole (2.2) (fwd)
Hello, > Alan pointed out that you're still the maintainer for the 2.2 quota > code, so I'm forwarding this patch to you as well as the earlier 2.4 > patch. The patch seems fine (although I can't quite understand those double - in it :)). Honza - 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] Inode quota allocation loophole (2.4)
Hello, > Currently, dquot_initialize() is a no-op if the inode being initialized > isn't a regular file, directory or symlink. This means that calling > DQUOT_ALLOC_INODE() on a named pipe or AF_UNIX socket has no effect (the > same applies to devices, but this is less likely to be a problem as > random users can't create them); as a result a user can exhaust the > filesystem's inodes even when they have a quota limit. This problem is > exploitable in 2.2.19 and 2.4.2, and appears to be present in all kernel > versions that I've looked at. > > I presume that the reason for not putting quotas on pipes and sockets is > that it's slightly more efficient not to do so. If that's the case, then > the simplest solution would be to remove the checks in fs/dquot.c (patch > below for 2.4.5 - patch for 2.2 in following email). Are there any > undesirable consequences to pipes, sockets and devices having non-NULL > pointers in i_dquot[]? I must admit that I don't know why we don't count quotas also for device/pipe/socket inodes. This behaviour was there for ages :). Maybe it's time to change it. I can't think of any problems which can be with it... Your patch seems to be fine. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE Labs - 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 2.4.5-ac12] New Sony Vaio Motion Eye camera driver
On Tue, 12 Jun 2001, Alex Deucher wrote: > > As far as I know they have not been integrated into the Xfree tree. I > believe there were some disagreements about extending the Xv API since > GATOS added some extentions to support the AIW video capture cards. I > suppose someone could try and submit a patch again and see if they'll > take it. I got just the YUV code from Gatos, and a few months ago it took less than an hour to merge just that part (and most of that was compiling and testing). The rest of Gatos is obviously more experimental, but the YUV code looks quite sane. > Also there is some work on a new XvMC interface that would allow for > extended DVD acceleration. Yes. Although I hope it's going to be XvMPG2 or something - some cards literally do all of the mpeg2 stuff, not just parts of it, and limiting yourself to just the motion comp is limiting the protocol quite badly. Linus - 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 2.4.5-ac12] New Sony Vaio Motion Eye camera driver
On 12 Jun, Alex Deucher wrote: > Also there is some work on a new XvMC interface that would allow for > extended DVD acceleration. Extended DVD acceleration with Motion-Compensation? How? Servus, 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/
Functionality of mmap, nopage and remap_page_range
Hi kernel list readers, I have a question about the functionality of mmap(), vma->vm_ops functions and different vma->vm_flags. Is there any documentation that describes these methods and how they should work (i.e when should mmap() use remap_page_range and when is the vma->vm_ops->no_page function called) Any help appreciated. -- Steffen Persvold Systems Engineer Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com) Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6 Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway - 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/
PROBLEM: Reiserfs + 3Ware issue with 2.4.5
1. Reiserfs + 3Ware issue with 2.4.5 2. I'm building a rescue cd based on Timo's Rescue CD v. 0.5.4. I've compiled the 2.4.5 kernel to be a 386, all scsi controllers I might encounter compiled in, software raid, reisersfs compiled in. The only modules are scsi tapes, network cards, nfs and smbfs support. When I boot my K6II-350 Box (128 MB memory) off the cd, it boots up and eventually gets me to my prompt. In the process the insmod of 3c59x gives me the following error: /lib/modules/2.4.5/kernel/drivers/net/3c59x.o: unresolved symbol del_timer_sync (This is just something I noticed along the way which is annoying but not a show stopper yet.) The real issue is when after mounting my filesystems off the 3ware card and going to unmount them the following happens: bash# umount tmp journal_begin called without kernel lock held kernel BUG at journal.c:423! invalid operand: CPU:0 EIP: 0010:[] EFLAGS: 00010282 eax: 001d ebx: c65aff24 ecx: c65f4000 edx: 0001 esi: c4a1e800 edi: ebp: 3b26397a esp: c65afeac ds: 0018 es: 0018ss: 0018 Process umount (pid: 116, stackpage=c65af000) Stack: c027b0cc c027b264 01a7 c017b62f c027c281 5b86 0808 c0106fb0 5b86 c48f1e50 c48f1df0 c65aff24 c4a1e800 c02c3560 c02c35d8 c017b857 c65aff24 c4a1e800 000a c016e064 c65aff24 Call Trace: [] [] [] [] [] [] [] [][][][] Code: 0f 0b 83 c4 0c c3 8d 76 00 31 c0 c3 90 31 c0 c3 90 53 31 db Segmentation fault bash# /boot is ext2 /, /home, /tmp, /var, /usr are all reiserfs -- As long as I don't retry to unmount the filesystem or unmount another filesystem the system is still usable. But when I try to unmount another filesystem that process just appears to go into a never ending state. Once I've locked up all my consoles I can only hit the reset button :( ps ax shows: 51 tty3 SW 0:00 [kreiserfsd] 119 tty3D 0:00 umount home I can get to my other virtual console and still look into the currently mounted filesystems, I just can't shutdown the box, kill the umount process, etc. I can even look into the filesystem mounted as home that I am currently trying to umount as seen in the ps output. The box is currently running a RH 7.1 system with a custom built 2.4.2 kernel so I know reiserfs and the 3ware card work correctly before 2.4.5. :) ver_linux shows (on my box that built the kernel): Linux navi.zelda.pcxperience.com 2.4.5 #1 Sat Jun 2 13:26:40 CDT 2001 i586 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.10s mount 2.11b modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0f PPP2.4.0 isdn4k-utils 3.1pre1 Linux C Library2.2.3 Dynamic linker (ldd) 2.2.3 Procps 2.0.7 Net-tools 1.57 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded tdfx 3c59x sb sb_lib uart401 sound soundcore I'm attaching my .config file if that helps. I can't really provide more output from the test box as I am having to manually type stuff in on my other machine (in this email). :( -- James A. Pattie [EMAIL PROTECTED] Linux -- SysAdmin / Programmer PC & Web Xperience, Inc. http://www.pcxperience.com/ # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_M386=y # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_X86_CMPXCHG is not set # CONFIG_X86_XADD is not set CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_MATH_EMULATION=y # CONFIG_MTRR is not set CONFIG_SMP=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCI_NAMES is not set # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set
Re: XFS and Alan kernel tree
On Sat, May 05, 2001 at 11:08:16PM +0200, Daniel Podlejski wrote: > I merge XFS witch Alan tree (2.4.4-ac5). It's seems to be stable. > Patch against Alan tree is avaliable at: Hi Daniel, I've got a KDB patch against a relatively recent 2.4.5-ac6, but are you still continuing your porting effort to the -ac series? Thanks, d -- Daniel Stone<[EMAIL PROTECTED]> <[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: es1371 and recent kernels
> > > > My ES1370 has done me good. You might want to try that card. Yes it's a > > > > creative card. It only has a crackle running 22k 8-bit > > > Argh, I had one of those, gave it away because it would hang my alpha > > hard (I'm told the card is pretty nonconformant to the PCI spec). > > *sigh* > > Now you tempt me to find this card and fix the alpha problem :) PLEASE!!! =) I'll help test it! I got a 1371 on my alpha -- Lab tests show that use of micro$oft causes cancer in lab animals - 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: es1371 and recent kernels
Bob McElrath wrote: > > Wakko Warner wrote: > > > My ES1370 has done me good. You might want to try that card. Yes it's a > > > creative card. It only has a crackle running 22k 8-bit > Argh, I had one of those, gave it away because it would hang my alpha > hard (I'm told the card is pretty nonconformant to the PCI spec). > *sigh* Now you tempt me to find this card and fix the alpha problem :) -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - 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: es1371 and recent kernels
Jeff Golds [[EMAIL PROTECTED]] wrote: > Wakko Warner wrote: > > > > My ES1370 has done me good. You might want to try that card. Yes it's a > > creative card. It only has a crackle running 22k 8-bit > > > > It's probably better because that is the AudioPCI chip from Ensoniq > before Creative bought them. I thought that was a good chip, too. Argh, I had one of those, gave it away because it would hang my alpha hard (I'm told the card is pretty nonconformant to the PCI spec). *sigh* Nobody out there uses a non-Create PCI card? (oh and not Aureal either) Cheers, -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics PGP signature
Re: 2.4.6-pre2 VM
On Tue, Jun 12, 2001 at 01:17:05AM -0300, Rik van Riel wrote: > On Mon, 11 Jun 2001, Alok K. Dhir wrote: > > > Just wondering - has anyone who was having issues with the VM > > subsystem in 2.4.5 and a few versions below tried v2.4.6-pre2? > > Is the problem reduced and/or resolved? > > The answer is both yes and no, depending on which VM problem > you're talking about. ;) What is about the problem that 2.4.x is swapping out too much? Are there currently any patches for testing? Or are there some values in proc which can change this bad vm-behaviour? - 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 2.4.5-ac12] New Sony Vaio Motion Eye camera driver
As far as I know they have not been integrated into the Xfree tree. I believe there were some disagreements about extending the Xv API since GATOS added some extentions to support the AIW video capture cards. I suppose someone could try and submit a patch again and see if they'll take it. Also there is some work on a new XvMC interface that would allow for extended DVD acceleration. Alex -- On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote: > > On 10 Jun, Linus Torvalds wrote: > > > I've not figured out why the ATI Xv stuff from gatos seems to not have > > made it into the XFree86 CVS tree - it works better than much of the > > Xv stuff for some other chipsets that _are_ in the CVS tree. > > > > I imported it into the XFree86 CVS some months ago, it was trivial. I > > don't have the patches lying around any more, though. I can try to > > re-create them if anybody needs help. > > Did it look endiansafe to you? The ATI Xv stuff from XFree86 4.1.0 > produces psychadelic results for me on PPC. I have to say that I have absolutely no idea. I only use little-endian machines myself (and 99% x86). Also, which ATI Xv stuff are you talking about? The ATI Rage128 and ATI Radeon Xv code was at least a few months ago completely separate from the ATI Rage code (the first two were in X CVS, while the latter only existed in the gatos version). Has the Gatos code (or some other code) maybe been integrated into 4.1.0 now? I haven't followed X CVS for the last months very closely.. Linus - 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: Clock drift on Transmeta Crusoe
--- Pavel Machek <[EMAIL PROTECTED]> wrote: > Let me guess: vesafb? I am running vesafb, yes... > If problem goes away when you stop using framebuffer > (i.e. go X), then > it is known. but the problem happens in X as well :) > You are lucky. My machine is able to loose 2 minutes > from every 3 > minutes. Indeed :) Thanks, it seems like mine is just a normal drift. Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - 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: Clock drift on Transmeta Crusoe
--- Jonathan Morton <[EMAIL PROTECTED]> wrote: > >> clock drift of a few minutes per day. > > That's about 0.1%. It may be relatively large > compared to tolerances of > hardware clocks, but it's realistically tiny. It > certainly compares > favourably with mkLinux on my PowerBook 5300, which > usually drifts by > several hours per day regardless of actual load. Several hours a day, gosh... Thanks for the responses, is it a common problem in notebooks then? Did not notice this on desktops before, anyway trying to adjust for the drift using adjtimex now. Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - 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/
Menuconfig has encountered a possible error...
Hello, if you want more informations, send me a mail or an icq msg. bye, Mat (ICQ# 23832402). === Menuconfig has encountered a possible error in one of the kernel's configuration files and is unable to continue. Here is the error report: Q> scripts/Menuconfig: MCmenu53: command not found Please report this to the maintainer <[EMAIL PROTECTED]>. You may also send a problem report to <[EMAIL PROTECTED]>. Please indicate the kernel version you are trying to configure and which menu you were trying to enter when this error occurred. make: *** [menuconfig] Error 1 nostromo:/usr/src/linux# uname -a Linux nostromo 2.4.5 #10 Sat Jun 9 13:34:54 CEST 2001 i686 unknown nostromo:/usr/src/linux# - 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/
Make fat compile again
The following makes fat/inode.c compile on ARM systems (and probably many others). fat/inode.c uses ffs(), which is defined in asm/bitops.h. ARM uses generic_ffs() which is in turn defined in linux/bitopts.h. (linux/bitops.h includes asm/bitops.h) diff -urN orig/fs/fat/inode.c linux/fs/fat/inode.c --- orig/fs/fat/inode.c Thu May 24 18:36:34 2001 +++ linux/fs/fat/inode.cTue Jun 12 10:44:35 2001 @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: es1371 and recent kernels
Wakko Warner wrote: > > My ES1370 has done me good. You might want to try that card. Yes it's a > creative card. It only has a crackle running 22k 8-bit > It's probably better because that is the AudioPCI chip from Ensoniq before Creative bought them. I thought that was a good chip, too. -Jeff -- Jeff Golds Sr. Software Engineer [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/
severe FS corruption with 2.4.6-pre2 + IBM jfs 0.3.4 patch
It's probably a JFS issue, but I thought I'd report this in case someone is collecting and correlating filesystem corruption messages (Alan?). Here is my sad story. I have an Athlon 700MHZ, 256mb ram, AIC7XXX w 2/U2W drives system. I've been running JFS on a small partition for a few weeks, JFS 0.3.1 under 2.4.5, 0.3.3 with 2.4.6-pre1 and yesterday I tried 2.4.6-pre2 with jfs 0.3.4. I rebooted into the new kernel, and noticed one of those Red Hat [FAIL] messages that pops up during the rc/init stages. It's a config problem I've had for months, nothing new, but I decided I'd take care of it. I logged into the console, ran emacs and it segfaulted. I ran 'dmesg' but there was nothing (I was expecting to see an oops). I ran emacs again, segfault. I tried logging in to another console, hang. At this point I hit sysrq-T, and of everything that spewed by, I noticed one process (which had scrolled to far off the screen to see the PID) with a whole lot of in the stack trace. At this point I did sysrq-S-U-B and rebooted. End of story. My filesystems were severely f***ed at this point. A total of about 60 seconds running this kernel and I was dead. My OS partition was trashed, about 1/2 of it was unrecoverable. My home partition fared better (good luck) but still had plenty of trashed inodes. I've never had problems with any kernels before this... That's my story, David -- David Mansfield (718) 963-2020 [EMAIL PROTECTED] Ultramaster Group, LLC www.ultramaster.com - 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: es1371 and recent kernels
> > [please be kind and Cc when replying] > > > > Has someone been able to get es1371 to actually produce anything > > audible with latest kernels? The last version I could use was 2.4.0. > > Then I had some trouble but I attributed them to devfs. Now I've > > removed devfs and still I'm not able to play anything. > > Works for me, but it produces all kinds of crackly noise garbage. I'm > not sure if this is because the driver has a bug, or the sound card is > a piece of flaming shit. But I'm inclined to believe the latter. > > Anybody have a suggestion for a card that isn't a flaming piece of shit, > (and not made by Creative) less than $100 US, PCI, supported by linux, > and available? My ES1370 has done me good. You might want to try that card. Yes it's a creative card. It only has a crackle running 22k 8-bit -- Lab tests show that use of micro$oft causes cancer in lab animals - 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: rsync hangs on RedHat 2.4.2 or stock 2.4.4
On Tue, Jun 12, 2001 at 11:23:02AM -0400, Disconnect wrote: > On Tue, 12 Jun 2001, David S. Miller did have cause to say: > > > Look everyone, it was determined to be a deadlock because of some > > interaction between how rsync sets up it's communication channels > > with the ssh subprocess, readas: userland bug. > > we're not using ssh. :( Neither am/was I. The rsync is within a single FS. Aside from that, here is the original bug report by Matthias Schniedermeyer: http://marc.theaimsgroup.com/?l=linux-kernel=98157768131423=2 with no reply. My report: http://marc.theaimsgroup.com/?l=linux-kernel=98262067309185=2 with myself replying :) Russell King's report: http://marc.theaimsgroup.com/?l=linux-kernel=98326853429463=2 which gave a fair amount of discussion. Note that in my report I state that the problem cannot be seen with smaller workloads; I have to try with at least drivers/* before it shows itself. Hmm, just tried with 243-ac12 (yeah, I'm way behind). I have to try the full tree now, drivers/* wont do it anymore. -- Regards, Rasmus([EMAIL PROTECTED]) "An intellectual is someone who has been educated beyond their intelligence." - 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.4.5 data corruption
Folks, I believe I have a reproducible test case which corrupts data in 2.4.5. We do nightly, weekly, and monthly backups by copying our entire /home partition on the company file server: FilesystemSize Used Avail Use% Mounted on /dev/hda1 1.9G 1.7G 123M 93% / /dev/hda6 1.9G 437M 1.4G 23% /tmp /dev/sda1 37G 26G 11G 71% /home /dev/sdc1 37G 26G 11G 70% /weekly /dev/sdd1 37G 24G 13G 65% /monthly /dev/sdb1 37G 26G 11G 71% /nightly The sd? drives are actually ide drives on a 3ware escalade controller. I have reason to believe the drives are good, before I installed them I scrubbed them with varying data patterns and verified that that I got back what I put there. All tested cleanly overnight. I recently added an integrity check to our backups - the integrity checker writes out the path, the gzip adler32 checksum, the size, and the mtime of each file. Each time I do a backup, the backup scripts look for the integrity listing in the other partitions and compares all files with the same path, size, and modtime. This morning I had a pile of errors after things having gone smoothly for the last few weeks. I suspected that I had screwed something up, looked over the backup scripts, simplified them down to a simple cpio, and tried again. Another pile of errors, different set of files. In both cases, the newly created files were corrupted, the ones on the live /home partition as well as the /weekly & /monthly partitions all compared cleanly. I rebooted into 2.2.19, tried again, no errors. I was running 2.4.5, no patches. I power cycled the machine between each reboot, went through the bios memory check, and also went through my own memory check; memory does not seem to be an issue. I think I can reproduce this, it takes a reboot and about 2 hours. I made it happen twice with 2.4.5, the first try on 2.2.19 did not work. The data corruption looks like *extra* bytes added at the beginning of files. I only looked at a few, if we go down the path of debugging this I'll save them all next time. The extra byte counts were small, in one case there was the letter "1" added to the start of the file, other than that it was identical. That's really weird, as a file system guy, I'd expect to see blocks of data not small chunks of data. Very strange. One thing I haven't done is to rule out the 3ware controller. I tend to doubt it is the problem but who knows. There were no kernel messages complaining about anything during the backup, so the kernel doesn't seem to know there is a problem. So, does anyone recognize these symptoms? Does anyone care? - 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: PC keyboard rate/delay
On Tue, Jun 12, 2001 at 06:19:49PM +0400, Sergey Tursanov wrote: > In file include/linux/kd.h was declared KDKBDREP ioctl number > But in 2.4.x kernel there is only m68k version for that. > I wrote some code for implement this feature on x86 machines. Yes, it is unfortunate that many ioctls are needlessly different between various architectures. But the utility kbdrate works on all architectures I have tried it on. Andries - 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: from dmesg: kernel BUG at inode.c:486
Hi all, this is try two, I just read the mailinglist FAQ and used ksymoops to translate the symbols. Today my girlfriend reported all programs that accessed my NFS mounted drive where crashing. Prevously to this, she did a lot of deleting and moving around of files on the NFS drive. I use (Debian Woody) with Linux 2.4.5 on the client: olivier@aria:~ $ uname -a Linux aria 2.4.5 #4 Mon May 28 18:19:37 CEST 2001 i686 unknown The kernel is build by myself using this gcc: olivier@aria:~ $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20010319 (Debian prerelease) I used these .config options (for NFS): CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y The client is a ABIT BE6 motherboard, PIII450, 256MB ram, IBM-DTLA-307045 IDE disk on HPT366 onboard controller running udma4, SMC etherpowerII NIC running full duplex 100Mbit, NCR860 scsi board, miro pctv tv card and an old ensoniq soundscape isa card. The server is a very old install, running user-space NFS daemon: fender:~$ /usr/sbin/rpc.nfsd --version Universal NFS Server 2.2beta41 The server doesn't show any warning in any logfile. this is the output from dmesg, used ksymoops to decode the symbols: Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 19 68 e8 01 00 00 68 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: f6 83 f4 00 00 00 10 testb $0x10,0xf4(%ebx) Code; 000c Before first symbol c: 75 19 jne27 <_EIP+0x27> 0027 Before first symbol Code; 000e Before first symbol e: 68 e8 01 00 00push $0x1e8 Code; 0013 Before first symbol 13: 68 00 00 00 00push $0x0 kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: cc703ba0 ecx: 0001 edx: c025ba84 esi: c025ec60 edi: c976eac0 ebp: c32fdfa4 esp: c32fdeec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 1193, stackpage=c32fd000) Stack: c021b86d c021b8cc 01e6 cc703ba0 c01409c7 cc703ba0 cceee320 cc703ba0 c015e62a cc703ba0 c013e5d6 cceee320 cc703ba0 cceee320 c013723c cceee320 c32fdf68 c013795a c976eac0 c32fdf68 c8587000 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 19 68 e8 01 00 00 68 >>EIP; c013fffb<= Trace; c01409c7 Trace; c015e62a Trace; c013e5d6 Trace; c013723c Trace; c013795a Trace; c0137f68 <__user_walk+3c/58> Trace; c0135276 Trace; c0106a7b Trace; c010002b Code; c013fffb <_EIP>: Code; c013fffb<= 0: 0f 0b ud2a <= Code; c013fffd 2: 83 c4 0c add$0xc,%esp Code; c014 5: f6 83 f4 00 00 00 10 testb $0x10,0xf4(%ebx) Code; c0140007 c: 75 19 jne27 <_EIP+0x27> c0140022 Code; c0140009 e: 68 e8 01 00 00push $0x1e8 Code; c014000e 13: 68 00 00 00 00push $0x0 kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: c62eb840 ecx: 0001 edx: c025ba84 esi: c025ec60 edi: c976eac0 ebp: c7135fa4 esp: c7135eec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 1239, stackpage=c7135000) Stack: c021b86d c021b8cc 01e6 c62eb840 c01409c7 c62eb840 cf7285e0 c62eb840 c015e62a c62eb840 c013e5d6 cf7285e0 c62eb840 cf7285e0 c013723c cf7285e0 c7135f68 c013795a c976eac0 c7135f68 c89ac000 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 19 68 e8 01 00 00 68 >>EIP; c013fffb<= Trace; c01409c7 Trace; c015e62a Trace; c013e5d6 Trace; c013723c Trace; c013795a Trace; c0137f68 <__user_walk+3c/58> Trace; c0135276 Trace; c0106a7b Trace; c010002b Code; c013fffb <_EIP>: Code; c013fffb<= 0: 0f 0b ud2a <= Code; c013fffd 2: 83 c4 0c add$0xc,%esp Code; c014 5: f6 83 f4 00 00 00 10 testb $0x10,0xf4(%ebx) Code; c0140007 c: 75 19 jne27 <_EIP+0x27> c0140022 Code; c0140009 e: 68 e8 01 00 00push $0x1e8 Code; c014000e 13: 68 00 00 00 00push $0x0 kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: c62ebde0 ecx: 0001 edx: c025ba84 esi: c025ec60 edi: c976eac0 ebp: c32fdfa4 esp: c32fdeec
Re: threading question
In article <[EMAIL PROTECTED]> you wrote: > For heavy threading, try a user-level threads package. Sure, userlevel threading is the best way to get SMP-scalability... -- Of course it doesn't work. We've performed a software upgrade. - 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: threading question
Any recommendations for alternate threading packages? Alexander Viro wrote: > On Tue, 12 Jun 2001, Kip Macy wrote: > > > implementation of threads is not an accidental oversight, threads are not > > looked upon favorably by most of the core linux kernel hackers. A quote > > s/threads/POSIX threads/. > > - > 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/ -- --- Russell Leighton[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: 2.2.19: eepro100 and cmd_wait issues
Or you could keep your hardware and try the Intel driver, which seems to work fine. It only works as a module, though. This might also help narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue. Personally, I've found the EtherExpress hardware and eepro100 driver to be flawless in production on both single and dual units, card and built-in. It's the first choice for Linux now that Tulip has somewhat faded from view, AFAIC. I have heard mentioned on this list that the Intel driver is necessary for some (older?) cards, however. OT: does anyone know what the current state of the Tulip driver is and if there is good hardware out there? SMC left Tulip and went through at least two other chipsets, so the only Tulip card I could find as of a couple of years ago was Digital's. But it was astonishingly expensive and not clearly supported by the Linux driver. Thanks, -- Ken. On Tuesday, June 12, 2001, at 11:51 AM, Florin Andrei wrote: > On 12 Jun 2001 13:00:41 -0500, John Madden wrote: >> >> kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! >> kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! > > I have the same problem, since a long time, with various 2.2 and 2.4 > kernels running on a i815 motherboard, with on-board eepro100 net card. > >> The only solution I've found that works is to reboot, and since this is > > For me, it's enough to "ifconfig down" then "ifconfig up" the interface. > > I will probably buy another network card, since changing the OS is not > an option, and Linux seems to not like eepro100 that much... :-/ > > -- > Florin Andrei > > - > 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/ - 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: threading question
On Tue, 12 Jun 2001, Kip Macy wrote: > implementation of threads is not an accidental oversight, threads are not > looked upon favorably by most of the core linux kernel hackers. A quote s/threads/POSIX threads/. - 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: threading question
On Tue, Jun 12, 2001 at 01:07:11PM -0600, [EMAIL PROTECTED] wrote: > Hello, > > due to the nature of the problem (a pairwise mutual alignment of n > sequences results in mx. n^2 alignments which can each be done in a > separate thread), I need to create and destroy the threads frequently. > > I am not really comfortable with 1.4 - 1.5 speedups since the solution was > intended as a Linux one primarily and it just happenned that it works (and > now even better) on Solaris/SGI/OSF... If you havily create threads under load you're rather srewed. If you want to stay with the (IMHO rather suboptimal) posix threads API you might want to take a look at the stuff IBM has produced: http://oss.software.ibm.com/developerworks/projects/pthreads/ Otherwise a simple wrapper for clone might be a _lot_ faster, but has it's own disadvantages: no ready-to-use lcoking primitives, no cross-platform support (ok, it should be portable to the FreeBSD rfork easily). Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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: threading question
For heavy threading, try a user-level threads package. -Kip On Tue, 12 Jun 2001 [EMAIL PROTECTED] wrote: > Hello, > > due to the nature of the problem (a pairwise mutual alignment of n > sequences results in mx. n^2 alignments which can each be done in a > separate thread), I need to create and destroy the threads frequently. > > I am not really comfortable with 1.4 - 1.5 speedups since the solution was > intended as a Linux one primarily and it just happenned that it works (and > now even better) on Solaris/SGI/OSF... > > Best regards, > Ognen > > On Tue, 12 Jun 2001, Christoph Hellwig wrote: > > > In article <[EMAIL PROTECTED]> you wrote: > > > On dual-CPU machines the speedups are as follows: my version > > > is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, > > > 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 > > > kernel. Why are the numbers on Linux machines so much lower? > > > > Does your measurement include the time needed to actually create the > > threads or do you even frequently create and destroy threads? > > > > The code for creating threads is _horribly_ slow in Linuxthreads due > > to the way it is implemented. > > > > > It is the > > > same multi-threaded code, I am not using any tricks, the code basically > > > uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack > > > size is set to 8K (but the numbers are the same with larger/smaller stack > > > sizes). > > > > > > Is there anything I am missing? Is this to be expected due to Linux way of > > > handling threads (clone call)? I am just trying to explain the numbers and > > > nothing else comes to mind > > > > Linuxthreads is a rather bad pthreads implementation performance-wise, > > mostly due to the rather different linux-native threading model. > > > > Christoph > > - > 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/ > - 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: threading question
This may sound like flamebait, but its not. Linux threads are basically just processes that share the same address space. Their performance is measurably worse than it is on most commercial Unixes and FreeBSD. They are not, or at least two years ago, were not POSIX compliant (they behaved badly with respect to signals). The impoverished implementation of threads is not an accidental oversight, threads are not looked upon favorably by most of the core linux kernel hackers. A quote from Larry McVoy's home page attributed to Alan Cox illustrates this reasonably well: "A computer is a state machine. Threads are for people who can't program state machines." Sorry for not being more helpful. -Kip On Tue, 12 Jun 2001 [EMAIL PROTECTED] wrote: > Hello, > > I am a summer student implementing a multi-threaded version of a very > popular bioinformatics tool. So far it compiles and runs without problems > (as far as I can tell ;) on Linux 2.2.x, Sun Solaris, SGI IRIX and Compaq > OSF/1 running on Alpha. I have ran a lot of timing tests compared to the > sequential version of the tool on all of these machines (most of them are > dual-CPU, although I am also running tests on 12-CPU Solaris and 108 CPU > SGI IRIX). On dual-CPU machines the speedups are as follows: my version > is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, > 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 > kernel. Why are the numbers on Linux machines so much lower? It is the > same multi-threaded code, I am not using any tricks, the code basically > uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack > size is set to 8K (but the numbers are the same with larger/smaller stack > sizes). > > Is there anything I am missing? Is this to be expected due to Linux way of > handling threads (clone call)? I am just trying to explain the numbers and > nothing else comes to mind > > Best regards, > Ognen Duzlevski > -- > [EMAIL PROTECTED] > Plant Biotechnology Institute > National Research Council of Canada > Bioinformatics team > > - > 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/ > - 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: threading question
Hello, due to the nature of the problem (a pairwise mutual alignment of n sequences results in mx. n^2 alignments which can each be done in a separate thread), I need to create and destroy the threads frequently. I am not really comfortable with 1.4 - 1.5 speedups since the solution was intended as a Linux one primarily and it just happenned that it works (and now even better) on Solaris/SGI/OSF... Best regards, Ognen On Tue, 12 Jun 2001, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you wrote: > > On dual-CPU machines the speedups are as follows: my version > > is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, > > 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 > > kernel. Why are the numbers on Linux machines so much lower? > > Does your measurement include the time needed to actually create the > threads or do you even frequently create and destroy threads? > > The code for creating threads is _horribly_ slow in Linuxthreads due > to the way it is implemented. > > > It is the > > same multi-threaded code, I am not using any tricks, the code basically > > uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack > > size is set to 8K (but the numbers are the same with larger/smaller stack > > sizes). > > > > Is there anything I am missing? Is this to be expected due to Linux way of > > handling threads (clone call)? I am just trying to explain the numbers and > > nothing else comes to mind > > Linuxthreads is a rather bad pthreads implementation performance-wise, > mostly due to the rather different linux-native threading model. > > Christoph - 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: threading question
In article <[EMAIL PROTECTED]> you wrote: > On dual-CPU machines the speedups are as follows: my version > is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, > 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 > kernel. Why are the numbers on Linux machines so much lower? Does your measurement include the time needed to actually create the threads or do you even frequently create and destroy threads? The code for creating threads is _horribly_ slow in Linuxthreads due to the way it is implemented. > It is the > same multi-threaded code, I am not using any tricks, the code basically > uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack > size is set to 8K (but the numbers are the same with larger/smaller stack > sizes). > > Is there anything I am missing? Is this to be expected due to Linux way of > handling threads (clone call)? I am just trying to explain the numbers and > nothing else comes to mind Linuxthreads is a rather bad pthreads implementation performance-wise, mostly due to the rather different linux-native threading model. Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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.2.19: eepro100 and cmd_wait issues
On 12 Jun 2001 13:00:41 -0500, John Madden wrote: > > kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! > kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! I have the same problem, since a long time, with various 2.2 and 2.4 kernels running on a i815 motherboard, with on-board eepro100 net card. > The only solution I've found that works is to reboot, and since this is For me, it's enough to "ifconfig down" then "ifconfig up" the interface. I will probably buy another network card, since changing the OS is not an option, and Linux seems to not like eepro100 that much... :-/ -- Florin Andrei - 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/
[BUG] 2.4.4 PCI /proc output
Hi, The /proc/bus/pci/devices data looks correct. /proc/bus/pci/0[01]/* entries look correct. The /proc/bus/pci/0[23]/* entries don't match "devices" data and looks wrong. The host machine is a HP LXR8000 (4x 500Mhz PIII, 2GB RAM, ~8 PCI slots). Eg for 02/6.0 lspci -v says: 02:06.0 Non-VGA unclassified device: Digital Equipment Corporation DECchip 21154 Flags: fast devsel I/O ports at [disabled] Memory at (type 3, non-prefetchable) [disabled] Memory at (type 3, non-prefetchable) [disabled] Memory at (low-1M, non-prefetchable) [disabled] Memory at (32-bit, prefetchable) [disabled] (This is a 64-bit PCI-PCI bridge) od -Ax -x /proc/bus/pci/02/06.0 00 1000 1000 0040 10 020b 4011 1000 000b 0157 0210 20 0007 0100 8008 0080 4001 4004 fe40 30 0004 fe40 40 * 000100 /proc/bus/pci/devices for 02/06.0 says: 0230101100260 Full output for lspci -t, lspci -v, /proc/bus/pci/0?/*, and devices is available at ftp://gsyprf10.external.hp.com/pub/244_pci/. If more info is desired, send me mail. I didn't see anything obviously wrong with proc_bus_pci_read() in drivers/pci/proc.c. My first guess is the *ppos parameter is fubar but I'm not able to test this theory. My excuse is the LXR8000 doesn't reboot reliably and is 1km away (I'm in Germany instead of California). If this isn't already fixed in 2.4.5 (or .6), I'll look at it in July when I get back. grant Grant Grundler parisc PCI|IOMMU|SMP hacker +1 408-447-7253 - 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/
threading question
Hello, I am a summer student implementing a multi-threaded version of a very popular bioinformatics tool. So far it compiles and runs without problems (as far as I can tell ;) on Linux 2.2.x, Sun Solaris, SGI IRIX and Compaq OSF/1 running on Alpha. I have ran a lot of timing tests compared to the sequential version of the tool on all of these machines (most of them are dual-CPU, although I am also running tests on 12-CPU Solaris and 108 CPU SGI IRIX). On dual-CPU machines the speedups are as follows: my version is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 kernel. Why are the numbers on Linux machines so much lower? It is the same multi-threaded code, I am not using any tricks, the code basically uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack size is set to 8K (but the numbers are the same with larger/smaller stack sizes). Is there anything I am missing? Is this to be expected due to Linux way of handling threads (clone call)? I am just trying to explain the numbers and nothing else comes to mind Best regards, Ognen Duzlevski -- [EMAIL PROTECTED] Plant Biotechnology Institute National Research Council of Canada Bioinformatics team - 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: Disaster under heavy network load on 2.4.x
It looks like you don't have 'lo' configured, i.e. your 127.0.0.1 interface. David Michal Margula wrote: >Hello! > >My friend told me to noticed you about problems I had with 2.4.x line of >kernels. I started up from 2.4.3. Under heavy load I was getting >messages from telnet, ping, nmap "No buffer space available". Strace >told me it was error marked as ENOBUFS. > >First thought was it was my fault. I asked many people and nobody could >help me. So I tried 2.4.5. It was a disaster also (should I mention few >oopses?:>). > >Second thought was to try 2.2.19 and it was good choice. Now there are >almost no messags like those above. Only thing that still happens is >"Neihgbour table overflow". > >Some data about my Linux box: > >2 x PIII 800 MHz/1024 MB; 2 x Intel EExpres 100; 3 x 3com 3c900B-Combo. >Summarizing all traffic about 5mbit at the moment. > ># arp -an | wc -l > 1018 > >Any more info needed? > >PS. It would be nice to be CCed with replies, beacause I am not >subscribed to LKML. > - 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: Any limitations on bigmem usage?
On Tue, 12 Jun 2001, Rob Landley wrote: > Brilliant. You need what, a 6x larger cache just to break even with > the amount of time you're running in-cache? That's going to be hard, since the cache will also need to be faster in order to feed the CPU core. Making a cache both larger AND faster at the same time will need some smart people. > And of course the compiler is GOING to put NOPs in that because it > won't always be able to figure out something for the second and third > cores to do this clock, regardless of how good a compiler it is. Compilers are also notoriously bad at runtime optimisations. > That's just beautiful. I also never expected Intel to dispose of themselves in such a cute way. cheers, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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.2.19: eepro100 and cmd_wait issues
I'm having trouble on one machine out of about 20 that run with eepro100's. This one in particular happens to be a dual port. I searched through the archives for this, but I didn't find any definite solutions (one thread, on "2.2.18 and laptop problems," provided a patch that doesn't seem to make any difference). After roughly 30 days of uptime, I get a lot of kernel messages like the following: kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! I'd like to assume that this is bad hardware, but since the problem only happens every 30 days or so (and every 30 days or so), I wanted to check here to make sure it wasn't a driver issue. The only solution I've found that works is to reboot, and since this is probably the most production machine I'm responsible for (couldn't be any other one, right?), I'd like to make sure I don't have to schedule a reboot every 29 days or something. :) More info: Kernel 2.2.19 SMP, lspci: 01:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 05) Subsystem: Intel Corporation EtherExpress PRO/100+ Dual Port Adapter Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at fafff000 (32-bit, prefetchable) I/O ports at ece0 Memory at fcf0 (32-bit, non-prefetchable) Expansion ROM at fd00 [disabled] Capabilities: [dc] Power Management version 1 01:05.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 05) Subsystem: Intel Corporation EtherExpress PRO/100+ Dual Port Adapter Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at faffe000 (32-bit, prefetchable) I/O ports at ecc0 Memory at fce0 (32-bit, non-prefetchable) Expansion ROM at fd00 [disabled] Capabilities: [dc] Power Management version 1 dmesg: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/driv ers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others eepro100.c: VA Linux custom, Dragan Stancevic <[EMAIL PROTECTED]> 2000/11/15 Thanks! John -- John Madden UNIX Systems Engineer Ivy Tech State College [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: Re[2]: PC keyboard rate/delay
> Because (almost?) all m68k machines don't have PC style keyboard controllers, > so we _had_ to invent some other way to implement it in a portable (across all > m68k machines) way. This stuff is such a mess :-( Sparc has its own routines as well. > > Of course it would be nice if all architectures would want to use it. > It will for 2.5.X :-) - 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: Any limitations on bigmem usage?
On Tuesday 12 June 2001 12:29, Alan Cox wrote: > If your algorithm can work well with say 2Gb windows on the data and only > change window evey so often (in computing terms) then it should be ok, if > its access is random you need to look at a 64bit box like an Alpha, Sparc64 > or eventually IA64 No, eventually Sledgehammer. You know that IA64 will never ship, because the performance will always suck. The design is fundamentally flawed. The real bottleneck is the memory bus. These days they're clock multiplying the inside of the processor by a factor of what, twelve? Fun as long as you're entirely in L1 cache and aren't task switching. But that's basicaly an embedded system. CISC instructions are effectively compressed. When you exhaust your cache your next 64 bit gulp can get more than 2 instructions, you can get more like 5 (which still means you're getting about 1/4 the performance of in-cache execution, although L2 and L3 caches help here, of course..) But optimizing for something that isn't actually your bottleneck is just dumb, and that's exactly what Intel did with the move to VLIW/EPIC/IA64. 3 times 64 bit instructions is 192, whereas Pentium can fit more than that in a single 64 bit chunk. Brilliant. You need what, a 6x larger cache just to break even with the amount of time you're running in-cache? And of course the compiler is GOING to put NOPs in that because it won't always be able to figure out something for the second and third cores to do this clock, regardless of how good a compiler it is. That's just beautiful. This is why they were so desperate for RAMBUS. They KNOW the memory bus is killing them, they were grasping at straws to fix it. (Currently they're saying that a future vaporware version of iTanium will fix everything, but it's a fundamental design flaw: the new instruction set they've chosen is WAY less efficient going across the memory bus, and that's the real limiting factor in performance.) Transmeta at least sucks CISC in from main memory to keep the northbridge bottleneck optimized. And they have a big cache, and they're still using 32 bit instructions so they only need 96 bytes per chunk (or atom or whatever they're calling it these days). Sledgehammer is the interesting x86 64 bit instruction set. You still have the cisc/risc hybrid that made pentium work. (And, of course, backwards compatability that's inherent in the design rather than bolted onto the side with duct tape and crazy glue.) Yeah the circuitry to make it work is probably fairly insane, but at least the Athlon design team made all the racy logic go away so they can migrate the design to new manufacturing processes without four months of redesign work. (And no, making insanely long pipelines in Pentium 4 is not a major improvement there either. Cache exhaustion still kills you, so does branch misprediction. Stalling a longer pipeline is more expensive.) I saw an 800 mhz iTanium which benchmarked about the same (running 64 bit code) as a Penium III 300 mhz running 32 bit code. That's just sad. Go ahead and blame the compiler. That's still just sad. And a design flaw in the new instruction set is not something that can be easily optimized away. Rob - 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: ethtool MII helpers
Bogdan Costescu wrote:
> On Sun, 10 Jun 2001, Jeff Garzik wrote:
> - I don't know what the long-term plan is about ethtool vs. MII ioctl's.
> If you do plan to replace completely the MII ioctl's, there should be a
> way to access _all_ MII registers provided by the PHY, even if you do this
> in a restricted way (i.e. for CAP_NET_ADMIN only). There is also useful
> info in other registers than the 4 you have in your implementation.
What are you doing that you need to access all registers from userspace?
On to your larger question, ethtool versus MII ioctls. That is an
issue that weighs heavily on me. Right now we have quite a bit of
deployed code using MII ioctls, and there is a gigabit MII standard; so,
Becker's argument is that each driver should provide a set of MII
ioctls, emulating behavior when hardware isn't exactly per spec. (yes,
right now they are SIOCDEVPRIVATE, but that can be easily changed to
SIOCDEVMIIxxx)
David's argument is for ethtool, which originally comes out of the sparc
port (see include/asm-sparc/ethtool.h in older trees), and has been
around for a while, but doesn't enjoy the massive deployment that the
MII ioctls enjoy. We have control over the ethtool API, and we can
correct its deficiencies, whereas any MII spec deficiencies must be
worked out inside the driver. Further, there is the question of "how
much MII to implement" -- currently the MII-ioctl-based net drivers all
implement -basic- MII, but I guarantee that you will find
per-driver(per-chip) differences in the MII implementation... which is a
flaw in the MII ioctl implementation in the driver, regardless of how
the chip is designed. There are completeness flaws in more than one MII
ioctl implementation. Several drivers will return zeroes for the MII id
registers, for example. The ethtool API doesn't have that problem.
For 2.4, my conclusion is: for drivers that already implement MII
ioctls as SIOCDEVPRIVATE, continue to support those ioctls. In
addition, support ethtool. For drivers without support for either, just
add ethtool support. The patch being discussed will cut down on
duplicate code for both cases.
Further, for the userland ethtool program, support for MII ioctls will
be added soon, so that there will be no need for additional mii-tool or
mii-diag tools.
For 2.5? I don't know. I am not a visionary. I defer that to Linus
and David and Donald and Jamal and Alexey and... I am mainly a
maintainer and merge monkey, only implementing new APIs when the needs
are blindingly obvious.
> - You are proposing some caching for the MII registers. I suppose that you
> would like to have this code also working with whatever caching will be
> done for MII access that was recently discussed. Wouldn't this produce
> double caching under some circumstances ?
You misunderstood the code. The "caching" here is whatever is -already-
being done by the driver. Many Becker-style drivers cache the
advertising value. If such a driver uses the ethtool MII code, that is
one less MII read that needs to occur.
If the driver author wishes to cache more stuff, they have to do so in
the obvious way. struct ethtool_mii_info is only used for helper
functions which are only used inside netdrv_ioctl().
> + int speed; /* 10, 100, 1000 or -1 (ask hw) */
>
> Please note that the comment specifies 1000, while the code in several
> places assumes only 2 possibilities: 10 and 100.
planning for the future :) Yes, the code only supports 10/100, as I
mentioned in my introductory message.
> + if (mii->autoneg < 0)
> + autoneg = mii->autoneg = (bmcr & BMCR_ANENABLE) ? 1 : 0;
> + elseautoneg = mii->autoneg;
>
> You don't read anything from the hardware at this point. Why do you want
> caching ?
I don't understand your question. Of course we have read BMCR from the
hardware at that point, read the code...
> Not related: I know that this comes from David Miller's older work, but
> wouldn't be possible to have a more uniform naming scheme ? You have
> BMCR_ANENABLE, but you have BMSR_ANEGCAPABLE...
capable != enable.. I prefer them different, so I am therefore
unmotivated to change anything ;-)
> + if (mii->full_duplex < 0)
> + full_duplex = mii->full_duplex =
> + mii_nway_result(negotiated) & LPA_DUPLEX;
> + elsefull_duplex = mii->full_duplex;
>
> If autoneg. is disabled, I don't think that you always get useful info in
> 'negotiated'. Applies to the next chunk, too.
>
> + if (mii->speed < 0) {
> + if (negotiated & LPA_100)
> + speed = mii->speed = 100;
> + else
> + speed = mii->speed = 10;
> + } else
> + speed = mii->speed;
interesting point, thanks.
> + ecmd->transceiver = XCVR_INTERNAL;
>
> I didn't understand what XCVR_INTERNAL should mean as opposed to
> XCVR_EXTERNAL or whatever.
It is really up to
[OT]: Tux vs khttpd? (fwd)
Hi Roy, IIRC Ingo posted some tux benchmark results on the khttpd mailing list some weeks ago - basically khttpd is not in the same ballpark at this point. cu jjs Roy Sigurd Karlsbakk wrote: > Hi everyone! > > I tried to send this message to the khttpd group, but got no answer. Can > any of you help me? > > -- Forwarded message -- > Date: Thu, 07 Jun 2001 17:31:20 + > From: Roy Sigurd Karlsbakk <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Tux vs khttpd? > > hi > > Does anyone know any details about how Tux performs in comparison with > khttpd? > Is this a separate project, or is it a somehow 'better version' of the > khttpd? > Are these going to be merged? > > roy > - > Roy Sigurd Karlsbakk > <[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/ - 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: es1371 and recent kernels
Hi yes i can Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 6). IRQ 12. Master Capable. Latency=64. Min Gnt=12.Max Lat=128. I/O at 0xe800 [0xe83f]. CPU0 0: 17921979 XT-PIC timer 1: 82047 XT-PIC keyboard 2: 0 XT-PIC cascade 4: 10 XT-PIC 8: 1 XT-PIC rtc 10: 17414341 XT-PIC eth0 12: 12959553 XT-PIC es1371 14:3066619 XT-PIC ide0 15: 16 XT-PIC ide1 e800-e83f : Ensoniq ES1371 [AudioPCI-97] e800-e83f : es1371 no problems with it at all though it is the same card as yours thats on a 2.4.5 kernel > >[please be kind and Cc when replying] > >Has someone been able to get es1371 to actually produce anything >audible with latest kernels? The last version I could use was 2.4.0. >Then I had some trouble but I attributed them to devfs. Now I've -- - Web: http://www.stev.org Mobile: +44 07779080838 E-Mail: [EMAIL PROTECTED] 5:00pm up 2 days, 1:42, 3 users, load average: 0.00, 0.00, 0.00 - 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/
CLOSE_WAIT bug?
Hi all,
I suppect that there is bug in both kernel 2.2.19 and 2.4.5.
The situation is as follow.
One server socket created and listening, blocking on select(),
once a client connect to that port, there is another thread in server
side issues a close() to the new connection.
After the client close the connection. The connection in server side will
stuck on CLOSE_WAIT forever until the program being killed.
I have attached a program to trigger the bug.
The program is written base on a bugtraq post on this link:
http://archives.indenial.com/hypermail/bugtraq/1999/January1999/0015.html
This is the output of "netstat -anop":
tcp 1 0 127.0.0.1:52882 127.0.0.1:1031 CLOSE_WAIT - off (0.00/0/0)
tcp 1 0 127.0.0.1:52882 127.0.0.1:1030 CLOSE_WAIT - off (0.00/0/0)
You can see that there is no owner and the timer is off.
I encounter this in my server program and the CLOSE_WAIT thread eat up
all the resource as it cannot be released.
I have tried this on kernel 2.2.16, 2.2.19, 2.4.5 and using
gcc version 2.96 2731 (Red Hat Linux 7.0), all this have such problem.
I am new to kernel hacking. I don't know whether this is a bug or not.
Please correct me if I am doing something wrong and forgive my poor
description. :)
Thanks
Dicky
PS. Please CC: [EMAIL PROTECTED] when reply.
// This program will kill a random port on a linux machine. The kernel will
// forever listen to that port and send the connections nowhere. Tested with
// Linux kernel 2.0.35 and libc-2.0.7. Requires LinuxThreads to compile,
// but removing LinuxThreads from your system will not solve the problem.
// The bug is triggered when a multithreaded program closes a socket from
// one thread while another thread is selecting on it. A subsequent abort
// leaves the socket in never-never land.
// Do not underestimate the risk of this exploit. While this program
// is mild, more vicious programs could lock large numbers of ports or
// replicate this same attack on an active connection with large
// send/receive buffers full of data. This could cause large increases
// in kernel memory consumption.
// Discovered by David J. Schwartz <[EMAIL PROTECTED]>
// Copyright (C) 1998, David J. Schwartz
// Note: This bug was not fixed in 2.0.36, as I was told it would be
// Compile with:
// gcc CLOSE_WAIT_test.c -lpthread -o CLOSE_WAIT_test
#include
#include
#include
#include
#include
#include
#include
#include
volatile int s;
volatile int sock;
volatile int connected=0;
void *Thread1(void *a)
{
int i,p;
struct sockaddr_in to;
fd_set fd;
s=socket(AF_INET, SOCK_STREAM, 0);
if(s<=0) return;
memset(, 0, sizeof(to));
srand(getpid());
/* we pick a random port between 5 and 5 */
p=(rand()%1)+5;
printf("port = %d\n", p);
fflush(stdout);
to.sin_port=htons(p);
to.sin_addr.s_addr=0;
to.sin_family=AF_INET;
if(bind(s, (struct sockaddr *), sizeof(to))<0)
fprintf(stderr,"no bind\n");
if(listen(s,10)!=0)
fprintf(stderr,"No Listen\n");
/* now we are listening on that port */
i=sizeof(to);
FD_ZERO();
FD_SET(s,);
fprintf(stdout,"Listening, before select\n");
fprintf(stdout,"Please connect to port %d now\n", p);
select(s+1,,NULL,NULL,NULL);
/* at this point we have selected on it as well */
fprintf(stderr,"select returned!\n");
if (FD_ISSET(s, ))
{
fprintf(stdout, "socket is set\n");
sock = accept(s, NULL, NULL);
fprintf(stdout, "accepted\n");
FD_SET(sock, );
fprintf(stdout, "FD_SET ok\n");
connected = 1;
fprintf(stdout,"\nListening, before select\n");
select(sock+1, , NULL, NULL, NULL);
fprintf(stdout, "select returned\n");
}
else
{
fprintf(stderr, "Error : fd not set\n");
exit(1);
}
}
void *Thread2(void *a)
{
fprintf(stdout,"Thread2 : before close the client socket\n");
close(sock);
fprintf(stdout,"Thread2 : after close the client socket\n\n\n");
fprintf(stdout,"Please close the remote session and check the result\n");
fflush(stderr);
// abort();
}
void main(void)
{
pthread_t j;
pthread_create(,NULL,Thread1,NULL);
while (connected == 0)
usleep(1000); /* give the other thread time to finish */
pthread_create(,NULL,Thread2,NULL);
while(1) sleep(1);
}
Re: PATCH: ethtool MII helpers
On Sun, 10 Jun 2001, Jeff Garzik wrote:
> Comments appreciated.
Some general comments first, the others are spread through the code.
- I don't know what the long-term plan is about ethtool vs. MII ioctl's.
If you do plan to replace completely the MII ioctl's, there should be a
way to access _all_ MII registers provided by the PHY, even if you do this
in a restricted way (i.e. for CAP_NET_ADMIN only). There is also useful
info in other registers than the 4 you have in your implementation.
- You are proposing some caching for the MII registers. I suppose that you
would like to have this code also working with whatever caching will be
done for MII access that was recently discussed. Wouldn't this produce
double caching under some circumstances ?
+ int speed; /* 10, 100, 1000 or -1 (ask hw) */
Please note that the comment specifies 1000, while the code in several
places assumes only 2 possibilities: 10 and 100.
+ if (mii->autoneg < 0)
+ autoneg = mii->autoneg = (bmcr & BMCR_ANENABLE) ? 1 : 0;
+ elseautoneg = mii->autoneg;
You don't read anything from the hardware at this point. Why do you want
caching ?
Not related: I know that this comes from David Miller's older work, but
wouldn't be possible to have a more uniform naming scheme ? You have
BMCR_ANENABLE, but you have BMSR_ANEGCAPABLE...
+ if (mii->full_duplex < 0)
+ full_duplex = mii->full_duplex =
+ mii_nway_result(negotiated) & LPA_DUPLEX;
+ elsefull_duplex = mii->full_duplex;
If autoneg. is disabled, I don't think that you always get useful info in
'negotiated'. Applies to the next chunk, too.
+ if (mii->speed < 0) {
+ if (negotiated & LPA_100)
+ speed = mii->speed = 100;
+ else
+ speed = mii->speed = 10;
+ } else
+ speed = mii->speed;
That's one of the places where you don't have 1000...
+ ecmd->speed = speed == 100 ? SPEED_100 : SPEED_10;
... and that's the second.
+ ecmd->transceiver = XCVR_INTERNAL;
I didn't understand what XCVR_INTERNAL should mean as opposed to
XCVR_EXTERNAL or whatever. For example: some older 3Com cards use external
transceivers (not on the chip), while newer ones have NWAY capable MII
transceivers on the chip. So, you can have:
1. chip + MII
2. NWAY-chip
3. NWAY-chip + MII
All MII accesses are done through the serial mdio_* protocol. How should
be this handled w.r.t. XCVR_* or is it completely orthogonal?
+ if ((in.phy_address != out.phy_address) ||
+ (in.transceiver != XCVR_INTERNAL) ||
+ (in.maxtxpkt != out.maxtxpkt) ||
+ (in.maxrxpkt != out.maxrxpkt))
+ return -EOPNOTSUPP;
... and here too.
+ if (advert != mii->advertising) {
+ bmcr |= BMCR_ANRESTART;
+ mii->mdio_write(dev, mii->phy_id, MII_ADVERTISE, advert);
+ mii->advertising = advert;
+ }
+
+ /* some phys need autoneg dis/enabled separately from other settings */
+ if ((bmcr & BMCR_ANENABLE) && (!(mii->bmcr & BMCR_ANENABLE))) {
+ mii->mdio_write(dev, mii->phy_id, MII_BMCR,
+ mii->bmcr | BMCR_ANENABLE | BMCR_ANRESTART);
+ bmcr &= ~BMCR_ANRESTART;
+ } else if ((!(bmcr & BMCR_ANENABLE)) && (mii->bmcr & BMCR_ANENABLE)) {
+ mii->mdio_write(dev, mii->phy_id, MII_BMCR,
+ mii->bmcr & ~BMCR_ANENABLE);
+ }
This is nice, but I would like to able to restart autonegotiation even
without changing any of the advertised capabilities. If I missed this
possibility, please point me to it...
Nice work!
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: [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: Any limitations on bigmem usage?
> Specifically, is there anything to prevent me from malloc()ing 6GB of memory, > then accessing that memory as I would any other buffer? FYI, the application X86 has no nice way to address over 4Gb of RAM. You can do paging games with multiple banks and shmat (ie like using DOS expanded ram but with bigger pieces). > I've been eyeing an 8-way Intel box with gobs of memory, but if there are subtle > issues with using that much memory, I need to know now. If your algorithm can work well with say 2Gb windows on the data and only change window evey so often (in computing terms) then it should be ok, if its access is random you need to look at a 64bit box like an Alpha, Sparc64 or eventually IA64 - 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] truncate_inode_pages
Am Dienstag, 12. Juni 2001 14:32 schrieb Daniel Phillips: > On Tuesday 12 June 2001 02:00, you wrote: > > Now with -ac13 and the third try. > > Is it final? > > There have been no further problems reported, but it's Andrew Morton's > patch, his decision. > > -- > Daniel Hello Andrew, have you forwarded it to Alan for apply? Thanks, Dieter - 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: es1371 and recent kernels
Pierfrancesco Caci [[EMAIL PROTECTED]] wrote: > > [please be kind and Cc when replying] > > Has someone been able to get es1371 to actually produce anything > audible with latest kernels? The last version I could use was 2.4.0. > Then I had some trouble but I attributed them to devfs. Now I've > removed devfs and still I'm not able to play anything. Works for me, but it produces all kinds of crackly noise garbage. I'm not sure if this is because the driver has a bug, or the sound card is a piece of flaming shit. But I'm inclined to believe the latter. Anybody have a suggestion for a card that isn't a flaming piece of shit, (and not made by Creative) less than $100 US, PCI, supported by linux, and available? Cheers, -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics PGP signature
Re: es1371 and recent kernels
It does work very well for me with 2.4.5 and 2.4.6-pre2, both with or without devfs, both if sound support has been statically linked or compiled as module. On 12 Jun 2001, Pierfrancesco Caci wrote: > > [please be kind and Cc when replying] > > Has someone been able to get es1371 to actually produce anything > audible with latest kernels? The last version I could use was 2.4.0. > Then I had some trouble but I attributed them to devfs. Now I've > removed devfs and still I'm not able to play anything. > > .config is available at http://mirror.seabone.net/paperino.config > > pieffe@paperino:/proc $ cat devices > Character devices: > 1 mem > 2 pty > 3 ttyp > 4 ttyS > 5 cua > 6 lp > 7 vcs > 10 misc > 14 sound > 29 fb > 89 i2c > 128 ptm > 129 ptm > 136 pts > 137 pts > 162 raw > > Block devices: > 2 fd > 3 ide0 > 22 ide1 > Character devices: 1 mem 2 pty 3 ttyp 4 vc/0 5 ptmx 7 vcs 10 misc 14 sound 21 sg 29 fb 36 netlink 81 video_capture 90 mtd 128 ptm 136 pts 162 raw 180 usb 202 cpu/msr 203 cpu/cpuid Block devices: 3 ide0 22 ide1 31 mtdblock > pieffe@paperino:/proc $ cat es1371 > Creative ES137x Debug Dump-o-matic > AC97 CODEC state > reg:0x00 val:0x1990 > reg:0x02 val:0x0303 > reg:0x04 val:0x1515 > reg:0x06 val:0x0017 > reg:0x08 val:0x > reg:0x0a val:0x000a > reg:0x0c val:0x0006 > reg:0x0e val:0x > reg:0x10 val:0x0b0b > reg:0x12 val:0x0b0b > reg:0x14 val:0x0b0b > reg:0x16 val:0x0b0b > reg:0x18 val:0x0b0b > reg:0x1a val:0x0404 > reg:0x1c val:0x0a0a > reg:0x1e val:0x > reg:0x20 val:0x > reg:0x22 val:0x > reg:0x24 val:0x > reg:0x26 val:0x800f > reg:0x28 val:0x0200 > reg:0x2a val:0x > reg:0x2c val:0xbb80 > reg:0x2e val:0x > reg:0x30 val:0x > reg:0x32 val:0xbb80 > reg:0x34 val:0x > reg:0x36 val:0x > reg:0x38 val:0x > reg:0x3a val:0x > reg:0x3c val:0x > reg:0x3e val:0x > reg:0x40 val:0x > reg:0x42 val:0x > reg:0x44 val:0x > reg:0x46 val:0x > reg:0x48 val:0x > reg:0x4a val:0x > reg:0x4c val:0x > reg:0x4e val:0x > reg:0x50 val:0x > reg:0x52 val:0x > reg:0x54 val:0x > reg:0x56 val:0x > reg:0x58 val:0x > reg:0x5a val:0x0302 > reg:0x5c val:0x > reg:0x5e val:0x0080 > reg:0x60 val:0x0022 > reg:0x62 val:0x > reg:0x64 val:0x > reg:0x66 val:0x > reg:0x68 val:0x > reg:0x6a val:0x > reg:0x6c val:0x > reg:0x6e val:0x > reg:0x70 val:0x > reg:0x72 val:0x > reg:0x74 val:0x > reg:0x76 val:0x > reg:0x78 val:0x003f > reg:0x7a val:0x > reg:0x7c val:0x4352 > reg:0x7e val:0x5913 > Creative ES137x Debug Dump-o-matic AC97 CODEC state reg:0x00 val:0x1990 reg:0x02 val:0x1717 reg:0x04 val:0x1515 reg:0x06 val:0x0017 reg:0x08 val:0x reg:0x0a val:0x000a reg:0x0c val:0x000b reg:0x0e val:0x000b reg:0x10 val:0x0b0b reg:0x12 val:0x0b0b reg:0x14 val:0x0b0b reg:0x16 val:0x0b0b reg:0x18 val:0x0b0b reg:0x1a val:0x0404 reg:0x1c val:0x0a0a reg:0x1e val:0x reg:0x20 val:0x reg:0x22 val:0x reg:0x24 val:0x reg:0x26 val:0x800f reg:0x28 val:0x0200 reg:0x2a val:0x reg:0x2c val:0xbb80 reg:0x2e val:0x reg:0x30 val:0x reg:0x32 val:0xbb80 reg:0x34 val:0x reg:0x36 val:0x reg:0x38 val:0x reg:0x3a val:0x reg:0x3c val:0x reg:0x3e val:0x reg:0x40 val:0x reg:0x42 val:0x reg:0x44 val:0x reg:0x46 val:0x reg:0x48 val:0x reg:0x4a val:0x reg:0x4c val:0x reg:0x4e val:0x reg:0x50 val:0x reg:0x52 val:0x reg:0x54 val:0x reg:0x56 val:0x reg:0x58 val:0x reg:0x5a val:0x0302 reg:0x5c val:0x reg:0x5e val:0x0080 reg:0x60 val:0x0022 reg:0x62 val:0x reg:0x64 val:0x reg:0x66 val:0x reg:0x68 val:0x reg:0x6a val:0x reg:0x6c val:0x reg:0x6e val:0x reg:0x70 val:0x reg:0x72 val:0x reg:0x74 val:0x reg:0x76 val:0x reg:0x78 val:0x0071 reg:0x7a val:0x reg:0x7c val:0x4352 reg:0x7e val:0x5913 > pieffe@paperino:/proc $ cat interrupts >CPU0 > 0: 122894 XT-PIC timer > 1: 5051 XT-PIC keyboard > 2: 0 XT-PIC cascade > 5: 3225 XT-PIC eth0 > 8: 1 XT-PIC rtc > 10: 38969 XT-PIC es1371 > 12: 28771 XT-PIC PS/2 Mouse > 14: 8790 XT-PIC ide0 > 15:112 XT-PIC ide1 > NMI: 0 > ERR: 0 > CPU0 0: 51784328 XT-PIC timer 1: 142458 XT-PIC keyboard 2: 0 XT-PIC cascade 11: 11021305 XT-PIC es1371, usb-uhci, eth0 12:1374347 XT-PIC PS/2 Mouse 14:1085963 XT-PIC ide0 15: 3 XT-PIC ide1 NMI: 0 ERR: 0 > pieffe@paperino:/proc $ cat iomem > -0009fbff : System RAM >
es1371 and recent kernels
[please be kind and Cc when replying] Has someone been able to get es1371 to actually produce anything audible with latest kernels? The last version I could use was 2.4.0. Then I had some trouble but I attributed them to devfs. Now I've removed devfs and still I'm not able to play anything. .config is available at http://mirror.seabone.net/paperino.config pieffe@paperino:/proc $ cat devices Character devices: 1 mem 2 pty 3 ttyp 4 ttyS 5 cua 6 lp 7 vcs 10 misc 14 sound 29 fb 89 i2c 128 ptm 129 ptm 136 pts 137 pts 162 raw Block devices: 2 fd 3 ide0 22 ide1 pieffe@paperino:/proc $ cat es1371 Creative ES137x Debug Dump-o-matic AC97 CODEC state reg:0x00 val:0x1990 reg:0x02 val:0x0303 reg:0x04 val:0x1515 reg:0x06 val:0x0017 reg:0x08 val:0x reg:0x0a val:0x000a reg:0x0c val:0x0006 reg:0x0e val:0x reg:0x10 val:0x0b0b reg:0x12 val:0x0b0b reg:0x14 val:0x0b0b reg:0x16 val:0x0b0b reg:0x18 val:0x0b0b reg:0x1a val:0x0404 reg:0x1c val:0x0a0a reg:0x1e val:0x reg:0x20 val:0x reg:0x22 val:0x reg:0x24 val:0x reg:0x26 val:0x800f reg:0x28 val:0x0200 reg:0x2a val:0x reg:0x2c val:0xbb80 reg:0x2e val:0x reg:0x30 val:0x reg:0x32 val:0xbb80 reg:0x34 val:0x reg:0x36 val:0x reg:0x38 val:0x reg:0x3a val:0x reg:0x3c val:0x reg:0x3e val:0x reg:0x40 val:0x reg:0x42 val:0x reg:0x44 val:0x reg:0x46 val:0x reg:0x48 val:0x reg:0x4a val:0x reg:0x4c val:0x reg:0x4e val:0x reg:0x50 val:0x reg:0x52 val:0x reg:0x54 val:0x reg:0x56 val:0x reg:0x58 val:0x reg:0x5a val:0x0302 reg:0x5c val:0x reg:0x5e val:0x0080 reg:0x60 val:0x0022 reg:0x62 val:0x reg:0x64 val:0x reg:0x66 val:0x reg:0x68 val:0x reg:0x6a val:0x reg:0x6c val:0x reg:0x6e val:0x reg:0x70 val:0x reg:0x72 val:0x reg:0x74 val:0x reg:0x76 val:0x reg:0x78 val:0x003f reg:0x7a val:0x reg:0x7c val:0x4352 reg:0x7e val:0x5913 pieffe@paperino:/proc $ cat interrupts CPU0 0: 122894 XT-PIC timer 1: 5051 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 3225 XT-PIC eth0 8: 1 XT-PIC rtc 10: 38969 XT-PIC es1371 12: 28771 XT-PIC PS/2 Mouse 14: 8790 XT-PIC ide0 15:112 XT-PIC ide1 NMI: 0 ERR: 0 pieffe@paperino:/proc $ cat iomem -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-03fe : System RAM 0010-0021aee3 : Kernel code 0021aee4-0027df2b : Kernel data 03ff-03ff2fff : ACPI Non-volatile Storage 03ff3000-03ff : ACPI Tables e000-e3ff : PCI Bus #01 e000-e0ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e200-e2000fff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e400-e5ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge e700-e77f : 3Com Corporation 3c905B-Combo [Deluxe Etherlink XL 10/100] - : reserved pieffe@paperino:/proc $ cat ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0376-0376 : ide1 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0778-077a : parport0 0cf8-0cff : PCI conf1 4000-403f : Intel Corporation 82371AB PIIX4 ACPI 5000-501f : Intel Corporation 82371AB PIIX4 ACPI d000-dfff : PCI Bus #01 d000-d0ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e000-e01f : Intel Corporation 82371AB PIIX4 USB e400-e47f : 3Com Corporation 3c905B-Combo [Deluxe Etherlink XL 10/100] e400-e47f : eth0 e800-e83f : Ensoniq ES1371 [AudioPCI-97] e800-e83f : es1371 f000-f00f : Intel Corporation 82371AB PIIX4 IDE f000-f007 : ide0 f008-f00f : ide1 pieffe@paperino:/proc $ cat modules es1371 25680 0 (autoclean) ac97_codec 8576 0 (autoclean) [es1371] parport_pc 23248 1 (autoclean) lp 5552 1 (autoclean) parport25664 1 (autoclean) [parport_pc lp] binfmt_misc 3264 0 soundcore 3792 4 (autoclean) [es1371] #lspci -vv 00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rsync hangs on RedHat 2.4.2 or stock 2.4.4
On Tue, 12 Jun 2001, David S. Miller did have cause to say: > Look everyone, it was determined to be a deadlock because of some > interaction between how rsync sets up it's communication channels > with the ssh subprocess, readas: userland bug. we're not using ssh. :( --- -BEGIN GEEK CODE BLOCK- Version: 3.1 [www.ebb.org/ungeek] GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++ --END GEEK CODE BLOCK-- - 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: rsync hangs on RedHat 2.4.2 or stock 2.4.4
* David S. Miller ([EMAIL PROTECTED]) wrote: > > Russell King writes: > > At the time I suggested it was because of a missing wakeup in 2.4.2 kernels, > > but I was shouted down for using 2.2.15pre13. Since then I've seen these > > reports appear on lkml several times, each time without a solution nor > > explaination. > > > > Oh, and yes, we're still using the same setup here at work, and its running > > fine now - no rsync lockups. I'm not sure why that is. ;( > > Look everyone, it was determined to be a deadlock because of some > interaction between how rsync sets up it's communication channels > with the ssh subprocess, readas: userland bug. > > I don't remember if the specific problem was in rsync itself or some > buggy version of ssh. One can search the list archives to discover > Alexey's full analysis of the problem. I don't have a URL handy. I have to say I find this likely to be the case for those who are having issues with rsync over ssh. I was recently playing with rsync over ssh (newer openssh to older openssh) and was just using it as a pass-through to another machine. When I replaced ssh with rinetd, everything worked fine. I havn't had a chance yet (though I'd like to) to try with two recent versions of ssh but I'm curious what the result will be. It may be that the problem has been fixed in later versions of ssh. Stephen PGP signature
Re: unused shared memory is written into core dump - bug or feature?
Hi Peter, On Tue, 12 Jun 2001, Peter Niemayer wrote: > I just noticed that when I attach some SYSV shared memory segments > to my process and then that process dies from a SIGSEGV that _all_ > the shared memory is dumped into the core file, even if it was never > used and therefore didn't show up in any of the memory statistics. Fixed in recent kernel versions (2.2 and 2.4). It will create sparse files and not touch the unused address space. Greetings Christoph - 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: rsync hangs on RedHat 2.4.2 or stock 2.4.4
On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote: > I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat > 7.1) or stock 2.4.4 on several machines. rsync often hangs copying files > from NFS or local disks to local disks. Strangely the problem is fixed by > stracing one of the three rsync threads! me too! but I got shafted because I was using 2.2.15pre13 on the machine rsync was pushing the data to, and this was the problem. However, I can confirm that your symptoms are _precisely_ identical to mine - when rsync locks up, stracing it on the 2.4.2 end causes it to start up again. At the time I suggested it was because of a missing wakeup in 2.4.2 kernels, but I was shouted down for using 2.2.15pre13. Since then I've seen these reports appear on lkml several times, each time without a solution nor explaination. Oh, and yes, we're still using the same setup here at work, and its running fine now - no rsync lockups. I'm not sure why that is. ;( -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: rsync hangs on RedHat 2.4.2 or stock 2.4.4
On Tue, 12 Jun 2001, Rasmus Andersen did have cause to say: > On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote: > > I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat > > 7.1) or stock 2.4.4 on several machines. rsync often hangs copying files > > I could swear that during early 240-testX this was not a problem, > but when I finally made a report about it and tried to go back > through earlier kernels, I could not reproduce. Also, this is > not reproducable under 2.2.X (for me, at least). Just a 'me too!' but I'm inclined to think 'rsync bug' because it happens on Redhat+2.4.x, Debian+2.4.x and Debian+2.2.18 - we finally gave up on rsync for big-stuff-site-to-site and went back to scp. (It was -way- faster to scp 4 gigs than to rsync the 50 megs or so of changes. It would run, then freeze (usually at different places - if it froze twice in the same place we'd just scp the file manually), so we'd wander past and kill/restart it, repeat. Fastest total was 4 days, where the two of us checked it every couple of hours over the weekend.) We're (trying to) using it in real-life-big-data environment, so if you need debuggers/more info/etc let me know. (I'm on LKML but not rsync-bugs, so cc me from that side.. thanks!) --- -BEGIN GEEK CODE BLOCK- Version: 3.1 [www.ebb.org/ungeek] GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++ --END GEEK CODE BLOCK-- - 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: rsync hangs on RedHat 2.4.2 or stock 2.4.4
On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote: > I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat > 7.1) or stock 2.4.4 on several machines. rsync often hangs copying files > from NFS or local disks to local disks. Strangely the problem is fixed by > stracing one of the three rsync threads! > [...] > Has anyone else encountered this problem? Is it a kernel problem or an > rsync problem? I encountered this exact problem some time ago. Some discussion but in the end the problem was blamed on rsync and nothing came of it. I'll post an URL to the thread later on when I have the time to dig it out. I could swear that during early 240-testX this was not a problem, but when I finally made a report about it and tried to go back through earlier kernels, I could not reproduce. Also, this is not reproducable under 2.2.X (for me, at least). Regards, Rasmus - 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: Any limitations on bigmem usage?
Thanks to all that replied. I've never needed to use so much memory before, and was ignorant to how much magic was implemented in the 64G support on IA32. Unfortunately, there's not quite enough magic in there for my needs... now to find an affordable SMP Alpha system Thanks again, -Matt Matt Nelson wrote: > I am about to embark on a data processing software project that will > require a LOT of memory (about, ohhh, 6GB or so), and I was wondering if > there are any limitations to how one can use very large chunks of memory > under Linux. Specifically, is there anything to prevent me from > malloc()ing 6GB of memory, then accessing that memory as I would any > other buffer? FYI, the application > will be buffering a stream of data, then performing a variety of > calculations on large blocks of data at a time, before writing it out to > a socket. > > I've been eyeing an 8-way Intel box with gobs of memory, but if there > are subtle issues with using that much memory, I need to know now. > > I haven't seen this specifcally addressed, so I figured I should ask you > folk. Any insights/comments/reccomendations would be greatly appreciated. > > Thanks, > > Matt > -- Matthew Nelson Dynamics Technology, Inc. 21311 Hawthorne Blvd., Suite 300, Torrance, CA 90503-5610 Voice: (310) 543-5433 FAX: (310) 543-2117 Email: [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: reiserfs problem on SMP
On Tuesday, June 12, 2001 05:25:46 PM +0800 Jeff Chua <[EMAIL PROTECTED]>
wrote:
>
> Got the following journaling error on 2.4.5 SMP during shutdown ...
>
Known 2.4.5 problem. Fix below is from Al Viro:
-chris
diff -Nru a/fs/super.c b/fs/super.c
--- a/fs/super.cSat Jun 2 13:27:07 2001
+++ b/fs/super.cSat Jun 2 13:27:07 2001
@@ -873,6 +873,7 @@
}
spin_unlock(_lock);
down_write(>s_umount);
+ lock_kernel();
sb->s_root = NULL;
/* Need to clean after the sucker */
if (fs->fs_flags & FS_LITTER)
@@ -901,6 +902,7 @@
put_filesystem(fs);
sb->s_type = NULL;
unlock_super(sb);
+ unlock_kernel();
up_write(>s_umount);
if (bdev) {
blkdev_put(bdev, BDEV_FS);
-
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/
unused shared memory is written into core dump - bug or feature?
Hi everybody, I just noticed that when I attach some SYSV shared memory segments to my process and then that process dies from a SIGSEGV that _all_ the shared memory is dumped into the core file, even if it was never used and therefore didn't show up in any of the memory statistics. One may say: "Oh, that's just a feature". But for some reason, this is a small catastrophy: I try to share some memory between the child processes of an application. At the time when the child processes are fork()ed, it is not known how much shared memory will be needed later. No other processes should see that memory. I searched through the literature how this could be done, but alas, the recommended methods such as mmap()ing "/dev/zero" with MAP_SHARED or using MAP_ANON are not implemented in Linux as they are within other Unices, and so using "ftruncate" to expand the shared memory region doesn't work either. So the only work-around I found was to attach the very maximum of what is to be used as shared memory using the SYSV shared memory functions, and allocating/using subsets of this memory later on the "logical" level. This of course means that any "parent" process starts by attaching ~512MB of shared memory, but since they are not mapped at that time, there's no undue performance or memory/swap consumption. But if one of the programs crashes (and you know, this is nothing you can be sure to never happen :-), it stymies the whole system, as the kernel first seems to map all the 512MB, then dumps them into the core file. Please tell me there is either a way to keep the kernel from dumping these unused pages (but generate the much appreciated core-dump anyway) or there is some better method to share memory with one's child processes (not with the whole universe) in a way that allows either the child or the parent to extend the amount of shared memory... Thanks for any hints in advance, Peter Niemayer PS: Please CC me if you reply - thanks! - 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/
rsync hangs on RedHat 2.4.2 or stock 2.4.4
I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat
7.1) or stock 2.4.4 on several machines. rsync often hangs copying files
from NFS or local disks to local disks. Strangely the problem is fixed by
stracing one of the three rsync threads!
I've encountered the problem just rsyncing the linux 2.4.4 kernel source
tree to a new (blank) directory.
rsync -raxv /data/jss/sysadmin/linux-2.4.4/linux .
The problem is repeatable with this source tree (which includes binaries)
on several machines (one PII machine and an Athlon). The problem also
exists copying the stock Linux 2.4.5 source tree (download it to reproduce
the problem). It hangs on linux/scripts/ver_linux in that case.
For example:
xpc6:~> rsync -raxv /data/jss/sysadmin/linux-2.4.4/linux /tmp/kernel/
[]
linux/scripts/tkparse.c
linux/scripts/tkparse.h
linux/scripts/ver_linux
linux/vmlinux
[hangs here, for at least several hours]
(switch to another window)
xpc6:~> ps auxw|grep rsync
jss 3165 10.9 1.7 3144 2272 pts/0S14:20 0:19 rsync -raxv
/data/jss/sysadmin/linux-2.4.4/linux .
jss 3166 1.1 1.7 3128 2216 pts/0S14:20 0:02 rsync -raxv
/data/jss/sysadmin/linux-2.4.4/linux .
jss 3167 10.4 1.7 3136 2236 pts/0S14:20 0:18 rsync -raxv
/data/jss/sysadmin/linux-2.4.4/linux .
xpc6:~> su
[blah]
[root@xpc6 jss]# strace -p 3165
select(0, NULL, NULL, NULL, {0, 1}) = 0 (Timeout)
gettimeofday({992352238, 401281}, NULL) = 0
wait4(3166, 0xbfffdd80, WNOHANG, NULL) = 0
gettimeofday({992352238, 401846}, NULL) = 0
gettimeofday({992352238, 402088}, NULL) = 0
select(0, NULL, NULL, NULL, {0, 2}) = 0 (Timeout)
gettimeofday({992352238, 420838}, NULL) = 0
select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout)
gettimeofday({992352238, 431066}, NULL) = 0
wait4(3166, 0xbfffdd80, WNOHANG, NULL) = 0
gettimeofday({992352238, 431568}, NULL) = 0
gettimeofday({992352238, 431809}, NULL) = 0
select(0, NULL, NULL, NULL, {0, 2}) = 0 (Timeout)
[lots more of these]
[root@xpc6 jss]# strace -p 3166
[program starts working again]
select(2, NULL, [1], NULL, {17, 86}) = 1 (out [1], left {17, 83})
write(1, "\27\0\0\tlinux/arch/ia64/sn/io/\n", 27) = 27
select(6, [3 5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
read(5, "\30\0\0\t", 4) = 4
select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
read(5, "linux/arch/ia64/sn/sn1/\n", 24) = 24
select(2, NULL, [1], NULL, {60, 0}) = 1 (out [1], left {60, 0})
write(1, "\30\0\0\tlinux/arch/ia64/sn/sn1/\n", 28) = 28
select(6, [3 5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
read(5, "\32\0\0\t", 4) = 4
select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
read(5, "linux/arch/ia64/sn/tools/\n", 26) = 26
select(2, NULL, [1], NULL, {60, 0}) = 1 (out [1], left {60, 0})
write(1, "\32\0\0\tlinux/arch/ia64/sn/tools/\n", 30) = 30
select(6, [3 5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
read(5, "\27\0\0\t", 4) = 4
select(6, [5], NULL, NULL, {60, 0}) = 1 (in [5], left {60, 0})
[lots more]
[program finishes]
Has anyone else encountered this problem? Is it a kernel problem or an
rsync problem?
Please CC answers to me, as I'm not on linux-kernel.
Jeremy
--
Jeremy Sanders <[EMAIL PROTECTED]> http://www-xray.ast.cam.ac.uk/~jss/
Pembroke College, Cambridge. UK Institute of Astronomy, Cambridge. UK
-
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/
net.agent ?
Hi, I'm porting a driver on 2.4. , I've done the necessary to get him working, but when I read the logs I found something like this after doing that : insmod my_module ifconfig up my_module >my_module : received ioctl 35585 >/etc/hotplug/net.agent : register event not handled Somebody know how ensure that the ioctl call come from net.agent ? Am I obliged to handle the ioctl for compatibilty or something else ? coud I just ignore it ? I'm using redhat 7.1 kernel 2.4.2 Thanks sebastien person - 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/
