i8042 problem
Hi, Vojtech:
On my old laptop, i8042 refuses to work with 2.6.0-test1-bk2. After a reboot, keyboard is dead. Hooking external keyboard revives the internal keyboard. Here's the dmesg with DEBUG:
Linux version 2.6.0-test1-bk2 (zaitcev@niphredil) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #6 Fri Jul 25 20:28:14 PDT 2003
...
Kernel command line: ro root=/dev/hda1 vga=0x0f05 console=ttyS0,38400
...
hda: 2822400 sectors (1445 MB) w/96KiB Cache, CHS=2800/16/63
hda: hda1 hda2 hda3drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]drivers/input/serio/i8042.c: 45 <- i8042 (return) [0]drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [1]drivers/input/serio/i8042.c: d3 -> i8042 (command) [2]drivers/input/serio/i8042.c: f0 -> i8042 (parameter) [2]drivers/input/serio/i8042.c: 0f <- i8042 (return) [2]drivers/input/serio/i8042.c: d3 -> i8042 (command) [2]drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [2]drivers/input/serio/i8042.c: a9 <- i8042 (return) [2]drivers/input/serio/i8042.c: d3 -> i8042 (command) [3]drivers/input/serio/i8042.c: a4 -> i8042 (parameter) [3]drivers/input/serio/i8042.c: 5b <- i8042 (return) [3]drivers/input/serio/i8042.c: d3 -> i8042 (command) [4]drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [4]drivers/input/serio/i8042.c: a5 <- i8042 (return) [4]drivers/input/serio/i8042.c: a7 -> i8042 (command) [4]drivers/input/serio/i8042.c: 20 -> i8042 (command) [5]drivers/input/serio/i8042.c: 74 <- i8042 (return) [5]drivers/input/serio/i8042.c: a8 -> i8042 (command) [5]drivers/input/serio/i8042.c: 20 -> i8042 (command) [5]drivers/input/serio/i8042.c: 54 <- i8042 (return) [5]drivers/input/serio/i8042.c: 60 -> i8042 (command) [6]drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [6]drivers/input/serio/i8042.c: 60 -> i8042 (command) [6]drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [6]drivers/input/serio/i8042.c: 60 -> i8042 (command) [8]drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [8]drivers/input/serio/i8042.c: d4 -> i8042 (command) [8]drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [8]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [11]drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [13]drivers/input/serio/i8042.c: 60 -> i8042 (command) [13]drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [13]
serio: i8042 AUX port at 0x60,0x64 irq 12drivers/input/serio/i8042.c: 60 -> i8042 (command) [26]drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [26]drivers/input/serio/i8042.c: 60 -> i8042 (command) [28]drivers/input/serio/i8042.c: 45 -> i8042 (parameter) [28]drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [28]drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [38]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [40]drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
serio: i8042 KBD port at 0x60,0x64 irq 1
NET4: Linux TCP/IP 1.0 for NET4.0
<------------- This is it, keyboard is dead.
.......
V---- Trying to hook external keyboard nowdrivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 0) [109588]drivers/input/serio/i8042.c: 60 -> i8042 (command) [109613]drivers/input/serio/i8042.c: 45 -> i8042 (parameter) [109613]drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [109614]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109619]drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 1) [109639]drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109660]drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [109680]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109687]drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [109708]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109714]drivers/input/serio/i8042.c: f8 -> i8042 (kbd-data) [109735]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109742]drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [109763]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109770]drivers/input/serio/i8042.c: f0 -> i8042 (kbd-data) [109790]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109797]drivers/input/serio/i8042.c: 02 -> i8042 (kbd-data) [109818]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109825]drivers/input/serio/i8042.c: f0 -> i8042 (kbd-data) [109846]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109852]drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [109873]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109879]drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109900]drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109921]atkbd.c: Unknown key (set 0, scancode 0x2, on isa0060/serio0) pressed.
input: AT Set 2 keyboard on isa0060/serio0
<----- Now we are talking!
Any ideas?
-- Pete
Quoted 9 lines · Pete Zaitcev
On my old laptop, i8042 refuses to work with 2.6.0-test1-bk2. After a reboot, keyboard is dead. Hooking external keyboard revives the internal keyboard. Here's the dmesg with DEBUG:
drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
serio: i8042 KBD port at 0x60,0x64 irq 1
<------------- This is it, keyboard is dead.
Writing 44 to the command byte disables IRQ1. (Otherwise the only remarkable part was that no reaction came to f2 - identify keyboard.)
Quoted 10 lines
V---- Trying to hook external keyboard now
drivers/input/serio/i8042.c: f0 -> i8042 (kbd-data) [109846]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109852]drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [109873]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109879]drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109900]drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109921]atkbd.c: Unknown key (set 0, scancode0x2, on isa0060/serio0) pressed.
input: AT Set 2 keyboard on isa0060/serio0
<----- Now we are talking!
Funny. Looks like the "read scancode set" command got the scancode set twice, and the second time was seen as unknown key.
Quoted 9 lines
Quoted 6 lines
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
serio: i8042 KBD port at 0x60,0x64 irq 1
<------------- This is it, keyboard is dead.Writing 44 to the command byte disables IRQ1.
It looks like a timeout problem. The ack (fa) arrived 11 ticks after the byte (00) was sent, but it looks like the timeout is only 10 ticks.
Try playing with the timeout in atkbd_sendbyte (line 217 of drivers/input/keyboard/atkbd.c).
Quoted 9 lines
Quoted 5 lines
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109900]drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109921]atkbd.c: Unknown key (set 0, scancode0x2, on isa0060/serio0) pressed.
input: AT Set 2 keyboard on isa0060/serio0
<----- Now we are talking!Funny. Looks like the "read scancode set" command got the scancode set twice, and the second time was seen as unknown key.
Both keyboards responded to the command, perhaps???
I'd suggest that we don't even ask the keyboard what scancode set it is using if we are attempting to use set 2.
Chris
Quoted 10 lines
Date: Sat, 26 Jul 2003 21:41:32 -0400
From: Chris Heath <[email protected]>Quoted 7 lines
Quoted 6 lines
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
serio: i8042 KBD port at 0x60,0x64 irq 1
<------------- This is it, keyboard is dead.
Quoted 7 lines
Quoted 1 line
Writing 44 to the command byte disables IRQ1.
It looks like a timeout problem. The ack (fa) arrived 11 ticks after the byte (00) was sent, but it looks like the timeout is only 10 ticks.
Try playing with the timeout in
atkbd_sendbyte(line 217 ofdrivers/input/keyboard/atkbd.c).
Playing with timeout does not help, but on second thought I suspect that atkbd fails to open the port for some reason, that's why interrupts stay disabled.
-- Pete
Quoted 15 lines · Pete Zaitcev
Quoted 15 lines
Date: Sat, 26 Jul 2003 21:41:32 -0400
From: Chris Heath <[email protected]>Quoted 8 lines
Quoted 6 lines
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
serio: i8042 KBD port at 0x60,0x64 irq 1
<------------- This is it, keyboard is dead.Writing 44 to the command byte disables IRQ1.
It looks like a timeout problem. The ack (fa) arrived 11 ticks after the byte (00) was sent, but it looks like the timeout is only 10 ticks.
Quoted 6 lines
Quoted 2 lines
Try playing with the timeout in
atkbd_sendbyte(line 217 ofdrivers/input/keyboard/atkbd.c).Playing with timeout does not help, but on second thought I suspect that atkbd fails to open the port for some reason, that's why interrupts stay disabled.
Well, Chris is right, of course.
As I said, writing 44 to the command byte disables IRQ1. So, the question is, who does that. Read the code:
We do i8042_init, detect a PS/2 keyboard/mouse controller, and call i8042_port_register() first for mouse, then for keyboard. This i8042_port_register() does
serio_register_port(port); and then happily reports printk(KERN_INFO "serio: i8042 %s port at %#lx,%#lx irq %d\n"
This serio_register_port(port) probes connected devices. It calls atkbd_connect(), which calls atkbd_probe(), and the latter fails.
Now atkbd_connect() does serio_close() which does i8042_close() and we see
i8042_ctr &= ~values->irqen; i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR);
that the IRQ is disabled.
So the culprit is the failing of atkbd_probe().
It does a ATKBD_CMD_GETID, but gets no answer, then a ATKBD_CMD_SETLEDS, and that command fails.
It sends the 0xed, gets an ACK, sends the 0x00 and times out.
And it times out because atkbd_sendbyte has a timeout of 10 msec while the reply came after 11 msec.
So, apart from other things you might try, it seems to me that changing the timeout in atkbd_sendbyte from the 10000 that is there to the 100000 that the comment implies, should help.
Andries
- int timeout = 10000; /* 100 msec */
+ int timeout = 100000; /* 100 msec */
Quoted 6 lines
Date: Sun, 27 Jul 2003 12:47:26 +0200
From: Andries Brouwer <[email protected]>So the culprit is the failing of
atkbd_probe(). It does aATKBD_CMD_GETID, but gets no answer, then aATKBD_CMD_SETLEDS, and that command fails.
I see the light now. Somehow I imagined that atkbd code does not call the ->open for the port. Now it all falls into place. Everything works with a bigger timeout.
Thanks a lot, Andries & Chris!
-- Pete
drivers/input/keyboard/atkbd.c +1 -1
@@ -214,7 +214,7 @@static int atkbd_sendbyte (struct atkbd *atkbd,unsigned char byte) { -int timeout =10000 ;/* 100 msec */ +int timeout =20000 ;/* 200 msec */ atkbd->ack =0 ;#ifdef ATKBD_DEBUG
Quoted 10 lines · Pete Zaitcev
Quoted 6 lines
Date: Sun, 27 Jul 2003 12:47:26 +0200
From: Andries Brouwer <[email protected]>So the culprit is the failing of
atkbd_probe(). It does aATKBD_CMD_GETID, but gets no answer, then aATKBD_CMD_SETLEDS, and that command fails.I see the light now. Somehow I imagined that atkbd code does not call the ->open for the port. Now it all falls into place. Everything works with a bigger timeout.
Unfortunately with this change several people still report failures
Quoted 8 lines · Alan Cox
Quoted 7 lines · Pete Zaitcev
Quoted 6 lines
Date: Sun, 27 Jul 2003 12:47:26 +0200
From: Andries Brouwer <[email protected]>So the culprit is the failing of
atkbd_probe(). It does aATKBD_CMD_GETID, but gets no answer, then aATKBD_CMD_SETLEDS, and that command fails.
Quoted 5 lines
Quoted 3 lines
I see the light now. Somehow I imagined that atkbd code does not call the ->open for the port. Now it all falls into place. Everything works with a bigger timeout.
Unfortunately with this change several people still report failures
Ach. One bug fixed and the Linux kernel is still not perfect? What a pity.
[But yes, as I also said to someone else: on i386 one has a working keyboard after bootup. No initialization and no probing required. The new keyboard code uses a lot of knowledge about common keyboards and keyboard controllers. It works in most cases. But already the linux-kernel readers see a long stream of problems. I am afraid of the effect on a million Linux users.]
[[On the other hand, as I wrote somewhere else, this is a great way to learn a lot about very obscure keyboards.]]
Quoted 12 lines · Andries Brouwer
Quoted 7 lines · Alan Cox
Quoted 4 lines · Pete Zaitcev
I see the light now. Somehow I imagined that atkbd code does not call the ->open for the port. Now it all falls into place. Everything works with a bigger timeout.
Unfortunately with this change several people still report failures
Ach. One bug fixed and the Linux kernel is still not perfect? What a pity.
Quoted 6 lines
[But yes, as I also said to someone else: on i386 one has a working keyboard after bootup. No initialization and no probing required. The new keyboard code uses a lot of knowledge about common keyboards and keyboard controllers. It works in most cases. But already the linux-kernel readers see a long stream of problems. I am afraid of the effect on a million Linux users.]
Well, are timeouts needed at all, except for a single initial command to
see if a device is there? I would imagine the keyboard to be initialized using an interrupt-driven state machine.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 1 line · Maciej W. Rozycki
Well, are timeouts needed at all?
Yes. We send a command to the keyboard. It may react, or it may not.
Quoted 3 lines · Andries Brouwer
Quoted 1 line
Well, are timeouts needed at all?
Yes. We send a command to the keyboard. It may react, or it may not.
But we need not wait for that actively. If we are unsure about a result
of a command, then we may send a command in question followed with an echo request. This assures an IRQ will finally arrive and if no command response arrives before an echo response, then the keyboard ignored the command. I used this approach many years ago to differ between PS/2 keyboards (which respond with 0xfa,0xab,0x83 to a request for ID) and genuine PC/AT ones (which respond with lone 0xfa). It worked.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 6 lines · Maciej W. Rozycki
Quoted 3 lines · Andries Brouwer
Quoted 1 line
Well, are timeouts needed at all?
Yes. We send a command to the keyboard. It may react, or it may not.
Quoted 7 lines
But we need not wait for that actively. If we are unsure about a result
of a command, then we may send a command in question followed with an echo request. This assures an IRQ will finally arrive and if no command response arrives before an echo response, then the keyboard ignored the command. I used this approach many years ago to differ between PS/2 keyboards (which respond with 0xfa,0xab,0x83 to a request for ID) and genuine PC/AT ones (which respond with lone0xfa). It worked.
And what did you do for XT? :-)
Quoted 12 lines · Andries Brouwer
Quoted 11 lines
Quoted 3 lines
Quoted 1 line
Well, are timeouts needed at all?
Yes. We send a command to the keyboard. It may react, or it may not.
But we need not wait for that actively. If we are unsure about a result
of a command, then we may send a command in question followed with an echo request. This assures an IRQ will finally arrive and if no command response arrives before an echo response, then the keyboard ignored the command. I used this approach many years ago to differ between PS/2 keyboards (which respond with 0xfa,0xab,0x83 to a request for ID) and genuine PC/AT ones (which respond with lone0xfa). It worked.
Quoted 1 line
And what did you do for XT? :-)
Nice joke, but I'll answer seriously. No support was provided. Hooking
a PC/XT keyboard to the 8042, if supported, requires a different setup of the command byte and is possibly done by the system firmware. You can read the command byte to see which configuration is used.
Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
choice as you have to do keyboard detection in the IRQ handler anyway to properly support hot plugging of a PC/AT or a PS/2 keyboard.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 8 lines · Maciej W. Rozycki
Nice joke, but I'll answer seriously. No support was provided. Hooking
a PC/XT keyboard to the 8042, if supported, requires a different setup of the command byte and is possibly done by the system firmware. You can read the command byte to see which configuration is used.Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
choice as you have to do keyboard detection in the IRQ handler anyway to properly support hot plugging of a PC/AT or a PS/2 keyboard.
The only problem there is that it results in a damn complex state machine. Look at the PS/2 mouse probing and imagine how the state machine would look.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 7 lines · Vojtech Pavlik
Quoted 3 lines
Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
choice as you have to do keyboard detection in the IRQ handler anyway to properly support hot plugging of a PC/AT or a PS/2 keyboard.The only problem there is that it results in a damn complex state machine. Look at the PS/2 mouse probing and imagine how the state machine would look.
Well, I don't think a complex state machine is needed. What's the
variable part of the initialization? Essentially the keyboard type (two options available) and the scancode mode selected (three options available). Everything else is constant. So besides the current initialization step, you only need to record these two variables. And the good news is the more complicated setup scenarios are simply a superset of the simpler ones, so you do not have multiple paths in the initialization -- there's only one, of which parts are skipped, depending on the configuration. Specifically, for a PC/AT keyboard you don't select a scancode mode and for the PS/2 keyboard you don't set up key up/down/repeat characteristics in modes #1 and #2.
Still if you go beyond the standard PC/XT compatibility mode, you need to
handle run-time keyboard switching, i.e. if I boot with a PS/2 keyboard, unplug it and later use a PC/AT one, it should just work. I have a similar problem with the LK201 keyboard driver (that's a standard DEC keyboard implementation for a lot of their systems). There are different keyboards having the same interface as the LK201 -- programming them is the same, but their features differ, including the interpretation of some keys and LEDs (the number of LEDs varies from 2 to 4 and they may have different labels). For 2.4, the driver does a reasonable job of run-time configuration, but it may still be improved (e.g. it doesn't yet do a handshake I'm thinking of; unfortunately not all LK201 commands return an ACK) and I'm planning to do that for 2.6. While looking at it, I may look at the PS/2 driver and see how it can be improved.
Maciej
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 7 lines
From: Alan Cox <[email protected]>
Date: 28 Jul 2003 12:25:05 +0100Quoted 4 lines
Quoted 3 lines
So the culprit is the failing of
atkbd_probe(). It does aATKBD_CMD_GETID, but gets no answer, then aATKBD_CMD_SETLEDS, and that command fails.
Quoted 5 lines
Quoted 3 lines
I see the light now. Somehow I imagined that atkbd code does not call the ->open for the port. Now it all falls into place. Everything works with a bigger timeout.
Unfortunately with this change several people still report failures
I'm afraid it is to be expected. They have to go through the motions of setting DEBUG. Unfortunately, it's not all that simple. Messages scroll up and since the keyboard is dead, they cannot be returned with Shift-PgUp. I used a serial console. I think it's more effort most people are prepared to spend.
-- Pete
Quoted 11 lines · Pete Zaitcev
Quoted 11 lines
From: Alan Cox <[email protected]>
Date: 28 Jul 2003 12:25:05 +0100Quoted 7 lines
Quoted 3 lines
So the culprit is the failing of
atkbd_probe(). It does aATKBD_CMD_GETID, but gets no answer, then aATKBD_CMD_SETLEDS, and that command fails.I see the light now. Somehow I imagined that atkbd code does not call the ->open for the port. Now it all falls into place. Everything works with a bigger timeout.
Quoted 7 lines
Quoted 1 line
Unfortunately with this change several people still report failures
I'm afraid it is to be expected. They have to go through the motions of setting DEBUG. Unfortunately, it's not all that simple. Messages scroll up and since the keyboard is dead, they cannot be returned with Shift-PgUp. I used a serial console. I think it's more effort most people are prepared to spend.
An USB keyboard can be very helpful in that case. Or a remote login.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Review
Quoted 9 lines · Andries Brouwer
So, apart from other things you might try, it seems to me that changing the timeout in
atkbd_sendbytefrom the 10000 that is there to the 100000 that the comment implies, should help.Andries
(quoted diff) +1
-1- int timeout = 10000; /* 100 msec */ + int timeout = 100000; /* 100 msec */
Note that we do udelay(10) in the loop, so with this change you're waiting for a whole second. The timeout might need to be made bigger, but not that much.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 4 lines · Vojtech Pavlik
Review
Quoted 2 lines
(quoted diff) +1
-1- int timeout = 10000; /* 100 msec */ + int timeout = 100000; /* 100 msec */Note that we do udelay(10) in the loop,
Right.
Pete Zaitcev made it 20000 (since he needed 11000). That seems reasonable.