You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Andreas S. <an...@sc...> - 2003-11-13 11:28:21
|
* Andreas Schuldei (an...@sc...) [031111 15:04]: > * Svetoslav Slavtchev (sv...@gm...) [031111 14:09]: > i see it in 2.6, too. i think i even have usb debugging messages > enabled, but one sees only the plugg- and unplugg events, nothing > more or strange, as far as the OS is concerned. now i figured out what was wrong with my setup, and drag and drop works again for me with X's event interface, as described on http://people.debian.org/~warp/evdev/ (which is included in both the debian experimental X and also in the one on www.schuldei.org). one must not have Emulate3Buttons option active, that absorbs the button=ADdepress-event and releases it only together with the button-release-event.=20 this patch (on the above url) also features a fifo which the input.agent uses to alert the Xserver of hotplug events. this means that devices are regrabbed on the fly, without the need of switching to the console and back. there is an issue with the keyboard in that input-agent, though, i guess that is due to the format change in the later 2.6 kernels... you could try if it works properly on your 2.4. |
From: Aivils S. <Aiv...@un...> - 2003-11-13 08:30:17
|
> I'm very happy to have gotten my dual user setup running under ruby, > I'm quite impressed with it. I am still having one problem, though, > which was also present in my Miguel Freitas style setup. When I > switch from X to VGA console on VT0 (from vt7 to vt1, say), or if I > just log out of X on VT0, it disrupts the X display on VT1 (vt17). > That is, the DFP on VT1 reports that its input is out of range. > > Details: VT0 is running on an AGP Radeon VE QY and VT1 is running on > a PCI Radeon VE QY; the kernel is 2.6.0-test9-ruby, with the > keyboard.c change as in CVS and the vt_ioctl.c change as in my > previous email; X is XFree86 4.3.99.15 with the PrefBusID patch > (version 3), which is enabled; I'm running gdm from Fedora Core 1. PrefBusID hide video adapters from xf86. Actualy xf86 see and use one video adapter given by PrefBusID. 1st xf86 schould not touch 2nd. xf86 is crazy like as fox, if that destroy 2nd desktop without access. > Any ideas on how to avoid this? I've tried enabling DEBUG in > XFree86's xf86pciBus.c, to see if logging out of X on VT0 led to some > PCI accesses, but the only PCI access debug statements that were > logged occurred at the startup of X. Is there an easy way for me to > dump the state of the PCI Radeon both before and after the console > switch/X logout? > > One workaround I've thought of is this: X already has the code needed > to restore its display after console switch, so if I had a simple way > to initiate a fake console switch for X on VT1, it should restore the > display. Any suggestions on how to do this? > > Any help would be very appreciated. I also included below a few minor > questions I have. Understanding of PCI handling under xf86 is quite hard. May be You can try second method echo 1 > /proc/bus/pci/hackvideo ? > 1) Why does section 4.3 of the HOWTO suggest using a different symlink > for each instance of X? Things seem to work for me without this, and > I checked that this doesn't fix my problem. That for gamers or wary. To kill xf86 You should know which. > 2) Also, I don't seem to have any trouble with gpm. I have it setup > to use /dev/psaux, and my X instances are using /dev/input/miceX. My > gpm RPM is gpm-1.20.1-38. Troubles under 2.4.XX. 2.6 has almost correct /dev/vc/0 important for gpm > 3) If I understand correctly, the legacy VGA area is only routed to > one video card at a time. If the X on VT1 reroutes the legacy VGA > area from the VT0 AGP card to the VT1 PCI card, behind the back of the > already running X on VT0, won't this cause problems? How does the > kernel VT system handles the legacy VGA area routing? No routes. Motherboard BIOS set up VGA interfce only for one video adapter. Kernel uses memory maped output, set up some VGA registries. Check out linux 1.3 2.0 kernels for understanding. xf86 on start set up VGA registry "graphic mode". To use up to date video adapter features, VIDEO BIOS inside video adapter must be initialized - automatic by Motherboard BIOS during boot for VGA adapter. All secondary cards are uninitialized. To set up secondary video adapters xf86 use "CPU real mode" BIOS calls ("real mode" - same as old best MS-DOS mode) libint10.a . To prevent init of 1st VGA adapter BIOS again after boot, xf86 must know , which is VGA - tech slang word "route". You cannot "unroute" VGA even if You are programming god, who knows, may be You can. Video adapter initializing is very much quite hard because of three type of bus ISA,VLB,PCI. AGP for xf86 looks like PCI. Aivils |
From: Aivils S. <Aiv...@un...> - 2003-11-13 07:11:13
|
> I'm trying out 2.6.0-test9-ruby, and I noticed that XFree86 tries to comes > up on the last used vc (vt06) instead of the first unused vc (vt07). I > think that there is an off by one error in the VT_OPENQRY ioctl and that > the patch below is appropriate. I've included the full text of the > VT_OPENQRY ioctl, since I'm not sure if I understand everything fully. Thank You. Applied. This may reach public CVS after 24 - 480 h. Aivils |
From: Kjetil K. <kj...@kj...> - 2003-11-12 19:22:15
|
On Wednesday 12 November 2003 20:13, hugo vanwoerkom wrote: > Backstreet Ruby took out the "input core support" > and "CONFIG_INPUT_KEYBDEV" from config so you > can't satisfy modprobe and give him a module. Yup, as I said in my debian-user-response, been there, done that, got my t-shirt! :-) Svetoslav suggested I added above hid usbcore to modules.conf, or if you want to do it the Debian Way: /etc/modutils/local Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kj...@kj... web...@sk... ed...@le... Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC |
From: hugo v. <hug...@ca...> - 2003-11-12 19:13:15
|
Hi! For reasons still unclear, after upgrading my 2.4.22 Debian Sarge partition running Bruby and gdm, HID wants keybdev.o loaded. Modprobe -c shows indeed a dependency. But because that module is absent from a Backstreet Ruby kernel, he is never going to find it... I can get around it by starting a script with an insmod of hid.o, before gpm or gdm get started, but that isn't right of course. Backstreet Ruby took out the "input core support" and "CONFIG_INPUT_KEYBDEV" from config so you can't satisfy modprobe and give him a module. I am trying to find out where modprobe finds that dependency. Hugo. The following signature is automatically added by the web email service I use, which is beyond my control: ======================================= Help the planet each day! It's free and easy: http://www.Care2.com/dailyaction/ |
From: Wayne W. <wh...@Ma...> - 2003-11-12 06:21:35
|
Hello, I'm very happy to have gotten my dual user setup running under ruby, I'm quite impressed with it. I am still having one problem, though, which was also present in my Miguel Freitas style setup. When I switch from X to VGA console on VT0 (from vt7 to vt1, say), or if I just log out of X on VT0, it disrupts the X display on VT1 (vt17). That is, the DFP on VT1 reports that its input is out of range. Details: VT0 is running on an AGP Radeon VE QY and VT1 is running on a PCI Radeon VE QY; the kernel is 2.6.0-test9-ruby, with the keyboard.c change as in CVS and the vt_ioctl.c change as in my previous email; X is XFree86 4.3.99.15 with the PrefBusID patch (version 3), which is enabled; I'm running gdm from Fedora Core 1. Any ideas on how to avoid this? I've tried enabling DEBUG in XFree86's xf86pciBus.c, to see if logging out of X on VT0 led to some PCI accesses, but the only PCI access debug statements that were logged occurred at the startup of X. Is there an easy way for me to dump the state of the PCI Radeon both before and after the console switch/X logout? One workaround I've thought of is this: X already has the code needed to restore its display after console switch, so if I had a simple way to initiate a fake console switch for X on VT1, it should restore the display. Any suggestions on how to do this? Any help would be very appreciated. I also included below a few minor questions I have. Thanks, Wayne 1) Why does section 4.3 of the HOWTO suggest using a different symlink for each instance of X? Things seem to work for me without this, and I checked that this doesn't fix my problem. 2) Also, I don't seem to have any trouble with gpm. I have it setup to use /dev/psaux, and my X instances are using /dev/input/miceX. My gpm RPM is gpm-1.20.1-38. 3) If I understand correctly, the legacy VGA area is only routed to one video card at a time. If the X on VT1 reroutes the legacy VGA area from the VT0 AGP card to the VT1 PCI card, behind the back of the already running X on VT0, won't this cause problems? How does the kernel VT system handles the legacy VGA area routing? |
From: Wayne W. <wh...@Ma...> - 2003-11-11 20:52:24
|
Hello, I'm trying out 2.6.0-test9-ruby, and I noticed that XFree86 tries to comes up on the last used vc (vt06) instead of the first unused vc (vt07). I think that there is an off by one error in the VT_OPENQRY ioctl and that the patch below is appropriate. I've included the full text of the VT_OPENQRY ioctl, since I'm not sure if I understand everything fully. Thanks, Wayne --- linux-2.6.0-test9-ruby/drivers/char/vt_ioctl.c~ 2003-10-02 04:25:00.000000000 -0700 +++ linux-2.6.0-test9-ruby/drivers/char/vt_ioctl.c 2003-11-11 12:33:50.000000000 -0800 @@ -1020,21 +1020,21 @@ case VT_OPENQRY: { int j = vc->display_fg->first_vc; for (i = 0; i < vc->display_fg->vc_count; ++i, j++) { struct vc_data *tmp = find_vc(j); if (!tmp || (tmp && !VT_IS_IN_USE(tmp))) break; } - ucval = i < vc->display_fg->vc_count ? (j) : -1; + ucval = i < vc->display_fg->vc_count ? (j+1) : -1; goto setint; } /* * ioctl(fd, VT_ACTIVATE, num) will cause us to switch to vt # num, * unless we attempt to switch to the visible VT, just * to preserve sanity). */ case VT_ACTIVATE: { struct vc_data *tmp; |
From: Andreas S. <an...@sc...> - 2003-11-11 14:02:35
|
* Svetoslav Slavtchev (sv...@gm...) [031111 14:09]: > > On Monday 10 November 2003 09:37, Svetoslav Slavtchev wrote: > > > i'm sure it's between 5m & 10m, > > > > OK. > > > > I tried to connect the primary keyboard to the USB Tangtop device and > > the secondary (which has to be on a long cable) on the PS/2 port, > > recompiled the kernel with atkbd and psmouse as modules, and got it up. > > Unfortunately, it didn't take many minutes before my keyboard, the one > > which was connected right on to the Tangtop with no extension cable, > > locked up. So it is definately not the long cable... :-( > > > > Any other ideas...? > > > > sorry, but no idea :( > > it should be sort of usb problem, were there some strange messages when this > happens ? > hopefully it will be fixed in later 2.4 kernels, a number of usb bugfixes > went in .2.4.23 pre series i see it in 2.6, too. i think i even have usb debugging messages enabled, but one sees only the plugg- and unplugg events, nothing more or strange, as far as the OS is concerned. |
From: Kjetil K. <kj...@kj...> - 2003-11-11 13:24:39
|
On Tuesday 11 November 2003 14:07, Svetoslav Slavtchev wrote: > sorry, but no idea :( OK, that's life. > it should be sort of usb problem, were there some strange messages > when this happens ? > hopefully it will be fixed in later 2.4 kernels, a number of usb > bugfixes went in .2.4.23 pre series OK, good! > what was your mainboard ? Asustek Computer, Inc. A7M266, which a CM8738 sound chip. > my board seems to feeze with test9-bk8+ , but hopefully it > will be fixed for test10/ 2.6.0 Yup! Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kj...@kj... web...@sk... ed...@le... Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC |
From: Svetoslav S. <sv...@gm...> - 2003-11-11 13:07:19
|
> On Monday 10 November 2003 09:37, Svetoslav Slavtchev wrote: > > i'm sure it's between 5m & 10m, > > OK. > > I tried to connect the primary keyboard to the USB Tangtop device and > the secondary (which has to be on a long cable) on the PS/2 port, > recompiled the kernel with atkbd and psmouse as modules, and got it up. > Unfortunately, it didn't take many minutes before my keyboard, the one > which was connected right on to the Tangtop with no extension cable, > locked up. So it is definately not the long cable... :-( > > Any other ideas...? > sorry, but no idea :( it should be sort of usb problem, were there some strange messages when this happens ? hopefully it will be fixed in later 2.4 kernels, a number of usb bugfixes went in .2.4.23 pre series what was your mainboard ? > > it should be out pretty soon, unless Linus decides that 2.6.0 is > > ready :-) > > Yup. And besides, it seems to be Andrew Morton's call now... :-) > > > have you tried passing "acpi=off pci=noacpi" or even disabling acpi > > in the kernel configuration? i had to use it for a long time to get > > my KT400 based mobo up and running > > Yep, didn't work... :( my board seems to feeze with test9-bk8+ , but hopefully it will be fixed for test10/ 2.6.0 svetljo -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Svetoslav S. <sv...@gm...> - 2003-11-11 12:53:56
|
Hi Aivils, > > could you find something in the oopses i sent you ? > > I use debugging style of 70ies. Cant You apply next patch > and resend to me dmesg? could you resend it as attachment, not inline ? > > No another way to debug it remotely. You only can determine oops > initiator. You might switch off any type of kernel debug. Ok, i assume we should first go for the modular fbcon, built in seems to freeze too early, or should i also send you from built in fbcon ? > Inside one month debugging should be well timed. what do you mean by that ? > Of course printk may destroy console debug. > > > and the bruby fixes : > > > > you hate i2c again :-) > > Applayed. > thanks :-) don't you monitor the temperature of your CPU/ mainboard ? best, svettljo -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Aivils S. <Aiv...@un...> - 2003-11-11 11:55:16
|
> could you find something in the oopses i sent you ? I use debugging style of 70ies. Cant You apply next patch and resend to me dmesg? --- r260t9-no-chg/drivers/video/console/fbcon.c 2003-11-10 22:04:55.000000000 +0200 +++ r260t9/drivers/video/console/fbcon.c 2003-11-10 22:02:28.000000000 +0200 @@ -235,6 +235,7 @@ int __init fb_console_setup(char *this_o { int unit; char *options; + printk("FBCON: fb_console_setup S\n"); if (!this_opt || !*this_opt) return 0; @@ -275,6 +276,7 @@ int __init fb_console_setup(char *this_o } } } + printk("FBCON: fb_console_setup E\n"); return 0; } @@ -522,6 +524,7 @@ static const char *fbcon_startup(struct static int done = 0; int irqres; + printk("FBCON: fbcon_startup S\n"); irqres = 1; /* * If num_registered_fb is zero, this is a call for the dummy part. @@ -665,6 +668,7 @@ static const char *fbcon_startup(struct add_timer(&cursor_timer); } done = 1; + printk("FBCON: fbcon_startup E\n"); return info->fix.id; } @@ -672,6 +676,7 @@ static void fbcon_init(struct vc_data *v { int unit = vc->vc_num; struct fb_info *info; + printk("FBCON: fbcon_init S\n"); /* on which frame buffer will we open this console? */ info = (struct fb_info *)vc->display_fg->data_hook; @@ -681,13 +686,16 @@ static void fbcon_init(struct vc_data *v else fb_display[unit].scrollmode = SCROLL_YREDRAW; fbcon_set_display(vc, init, !init); + printk("FBCON: fbcon_init E\n"); } static void fbcon_deinit(struct vc_data *vc) { struct display *p = &fb_display[vc->vc_num]; + printk("FBCON: fbcon_deinit S\n"); fbcon_free_font(p); + printk("FBCON: fbcon_deinit E\n"); } static __inline__ void updatescrollmode(struct display *p, struct vc_data *vc) @@ -695,6 +703,7 @@ static __inline__ void updatescrollmode( struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; int m; + if (p->scrollmode & __SCROLL_YFIXED) return; if (divides(info->fix.ywrapstep, vc->vc_font.height) && @@ -720,6 +729,7 @@ static void fbcon_set_display(struct vc_ int i, charcnt = 256; struct font_desc *font; + printk("FBCON: fbcon_set_display S\n"); if (!IS_VISIBLE || (info->flags & FBINFO_FLAG_MODULE) || info->fix.type == FB_TYPE_TEXT) logo = 0; @@ -883,6 +893,7 @@ static void fbcon_set_display(struct vc_ softback_top = 0; } } + printk("FBCON: fbcon_set_display E\n"); } @@ -928,6 +939,7 @@ static void fbcon_clear(struct vc_data * struct display *p = &fb_display[vc->vc_num]; u_int y_break; + printk("FBCON: fbcon_clear S\n"); if (!info->fbops->fb_blank && vc->display_fg->vt_blanked) return; @@ -944,6 +956,7 @@ static void fbcon_clear(struct vc_data * width); } else accel_clear(vc, info, real_y(p, sy), sx, height, width); + printk("FBCON: fbcon_clear E\n"); } @@ -952,6 +965,7 @@ static void fbcon_putc(struct vc_data *v struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; struct display *p = &fb_display[vc->vc_num]; + printk("FBCON: S\n"); if (!info->fbops->fb_blank && vc->display_fg->vt_blanked) return; @@ -959,6 +973,7 @@ static void fbcon_putc(struct vc_data *v return; accel_putc(vc, info, c, real_y(p, ypos), xpos); + printk("FBCON: E\n"); } static void fbcon_putcs(struct vc_data *vc, const unsigned short *s, @@ -967,6 +982,7 @@ static void fbcon_putcs(struct vc_data * struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; struct display *p = &fb_display[vc->vc_num]; + printk("FBCON: fbcon_putc S\n"); if (!info->fbops->fb_blank && vc->display_fg->vt_blanked) return; @@ -987,6 +1003,7 @@ static void fbcon_cursor(struct vc_data int y = real_y(p, vc->vc_y); struct fb_cursor cursor; + printk("FBCON: fbcon_cursor S\n"); if (mode & CM_SOFTBACK) { mode &= ~CM_SOFTBACK; if (softback_lines) { @@ -1088,6 +1105,7 @@ static void fbcon_cursor(struct vc_data vbl_cursor_cnt = CURSOR_DRAW_DELAY; break; } + printk("FBCON: fbcon_cursor E\n"); } static int scrollback_phys_max = 0; @@ -1190,6 +1208,7 @@ static void fbcon_redraw_softback(struct unsigned long n; int line = 0; + printk("FBCON: fbcon_redraw_softback S\n"); d = (u16 *) softback_curr; if (d == (u16 *) softback_in) d = (u16 *) vc->vc_origin; @@ -1274,6 +1293,7 @@ static void fbcon_redraw_softback(struct if (s == (u16 *) softback_in) s = (u16 *) vc->vc_origin; } + printk("FBCON: fbcon_redraw_softback E\n"); } static void fbcon_redraw(struct vc_data *vc, struct display *p, @@ -1284,6 +1304,7 @@ static void fbcon_redraw(struct vc_data struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; unsigned short *s = d + offset; + printk("FBCON: fbcon_redraw S\n"); while (count--) { unsigned short *start = s; unsigned short *le = advance_row(s, 1); @@ -1331,6 +1352,7 @@ static void fbcon_redraw(struct vc_data d -= vc->vc_size_row; } } + printk("FBCON: fbcon_redraw E\n"); } static inline void fbcon_softback_note(struct vc_data *vc, int t, @@ -1365,6 +1387,7 @@ static int fbcon_scroll_region(struct vc struct display *p = &fb_display[vc->vc_num]; int scroll_partial = !(p->scrollmode & __SCROLL_YNOPARTIAL); + printk("FBCON: fbcon_scroll_region S\n"); if (!info->fbops->fb_blank && vc->display_fg->vt_blanked) return 0; @@ -1515,6 +1538,7 @@ static int fbcon_scroll_region(struct vc return 1; } } + printk("FBCON: fbcon_scroll_region E\n"); return 0; } @@ -1525,6 +1549,7 @@ static void fbcon_bmove(struct vc_data * struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; struct display *p = &fb_display[vc->vc_num]; + printk("FBCON: fbcon_bmove S\n"); if (!info->fbops->fb_blank && vc->display_fg->vt_blanked) return; @@ -1540,6 +1565,7 @@ static void fbcon_bmove(struct vc_data * */ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, height, width, p->vrows - p->yscroll); + printk("FBCON: fbcon_bmove E\n"); } static void fbcon_bmove_rec(struct vc_data *vc, struct display *p, int sy, int sx, @@ -1548,6 +1574,7 @@ static void fbcon_bmove_rec(struct vc_da struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; u_int b; + printk("FBCON: fbcon_bmove_rec S\n"); if (sy < y_break && sy + height > y_break) { b = y_break - sy; if (dy < sy) { /* Avoid trashing self */ @@ -1581,6 +1608,7 @@ static void fbcon_bmove_rec(struct vc_da } accel_bmove(vc, info, real_y(p, sy), sx, real_y(p, dy), dx, height, width); + printk("FBCON: fbcon_bmove_rec E\n"); } static int fbcon_resize(struct vc_data *vc, unsigned int width, @@ -1593,6 +1621,7 @@ static int fbcon_resize(struct vc_data * int fw = vc->vc_font.width; int fh = vc->vc_font.height; + printk("FBCON: fbcon_resize S\n"); var.xres = width * fw; var.yres = height * fh; x_diff = info->var.xres - var.xres; @@ -1611,6 +1640,7 @@ static int fbcon_resize(struct vc_data * p->vrows = var.yres_virtual/fh; if (var.yres > (fh * (height + 1))) p->vrows -= (var.yres - (fh * height)) / fh; + printk("FBCON: fbcon_resize E\n"); return 0; } @@ -1619,6 +1649,7 @@ static int fbcon_switch(struct vc_data * struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; struct display *p = &fb_display[vc->vc_num]; + printk("FBCON: fbcon_switch S\n"); if (softback_top) { int l = fbcon_softback_size / vc->vc_size_row; if (softback_lines) @@ -1676,6 +1707,7 @@ static int fbcon_switch(struct vc_data * vc->vc_origin + vc->vc_size_row * vc->vc_top, vc->vc_size_row * (vc->vc_bottom - vc->vc_top) / 2); + printk("FBCON: fbcon_switch E\n"); return 0; } return 1; @@ -1687,6 +1719,7 @@ static int fbcon_blank(struct vc_data *v struct fb_info *info = (struct fb_info *)vc->display_fg->data_hook; struct display *p = &fb_display[vc->vc_num]; + printk("FBCON: fbcon_blank S\n"); if (blank < 0) /* Entering graphics mode */ return 0; @@ -1714,6 +1747,7 @@ static int fbcon_blank(struct vc_data *v vc->vc_video_erase_char = oldc; } else update_screen(vc); + printk("FBCON: fbcon_blank E\n"); return 0; } else return fb_blank(info, blank); @@ -1721,10 +1755,12 @@ static int fbcon_blank(struct vc_data *v static void fbcon_free_font(struct display *p) { + printk("FBCON: fbcon_free_font S\n"); if (p->userfont && p->fontdata && (--REFCOUNT(p->fontdata) == 0)) kfree(p->fontdata - FONT_EXTRA_WORDS * sizeof(int)); p->fontdata = NULL; p->userfont = 0; + printk("FBCON: fbcon_free_font E\n"); } static inline int fbcon_get_font(struct vc_data *vc, struct console_font_op *op) @@ -1789,6 +1825,7 @@ static int fbcon_do_set_font(struct vc_d int cnt; char *old_data = NULL; + printk("FBCON: fbcon_do_set_font S\n"); if (!w > 32) { if (userfont && op->op != KD_FONT_OP_COPY) kfree(data - FONT_EXTRA_WORDS * sizeof(int)); @@ -1896,6 +1933,7 @@ static int fbcon_do_set_font(struct vc_d if (old_data && (--REFCOUNT(old_data) == 0)) kfree(old_data - FONT_EXTRA_WORDS * sizeof(int)); + printk("FBCON: fbcon_do_set_font E\n"); return 0; } @@ -2026,6 +2064,7 @@ static inline int fbcon_set_def_font(str static int fbcon_font_op(struct vc_data *vc, struct console_font_op *op) { + printk("FBCON: fbcon_font_op S\n"); switch (op->op) { case KD_FONT_OP_SET: return fbcon_set_font(vc, op); @@ -2054,6 +2093,7 @@ static int fbcon_set_palette(struct vc_d int i, j, k; u8 val; + printk("FBCON:fbcon_set_palette S\n"); if (!vc->vc_can_do_color || (!info->fbops->fb_blank && vc->display_fg->vt_blanked)) return -EINVAL; @@ -2071,6 +2111,7 @@ static int fbcon_set_palette(struct vc_d else palette_cmap.len = 16; palette_cmap.start = 0; + printk("FBCON: fbcon_set_palette E\n"); return fb_set_cmap(&palette_cmap, 1, info); } @@ -2079,6 +2120,7 @@ static u16 *fbcon_screen_pos(struct vc_d unsigned long p; int line; + printk("FBCON: fbcon_screen_pos S\n"); if (!IS_VISIBLE || !softback_lines) return (u16 *) (vc->vc_origin + offset); line = offset / vc->vc_size_row; @@ -2088,6 +2130,7 @@ static u16 *fbcon_screen_pos(struct vc_d p = softback_curr + offset; if (p >= softback_end) p += softback_buf - softback_end; + printk("FBCON: fbcon_screen_pos E\n"); return (u16 *) p; } @@ -2097,6 +2140,7 @@ static unsigned long fbcon_getxy(struct unsigned long ret; int x, y; + printk("FBCON: fbcon_getxy S\n"); if (pos >= vc->vc_origin && pos < vc->vc_scr_end) { unsigned long offset = (pos - vc->vc_origin) / 2; @@ -2127,6 +2171,7 @@ static unsigned long fbcon_getxy(struct *px = x; if (py) *py = y; + printk("FBCON: fbcon_getxy E\n"); return ret; } @@ -2134,6 +2179,7 @@ static unsigned long fbcon_getxy(struct that's why we have to use a separate routine. */ static void fbcon_invert_region(struct vc_data *vc, u16 * p, int cnt) { + printk("FBCON: fbcon_invert_region S\n"); while (cnt--) { u16 a = scr_readw(p); if (!vc->vc_can_do_color) @@ -2150,6 +2196,7 @@ static void fbcon_invert_region(struct v if (p == (u16 *) softback_in) p = (u16 *) vc->vc_origin; } + printk("FBCON: fbcon_invert_region E\n"); } static int fbcon_scroll(struct vc_data *vc, int lines) @@ -2158,6 +2205,7 @@ static int fbcon_scroll(struct vc_data * struct display *p = &fb_display[vc->display_fg->fg_console->vc_num]; int offset, limit, scrollback_old; + printk("FBCON: fbcon_scroll S\n"); if (softback_top) { if (!IS_VISIBLE) return 0; @@ -2236,13 +2284,16 @@ static int fbcon_scroll(struct vc_data * update_var(vc->vc_num, info); if (!scrollback_current) fbcon_cursor(vc, CM_DRAW); + printk("FBCON: fbcon_scroll E\n"); return 0; } static int fbcon_set_origin(struct vc_data *vc) { + printk("FBCON: fbcon_set_origin S\n"); if (softback_lines && !vc->display_fg->vt_blanked) fbcon_scroll(vc, softback_lines); + printk("FBCON: fbcon_set_origin E\n"); return 0; } @@ -2278,6 +2329,7 @@ int fbcon_resize_all(struct fb_info *inf struct vc_data *vc; int i; + printk("FBCON: fbcon_resize_all S\n"); if(!vt) return -ENODEV; @@ -2286,6 +2338,7 @@ int fbcon_resize_all(struct fb_info *inf vc->vc_rows = info->var.yres/vc->vc_font.height; for(i = 0; i < vt->vc_count; i++) vc_resize(vt->vc_cons[i], vc->vc_cols, vc->vc_rows); + printk("FBCON: fbcon_resize_all E\n"); return 0; } @@ -2295,6 +2348,7 @@ int fbcon_add(int unit, int vc_count) struct vt_struct *vt; struct vc_data *vc; + printk("FBCON: fbcon_add S\n"); vt = (struct vt_struct *) kmalloc(sizeof(struct vt_struct),GFP_KERNEL); if (!vt) return -ENOMEM; @@ -2325,6 +2379,7 @@ int fbcon_add(int unit, int vc_count) vt->default_mode->vc_cols, vt->default_mode->vc_rows, vt->first_vc + 1, vt->first_vc + vt->vc_count); + printk("FBCON: fbcon_add E\n"); return 0; } @@ -2332,6 +2387,7 @@ int __init fb_console_init(void) { int unit; + printk("FBCON: fb_console_init S\n"); if (!num_registered_fb) return -ENODEV; @@ -2349,6 +2405,7 @@ int __init fb_console_init(void) } else fbcon_add(unit, vt2fb[unit]); + printk("FBCON: fb_console_init E\n"); return 0; } --- r260t9/drivers/char/vt.c 2003-10-28 10:08:58.000000000 +0000 +++ r260t9/drivers/char/vt.chg.c 2003-11-11 14:19:36.000000000 +0000 @@ -1088,6 +1088,11 @@ int vc_resize(struct vc_data *vc, unsign video_size_row = new_row_size; screenbuf_size = ss; + printk("VC_RES: new rows:%d cols:%d size:%d ss:%d\n", + new_rows, new_cols, new_row_size, ss); + printk("VC_RES: font widht:%d height:%d\n", + vc->vc_font.width, vc->vc_font.height); + err = resize_screen(vc, new_cols * vc->vc_font.width, new_rows * vc->vc_font.height); if (err) { resize_screen(vc, old_cols * vc->vc_font.width, old_rows * vc->vc_font.height); No another way to debug it remotely. You only can determine oops initiator. You might switch off any type of kernel debug. Inside one month debugging should be well timed. Of course printk may destroy console debug. > and the bruby fixes : > > you hate i2c again :-) Applayed. Aivils |
From: Kjetil K. <kj...@kj...> - 2003-11-11 11:40:12
|
On Monday 10 November 2003 09:37, Svetoslav Slavtchev wrote: > i'm sure it's between 5m & 10m, OK. I tried to connect the primary keyboard to the USB Tangtop device and the secondary (which has to be on a long cable) on the PS/2 port, recompiled the kernel with atkbd and psmouse as modules, and got it up. Unfortunately, it didn't take many minutes before my keyboard, the one which was connected right on to the Tangtop with no extension cable, locked up. So it is definately not the long cable... :-( Any other ideas...? > it should be out pretty soon, unless Linus decides that 2.6.0 is > ready :-) Yup. And besides, it seems to be Andrew Morton's call now... :-) > have you tried passing "acpi=off pci=noacpi" or even disabling acpi > in the kernel configuration? i had to use it for a long time to get > my KT400 based mobo up and running Yep, didn't work... Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kj...@kj... web...@sk... ed...@le... Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC |
From: Svetoslav S. <sv...@gm...> - 2003-11-11 09:24:59
|
Hi Aivils, could you find something in the oopses i sent you ? and the bruby fixes : you hate i2c again :-) AA00_bruby-2.4.22-20030903-fix_i2c_Config.in.patch fix menuconfig AA00_bruby-2.4.22-20030903-fix_input_keyboard_Config.in.patch AA00_bruby-2.4.22-20030903-fix_konicawc.patch AA00_bruby-2.4.22-20030903-fix_sonypi.patch also your patch includes include/linux/modversions.h could you delete it ? best, svetljo PS. it might look like the patches are for older bruby, but they seem to be need on regular basis :-) -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Andreas S. <an...@sc...> - 2003-11-10 15:00:21
|
* Kjetil Kjernsmo (kj...@kj...) [031108 23:27]: > > have you tried ruby with linux-2.6.0-test9 ? > > No, but I did try with, uhm, I think it was test8 (Andreas...?). yes, it was test8. |
From: Svetoslav S. <sv...@gm...> - 2003-11-10 08:38:06
|
> On Friday 07 November 2003 19:13, Svetoslav Slavtchev wrote: > > > isn't there a limitation of the length of usb cables ? > > smth between 5-10 meters ? > > Dunno. But since you mention it, I couldn't find USB cables longer than > 3 meters when I searched for it, and I found cables with amplifiers at > 30 meters. It is reasonable to expect a limit, yeah, but I mean, five > meters...? :-) > > However, I'm pretty sure I saw this problem, before I realized what the > problems was, without the extension cables. > i'm sure it's between 5m & 10m, i had strange issues with Mac OS X & a usb printer, and i had to google a bit, until i found it > > have you tried ruby with linux-2.6.0-test9 ? > > No, but I did try with, uhm, I think it was test8 (Andreas...?). > Couldn't get it booted. Tried a few different things, and also a > non-ruby test9 kernel without success. Seems to die at some APIC > things. Since Linus seems to actually be soliciting the feedback of J. > Random Desktop User in > http://www.oetrends.com/news.php?action=view_record&idnum=277 > I thought I'd wait a few days and give test10 a whirl and tell the > hackers what I found, it should be out pretty soon, unless Linus decides that 2.6.0 is ready :-) have you tried passing "acpi=off pci=noacpi" or even disabling acpi in the kernel configuration? i had to use it for a long time to get my KT400 based mobo up and running svetljo -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Adrian A. <r8k...@ya...> - 2003-11-09 08:48:06
|
Cable TV Subscribers Get Our Cable TV Filter and Stop-Paying For Your Pay-Per-View, Mature Chan= nels, Movie Channels, Sporting Events... Find Out More - http://www.XhenTronic.net?refid=3D10010000858361131 Don't worry, it's perfectly-legal. Check out our legal page - http://cable.xhentronic.com/Legal.asp?rid=3D10= 563 No more advertisments - http://www.XhenTronic.net?unsub=3D100100008583611= 31 j lat |
From: Kjetil K. <kj...@kj...> - 2003-11-08 22:25:17
|
On Friday 07 November 2003 19:13, Svetoslav Slavtchev wrote: > isn't there a limitation of the length of usb cables ? > smth between 5-10 meters ? Dunno. But since you mention it, I couldn't find USB cables longer than 3 meters when I searched for it, and I found cables with amplifiers at 30 meters. It is reasonable to expect a limit, yeah, but I mean, five meters...? :-) However, I'm pretty sure I saw this problem, before I realized what the problems was, without the extension cables. > have you tried ruby with linux-2.6.0-test9 ? No, but I did try with, uhm, I think it was test8 (Andreas...?). Couldn't get it booted. Tried a few different things, and also a non-ruby test9 kernel without success. Seems to die at some APIC things. Since Linus seems to actually be soliciting the feedback of J. Random Desktop User in http://www.oetrends.com/news.php?action=view_record&idnum=277 I thought I'd wait a few days and give test10 a whirl and tell the hackers what I found, Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kj...@kj... web...@sk... ed...@le... Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC |
From: Terrence K. <ro...@ya...> - 2003-11-08 21:57:45
|
Protect Your Children With ProtecTV. ProtecTV gives you the power to block the cursing and offensive language c= oming into your home through television and video. ProtecTV filters out more than 400 offensive words. ProtecTV works with your TV, VCR, Satellite, Cable Box and DVD player. ProtecTV is easy to connect. Get ProtectTV Today - www.bargaindeals.bz Go here if you wish to be excluded from our advertising - www.XhenTronic.n= et?unsub=3D10010000858361131 dovxlr drw tzex fe xtznrtxaznmx sayqej |
From: hugo v. <hug...@ca...> - 2003-11-08 16:50:51
|
Hi! Is this with 2.4.22 and its patch? I cannot recall that I have ever had this, with constant heavy use... Hugo. The following signature is automatically added by the web email service I use, which is beyond my control: ======================================= Help the planet each day! It's free and easy: http://www.Care2.com/dailyaction/ |
From: Svetoslav S. <sv...@gm...> - 2003-11-07 18:28:46
|
> I tried booting ruby-2.6-test9 with the single console patch > and framebuffer console again. > > ruby without the patch hangs as soon as it switch away > >from vga. > > runy with the patch gets further. The framebuffer shows > only garbage, similar to ruby with framebuffer but without > fbcon. (Plain 2.6.0-test9 shows text on the framebuffer > console.) So there are more problems than just the > number of framebuffers on a G550. > > I can't see printk's, but I see from disk lights that > the scsi bus does the usual lengthy initialization. > The kernel hangs shortly after that. I know it hangs > because the keyboards stop reacting to numlock/capslock. > (No LED reaction, and no sysrq either.) thats with tha patch for single fbcon oopses in swapper the shorter is without fbcon=..., the longer with fbcon=vt:toc.8 (i'mdumb, am i not :( ) -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Svetoslav S. <sv...@gm...> - 2003-11-07 18:13:17
|
Hi, > On Friday 07 November 2003 00:22, Andreas Schuldei wrote: > > > this is something that i experience, too. > > Good to hear we're not alone. ;-) > > > i assumed it was my usb hardware which was slighly broken, so i > > looked for ways to work around it. your usb setup doesnt seem to > > be too stable either, perhaps it is the same problem? however, > > here it is mostly the two mice and my keyboard dis- and reappearing. > > Hm, ok, it could be. However, I see no evidence in any logs that it is > actually having problems with loosing contact... What should I look > for? But then, there are quite a lot of cables here; first the normal > cable to a 5m extension cable, which again is connected to the Tangtop, > which is connected to the USB port. If any of those gets displaced, > obviously, it can happen easily. But then, she was just typing > carefully when it happened. isn't there a limitation of the length of usb cables ? smth between 5-10 meters ? > BTW, it happened a second time just after I wrote my post. > > Then, it didn't pour out events, it just sat there. Also, in the first > case, DPMS didn't blank the screen, in the second case it did. > > > the problem with reappearing is that the xserver does not reclaim > > its hw automatically once it was gone. It does that only on > > special events, e.g. when you switch from the console to X. > > OK. > > > the Xserver in debian-experimental is able to regrab its hardware > > with help of the input.agent from > > http://people.debian.org/~warp/evdev/ , since it can react to > > events received from a pipe, which the input.agent writes to. > > > > the drawback with the event interface configuration is that it > > seems to have problems with mouse keypresses (the pressbutton > > event is generated at the same time as the releasebutton event, > > making dragging and marking things under X impossible). > > Ouch, yes, that's rather bad. > > >I still > > want to debug this so this is fully usable. the author of the x > > event interface can not explain this and never saw this > > phenomenon. > > If there is anything I can try, please let me know! > have you tried ruby with linux-2.6.0-test9 ? :-) best, svetljo -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Kjetil K. <kj...@kj...> - 2003-11-07 12:35:10
|
On Friday 07 November 2003 00:22, Andreas Schuldei wrote: > this is something that i experience, too. Good to hear we're not alone. ;-) > i assumed it was my usb hardware which was slighly broken, so i > looked for ways to work around it. your usb setup doesnt seem to > be too stable either, perhaps it is the same problem? however, > here it is mostly the two mice and my keyboard dis- and reappearing. Hm, ok, it could be. However, I see no evidence in any logs that it is actually having problems with loosing contact... What should I look for? But then, there are quite a lot of cables here; first the normal cable to a 5m extension cable, which again is connected to the Tangtop, which is connected to the USB port. If any of those gets displaced, obviously, it can happen easily. But then, she was just typing carefully when it happened. BTW, it happened a second time just after I wrote my post. Then, it didn't pour out events, it just sat there. Also, in the first case, DPMS didn't blank the screen, in the second case it did. > the problem with reappearing is that the xserver does not reclaim > its hw automatically once it was gone. It does that only on > special events, e.g. when you switch from the console to X. OK. > the Xserver in debian-experimental is able to regrab its hardware > with help of the input.agent from > http://people.debian.org/~warp/evdev/ , since it can react to > events received from a pipe, which the input.agent writes to. > > the drawback with the event interface configuration is that it > seems to have problems with mouse keypresses (the pressbutton > event is generated at the same time as the releasebutton event, > making dragging and marking things under X impossible). Ouch, yes, that's rather bad. >I still > want to debug this so this is fully usable. the author of the x > event interface can not explain this and never saw this > phenomenon. If there is anything I can try, please let me know! Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kj...@kj... web...@sk... ed...@le... Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC |
From: Helge H. <hel...@ai...> - 2003-11-07 09:06:22
|
Kjetil Kjernsmo wrote: > > Also, is it some way I can reset the keyboard without rebooting the box? How about unplugging it? Ordinary ps2 keyboards resets this way. Helge Hafting |
From: Trudy P. <wgo...@ya...> - 2003-11-07 02:49:23
|
FUEL SAVER PRO This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet= ter using three patented processes from General Motors. Take a test drive Today - http://www.zppi.org/?axel=3D49 PROVEN TECHNOLOGY A certified U.S. Environmental Protection Agency (EPA) laboratory recently= completed tests on the new Fuel Saver. The results were astounding! Maste= r Service, a subsidiary of Ford Motor Company, also conducted extensive em= issions testing and obtained similar, unheard of results. The achievements= of the Fuel Saver is so noteworthy to the environmental community, that C= ommercial News has featured it as their cover story in their June, 2000 ed= ition. Take a test drive Today - http://www.zppi.org/?axel=3D49 No more advertisements, thanks - http://www.aqmp.net/out5s/rem2e.asp zptj g bcatzfrauk crajs f n nwoilfenaqnjcobfzmwsbxk |