Bug#1057734: dahdi-dkms: Update to v3.3.0 and re-enable wctdm for TDM400P hardware
Package: dahdi-dkms Version: 1:3.1.0+git20230717~dfsg-5 Severity: wishlist Dear Maintainer, I lost support for my TDM400P when updating to v3.1.0 as upstream had removed the wctdm module. v3.3.0 brings it back, so an update to that version along with re-enabling the module in dkms.conf.in would be greatly appreciated. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dahdi-dkms depends on: ii dkms 3.0.12-1 ii dpkg-dev 1.22.1 ii gawk 1:5.2.1-2 ii gcc4:13.2.0-2 ii libc6-dev 2.37-13 ii make 4.3-4.1 Versions of packages dahdi-dkms recommends: ii dahdi-linux 1:3.1.0+git20230717~dfsg-5 dahdi-dkms suggests no packages. -- no debconf information
Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4
I'm pretty happy with that solution. the downside would be that the Z3 constraint solver can't be used by LLVM. Ubuntu and Fedora currently have it disabled for all architectures and I'm not seeing any bug reports. On Mon, Oct 17, 2022 at 3:33 PM Bernhard Übelacker wrote: > > Hello Karo, hello Dill, > I tried to carry this issue to the llvm people, if it > might be possible to drop libz3 linking of libllvm at i386. > This should mitigate most visible issues, > but I am not sure what the downsides would be. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021926 > > Kind regards, > Bernhard
Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4
> The package pulling in libz3-4 into the dependency chain is libllvm14.
> I've noticed the ubuntu version of the package does not link against
> libz3-4 and the libz3-4 package can be removed from the system and
> xorg and mesa function just fine. Perhaps a version of libllvm14
> compiled without libz3-4 support that could be installed on instead or
> even along side?
A look at the control file for libllvm14 gives a little more detail:
Z3_FLAG = -DLLVM_ENABLE_Z3_SOLVER=OFF
ifeq ($(shell dpkg --compare-versions $(shell dpkg-query -W -f
'$${Version}' libz3-dev) gt 4.7.0; echo $$?),0)
# no ocaml support in main for Ubuntu
ifneq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
Z3_FLAG = -DLLVM_ENABLE_Z3_SOLVER=ON
endif
endif
STAGE_2_CMAKE_EXTRA += $(Z3_FLAG)
https://www.cambus.net/clang-static-analyzer-and-the-z3-constraint-solver/
I'm pretty sure the "no ocaml support in main for Ubuntu" is in error
and should read "no z3 constraint solver support in main for Ubuntu".
The author seems to have gotten the similarly named z3 constraint
solver and the LLVM backend for ocaml (Z3) confused.
https://github.com/ohmi/Z3
Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4
On Tue, Oct 11, 2022 at 4:06 AM karogyoker999 wrote: > > > As far as I see your MR just adds a dependency to sse2-support, > > which I guess just makes the installation abort in case of a CPU > > not supporting sse2, so I guess this would just make > > mesa not installable on your hardware? > > Exactly. > > It will abort the installation as it wouldn't work anyways. > Mesa now requires SSE2 and therefore Xorg as well. > The workaround is to use Wayland with GNOME or KDE. > But KDE requires SSE2 since several months too (and therefore fails to > install). > It is better to have the installation fail rather than > having an unusable system after install. Because in the latter case, > it would mean that users would be disappointed, much time would be wasted > to troubleshoot. Failing the installation with a clear error message > is a much better solution. This is a bit of a further pain point for those out there running on P6 systems as they commonly have video hardware that only supports DRI1. > The alternative would be to disable SSE2 for all i386 packages of libz3-4. > But usually maintainers don't like that since that would have a performance > impact on Pentium 4 CPUs. So there is a choice to make: disable SSE2 on > all x86_32 CPUs or fail the install on everything except Pentium 4. According to the developers of libz4-3, the precision of the FPU x87 registers is not sufficient therefore a libz4-3 package compiled without SSE2 would be non-functional. It would be far better if libz3-4 could fail late rather than early. If it could fail later, in the case that calls to libz3-4 were made I think that would avoid the current issue. Perhaps if video hardware that requires shader compilation isn't present, no failures would occur. However the crash occurs at dlopen time as there are a number of c++ static initializers that get executed so even if no calls to libz3-4 are even made, or even calls to the mesa library that links to libllvm14, which links to libz3-4, everything works fine. I'm not even certain that libz3-4 is ever even called by mesa. I think it's just an option feature of libllvm and because mesa links libllvm, it ends up calling dlopen on the libz3-4 library. The debian changelog reads: * Enable Z3 solver (llvm & clang) to improve the quality of the static analysis results This doesn't sound like a feature mesa needs and I can't find any mention of mesa using the z3 solver. > There is a Debian patch [1] for the z3 package which does something with SSE2. > But then why is it still crashing? Maybe z3 has some hardcoded SSE2 > instruction somewhere? > Or it has been just compiled with the incorrect compiler flags? Doesn't appear to be disabling SSE2, just trying to make something work when SSE2 is disabled. Not sure why. > To have both performance and compatibility, a runtime check would be needed > to be added, but that would mean a significant amount of work. > > Until this work is not done by someone, failing the installation is > still better than > crashing and leaving the system in an unbootable state. > > [1]: https://sources.debian.org/patches/z3/4.8.12-1/00-intrinsics.patch/ The package pulling in libz3-4 into the dependency chain is libllvm14. I've noticed the ubuntu version of the package does not link against libz3-4 and the libz3-4 package can be removed from the system and xorg and mesa function just fine. Perhaps a version of libllvm14 compiled without libz3-4 support that could be installed on instead or even along side?
Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4
Package: libz3-4 Version: 4.8.12-1+b2 Severity: important X-Debbugs-Cc: russ.d...@gmail.com Dear Maintainer, Running Xorg on my Pentium Pro system crashes with an illegal instruction: (gdb) run Starting program: /usr/lib/xorg/Xorg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". X.Org X Server 1.21.1.4 X Protocol Version 11, Revision 0 Current Operating System: Linux ppro 5.19.0-2-686 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24) i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.19.0-2-686 root=UUID=dbeee09d-4412-49ab-9c61-a0900452f978 ro apic=debug console=tty0 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 mitigations=off xorg-server 2:21.1.4-2 (https://www.debian.org/support) Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep 26 15:14:33 2022 (==) Using system config directory "/usr/share/X11/xorg.conf.d" xf86TokenToOptinfo: table is NULL xf86TokenToOptinfo: table is NULL Program received signal SIGILL, Illegal instruction. 0xa95672de in ?? () from /lib/i386-linux-gnu/libz3.so.4 There doesn't seem to be an easy way to build libz3-4 without SSE support. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 5.19.0-2-686 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libz3-4 depends on: ii libc6 2.35-1 ii libgcc-s1 12.2.0-3 ii libstdc++6 12.2.0-3 libz3-4 recommends no packages. libz3-4 suggests no packages. -- no debconf information
Bug#392848: Updated patch for socks support
Just to show that yes, this is a useful feature, here's an updated patch.
My use case is a have a copy of Internet Explorer on my network that
needs to resolve and connect via socks5, but IE won't resolve hosts
via socks5 and instead leaks the requests over the network. tinyproxy
lets me direct IE instead to a HTTP/HTTPS proxy that forwards the
request over a socks5 proxy including the resolve.
This is against 1.8.0-122-g800c3a2, the config file format changed
slightly, upstream4 and upstream5 is used instead.
diff --git a/src/conf.c b/src/conf.c
index c003627..7033dff 100644
--- a/src/conf.c
+++ b/src/conf.c
@@ -160,6 +160,8 @@ static HANDLE_FUNC (handle_xtinyproxy);
#ifdef UPSTREAM_SUPPORT
static HANDLE_FUNC (handle_upstream);
+static HANDLE_FUNC (handle_upstream4);
+static HANDLE_FUNC (handle_upstream5);
static HANDLE_FUNC (handle_upstream_no);
#endif
@@ -257,6 +259,14 @@ struct {
BEGIN (upstream) WS ( IP | ALNUM ) : INT ( WS STR
)? END, handle_upstream, NULL
},
+{
+BEGIN (upstream4) WS ( IP | ALNUM ) : INT ( WS STR
+ )? END, handle_upstream4, NULL
+},
+{
+BEGIN (upstream5) WS ( IP | ALNUM ) : INT ( WS STR
+ )? END, handle_upstream5, NULL
+},
#endif
/* loglevel */
STDCONF (loglevel, (critical|error|warning|notice|connect|info),
@@ -1070,7 +1080,8 @@ static HANDLE_FUNC (handle_reversepath)
#endif
#ifdef UPSTREAM_SUPPORT
-static HANDLE_FUNC (handle_upstream)
+static int _handle_upstream(struct config_s* conf, const char* line,
+ regmatch_t match[], proxy_type type)
{
char *ip;
int port;
@@ -1084,11 +1095,11 @@ static HANDLE_FUNC (handle_upstream)
if (match[10].rm_so != -1) {
domain = get_string_arg (line, match[10]);
if (domain) {
-upstream_add (ip, port, domain, conf-upstream_list);
+upstream_add (ip, port, domain, type,
conf-upstream_list);
safefree (domain);
}
} else {
-upstream_add (ip, port, NULL, conf-upstream_list);
+upstream_add (ip, port, NULL, type, conf-upstream_list);
}
safefree (ip);
@@ -1096,6 +1107,21 @@ static HANDLE_FUNC (handle_upstream)
return 0;
}
+static HANDLE_FUNC (handle_upstream)
+{
+ return _handle_upstream(conf, line, match, HTTP_TYPE);
+}
+
+static HANDLE_FUNC (handle_upstream4)
+{
+ return _handle_upstream(conf, line, match, SOCKS4_TYPE);
+}
+
+static HANDLE_FUNC (handle_upstream5)
+{
+ return _handle_upstream(conf, line, match, SOCKS5_TYPE);
+}
+
static HANDLE_FUNC (handle_upstream_no)
{
char *domain;
@@ -1104,7 +1130,7 @@ static HANDLE_FUNC (handle_upstream_no)
if (!domain)
return -1;
-upstream_add (NULL, 0, domain, conf-upstream_list);
+upstream_add (NULL, 0, domain, HTTP_TYPE, conf-upstream_list);
safefree (domain);
return 0;
diff --git a/src/reqs.c b/src/reqs.c
index d0f296f..dae13ce 100644
--- a/src/reqs.c
+++ b/src/reqs.c
@@ -61,9 +61,11 @@
#ifdef UPSTREAM_SUPPORT
# define UPSTREAM_CONFIGURED() (config.upstream_list != NULL)
# define UPSTREAM_HOST(host) upstream_get(host, config.upstream_list)
+# define UPSTREAM_IS_HTTP(conn) (conn-upstream_proxy != NULL
conn-upstream_proxy-type == HTTP_TYPE)
#else
# define UPSTREAM_CONFIGURED() (0)
# define UPSTREAM_HOST(host) (NULL)
+# define UPSTREAM_IS_HTTP(up) (0)
#endif
/*
@@ -847,10 +849,10 @@ process_client_headers (struct conn_s *connptr, hashmap_t
hashofheaders)
/*
* Don't send headers if there's already an error, if the request was
* a stats request, or if this was a CONNECT method (unless upstream
- * proxy is in use.)
+ * http proxy is in use.)
*/
if (connptr-server_fd == -1 || connptr-show_stats
-|| (connptr-connect_method (connptr-upstream_proxy == NULL)))
{
+|| (connptr-connect_method ! UPSTREAM_IS_HTTP(connptr))) {
log_message (LOG_INFO,
Not sending client headers to remote machine);
return 0;
@@ -1259,6 +1261,88 @@ static void relay_connection (struct conn_s *connptr)
return;
}
+static int
+connect_to_upstream_proxy(struct conn_s *connptr, struct request_s *request)
+{
+ int len;
+ char buff[512]; /* won't use more than 7 + 255 */
+ unsigned short port;
+ struct hostent *host;
+ struct upstream *cur_upstream = connptr-upstream_proxy;
+
+ log_message(LOG_CONN,
+ Established connection to %s proxy \%s\ using file
descriptor %d.,
+ proxy_type_name(cur_upstream-type), cur_upstream-host,
connptr-server_fd);
+
+ if (cur_upstream-type == SOCKS4_TYPE) {
+
+
Bug#593438: dahdi-source: Kernel panic while call in progress on TDM400P
On Wed, Aug 18, 2010 at 2:52 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: Thanks for the report, On Wed, Aug 18, 2010 at 01:27:46AM -0700, Russ Dill wrote: Package: dahdi-source Version: 1:2.3.0.1+dfsg-1 Severity: important Tags: upstream System becomes unreponsive, even to serial break sysrq (oops captured via serial console). This occurs after only a few minutes of call time. [ 9695.212106] BUG: unable to handle kernel NULL pointer dereference at 01f0 [ 9695.216018] IP: [c1001eaf] __switch_to+0x50/0x129 [ 9695.216018] *pde = [ 9695.216018] Oops: 0002 [#1] [ 9695.216018] last sysfs file: /sys/devices/pci:00/:00:10.2/usb4/4-2/idProduct [ 9695.216018] Modules linked in: dahdi_echocan_oslec echo loop snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_page_alloc] [ 9695.216018] [ 9695.216018] Pid: 14267, comm: tail Not tainted (2.6.32-5-486 #1) [ 9695.216018] EIP: 0060:[c1001eaf] EFLAGS: 00010046 CPU: 0 [ 9695.216018] EIP is at __switch_to+0x50/0x129 [ 9695.216018] EAX: 0001 EBX: ce835040 ECX: 57ab6cfd EDX: ce835040 [ 9695.216018] ESI: cd15e8a0 EDI: EBP: ESP: ce847f28 [ 9695.216018] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 9695.216018] Process tail (pid: 14267, ti=ce846000 task=cd15e8a0 task.ti=cd24e000) [ 9695.216018] Stack: [ 9695.216018] c101cf62 c08ea080 c08ea0ac 725916f1 cd16e540 cd15e8a0 c1242f26 [ 9695.216018] 0 ce835040 0046 cb023800 c1350604 ce8351fc 576e589e 08d1 c135ae30 [ 9695.216018] 0 0246 cd0c281c 0286 cd4af4b8 cb0238a4 ce80a0e0 ce847fb4 ce80a0e0 [ 9695.216018] Call Trace: [ 9695.216018] [c101cf62] ? set_next_entity+0x29/0x51 [ 9695.216018] [c1242f26] ? schedule+0x395/0x3d5 [ 9695.216018] [c1030d4a] ? worker_thread+0x90/0x1a4 [ 9695.216018] [c116e0a5] ? flush_to_ldisc+0x0/0x161 [ 9695.216018] [c1033570] ? autoremove_wake_function+0x0/0x2d [ 9695.216018] [c1030cba] ? worker_thread+0x0/0x1a4 [ 9695.216018] [c10331c8] ? kthread+0x60/0x65 [ 9695.216018] [c1033168] ? kthread+0x0/0x65 [ 9695.216018] [c1003997] ? kernel_thread_helper+0x7/0x10 [ 9695.216018] Code: 40 0c a8 01 74 56 a8 10 8b be 8c 02 00 00 74 1b 83 c8 ff 89 c2 0f ae 27 f6 87 00 02 00 00 01 74 23 80 7f 02 00 [ 9695.216018] EIP: [c1001eaf] __switch_to+0x50/0x129 SS:ESP 0068:ce847f28 [ 9695.216018] CR2: 01f0 [ 9695.216018] ---[ end trace 090adb1746d9327c ]--- [ 9695.452635] BUG: unable to handle kernel NULL pointer dereference at 01f0 [ 9695.456014] IP: [c1003b13] __math_state_restore+0x30/0x67 Yup. Could indeed be related to OSLEC and its unique feature of MMX code running in the interrupt handler. I'll try to look into it. An ugly workaround would be to disable the MMX optimizations of the OSLEC code (see drivers/staging/oslec/Kbuild , IIRC). That would have a noticable performance penalty, which may be rather meaningful on a system such as yours testing that now by removing the mmx_auto patch. A very interesting side effect is that my codec_g729.so is now working. The performance difference isn't a big deal as the system has more than enough horsepower to handle 2 or 3 calls. BTW, I've noticed that Greg KH has removed the USE_MMX and USE_SSE code from the staging tree. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593438: dahdi-source: Kernel panic while call in progress on TDM400P
Package: dahdi-source Version: 1:2.3.0.1+dfsg-1 Severity: important Tags: upstream System becomes unreponsive, even to serial break sysrq (oops captured via serial console). This occurs after only a few minutes of call time. [ 9695.212106] BUG: unable to handle kernel NULL pointer dereference at 01f0 [ 9695.216018] IP: [c1001eaf] __switch_to+0x50/0x129 [ 9695.216018] *pde = [ 9695.216018] Oops: 0002 [#1] [ 9695.216018] last sysfs file: /sys/devices/pci:00/:00:10.2/usb4/4-2/idProduct [ 9695.216018] Modules linked in: dahdi_echocan_oslec echo loop snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_page_alloc] [ 9695.216018] [ 9695.216018] Pid: 14267, comm: tail Not tainted (2.6.32-5-486 #1) [ 9695.216018] EIP: 0060:[c1001eaf] EFLAGS: 00010046 CPU: 0 [ 9695.216018] EIP is at __switch_to+0x50/0x129 [ 9695.216018] EAX: 0001 EBX: ce835040 ECX: 57ab6cfd EDX: ce835040 [ 9695.216018] ESI: cd15e8a0 EDI: EBP: ESP: ce847f28 [ 9695.216018] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 9695.216018] Process tail (pid: 14267, ti=ce846000 task=cd15e8a0 task.ti=cd24e000) [ 9695.216018] Stack: [ 9695.216018] c101cf62 c08ea080 c08ea0ac 725916f1 cd16e540 cd15e8a0 c1242f26 [ 9695.216018] 0 ce835040 0046 cb023800 c1350604 ce8351fc 576e589e 08d1 c135ae30 [ 9695.216018] 0 0246 cd0c281c 0286 cd4af4b8 cb0238a4 ce80a0e0 ce847fb4 ce80a0e0 [ 9695.216018] Call Trace: [ 9695.216018] [c101cf62] ? set_next_entity+0x29/0x51 [ 9695.216018] [c1242f26] ? schedule+0x395/0x3d5 [ 9695.216018] [c1030d4a] ? worker_thread+0x90/0x1a4 [ 9695.216018] [c116e0a5] ? flush_to_ldisc+0x0/0x161 [ 9695.216018] [c1033570] ? autoremove_wake_function+0x0/0x2d [ 9695.216018] [c1030cba] ? worker_thread+0x0/0x1a4 [ 9695.216018] [c10331c8] ? kthread+0x60/0x65 [ 9695.216018] [c1033168] ? kthread+0x0/0x65 [ 9695.216018] [c1003997] ? kernel_thread_helper+0x7/0x10 [ 9695.216018] Code: 40 0c a8 01 74 56 a8 10 8b be 8c 02 00 00 74 1b 83 c8 ff 89 c2 0f ae 27 f6 87 00 02 00 00 01 74 23 80 7f 02 00 [ 9695.216018] EIP: [c1001eaf] __switch_to+0x50/0x129 SS:ESP 0068:ce847f28 [ 9695.216018] CR2: 01f0 [ 9695.216018] ---[ end trace 090adb1746d9327c ]--- [ 9695.452635] BUG: unable to handle kernel NULL pointer dereference at 01f0 [ 9695.456014] IP: [c1003b13] __math_state_restore+0x30/0x67 [ 9695.456014] *pde = [ 9695.456014] Oops: [#2] [ 9695.456014] last sysfs file: /sys/devices/pci:00/:00:10.2/usb4/4-2/idProduct [ 9695.456014] Modules linked in: dahdi_echocan_oslec echo loop snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_page_alloc] [ 9695.456014] [ 9695.456014] Pid: 14267, comm: tail Tainted: G D(2.6.32-5-486 #1) [ 9695.456014] EIP: 0060:[c1003b13] EFLAGS: 00010046 CPU: 0 [ 9695.456014] EIP is at __math_state_restore+0x30/0x67 [ 9695.456014] EAX: cd24e000 EBX: cd24e000 ECX: cd15e8a0 EDX: [ 9695.456014] ESI: cd15e8a0 EDI: EBP: cd266300 ESP: cd24fdfc [ 9695.456014] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 9695.456014] Process tail (pid: 14267, ti=cd24e000 task=cd15e8a0 task.ti=cd24e000) [ 9695.456014] Stack: [ 9695.456014] c135f658 cd24fe28 0007 c1244103 cd266300 c1244140 0246 [ 9695.456014] 0 cd266360 c1243dfb cd266360 0080 cd266f00 0007 0008 [ 9695.456014] 0 cd266300 cd32860e 007b 007b 00e0 cfeda029 [ 9695.456014] Call Trace: [ 9695.456014] [c124299e] ? panic+0x38/0xde [ 9695.456014] [c12446ec] ? oops_end+0x81/0x8d [ 9695.456014] [c1014d1c] ? no_context+0x104/0x10d [ 9695.456014] [c1014e6c] ? __bad_area_nosemaphore+0x147/0x152 [ 9695.456014] [c1245521] ? do_page_fault+0x0/0x26a [ 9695.456014] [c1014e81] ? bad_area_nosemaphore+0xa/0xc [ 9695.456014] [c1243dfb] ? error_code+0x6b/0x70 [ 9695.456014] [c1003b13] ? __math_state_restore+0x30/0x67 [ 9695.456014] [c1244103] ? do_device_not_available+0x0/0x4d [ 9695.456014] [c1244140] ? do_device_not_available+0x3d/0x4d [ 9695.456014] [c1243dfb] ? error_code+0x6b/0x70 [ 9695.456014] [cfeda029] ? fir16+0x29/0x7c [echo] [ 9695.456014] [cfeda1de] ? oslec_update+0x10a/0x3a8 [echo] [ 9695.456014] [cfee4025] ? echo_can_process+0x1f/0x2f [dahdi_echocan_oslec] [ 9695.456014] [cfb98520] ? __dahdi_ec_chunk+0x18d/0x2d7 [dahdi] [ 9695.456014] [cfc1b91f] ? wctdm_interrupt+0xb32/0xc0b [wctdm] [ 9695.456014] [c107d8fa] ? __do_fault+0x30c/0x33c [ 9695.456014] [c1058b02] ? handle_IRQ_event+0x4e/0x100 [ 9695.456014] [c1059d6d] ? handle_fasteoi_irq+0x4f/0x75 [ 9695.456014] [c1004507] ? handle_irq+0x17/0x1c [ 9695.456014] [c10041d6] ? do_IRQ+0x2b/0x76 [ 9695.456014] [c1003790] ? common_interrupt+0x30/0x40 [ 9695.456014] [c124560f] ? do_page_fault+0xee/0x26a [ 9695.456014] [c1245521] ? do_page_fault+0x0/0x26a [ 9695.456014] [c1243dfb] ? error_code+0x6b/0x70 processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 13 model name : VIA C7 Processor
Bug#205671: This breaks external modules.
I can no longer build my iptables target module against iptables-dev. I'm very confused with this change. In file included from libipt_AES.c:6: /usr/include/iptables.h:5:29: error: libiptc/libiptc.h: No such file or directory In file included from libipt_AES.c:6: /usr/include/iptables.h:19: error: expected declaration specifiers or '...' before 'iptc_handle_t' /usr/include/iptables.h:20: error: expected ';', ',' or ')' before 'chain' /usr/include/iptables.h:22: error: expected ';', ',' or ')' before 'chain' /usr/include/iptables.h:24: error: expected declaration specifiers or '...' before 'iptc_handle_t' /usr/include/iptables.h:25: error: expected declaration specifiers or '...' before 'iptc_handle_t' /usr/include/iptables.h:27: error: expected declaration specifiers or '...' before 'iptc_handle_t' libipt_AES.c:18: warning: 'struct ipt_entry_target' declared inside parameter list libipt_AES.c:23: warning: 'struct ipt_entry_target' declared inside parameter list libipt_AES.c:23: warning: 'struct ipt_entry' declared inside parameter list libipt_AES.c:33: warning: 'struct ipt_entry_target' declared inside parameter list libipt_AES.c:33: warning: 'struct ipt_ip' declared inside parameter list libipt_AES.c:37: warning: 'struct ipt_entry_target' declared inside parameter list libipt_AES.c:37: warning: 'struct ipt_ip' declared inside parameter list libipt_AES.c:41: error: variable 'targ' has initializer but incomplete type libipt_AES.c:42: error: unknown field 'name' specified in initializer libipt_AES.c:42: warning: excess elements in struct initializer libipt_AES.c:42: warning: (near initialization for 'targ') libipt_AES.c:43: error: unknown field 'help' specified in initializer libipt_AES.c:43: warning: excess elements in struct initializer libipt_AES.c:43: warning: (near initialization for 'targ') libipt_AES.c:44: error: unknown field 'init' specified in initializer libipt_AES.c:44: warning: excess elements in struct initializer libipt_AES.c:44: warning: (near initialization for 'targ') libipt_AES.c:45: error: unknown field 'parse' specified in initializer libipt_AES.c:45: warning: excess elements in struct initializer libipt_AES.c:45: warning: (near initialization for 'targ') libipt_AES.c:46: error: unknown field 'final_check' specified in initializer libipt_AES.c:46: warning: excess elements in struct initializer libipt_AES.c:46: warning: (near initialization for 'targ') libipt_AES.c:47: error: unknown field 'print' specified in initializer libipt_AES.c:47: warning: excess elements in struct initializer libipt_AES.c:47: warning: (near initialization for 'targ') libipt_AES.c:48: error: unknown field 'save' specified in initializer libipt_AES.c:48: warning: excess elements in struct initializer libipt_AES.c:48: warning: (near initialization for 'targ') libipt_AES.c:49: error: unknown field 'extra_opts' specified in initializer libipt_AES.c:49: warning: excess elements in struct initializer libipt_AES.c:49: warning: (near initialization for 'targ') libipt_AES.c: In function 'my_init': libipt_AES.c:54: error: invalid use of undefined type 'struct iptables_target' libipt_AES.c:55: warning: implicit declaration of function 'register_target' make: *** [libipt_AES.o] Error 1 [EMAIL PROTECTED]:~/src/enc_new$ nano /usr/include/iptables.h [EMAIL PROTECTED]:~/src/enc_new$ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338348: solution for debian bug #338348 ?
So we have 2 options: using TERM we get rid of udhcpc.pid but not of /etc/resolvconf/run/interface/eth0.udhcpc Actually, TERM should probably call the deconfig script. The only problem is that changing the behavior would probably change a number of peoples configurations. The issue is that a SIGTERM doesn't necessarily mean the user wants their connection severed. using SIGUSR2 we get rid of /etc/resolvconf/run/interface/eth0.udhcpc but not of udhcpc.pid If you want the connection to come down, then the documented behavior is to give a SIGUSR2 and then if you want it to die, a SIGTERM. Is there a third way ? Do you have any suggestion ? I would give a SIGUSR2 and then a SIGTERM, you don't need a delay between the signals. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302658: workaround for failure to obtain lease
On Tue, 2005-06-07 at 13:27 +, Kacper Wysocki wrote: On 06/07/05 08:51:14, Eric Van Buggenhaut wrote: On Tue, Jun 07, 2005 at 12:06:46PM +, Kacper Wysocki wrote: [snip] but instead of -else - /sbin/ifconfig $interface 0.0.0.0 fi +/sbin/ifconfig $interface 0.0.0.0 I'd rather use -else - /sbin/ifconfig $interface 0.0.0.0 fi +/sbin/ifconfig $interface up Any comment ? Thanks for the quick follow-up. Seems to work fine here, however the former ifconfig stanza is upstream, maybe they should use 'ifconfig $interface up' as well for their sample scripts, as it is indeed cleaner. -K sorry to jump in so late, but the purpose is not just to bring up the interface, but also to clear any address. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302019: use resolvconf
modifying the udhcpc scripts to user resolvconf would be very trivial. No patches to source necessary. (Patches to the scripts could be provided though) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
