Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Sean Hunter wrote: > A working VM would have several differences from what we have in my > opinion, among which are: > - It wouldn't require 8GB of swap on my large boxes > - It wouldn't suffer from the "bounce buffer" bug on my > large boxes > - It wouldn't cause the disk drive on my laptop to be > _constantly_ in use even when all I have done is spawned a > shell session and have no large apps or daemons running. > - It wouldn't kill things saying it was OOM unless it was OOM. I fully agree these problems need to be fixed. I just wish I had the time to tackle all of them right now ;) We should be close to getting the 3rd problem fixed and the deadlock problem with the bounce buffers seems to be fixed already. Getting reclaiming of swap space and OOM fixed is a matter of time ... I hope I'll have that time in the near future. 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/
workaround for all this weirdness in vm?
Is running without swap a possible workaround for all this vm weirdness folks are reporting? Alexander - 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: VM Report was:Re: Break 2.4 VM in five easy steps
> reads the RTC device. The patched RTC driver can then > measure the elapsed time between the interrupt and the > read from userspace. Voila: latency. interesting, but I'm not sure there's much advantage over doing it entirely in user-space with the normal /dev/rtc: http://brain.mcmaster.ca/~hahn/realfeel.c it just prints out the raw time difference from when rtc should have woken up the program. you can do your own histogram; for summary purposes, something like stdev is probably best. - 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/
IOCTLS
first of all i am sorry to post this message here without actually knowing if this could be asked here... Where can i find the documentation about ioctls, specially the ioctls listed in asm/ioctls.h Thanks in advance Prasad<[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: Comment on patch to remove nr_async_pages limit
On Sat, 9 Jun 2001, Rik van Riel wrote: > On 5 Jun 2001, Zlatko Calusic wrote: > > Marcelo Tosatti <[EMAIL PROTECTED]> writes: > > > > [snip] > > > Exactly. And when we reach a low watermark of memory, we start writting > > > out the anonymous memory. > > > > Hm, my observations are a little bit different. I find that writeouts > > happen sooner than the moment we reach low watermark, and many times > > just in time to interact badly with some read I/O workload that made a > > virtual shortage of memory in the first place. > > I have a patch that tries to address this by not reordering > the inactive list whenever we scan through it. I'll post it > right now ... Excellent. I've done some of that (crude but effective) and have had nice encouraging results. If the dirty list is long enough, this most definitely improves behavior under heavy load. -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/
Re: Break 2.4 VM in five easy steps
On 6 Jun 2001, Miles Lane wrote: >> Precicely. Saying 8x RAM doesn't change it either. Sometime >> next week I'm going to purposefully put a new 60Gb disk in on a >> separate controller as pure swap on top of 256Mb of RAM. My >> guess is after bootup, and login, I'll have 48Gb of stuff in >> swap "just in case". > >Mike and others, I am getting tired of your comments. Sheesh. And I'm tired of having people tell me, or tell others to buy a faster computer or more RAM to work around a real technical problem. If a dual 1Ghz system with 1Gb of RAM and 60GB of disk space broken across 3 U160 drives is not a modern fast workstation I don't know what is. My 300Mhz system however works on its own stuff, and doesn't need upgrading. >The various developers who actually work on the VM have already >acknowledged the issues and are exploring fixes, including at >least one patch that already exists. Precicely, which underscores what I'm saying: The problem is acknowledged, and being worked on by talented hackers knowing what they are doing - so why must people keep saying "get more disk space, it is cheap?" et al.? That is totally nonuseful advice in most cases. Many have pointed out already for example how impossible that would be in a 500 computer webserver farm. >It seems clear that the uproar from the people who are having >trouble with the new VM's handling of swap space have been >heard and folks are going to fix these problems. It may not >happen today or tomorrow, but soon. What the heck else do you >want? I agree with you. What I want, is when someone talks about this stuff or inquires about it, for people to stop telling them that their computer is out of date and they should upgrade it as that is bogus advice. "It worked fine yesterday, why should I upgrade" reigns supreme. >Making enflammatory remarks about the current situation does >nothing to help get the problems fixed, it just wastes our time >and bandwidth. It's not like there is someone forcing you to read it though. >So please, if you have new facts that you want to offer that >will help us characterize and understand these VM issues better >or discover new problems, feel free to share them. But if you >just want to rant, I, for one, would rather you didn't. Point noted, however that isn't going to stop anyone from speaking their personal opinion on things. Freedom of speech. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - 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: temperature standard - global config option?
Michael H. Warfiel writes: > On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote: >> The bits are free; the API is hard to change. >> Sensors might get better, at least on high-end systems. >> Rounding gives a constant 0.15 degree error. >> Only the truly stupid would assume accuracy from decimal places. >> Again, the bits are free; the API is hard to change. ... > No... The average person, NO, the vast majority of people, > DO assume accuracy from decimal places and honestly do not know the > difference between precision and accuracy. I've had comments on this > thread in private E-Mail the reinforce this impression. Fine. Most user apps can round to the nearest degree, or even display the values "cool", "warm", "hot", and "BURNING!". The kernel API should not be so limiting. > Even the rounding error vis-a-vis the .15 is silly and irrelevant! > If the sensor is +- 1 degree, you can't even measure the rounding error, > even if you HAVE two decimal places. With that degree of accuracy, you > are no better off than 273 with no decimal places. Worrying about rounding > error on .15 when the accuracy is in the units is exactly the kind of > misinformed false precision that I worry about. You actually though that > the .15 was significant enough to worry about round error when, in fact, > it will be impossible to measure with the equipment available in the > environment of discourse. The 0.15 may mean the difference between: a. less than 0.005 chance of exceeding 370 degrees b. less than 0.01 chance of exceeding 370 degrees for a measurement that might be 365 degrees. >> One might provide other numbers to specify accuracy and precision. > > Now... That I can agree with and it would make absolute sense. > Especially if we were discussing lab grade or scientific grade measure > equipment and measurements. In fact, that would be a requirement for > any validity to be attached to measurements of that level of precision. No, at any level of precision. I'd sure want to know if the device is specified as "resolution 8 degrees, standard deviation 23". This information is fairly important. The user is responsible for defining acceptable risk, and the app should be able to provide a warning or shutdown based on this. For typical PC hardware, one might assume that the device is a cheap piece of junk 2 mm below the CPU. (with quite a bit of lag!) The lag ought to be specified too of course. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Sat, 9 Jun 2001, Jonathan Morton wrote: > >> On the subject of Mike Galbraith's kernel compilation test, how much > >> physical RAM does he have for his machine, what type of CPU is it, and what > >> (approximate) type of device does he use for swap? I'll see if I can > >> partially duplicate his results at this end. So far all my tests have been > >> done with a fast CPU - perhaps I should try the P166/MMX or even try > >> loading linux-pmac onto my 8100. > > > >It's a PIII/500 with one ide disk. > > ...with how much RAM? That's the important bit. Duh! :) I'm a dipstick. 128mb. -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/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, Marcelo Tosatti wrote: > On Fri, 8 Jun 2001, John Stoffel wrote: > > > More importantly, a *repeatable* set of tests is what is needed to > > test the VM and get consistent results from run to run, so you can see > > how your changes are impacting performance. The kernel compile > > doesn't really have any one process grow to a large fraction of > > memory, so dropping in a compile which *does* is a good thing. > > I agree with you. > > Mike, I'm sure you have noticed that stock kernel gives much better > results than mine or Jonathan's patch. I noticed that Jonathan brought back waiting.. that (among others) made me very interested. > Now the stock kernel gives us crappy interactivity compared to my patch. > (Note: my patch still does not gives me the interactivity I want under > high VM loads, but I hope to get there soon). (And that's why) Among other things (yes, I do love throughput) I've poked at the interactivity problem. I can't improve it anymore without doing some strategic waiting :( I used to be able to help it a little by doing a careful roll-up in scrub size as load builds.. trying to smooth the transition from latency oriented to hammer down throughput. > BTW, we are talking with the OSDL (http://www.osdlab.org) guys about a > possibility to setup a test system which would run a different variety of > benchmarks to give us results of different kinds of workloads. If that > ever happens, we'll probably get rid of most of this testing problems. Excellent! -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/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, Tobias Ringstrom wrote: > On Fri, 8 Jun 2001, Mike Galbraith wrote: > > On Fri, 8 Jun 2001, Tobias Ringstrom wrote: > > > On Fri, 8 Jun 2001, Mike Galbraith wrote: > > > > I gave this a shot at my favorite vm beater test (make -j30 bzImage) > > > > while testing some other stuff today. > > > > > > Could you please explain what is good about this test? I understand that > > > it will stress the VM, but will it do so in a realistic and relevant way? > > > > Can you explain what is bad about this test? ;) It spins the same VM wheels > > I think a load of ~30 is quit uncommon, and therefor it is unclear to me > that it would be a test that would be repesentative of most normal loads. It's not supposed to be repesentative. It's supposed to take the box rapidly (but not instantly) from idle through lo->medium->high and maintain solid throughput. > > as any other load does. What's the difference if I have a bunch of httpd > > allocating or a bunch of cc1/as/ld? This load has a modest cachable data > > set and is compute bound.. and above all gives very repeatable results. > > Not a big difference. The difference I was thinking abount is the > difference between spawning lots of processes allocating, using and > freeing lots of memory, compared to a case where you have a few processes > touching a lot of already allocated pages in some pattern. I was > wondering whether optimizing for your case would be good or bad for the > other case. I know, I know, I should do more testing myself. And I > should probably not ask you, since you really really like your test, > and you will probably just say yes... ;-) It's not a matter of optimizing for my case.. that would be horrible. It's a matter of is the vm capable of rapid and correct responses. > At home, I'm running a couple of computers. One of them is a slow > computer running Linux, serving mail, NFS, SMB, etc. I'm usually logged > in on a couple of virtual consoles. On this machine, I do not mind if all > shells, daemons and other idle processes are beeing swapped out in favor > of disk cache for the NFS and SMB serving. In fact, that is a very good > thing, and I want it that way. > > Another maching is my desktop machine. When using this maching, I really > hate when my emacsen, browsers, xterms, etc are swapped out just to give > me some stupid disk cache for my xmms or compilations. I do not care if a > kernel compile is a little slower as long as my applications are snappy. > > How could Linux predict this? It is a matter of taste, IMHO. I have no idea. It would be _wonderful_ if it could detect interactive tasks and give them preferencial treatment. > > I use it to watch reaction to surge. I watch for the vm to build to a > > solid maximum throughput without thrashing. That's the portion of VM > > that I'm interested in, so that's what I test. Besides :) I simply don't > > have the hardware to try to simulate hairy chested server loads. There > > are lots of folks with hairy chested boxes.. they should test that stuff. > > Agreed. More testing is needed. Now if we would have those knobs and > wheels to turn, we could perhaps also tune our systems to behave as we > like them, and submit that as well. Right now you need to be a kernel > hacker, and see through all the magic with shm, mmap, a bunch of caches, > page lists, etc. I'd give a lot for a nice picture (or state diagram) > showing the lifetime of a page, but I have not found such a picture > anywhere. Besides, the VM seems to change every new release anyway. > > > I've been repeating ~this test since 2.0 times, and have noticed a 1:1 > > relationship. When I notice that my box is ~happy doing this load test, > > I also notice very few VM gripes hitting the list. > > Ok, but as you say, we need more tests. > > > > Isn't the interesting case when you have a number of processes using lots > > > of memory, but only a part of all that memory is beeing actively used, and > > > that memory fits in RAM. In that case, the VM should make sure that the > > > not used memory is swapped out. In RAM you should have the used memory, > > > but also disk cache if there is any RAM left. Does the current VM handle > > > this case fine yet? IMHO, this is the case most people care about. It is > > > definately the case I care about, at least. :-) > > > > The interesting case is _every_ case. Try seeing my particular test as > > a simulation of a small classroom box with 30 students compiling their > > assignments and it'll suddenly become quite realistic. You'll notice > > by the numbers I post that I was very careful to not overload the box in > > a rediculous manner when selecting the total size of the job.. it's just > > a heavily loaded box. This test does not overload my IO resources, so > > it tests the VM's ability to choose and move the right stuff at the right > > time to get the job done with a minimum of additional overhead. > > I did not understand th
PATCH: 8139too fixes for testing
Testing requested, especially if you had problems with 8139too in recent
2.4.x kernels.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
Index: linux_2_4/drivers/net/8139too.c
diff -u linux_2_4/drivers/net/8139too.c:1.1.1.39
linux_2_4/drivers/net/8139too.c:1.1.1.39.2.3
--- linux_2_4/drivers/net/8139too.c:1.1.1.39Fri Jun 8 15:40:33 2001
+++ linux_2_4/drivers/net/8139too.c Fri Jun 8 21:22:43 2001
@@ -136,6 +136,10 @@
*/
+#define DRV_NAME "8139too"
+#define DRV_VERSION"0.9.18-pre1"
+
+
#include
#include
#include
@@ -146,13 +150,13 @@
#include
#include
#include
+#include
#include
+#include
-#define RTL8139_VERSION "0.9.17"
-#define MODNAME "8139too"
-#define RTL8139_DRIVER_NAME MODNAME " Fast Ethernet driver " RTL8139_VERSION
-#define PFX MODNAME ": "
+#define RTL8139_DRIVER_NAME DRV_NAME " Fast Ethernet driver " DRV_VERSION
+#define PFX DRV_NAME ": "
/* enable PIO instead of MMIO, if CONFIG_8139TOO_PIO is selected */
@@ -363,7 +367,10 @@
TxOK = 0x04,
RxErr = 0x02,
RxOK = 0x01,
+
+ RxAckBits = RxFIFOOver | RxOverflow | RxOK,
};
+
enum TxStatusBits {
TxHostOwns = 0x2000,
TxUnderrun = 0x4000,
@@ -542,6 +549,11 @@
};
+struct rtl_extra_stats {
+ unsigned long early_rx;
+ unsigned long tx_buf_mapped;
+ unsigned long tx_timeouts;
+};
struct rtl8139_private {
void *mmio_addr;
@@ -560,7 +572,6 @@
dma_addr_t rx_ring_dma;
dma_addr_t tx_bufs_dma;
signed char phys[4];/* MII device addresses. */
- u16 advertising;/* NWay media advertisement */
char twistie, twist_row, twist_col; /* Twister tune state. */
unsigned int full_duplex:1; /* Full-duplex operation requested. */
unsigned int duplex_lock:1;
@@ -574,6 +585,7 @@
wait_queue_head_t thr_wait;
struct semaphore thr_exited;
u32 rx_config;
+ struct rtl_extra_stats xstats;
};
MODULE_AUTHOR ("Jeff Garzik <[EMAIL PROTECTED]>");
@@ -582,6 +594,10 @@
MODULE_PARM (max_interrupt_work, "i");
MODULE_PARM (media, "1-" __MODULE_STRING(MAX_UNITS) "i");
MODULE_PARM (full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i");
+MODULE_PARM_DESC (multicast_filter_limit, "8139too maximum number of filtered
+multicast addresses");
+MODULE_PARM_DESC (max_interrupt_work, "8139too maximum events handled per interrupt");
+MODULE_PARM_DESC (media, "8139too: Bits 4+9: force full duplex, bit 5: 100Mbps");
+MODULE_PARM_DESC (full_duplex, "8139too: Force full duplex for board(s) (1)");
static int read_eeprom (void *ioaddr, int location, int addr_len);
static int rtl8139_open (struct net_device *dev);
@@ -596,7 +612,7 @@
static void rtl8139_interrupt (int irq, void *dev_instance,
struct pt_regs *regs);
static int rtl8139_close (struct net_device *dev);
-static int mii_ioctl (struct net_device *dev, struct ifreq *rq, int cmd);
+static int netdev_ioctl (struct net_device *dev, struct ifreq *rq, int cmd);
static struct net_device_stats *rtl8139_get_stats (struct net_device *dev);
static inline u32 ether_crc (int length, unsigned char *data);
static void rtl8139_set_rx_mode (struct net_device *dev);
@@ -938,7 +954,7 @@
dev->stop = rtl8139_close;
dev->get_stats = rtl8139_get_stats;
dev->set_multicast_list = rtl8139_set_rx_mode;
- dev->do_ioctl = mii_ioctl;
+ dev->do_ioctl = netdev_ioctl;
dev->tx_timeout = rtl8139_tx_timeout;
dev->watchdog_timeo = TX_TIMEOUT;
@@ -984,11 +1000,11 @@
for (phy = 0; phy < 32 && phy_idx < sizeof(tp->phys); phy++) {
int mii_status = mdio_read(dev, phy, 1);
if (mii_status != 0x && mii_status != 0x) {
+ u16 advertising = mdio_read(dev, phy, 4);
tp->phys[phy_idx++] = phy;
- tp->advertising = mdio_read(dev, phy, 4);
printk(KERN_INFO "%s: MII transceiver %d status
0x%4.4x "
"advertising %4.4x.\n",
- dev->name, phy, mii_status,
tp->advertising);
+ dev->name, phy, mii_status, advertising);
}
}
if (phy_idx == 0) {
@@ -1331,16 +1347,16 @@
rtl8139_chip_reset (ioaddr);
/* unlock Config[01234] and BMCR register writes */
- RTL_W8 (Cfg9346, Cfg9346_Unlock);
+ RTL_W8_F (Cfg9346, Cfg9346_Unlock);
/* Restore our idea of the MAC address. */
RTL_W32_F (MAC0 + 0, cpu_to_le32 (*(u32 *) (dev->dev_addr + 0)));
- RTL_W32 (MAC0 + 4, cpu_to_le32 (*(u32 *) (dev->dev_addr + 4)));
+ RTL_W32_F (MAC0 + 4, cpu_to_le32 (*(u32 *) (dev->dev_addr + 4)));
/* Must enable Tx/Rx before setting
Probable endianess problem in TLAN driver
Hello. I'm trying to use a Compaq Dual Netteligent card in a Apple Macintosh Performa 6360. Basically, my purpose is to use this system as a more powerful firewall than that the one I have today. To make things shorter, the TLAN driver on its atual incarnation does not work in PowerPC machines. It isn't detected on 2.2 kernel unless I activate it with setpci; OTOH, it is detected on 2.4, but does not work. I get messages like "TLAN: Adaptor Error: 0x180005" every time I try to ping other hosts; when this message appears, the link is reset and goes online again. Also I get occasional panics when I try to ping the machine from other machines in my Ethernet network. I've noticed also that the board statistics don't change: all values are zero, always. Physical media disruption was ruled out, since mii-diag reported that the link was up and I could verify this on the leds of the board and of the hub I use; both reported link up for the connection. mii-diag also detects correctly when the link is up or down. As I'm really no kernel hacker, I started looking for help. I've found Hollis of openprojects.org (CC:ed in this message), and we begun to think what could be the problem. I've generated backtraces of the panics I've got, but there wasn't nothing really conclusive. So Hollis inspected the code and found lines like these: host_int = inw( dev->base_addr + TLAN_HOST_INT ); outw( host_int, dev->base_addr + TLAN_HOST_INT ); or outl( virt_to_bus( tail_list ), dev->base_addr + TLAN_CH_PARM ); outl( TLAN_HC_GO, dev->base_addr + TLAN_HOST_CMD ); He said me that these funtions don't address the endianess question, and sent me a patch. He said that this probably wouldn't work, but I've decided to give a try anyway. Here is the patch: --- tlan.c.old Thu Jun 7 21:24:25 2001 +++ tlan.c Thu Jun 7 21:37:42 2001 @@ -172,6 +172,12 @@ #include #include +#if defined(__powerpc__) +#define inw(addr) le32_to_cpu(inw(addr)) +#define inl(addr) le32_to_cpu(inl(addr)) +#define outw(val, addr)outw(cpu_to_le32(val), addr) +#define outl(val, addr)outl(cpu_to_le32(val), addr) +#endif It's very clear (even to me) what it does: it takes into account the big-endianess of PowerPC for out[l,w] and in[l,w]. I've applied this patch, and for my surprise it brought some good effects. The error messages stopped, and the machine does not crash anymore. Also, I'm now able to see changes on the statistics of the board, even if they are completely bogus nowadays. It's a real change for good but for one thing: I still can't communicate with the other computers on my network. I've tried to contact Torben, but oddly seems that he is not around. The driver page in tlan.kernel.dk has not been updated since October 2000, and there is no recent activity either on the TLAN driver mailing list or in the new project page on Compaq (http://linuxalpha.compaq.com/sourceforge/project/?group_id=12). Again, as I'm no kernel hacker, I'd like to ask the linux-kernel list for help (even if to point me to sources about correcting this problem). Please answer directly to me, as I'm not subscribed to linux-kernel. TIA, Paulo Fessel - 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/
cramfs
I hate to ask this, however here goes. I am doing some remote upgrading and some other really funky stuff to some boxes I keep up. Part of these are total system upgrades and I need to move data out of the way while still having a working box. I decided that cramfs may be the way to do this. If you can tell me no and point me to a resource on how to do this, I would LOVE to hear about it. However, the question is, how can I tell lilo to tell the kernel too boot off a cramfs file system? I have already created the file with /etc /bin /sbin /dev and /lib from a working system, doing the correct deletions and other such changes. I have a 15 meg cramfs that should do the trick. Thank you for any help you can offer. Trever Adams - 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: VM Report was:Re: Break 2.4 VM in five easy steps
>> On the subject of Mike Galbraith's kernel compilation test, how much >> physical RAM does he have for his machine, what type of CPU is it, and what >> (approximate) type of device does he use for swap? I'll see if I can >> partially duplicate his results at this end. So far all my tests have been >> done with a fast CPU - perhaps I should try the P166/MMX or even try >> loading linux-pmac onto my 8100. > >It's a PIII/500 with one ide disk. ...with how much RAM? That's the important bit. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) The key to knowledge is not to rely on people to teach you it. GCS$/E/S dpu(!) s:- a20 C+++ UL++ 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+(*) - 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: temperature standard - global config option?
John Chris Wren writes: > coupling to the CPU that is about as bad as it can get. You've got an epoxy > housing of an inconsistent shape in contact with ceramic. The actual > contact point is miniscule. There's no thermal paste, and often, I've seen > the sensors not quite raised high enough to contact the chip (you should be > able to rack a business card across the empty socket and feel a slight > "bump" as you touch the sensor. If not, you need to bend it up slightly, to > give better physical contact to the CPU). > > But in spite of all this, you're not really measure the critical > temperature, which is junction tempature. Yes, case tempature has *some* There are processors with temperature measurement built right into the silicon. > For the record, in the course of a normal day, I see my temperatures > fluctuate from 48C with the house A/C set to 73, to 56C when I open the > doors, and let it get up to 76 in the house. That's 8C (14.4F) over a 3F > change in ambient. This makes sense. Heat increases resistance, which generates heat. At some point, a tiny increase will cause thermal run-away. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Sat, 9 Jun 2001, Jonathan Morton wrote: > On the subject of Mike Galbraith's kernel compilation test, how much > physical RAM does he have for his machine, what type of CPU is it, and what > (approximate) type of device does he use for swap? I'll see if I can > partially duplicate his results at this end. So far all my tests have been > done with a fast CPU - perhaps I should try the P166/MMX or even try > loading linux-pmac onto my 8100. It's a PIII/500 with one ide disk. -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/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, Mike Galbraith wrote: > On Fri, 8 Jun 2001, John Stoffel wrote: > > I agree, this isn't really a good test case. I'd rather see what > > happens when you fire up a gimp session to edit an image which is > > *almost* the size of RAM, or even just 50% the size of ram. > > OK, riddle me this. If this test is a crummy test, just how is it Personally, I'd like to see BOTH of these tests, and many many more. Preferably, handed to the VM hackers in various colourful graphs that allow even severely undercaffeinated hackers to see how things changed for the good or the bad between kernel revisions. 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/
Re: Background scanning change on 2.4.6-pre1
On Thu, 7 Jun 2001, Linus Torvalds wrote: > On Thu, 7 Jun 2001, Marcelo Tosatti wrote: > > time (the old code from Rik which has been replaced by this code tried to > > avoid that) > > Now, I think the problem with the old code was that it didn't do _any_ > background page aging if "inactive" was large enough. And that really > doesn't make all that much sense. Background page aging is needed to > "sort" the active list, regardless of how many inactive pages there are. I'll be posting a patch in a few minutes (against 2.4.5-acX, which was the latest kernel available to me while on holidays with no net access) which doesn't "roll over" the inactive dirty pages when we scan the list. This should make us reclaim the inactive_dirty pages in a much better LRU order, so this whole background aging limiting stuff becomes close to moot. 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: Comment on patch to remove nr_async_pages limit
On 5 Jun 2001, Zlatko Calusic wrote: > Marcelo Tosatti <[EMAIL PROTECTED]> writes: > > [snip] > > Exactly. And when we reach a low watermark of memory, we start writting > > out the anonymous memory. > > Hm, my observations are a little bit different. I find that writeouts > happen sooner than the moment we reach low watermark, and many times > just in time to interact badly with some read I/O workload that made a > virtual shortage of memory in the first place. I have a patch that tries to address this by not reordering the inactive list whenever we scan through it. I'll post it right now ... (yes, I've done some recreational patching while on holidays) 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: VM Report was:Re: Break 2.4 VM in five easy steps
Jonathan Morton wrote: > > [ Re-entering discussion after too long a day and a long sleep... ] > > >> There is the problem in terms of some people want pure interactive > >> performance, while others are looking for throughput over all else, > >> but those are both extremes of the spectrum. Though I suspect > >> raw throughput is the less wanted (in terms of numbers of systems) > >> than keeping interactive response good during VM pressure. > > > >And this raises a very very important point: raw throughtput wins > >enterprise-like benchmarks, and the enterprise people are the ones who pay > >most of hackers here. (including me and Rik) > > Very true. As well as the fact that interactivity is much harder to > measure. The question is, what is interactivity (from the kernel's > perspective)? It usually means small(ish) processes with intermittent > working-set and CPU requirements. These types of process can safely be > swapped out when not immediately in use, but the kernel has to be able to > page them in quite quickly when needed. Doing that under heavy load is > very non-trivial. For the low-latency stuff, latency can be defined as the worst-case time to schedule a userspace process in response to an interrupt. That metric is also appropriate in this case, (latency equals interactivity), although here you don't need to be so fanatical about the *worst case*. A few scheduling blips here are less fatal. I have tools to measure latency (aka interactivity). At http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads there is a kernel patch called `rtc-debug' which causes the PC RTC to generate a stream of interrupts. A user-space task called `amlat' responds to those interrupts and reads the RTC device. The patched RTC driver can then measure the elapsed time between the interrupt and the read from userspace. Voila: latency. When you close the RTC device (by killing amlat), the RTC driver will print out a histogram of the latencies. `amlat' at present gives itself SCHED_RR policy and runs under mlockall() - for your testing you'll need to delete those lines. So. Simple apply rtc-debug, run `amlat' and kill it when you've finished the workload. The challenge will be to relate the latency histogram to human-perceived interactivity. I'm not sure of the best way of doing that. Perhaps monitor the 90th percentile, and aim to keep it below 100 milliseconds. Also, `amlat' should do a bit of disk I/O as well. - 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: no sound with CS4281 card
On Thu, 31 May 2001, Woller, Thomas wrote:
> I'll send the latest driver that I have via separate email. Toshiba
> refuses to supply equipment, and there are some design issues with
> Toshiba laptops.
It turned out a one-liner change to the in-kernel driver
also worked (I was on holidays for a week, so I only see
this email after I got the thing to work ;))
--- linux-2.4.5-ac2/drivers/sound/cs4281/cs4281m.c.orig Fri Jun 1 09:19:57 2001
+++ linux-2.4.5-ac2/drivers/sound/cs4281/cs4281m.c Fri Jun 1 09:20:57 2001
@@ -658,7 +658,7 @@
card->pBA0 + BA0_ACCTL);
// Wait for the write to occur.
- for (count = 0; count < 10; count++) {
+ for (count = 0; count < 100; count++) {
// First, we want to wait for a short time.
udelay(25);
// Now, check to see if the write has completed.
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: xircom_cb problems
Quoting Ion Badulescu <[EMAIL PROTECTED]>: > On Fri, 8 Jun 2001, Tom Sightler wrote: > > > OK, I tried your patch, it did fix the problem where pump wouldn't > > pull an IP address, but I'm still having the problem where my ping > > times go nuts. I've attached an example, it's 100% repeatable on my > > network at work. It was so bad I couldn't get any benchmark > numbers. > > Just one more question: do you see the same bad ping times if you > completely comment out the call to set_half_duplex? No, the problem goes away if I do this, although then I hae the performance problems as before. I also noticed that even when the call to set_half_duplex is left in, the switch reports that the link is still in full duplex, 100Mb mode. I tried forcing half duplex on the switch but this didn't help. It actually looks like half duplex is not really being set correctly. I plugged in a desktop with an eepro100 based card and forced the duplex to half with the command line options and the switch properly reported a half-duplex link had been negotiated, with the xircom card the switch reports full-duplex with or without the set_half_duplex line, which certainly implies it's not really working right. Hope the helps. I won't be back at the office until Monday so that's the earliest I'll be able to test again, but I'll be glad to test any combination that I can. Later, Tom - 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: missing sysrq
BTW, you ONLY need to echo 1 > /proc../sysrq if you use a distribution that puts a 0 there on init. By default the kernel initializes with '1'. David >>>I compiled it, and the sysrq is definitely in the config. No doubt at >>>all. I also use make mrproper and config again before dep and actual >>>compile. Maybe it is just a quirk/oddball. >>> >>>D. Stimits, [EMAIL PROTECTED] >>> >>Have you tried "echo 1 > /proc/sys/kernel/sysrq"? >>You need both, compiled in and activation. >> - 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] Race between sys_swapon and /proc/swaps (2.2)
This is the equivalent patch for Linux 2.2 (prepared against 2.2.19)
for the swapon/procfs race also described in my previous email.
sys_swapon() sets SWP_USED in p->flags when it begins to set up a swap
area, and then calls vmalloc() to allocate p->swap_map[], which may
sleep. Most other users of the swap info structures either traverse the
swap list (to which the new swap area hasn't yet been added) or check
SWP_WRITEOK (which hasn't yet been set), but get_swaparea_info() only
checks for SWP_USED, and then proceeds to dereference ptr->swap_map. So
reading /proc/swaps whilst doing a swapon() can Oops.
This could either be solved by making get_swaparea_info() check for
ptr->swap_map, or check for ((ptr->flags & SWP_WRITEOK) == SWP_WRITEOK).
The patch below (applicable to 2.2 - patch for 2.4 in previous email)
checks for the former on the grounds that that is what's causing the
immediate problem, and some people might want to be able to use
/proc/swaps to track the progress of a swapoff().
Paul
diff -u linux/mm/swapfile.c linux/mm/swapfile.c
--- linux/mm/swapfile.cWed May 9 23:34:24 2001
+++ linux.new/mm/swapfile.c Fri Jun 8 17:00:54 2001
@@ -448,7 +448,7 @@
len += sprintf(buf, "Filename\t\t\tType\t\tSize\tUsed\tPriority\n");
for (i = 0 ; i < nr_swapfiles ; i++, ptr++) {
- if (ptr->flags & SWP_USED) {
+ if ((ptr->flags & SWP_USED) && ptr->swap_map) {
char * path = d_path(ptr->swap_file, page, PAGE_SIZE);
len += sprintf(buf + len, "%-31s ", path);
-
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.5-ac11
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac11 o Fix the megaraid driver ioctl check (me) o Fix the moxa ioctl checks (me) o Fix the i810 dri length check (me) o Fix array check in se401.c (me) o Fix scc irq array problems (me) o Fix sign check on zr36120 (me) o Fix sign check in raw driver(me) o Fix zr36067 array size check(me) | All the above from the Stanford checker o Fix an irq order assumption in the i810 audio (Doug Ledford) o Make real mode poweroff configurable and also (Arjan van de Ven) add DMI entries for it o Clean up Alpha oops reporting (Will Woods) o Fix ia64 build bug from mmap change (Bill Nottingham) o Fix sysinfo padding so m68k comes out right (Jes Sorensen) o Update pci ids related to ide devices (Andre Hedrick) o Update ide registers/ioctl numbers/info (Andre Hedrick) o Fix speed detection on slc90e66 (Andre Hedrick) o Update promise IDE driver (Andre Hedrick) o osb4 becomes generic serverworks ide driver (Andre Hedrick) o Use new inits on ide_tape, add a reinit (Andre Hedrick) o Use new inits on ide_floppy add a reinit(Andre Hedrick) o Add amd74xx ide driver (Andre Hedrick) o Tidy up ide disk init/reinit. Add feature (Andre Hedrick) register clear o Additional ide updates (Andre Hedrick) 2.4.5-ac10 o Fix xircom cardbus filter setup (Ion Badulescu) o Dave Jones has moved(Dave Jones) o Further Configure.help cleanup (Eric Raymond) o Switch usb serial driver locking(Greg Kroah-Hartmann) o Update IRDA Irnet protocol code (Jean Tourrilhes) o Update ide-tape and osst drivers(Willem Riede) o Add ethtool support to ne2k-pci (Jeff Garzik) o Misc small network driver tweaks/cleanup(Jeff Garzik) o Module description strings for net drivers (Jeff Garzik) o Fix thread/unload race in reiserfs (Nikita Danilov) o Fix a race in reiserfs_writepage(Chris Mason) o Add prolific 2203 USB serial support(Greg Kroah-Hartmann) o Update isdn maintainers (Kai Germaschewski) o Add another USS720 device entry (Steve Tell) o Reap dead swap cache pages (Marcelo Tosatti) o Fix USB sign handling error (Jochen Pernsteiner) o Update input driver docs(Vojtech Pavlik) o Fix locking bug in hysdn(Kai Germaschewski) o Fix hid parsing bug with feature reports(Vojtech Pavlik) o Fix ataraid config.in bug (Jim Wright) 2.4.5-ac9 o Fix gameport link problems (Vojtech Pavlik) o Fix an oops in the sg driver(Tachino Nobuhiro) o Fix brlock indexing bug (Takanori Kawano) o Add parport_pc_unregister_port (Tim Waugh) o Configure.help updates (Eric Raymond) o Fix xircom_cb problems with some cisco kit (Ion Badulescu) o Fix tdfxfb cursor rendering bug (Franz Melchior) o Add driver for the sony vaio i/o controller (Stelian Pop, Junchi Morita, Takaya Kinjo, Andrew Tridgell) o Orinoco updates for symbol, intel, 3com cards (Jean Tourrihles) o Use list_del_init in uhci driver(Herbert Xu) o Fix a uhci SMP deadlock (Herbert Xu) o Allow faster freeing of reisefs metadata(Chris Mason) o Fix error path leaks in reiserfs(Chris Mason, Vladimir Saveliev) o Fix NFS problems triggered by 2.4.5 mmap change (Trond Myklebust) o Resynchronize with m68k tree(Jes Sorensen) o Add es1371 sound driver locking (Frank Davis) o Fix a small error in the trident locking(Frank Davis) 2.4.5-ac8 o Fix sign handling bug in random sysctl
[PATCH] Race between sys_swapon and /proc/swaps (2.4)
sys_swapon() sets SWP_USED in p->flags when it begins to set up a swap
area, and then calls vmalloc() to allocate p->swap_map[], which may
sleep. Most other users of the swap info structures either traverse the
swap list (to which the new swap area hasn't yet been added) or check
SWP_WRITEOK (which hasn't yet been set), but get_swaparea_info() only
checks for SWP_USED, and then proceeds to dereference ptr->swap_map. So
reading /proc/swaps whilst doing a swapon() can Oops.
This could either be solved by making get_swaparea_info() check for
ptr->swap_map, or check for ((ptr->flags & SWP_WRITEOK) == SWP_WRITEOK).
The patch below (applicable to 2.4.5 - patch for 2.2 in following email)
checks for the former on the grounds that that is what's causing the
immediate problem, and some people might want to be able to use
/proc/swaps to track the progress of a swapoff().
Paul
diff -Naur linux/mm/swapfile.c linux.new/mm/swapfile.c
--- linux/mm/swapfile.cWed Apr 11 21:59:56 2001
+++ linux.new/mm/swapfile.c Fri Jun 8 17:18:32 2001
@@ -503,7 +503,7 @@
len += sprintf(buf, "Filename\t\t\tType\t\tSize\tUsed\tPriority\n");
for (i = 0 ; i < nr_swapfiles ; i++, ptr++) {
- if (ptr->flags & SWP_USED) {
+ if ((ptr->flags & SWP_USED) && ptr->swap_map) {
char * path = d_path(ptr->swap_file, ptr->swap_vfsmnt,
page, PAGE_SIZE);
-
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: question about scsi generic behavior
> Hardcoding of block size to 512 bytes for disk devices is what currently > either the block device driver or the sd driver is doing. Because, if I'm using 2048 byte block sized scsi media just fine. I've not tried using sg on the same device - 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/
[PANIC] aic7xxx loaded from initrd under 2.4.5
A panic occurs at boot while the aic7xxx is doing its thing..the following has been hand copied from the screen... > printing eip: >c01b6e36 *pde = >Oops: >CPU: 1 >EIP: 0010:[] >EFLAGS: 00010202 >eax: 003 ebx: 1261 ecx: edx: c144fd74 esi: >000edi: cff1a3c0 ebp: cff18f60 esp: c144fd54 >ds: 0018 es: 0018ss: 0018 >Process swapper (pid: 1, stackpage=c144f000) >Stack: c144e000 cff1a3c0 c013abea c144fd74 1261 > cff17c00 cfb669e0 0202 0bb8 cff17c00 cfb8fa00 >d080452e cfb8fa00 0202 cfb8fa00 d081c640 c0300900 >cfff4350 cfff0100 cfd01f20 Call Trace: [] [] >[] [] [] [] [] > [] [] [] [] >[] [] [] [] > [] [] [] [] >[] [] >[][] > [] [] >Code: 8b 40 10 83 f8 02 7e 62 b8 f0 ff ff ff eb 74 85 c9 b8 ea ff >Kernel panic: Attempted to kill init! In this particular instance the driver was aic7xxx_old, tested because the current aic7xxx had been behaving identically. The problem had not occurred when I tried aic7xxx as part of a monolithic 2.4.5 and no initrd/modules. The box is an IBM Netfinity 4500R with dual pentiums, ServeRAID 3L adapter attaching three internal drives, internal SCSI adapter disabled and IBM's Ultra 160 SCSI controller (Adaptec 29160) tested with and without a drive attached. Original system is RedHat 7.1 with fresh kernel 2.4.5 (for SMP) and latest patch for ext3 applied. Booting was initially set to launch a monolithic 2.4.5 kernel which boots with no problem. Then I tried it 2.4.5 from scratch with a fresh initrd and modules of scsi and aic7xxx where it causes the panic described above. -- Maurice Volaski, [EMAIL PROTECTED] Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University - 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: temperature standard - global config option?
> "MHW" == Michael H Warfield <[EMAIL PROTECTED]> writes: [snip] MHW> Yes, bits are free, sort of... That's why an extra decimal MHW> place is "ok". Keeping precision within an order of magnitude MHW> of accuracy is within the realm of reasonable. Running out to MHW> two decimal places for this particular application is just MHW> silly. If it were for calibrated lab equipment, fine. But not MHW> for CPU temperatures. You do introduce some rounding errors if the measurement isn't in Celsius or Kelvin. Ie, you must do a conversion because the hardware isn't in the desired units. In this case, the extra precision will be beneficial. If you are going your route, you should send error bars with all the measurements ;-) Fine, too many decimals leads to a false sense of security. However, no one knows the accuracy of any future temperature sensors so why not accommodate the possibility. Certainly some band gap semis can give a pretty good measurement if you have good coupling. If the temperature sensor was built into the CPU, you might actually have accuracy! regards, Bill Pringlemeir. This thread keeps going and going and going... - 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: question about scsi generic behavior
Well, Hardcoding of block size to 512 bytes for disk devices is what currently either the block device driver or the sd driver is doing. Because, if I run dd to the same device using the corresponding block device (sde) it runs fine. So, I feel that either the sg driver or the block device driver or sd driver needs to be fixed. One more thing is that, sg driver can find out from READ_CAPACITY the current block size on the device. So, if dd specifies bs=4096 and count=1, then accordingly, the sg driver should set the count to 8 and bs to the bs of the device. IMHO, untimately, the total transfer length is what matters. Regards, -hiren (408)970-3062 [EMAIL PROTECTED] > -Original Message- > From: David Chambliss [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 08, 2001 4:49 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: question about scsi generic behavior > > > > I think you need to set bpt=8 . > > It is possible to set some drives to block sizes other than > 512 bytes, and > hardcoding 512 is not a good idea, especially in code that > might last a > while. In a few years we might have 4096-byte blocks to let > the drives use > more powerful error correcting codes. > > David Chambliss > Research Staff Member, Computer Science /Storage Systems > IBM Research Division > (408) 927-2243 (TL 457-2243) > FAX (408) 927-3497 > - 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: question about scsi generic behavior
I think you need to set bpt=8 . It is possible to set some drives to block sizes other than 512 bytes, and hardcoding 512 is not a good idea, especially in code that might last a while. In a few years we might have 4096-byte blocks to let the drives use more powerful error correcting codes. David Chambliss Research Staff Member, Computer Science /Storage Systems IBM Research Division (408) 927-2243 (TL 457-2243) FAX (408) 927-3497 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please test: workaround to help swapoff behaviour
>> I looked at try_to_unuse in swapfile.c. I believe that the algorithm is >> broken. >> For each and every swap entry it is walking the entire process list >> (for_each_task(p)). It is also grabbing a whole bunch of locks >> for each swap entry. It might be worthwhile processing swap entries in >> batches instead of one entry at a time. >> >> In any case, I think having this patch is worthwhile as a quick and dirty >> remedy. > >Bulent, > >Could you please check if 2.4.6-pre2+the schedule patch has better >swapoff behaviour for you? No problem. I will check it tomorrow. I don't think it can be any worse than it is now. The patch looks correct in principle. I believe it should go in to 2.4.6. But I will test it. On small machines people don't notice it, but otherwise if you have few GB of memory it really hurts. Shutdowns take forever since swapoff takes forever. - 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: temperature standard - global config option?
On Fri, Jun 08, 2001 at 01:33:44PM -0800, Leif Sawyer wrote: > > From: L. K. [mailto:[EMAIL PROTECTED]] > > I really do not belive that for a CPU or a motherboard +- 1 > > degree would make any difference. > You haven't pushed your system, or run it in a hostile > environment then. There are many places where systems are run > right up to the edge of thermal breakdown, and it's a firm > requirement to know exactly what that edge is. > > If a CPU runs fine at, say, 37 degrees C, I do not belive it > > will have any problems running at 38 or 36 degrees. I support > > the ideea of having very good sensors for temperature > > monitoring, but CPU and motherboard temperature do not depend > > on the rise of the temperature of 1 degree, but when the > > temperature rises 10 or more degrees. I hope you understand > > what I want to say. > I have a CPU that runs great up to 43C, and shuts down hard at 44C > so I obviously want to know how close I am to that. I don't want > rounding errors to get in the way, and I don't want changes > between kernel revs to affect it either. If the rounding errors are less than the accuracy and the reproducibility of your sensor, and you operate in that range and depend on those values, then you have no clue where you are, no matter what your granularity. You sound like the classic example of why we should NOT do this. You are foolish enough to depend on that precision and think that it's accuracy and think that it means something in comparision to the identical measurement 15 minutes later. It does not. > If we've got the bitspace, keep the counters as granular as > possible within the useable range that we're designing for. > counter = .01 * degrees kelvin Then you are being foolish. Your sensors are neither accurate to that degree nor are they reproducible to that degree. What you are describing is jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - 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: temperature standard - global config option?
[Snip] (Mike writes a bunch a good stuff) > Yes, bits are free, sort of... That's why an extra decimal > place is "ok". Keeping precision within an order of magnitude of > accuracy is within the realm of reasonable. Running out to two decimal > places for this particular application is just silly. If it were for > calibrated lab equipment, fine. But not for CPU temperatures. > > Yes, APIs are difficult to change. But can you honestly say > that, even if we magically get off the shelf economical > temperature sensors > that are two orders of magnitude more accurate (without need of constant > tracible recalibration - these things DO drift), that this level of > precision would have any real meaning at all? I would expect the > CPU temperature to vary by a few hundreths of a degree just by how > many people were sweating in the cube next to me. > [snip] > > Now... That I can agree with and it would make absolute sense. > Especially if we were discussing lab grade or scientific grade measure > equipment and measurements. In fact, that would be a requirement for > any validity to be attached to measurements of that level of precision. > But that's not what we are talking about here, is it? We're not talking > about a lab grade instrumentation API here, are we? If we are, then > everything changes. > > Mike As someone who has been intimately involved in temperature measurement of electronics, Mike has pretty much thoroughly addressed the issue. Allow me to add this: You can go buy 12 "calibrated" temperature sensors (commercial, not lab quality), and you will get 12 different temperatures. When sampling the sensor (usually a thermocouple) in a motherboard, you have at best 1% resistors being used in the surrounding support components, +20%/-10% capacitors, A/Ds with +-1 LSB resolution, and worst of all, a coupling to the CPU that is about as bad as it can get. You've got an epoxy housing of an inconsistent shape in contact with ceramic. The actual contact point is miniscule. There's no thermal paste, and often, I've seen the sensors not quite raised high enough to contact the chip (you should be able to rack a business card across the empty socket and feel a slight "bump" as you touch the sensor. If not, you need to bend it up slightly, to give better physical contact to the CPU). But in spite of all this, you're not really measure the critical temperature, which is junction tempature. Yes, case tempature has *some* correlation, but it's not ratiometric. It can be affected by the mounting of the motherboard (believe it or not, you can see over 1C different in temperature between a vertical and horizontally mounted motherboard just because of convection out from under the socket. Yea, we would all love to truly know the CPU tempature down to a fraction of a degree. But it's useless information. Kinda of like knowing your fan speed to less than 100 RPM. Voltages fluctuations of .1 volts can cause a 100+ RPM change in the fan speed. All you really need to know that it's turning a lot less than when it first was. But I digress. Temperature measurement is an art. It requires having good sensors, good conversion electronics, and good mechanical coupling (if you really doubt this, look at the networks required to properly compensate any standard JK thermocouple). On top of ALL this mess, you have values being passed back from the hardware that are improperly converted. Ever wonder why the BIOS never exactly matches what you see from the 'sensors' program? It's because the adjustment factors in the config file are a best guess. For the record, in the course of a normal day, I see my temperatures fluctuate from 48C with the house A/C set to 73, to 56C when I open the doors, and let it get up to 76 in the house. That's 8C (14.4F) over a 3F change in ambient. --John - 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] sockreg2.4.5-05 inet[6]_create() register/unregister table
[EMAIL PROTECTED] said: > Consider a chunk of x86 instructions using a home-grown OS > abstraction layer, and drivers that implement that layer for both > Linux and any non-GPL operating system. The binary blob is obviously > not derived from Linux, and may in fact run without modification in a > BSD or Solaris/x86 kernel. > There is in fact just such a layer. It might not currently have the > features needed to implement TCP, but it could be extended as needed. Sounds like you're talking about UDI. I thought that had died the horrible slow death it deserved - only to be dusted off, redone in CPU-agnostic bytecode and called ACPI. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
[ Re-entering discussion after too long a day and a long sleep... ] >> There is the problem in terms of some people want pure interactive >> performance, while others are looking for throughput over all else, >> but those are both extremes of the spectrum. Though I suspect >> raw throughput is the less wanted (in terms of numbers of systems) >> than keeping interactive response good during VM pressure. > >And this raises a very very important point: raw throughtput wins >enterprise-like benchmarks, and the enterprise people are the ones who pay >most of hackers here. (including me and Rik) Very true. As well as the fact that interactivity is much harder to measure. The question is, what is interactivity (from the kernel's perspective)? It usually means small(ish) processes with intermittent working-set and CPU requirements. These types of process can safely be swapped out when not immediately in use, but the kernel has to be able to page them in quite quickly when needed. Doing that under heavy load is very non-trivial. It can also mean multimedia applications with a continuous (maybe small) working set, a continuous but not 100% CPU usage, and the special property that the user WILL notice if this process gets swapped out even briefly. mpg123 and XMMS fall into this category, and I sometimes tried running these alongside my compilation tests to see how they fared. I think I had it going fairly well towards the end, with mpg123 stuttering relatively rarely and briefly while VM load was high. On the subject of Mike Galbraith's kernel compilation test, how much physical RAM does he have for his machine, what type of CPU is it, and what (approximate) type of device does he use for swap? I'll see if I can partially duplicate his results at this end. So far all my tests have been done with a fast CPU - perhaps I should try the P166/MMX or even try loading linux-pmac onto my 8100. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) The key to knowledge is not to rely on people to teach you it. GCS$/E/S dpu(!) s:- a20 C+++ UL++ 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+(*) - 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: [CHECKER] 15 probable security holes in 2.4.5-ac8
On Fri, 8 Jun 2001, Dawson Engler wrote: > You can look at this checker as essentially tracking whether the > information from an untrusted source (e.g., from copy_from_user) can reach > a trusting sink (e.g., an array index). The main limiting factor on its > effectiveness is that we have a very incomplete notion of trusting sinks. > If anyone has suggestions for other general places where it's dangerous > to consume bad data, please send me an email. I wrote something similar to this for userspace (via ld preload). Most of my checks followed strings around and made sure they were length checked so as to avoid stack overflows, but I also checked args to open, etc.. In your case, basically all destinations are trusting sinks at some level: userspace gives you data to put it somewhere. You might want to instead check that data is passing through functions that 'detaint', by checking capabilities, etc. I bet that you'll find that something like 90% of code paths are covered by a few common security checks. And that most of the remainder could be rewritten to be. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
question about scsi generic behavior
Hi List, I am trying to use sg_dd which goes through the scsi generic driver. This is how use it. sg_dd if=/dev/zero of=/dev/sg5 bs=4096 count=1 And sg5 is actually a disk. The question that I have is, does the scsi generic driver have a knowledge about what kind of device it is dealing with ? As you know, all disk drives have block size of 512 bytes. So, according to the above command, I am suppose write 4096 bytes of data. But when my driver gets the CDB, I see that the transfer length is set to 1 block instead of 8 blocks. And to transfer 4096 bytes, obviously we need transfer length=8 in CDB. Since, the transfer length is set to 1, the drive comes back with 1 512 byte block and then comes back with a good status because of which sg_dd command is not able to transfer all 4096 bytes of data. Any input on this ? Regards, -hiren [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: temperature standard - global config option?
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote: > The bits are free; the API is hard to change. > Sensors might get better, at least on high-end systems. > Rounding gives a constant 0.15 degree error. > Only the truly stupid would assume accuracy from decimal places. > Again, the bits are free; the API is hard to change. Twice a year I'm a judge at science fairs. Once at the local level and once at the state level. I generally judge on the senior level in the physics category. All too often I have a hard time even convincing some of my fellow judges. Each year there is at least one project where some student has used "fancy scientific equipment" to make measurements of impressive precision and beautiful results. Till you look closer and you find that their standard deviation is as large as their averages and their raw test results are all over the map. With 5 or more decimal places of precision, you find that their sample sizes and proceedures don't even support one or two decimal places, if they are lucky. If it were not for the fact that I don't think they are really that good at it, I would give them an award for "if you can't dazzle them with brilliance, baffle them with bullshit". Unfortunately, they honestly don't KNOW the difference between precision and accuracy. We often judge between a half a dozen and a dozen exhibits. This comes up every year and gets written up in comments every year. Of course, you can't be harse in judging these things and most of them really do make a legitimate effort, but it is difficult to tactfully explain to someone why their elaborate and extremely detailed results amount to utter jibberish. (To the smartasses who are about to fire off the obligatory smart remarks: Trust me, I am much more tactful with those students than I am on this list... Maybe I shouldn't be. Read that either way.) What's more apalling is that their teachers did not catch this and I have to point out the fatal flaws to a lot of my co-judges who were impressed with the scientific prowess of these individuals. No... The average person, NO, the vast majority of people, DO assume accuracy from decimal places and honestly do not know the difference between precision and accuracy. I've had comments on this thread in private E-Mail the reinforce this impression. Yes, bits are free, sort of... That's why an extra decimal place is "ok". Keeping precision within an order of magnitude of accuracy is within the realm of reasonable. Running out to two decimal places for this particular application is just silly. If it were for calibrated lab equipment, fine. But not for CPU temperatures. Yes, APIs are difficult to change. But can you honestly say that, even if we magically get off the shelf economical temperature sensors that are two orders of magnitude more accurate (without need of constant tracible recalibration - these things DO drift), that this level of precision would have any real meaning at all? I would expect the CPU temperature to vary by a few hundreths of a degree just by how many people were sweating in the cube next to me. Even the rounding error vis-a-vis the .15 is silly and irrelevant! If the sensor is +- 1 degree, you can't even measure the rounding error, even if you HAVE two decimal places. With that degree of accuracy, you are no better off than 273 with no decimal places. Worrying about rounding error on .15 when the accuracy is in the units is exactly the kind of misinformed false precision that I worry about. You actually though that the .15 was significant enough to worry about round error when, in fact, it will be impossible to measure with the equipment available in the environment of discourse. > One might provide other numbers to specify accuracy and precision. Now... That I can agree with and it would make absolute sense. Especially if we were discussing lab grade or scientific grade measure equipment and measurements. In fact, that would be a requirement for any validity to be attached to measurements of that level of precision. But that's not what we are talking about here, is it? We're not talking about a lab grade instrumentation API here, are we? If we are, then everything changes. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel headers violate RFC2553
On 8 Jun 2001, Linus Torvalds wrote: > The basic issue is that the kernel will _refuse_ to follow the > "namespace of the day" rules of C89, C99, POSIX, BSD, SuS, GNU .. the > list goes on. The kernel headers are not meant to be used in user space, > and will not have the strict namespace rules that a lot of standards > spend so much time playing with. Add something like this to linux/config.h in 2.5? #if !defined(__KERNEL__) || !defined(__KERNEL_ME_HARDER__) #warning "Using kernel headers in userspace apps is unsupported." #warning "Don't come crying to us when it breaks." #endif -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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 Kernel2.2 is SMP versioned by default?
On 08 Jun 2001 07:58:48 -0700, jalaja devi wrote: > Hi, > Could anyone plz tell me whether the kernel - 2.2.14 > is SMP or NON-SMP by default? > To make it SMP versioned, Do I need to add some flags > in the kernel header files and re-compile to kernel? i actually think it may be SMP (for whatever odd reason). you need to configure and compile the kernel, anyhow. select from one of: make config (text) make menuconfig (curses) make xconfig (Tk) and make sure SMP is enabled, as well as support for the rest of your hardware and the features you want. then: make dep clean bzImage modules see the Kernel Compile HOWTO -- 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: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Henning P. Schmied writes: > Alan Cox <[EMAIL PROTECTED]> writes: >> So it comes down to the question of whether the module is linking >> (which is about dependancies and requirements) and what the legal >> scope is. Which is a matter for lawyers. > > And this would void DaveMs' argument, that only the "official in > Linus' kernel published interface is allowed for binary modules". This > would mean, that putting the posted, unofficial patch under GPL into > the kernel and then using this interface for a binary module is just > the same as using only the official ABI from a lawyers' point of > view! > > This would make DaveMs' position even less understandable, because > there would be no difference for a proprietary vendor but keeping the > patch out of the kernel makes life harder for people like the original > poster that want to test new (open sourced) protocols like SCTP. Yep. Consider a chunk of x86 instructions using a home-grown OS abstraction layer, and drivers that implement that layer for both Linux and any non-GPL operating system. The binary blob is obviously not derived from Linux, and may in fact run without modification in a BSD or Solaris/x86 kernel. There is in fact just such a layer. It might not currently have the features needed to implement TCP, but it could be extended as needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please test: workaround to help swapoff behaviour
On Thu, 7 Jun 2001, Bulent Abali wrote:
>
>
>
>
> >This is for the people who has been experiencing the lockups while running
> >swapoff.
> >
> >Please test. (against 2.4.6-pre1)
> >
> >
> >--- linux.orig/mm/swapfile.c Wed Jun 6 18:16:45 2001
> >+++ linux/mm/swapfile.c Thu Jun 7 16:06:11 2001
> >@@ -345,6 +345,8 @@
> > /*
> > * Find a swap page in use and read it in.
> > */
> >+if (current->need_resched)
> >+ schedule();
> > swap_device_lock(si);
> > for (i = 1; i < si->max ; i++) {
> > if (si->swap_map[i] > 0 && si->swap_map[i] != SWAP_MAP_BAD)
> {
>
>
> I tested your patch against 2.4.5. It works. No more lockups. Without
> the
> patch it took 14 minutes 51 seconds to complete swapoff (this is to recover
> 1.5GB of
> swap space). During this time the system was frozen. No keyboard, no
> screen, etc. Practically locked-up.
>
> With the patch there are no more lockups. Swapoff kept running in the
> background.
> This is a winner.
>
> But here is the caveat: swapoff keeps burning 100% of the cycles until it
> completes.
> This is not going to be a big deal during shutdowns. Only when you enter
> swapoff from
> the command line it is going to be a problem.
>
> I looked at try_to_unuse in swapfile.c. I believe that the algorithm is
> broken.
> For each and every swap entry it is walking the entire process list
> (for_each_task(p)). It is also grabbing a whole bunch of locks
> for each swap entry. It might be worthwhile processing swap entries in
> batches instead of one entry at a time.
>
> In any case, I think having this patch is worthwhile as a quick and dirty
> remedy.
Bulent,
Could you please check if 2.4.6-pre2+the schedule patch has better
swapoff behaviour for you?
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/
DoS using tmpfs
Hello! It appears that a system with tmpfs mounted with the default (!!!) parameters can be used by ordinary users to make the system non-functional. Let me tell you the whole story. I don't know what is wrong here and what is not, but the end result is a security hole. The kernel version is 2.4.5-ac9. It's compiled with gcc from RedHat 7.1. The processor is Pentium III 550 MHz. Alt-Sysrq is enabled - we'll need it later. # mount /dev/ide/host2/bus0/target0/lun0/part4 on / type reiserfs (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) devfs on /dev type devfs (rw) none on /tmp type tmpfs (rw,mode=1777) none on /dev/shm type shm (rw) Note the "mode=1777" is not required - it's the default. I put is here just in case if the default changes. # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/ide/host2/bus0/target0/lun0/part4 5124540 3510036 1614504 69% / none277728 0277728 0% /tmp none277728 0277728 0% /dev/shm # free total used free sharedbuffers cached Mem:255948 97520 158428 0 14880 68172 -/+ buffers/cache: 14468 241480 Swap: 104380 0 104380 Note that my swap file is just 100M compared to 256M memory, but I never run anything bigger than Mozilla, so even 350M virtual memory is more than enough for me. Now I log in on tty2 as user. $ dd if=/dev/zero of=/tmp/foo If a few seconds I'm pressing Ctrl-C - it doesn't work. Alt-F1 works. I type df as root, press enter and it hangs. I'm hitting Ctrl-C in vain. Now I press Alt-F2 - it works. I'm trying the last resort - Alt-Sysrq-K. It works, the login appears. Now let's see what we have. # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/ide/host2/bus0/target0/lun0/part4 5124540 3510044 1614496 69% / none177124159968 17156 91% /tmp none 17156 0 17156 0% /dev/shm There is still free space in /tmp, but ... # free total used free sharedbuffers cached Mem:255948 253680 2268 55588 14880 171280 -/+ buffers/cache: 67520 188428 Swap: 104380 104380 0 ... the swap is exhausted, and so it the memory. Now let's remove /tmp/foo and see what happens. # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/ide/host2/bus0/target0/lun0/part4 5124540 3510044 1614496 69% / none 72340 0 72340 0% /tmp none 72340 0 72340 0% /dev/shm The free space didn't rebound to it's initial value, and here's why: # free total used free sharedbuffers cached Mem:255948 198492 57456 0 14880 171284 -/+ buffers/cache: 12328 243620 Swap: 104380 104380 0 The memory is freed, but the swap is still full! Running "swapoff -a" followed by "swapon -a" brings the system to the sane state. Now let me stress some points where the kernel is _possibly_ at fault. 1) tmpfs, as opposed to ramfs doesn't limit the usage by default. It's not a good default for a filesystem designed for temporary files. 2) Not delivering SIGINT to processes is probably not the best behavior if the memory if low. However, one could argue that some processes would use even more resources if they get control with SIGINT. 3) All swap in the system was exhausted and yet tmpfs didn't return ENOSPC to "dd". 4) The swap wasn't freed. Yes, I know, it's not a new problem. I don't really know much about OS design and VM in particular, but I was bitten by this behavior, so I desided to report it. If you cannot find anything useful in this message, I'm sorry for your time. "IMHO" applies to all statements made in this message. -- Regards, Pavel Roskin - 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/
oops question
does the attached oops makes sense or it is just messed up?
AFAICT the ksymoops is using right System.map, yet the stack
trace does not seem to follow logical order. it is from 2.4.6-pre1
for that matter is "defensive" programming the rule in kernel?
this ops could be avoided if the net/ipv4/ipmr.c:ipmr_new_tunel()
function was changed to check whether 'v' is null and if it is
true then just return.
I did not submit this patch though since I couldn't figure how
in the the first place code ended up there.
--
Adam
http://www.eax.com The Supreme Headquarters of the 32 bit registers
ksymoops 2.4.0 on i686 2.4.6-pre1-packet. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.6-pre1-packet/ (default)
-m /boot/System.map-2.4.6-pre1-packet (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol do_softirq_R__ver_do_softirq not found in
System.map. Ignoring ksyms_base entry
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01b4a50,
System.map says c0157cf0. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
tasklet_hi_schedule_R__ver_tasklet_hi_schedule not found in System.map. Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol tasklet_schedule_R__ver_tasklet_schedule not
found in System.map. Ignoring ksyms_base entry
cpu: 0, clocks: 1002388, slice: 334129
cpu: 1, clocks: 1002388, slice: 334129
Unable to handle kernel NULL pointer dereference at virtual address 000c
c01fbd2d
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: ebx: ecx: edx: 0100
esi: 06c71bbf edi: c71bbe4c ebp: c71bbe18 esp: c71bbe18
ds: 0018 es: 0018 ss: 0018
Process gaim (pid: 19160, stackpage=c71bb000)
Stack:
009e c5e8781e c6ed0540
c6a37140 0010 cc874144 0001
Call Trace: [] [] [] [] []
[] []
[] [] [] []
Code: 8b 43 0c 89 44 24 30 8b 43 08 c6 44 24 20 45 c6 44 24 29 04
>>EIP; c01fbd2d<=
Trace; cc874144 <[tulip]tulip_interrupt+5d4/780>
Trace; c01bb281
Trace; c0130584 <__alloc_pages+74/270>
Trace; c01d8ebe
Trace; c01414d9
Trace; c01ba6af
Trace; c014743d
Trace; c01bb2fd
Trace; c01bb994
Trace; c0106fff
Trace; c010002b
Code; c01fbd2d
<_EIP>:
Code; c01fbd2d<=
0: 8b 43 0c mov0xc(%ebx),%eax <=
Code; c01fbd30
3: 89 44 24 30 mov%eax,0x30(%esp,1)
Code; c01fbd34
7: 8b 43 08 mov0x8(%ebx),%eax
Code; c01fbd37
a: c6 44 24 20 45movb $0x45,0x20(%esp,1)
Code; c01fbd3c
f: c6 44 24 29 04movb $0x4,0x29(%esp,1)
6 warnings issued. Results may not be reliable.
RE: mkinitrd errors...
Missed the command line in earlier mail ashokr -Original Message- From: Raj, Ashok [mailto:[EMAIL PROTECTED]] Sent: Friday, June 08, 2001 1:08 PM To: Linux-Kernel (E-mail) Subject: mkinitrd errors... Hello. I have a need to have some drivers pre-loaded before the scsi adapter driver is loaded. I followed the usage and i got some errors which iam attaching below in this mail. If someone can give me a way to get this to work that would be awesome!!! please reply back to me.. 1. Is the size of the ramdisk limited? if so to what, and how can we increase the size of the ramdisk created? # mkinitrd --preload 82808XA xx.img 2.4.2-2 tar: ./lib/82808XA.o: Wrote only 3584 of 10240 bytes tar: Skipping to next header tar: ./lib/sd_mod.o: Wrote only 0 of 10240 bytes tar: Skipping to next header tar: ./bin/nash: Wrote only 0 of 10240 bytes tar: Skipping to next header tar: ./sbin/: Cannot mkdir: No space left on device tar: ./sbin/bin: Cannot open: No such file or directory tar: ./sbin/modprobe: Cannot create symlink to `/bin/nash': No such file or dire ctory tar: ./etc/: Cannot mkdir: No space left on device tar: ./dev/: Cannot mkdir: No space left on device tar: ./dev/console: Cannot mknod: No such file or directory tar: ./dev/null: Cannot mknod: No such file or directory tar: ./dev/ram: Cannot mknod: No such file or directory tar: ./dev/systty: Cannot mknod: No such file or directory tar: ./dev/tty1: Cannot mknod: No such file or directory tar: ./dev/tty2: Cannot mknod: No such file or directory tar: ./dev/tty3: Cannot mknod: No such file or directory tar: ./dev/tty4: Cannot mknod: No such file or directory tar: ./loopfs/: Cannot mkdir: No space left on device tar: ./linuxrc: Wrote only 0 of 10240 bytes tar: Error exit delayed from previous errors - 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: Linux kernel headers violate RFC2553
In article <[EMAIL PROTECTED]>, Felix von Leitner <[EMAIL PROTECTED]> wrote: >Thus spake David S. Miller ([EMAIL PROTECTED]): >> > glibc works around this, but the diet libc uses the kernel headers and >> > thus exports the wrong API to user land. >> Don't user kernel headers for userspace. > >What choice do I have? >Duplicate everything and then be out of sync when the specs change? Yes. Even more preferably - write user-space headers that have _only_ the minimum amount of code in them. The kernel headers have a lot of cruft that is kernel-only, and that means that if you compile user space using them, your compiles will be slower than they should be. The basic issue is that the kernel will _refuse_ to follow the "namespace of the day" rules of C89, C99, POSIX, BSD, SuS, GNU .. the list goes on. The kernel headers are not meant to be used in user space, and will not have the strict namespace rules that a lot of standards spend so much time playing with. There aren't that many things that are actually useful in the kernel headers anyway. Most of them (like the IPv6 stuff) are really specified in other places in the first place. 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, John Stoffel wrote: > > Marcelo> Now the stock kernel gives us crappy interactivity compared > Marcelo> to my patch. (Note: my patch still does not gives me the > Marcelo> interactivity I want under high VM loads, but I hope to get > Marcelo> there soon). > > This raises the important question, how can we objectively measure > interactive response in the kernel and relate it to the user's > perceived interactive response? If we could come up with some sort of > testing system that would show us this, it would help alot, since we > could just have people run tests in a more automatic and repeatable > manner. > > And I think it would also help us automatically tune the Kernel, since > it would have a knowledge of it's own performance. > > There is the problem in terms of some people want pure interactive > performance, while others are looking for throughput over all else, > but those are both extremes of the spectrum. Though I suspect > raw throughput is the less wanted (in terms of numbers of systems) > than keeping interactive response good during VM pressure. And this raises a very very important point: raw throughtput wins enterprise-like benchmarks, and the enterprise people are the ones who pay most of hackers here. (including me and Rik) We have to be careful about that. > I have zero knowledge of how we could do this, but giving the kernel > some counters, even if only for use during debugging runs, which would > give us some objective feedback on performance would be a big win. > > Having people just send in reports of "I ran X,Y,Z and it was slow" > doesn't help us, since it's so hard to re-create their environment so > you can run tests against it. Lets wait for some test system to be set up (eg the OSDL thing). Once thats done, I'm sure we will find out some way of doing it. Well, good weekend for you too. - 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: temperature standard - global config option?
L. K. writes: > On Fri, 8 Jun 2001, Albert D. Cahalan wrote: >> The bits are free; the API is hard to change. >> Sensors might get better, at least on high-end systems. >> Rounding gives a constant 0.15 degree error. >> Only the truly stupid would assume accuracy from decimal places. >> Again, the bits are free; the API is hard to change. >> >> One might provide other numbers to specify accuracy and precision. > > I really do not belive that for a CPU or a motherboard +- 1 degree would > make any difference. > > If a CPU runs fine at, say, 37 degrees C, I do not belive it will have any > problems running at 38 or 36 degrees. I support the ideea of having very > good sensors for temperature monitoring, but CPU and motherboard > temperature do not depend on the rise of the temperature of 1 degree, but > when the temperature rises 10 or more degrees. I hope you understand what > I want to say. Of course I understand. Motorola offers 4-degree resolution, with a random offset of up to 12 degrees. (calibration is possible) You seem to need another reminder that THE BITS ARE FREE. Why would you even consider trying to squeeze out a few bits? You can't be absolutely sure that they will never be useful. - 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/
[CHECKER] 15 probable security holes in 2.4.5-ac8
Hi All,
here are 15 probable security holes where user input (e.g. data from
copy_from_user, get_user, etc) is:
1. passed as a length argument to copy_*user (or passed to a
function that does so), OR
2. is used as an array index.
The main difference between this and past checkers is that we do
"inherited" tainting: if a structure is copied in from user space,
we recursively mark all of it's fields as tainted as well. I'm still
fussing with the extension, so hopefully find a bunch more errors after
this batch.
You can look at this checker as essentially tracking whether the
information from an untrusted source (e.g., from copy_from_user) can reach
a trusting sink (e.g., an array index). The main limiting factor on its
effectiveness is that we have a very incomplete notion of trusting sinks.
If anyone has suggestions for other general places where it's dangerous
to consume bad data, please send me an email.
Here's the location summary:
# Total = 15
# BUGs | File Name
3 | drivers/char/drm/mga_state.c
2 | drivers/scsi/megaraid.c
2 | drivers/char/drm/i810_dma.c
2 | drivers/char/raw.c
1 | drivers/usb/usbvideo.c
1 | drivers/usb/se401.c
1 | drivers/net/hamradio/scc.c
1 | drivers/char/moxa.c
1 | drivers/media/video/zr36120.c
1 | drivers/media/video/zr36067.c
Dawson
-
[BUG] dataxferlen is never checked.
/u2/engler/mc/oses/linux/2.4.5-ac8/drivers/scsi/megaraid.c:4108:megadev_ioctl:
ERROR:RANGE:3825:4108: Using user length "dataxferlen" as argument to "copy_from_user"
[type=LOCAL] [state = any_check] set by 'copy_from_user':3825 [val=28300]
ret = verify_area (VERIFY_WRITE, (char *) arg, sizeof (struct uioctl_t));
if (ret)
return ret;
Start --->
if(copy_from_user (&ioc, (char *) arg, sizeof (struct uioctl_t)))
... DELETED 277 lines ...
if (inlen) {
if (ioc.mbox[0] == MEGA_MBOXCMD_PASSTHRU) {
/* copyin the user data */
copy_from_user (kphysaddr,
uaddr,
Error --->
ioc.pthru.dataxferlen);
} else {
copy_from_user (kphysaddr,
uaddr, inlen);
-
[BUG] symetry.
/u2/engler/mc/oses/linux/2.4.5-ac8/drivers/scsi/megaraid.c:4167:megadev_ioctl:
ERROR:RANGE:3825:4167: Using user length "dataxferlen" as argument to "copy_to_user"
[type=LOCAL] [state = any_check] set by 'copy_from_user':3825 [val=34200]
ret = verify_area (VERIFY_WRITE, (char *) arg, sizeof (struct uioctl_t));
if (ret)
return ret;
Start --->
if(copy_from_user (&ioc, (char *) arg, sizeof (struct uioctl_t)))
... DELETED 336 lines ...
down (&mimd_ioctl_sem);
if (!scsicmd->result && outlen) {
if (ioc.mbox[0] == MEGA_MBOXCMD_PASSTHRU) {
copy_to_user (uaddr,
Error --->
kphysaddr, ioc.pthru.dataxferlen);
} else {
copy_to_user (uaddr, kphysaddr, outlen);
}
-
[BUG]
static int moxaload320b(int cardno, unsigned char * tmp, int len)
{
unsigned long baseAddr;
int i;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
/u2/engler/mc/oses/linux/2.4.5-ac8/drivers/char/moxa.c:1730:MoxaDriverIoctl:
ERROR:RANGE:1728:1730: Using user length "len" as argument to "moxaload320b"
[type=GLOBAL] [state = tainted] set by 'copy_from_user':1728 [val=200]
case MOXA_FIND_BOARD:
if(copy_from_user(&dltmp, (void *)arg, sizeof(struct dl_str)))
return -EFAULT;
return moxafindcard(dltmp.cardno);
case MOXA_LOAD_C320B:
Start --->
if(copy_from_user(&dltmp, (void *)arg, sizeof(struct dl_str)))
return -EFAULT;
Error --->
moxaload320b(dltmp.cardno, dltmp.buf, dltmp.len);
return (0);
case MOXA_LOAD_CODE:
if(copy_from_user(&dltmp, (void *)arg, sizeof(struct dl_str)))
-
[BUG] d.idx is an int: < 0 = bad news.
/u2/engler/mc/oses/linux/2.4.5-ac8/drivers/char/drm/i810_dma.c:1413:i810_copybuf:
ERROR:RANGE:1409:1413: Using user length "idx"as an array index for "buflist" set by
'copy_from_user':1409 [val=400]
RE: temperature standard - global config option?
> From: L. K. [mailto:[EMAIL PROTECTED]] > I really do not belive that for a CPU or a motherboard +- 1 > degree would make any difference. You haven't pushed your system, or run it in a hostile environment then. There are many places where systems are run right up to the edge of thermal breakdown, and it's a firm requirement to know exactly what that edge is. > If a CPU runs fine at, say, 37 degrees C, I do not belive it > will have any problems running at 38 or 36 degrees. I support > the ideea of having very good sensors for temperature > monitoring, but CPU and motherboard temperature do not depend > on the rise of the temperature of 1 degree, but when the > temperature rises 10 or more degrees. I hope you understand > what I want to say. I have a CPU that runs great up to 43C, and shuts down hard at 44C so I obviously want to know how close I am to that. I don't want rounding errors to get in the way, and I don't want changes between kernel revs to affect it either. If we've got the bitspace, keep the counters as granular as possible within the useable range that we're designing for. counter = .01 * degrees kelvin - 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: temperature standard - global config option?
Hi, > Only the truly stupid would assume accuracy from decimal places. Well then, tell all the teachers in this world that they're stupid, and tell everyone who learnt from them as well. I'm in high school (gd. 11, junior) and my physics teacher is always screaming at us for putting too many decimal places or having them inconsistent. There are certain situations where adding a ±1 is too cumbersome and / or clumsy, so you can specify the accuracy using just decimal places. For example, 5.00 would mean pretty much spot on 5 (anywhere from 4.995 to 5.00499), wheras 5 could mean anywhere from 4.5 to 5.499. Please, let's quit this dumb argument. We all know that thermistors and other types of cheap temperature gauges are very inaccurate, and I don't think expensive thermocouples will make it into computer sensors very soon. Plus, who the hell could care whether their chip is at 45.4 or 45.5 degrees? Does it really matter? A difference of 0.1 will not decide whether your chip will fry. Just my 2 eurocents. -- Chris Boot [EMAIL PROTECTED] DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and millions of others are by far the most popular, with about 70 million machines in use worldwide. Macintosh fans, on the other hand, may note that cockroaches are far more numerous than humans, and that numbers alone do not denote a higher life form. New York Times, November 26, 1991 - 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.5-ac10
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac10 o Fix xircom cardbus filter setup (Ion Badulescu) o Dave Jones has moved(Dave Jones) o Further Configure.help cleanup (Eric Raymond) o Switch usb serial driver locking(Greg Kroah-Hartmann) o Update IRDA Irnet protocol code (Jean Tourrilhes) o Update ide-tape and osst drivers(Willem Riede) o Add ethtool support to ne2k-pci (Jeff Garzik) o Misc small network driver tweaks/cleanup(Jeff Garzik) o Module description strings for net drivers (Jeff Garzik) o Fix thread/unload race in reiserfs (Nikita Danilov) o Fix a race in reiserfs_writepage(Chris Mason) o Add prolific 2203 USB serial support(Greg Kroah-Hartmann) o Update isdn maintainers (Kai Germaschewski) o Add another USS720 device entry (Steve Tell) o Reap dead swap cache pages (Marcelo Tosatti) o Fix USB sign handling error (Jochen Pernsteiner) o Update input driver docs(Vojtech Pavlik) o Fix locking bug in hysdn(Kai Germaschewski) o Fix hid parsing bug with feature reports(Vojtech Pavlik) o Fix ataraid config.in bug (Jim Wright) 2.4.5-ac9 o Fix gameport link problems (Vojtech Pavlik) o Fix an oops in the sg driver(Tachino Nobuhiro) o Fix brlock indexing bug (Takanori Kawano) o Add parport_pc_unregister_port (Tim Waugh) o Configure.help updates (Eric Raymond) o Fix xircom_cb problems with some cisco kit (Ion Badulescu) o Fix tdfxfb cursor rendering bug (Franz Melchior) o Add driver for the sony vaio i/o controller (Stelian Pop, Junchi Morita, Takaya Kinjo, Andrew Tridgell) o Orinoco updates for symbol, intel, 3com cards (Jean Tourrihles) o Use list_del_init in uhci driver(Herbert Xu) o Fix a uhci SMP deadlock (Herbert Xu) o Allow faster freeing of reisefs metadata(Chris Mason) o Fix error path leaks in reiserfs(Chris Mason, Vladimir Saveliev) o Fix NFS problems triggered by 2.4.5 mmap change (Trond Myklebust) o Resynchronize with m68k tree(Jes Sorensen) o Add es1371 sound driver locking (Frank Davis) o Fix a small error in the trident locking(Frank Davis) 2.4.5-ac8 o Fix sign handling bug in random sysctl (me) | From Stanford tools o Add more idents to the NS558 driver (Vojtech Pavlik) o Fix oops on some HID descriptor sets(Vojtech Pavlik) o Fix reuse bug in UML net code + clean up(Jeff Dike) o ES1370 driver locking (Frank Davis) o Update init/main.c patch for umask (Andrew Tridgell) o Fix uml fault race, and looping fault on(Jeff Dike) protection error o Update devices.txt (H Peter Anvin) o Update the airo driver (fix pci pm oops.(Jeff Garzik) spinlock abuse, delete after kfree, unchecked copies) o Remove old UML umn driver (Jeff Dike) o Fix resource leaks and printk levels in isapnp (Mike Borrelli) o Add new procfs programming documentation(Erik Mouw) o Fix usb xconfig breakage(Andrzej Krzysztofowicz) o Replace accidentaly lost UP_APIC help (Mikael Pettersson) o Olypmic driver update (Mike Phillips) o Clean up LVM spelling, debug macros (Andreas Dilger) o Make various bits of LVM static (Andreas Dilger) o Make lvm_snapshot_use_rate its own function (Andreas Dilger) o Make lvm_do_lv_create loop the right amount o Fix lvm stamping on a semaphore causing an oops o Fix lvm hardware block size handling(Andrea Arcangeli) 2.4.5-ac7 o UML cleanups(Jeff Dike) o Trap invalid addresses in UML ethernet driver (Jeff Dike) o
Ext3 kernel RPMS (2.4.5 & 2.2.19)
Hi, Mostly for my own use, I prepared two kernel RPM's with Ext3 in them. They are totally basic: kernel + ext3 patch, config based on Red Hat i386-smp config files. They include an RPM for e2fsprogs based on Stephen's code. I am running them (very) happily. Versions: 2.2.19 + 0.0.7a 2.4.5 + 0.0.6 PLEASE USE THESE AT YOUR OWN RISK - THEY CONTAIN EXPERIMENTAL FILE SYSTEM CODE. The RPMS's can be found at: ftp://ftp.clusterfilesystem.com/pub/ext3 Have a good day! - Peter J. Braam - http://www.clusterfilesystem.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: temperature standard - global config option?
On Fri, 8 Jun 2001, Albert D. Cahalan wrote: > Michael H. Warfiel writes: > > > We don't have sensors that are accurate to 1/10 of a K and certainly not > > to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when > > the accuracy of the best sensor we are likely to see is no better than > > +- 1 K is just about as relevant as negative absolute temperatures. > ... > > Even if we had or could, anticiplate, sensors with a +- .01 K, > > the relevance of knowing the CPU temperature to that precision is > > lost on me. I see no sense in stuffing a field with meaningless > > bits just because the field will hold them. In fact, this "false precision" > > quickly leads to the false impression of accuracy. Based on several > > messages I have seen on this thread and in private E-Mail, there are a > > number of people who don't seem to grasp the fundamental difference > > between precision and accuracy and truely don't understand that adding > > meaningless precision like this adds nothing to the accuracy. > > > > I can see maybe making it precise to .1 K. But stuffing the bits > > in there to be precise to .01 K just because we have the bits and not > > because we have any realistic information to fill the bits in with, is > > just silly to me. Just as silly as allowing for negative numbers in an > > absolute temperature field. We have the bits to support it, but why? > > The bits are free; the API is hard to change. > Sensors might get better, at least on high-end systems. > Rounding gives a constant 0.15 degree error. > Only the truly stupid would assume accuracy from decimal places. > Again, the bits are free; the API is hard to change. > > One might provide other numbers to specify accuracy and precision. > I really do not belive that for a CPU or a motherboard +- 1 degree would make any difference. If a CPU runs fine at, say, 37 degrees C, I do not belive it will have any problems running at 38 or 36 degrees. I support the ideea of having very good sensors for temperature monitoring, but CPU and motherboard temperature do not depend on the rise of the temperature of 1 degree, but when the temperature rises 10 or more degrees. I hope you understand what I want to say. Regards, > - 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: temperature standard - global config option?
Michael H. Warfiel writes: > We don't have sensors that are accurate to 1/10 of a K and certainly not > to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when > the accuracy of the best sensor we are likely to see is no better than > +- 1 K is just about as relevant as negative absolute temperatures. ... > Even if we had or could, anticiplate, sensors with a +- .01 K, > the relevance of knowing the CPU temperature to that precision is > lost on me. I see no sense in stuffing a field with meaningless > bits just because the field will hold them. In fact, this "false precision" > quickly leads to the false impression of accuracy. Based on several > messages I have seen on this thread and in private E-Mail, there are a > number of people who don't seem to grasp the fundamental difference > between precision and accuracy and truely don't understand that adding > meaningless precision like this adds nothing to the accuracy. > > I can see maybe making it precise to .1 K. But stuffing the bits > in there to be precise to .01 K just because we have the bits and not > because we have any realistic information to fill the bits in with, is > just silly to me. Just as silly as allowing for negative numbers in an > absolute temperature field. We have the bits to support it, but why? The bits are free; the API is hard to change. Sensors might get better, at least on high-end systems. Rounding gives a constant 0.15 degree error. Only the truly stupid would assume accuracy from decimal places. Again, the bits are free; the API is hard to change. One might provide other numbers to specify accuracy and precision. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
Marcelo> Now the stock kernel gives us crappy interactivity compared Marcelo> to my patch. (Note: my patch still does not gives me the Marcelo> interactivity I want under high VM loads, but I hope to get Marcelo> there soon). This raises the important question, how can we objectively measure interactive response in the kernel and relate it to the user's perceived interactive response? If we could come up with some sort of testing system that would show us this, it would help alot, since we could just have people run tests in a more automatic and repeatable manner. And I think it would also help us automatically tune the Kernel, since it would have a knowledge of it's own performance. There is the problem in terms of some people want pure interactive performance, while others are looking for throughput over all else, but those are both extremes of the spectrum. Though I suspect raw throughput is the less wanted (in terms of numbers of systems) than keeping interactive response good during VM pressure. I have zero knowledge of how we could do this, but giving the kernel some counters, even if only for use during debugging runs, which would give us some objective feedback on performance would be a big win. Having people just send in reports of "I ran X,Y,Z and it was slow" doesn't help us, since it's so hard to re-create their environment so you can run tests against it. Anyway, enjoy the weekend all. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548 - 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] 32-bit dma memory zone
Followup to: <[EMAIL PROTECTED]> By author:[EMAIL PROTECTED] (Eric W. Biederman) In newsgroup: linux.dev.kernel > > The AMD760 which looks like it might walk on both the alpha, an x86 > side of the fence also has an iommu. Mostly it's used for AGP but > according to the docs it should be able to handle the other cases as > well. The only downside is that it only supports 4GB of ram... > > Anyway we shouldn't assume iommu's don't exist on x86. > On most chips the AGP GART isn't just limited to AGP; it's a full-fledged iommu. The main problem with it is that it is usually a rather limited space it provides. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: xircom_cb problems
On Fri, 8 Jun 2001, Tom Sightler wrote: > OK, I tried your patch, it did fix the problem where pump wouldn't > pull an IP address, but I'm still having the problem where my ping > times go nuts. I've attached an example, it's 100% repeatable on my > network at work. It was so bad I couldn't get any benchmark numbers. Just one more question: do you see the same bad ping times if you completely comment out the call to set_half_duplex? Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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: [driver] New life for Serial mice
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > Can't it make mouse jump forward and back when user suddenly stops? > > In theory - yes. It doesn't seem to be a problem in practice, though. > It'll happen when a user slows down the mouse pointer motion faster than > exponentially (base 2). I haven't been able to stop that fast. Put a big brick on your desktop and *ram* it with your mouse. :-) -- Mike Coleman, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - 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/
mkinitrd errors...
Hello. I have a need to have some drivers pre-loaded before the scsi adapter driver is loaded. I followed the usage and i got some errors which iam attaching below in this mail. If someone can give me a way to get this to work that would be awesome!!! please reply back to me.. 1. Is the size of the ramdisk limited? if so to what, and how can we increase the size of the ramdisk created? tar: ./lib/82808XA.o: Wrote only 3584 of 10240 bytes tar: Skipping to next header tar: ./lib/sd_mod.o: Wrote only 0 of 10240 bytes tar: Skipping to next header tar: ./bin/nash: Wrote only 0 of 10240 bytes tar: Skipping to next header tar: ./sbin/: Cannot mkdir: No space left on device tar: ./sbin/bin: Cannot open: No such file or directory tar: ./sbin/modprobe: Cannot create symlink to `/bin/nash': No such file or dire ctory tar: ./etc/: Cannot mkdir: No space left on device tar: ./dev/: Cannot mkdir: No space left on device tar: ./dev/console: Cannot mknod: No such file or directory tar: ./dev/null: Cannot mknod: No such file or directory tar: ./dev/ram: Cannot mknod: No such file or directory tar: ./dev/systty: Cannot mknod: No such file or directory tar: ./dev/tty1: Cannot mknod: No such file or directory tar: ./dev/tty2: Cannot mknod: No such file or directory tar: ./dev/tty3: Cannot mknod: No such file or directory tar: ./dev/tty4: Cannot mknod: No such file or directory tar: ./loopfs/: Cannot mkdir: No space left on device tar: ./linuxrc: Wrote only 0 of 10240 bytes tar: Error exit delayed from previous errors - 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/
alpha traps.c patch for improved oops output
This is a patch to arch/alpha/kernel/traps.c which changes its oops output
to be like other architectures: Output a trace, given in a series of hex
numbers, and then output the instructions surrounding the oops, in hex
numbers.
The disassemble() function and its associated data structures and helper
functions have been removed, since ksymoops and objdump do it better
anyway.
It applies to 2.4.5-ac[67] and 2.2.19 with a bit of fuzz.
Regards,
(posting from home since Compaq doesn't do ECN,)
Will Woods
Alpha Technology Solutions Group
Compaq Computer Corp.
--- linux/arch/alpha/kernel/traps.c Fri Jun 8 13:00:18 2001
+++ linux-2.4.5-ac7-ww/arch/alpha/kernel/traps.cFri Jun 8 12:57:12 2001
@@ -61,202 +61,6 @@
"a0", "a1", "a2", "a3", "a4", "a5", "t8", "t9",
"t10", "t11", "ra", "pv", "at", "gp", "sp", "zero"};
-static char * inst_name[] = {"call_pal", "", "", "", "", "", "", "",
- "lda", "ldah", "ldbu", "ldq_u", "ldwu", "stw", "stb", "stq_u",
- "ALU", "ALU", "ALU", "ALU", "SQRT", "FVAX", "FIEEE", "FLOAT",
- "MISC", "PAL19", "JMP", "PAL1B", "GRAPH", "PAL1D", "PAL1E", "PAL1F",
- "ldf", "ldg", "lds", "ldt", "stf", "stg", "sts", "stt",
- "ldl", "ldq", "ldl_l", "ldq_l", "stl", "stq", "stl_c", "stq_c",
- "br", "fbeq", "fblt", "fble", "bsr", "fbne", "fbge", "fbgt"
- "blbc", "beq", "blt", "ble", "blbs", "bne", "bge", "bgt"
-};
-
-static char * jump_name[] = {"jmp", "jsr", "ret", "jsr_coroutine"};
-
-typedef struct {int func; char * text;} alist;
-
-static alist inta_name[] = {{0, "addl"}, {2, "s4addl"}, {9, "subl"},
- {0xb, "s4subl"}, {0xf, "cmpbge"}, {0x12, "s8addl"}, {0x1b, "s8subl"},
- {0x1d, "cmpult"}, {0x20, "addq"}, {0x22, "s4addq"}, {0x29, "subq"},
- {0x2b, "s4subq"}, {0x2d, "cmpeq"}, {0x32, "s8addq"}, {0x3b, "s8subq"},
- {0x3d, "cmpule"}, {0x40, "addl/v"}, {0x49, "subl/v"}, {0x4d, "cmplt"},
- {0x60, "addq/v"}, {0x69, "subq/v"}, {0x6d, "cmple"}, {-1, 0}};
-
-static alist intl_name[] = {{0, "and"}, {8, "andnot"}, {0x14, "cmovlbs"},
- {0x16, "cmovlbc"}, {0x20, "or"}, {0x24, "cmoveq"}, {0x26, "cmovne"},
- {0x28, "ornot"}, {0x40, "xor"}, {0x44, "cmovlt"}, {0x46, "cmovge"},
- {0x48, "eqv"}, {0x61, "amask"}, {0x64, "cmovle"}, {0x66, "cmovgt"},
- {0x6c, "implver"}, {-1, 0}};
-
-static alist ints_name[] = {{2, "mskbl"}, {6, "extbl"}, {0xb, "insbl"},
- {0x12, "mskwl"}, {0x16, "extwl"}, {0x1b, "inswl"}, {0x22, "mskll"},
- {0x26, "extll"}, {0x2b, "insll"}, {0x30, "zap"}, {0x31, "zapnot"},
- {0x32, "mskql"}, {0x34, "srl"}, {0x36, "extql"}, {0x39, "sll"},
- {0x3b, "insql"}, {0x3c, "sra"}, {0x52, "mskwh"}, {0x57, "inswh"},
- {0x5a, "extwh"}, {0x62, "msklh"}, {0x67, "inslh"}, {0x6a, "extlh"},
- {0x72, "mskqh"}, {0x77, "insqh"}, {0x7a, "extqh"}, {-1, 0}};
-
-static alist intm_name[] = {{0, "mull"}, {0x20, "mulq"}, {0x30, "umulh"},
- {0x40, "mull/v"}, {0x60, "mulq/v"}, {-1, 0}};
-
-static alist * int_name[] = {inta_name, intl_name, ints_name, intm_name};
-
-static char *
-assoc(int fcode, alist * a)
-{
- while ((fcode != a->func) && (a->func != -1))
- ++a;
- return a->text;
-}
-
-static char *
-iname(unsigned int instr)
-{
- int opcode = instr >> 26;
- char * name = inst_name[opcode];
-
- switch (opcode) {
- default:
- break;
-
- case 0x10:
- case 0x11:
- case 0x12:
- case 0x13: {
- char * specific_name
- = assoc((instr >> 5) & 0x3f, int_name[opcode - 0x10]);
- if (specific_name)
- name = specific_name;
- break;
- }
-
- case 0x1a:
- name = jump_name[(instr >> 14) & 3];
- break;
- }
-
- return name;
-}
-
-static enum {NOT_INST, PAL, BRANCH, MEMORY, JUMP, OPERATE, FOPERATE, MISC}
-iformat(int opcode)
-{
- if (opcode >= 0x30)
- return BRANCH;
- if (opcode >= 0x20)
- return MEMORY;
- if (opcode == 0)
- return PAL;
- if (opcode < 8)
- return NOT_INST;
- if (opcode < 0x10)
- return MEMORY;
- if (opcode < 0x14)
- return OPERATE;
- if (opcode < 0x18)
- return FOPERATE;
- switch (opcode) {
- case 0x18:
- return MISC;
- case 0x1A:
- return JUMP;
- case 0x1C:
- return OPERATE;
- default:
- return NOT_INST;
- }
-}
-
-/*
- * The purpose here is to provide useful clues about a kernel crash, s
Re: Large ramdisk crashes system
On Thu, 7 Jun 2001, Marcelo Tosatti wrote: > On Thu, 7 Jun 2001, Paul Buder wrote: > > > I am trying to create a system which boots off of a cd and has no hard > > disks. So it needs ramdisks. But I haven't had much luck creating > > large ones. [ explanation of large ram disks crashing the system edited out for brevity] > > Can you get the (traced by ksymoops) backtrace of dd and kswapd > everything is locked? > > You can do that with sysrq. I copied the sysreq-t screen to paper and then typed it up and fed it to ksymoops. I get some errors since this kernel has module support turned off. I also get a message from ksymoops saying Warning (Oops_read): Code line not seen, dumping what data is available which I'm not sure of the meaning. So anyway, my oops file and the output from ksymoops follow. Hopefully I've done this right. If there is anything else I can provide let me know. kswapdR f7d5abfc 0 3 1(L-TLB) 4 2 Call Trace: c010fd6b>] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] ddR current 756 249 187(NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] ksymoops 2.4.1 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux/System.map (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Call Trace: c010fd6b>] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c010fd6b Trace; c010e526 Trace; c01247e4 Trace; c01247e4 Trace; c010e030 Trace; c01247e4 Trace; c010deab Trace; c01260aa Trace; c0126115 Trace; c0126299 Trace; c0126349 Trace; c01263dc Trace; c011153f Trace; c012727d Trace; c0127459 Trace; c01274d2 Trace; c012753b Trace; c01056d0 Trace; c015c184 Trace; c01964c1 Trace; c019ddab Trace; c019d804 Trace; c0194799 Trace; c01974f2 Trace; c011043e Trace; c012e4e5 <__wait_on_buffer+85/94> Trace; c0173b8b <__make_request+15b/6bc> Trace; c0173bbf <__make_request+18f/6bc> Trace; c0173bd9 <__make_request+1a9/6bc> Trace; c01964c1 Trace; c019ddab Trace; c019d804 Trace; c0197499 Trace; c01974f2 Trace; c020e742 Trace; c01e81b0 Trace; c020956b Trace; c01df693 Trace; c01d923d Trace; c01e8253 Trace; c01df143 Trace; c01e6da2 Trace; c01e81b0 Trace; c01e81a9 Trace; c01df143 Trace; c01e7a5f Trace; c01e819c Trace; c0201c1c Trace; c0201a2c Trace; c0201c30 Trace; c0202322 Trace; c017184c Trace; c016be8f Trace; c016b159 Trace; c01150ea Trace; c012f88a Trace; c017184c Trace; c01c5df0 Trace; c0167ff2 Trace; c016b464 Trace; c0112d86 Trace; c0112d86 Trace; f880 Trace; c01071d8 Trace; c01071d8 Trace; c0107207 Trace; c0111033 Trace; c01110ee Trace; c017307f Trace; c0171747 Trace; c01728bd Trace; c0172948 Trace; c01085f0 Trace; c01087d7 Trace; c0106f40 Trace; c021ce04 Trace; c0122880 Trace; c012d7aa Trace; c0106e67 1 warning and 1 error issued. Results may not be reliable. - 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: Large ramdisk crashes system
On Fri, 8 Jun 2001, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > the kernel is 2.4.5 with 'Simple RAM-based file system support' turned on. > > > I issued the following commands. > > > mkfs /dev/ram0 40 > > mount /dev/ram0 /mnt > > dd if=/dev/zero of=/mnt/junk bs=1024 count=50 > > Why turn on ramfs if you're not going to use it? > Actually I experimented with both ext2 and ramfs, getting similar results. I forgot to mention that in the post though. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, John Stoffel wrote: > > Mike> OK, riddle me this. If this test is a crummy test, just how is > Mike> it that I was able to warn Rik in advance that when 2.4.5 was > Mike> released, he should expect complaints? How did I _know_ that? > Mike> The answer is that I fiddle with Rik's code a lot, and I test > Mike> with this test because it tells me a lot. It may not tell you > Mike> anything, but it does me. > > I never said it was a crummy test, please do not read more into my > words than was written. What I was trying to get across is that just > one test (such as a compile of the kernel) isn't perfect at showing > where the problems are with the VM sub-system. > > Jonathan Morton has been using another large compile to also test the > sub-system, and it includes a compile which puts a large, single > process pressure on the VM. I consider this to be a more > representative test of how the VM deals with pressure. > > The kernel compile is an ok test of basic VM handling, but from what > I've been hearing on linux-kernel and linux-mm is that the VM goes to > crap when you have a mix of stuff running, and one (or more) processes > starts up or grows much larger and starts impacting the system > performance. > > I'm also not knocking your contributions to this discussion, so stop > being so touchy. I was trying to contribute and say (albeit poorly) > that a *mix* of tests is needed to test the VM. > > More importantly, a *repeatable* set of tests is what is needed to > test the VM and get consistent results from run to run, so you can see > how your changes are impacting performance. The kernel compile > doesn't really have any one process grow to a large fraction of > memory, so dropping in a compile which *does* is a good thing. I agree with you. Mike, I'm sure you have noticed that stock kernel gives much better results than mine or Jonathan's patch. Now the stock kernel gives us crappy interactivity compared to my patch. (Note: my patch still does not gives me the interactivity I want under high VM loads, but I hope to get there soon). BTW, we are talking with the OSDL (http://www.osdlab.org) guys about a possibility to setup a test system which would run a different variety of benchmarks to give us results of different kinds of workloads. If that ever happens, we'll probably get rid of most of this testing problems. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, Mike Galbraith wrote: > On Fri, 8 Jun 2001, Tobias Ringstrom wrote: > > On Fri, 8 Jun 2001, Mike Galbraith wrote: > > > I gave this a shot at my favorite vm beater test (make -j30 bzImage) > > > while testing some other stuff today. > > > > Could you please explain what is good about this test? I understand that > > it will stress the VM, but will it do so in a realistic and relevant way? > > Can you explain what is bad about this test? ;) It spins the same VM wheels I think a load of ~30 is quit uncommon, and therefor it is unclear to me that it would be a test that would be repesentative of most normal loads. > as any other load does. What's the difference if I have a bunch of httpd > allocating or a bunch of cc1/as/ld? This load has a modest cachable data > set and is compute bound.. and above all gives very repeatable results. Not a big difference. The difference I was thinking abount is the difference between spawning lots of processes allocating, using and freeing lots of memory, compared to a case where you have a few processes touching a lot of already allocated pages in some pattern. I was wondering whether optimizing for your case would be good or bad for the other case. I know, I know, I should do more testing myself. And I should probably not ask you, since you really really like your test, and you will probably just say yes... ;-) At home, I'm running a couple of computers. One of them is a slow computer running Linux, serving mail, NFS, SMB, etc. I'm usually logged in on a couple of virtual consoles. On this machine, I do not mind if all shells, daemons and other idle processes are beeing swapped out in favor of disk cache for the NFS and SMB serving. In fact, that is a very good thing, and I want it that way. Another maching is my desktop machine. When using this maching, I really hate when my emacsen, browsers, xterms, etc are swapped out just to give me some stupid disk cache for my xmms or compilations. I do not care if a kernel compile is a little slower as long as my applications are snappy. How could Linux predict this? It is a matter of taste, IMHO. > I use it to watch reaction to surge. I watch for the vm to build to a > solid maximum throughput without thrashing. That's the portion of VM > that I'm interested in, so that's what I test. Besides :) I simply don't > have the hardware to try to simulate hairy chested server loads. There > are lots of folks with hairy chested boxes.. they should test that stuff. Agreed. More testing is needed. Now if we would have those knobs and wheels to turn, we could perhaps also tune our systems to behave as we like them, and submit that as well. Right now you need to be a kernel hacker, and see through all the magic with shm, mmap, a bunch of caches, page lists, etc. I'd give a lot for a nice picture (or state diagram) showing the lifetime of a page, but I have not found such a picture anywhere. Besides, the VM seems to change every new release anyway. > I've been repeating ~this test since 2.0 times, and have noticed a 1:1 > relationship. When I notice that my box is ~happy doing this load test, > I also notice very few VM gripes hitting the list. Ok, but as you say, we need more tests. > > Isn't the interesting case when you have a number of processes using lots > > of memory, but only a part of all that memory is beeing actively used, and > > that memory fits in RAM. In that case, the VM should make sure that the > > not used memory is swapped out. In RAM you should have the used memory, > > but also disk cache if there is any RAM left. Does the current VM handle > > this case fine yet? IMHO, this is the case most people care about. It is > > definately the case I care about, at least. :-) > > The interesting case is _every_ case. Try seeing my particular test as > a simulation of a small classroom box with 30 students compiling their > assignments and it'll suddenly become quite realistic. You'll notice > by the numbers I post that I was very careful to not overload the box in > a rediculous manner when selecting the total size of the job.. it's just > a heavily loaded box. This test does not overload my IO resources, so > it tests the VM's ability to choose and move the right stuff at the right > time to get the job done with a minimum of additional overhead. I did not understand those numbers when I saw them the first time. Now, I must say that your test does not look as silly as it did before. > The current VM handles things generally well imho, but has problems > regulating itself under load. My test load hits the VM right in it's > weakest point (not _that_ weak, but..) by starting at zero and building > rapidly to max.. and keeping it _right there_. > > > I'm not saying that it's a completely uninteresting case when your active > > memory is bigger than you RAM of course, but perhaps there should be other > > algorithms handling that case, such as putting some of the swa
Re: temperature standard - global config option?
On 06.08 Michael H. Warfield wrote: > > No, we are not talking lab instrumentation here. We are talking > about CPU monitoring. Lab instrumentation is a whole different issue > with things like the IEEE bus and such. Lab instrumentation would require > it's own drivers and interface. > Sorry, I thought you were talking about general temperature handling in kernel, both for LM78, ACPI or any driver that managed that kind of data. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 - 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: temperature standard - global config option?
On Fri, Jun 08, 2001 at 08:43:06PM +0200, J . A . Magallon wrote: > On 06.08 Michael H. Warfield wrote: > > Actually, the REAL point I was TRYING to make (and doing a really > > shabby job of it) is that some of this needs a little dose of reality. > > We don't have sensors that are accurate to 1/10 of a K and certainly not > > to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when > > the accuracy of the best sensor we are likely to see is no better than > > +- 1 K is just about as relevant as negative absolute temperatures. > Lets see, somebody can develop lab equipment (dont think on PTRs or > thermistors in common world) that givee 10e-3 precission, and you are just > making linux not suitable to control that hardware. Think open. > What is the real difference between managing temperatures with a short > or a long ?. Is it really needed to fit it in a short ??!!! > I would use an unsigned long with fixed point and all done. No, we are not talking lab instrumentation here. We are talking about CPU monitoring. Lab instrumentation is a whole different issue with things like the IEEE bus and such. Lab instrumentation would require it's own drivers and interface. > -- > J.A. Magallon # Let the source be with you... > mailto:[EMAIL PROTECTED] > Linux Mandrake release 8.1 (Cooker) for i586 > Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - 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: temperature standard - global config option?
On 06.08 Michael H. Warfield wrote: > > Actually, the REAL point I was TRYING to make (and doing a really > shabby job of it) is that some of this needs a little dose of reality. > We don't have sensors that are accurate to 1/10 of a K and certainly not > to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when > the accuracy of the best sensor we are likely to see is no better than > +- 1 K is just about as relevant as negative absolute temperatures. Lets see, somebody can develop lab equipment (dont think on PTRs or thermistors in common world) that givee 10e-3 precission, and you are just making linux not suitable to control that hardware. Think open. What is the real difference between managing temperatures with a short or a long ?. Is it really needed to fit it in a short ??!!! I would use an unsigned long with fixed point and all done. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 - 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/
diff for ipv6 RFC compatibility
I have been told that I should send a diff rather than complain and expect others to make a diff. Oops ,) So attached is a diff. Oh boy oh boy will I now become part of the Linux Changelog? ;) Felix --- linux/include/linux/in6.h Sat May 19 02:45:08 2001 +++ linux.fefe/include/linux/in6.h Fri Jun 8 20:37:13 2001 @@ -53,7 +53,7 @@ struct in6_addr ipv6mr_multiaddr; /* local IPv6 address of interface */ - int ipv6mr_ifindex; + int ipv6mr_interface; }; struct in6_flowlabel_req --- linux/net/ipv6/ipv6_sockglue.c Mon Mar 26 04:14:25 2001 +++ linux.fefe/net/ipv6/ipv6_sockglue.c Fri Jun 8 20:37:01 2001 @@ -346,9 +346,9 @@ break; if (optname == IPV6_ADD_MEMBERSHIP) - retv = ipv6_sock_mc_join(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_multiaddr); + retv = ipv6_sock_mc_join(sk, mreq.ipv6mr_interface, +&mreq.ipv6mr_multiaddr); else - retv = ipv6_sock_mc_drop(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_multiaddr); + retv = ipv6_sock_mc_drop(sk, mreq.ipv6mr_interface, +&mreq.ipv6mr_multiaddr); break; } case IPV6_ROUTER_ALERT:
Re: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, John Stoffel wrote: > Mike> OK, riddle me this. If this test is a crummy test, just how is > Mike> it that I was able to warn Rik in advance that when 2.4.5 was > Mike> released, he should expect complaints? How did I _know_ that? > Mike> The answer is that I fiddle with Rik's code a lot, and I test > Mike> with this test because it tells me a lot. It may not tell you > Mike> anything, but it does me. > > I never said it was a crummy test, please do not read more into my > words than was written. What I was trying to get across is that just > one test (such as a compile of the kernel) isn't perfect at showing > where the problems are with the VM sub-system. Hmm... Tobias> Could you please explain what is good about this test? I Tobias> understand that it will stress the VM, but will it do so in a Tobias> realistic and relevant way? I agree, this isn't really a good test case. I'd rather see what happens when you fire up a gimp session to edit an image which is *almost* the size of RAM, or even just 50% the size of ram. Then how does that affect your other processes that are running at the same time? ...but anyway, yes it just one test from any number of possibles. > Jonathan Morton has been using another large compile to also test the > sub-system, and it includes a compile which puts a large, single > process pressure on the VM. I consider this to be a more > representative test of how the VM deals with pressure. What does 'more representative' mean given that the VM must react to every situation it runs into? > The kernel compile is an ok test of basic VM handling, but from what Now we're communicating. I never said it was more than that ;-) > I've been hearing on linux-kernel and linux-mm is that the VM goes to > crap when you have a mix of stuff running, and one (or more) processes > starts up or grows much larger and starts impacting the system > performance. > > I'm also not knocking your contributions to this discussion, so stop > being so touchy. I was trying to contribute and say (albeit poorly) > that a *mix* of tests is needed to test the VM. Yes, more people need to test. I don't need to do all of those other tests (no have right toys), more people need to do repeatable tests. > More importantly, a *repeatable* set of tests is what is needed to > test the VM and get consistent results from run to run, so you can see > how your changes are impacting performance. The kernel compile > doesn't really have any one process grow to a large fraction of > memory, so dropping in a compile which *does* is a good thing. I know I'm only watching basic functionality. I'm watching basic functionality with one very consistant test run very consistantly. -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/
Re: [driver] New life for Serial mice
sorry I'm late, could you tell me where this driver/patch is? also, my problem with USB mice on slow machines is that it takes up too much CPU, and you get a jumpy mouse if your box is doing a lot of work (like a heavy nfs server, say). Would this driver do the same to that box? On Fri, Jun 08, 2001 at 06:15:21PM +0200, Vojtech Pavlik wrote: > On Wed, Jun 06, 2001 at 11:21:34PM +, Pavel Machek wrote: > > > > If you still have your 3-button MouseSystems (or any other serial) mouse > > > somewhere in your driver, forgotten becase of the incredibly slow update > > > rate causing so much jumping of the pointer on the screen that it is > > > unusable, you may want to pull it out and give it a try. > > > > > > Or if you're still using it with some old 486 computer, this driver is > > > for you. > > > > > > What it does is that it enhances the update rate from 24 (with current > > > GPM and X drivers) to 96. This is almost what the best USB mice do. > > > > What's the "prediction" stuff? Does it mean you are guessing some values > > by interpolation? > > Extrapolation, yes. > > > [If so, what kind of update rate would it do on USB?] > > It wouldn't make any difference - on USB you always get whole packets, > while over serial port the data is processed byte by byte and thus we > know a little of the information before the whole packet arrives. > > -- > Vojtech Pavlik > 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/ > -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Hear about... the nymphomaniac teenager popularly known as Little Often Annie? PGP signature
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 07:33:14PM +0200, Chris Boot wrote: > Hi, > > Then you must have blown your quantum finals. Royally. ESPECIALLY > > after that statement about "temperature is nothing but the movement of > > pieces of materie". Not even close, once you get into the quant. > > > > Mathematically and quantum mechanically, negative absolute > > temperatures do exist. In quantum mechanics, temperature is expressed as > > probability populations in various quantum states. > Excuse me, but I don't think that we can get computer temperature sensors as > we know them to measure temperatures of matter in quantum states. Even if, > one day, we built a usable quantum computer which might need temperature > measurements, I doubt that the Linux kernel would run on it without being > totally rewritten. > Anyhow, I like the discussion. I love anything to do with quantum physics! Actually, the REAL point I was TRYING to make (and doing a really shabby job of it) is that some of this needs a little dose of reality. We don't have sensors that are accurate to 1/10 of a K and certainly not to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when the accuracy of the best sensor we are likely to see is no better than +- 1 K is just about as relevant as negative absolute temperatures. (Ok... Ok... Actually it did annoy me, as someone who majored in physics, to see someone else write that because physics was "a major course" for them that they could say definitively that there was no such thing and that temperature was only the movement of materials. But it was a perfect opening to try an exercise in absurdity. It just seems to have flopped. My fault.) Trying to keep this relevant to the topic of the Linux kernel, I was trying to impress people with the absurdity. That's why I closed that message about the precision being just as silly. Unfortunately, I need to be a little more explicit about things like that since it seems that my forey into absurdity went right over several peoples heads. Again... My fault. Even if we had or could, anticiplate, sensors with a +- .01 K, the relevance of knowing the CPU temperature to that precision is lost on me. I see no sense in stuffing a field with meaningless bits just because the field will hold them. In fact, this "false precision" quickly leads to the false impression of accuracy. Based on several messages I have seen on this thread and in private E-Mail, there are a number of people who don't seem to grasp the fundamental difference between precision and accuracy and truely don't understand that adding meaningless precision like this adds nothing to the accuracy. I can see maybe making it precise to .1 K. But stuffing the bits in there to be precise to .01 K just because we have the bits and not because we have any realistic information to fill the bits in with, is just silly to me. Just as silly as allowing for negative numbers in an absolute temperature field. We have the bits to support it, but why? I do agree that it should be in K, though. > -- > Chris Boot > [EMAIL PROTECTED] > #define QUESTION ((2b) || (!2b)) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - 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: xircom_cb problems
Tom Sightler wrote: > > Whoops!! Sorry, forgot the attachment. > > > > [root@iso-2146-l1 ttsig]# ping 10.10.4.254 > PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. > 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec > 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec > 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec > 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec > 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec > 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec > 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec > 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec > This matches exactly with what I think is the problem; now to find the code that causes it... - 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 kernel headers violate RFC2553
glibc works around this, but the diet libc uses the kernel headers and
thus exports the wrong API to user land.
Here is what RFC2553 mandates:
struct ipv6_mreq {
struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
unsigned intipv6mr_interface; /* interface index */
};
...and here is what include/linux/in6.h declares:
struct ipv6_mreq {
/* IPv6 multicast address of group */
struct in6_addr ipv6mr_multiaddr;
/* local IPv6 address of interface */
int ipv6mr_ifindex;
};
Note the ipv6mr_ifindex instead of the correct ipv6mr_interface.
This wrong name is only used twice in net/ipv6/ipv6_sockglue.c, so it should be
trivial to fix.
Felix
-
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] USB Scanner devfs support
Hello!
I've made a patch for devfs support in USB scanners (against 2.4.5-ac9).
It can be found here:
http://www.red-bean.com/~proski/linux/scanner-devfs.diff
The patch is quite straightforward. The necessary changes have been taken
from usb-skeleton.c and verified against printer.c.
The scanner names will be /dev/usb/scanner0 ... /dev/usb/scanner15 in full
accordance will Documentation/devices.txt.
For some reason private structures of the driver are kept in scanner.h,
but it's only included by scanner.c, so please don't worry about changes
in the headers. Ideally, most (all?) stuff from scanner.h should be moved
into scanner.c, but I don't want to mix two patches.
The patch has been tested with ScanPrisa 640U.
The patch is below my signature as well as at
http://www.red-bean.com/~proski/linux/scanner-devfs.diff
--
Regards,
Pavel Roskin
-
--- linux.orig/drivers/usb/scanner.c
+++ linux/drivers/usb/scanner.c
@@ -263,6 +263,13 @@
*/
#include "scanner.h"
+/* the global usb devfs handle */
+extern devfs_handle_t usb_devfs_handle;
+
+/* Forward declarations */
+static struct
+file_operations usb_scanner_fops;
+
static void
irq_scanner(struct urb *urb)
@@ -363,6 +370,8 @@ close_scanner(struct inode * inode, stru
scn = p_scn_table[scn_minor];
+ devfs_unregister(scn->devfs);
+
scn->isopen = 0;
file->private_data = NULL;
@@ -594,6 +603,7 @@ probe_scanner(struct usb_device *dev, un
char valid_device = 0;
char have_bulk_in, have_bulk_out, have_intr;
+ char name[12];
if (vendor != -1 && product != -1) {
info("probe_scanner: User specified USB scanner -- Vendor:Product -
%x:%x", vendor, product);
@@ -813,6 +823,17 @@ probe_scanner(struct usb_device *dev, un
init_MUTEX(&(scn->gen_lock));
+ sprintf(name, "scanner%d", scn_minor);
+
+ /* Create with perms=664 */
+ scn->devfs = devfs_register(usb_devfs_handle, name,
+ DEVFS_FL_DEFAULT, USB_MAJOR,
+ SCN_BASE_MNR + scn_minor,
+ S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP |
+ S_IWGRP, &usb_scanner_fops, NULL);
+ if (scn->devfs == NULL)
+ err("scanner%d: device node registration failed", scn_minor);
+
return p_scn_table[scn_minor] = scn;
}
@@ -830,6 +851,8 @@ disconnect_scanner(struct usb_device *de
kfree(scn->ibuf);
kfree(scn->obuf);
+
+ devfs_unregister(scn->devfs);
dbg("disconnect_scanner: De-allocating minor:%d", scn->scn_minor);
p_scn_table[scn->scn_minor] = NULL;
--- linux.orig/drivers/usb/scanner.h
+++ linux/drivers/usb/scanner.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
// #define DEBUG
@@ -169,6 +170,7 @@
struct scn_usb_data {
struct usb_device *scn_dev;
+ devfs_handle_t devfs; /* devfs device */
struct urb scn_irq;
unsigned int ifnum; /* Interface number of the USB device */
kdev_t scn_minor; /* Scanner minor - used in disconnect() */
-
-
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/
Proc table and file table
Hello: I would like to know how can I check the current number of process and open files i have running on my system. 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/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
Mike> OK, riddle me this. If this test is a crummy test, just how is Mike> it that I was able to warn Rik in advance that when 2.4.5 was Mike> released, he should expect complaints? How did I _know_ that? Mike> The answer is that I fiddle with Rik's code a lot, and I test Mike> with this test because it tells me a lot. It may not tell you Mike> anything, but it does me. I never said it was a crummy test, please do not read more into my words than was written. What I was trying to get across is that just one test (such as a compile of the kernel) isn't perfect at showing where the problems are with the VM sub-system. Jonathan Morton has been using another large compile to also test the sub-system, and it includes a compile which puts a large, single process pressure on the VM. I consider this to be a more representative test of how the VM deals with pressure. The kernel compile is an ok test of basic VM handling, but from what I've been hearing on linux-kernel and linux-mm is that the VM goes to crap when you have a mix of stuff running, and one (or more) processes starts up or grows much larger and starts impacting the system performance. I'm also not knocking your contributions to this discussion, so stop being so touchy. I was trying to contribute and say (albeit poorly) that a *mix* of tests is needed to test the VM. More importantly, a *repeatable* set of tests is what is needed to test the VM and get consistent results from run to run, so you can see how your changes are impacting performance. The kernel compile doesn't really have any one process grow to a large fraction of memory, so dropping in a compile which *does* is a good thing. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548 - 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: xircom_cb problems
Whoops!! Sorry, forgot the attachment. Thanks, Tom > Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving > from a 100Mbit box (tulip or starfire, doesn't seem to matter). > Transmitting is still slow for me, but that is most likely a different > problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s is below usable when doing any network based work. > Moreover, I'm getting 9+MB/s in both directions when using the other > driver (xircom_tulip_cb), patched to do half-duplex only. So the card > can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. > Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec --- 10.10.4.254 ping statistics --- 10 packets transmitted, 8 packets received, 20% packet loss round-trip min/avg/max/mdev = 0.575/1500.228/3000.710/1117.327 ms [root@iso-2146-l1 ttsig]# rmmod xircom_cb rmmod: module xircom_cb is not loaded [root@iso-2146-l1 ttsig]# lsmod Module Size Used by appletalk 18352 0 (autoclean) serial 44864 0 vmnet 16448 1 vmmon 18352 0 r128 145392 1 agpgart13568 3 (autoclean) usb-uhci 20864 0 (unused) usbcore48176 1 [usb-uhci] [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=955 usec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=492 usec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=453 usec 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=465 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=451 usec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=455 usec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=450 usec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=453 usec --- 10.10.4.254 ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.450/0.521/0.955/0.166 ms
Re: temperature standard - global config option?
Hi, > Then you must have blown your quantum finals. Royally. ESPECIALLY > after that statement about "temperature is nothing but the movement of > pieces of materie". Not even close, once you get into the quant. > > Mathematically and quantum mechanically, negative absolute > temperatures do exist. In quantum mechanics, temperature is expressed as > probability populations in various quantum states. Excuse me, but I don't think that we can get computer temperature sensors as we know them to measure temperatures of matter in quantum states. Even if, one day, we built a usable quantum computer which might need temperature measurements, I doubt that the Linux kernel would run on it without being totally rewritten. Anyhow, I like the discussion. I love anything to do with quantum physics! -- Chris Boot [EMAIL PROTECTED] #define QUESTION ((2b) || (!2b)) - 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: oops with kernel 2.4.5
well, my guess is that the compiler misscompiles your kernel. stil _contrary_ to REPORTING_BUGS file you did not gave any info about your system. some usefull stuff you should email are (adjust it to your setup) a) cd /usr/src/linux rm fs/buffer.o make fs/buffer.o email output of the make then find out what gcc was used (gcc,kgcc etc) and email what gcc it was, ie b) gcc -v then run following command c) gdb vmlinux disassemble __remove_from_queues in gdb run the above command and email output of all the 3 above, then ppl on LKML might be able to help you better. On Fri, 8 Jun 2001, szonyi calin wrote: > Hi > we found in logs a oops and here are the results from > ksymoops (2.4.1) > > Unable to handle kernel NULL pointer dereference at > virtual address 0004 > c012db89 > *pde = > Oops: 0002 > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: ebx: c00725c0 ecx: c00725c0 edx: > 0004 > esi: c00725c0 edi: c00725c0 ebp: esp: > c10a9f70 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 3, stackpage=c10a9000) > Stack: c0130092 c00725c0 c1076e94 c1076e78 c025eb90 > 0027 c00725c0 0003 >c0126cb1 c1076e78 0004 > 0008e000 > 0004 003c c0127551 > 0004 c10a8000 > Call Trace: [] [] [] > [] [] [ 0105463>] > Code: 89 02 c7 41 30 00 00 00 00 31 c0 66 8b 41 0a 50 > 51 e8 0d ffUnable to handle kernel NULL pointer > dereference at virtual address 0004 > c012db89 > *pde = > Oops: 0002 > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: ebx: c00725c0 ecx: c00725c0 edx: > 0004 > esi: c00725c0 edi: c00725c0 ebp: esp: > c10a9f70 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 3, stackpage=c10a9000) > Stack: c0130092 c00725c0 c1076e94 c1076e78 c025eb90 > 0027 c00725c0 0003 >c0126cb1 c1076e78 0004 > 0008e000 > 0004 003c c0127551 > 0004 c10a8000 > Call Trace: [] [] [] > [] [] [ 0105463>] > Code: 89 02 c7 41 30 00 00 00 00 31 c0 66 8b 41 0a 50 > 51 e8 0d ff > >>EIP; c012db89 <__remove_from_queues+19/34> <= > Trace; c0130092 > Trace; c0126cb1 > Trace; c0127551 > Trace; c01275df > Trace; c0105000 > Code; c012db89 <__remove_from_queues+19/34> > <_EIP>: > Code; c012db89 <__remove_from_queues+19/34> <= >0: 89 02 movl %eax,(%edx) > <= > Code; c012db8b <__remove_from_queues+1b/34> >2: c7 41 30 00 00 00 00 movl > $0x0,0x30(%ecx) > Code; c012db92 <__remove_from_queues+22/34> >9: 31 c0 xorl %eax,%eax > Code; c012db94 <__remove_from_queues+24/34> >b: 66 8b 41 0a movw 0xa(%ecx),%ax > Code; c012db98 <__remove_from_queues+28/34> >f: 50pushl %eax > Code; c012db99 <__remove_from_queues+29/34> > 10: 51pushl %ecx > Code; c012db9a <__remove_from_queues+2a/34> > 11: e8 0d ff 00 00call ff23 > <_EIP+0xff23> c013daac >>EIP; > c012db89 <__remove_from_queues+19/34> <= > Trace; c0130092 > Trace; c0126cb1 > Trace; c0127551 > Trace; c01275df > Trace; c0105000 > Code; c012db89 <__remove_from_queues+19/34> > <_EIP>: > Code; c012db89 <__remove_from_queues+19/34> <= >0: 89 02 movl %eax,(%edx) > <= > Code; c012db8b <__remove_from_queues+1b/34> >2: c7 41 30 00 00 00 00 movl > $0x0,0x30(%ecx) > Code; c012db92 <__remove_from_queues+22/34> >9: 31 c0 xorl %eax,%eax > Code; c012db94 <__remove_from_queues+24/34> >b: 66 8b 41 0a movw 0xa(%ecx),%ax > Code; c012db98 <__remove_from_queues+28/34> >f: 50pushl %eax > Code; c012db99 <__remove_from_queues+29/34> > 10: 51pushl %ecx > Code; c012db9a <__remove_from_queues+2a/34> > 11: e8 0d ff 00 00call ff23 > <_EIP+0xff23> c013daac > > Well ? > > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.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/ > -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - 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
Re: [patch] Re: Linux 2.4.5-ac6
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote: > On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: > > On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: > > > > Exactly. However, there are situations when you have only two options: > > > rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) > > > > Why can't mozilla be fixed? With the -taso option there is actually less > > encouragement to do so. > > Mozilla is fine. Its netscape 4.X that probably needs -taso. And only the old netscape 4.x releases at that afik the newer releases are all compiled ELF. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, John Stoffel wrote: > > "Tobias" == Tobias Ringstrom <[EMAIL PROTECTED]> writes: > > Tobias> On Fri, 8 Jun 2001, Mike Galbraith wrote: > > >> I gave this a shot at my favorite vm beater test (make -j30 bzImage) > >> while testing some other stuff today. > > Tobias> Could you please explain what is good about this test? I > Tobias> understand that it will stress the VM, but will it do so in a > Tobias> realistic and relevant way? > > I agree, this isn't really a good test case. I'd rather see what > happens when you fire up a gimp session to edit an image which is > *almost* the size of RAM, or even just 50% the size of ram. Then how > does that affect your other processes that are running at the same > time? OK, riddle me this. If this test is a crummy test, just how is it that I was able to warn Rik in advance that when 2.4.5 was released, he should expect complaints? How did I _know_ that? The answer is that I fiddle with Rik's code a lot, and I test with this test because it tells me a lot. It may not tell you anything, but it does me. -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/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, Tobias Ringstrom wrote: > On Fri, 8 Jun 2001, Mike Galbraith wrote: > > I gave this a shot at my favorite vm beater test (make -j30 bzImage) > > while testing some other stuff today. > > Could you please explain what is good about this test? I understand that > it will stress the VM, but will it do so in a realistic and relevant way? Can you explain what is bad about this test? ;) It spins the same VM wheels as any other load does. What's the difference if I have a bunch of httpd allocating or a bunch of cc1/as/ld? This load has a modest cachable data set and is compute bound.. and above all gives very repeatable results. I use it to watch reaction to surge. I watch for the vm to build to a solid maximum throughput without thrashing. That's the portion of VM that I'm interested in, so that's what I test. Besides :) I simply don't have the hardware to try to simulate hairy chested server loads. There are lots of folks with hairy chested boxes.. they should test that stuff. I've been repeating ~this test since 2.0 times, and have noticed a 1:1 relationship. When I notice that my box is ~happy doing this load test, I also notice very few VM gripes hitting the list. > Isn't the interesting case when you have a number of processes using lots > of memory, but only a part of all that memory is beeing actively used, and > that memory fits in RAM. In that case, the VM should make sure that the > not used memory is swapped out. In RAM you should have the used memory, > but also disk cache if there is any RAM left. Does the current VM handle > this case fine yet? IMHO, this is the case most people care about. It is > definately the case I care about, at least. :-) The interesting case is _every_ case. Try seeing my particular test as a simulation of a small classroom box with 30 students compiling their assignments and it'll suddenly become quite realistic. You'll notice by the numbers I post that I was very careful to not overload the box in a rediculous manner when selecting the total size of the job.. it's just a heavily loaded box. This test does not overload my IO resources, so it tests the VM's ability to choose and move the right stuff at the right time to get the job done with a minimum of additional overhead. The current VM handles things generally well imho, but has problems regulating itself under load. My test load hits the VM right in it's weakest point (not _that_ weak, but..) by starting at zero and building rapidly to max.. and keeping it _right there_. > I'm not saying that it's a completely uninteresting case when your active > memory is bigger than you RAM of course, but perhaps there should be other > algorithms handling that case, such as putting some of the swapping > processes to sleep for some time, especially if you have lots of processes > competing for the memory. I may be wrong, but it seems to me that your > testcase falls into this second category (also known as thrashing). Thrashing? Let's look some numbers. (not the ugly ones, the ~ok ones;) real9m12.198s make -j 30 bzImage user7m41.290s sys 0m34.840s user : 0:07:47.69 76.8% page in : 452632 nice : 0:00:00.00 0.0% page out: 399847 system: 0:01:17.08 12.7% swap in :75338 idle : 0:01:03.97 10.5% swap out:88291 real8m6.994s make bzImage user7m34.350s sys 0m26.550s user : 0:07:37.52 78.4% page in :90546 nice : 0:00:00.00 0.0% page out:18164 system: 0:01:26.13 14.8% swap in :1 idle : 0:00:39.69 6.8% swap out:0 ...look at cpu utilization. One minute +tiny change to complete the large job vs the small (VM footprint) job. The box is not thrashing, it's working it's little silicon butt off. What I'm testing is the VM's ability to handle load without thrashing so badly that it loses throughput bigtime, stalls itself whatever.. it's ability to regulate itself. I consider a minute and a half to be ~acceptable, a minute to be good, and 30 seconds to be excellent. That's just my own little VM performance thermometer. > An at last, a humble request: Every problem I've had with the VM has been > that it either swapped out too many processes and used too much cache, or > the other way around. I'd really enjoy a way to tune this behaviour, if > possible. Tunables aren't really practical in VM (imho). If there were a dozen knobs, you'd have to turn a dozen knobs a dozen times a day. VM has to be self regulating. In case you can't tell (the length of this reply) I like my fovorite little generic throughput test a LOT :-) -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/
Re: [driver] New life for Serial mice
On Fri, Jun 08, 2001 at 06:20:46PM +0200, Pavel Machek wrote: > Hi! > > > > > If you still have your 3-button MouseSystems (or any other serial) mouse > > > > somewhere in your driver, forgotten becase of the incredibly slow update > > > > rate causing so much jumping of the pointer on the screen that it is > > > > unusable, you may want to pull it out and give it a try. > > > > > > > > Or if you're still using it with some old 486 computer, this driver is > > > > for you. > > > > > > > > What it does is that it enhances the update rate from 24 (with current > > > > GPM and X drivers) to 96. This is almost what the best USB mice do. > > > > > > What's the "prediction" stuff? Does it mean you are guessing some values > > > by interpolation? > > > > Extrapolation, yes. > > Can't it make mouse jump forward and back when user suddenly stops? In theory - yes. It doesn't seem to be a problem in practice, though. It'll happen when a user slows down the mouse pointer motion faster than exponentially (base 2). I haven't been able to stop that fast. > > > [If so, what kind of update rate would it do on USB?] > > > > It wouldn't make any difference - on USB you always get whole packets, > > while over serial port the data is processed byte by byte and thus we > > know a little of the information before the whole packet arrives. > > Ouch, nice trick! Most importantly - it makes serial mice usable. -- Vojtech Pavlik 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: [driver] New life for Serial mice
Hi! > > > If you still have your 3-button MouseSystems (or any other serial) mouse > > > somewhere in your driver, forgotten becase of the incredibly slow update > > > rate causing so much jumping of the pointer on the screen that it is > > > unusable, you may want to pull it out and give it a try. > > > > > > Or if you're still using it with some old 486 computer, this driver is > > > for you. > > > > > > What it does is that it enhances the update rate from 24 (with current > > > GPM and X drivers) to 96. This is almost what the best USB mice do. > > > > What's the "prediction" stuff? Does it mean you are guessing some values > > by interpolation? > > Extrapolation, yes. Can't it make mouse jump forward and back when user suddenly stops? > > [If so, what kind of update rate would it do on USB?] > > It wouldn't make any difference - on USB you always get whole packets, > while over serial port the data is processed byte by byte and thus we > know a little of the information before the whole packet arrives. Ouch, nice trick! Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - 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: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 11:21:34PM +, Pavel Machek wrote: > > If you still have your 3-button MouseSystems (or any other serial) mouse > > somewhere in your driver, forgotten becase of the incredibly slow update > > rate causing so much jumping of the pointer on the screen that it is > > unusable, you may want to pull it out and give it a try. > > > > Or if you're still using it with some old 486 computer, this driver is > > for you. > > > > What it does is that it enhances the update rate from 24 (with current > > GPM and X drivers) to 96. This is almost what the best USB mice do. > > What's the "prediction" stuff? Does it mean you are guessing some values > by interpolation? Extrapolation, yes. > [If so, what kind of update rate would it do on USB?] It wouldn't make any difference - on USB you always get whole packets, while over serial port the data is processed byte by byte and thus we know a little of the information before the whole packet arrives. -- Vojtech Pavlik 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: Linux support for PDC20268
I am betting on CMD and Highpoint. I will meet with CMD in Irvine during the next T13 meeting in two weeks. Andre Hedrick ASL Kernel Development Linux ATA Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com On Fri, 8 Jun 2001, Frank Neuber wrote: > Andre Hedrick wrote: > > > > Frank, > > > > "Frank Tiernan" does not exist at Promise anymore, and that company is > > HOSTILE towards Linux Now. > Hi Andre, > thanks for your response. What is your advice for an IDE-Controller > in an multi platform environment? > > Frank > > -- > Dipl.-Ing. Elektrotechnik convergence integrated media gmbh / HW > Frank NeuberRosenthalerstr.51 / 10178 Berlin > Email: [EMAIL PROTECTED] Phone: +49(0)30-72 62 06 50 > WWW:www.convergence.de Fax:+49(0)30-72 62 06 55 > - 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: VM Report was:Re: Break 2.4 VM in five easy steps
> "Tobias" == Tobias Ringstrom <[EMAIL PROTECTED]> writes: Tobias> On Fri, 8 Jun 2001, Mike Galbraith wrote: >> I gave this a shot at my favorite vm beater test (make -j30 bzImage) >> while testing some other stuff today. Tobias> Could you please explain what is good about this test? I Tobias> understand that it will stress the VM, but will it do so in a Tobias> realistic and relevant way? I agree, this isn't really a good test case. I'd rather see what happens when you fire up a gimp session to edit an image which is *almost* the size of RAM, or even just 50% the size of ram. Then how does that affect your other processes that are running at the same time? This testing could even be automated with the script-foo stuff to get consistent results across runs, which is the prime requirement of any sort of testing. On another issue, in swap.c we have two defines for buffer_mem and page_cache, but the first maxes out at 60%, while the cache maxes out at 75%. Shouldn't they both be lower numbers? Or at least equally sized? I've set my page_cache maximum to be 60, I'll be trying to test it over the weekend, but good weather will keep me outside doing other stuff... Thanks, John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548 - 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: Cannot mount old ext2 cdrom, but e2fsck shows no problems
HIi! > I made 18 ext2 cdroms in October 1998 using an old (new at the time) Red > Hat system. Now I can't mount them. e2fsck shows no problems. I also > can dd them to a file, then mount the file. But I want to be able to > simply access them directly. Current system: RH 7.1 with all updates. > > Sorry, I can't remember the exact command I used to create the images. > > I also want to better understand the output of dumpe2fs, and how to > relate this to mount. > > I will be very grateful for any help that increases my understanding of > what is going on. > > $ sudo mount -t ext2 /dev/scd0 /cdrom -o ro > mount: wrong fs type, bad option, bad superblock on /dev/scd0, >or too many mounted file systems Try -o loop. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.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: [driver] New life for Serial mice
Hi! > > If you still have your 3-button MouseSystems (or any other serial) mouse > somewhere in your driver, forgotten becase of the incredibly slow update > rate causing so much jumping of the pointer on the screen that it is > unusable, you may want to pull it out and give it a try. > > Or if you're still using it with some old 486 computer, this driver is > for you. > > What it does is that it enhances the update rate from 24 (with current > GPM and X drivers) to 96. This is almost what the best USB mice do. What's the "prediction" stuff? Does it mean you are guessing some values by interpolation? [If so, what kind of update rate would it do on USB?] Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.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/
Unresolved symbols in 2.4.6-pre1
A make modules_install gives: depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/input/keybdev.o depmod: tasklet_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/isdn/hisax/hisax.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/isdn/isdn.o depmod: tasklet_hi_schedule depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_async.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_synctty.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/pppoe.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/pppox.o depmod: do_softirq - 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: PROC under 2.4
http://www.kernelnewbies.org/documents/ then ProcFS guide. ~Randy sebastien person wrote: > > Hi, > > I'm trying to port a driver to 2.4, but it seem that proc use has changed. > Is somebody have any docs about ? > > 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/
Is Kernel2.2 is SMP versioned by default?
Hi, Could anyone plz tell me whether the kernel - 2.2.14 is SMP or NON-SMP by default? To make it SMP versioned, Do I need to add some flags in the kernel header files and re-compile to kernel? Thanks in advance, Jal __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.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: [patch] 32-bit dma memory zone
Richard Henderson <[EMAIL PROTECTED]> writes: > On Thu, Jun 07, 2001 at 02:22:10PM -0700, Linus Torvalds wrote: > > For example, what's the difference between ZONE_HIGHMEM and ZONE_NORMAL > > on a sane 64-bit architecture (right now I _think_ the 64-bit architectures > > actually make ZONE_NORMAL be what we call ZONE_DMA32 on x86, because they > > already need to be able to distinguish between memory that can be PCI-DMA'd > > to, and memory that needs bounce-buffers. Or maybe it's ZONE_DMA that they > > use for the DMA32 stuff?). > > On most alphas we use only one zone -- ZONE_DMA. The iommu makes it > possible to do 32-bit pci to the entire memory space. > > For those alphas without an iommu, we also set up ZONE_NORMAL. The AMD760 which looks like it might walk on both the alpha, an x86 side of the fence also has an iommu. Mostly it's used for AGP but according to the docs it should be able to handle the other cases as well. The only downside is that it only supports 4GB of ram... Anyway we shouldn't assume iommu's don't exist on x86. Eric - 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/
PROC under 2.4
Hi, I'm trying to port a driver to 2.4, but it seem that proc use has changed. Is somebody have any docs about ? 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/
tcp_recvmsg() in 2.4.4
If there are no packets on sk->recieve_queue, and nothing has been copied
to userland yet, it seems to me there is a redundant test of sk->done.
About line 1461 in net/ipv4/tcp.c:
/* Well, if we have backlog, try to process it now yet. */
if (copied >= target && sk->backlog.tail == NULL)
break;
if (copied) {
if (sk->err ||
sk->state == TCP_CLOSE ||
(sk->shutdown & RCV_SHUTDOWN) ||
!timeo ||
(flags & MSG_PEEK))
break;
} else {
if (sk->done)
break;
if (sk->err) {
copied = sock_error(sk);
break;
}
if (sk->shutdown & RCV_SHUTDOWN)
break;
if (sk->state == TCP_CLOSE) {
if (!sk->done) {
/* This occurs when user tries to read
* from never connected socket.
*/
copied = -ENOTCONN;
break;
}
break;
}
if (!timeo) {
copied = -EAGAIN;
break;
}
}
When it get to if(sk->state == TCP_CLOSE), surely sk->done has already been
tested (and the socket is locked), so -ENOTCONN could be returned
immediately.
Actually I'd really appreciate it if someone could explain the order of
tests for sk->done, sk->err, sk->shutdown and sk->state...
--
Cheers,
Eric
|Eric BartonBarton Software|
|9 York Gardens Tel:+44 (117) 923 9831 |
|CliftonMobile: +44 (7909) 680 356 |
|Bristol BS8 4LLFax:call first |
|United Kingdom 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/
[PATCH] Support Timedia/Sunix/Exsys PCI card problem in Serial 5.0.5 / Kernel 2.4.xx
Hi!
I've found a bug in the serial driver 5.0.5, the problem is
that the Sunix pci 4port serial card wasn't correctly detected.
I'm using the serial 5.0.5 serial driver on a vanilla 2.2.19 kernel.
Searching the web I've found this changes that looks wrong :
http://www.linuxhq.com/kernel/v2.3/patch/patch-2.4.0-test7/linux_drivers_char_serial.c.html
here the obvious patch that made it work again here on 2.2.19 kernel.
Should be applied also on 2.4.x :
--- serial.c.oriFri Jun 8 16:12:16 2001
+++ serial.cFri Jun 8 16:12:30 2001
@@ -4178,7 +4178,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
- if (pci_get_subvendor(dev) == ids[j]) {
+ if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
ciao,
luca
-
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] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:28:04PM +0200, Maciej W. Rozycki wrote: > DU seems to map as low as possible, it would seem. Yes, I've just checked, starting at 64K... > Maybe we could just > do the same for OSF/1 binaries by setting TASK_UNMAPPED_BASE > appropriately? No. I've changed in load_aout_binary() set_personality(PER_LINUX) to set_personality(PER_LINUX_32BIT), and now I have another error. You will laugh, but... $ netscape 665:/usr/lib/netscape/netscape-communicator: : Fatal Error: mmap available address is not larger than requested This happens after mmap(0x7fdc8000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 And note, this is the message from loader, not from netscape itself. So I think my second patch is an easiest solution for now. Look, compared with the code in Linus' tree: - it doesn't add any overhead in general case (addr == 0); - if the specified address is too high and we can't find a free area above it, we just continue search from TASK_UNMAPPED_BASE as usual; - if address is too low, extra cost is only compare and taken branch. I think it's clean enough. Ivan. - 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: VM Report was:Re: Break 2.4 VM in five easy steps
On Fri, 8 Jun 2001, Mike Galbraith wrote: > I gave this a shot at my favorite vm beater test (make -j30 bzImage) > while testing some other stuff today. Could you please explain what is good about this test? I understand that it will stress the VM, but will it do so in a realistic and relevant way? Isn't the interesting case when you have a number of processes using lots of memory, but only a part of all that memory is beeing actively used, and that memory fits in RAM. In that case, the VM should make sure that the not used memory is swapped out. In RAM you should have the used memory, but also disk cache if there is any RAM left. Does the current VM handle this case fine yet? IMHO, this is the case most people care about. It is definately the case I care about, at least. :-) I'm not saying that it's a completely uninteresting case when your active memory is bigger than you RAM of course, but perhaps there should be other algorithms handling that case, such as putting some of the swapping processes to sleep for some time, especially if you have lots of processes competing for the memory. I may be wrong, but it seems to me that your testcase falls into this second category (also known as thrashing). An at last, a humble request: Every problem I've had with the VM has been that it either swapped out too many processes and used too much cache, or the other way around. I'd really enjoy a way to tune this behaviour, if possible. /Tobias - 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/
