Older blog entries for Zaitcev (starting at number 407)


I didn't try to burn a CD with ub in a while, because my new laptop comes with a built-in burner. After all the hustling with __blk_end_request, I thought the situation called for a test. This looked worrysome:

Track 01: Total bytes read/written: 548321280/548321280 (267735 sectors).
Errno: 5 (Input/output error), close track/session scsi sendcmd: cmd timeout after 5.000 (480) s
CDB:  5B 00 02 00 00 00 00 00 00 00
cmd finished after 5.000s timeout 480s
cmd finished after 5.000s timeout 480s
wodim: Cannot fixate disk.

The resulting CD was not a coaster though. A welcome surprise, but clearly I did something wrong regarding timeouts, and it needs fixing (although I'm quite sure that there's no other person on Earth who would want to burn CDs with ub).

BTW, the new cdrecord looks nice indeed. Before, I only used the one maintained by that self-centered dude with attitude... No idea who maintains this one, but it seems working ok.

Syndicated 2008-04-07 03:28:25 from Pete Zaitcev

22 Mar 2008 (updated 2 Apr 2008 at 01:08 UTC) »

What Would Rusty Say?

One of the many great things Rusty has done was introducing the Misuse Levels of APIs (in OLS 03 keynote, slide 30 and beyond). I had a run-in with something of that nature last week.

Here's an interface:

 * blk_end_request - Helper function for drivers to complete the request.
 * @rq:       the request being processed
 * @error:    0 for success, < 0 for error
 * @nr_bytes: number of bytes to complete
 * Description:
 *     Ends I/O on a number of bytes attached to @rq.
 *     If @rq has leftover, sets it up for the next range of segments.
 * Return:
 *     0 - we are done with this request
 *     1 - still buffers pending for this request
int blk_end_request(struct request *rq, int error, unsigned int nr_bytes)

What do you think the "number of bytes to complete" is? It seemed natural to me that it's the number of bytes which was transferred (and thus, it can be smaller than the number of bytes remembered in the request). This is how I would design an API. But in this case, nr_bytes is the number of bytes which was in the request initially. As such, it is greater than the request->data_len, which drivers modify to indicate the residue.

I think this has something to do with Tomo's & Jens' desire to avoid modifying drivers which poke ->data_len today (indeed, the code doing so in ub remained unchanged). If so, the price is too steep, IMHO.

Curiously, the designers of the API themselves misused it when they converted ub. They called __blk_end_request() with and argument of blk_rq_bytes(rq), but since ub modifies ->data_len, it guaranteed a failure for packet requests.

Everything seems to be working now, but I suspect that 2.6.25 is going to ship with a broken ub (thank Chris Wright for the Stable Tree).

UPDATE: See also a blog article (same server, but helps if Rusty decides to reshuffle his home directory).

Syndicated 2008-03-22 04:49:37 (Updated 2008-04-02 00:22:24) from Pete Zaitcev

Irony of the day

Seen today:

23015 root      20   0  311m  63m  S  1.0  7.4 148:50.50 Xorg   
23661 zaitcev   20   0  446m 9324  S  1.0  1.1 117:00.18 gnome-power-man

So, the process which is supposed to save my CPU cycles is responsible for consuming almost as much as X server, which does a heck of a lot of work. Isn't it ironic?

I suspect Gnome Power Manager loses its mind when I close the lid overnight.

Syndicated 2008-03-21 05:04:59 from Pete Zaitcev

The LJ dorama

I welcome the deprecation of "free" LJ accounts. I always found it unfair and unsustainable how paying users subsidized unpaid users. As for Brad, being a former honcho gives him some insight points, but not too many. Look at Craig, does he blog about dumb people turning his website into something he does not like?

Syndicated 2008-03-18 23:29:39 from Pete Zaitcev

When release is not

Spent a weekend on a bug which looked like some interesting race, but in fact was just a simple logic error. Result is a trivial one line patch, I'm two days older and not an iota smarter.

BTW, our input subsystem is really convoluted. I'm not surprised bugs like this happen.

Syndicated 2008-03-18 07:33:00 from Pete Zaitcev


A minute ago I pulled a mouse out of my laptop and the X server crashed. The last messages in Xorg.0.log were:

(EE) Read error: No such device (19, -1 != 24)
(II) Microsoft Microsoft USB Wireless Mouse: Off

This happened because Xorg server force-loads evdev contrary to my xorg.conf, and we all know that evdev is a crash city.

