Bug#814855: linux-image-4.4.0-trunk-amd64: Please restore snd-emu10k1 module
Hello again, >> Is there any way to enable snd-emu10k1 on current kernel? > > No. > Well, It worked. >> Do we need to recompile it on our own? > > That won't help, its dependencies are not bet. > I've compiled my own 4.4.2 from kernel.org, so that was the way. I've started with the config from 4.3.0. >> >> What should I do to use my soundcard? > [...] > > Use an older kernel version; the kernel in jessie will continue to work > with unstable userland. As I simply like recent software versions I'd rather stick to newer branches. However, I haven't compiled my own kernel for ages, and I would have not suppose I'll actually ever need this skill in Debian. -- Best Regards Oskar Bożek
Bug#814855: linux-image-4.4.0-trunk-amd64: Please restore snd-emu10k1 module
Package: src:linux Version: 4.4.2-2 Followup-For: Bug #814855 Hi, Is there any way to enable snd-emu10k1 on current kernel? Do we need to recompile it on our own? The driver does not seem to be removed in mainline kernel, it's just disabled at build, am I right? I definetly won't ever need NVDIMM support in my host, and that was the reason because emu10k1 was dropped, as described here: https://lists.ubuntu.com/archives/kernel-team/2016-January/067683.html What should I do to use my soundcard? -- Package-specific info: ** Version: Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 20160205 (Debian 5.3.1-8) ) #1 SMP Debian 4.4.2-2 (2016-02-19) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 root=UUID=c4bcc83d-9b0b-4b45-8a5b-9365a65f872f ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [1.280297] usbhid: USB HID core driver [1.281279] input: A4TECH USB Device as /devices/pci:00/:00:1d.3/usb5/5-2/5-2:1.0/0003:09DA:9090.0001/input/input1 [1.336299] hid-generic 0003:09DA:9090.0001: input,hiddev0,hidraw0: USB HID v1.11 Keyboard [A4TECH USB Device] on usb-:00:1d.3-2/input0 [1.336550] input: A4TECH USB Device as /devices/pci:00/:00:1d.3/usb5/5-2/5-2:1.1/0003:09DA:9090.0002/input/input2 [1.336633] hid-generic 0003:09DA:9090.0002: input,hidraw1: USB HID v1.11 Mouse [A4TECH USB Device] on usb-:00:1d.3-2/input1 [1.496018] tsc: Refined TSC clocksource calibration: 2499.951 MHz [1.496022] clocksource: tsc: mask: 0x max_cycles: 0x24090ba845d, max_idle_ns: 440795332440 ns [2.496077] clocksource: Switched to clocksource tsc [3.612027] floppy0: no floppy controllers found [3.697258] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [3.733318] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: discard [4.041857] tsc: Marking TSC unstable due to TSC halts in idle [4.041871] ACPI: acpi_idle registered with cpuidle [4.042057] clocksource: Switched to clocksource hpet [4.042329] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3 [4.042334] ACPI: Power Button [PWRB] [4.042434] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 [4.042437] ACPI: Power Button [PWRF] [4.048905] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [4.056946] parport_pc 00:03: reported by Plug and Play ACPI [4.057023] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [4.068148] intel_rng: FWH not detected [4.069810] i801_smbus :00:1f.3: SMBus using PCI interrupt [4.076464] sd 0:0:0:0: Attached scsi generic sg0 type 0 [4.076688] [drm] Initialized drm 1.1.0 20060810 [4.076736] sd 0:0:1:0: Attached scsi generic sg1 type 0 [4.076853] sr 1:0:0:0: Attached scsi generic sg2 type 5 [4.077194] input: PC Speaker as /devices/platform/pcspkr/input/input5 [4.091022] gameport gameport0: EMU10K1 is pci:04:01.1/gameport0, io 0xde00, speed 1015kHz [4.160907] ACPI Warning: SystemIO range 0x0428-0x042F conflicts with OpRegion 0x042C-0x042D (\GP2C) (20150930/utaddress-254) [4.160915] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [4.160950] lpc_ich: Resource conflict(s) found affecting gpio_ich [4.165826] leds_ss4200: no LED devices found [4.219165] ppdev: user-space parallel port driver [4.224719] nvidia: module license 'NVIDIA' taints kernel. [4.224724] Disabling lock debugging due to kernel taint [4.232240] iTCO_vendor_support: vendor-support=0 [4.233943] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [4.234007] iTCO_wdt: Found a ICH7 or ICH7R TCO device (Version=2, TCOBASE=0x0460) [4.234137] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [4.236405] snd_hda_intel :01:00.1: Disabling MSI [4.236414] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [4.242649] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [4.243656] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [4.243667] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 352.79 Wed Jan 13 16:17:53 PST 2016 [5.049839] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input6 [5.049930] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input7 [5.050017] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input8 [5.050105] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input9 [7.076069] floppy0: no floppy controllers found [7.402992] EXT4-fs (sda1): re-mounted. Opts:
Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
Hello again, IMHO there is a bug - mime type is incorrect in cups to cups scenario: d [15/Feb/2015:16:09:18 +0100] add_file(con=0xb891d028[15], job=843, filetype=application/vnd.cups-pdf, compression=1) which causes filtering by foomatic and fail: D [15/Feb/2015:16:13:33 +0100] [Job 844] Cannot process STDIN: Unknown filetype. with windows client the mime is set correctly: d [15/Feb/2015:16:02:31 +0100] add_file(con=0xb891d028[15], job=842, filetype=application/octet-stream, compression=0) so it works. I don't know if mime is set (forced?) by the client or detected by the server - although, as the data is already in zjstream it should not be detected as application/vnd.cups-pdf, as zjstream doesn't have its own application/octet-stream should be used. It's much less important as a working bypass is known, but it should work with default settings anyway. If You need full debug logs of both scenario - I'll post them. If You choose to close this bug - it's fine too, as it works. Thank You for the working solution anyway -- Best Regards Oskar 2015-02-16 12:23 GMT+01:00 Brian Potkin claremont...@gmail.com: On Sun 15 Feb 2015 at 12:37:06 +0100, Oskar Bożek wrote: Ok, so what should I try now? How I should prevent double-processing? If you are insisting on processing on the client lpadmin -p whatever -v whatever -E -m raw on the server. This works for me. None of the problems you are having appear to be due to bugs in the printing system. I'd suggest debian-user may be a more appropropiate place to discuss them. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
Ok, so what should I try now? How I should prevent double-processing? After reading #769058 I supposed it's gzip related, but I haven't managed to properly disable it, nor catch the gzipped file anywhere. Although, It used to work with older versions. -- Regards Oskar 2015-02-09 18:06 GMT+01:00 Brian Potkin claremont...@gmail.com: On Sat 07 Feb 2015 at 11:49:10 +0100, Oskar Bożek wrote: Hellp Oskar, Thank you for your report. Please consider following configuration: Raspberry Pi with raspbian wheezy with printer-driver-foo2zjs 20120510dfsg0-1 cups 1.5.3-5+deb7u4 and a HP Laserjet 1018 connected. Client (amd64 PC) with Debian jessie with printer-driver-foo2zjs 20140925dfsg0-3 cups 1.7.5-10 Printing from client to server over IPP does not work. Both are set to foo2zjs driver. The job undergoes two sets of processing - once on the client and then on the server. I do not understand why this is necessary. If processing on the client is a must the queue on the server should be a raw one. #769058 is a similar report. It is difficult to accept there is a bug in the behaviour of the printing system. Client is doing the ghostscript job, foo2zjs job, and sending the zjstream over IPP. The stream is then processed by server, and here the fail comes: D [07/Feb/2015:10:18:24 +0100] [Job 798] Cannot process STDIN: Unknown filetype. Possibly the file type is application/vnd.cups-pdf. D [07/Feb/2015:10:18:24 +0100] [Job 798] Process is dying with Could not print file STDIN D [07/Feb/2015:10:18:24 +0100] [Job 798] , exit stat 2 D [07/Feb/2015:10:18:24 +0100] [Job 798] Cleaning up... D [07/Feb/2015:10:18:24 +0100] [Job 798] Sent 0 bytes... D [07/Feb/2015:10:18:24 +0100] [Job 798] Waiting for read thread to exit... D [07/Feb/2015:10:18:24 +0100] [Job 798] Read thread still active, aborting the pending read... D [07/Feb/2015:10:18:24 +0100] [Job 798] End of messages D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state=3(idle) D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state- message=/usr/lib/cups/filter/foomatic-rip failed D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state-reasons=none E [07/Feb/2015:10:23:29 +0100] [Job 798] Stopping unresponsive job! Basically - zjs is not sent directly to the printer as it should. It used to work some time ago, with some limitations, like page number always set to 1, etc. The basic solution is to send generic postscript stream over IPP (setting driver on client to Generic Postscript Printer) and process it to zjs on server. It works, but foo2zjs on Raspberry Pi is obviously very inefficient. The file type given to the server is application/vnd.cups-postscript, so this works. Why do I even report it? Because using MS Windows as clients, and sending client-side processed stream over IPP just works perfectly, so there must be some client-side solution. That's the desired way because of processing power. Jobs from Windows clients undergo no further processing on the server. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
Ok, I've changed *cupsFilter: application/vnd.cups-postscript 100 foomatic-rip *cupsFilter: application/vnd.cups-pdf 0 foomatic-rip to *cupsFilter: application/vnd.cups-postscript 100 - *cupsFilter: application/vnd.cups-pdf 0 - and It now works remotely. (after some time - I've changed it BACK to foomatic-rip - it still works. even after printserver reboot). Local printing does NOT work with this printer, despite chaging it back to foomatic-rip. I don't need it currently. It looks like the modified PPD has been cached somewhere(?!). The automatically discovered printer (avahi?) with server side processing now does not work neither, but it used to. Modifying the settings from cups panel recreates the problem, and the problem is present for freshly added duplicates of the printer. So the current situation is: Cups with foo2zjs on client puts the stream with unknown mime to the server. The server matches the stream to one of those: application/vnd.cups-pdf application/vnd.cups-postscript but it should not - as raw stream it should be sent directly. 2015-02-15 12:37 GMT+01:00 Oskar Bożek boz...@gmail.com: Ok, so what should I try now? How I should prevent double-processing? After reading #769058 I supposed it's gzip related, but I haven't managed to properly disable it, nor catch the gzipped file anywhere. Although, It used to work with older versions. -- Regards Oskar 2015-02-09 18:06 GMT+01:00 Brian Potkin claremont...@gmail.com: On Sat 07 Feb 2015 at 11:49:10 +0100, Oskar Bożek wrote: Hellp Oskar, Thank you for your report. Please consider following configuration: Raspberry Pi with raspbian wheezy with printer-driver-foo2zjs 20120510dfsg0-1 cups 1.5.3-5+deb7u4 and a HP Laserjet 1018 connected. Client (amd64 PC) with Debian jessie with printer-driver-foo2zjs 20140925dfsg0-3 cups 1.7.5-10 Printing from client to server over IPP does not work. Both are set to foo2zjs driver. The job undergoes two sets of processing - once on the client and then on the server. I do not understand why this is necessary. If processing on the client is a must the queue on the server should be a raw one. #769058 is a similar report. It is difficult to accept there is a bug in the behaviour of the printing system. Client is doing the ghostscript job, foo2zjs job, and sending the zjstream over IPP. The stream is then processed by server, and here the fail comes: D [07/Feb/2015:10:18:24 +0100] [Job 798] Cannot process STDIN: Unknown filetype. Possibly the file type is application/vnd.cups-pdf. D [07/Feb/2015:10:18:24 +0100] [Job 798] Process is dying with Could not print file STDIN D [07/Feb/2015:10:18:24 +0100] [Job 798] , exit stat 2 D [07/Feb/2015:10:18:24 +0100] [Job 798] Cleaning up... D [07/Feb/2015:10:18:24 +0100] [Job 798] Sent 0 bytes... D [07/Feb/2015:10:18:24 +0100] [Job 798] Waiting for read thread to exit... D [07/Feb/2015:10:18:24 +0100] [Job 798] Read thread still active, aborting the pending read... D [07/Feb/2015:10:18:24 +0100] [Job 798] End of messages D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state=3(idle) D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state- message=/usr/lib/cups/filter/foomatic-rip failed D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state-reasons=none E [07/Feb/2015:10:23:29 +0100] [Job 798] Stopping unresponsive job! Basically - zjs is not sent directly to the printer as it should. It used to work some time ago, with some limitations, like page number always set to 1, etc. The basic solution is to send generic postscript stream over IPP (setting driver on client to Generic Postscript Printer) and process it to zjs on server. It works, but foo2zjs on Raspberry Pi is obviously very inefficient. The file type given to the server is application/vnd.cups-postscript, so this works. Why do I even report it? Because using MS Windows as clients, and sending client-side processed stream over IPP just works perfectly, so there must be some client-side solution. That's the desired way because of processing power. Jobs from Windows clients undergo no further processing on the server. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
Source: foo2zjs Severity: important Tags: upstream Dear Maintainer, Please consider following configuration: Raspberry Pi with raspbian wheezy with printer-driver-foo2zjs 20120510dfsg0-1 cups 1.5.3-5+deb7u4 and a HP Laserjet 1018 connected. Client (amd64 PC) with Debian jessie with printer-driver-foo2zjs 20140925dfsg0-3 cups 1.7.5-10 Printing from client to server over IPP does not work. Both are set to foo2zjs driver. Client is doing the ghostscript job, foo2zjs job, and sending the zjstream over IPP. The stream is then processed by server, and here the fail comes: D [07/Feb/2015:10:18:24 +0100] [Job 798] Cannot process STDIN: Unknown filetype. D [07/Feb/2015:10:18:24 +0100] [Job 798] Process is dying with Could not print file STDIN D [07/Feb/2015:10:18:24 +0100] [Job 798] , exit stat 2 D [07/Feb/2015:10:18:24 +0100] [Job 798] Cleaning up... D [07/Feb/2015:10:18:24 +0100] [Job 798] Sent 0 bytes... D [07/Feb/2015:10:18:24 +0100] [Job 798] Waiting for read thread to exit... D [07/Feb/2015:10:18:24 +0100] [Job 798] Read thread still active, aborting the pending read... D [07/Feb/2015:10:18:24 +0100] [Job 798] End of messages D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state=3(idle) D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state- message=/usr/lib/cups/filter/foomatic-rip failed D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state-reasons=none E [07/Feb/2015:10:23:29 +0100] [Job 798] Stopping unresponsive job! Basically - zjs is not sent directly to the printer as it should. It used to work some time ago, with some limitations, like page number always set to 1, etc. The basic solution is to send generic postscript stream over IPP (setting driver on client to Generic Postscript Printer) and process it to zjs on server. It works, but foo2zjs on Raspberry Pi is obviously very inefficient. Why do I even report it? Because using MS Windows as clients, and sending client-side processed stream over IPP just works perfectly, so there must be some client-side solution. That's the desired way because of processing power. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663868: Still not working correctly under one of my Debian boxes...
After de-blacklisting usblp:
Jun 30 17:57:18 limes kernel: [ 569.232502] usb 1-2: new full-speed USB
device number 4 using uhci_hcd
Jun 30 17:57:18 limes kernel: [ 569.400511] usb 1-2: New USB device found,
idVendor=03f0, idProduct=4117
Jun 30 17:57:18 limes kernel: [ 569.400549] usb 1-2: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Jun 30 17:57:18 limes kernel: [ 569.400580] usb 1-2: Product: HP LaserJet
1018
Jun 30 17:57:18 limes kernel: [ 569.400606] usb 1-2: Manufacturer:
Hewlett-Packard
Jun 30 17:57:18 limes kernel: [ 569.400630] usb 1-2: SerialNumber: KP32RZ9
Jun 30 17:57:18 limes kernel: [ 569.416371] usblp0: USB Bidirectional
printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
Jun 30 17:57:18 limes udevd[4187]: missing file parameter for attr
Jun 30 17:57:18 limes hp-mkuri: io/hpmud/model.c 625: unable to find
[s{product}] support-type in /usr/share/hplip/data/models/models.dat
Jun 30 17:57:21 limes /usr/sbin/hplj1018: foo2zjs: loading HP LaserJet 1018
firmware /lib/firmware/hp/sihp1018.dl to /dev/usb/lp0 ...
Jun 30 17:57:23 limes /usr/sbin/hplj1018: foo2zjs: ... download successful.
Jun 30 17:57:27 limes colord-sane: io/hpmud/musb.c 2066: Invalid usb_open:
Permission denied
Jun 30 17:57:35 limes colord-sane: io/hpmud/musb.c 2066: Invalid usb_open:
Permission denied
so far... OK
and I hoped to print something, and then:
Jun 30 18:01:19 limes kernel: [ 810.242823] usblp0: removed
Jun 30 18:01:24 limes colord-sane: io/hpmud/musb.c 2066: Invalid usb_open:
Permission denied
Jun 30 18:01:30 limes kernel: [ 821.263309] usblp0: USB Bidirectional
printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
Jun 30 18:01:35 limes kernel: [ 826.333158] usblp0: nonzero read bulk
status received: -108
Jun 30 18:01:38 limes kernel: [ 829.376378] usblp0: removed
Jun 30 18:01:49 limes kernel: [ 840.410288] usblp0: USB Bidirectional
printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
Jun 30 18:01:49 limes colord-sane: io/hpmud/musb.c 2066: Invalid usb_open:
Permission denied
Jun 30 18:01:54 limes kernel: [ 845.425103] usblp0: nonzero read bulk
status received: -108
Jun 30 18:01:57 limes kernel: [ 848.519229] usblp0: removed
Jun 30 18:02:03 limes colord-sane: io/hpmud/musb.c 2066: Invalid usb_open:
Permission denied
Jun 30 18:02:08 limes kernel: [ 859.550241] usblp0: USB Bidirectional
printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
Jun 30 18:02:13 limes kernel: [ 864.563026] usblp0: nonzero read bulk
status received: -108
Jun 30 18:02:16 limes kernel: [ 867.642164] usblp0: removed
Jun 30 18:02:22 limes colord-sane: io/hpmud/musb.c 2066: Invalid usb_open:
Permission denied
Jun 30 18:02:27 limes kernel: [ 878.669191] usblp0: USB Bidirectional
printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
Jun 30 18:02:32 limes kernel: [ 883.680980] usblp0: nonzero read bulk
status received: -108
Jun 30 18:02:35 limes kernel: [ 886.770369] usblp0: removed
Jun 30 18:02:39 limes kernel: [ 890.744639] usblp: can't set desired
altsetting 0 on interface 0
It's a mixed squeeze/wheezy box, I will check it on current stable.
Bug#714538: libjpeg8: libjpeg.so.8.4.0 segfaults in wheezy when processing big files with vips or iipimage-server
Iipserver seems to be unrelated to vips. The key here is probably the fact, that in both cases I've tried to use jpeg compression in tiff container. (created by vips, read by iipserver). 2013/6/30 Bill Allombert bill.allomb...@math.u-bordeaux1.fr On Sun, Jun 30, 2013 at 05:30:41PM +0200, boskar wrote: Package: libjpeg8 Version: 8d-1 Severity: normal iipimage-server and vips are crashing while processing large (200 MB) images. First I tried to covert image from openslide-compatibile (internally jpeg tiles) format using vips from stable repository. It creashed subsequently with Jun 30 16:13:13 hostname: [867164.398836] vips[10889]: segfault at ip 7fbc9eb201d7 sp 7c3ee190 error 7 in libjpeg.so.8.4.0[7fbc9eaf6000+3a000] Jun 30 16:31:52 hostname: [868282.002271] vips[11125]: segfault at ip 7fdae27921d7 sp 7fffdf0d68c0 error 7 in libjpeg.so.8.4.0[7fdae2768000+3a000] Hello, Could you provide a way to reproduce the crash that does not depends on vips code ? the fact that the segfault happen in libjpeg does not imply that the libjpeg code is at fault, it can be improperly used. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here.
Bug#640946: mobile-broadband-provider-info: New providers for Poland (and top-up/balance support)
Package: mobile-broadband-provider-info Version: 20110806-1 Severity: normal Tags: patch I've recently added some data to the database. Changes: - A lot of new operators, including non-default biling more plans - Top-up/balance codes for gnome-prepaid-manager - CDMA operators Bug has been reported to https://bugzilla.gnome.org/show_bug.cgi?id=658171 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff --git a/serviceproviders.xml b/serviceproviders.xml index 40a7390..055f08f 100644 --- a/serviceproviders.xml +++ b/serviceproviders.xml @@ -5405,13 +5405,18 @@ conceived. !-- Poland -- country code=pl + !-- Polish physical operators -- provider - nameERA/name + nameT-mobile/name!-- rebranded from Era in 2011 -- gsm network-id mcc=260 mnc=02/ - apn value=erainternet -usernameerainternet/username -passworderainternet/password + balance-check +ussd*101#/ussd + /balance-check + balance-top-up +ussd replacement=CODE*111*CODE#/ussd + /balance-top-up + apn value=internet dns213.158.194.1/dns dns213.158.193.38/dns /apn @@ -5421,13 +5426,145 @@ conceived. namePlay Online/name gsm network-id mcc=260 mnc=06/ - apn value=Internet/ + balance-check +ussd*101#/ussd +ussd*155#/ussd + /balance-check + balance-top-up +ussd replacement=CODE*100*CODE#/ussd + /balance-top-up + apn value=internet/ + /gsm + /provider + provider + nameOrange/name + gsm + network-id mcc=260 mnc=03/ + balance-check +ussd*124*#/ussd + /balance-check + balance-top-up +ussd replacement=CODE*125*CODE#/ussd + /balance-top-up + apn value=internet +nameStandard access - with image compression/name +name xml:lang=plDostęp standardowy - z kompresją grafiki/name +usernameinternet/username +passwordinternet/password +dns194.9.223.79/dns +dns194.204.159.1/dns + /apn + apn value=vpn +nameVPN mode access without compression (requires activation)/name +name xml:lang=plDostęp VPN bez kompresji (wymaga aktywacji)/name +usernameinternet/username +passwordinternet/password +dns194.9.223.79/dns +dns194.204.159.1/dns + /apn + /gsm + cdma + usernamecdma@orange/username + passwordorange/password + /cdma + /provider + provider + namePlus/name + gsm + network-id mcc=260 mnc=01/ + balance-check +ussd*100#/ussd + /balance-check + balance-top-up +ussd replacement=CODE*123*CODE#/ussd + /balance-top-up + apn value=www.plusgsm.pl +nameStandard access/name +name xml:lang=plDostęp standardowy/name +usernameplusgsm/username +passwordplusgsm/password +dns212.2.96.51/dns +dns212.2.96.52/dns + /apn + apn value=pro.plusgsm.pl +nameExternal dynamic IP address (requires activation)/name +name xml:lang=plZewnętrzny dynamiczny adres IP (wymaga aktywacji)/name +usernameplusgsm/username +passwordplusgsm/password +dns212.2.96.51/dns +dns212.2.96.52/dns + /apn + apn value=m2m.plusgsm.pl +nameExternal static IP address (requires activation)/name +name xml:lang=plZewnętrzny statyczny adres IP (wymaga aktywacji)/name +usernameplusgsm/username +passwordplusgsm/password +dns212.2.96.51/dns +dns212.2.96.52/dns + /apn + apn value=optimizer +nameiPlus optimizer with data compression/name +name xml:lang=pliPlus optimizer z kompresją danych/name +dns212.2.96.51/dns +dns212.2.96.52/dns + /apn + /gsm + /provider + provider + nameCyfrowy Polsat/name + gsm + network-id mcc=260 mnc=12/ + apn value=multi.internet/ + /gsm + /provider + provider + nameaero2/name + gsm + network-id mcc=260 mnc=17/ + apn value=darmowy/ + /gsm + /provider + !-- Polish MVNO operators -- + provider + nameMultimo/name + gsm + network-id mcc=260 mnc=03/ + apn value=internet +nameDefault APN/name +usernameinternet/username +passwordinternet/password + /apn + apn value=mni.internet +nameAPN: mni.internet/name +usernamemni.internet/username + /apn + apn value=telogic.internet +nameAPN: telogic.internet/name +usernametelogic.internet/username + /apn + /gsm + cdma + usernamecdma@orange/username + passwordorange/password + /cdma + /provider + provider + nameFreeM/name + gsm + network-id mcc=260 mnc=01/ + apn value=freedata.pl/ /gsm /provider provider nameHeyah/name gsm network-id mcc=260 mnc=02/ + balance-check +ussd*108#/ussd + /balance-check + balance-top-up +ussd replacement=CODE*109*CODE#/ussd + /balance-top-up apn value=heyah.pl usernameheyah/username passwordheyah/password @@ -5437,34 +5574,92 @@ conceived. /gsm /provider provider - nameOrange/name + nameGaduAIR/name + gsm +
