Re: [PATCH] Force UNIX domain sockets to be built in
On Mon, Dec 31, 2007 at 04:34:55PM +0100, Jan Engelhardt wrote: > > > >If you'd aim for a small kernel image, you would build anything as a module > >that is not requred for booting. > > > Yes, there is a tradeoff for both. > > Example: > 16:30 ichi:../net/802 > l fc.o fc.ko > -rw-r--r-- 1 jengelh users 7961 Dec 27 15:19 fc.ko > -rw-r--r-- 1 jengelh users 2453 Dec 28 23:58 fc.o > (from a recent not-so-complete patch turning CONFIG_FC etc. into =m) > > If fc was modular, it might save the 2453 bytes off the core kernel image, > but adds ~5508 bytes to disk. > So one has to pick =y or =m depending on whatever suits his/her situation. May I ask something that might be obvious for most of the development community: Modules have to be loaded in seperate pages, right ? Does that mean that each module wastes partially used pages of memory at runtime ? I've always tried to build as much into the kernel image as possible, because all of my systems have only 512M memory. Thanks, Patrick -- 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: programs vanish with 2.6.22+
On Sat, Dec 08, 2007 at 01:25:21PM +0100, Markus wrote: > Well, just tried it. Started a dozen konquerors and attached strace to > everyone. When one disapeared, I only got a "Process 9246 detached", > nothing else is printed or written in the log. > > Markus Hallo Markus Whenever the connection to the X server is dropped the application using that connection will be terminated by the client library error handler (KDE/Qt/X11). Probably the applications simply drop out of their event loop and terminate, you should see some X11 related error messages in .xsession-errors My guess would be that some of the eye-candy in KDE is using DRI / OpenGL features that might be the cause for mailfunction. I would suggest you start by disabling DRI / AIGLX rendering in your xorg.conf and see if your applications work without all those nifty features. Below you can find some settings to disable AIGLX, DRI and composite rendering. They should be integrated in the configuration sections I quoted. This is not a complete configuration file. Best regards, Patrick --- --- Section "ServerFlags" Option "AIGLX" "false" EndSection Section "Module" Disable "dri" EndSection Section "Extensions" Option "Composite" "false" EndSection --- --- -- 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: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)
On Mon, Sep 03, 2007 at 09:56:10AM +0200, Xavier Bestel wrote: > Hi, Hi Xavier > I have a server running with RAID5 disks, under debian/stable, kernel > 2.6.18-5-686. Yesterday the RAID resync'd for no apparent reason, > without even mdamd sending a mail to warn about that: > > Sep 2 01:06:01 awak kernel: md: syncing RAID array md0 [snip] > I'm still gathering informations (no idea what his disks are, etc.), but > does anyone have the same problem ? Does anyone know where it can come > from (debian trouble, md bug, drive firmware problem, rootkit, ..) and > how I can pinpoint that ? My debian installation has a system cronjob that will perform a resync every first Sunday morning at 1:06 AM: [EMAIL PROTECTED] cat /etc/cron.d/mdadm ... 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet I did not read the manpage, but my guess is that 'quiet' will suppress the mail notification. Regards, Patrick - 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: Hang in 2.6.23-rc5
On Mon, Sep 03, 2007 at 04:15:01AM +0530, Satyam Sharma wrote: > On Mon, 3 Sep 2007, Alexey Dobriyan wrote: > > > > Try this from net-2.6 tree: > > > > --- a/net/ipv4/tcp_input.c > > +++ b/net/ipv4/tcp_input.c > > @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) > > struct dst_entry *dst = __sk_dst_get(sk); > > u32 rto_min = TCP_RTO_MIN; > > > > - if (dst_metric_locked(dst, RTAX_RTO_MIN)) > > + if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) > > rto_min = dst->metrics[RTAX_RTO_MIN-1]; > > return rto_min; > > } > > That's my impression as well. That's way too core/busy a codepath to have > a bug in. As I said earlier, almost anybody testing -rc5 is sure to hit > this within a few hours (probably less) -- sad, it greatly erodes from the > usefulness of -rc5 as a release candidate. The above patch also fixed my problems using NFS mounted home directories. I already applied it yesterday without giving any feedback, so I just thought I should comment. In addition I totally agree with Satyam's comment above: either anybody is testing rc's these days, or people simply stopped reporting. My concern is that we have to live with a git tree that has this problem, because core developers are unavailable and nobody has the authority to commit this fix. (That was already posted before). I am not voting for public commit rights and personally I don't want them anyway. It's just my observation that nothing really happens whenever a point release is only a few days away. Maybe most people believe that they have to wait for the 2.6.24 cycly to start before they join the discussion again ... Patrick - 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: SATA RAID5 speed drop of 100 MB/s
On Mon, Jun 25, 2007 at 12:07:23AM +0200, Carlo Wood wrote: > On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote: > > Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed > > per various bonnie++ tests. > > There is more going on than a bad NCQ implementation of the drive imho. > I did a long test over night (and still only got two schedulers done, > will do the other two tomorrow), and the difference between a queue depth > of 1 and 2 is DRAMATIC. > > See http://www.xs4all.nl/~carlo17/noop_queue_depth.png > and http://www.xs4all.nl/~carlo17/anticipatory_queue_depth.png Hi Carlo, Have you considered using "blktrace" ? It enables you to gather data of all seperate requests queues and will also show you the mapping of bio request from /dev/mdX to the individual physical disk. You can also identify SYNC and BARRIER flags for requests, that might show you why the md driver will sometimes wait for completion or even REQUEUE if the queue is full. Just compile your kernel with CONFIG_BLK_DEV_IO_TRACE and pull the "blktrace" (and "blockparse") utility with git. The git URL is in the Kconfig help text. You have to mount, debugfs (automatically selected by IO trace). I just want to mention, because I did not figure it at first ;) You should of course use a different location for the output files to avoid an endless flood of IO. Regards, Patrick PS: I know, I talked about blktrace twice already ;) - 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] [RFC] Adjust queue unplugging and congestion limits
Good afternoon
Following is a small patch to "ll_rw_block" I played around with.
I started using "blktrace" to analyse the performance of my dated
LVM / MD / SCSI setup. It's really a nice tool, by the way.
The changes are:
* Change the "q->unplug_thresh" to be halve of "q->nr_requets".
This dynamically delays unplugging. It was hardcoded to 4 and
makes a difference in performace because of higher merge counts.
* Change the unplug timeout to 10 milliseconds.
This is of course questionable, but I don't know why 3 was
choosen in the first place. I just played with it.
* Set the congestion on/off limits further apart.
* Cleanup the congestion checks (no "+1" anymore, more readable).
* Update "q->unplug_thresh" whenever "q->nr_requests" is updated
through sysfs.
I did various artifical benchmarksi, mostly tar, dd and cp (also to NFS).
Comments are welcome.
Best regards,
Patrick
Signed-Off-By: Patrick Mau <[EMAIL PROTECTED]>
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index c99b463..aa26ff3 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -96,17 +96,8 @@ static inline int queue_congestion_off_threshold(struct
request_queue *q)
static void blk_queue_congestion_threshold(struct request_queue *q)
{
- int nr;
-
- nr = q->nr_requests - (q->nr_requests / 8) + 1;
- if (nr > q->nr_requests)
- nr = q->nr_requests;
- q->nr_congestion_on = nr;
-
- nr = q->nr_requests - (q->nr_requests / 8) - (q->nr_requests / 16) - 1;
- if (nr < 1)
- nr = 1;
- q->nr_congestion_off = nr;
+ q->nr_congestion_on = q->nr_requests - (q->nr_requests / 32);
+ q->nr_congestion_off = q->nr_requests - (q->nr_requests / 16);
}
/**
@@ -217,8 +208,10 @@ void blk_queue_make_request(request_queue_t * q,
make_request_fn * mfn)
blk_queue_congestion_threshold(q);
q->nr_batching = BLK_BATCH_REQ;
- q->unplug_thresh = 4; /* hmm */
- q->unplug_delay = (3 * HZ) / 1000; /* 3 milliseconds */
+ /* make these tuneable ? */
+ q->unplug_thresh = BLKDEV_MAX_RQ / 2;
+ q->unplug_delay = (10 * HZ) / 1000;
+
if (q->unplug_delay == 0)
q->unplug_delay = 1;
@@ -2033,7 +2026,7 @@ static void __freed_request(request_queue_t *q, int rw)
if (rl->count[rw] < queue_congestion_off_threshold(q))
blk_clear_queue_congested(q, rw);
- if (rl->count[rw] + 1 <= q->nr_requests) {
+ if (rl->count[rw] < q->nr_requests) {
if (waitqueue_active(&rl->wait[rw]))
wake_up(&rl->wait[rw]);
@@ -2078,8 +2071,8 @@ static struct request *get_request(request_queue_t *q,
int rw_flags,
if (may_queue == ELV_MQUEUE_NO)
goto rq_starved;
- if (rl->count[rw]+1 >= queue_congestion_on_threshold(q)) {
- if (rl->count[rw]+1 >= q->nr_requests) {
+ if (rl->count[rw] >= queue_congestion_on_threshold(q)) {
+ if (rl->count[rw] >= q->nr_requests) {
ioc = current_io_context(GFP_ATOMIC, q->node);
/*
* The queue will fill after this allocation, so set
@@ -3877,7 +3870,7 @@ queue_var_store(unsigned long *var, const char *page,
size_t count)
static ssize_t queue_requests_show(struct request_queue *q, char *page)
{
- return queue_var_show(q->nr_requests, (page));
+ return queue_var_show(q->nr_requests, page);
}
static ssize_t
@@ -3890,6 +3883,7 @@ queue_requests_store(struct request_queue *q, const char
*page, size_t count)
nr = BLKDEV_MIN_RQ;
spin_lock_irq(q->queue_lock);
+ q->unplug_thresh = nr / 2;
q->nr_requests = nr;
blk_queue_congestion_threshold(q);
@@ -3905,14 +3899,14 @@ queue_requests_store(struct request_queue *q, const
char *page, size_t count)
if (rl->count[READ] >= q->nr_requests) {
blk_set_queue_full(q, READ);
- } else if (rl->count[READ]+1 <= q->nr_requests) {
+ } else if (rl->count[READ] < q->nr_requests) {
blk_clear_queue_full(q, READ);
wake_up(&rl->wait[READ]);
}
if (rl->count[WRITE] >= q->nr_requests) {
blk_set_queue_full(q, WRITE);
- } else if (rl->count[WRITE]+1 <= q->nr_requests) {
+ } else if (rl->count[WRITE] < q->nr_requests) {
blk_clear_queue_full(q, WRITE);
wake_up(&rl->wait[WRITE]);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 on Fedora Core 6 breaks LVM/vgscan
On Mon, May 21, 2007 at 04:02:46PM +0930, Jonathan Woithe wrote: > On 21 May 2007 I wrote: > > > Attempting to compile a 2.6.21.1 kernel for use on a Fedora Core 6 box > > results in a panic at boot because the root filesystem can't be found. > > I have just compiled 2.6.22-rc2 with the configuration file given in my > previous post and the resulting kernel successfully boots on the machine > concerned. Whatever broke LVM for this machine in between 2.6.18 and > 2.6.21.1 has now been fixed. I recall that the device major number was moved to another place (253 ?) Since this change caused many complaints, it was removed later on ... > There is still a problem with the CDROM but I will follow up in another > thread about that. Did you mention ata_piix ? With a recent git kernel, which I forgot, I was unable to read or eject DVD's. (Un-encrypted, BTW). Current git tree works fine again ... Patrick - 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: RSDL for 2.6.21-rc3- 0.29
On Mon, Mar 12, 2007 at 03:43:09PM -0400, Douglas McNaught wrote: > Gene Heskett <[EMAIL PROTECTED]> writes: > > > On Monday 12 March 2007, Douglas McNaught wrote: > >>Gene Heskett <[EMAIL PROTECTED]> writes: > >>> I'd considered it, but with 32 dle entries, the whole strace output > >>> would be terrabytes & I don't have THAT much disk. Not to mention it > >>> traces only the parent process, so tar would be merrily marching along > >>> to its own drummer and not traced I'm afraid. > >> > >>$ strace -ff > >> > >>-Doug > > > > Someone else suggested the single -f, and I tried that, but even with the > > shell history set for 100,000 lines, i can't get back to the start, and I > > think its mucking with the shell arguments numbering as what I can see is > > about 5 reads through /etc/services accompanied by endless complaints > > of -EBADFD, the the logfile it generates says the port it was given was > > rejected when amcheck was run, here is that snip: > > I'd do 'strace -ff -o /tmp/amanda-strace ', which will give > you a set of files in /tmp, one for each PID created by fork(). Then > find the one that has the 'tar' invocation you're looking for. Hi, I hope you don't mind me jumping in ... Why not temporarly replace "/bin/tar" with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ That should be working, shouldn't it ? Cheers, Patrick - 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] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Fri, Dec 22, 2006 at 01:32:49PM +0100, Martin Michlmayr wrote: > * Andrei Popa <[EMAIL PROTECTED]> [2006-12-22 14:24]: > > With all three patches I have corruption > > I've completed one installation with Linus' patch plus the two from > Andrew successfully, but I'm currently trying again... but I really > need a better testcase since an installation takes about an hour. > Andrei, which torrent do you download as a testcase? It would be good > if someone could suggest a torrent which is legal and not too large. Hi everyone, I have been reading this thread for the last few days, but have been silent. I have 3 torrents here for testing, if you want. You can easily reproduce with "rtorrent", if you: - Have a completly downloaded one, no matter what size - Corrupt the download with dd if=/dev/zero of=download.file bs=16k count=1 - Restart 'rtorrent', hash-check fails - It will download 1 piece that was corrupted. The important part here is that rtorrent transfers one piece, using its own code sequence to write to the file. Let me offer to test until Saturday afternoon CET, I have a cloned git repository, downloaded torrent files and "apt". My systems that are affected are: Linux oscar 2.6.18 SMP (2x450Mhz Intel P3) (rolled back to 2.6.18 but can boot latest git) Linux tony 2.6.20-git UP (can be tested using all kinds of "apt" operations) Both machines are using: IDE -> MD-RAID1 -> LVM -> EXT3 (data=ordered) SCSI -> MD-RAID5 -> . I don't want to disturb your technical discussion, just offering some help in testing. Regards, Patrick - 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 "aic7yyy Domain Validation"
Hallo everyone, I have a small question regarding the Domain Validation debugging output from my machine. It has four identical IBM drives, two on each channel. There's always a message saying "target0:0:0: wide asynchronous.", even without "verbose" booting. But in the verbose output below, there is also a line saying scsi0: target 0 synchronous at 80.0MHz DT, offset = 0x3f I assume that the first line should be considered as a debugging message, but the normally not printed second line is the actual device negotiation. Am I correct about that? Are the drives running at 160MB/s synchronous ? Would a patch be acceptable that removes the "wide asychronous" line and would instead output the final settings ? Thanks for your comments, Patrick PS: I will only include the first DV output with "aic7xxx=verbose" Hopefully it's not too long: Uniform CD-ROM driver Revision: 3.20 ahc_pci:2:10:0: Reading SEEPROM...done. ahc_pci:2:10:0: Manual SE Termination ahc_pci:2:10:0: BIOS eeprom is present ahc_pci:2:10:0: Primary Low Byte termination Enabled ahc_pci:2:10:0: Primary High Byte termination Enabled ahc_pci:2:10:0: Downloading Sequencer Program... 422 instructions downloaded ahc_pci:2:10:0: Features 0x1fef6, Bugs 0x40, Flags 0x20485500 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi0: Slave Alloc 0 (scsi0:A:0:0): Sending WDTR 0 (scsi0:A:0:0): Received WDTR 0 filtered to 0 target0:0:0: FAST-5 SCSI 1.0 MB/s ST (1020 ns, offset 255) scsi0: target 0 using 8bit transfers (scsi0:A:0:0): Sending SDTR period 45, offset 0 (scsi0:A:0:0): Received SDTR period 45, offset 0 Filtered to period 0, offset 0 target0:0:0: asynchronous. scsi0: target 0 using asynchronous transfers Vendor: IBM Model: IC35L036UCD210-0 Rev: S5BA Type: Direct-Access ANSI SCSI revision: 03 scsi0: Slave Configure 0 target0:0:0: asynchronous. scsi0:A:0:0: Tagged Queuing enabled. Depth 64 target0:0:0: Beginning Domain Validation (scsi0:A:0:0): Sending WDTR 1 (scsi0:A:0:0): Received WDTR 1 filtered to 1 target0:0:0: FAST-5 WIDE SCSI 2.0 MB/s ST (1020 ns, offset 255) scsi0: target 0 using 16bit transfers (scsi0:A:0:0): Sending SDTR period 45, offset 0 (scsi0:A:0:0): Received SDTR period 45, offset 0 Filtered to period 0, offset 0 target0:0:0: wide asynchronous. scsi0: target 0 using asynchronous transfers (scsi0:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (scsi0:A:0:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s ST (12.5 ns, offset 63) scsi0: target 0 synchronous at 80.0MHz DT, offset = 0x3f target0:0:0: Ending Domain Validation - 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/
Paket counters for aliased interfaces ?
Hello, I would like to use IP-Aliasing to create a private network between a few machines without buying more hardware. That's easy, but ifconfig tells me: eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:x.x.x.x Bcast:x.x.x.x Mask:x.x.x.x UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:126810 errors:0 dropped:0 overruns:0 frame:1426 TX packets:49286 errors:0 dropped:0 overruns:0 carrier:0 collisions:15942 txqueuelen:100 Interrupt:17 eth0:0Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:17 And here's the question: I would like to collect statistics for eth0:0 but obviously the pakets are only counted for the real interface. If I had enough time and knowledge, how should I implement paket counters for aliased interfaces ? PS: Am I right that it isn't possible ? tcpdump doesn't 'work right' either. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Where's pre13-x.diff.gz ?
Hi all, just a small question. The pre13-x.diff.gz patches vanished from ftp.xx.kernel.org. I need pre13-5 and pre13-6 (and later, if there where any). They have not been moved to testing/old or something, hopefully they're not lost ? cheers, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 3c59x still problems
On Thu, Oct 12, 2000 at 01:22:59AM +1100, Andrew Morton wrote: > [EMAIL PROTECTED] wrote: > > > > After upgrade to > > 2.4.0-test9 > > 3c59x is still giving these messages: > > > > Oct 11 06:34:36 adglinux1 kernel: eth0: transmit timed out, tx_status 00 status >e000. > > Oct 11 06:34:36 adglinux1 kernel: Flags; bus-master 1, full 1; dirty 10934497(1) >current 10934513(1). > > Oct 11 06:34:36 adglinux1 kernel: Transmit list 0f92d2f0 vs. cf92d210. > > Oct 11 06:34:36 adglinux1 kernel: 0: @cf92d200 length 85ea status 85ea > > ... > > This indicates that the NIC was unable to transmit a packet for 0.4 > seconds > due to collisions. > Hallo Mr Morton, I also upgraded my machine to 2.4.0test9 and have the same problems. Our network is a fully switched 100MBit Full-Duplex Network. All machines are connected to a cisco catalyst 5000. My machine is an ASUS P2B-S with 128MB RAM and a Pentium II 400MHz. (the report data is generated from 2.4.0-test7 but you can truely believe it's the same with 2.4.0-test9) uname -a : Linux reboot 2.4.0-test7 #2 Mon Okt 9 15:09:12 CEST 2000 i686 unknown The card banner on kernel-bootup looks like this: 3c59x.c:LK1.1.8 13 Aug 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.25 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0xb400, 00:10:5a:4c:c4:f2, IRQ 10 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. MII transceiver found at address 0, status 786d. Enabling bus-master transmits and whole-frame receives. This is lspci -vx 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) Subsystem: 3Com Corporation: Unknown device 9055 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at b400 [size=128] Memory at e080 (32-bit, non-prefetchable) [size=128] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 1 00: b7 10 55 90 17 00 10 02 30 00 00 02 08 20 00 00 10: 01 b4 00 00 00 00 80 e0 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 0a 0a This is a sample of /var/log/messages: Flags; bus-master 1, full 0; dirty 2170(10) current 2173(13). Transmit list 07f792b0 vs. c7f792a0. 0: @c7f79200 length 8382 status 00010382 1: @c7f79210 length 85ea status 000105ea 2: @c7f79220 length 83c2 status 000103c2 3: @c7f79230 length 85ea status 000105ea 4: @c7f79240 length 85ea status 000105ea 5: @c7f79250 length 85ea status 000105ea 6: @c7f79260 length 85ea status 000105ea 7: @c7f79270 length 85ea status 000105ea 8: @c7f79280 length 8112 status 00010112 9: @c7f79290 length 85ea status 000105ea 10: @c7f792a0 length 85ea status 000105ea 11: @c7f792b0 length 85ea status 05ea 12: @c7f792c0 length 85ea status 85ea 13: @c7f792d0 length 809e status 0001009e 14: @c7f792e0 length 80be status 000100be 15: @c7f792f0 length 80a2 status 000100a2 If you want me to send you additional information, contact me. Thanks, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc/sys/vm/freepages not writable.
Dear kernel-hackers, I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess these days ...) and noticed that /proc/sys/vm/freepages is no longer writable: [root@oscar] ll /proc/sys/vm/freepages -r--r--r--1 root root0 Sep 17 02:25 /proc/sys/vm/freepages If this was intentional, why has it changed ? thanks, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Masking out one page of RAM because of bit-errors.
Dear list-readers,
I have a bad SDRAM chip with exactly one bit error. Memtest86 shows
that the bit error always occurs at the address 0x4eff508. I tried
to calculate the page number and it should be 20223.
I then looked at arch/i386/mm/init.c and found the function
"page_is_ram". I added a test which was something like this:
static inline int page_is_ram (unsigned long pagenr)
{
int i;
if (pagenr == 20223)
return 0;
[rest of function snipped]
A also added a few printk's so I could verify that the page was
marked as reserved by the calling function.
But it does not work. I also tried 20222 and 20224 because I didn't
know if the first pagenr is 0 or 1.
Could someone tell me if there's another way to mark this single page
as unusable ?
Thanks,
Patrick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
