Hi, Next pre is up, changes since pre2: - Remove rq->cmd checks in merge functions, only WRITEs now - Fix io_request_lock lockup when used with ATAPI (req->end_io) - Throttle down write when failed and retry, should write OPC entry when this happens - Use current time for b_flushtime in buffer.c for packet device, we don't want to postpone flushing a buffer if it causes read gathering - Remove all bh->b_private references, we could be stomping on other users (highmem, most notably). - Always use pkt_end_io_write as our bh->b_end_io callback - Added write caching config option (don't use yet) - Added UDF empty block querying option - Fixed missing brelse() for buffers stolen from buffer cache - Combine pkt_init_bh and pkt_recount_segments to only do one scan of request (pkt_init_rq) - Fix dupe buffer_head in pkt_hole_merge - Change buffer_head sequence check in ll_rw_blk, add to SCSI end_request handling and it's been merged to 2.4.4-pre6. I'll hang on for final 0.0.2i until 2.4.4 is really released. *.kernel.org/pub/linux/kernel/people/axboe/packet/ As usual, there's a pre2 -> pre3 ugrade patch too. However, this one doesn't catch pre5 -> pre6, so I suggest getting 0.0.2i-pre3 from scratch. SCSI (Plextor 12/4/32) and ATAPI (Sony CRX100E) tested to the extent that large file copying was verified correct (100MB random data file), untarring 2.2.19 kernel source (and compiling it!), and various small files. No data loss of corruption detected, and it was all checked down to the very last byte. ATAPI used DMA mainly, PIO has also been tested good on this drive (just a large file copy, sanity verify). Note: although stuff like copying/untarring a kernel tree seems like fun, it isn't really a decent way to use packet writing. The pktcdvd module will do all it can to merge small writes together, but for decent performance one really should tar up small files before writing them to disc. For example, doing a make dep run on the 2.2.19 source ends up reading half the stuff from disc. Some writers are better at doing this quickly than others, the Sony beats the Plextor hands down in this sort of test (turning off laser, reading blocks, turn on and write). For the 100MB file copy, read gathering is almost exclusively due to getting the remaining parts of the packet that the UDF sparing table is written to. This is something we can't avoid (the WRITE), however I have plans for at least pinning the remaining blocks in memory. Right Ben? :-) Then arge file writes should go as fast as packet writing can go on your drive. Don't ask how long it takes to run make dep bzImage on a cd-rw stored kernel :-) (Un) fortunately I haven't had any failed writes on this particular disc just yet, so the write throttling path has not been exercised at all. It could be severly broken :-) Adam, I'll take a look at your scatter gather segment miscount next. I suspect this happens because of a requeue of the request. -- Jens Axboe
On Mon, Apr 23 2001, Jens Axboe wrote:
reading half the stuff from disc. Some writers are better at doing this quickly than others, the Sony beats the Plextor hands down in this sort of test (turning off laser, reading blocks, turn on and write). For the
In all fairness, the Plextor beats the Sony hands down for sequential writes, btw :-) -- Jens Axboe
Jens Axboe
Next pre is up, changes since pre2:
[...]
Yesterday with pre2 I had dire problems, so many that I gave up on making a proper bug report but basically it freaked out completely with scsi host resetting errors and kernel panic messages that took control over my tty + kbd when I tried to do the formatting part - and I was not able to log anything either. Eventually I had to push the big button. I tried again today with pre3 and still I don't get past the formatting hurdle. Here's what happens when I try to format a disc: -------------------- root@olafrye:/home/mojo# cdrwtool -d /dev/sr1 -q using device /dev/sr1 768KB internal buffer setting write speed to 12x Settings for /dev/sr1: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/sr1. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTR L-C to cancel now. Initiating quick disc blank Disc capacity is 274944 blocks (549888KB/537MB) Formatting track Writing UDF structures to disc 7200 (CEST)/-120 -------------------- While writing those structures my system freezes completely and once again I have to resort to power recycling. Surely my system consists of some cheapo hardware, the cdrw device being a Phillips CDD 3610, but I think it ought to work anyway. There are two things I noticed from the output above: 1) that cdrwtool sets the writing speed to 12x by default while my drive is only capable of 2x. I suspect that it should not really matter and that using 12x would just mean that the maximum speed of my drive is being used but nevertheless I might ask: do you think that it might make a difference setting the speed with the "t" parameter..? 2) The disc capacity is being calculated as 537 mb - why..? As for the rest I have followed the install instructions in the readme file meticulously. I have compiled with modules and I have enabled write caching and retained the default of 256 kb of data gathering buffer. I got the UDF cvs tree and compiled and installed the udf module. Prior to this I bumped up my kernel version to 2.4.4-pre6 and rebooted. Regards, Morten -- "It is characteristic of the present time always to be conscious of the medium. It is almost bound to end in madness, like a man who whenever he looked at the sun and the stars was conscious of the world going round." (Kierkegaard)
On Mon, Apr 23 2001, Morten Bo Johansen wrote:
Yesterday with pre2 I had dire problems, so many that I gave up on making a proper bug report but basically it freaked out completely with scsi host resetting errors and kernel panic messages that took control over my tty + kbd when I tried to do the formatting part - and I was not able to log anything either. Eventually I had to push the big button.
Ugh
I tried again today with pre3 and still I don't get past the formatting hurdle. Here's what happens when I try to format a disc:
--------------------
root@olafrye:/home/mojo# cdrwtool -d /dev/sr1 -q using device /dev/sr1 768KB internal buffer setting write speed to 12x Settings for /dev/sr1: Fixed packets, size 32 Mode-2 disc
I'm going to do a quick setup of /dev/sr1. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTR L-C to cancel now.
Initiating quick disc blank Disc capacity is 274944 blocks (549888KB/537MB) Formatting track
Writing UDF structures to disc 7200 (CEST)/-120
--------------------
While writing those structures my system freezes completely and once again I have to resort to power recycling.
Very strange. What happens here is that cdrwtool writes out 64kB packets with the UDF data structures, so it should be a relatively painless operation. I'm very curious as to why this would hang the system.. Any chances of setting up a serial console and capturing kernel messages??
Surely my system consists of some cheapo hardware, the cdrw device being a Phillips CDD 3610, but I think it ought to work anyway.
Yes it should
There are two things I noticed from the output above:
1) that cdrwtool sets the writing speed to 12x by default while my drive is only capable of 2x. I suspect that it should not really matter and that using 12x would just mean that the maximum speed of my drive is being used but nevertheless I might ask: do you think that it might make a difference setting the speed with the "t" parameter..?
Nope, the 12 is just a random "high" number so that the speed isn't set too low. It prints 12 because cdrwtool doesn't do the usual - set high speed - read back current speed from drive - print speed because I was lazy when I wrote it.
2) The disc capacity is being calculated as 537 mb - why..?
Because that's the capacity :-). Fixed packet cd-rw writing does waste some space on the media, ~540 meg is about right.
As for the rest I have followed the install instructions in the readme file meticulously. I have compiled with modules and I have enabled write caching and retained the default of 256 kb of data gathering buffer. I got the UDF cvs tree and compiled and installed the udf module. Prior to this I bumped up my kernel version to 2.4.4-pre6 and rebooted.
Write caching is a no-no, but it has no effect when you do the above cdrwtool command. It sounds like you did it right, and I'd love for you to setup some sort of serial logger and grab some kernel messages. Alternatively, stay in the console and stop syslog and see if it prints anything before going down. -- Jens Axboe
On Mon, Apr 23 2001, Morten Bo Johansen wrote:
Jens Axboe
wrote: .. Any chances of setting up a serial console and capturing kernel messages??
Sure, just tell me how to do it...;-)
Ok, no problem. You need a null modem serial cable, and a second machine with some sort of terminal program running (minicom, for example). First start by attaching the cable and testing a direct connection between two minicom's for instance, one on each end. Once this is working, you need to read Documentation/serial-console.txt. Basically it's pretty easy -- on the machine you are doing pktcdvd testing on, include something ala append="console=ttyS0,38400 console=tty0" in your /etc/lilo.conf, reboot, and that's it. Substitute your selected serial device for ttyS0, the baud rate is probably fine. You probably also want to stop syslog once the machine has booted. -- Jens Axboe
Jens Axboe
Ok, no problem. You need a null modem serial cable, and a second machine with some sort of terminal program running (minicom, for example). First start by attaching the cable and testing a direct connection between two minicom's for instance, one on each end.
To the best of my ability I have followed your instructions as well as those in serial-console.txt, I have: - compiled kernel with CONFIG_SERIAL_CONSOLE=y - included S1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 in /etc/inittab - console=ttyS1,9600 console=tty0 as lilo append parameter - made sure that proper character devices exist - connected two computers with null modem cable - minicom is running on remote with 9600 8N1 and VT102 - removed /etc/ioctl.save as stated in serial-console.txt During the boot process of the local computer something is logged to the remote minicom screen but the characters are unintelligble, something like )+oE++#B.1.*c=+.. etc. Starting minicom on the local end with the same port settings as the remote, and typing something those typings are echoed on the remote but again the characters are misrepresented as yyyy... etc.. What am I missing? Regards, Morten
On Tue, Apr 24 2001, Morten Bo Johansen wrote:
Ok, no problem. You need a null modem serial cable, and a second machine with some sort of terminal program running (minicom, for example). First start by attaching the cable and testing a direct connection between two minicom's for instance, one on each end.
To the best of my ability I have followed your instructions as well as those in serial-console.txt, I have:
- compiled kernel with CONFIG_SERIAL_CONSOLE=y - included S1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 in /etc/inittab - console=ttyS1,9600 console=tty0 as lilo append parameter - made sure that proper character devices exist - connected two computers with null modem cable - minicom is running on remote with 9600 8N1 and VT102 - removed /etc/ioctl.save as stated in serial-console.txt
During the boot process of the local computer something is logged to the remote minicom screen but the characters are unintelligble, something like )+oE++#B.1.*c=+.. etc.
Starting minicom on the local end with the same port settings as the remote, and typing something those typings are echoed on the remote but again the characters are misrepresented as yyyy... etc..
What am I missing?
No, it looks like you have anything setup alright. I'd suspect the cable if I were you, are you sure it's a null modem cable? -- Jens Axboe
Jens Axboe
No, it looks like you have anything setup alright. I'd suspect the cable if I were you, are you sure it's a null modem cable?
That's what I bought it to be originally - but I never got to use it before now so I am not altogether sure that it is wired correctly. Even if it is maybe going a little to far persevering with this subject here I am laying out the wiring below in case you or anyone else might tell me if it is okay or not: Two 25 pin female connectors (C1 & C2) Pin # color/wire C1: C2: 1 brown brown 2 red orange 3 orange red 4 yellow green 5 green yellow 6 - - 7 blue blue 8 lilac black 9 - - 10 - - 11 - - 12 - - 13 - - 14 grey - 15------ ----- | wire thickish | 16 | + red | | | 17------ white ----- grey 18 - - 19 - - 20 black lilac 21 - - 22 - - 23 - - 24 - white 25 - With regards to pin 15+17 it means that C1 & C2 are jumpered with a thickish red wire and that pin 17 has an additional white respectively grey wire going to it. This layout is somehwat different from the diagram over a null modem cable found at http://sunsite.dk/hwb/ - but pins 2-5 are indeed crossed over and isn't that what's essential here? Regards, Morten -- "Education is a method whereby one acquires a higher grade of prejudices." (Laurence J. Peter)
On Mon, 23 Apr 2001, Jens Axboe wrote:
Next pre is up, changes since pre2:
Wow, just copied linux-2.4.3.tar.gz, a whole subdir with movie trailers and at the moment the whole linux subtree with compiled files is copied. And till now its working very nice and smooth, hope this stays like this. Well done Jens!
and it's been merged to 2.4.4-pre6. I'll hang on for final 0.0.2i until 2.4.4 is really released.
I had a .rej from your patch because I fixed the problems with the __expect_? with the rwsem.patch from lkml. Th small overlap in rwsem.c is a bit different, but I took the one from rwsem.patch. Best wishes Norbert -- ciao norb +-------------------------------------------------------------------+ | Norbert Preining http://www.logic.at/people/preining | | University of Technology Vienna, Austria preining@logic.at | | DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key | +-------------------------------------------------------------------+
On Mon, Apr 23 2001, Norbert Preining wrote:
On Mon, 23 Apr 2001, Jens Axboe wrote:
Next pre is up, changes since pre2:
Wow, just copied linux-2.4.3.tar.gz, a whole subdir with movie trailers and at the moment the whole linux subtree with compiled files is copied. And till now its working very nice and smooth, hope this stays like this.
Well done Jens!
Wooo, the first good report this time around :-). Thanks, glad it's working well.
and it's been merged to 2.4.4-pre6. I'll hang on for final 0.0.2i until 2.4.4 is really released.
I had a .rej from your patch because I fixed the problems with the __expect_? with the rwsem.patch from lkml. Th small overlap in rwsem.c is a bit different, but I took the one from rwsem.patch.
I debated whether to leave the __builtin_expected stuff in, but stripped it completely. As long as you have it fixed, all is well. Hopefully the next pre will have this removed, so I don't have to worry about it. -- Jens Axboe
On Mon, 23 Apr 2001, Norbert Preining wrote:
Wow, just copied linux-2.4.3.tar.gz, a whole subdir with movie trailers and at the moment the whole linux subtree with compiled files is copied. And till now its working very nice and smooth, hope this stays like this.
Well, I was too fast! The copying of the linux subtree finally froze my system, sorry Jens, no messages, nothing worked, not even Sysrq. Reset. Best wishes Norbert -- ciao norb +-------------------------------------------------------------------+ | Norbert Preining http://www.logic.at/people/preining | | University of Technology Vienna, Austria preining@logic.at | | DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key | +-------------------------------------------------------------------+
On Mon, Apr 23 2001, Norbert Preining wrote:
On Mon, 23 Apr 2001, Norbert Preining wrote:
Wow, just copied linux-2.4.3.tar.gz, a whole subdir with movie trailers and at the moment the whole linux subtree with compiled files is copied. And till now its working very nice and smooth, hope this stays like this.
Well, I was too fast! The copying of the linux subtree finally froze my system, sorry Jens, no messages, nothing worked, not even Sysrq. Reset.
Oh well, almost there. The serial console message sent to Morten goes for you too. Also, if any of you are using SMP (or UP with io-apic on board), then enabling the nmi_watchdog is very helpful indeed. See Documentation/nmi_watchdog.txt -- Jens Axboe
participants (3)
-
Jens Axboe
-
Morten Bo Johansen
-
Norbert Preining