It's a good thing I was born and raised back when this sort of thing was expected every day, so X cannot catch me with a half-entered bug report in a browser. Also, it seems that Vim finally learned to remove dead .swp files without annoying users.

Syndicated 2008-03-06 01:15:23 from Pete Zaitcev

12 Feb 2008 (updated 13 Feb 2008 at 05:07 UTC) »

GNOME does something right

Today I plugged my iPod in, and Rawhide launched Rhythmbox, which chugged along for about half a minute, then crashed. At least it did not wipe the player's database. WTF, I thought I had all auto-run types set to off...

Looks like there were some changes. No more unchecking umpteenth type of crashware.

To compensate for a good thing, they worked extra hard to hide this panel. It's not reacheable from any parts of System menu. File Browser has to be started, and its Preferences adjusted.

UPDATE: The last part is untrue, I missed the right item. Thanks ucc_journal for the correction.

Syndicated 2008-02-12 21:24:21 (Updated 2008-02-13 04:40:52) from Pete Zaitcev

GNOME lies to me

Every time I log in, it promises not to show the message again, but then does.

I suppose I should clean some keys in gconf-editor, but which?

Also, tinkering with the registry is so Windows.

Syndicated 2008-02-08 17:40:53 from Pete Zaitcev

3 Feb 2008 (updated 4 Feb 2008 at 21:07 UTC) »

Centralized git at Xorg

One side effect of the multiply-repo organization of Xorg is that I cannot clone a local repository without editing git_xorg.sh. In kernel, I usually have just one repository which tracks Linus (linux-2.6), then clone and blow away repositories as needed (linux-2.6-ub, linux-2.6.24-rc7, linux-2.6.23-253424). In X, git_xorg.sh has a variable on top which encodes the parent, which is not so bad. But still... Obviously they just do it differently, but how? Keith was saying something about extensive use of branches, so maybe that's it.

Also, since we're on topic, git_xorg.sh itself is not in the git. Now that's really odd, because how do I know if it's changed? I don't even remember now whence I downloaded it.

P.S. Another thing, before blowing away a repo, I would look quickly with "git diff" if anything interesting was left in it. Needless to say, this is impossible in Xorg, so it's just more evidence that they never clone anything.

Syndicated 2008-02-03 19:14:15 (Updated 2008-02-04 20:25:57) from Pete Zaitcev

30 Jan 2008 (updated 30 Jan 2008 at 19:08 UTC) »

Have libsilc problem?

On one box, every run of yum update was complaining about something unavailable around libsilc... I wrote it down to mirror inconsistency and worked around with --exclude. Today I decided to look into it closer, and saw the following:

  [root@simbelmyne zaitcev]# rpm -q pidgin fedora-release
[root@simbelmyne zaitcev]# yum update pidgin
Setting up Update Process
Could not find update match for pidgin
No Packages marked for Update
[root@simbelmyne zaitcev]# 

An F7 package has no update when we're builing F9? [*]

  [root@simbelmyne zaitcev]# rpm -q --queryformat "%{epoch}\\n" pidgin
[root@simbelmyne zaitcev]# 

Suddenly the problem came into focus. The worst part of it, current pidgin is version 2.3.1, which is greater than 2.0.0. They could've kept epoch forever and nobody would've noticed... The changelog explains:

  * Sat Apr 21 2007 Warren Togami <wtogami@redhat.com> 2.0.0-0.35.beta7devel
- upstream insists that we remove the Epoch
  rawhide users might need to use --oldpackage once to upgrade
- remove mono and howl cruft

* Wed Jul 12 2006 Jesse Keating <jkeating@redhat.com> 2:2.0.0-0.6.beta3.1
- rebuild

Hmm... Not sure why "upstream" cares, but whatever.

Just for fun I ran rpm|grep|wc and found a ton of packages with non-empty Epoch. Epoch 0: 108 packages, Epoch 1: 79, other values: 52. The biggest number has aspell-en: Epoch 50! The changelog is:

  * Wed Aug 11 2004 Adrian Havill <havill@redhat.com> 50:0.51-9
- sync epoch with other aspell dicts, upgrade to 0.51-1

Now that must be a pretty funny story, but I don't want to know.

[*] Actually we have a few packages from F7 which weren't rebuilt across the whole Fedora 8 cycle, for example grep.

Syndicated 2008-01-30 06:06:18 (Updated 2008-01-30 19:01:57) from Pete Zaitcev

398 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!